Deploy multi-container app to Swarm cluster in Azure using VSTS

Background

This is the continuation of Continuous Deployment of Multi-Container app in Azure using VSTS and Docker. So far we have covered following topics

• Part 1 – Overview of different tools and technologies we will be using during this series
• Part 2 – Setup VSTS Continuous Integration (CI) build for DotNet Core 2.1 multi-container app
• Part 3 – Integrate DockerHub container registry with VSTS CI build to publish Docker images
• Part 4 – Provision Docker Swarm cluster in Azure using ACS Engine
• Part 5 – Create SSH Endpoint to Docker Swarm running in Azure
• Part 6 – Create Release Pipeline using VSTS for Multi-Container app

In this post we will look at running containers in Docker Swarm cluster by deploying the latest version of the code packaged as Docker image from DockerHub container registry. As part of this post we will be performing following steps

• Define Release variables for connecting to DockerHub account
• Add SSH tasks to login to DockerHub and to deploy the latest version using Docker CLI command to Docker Swarm manager
• Test release cycle

Define Release variables for connecting to DockerHub account

In part 6, we had published couple of shell scripts as part of build artifacts. We will use both those scripts in this post. The first script named dockerhub-login.sh is used to login to the DockerHub container registry. It uses the docker login command with username and password as parameters.

In order to make the script generic and to avoid hardcoding the credentials, I am taking in the username and password as parameters. We need to pass these parameters when we trigger the script as part of release task.

VSTS allows us to store build and release variables. I will add 3 Release variables for storing the username, password and the URL of the container registry as shown below

The variables are named docker.username, docker.password and docker.registry. Make sure to change the type of password from cleartext to password field to avoid leaking the password. The registry url is set to https://index.docker.io/v1/ 

Add SSH task to login to DockerHub

Edit the release definition and add a new SSH task. This task is required to trigger the login script shown above.

In the configurations for the task, select the SSH endpoint and select the Run type option as Script file. In the script file path choose dockerhub-login.sh file from the drop location. In the arguments section pass $(docker.username) and $(docker.password) as runtime arguments.

We can use inline scripts for quick testing. But going back to the DevOps best practices, we should keep everything in source control as much as possible. This approach also allows us to use different parameters based on environment and the script can be reused in multiple places. By using the SwarmSSH endpoint we ensure that the command will be executed on the Swarm master node.

Add SSH tasks to deploy the latest version using Docker CLI command to Docker Swarm cluster

Similar to the DockerHub login script, I have another script which will run the docker stack deploy command with the compose file which we copied to the deploy folder in part 6 of this series.

The script calls docker stack deploy command with –c parameter for compose file name which is docker-stack-swarm.yml in our case. We are also naming the stack as webapp.

We add another SSH task to execute this script.The settings are similar to earlier steps except for change in the script file name and arguments. Make sure to pick thee docker-deploy-stack.sh file. We do not need specify any arguments to this script.

Save all the changes to the release steps definition. With these two additions to the release tasks we are ready to test the full release end to end.

Test release cycle

Trigger a new release and deployment. Monitor the log to ensure that our changes are effective.

As we can see from the screenshot, the two newly added tasks have been completed successfully. We have two services named webapp_coremvc and webapp_corewebapi created as part of the stack deployment. Congratulations, with this we have successfully deployed the latest version of our code from DockerHub registry to Swarm cluster using VSTS.

Conclusion

In this post we saw how to use release variables to store DockerHub credentials. VSTS makes life easier by providing us multiple options to execute scripts by means of SSH tasks. The complete process of triggering the release and monitoring the live changes using logs is oversimplified due to various integration points. As demonstrated in this series so far it is very easy to setup CI CD pipeline using VSTS, Docker, DockerHub and Azure. We are still doing some manual steps in terms of creating a new release and deploying it to an environment. In the upcoming post we will see how this can be automated  and we can truly achieve CI CD right from checking in code in the IDE all the way till production. Until next time code with passion and strive for excellence.

Share: