Blue/Green Deployments
You can configure your apps to be deployed using a blue/green strategy, where Porter will keep the older version of your app running (the “blue” version), while it spins up an identical number of replicas for your app using a new build (the “green” version), and waits for the entire environment to be up and running, before switching traffic from the old version (“blue”) to the new version (“green”). Setting up B/G deployments for your app involves modifying your app’s configuration, as well as your build step in your CI system that’s responsible for updating the Porter app after a successful build.
Setup Sequence
Please note - this process needs to followed in the same sequence as presented below, and it is a good idea to complete the second step for tweaking your build step right after you’ve made changes to the Porter app; this will ensure any other builds/revisions will not conflict with B/G deployments.
Step 1: Modify your apps on Porter
On the Porter dashboard, navigate to the app you’d like to set this up for, and ensure DevOps Mode
is selected. The first step is to get the active image tag your app’s running - you’ll find this in the Source Settings
section under the Settings
tab. Note the image tag that’s currently selected.
Next, you need to navigate to the tab called Helm Values
. In this tab, add and modify the config blow below:
bluegreen:
activeImageTag: <tag>
disablePrimaryDeployment: true
enabled: true
imageTags:
- <tag>
For <tag>
, you’ll need to specify the image tag you noted down earlier. Once done, click Update Values
, and wait for your app to be refreshed.
Step 2: Modify your build process
This step involves modifying your CI build process to ensure that instead of using the Porter CLI to simply update the Porter app. In your current build process, you’ll see sections that use porter update config
to update the image tag being used for the app; we need to add an additional step right after this update, which tells Porter to switch traffic to the new version.
As an example, let’s consider the following Github Action workflow step, that currently simply updates an app on Porter called web-sample
with the new image tag:
porter-deploy-app:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v2.3.4
- name: Set Github tag
id: vars
run: echo "::set-output name=sha_short::$(git rev-parse --short HEAD)"
- name: Update configuration for web-sample
uses: porter-dev/porter-cli-action@v0.1.0
with:
command: update config --app web-sample --tag ${{ steps.vars.outputs.sha_short }} --stream
env:
PORTER_HOST: https://dashboard.getporter.dev
PORTER_CLUSTER: 0000
PORTER_PROJECT: 0000
PORTER_TOKEN: ${{ secrets.PORTER_TOKEN_0000 }}
To enable B/G deployments in this case, we’ll just add an additional step at the end of this block to switch traffic, like so:
porter-deploy-app:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v2.3.4
- name: Set Github tag
id: vars
run: echo "::set-output name=sha_short::$(git rev-parse --short HEAD)"
- name: Update configuration for web-sample
uses: porter-dev/porter-cli-action@v0.1.0
with:
command: update config --app web-sample --tag ${{ steps.vars.outputs.sha_short }} --stream
env:
PORTER_HOST: https://dashboard.getporter.dev
PORTER_CLUSTER: 0000
PORTER_PROJECT: 0000
PORTER_TOKEN: ${{ secrets.PORTER_TOKEN_0000 }}
- name: Switch traffic to the new app once ready for web-sample
uses: porter-dev/porter-cli-action@v0.1.0
with:
command: deploy blue-green-switch --app web-sample --tag ${{ steps.vars.outputs.sha_short }}
env:
PORTER_HOST: https://dashboard.getporter.dev
PORTER_CLUSTER: 0000
PORTER_PROJECT: 0000
PORTER_TOKEN: ${{ secrets.PORTER_TOKEN_0000 }}
Once you’ve saved this and triggered a new set of builds, your CI runner will be able to specify a “green” version of your app, and switch traffic to it once the “green” version is ready.
Environment
You’ll need to ensure that PORTER_HOST
, PORTER_CLUSTER
, PORTER_PROJECT
and PORTER_TOKEN
are set correctly - you can reuse the same values as in your existing CI definition.
Multiple Revisions
When your app’s being deployed using the B/G deployment strategy, you’ll notice that each deployment causes your app to jump by three revisions:
- The first revision runs both “blue” and “green” versions in parallel, with traffic being directed towards the “blue” version.
- The second revision runs both “blue” and “green” versions in parallel, with traffic being directed towards the “green” version.
- The third - and final - revision removes the “blue” version, after verifying that traffic has been switched properly from “blue” to “green”.