Blue Green Deployments

blue green deployments allow the next version ( let's call it preview ) of your application to be in the same environment as your active version for some time until all your sanity checks are approved and you "promote" the preview to active getting started there are five core steps to support a blue green deployment for an existing kubernetes deployment ensure your target (destination) kubernetes cluster(s) have the argo rollouts controller installed (see install deploynow agent https //docs opsverse io/install the deploynow agent for more info) in your manifest/template, replace kind deployment to kind rollout in your manifest/template, replace apiversion apps/v1 to apiversion argoproj io/v1alpha1 in your manifest/template, replace spec strategy with bluegreen and add any specific configurable features https //argoproj github io/argo rollouts/features/bluegreen/#configurable features you like to support a preview service, add a kind service which is identical to your current "active" service, but change the name example a good sample app to show off this feature is from the argo rollouts blue green example https //github com/argoproj/rollouts demo/tree/master/examples/blue green manifests say we have a manifest, rollout bluegreen yaml , like so \# this example demonstrates a rollout using the blue green update strategy, which contains a manual \# gate before promoting the new stack apiversion argoproj io/v1alpha1 kind rollout metadata name rollout bluegreen spec replicas 2 revisionhistorylimit 2 selector matchlabels app rollout bluegreen template metadata labels app rollout bluegreen spec containers \ name rollouts demo image argoproj/rollouts demo\ green imagepullpolicy always ports \ containerport 8080 strategy bluegreen \# activeservice specifies the service to update with the new template hash at time of promotion \# this field is mandatory for the bluegreen update strategy activeservice rollout bluegreen active \# previewservice specifies the service to update with the new template hash before promotion \# this allows the preview stack to be reachable without serving production traffic \# this field is optional previewservice rollout bluegreen preview \# autopromotionenabled disables automated promotion of the new stack by pausing the rollout \# immediately before the promotion if omitted, the default behavior is to promote the new \# stack as soon as the replicaset are completely ready/available \# rollouts can be resumed using `kubectl argo rollouts promote rollout` autopromotionenabled false \ kind service apiversion v1 metadata name rollout bluegreen active spec selector app rollout bluegreen ports \ protocol tcp port 80 targetport 8080 \ kind service apiversion v1 metadata name rollout bluegreen preview spec selector app rollout bluegreen ports \ protocol tcp port 80 targetport 8080 note the extra preview service and the app set to image argoproj/rollouts demo\ blue create an argo app which points to this manifest since this is the initial rollout, notice how nothing is suspended and active is pointing to green port forwarding the active service shows green $ kubectl port forward svc/rollout bluegreen active 8080 80 everything is as expected update to a new version of the app now, let's update our git repo to change the version from green to blue when your argo app is next synced, notice how it gets in a suspended state this simply means there's a new version of your app, and your current active service will still be pointing to the original version until you promote this is proven by port forwarding both of the services and checking $ kubectl port forward svc/rollout bluegreen active 8080 80 $ kubectl port forward svc/rollout bluegreen preview 8080 80 the preview service can be sanity checked until you are ready to promote it to active promote the new app version to active when you are ready to promote the preview to active , you may click on promote full of the rollout at this point, the argo rollouts controller will ensure that all replicas of the pod have the preview pods promoted and the active service will route traffic to that pod we can confirm this by looking at the active service (which should now be "blue") $ kubectl port forward svc/rollout bluegreen active 8080 80