{"id":543,"date":"2019-12-01T20:00:00","date_gmt":"2019-12-02T04:00:00","guid":{"rendered":"http:\/\/blog.nillsf.com\/?p=543"},"modified":"2019-11-24T09:24:14","modified_gmt":"2019-11-24T17:24:14","slug":"integrating-your-a-helm-blue-green-deployment-into-a-ci-cd-pipeline","status":"publish","type":"post","link":"https:\/\/nillsf.com\/index.php\/2019\/12\/01\/integrating-your-a-helm-blue-green-deployment-into-a-ci-cd-pipeline\/","title":{"rendered":"Integrating your a helm blue\/green deployment into a CI\/CD pipeline"},"content":{"rendered":"\n

A while ago, I wrote about setting up a Kubernetes blue\/green deployment <\/a>using the service object in Kubernetes. All the work done there, was done editing yaml files and using direct kubectl commands, which you wouldn’t do in production. Later on, we updated those yaml files to Helm charts<\/a>, so we can update with a helm upgrade<\/code>.<\/p>\n\n\n\n

Today, we’ll take this to the next level and execute updates via a CI\/CD pipeline.<\/p>\n\n\n\n

Let’s get started. <\/p>\n\n\n\n

Environment we’ll use<\/h2>\n\n\n\n

I posted all the relevant files from my previous demo on Github<\/a>. We’ll be using this repo to trigger (CI\/)CD.<\/p>\n\n\n\n

As a CI\/CD tool I’m going to be using Azure pipelines. I haven’t tried out YAML pipelines before, so it’s a good time to finally give those a spin.<\/p>\n\n\n\n

As a run-time, we’ll use an AKS cluster. If you went along with me and deployed the blue\/green app in a cluster and still have them running, that is fine. If you don’t, that’s fine as well. Our pipeline will contain the option to execute the install if you haven’t done that yet.<\/p>\n\n\n\n

Let’s get started with building our pipeline.<\/p>\n\n\n\n

Building a CI\/CD pipeline in Azure Devops<\/h2>\n\n\n\n

We’ll login to Azure Devops<\/a>, and create a new pipeline. This asks us where the source code is hosted, which in our case will be Github (if you want to play along, I’d recommend making a fork of my blog repo).<\/p>\n\n\n\n

\"\"
We’ll select Github as our code repo.<\/figcaption><\/figure>\n\n\n\n

We’ll then authorize Azure pipelines in Github.<\/p>\n\n\n\n

\"\"
We need to authorize Azure Devops to use Github.<\/figcaption><\/figure>\n\n\n\n

Next we’ll select a repo, after which Github will again ask us for approval. As I might be doing more pipelines via Github, I’ll allow this in all my repos.<\/p>\n\n\n\n

\"\"
Final approval step.<\/figcaption><\/figure>\n\n\n\n

Next step would be to configure our pipeline. We’ll start of with a starter pipeline, as I don’t have an existing YAML pipeline.<\/p>\n\n\n\n

\"\"
We’ll start of with a starter pipeline.<\/figcaption><\/figure>\n\n\n\n

And this starter pipeline looks like this:<\/p>\n\n\n\n

# Starter pipeline\n# Start with a minimal pipeline that you can customize to build and deploy your code.\n# Add steps that build, run tests, deploy, and more:\n# https:\/\/aka.ms\/yaml\n\ntrigger:\n- master\n\npool:\n  vmImage: 'ubuntu-latest'\n\nsteps:\n- script: echo Hello, world!\n  displayName: 'Run a one-line script'\n\n- script: |\n    echo Add other tasks to build, test, and deploy your project.\n    echo See https:\/\/aka.ms\/yaml\n  displayName: 'Run a multi-line script'<\/code><\/pre>\n\n\n\n
We won’t make any changes just yet, but we’ll save this pipeline and run it for a first time. At this point, Azure DevOps whether to save the pipeline YAML to master, or to a branch. I was heavily conflicted between saving in a branch or on master (remember this post<\/a>?). I decided to hold myself accountable, and actually work on this in a branch, which Azure pipelines will create for us.<\/p>\n\n\n\n
\"\"
Saving our default YAML pipeline.<\/figcaption><\/figure>\n\n\n\n
This will trigger out pipeline to run, which looks finishes quickly (as it only does some echos.<\/p>\n\n\n\n
\"\"
Our pipeline finished quickly.<\/figcaption><\/figure>\n\n\n\n
We can drill-down in the job, and actually look at the job output.<\/p>\n\n\n\n
\"\"
We can see detailed logs about each step in the pipeline.<\/figcaption><\/figure>\n\n\n\n
Now, we’ll go ahead and make changes to our pipeline to execute a blue\/green deployment.<\/p>\n\n\n\n
Making a blue\/green deployment pipeline<\/h2>\n\n\n\n
The first thing we’ll need to do, is add our Kubernetes cluster to the pipeline by creating an environment in Azure Devops. <\/p>\n\n\n\n
\"\"
We’ll go ahead and create a new environment<\/figcaption><\/figure>\n\n\n\n
\"\"
We’ll name our environment and pick Kubernetes.<\/figcaption><\/figure>\n\n\n\n
\"\"
There’s a built-in connection to Azure, so we can easily pick our existing AKS cluster.<\/figcaption><\/figure>\n\n\n\n
Next up, we’ll start editing our pipeline itself. We’ll add the ‘Helm tool installer’ step and a ‘Package and deploy Helm charts’ step to our pipeline. We won’t do a Helm upgrade just yet, but we’ll do a helm ls<\/code>, just to see if Helm is installed correctly. This basic pipeline will look like:<\/p>\n\n\n\n
# Starter pipeline\n# Start with a minimal pipeline that you can customize to build and deploy your code.\n# Add steps that build, run tests, deploy, and more:\n# https:\/\/aka.ms\/yaml\n\ntrigger:\n- master\n\npool:\n  vmImage: 'ubuntu-latest'\n\njobs:\n- job: Update_version\n  steps:\n  - task: HelmInstaller@1\n    inputs:\n      helmVersionToInstall: '3.0.0'\n  - task: HelmDeploy@0\n    inputs:\n      connectionType: 'Kubernetes Service Connection'\n      kubernetesServiceConnection: 'k8s-cluster-nf-keda-default-1574378163229'\n      command: 'ls'<\/code><\/pre>\n\n\n\n
We can now save our pipeline, and run it. <\/p>\n\n\n\n
\"\"
We can save our pipeline. Notice how I’m playing nicely and commiting to a branch.<\/figcaption><\/figure>\n\n\n\n
\"\"
Let’s run our pipeline for a first time.<\/figcaption><\/figure>\n\n\n\n
The pipeline should finish quickly, and actually return us the output from our helm ls command:<\/p>\n\n\n\n
\"\"
The output of helm ls, executed in our pipeline.<\/figcaption><\/figure>\n\n\n\n
This worked out pretty well. Let’s update our pipeline to include a couple extra steps:<\/p>\n\n\n\n