Continuous Deployment of Multi-Container app in Azure using VSTS and Docker : Part I

In an earlier post, I demonstrated how to upgrade .Net Core Docker image to an Alpine based Linux distribution. Before upgrading the Docker image, I had set up the CI CD pipeline which was deploying the multi-container apps to the Docker Swarm cluster hosted in Azure and provisioned using Azure Container Service (ACS). I updated the CI CD pipeline to reflect the changes done during the upgrade and was able to run the .Net Core 2.1 based Docker images. This is the first post of the journey of the containers running on my local laptop to Swarm cluster using an automated continuous build and deployment process.

I intend to cover the different steps in a series  of posts which will include

• Setting up VSTS continuous build
• Integration with different services like GitHub, Azure Resource Manager, DockerHub, SSH endpoints
• Setup Continuous Integration build pipeline to publish images to DockerHub
• Provision Docker Swarm cluster in Azure using Azure Container Service (ACS) Engine
• Setup Continuous Deployment pipeline to deploy multi-container app to Docker Swarm cluster

Pre-requisites

In order to perform all the above mentioned steps there are some pre-requisites.

1 - VSTS account

Visual Studio Team Services provides a complete solution for managing the Application Lifecycle management for various kinds of application. It is free up to 5 users. It has all the features required to start your DevOps journey. In an enterprise scenario, we can use it for requirement management, building dashboards, manage Sprints etc. for end to end delivery process. For the purpose of this blog post series, we will be using it purely as build and release management tool. We will configure the automated build and release pipeline using VSTS. If you don’t have a VSTS account you can create one for free.

2 - Source code in GitHub repo

VSTS has its own Git repository. This can be used if we do not have existing source code in some other version control system. I already have the source code hosted on Github. VSTS supports integration with existing Github repositories. We will be using this approach to connect VSTS to the DotNet-2017 repository. Every time there is a checkin a continuous integration build will trigger and produce the two docker images.

3 - DockerHub account

The images created during CI build will be pushed to the DockerHub repository. If you do not have dockerhub account you can create one. I am using DockerHub since I already have these images published there. If you prefer you can chose other container registry like Azure Container Registry. Only prerequisite is that we should be able to push the images to this registry during the build phase. VSTS provides integration with DockerHub out of the box.

If you decide to use other registry and there is no integration with VSTS, we should at least be able to push docker images to it using the CLI. That would enable us to write a bash or windows script to trigger the commands using scripting task.

4 - Azure Subscription to create Docker Swarm cluster

Finally we need Azure Subscription which will allow us to provision the Docker Swarm cluster. As I had mentioned during the post on Visualizing Docker Swarm using Portainer And Swarm Visualizer, there is a limitation with the Azure Container Service. It runs the Swarm cluster in legecy mode. To overcome this limitation, we will be using the ARM template for ACS Engine – Swarm Mode.

At the end of this series we will have the fully automated build and release pipeline for .Net Core Multi-Container app running inside docker containers in Azure. The whole process described below takes away the mundane and repetitive task of running various commands on terminal and automates them as much as possible. We would still need to write those commands. But they will be part of source control in script files. The automated build process will use the script files to execute the commands. This is important from DevOps point of view where we have a repeatable process which can be used by anybody in the team working on the project. By using such technique we follow the infrastructure as code principle which ensures that there are no manual steps required during the build and deployment process.

I am using Visual Studio code as my code editor but you can use anything that suits your needs. I am in love with VS Code since I started coding with it. If you have not tried it I can say you are missing something. The other steps in the above picture are self explanatory with regards to CI and CD phases. I hope you will enjoy this journey with me.

Given the popularity of Kubernetes and recent announcements by Microsoft that Azure Container Service (AKS) will support managed Kubernetes cluster, I would like to migrate to Kubernetes at some point in future. Other option I am also exploring is to create an additional step in the deployment phase which will deploy the application to Kubernetes cluster in parallel with Docker Swarm. This would require some additional resources in Azure.

Let me know via comments if you have any suggestion or feedback for the upcoming posts. Until next time code with passion and strive for excellence.

Share: