MENU

[Azure] Continuous Integration / Continuous Deployment with Docker (ACS and ACR), Visual Studio Code, Visual Studio Team Services and GitHub

Posted by Florent Appointaire on March 20, 2017
Share on Facebook0Share on Google+0Share on LinkedIn12Share on Reddit2Tweet about this on Twitter0
5/5 (1)
5/51

docker with microsoft azure

A major force of infrastructure today is the possibility to use CI/CD. Understand, Continuous Integration and Continuous Deployment.

To resume, these technologies, give the possibility to your developers to create/modify their codes, send them to GitHub for example, build it with Visual Studio Team Services (VSTS), save it on you registry (Azure Container Registry for me), manage the versioning, always with VSTS, send it to your Docker Swarm cluster as container et to finish, access it through a simple web interface.

We will see how to implement this solution (the Microsoft documentation is available here). To start, you need to be sure to have the following requirements:

Before starting, you must deploy on your ACS, the VSTS agent.

You need a token to install this agent. Go in your VSTS > Your account > Security :

VSTS agent security

Click on Add to create a new token:

VSTS agent personal access token

Select Agent Pools (read, manage) for the permission and create the token:

VSTS agent personal agent tokens agent pools

Save the key that VSTS will generate because you’ll not be able to get it later. Connect to a server where Docker is available to install the VSTS Agent (you can deploy this agent on a Docker container). My server is on Ubuntu 16.04. In the VSTS interface, click on Settings > Agent queues > Download Agent and select your OS:

VSTS interface Settings Agent queues Download Agent

Download the agent from the server and execute the configuration command by replacing the URL of your VSTS. Provide the token that you created just before for the authentication:

VSTS token script

The agent is now configured. To start it, execute the script ./run.sh:

VSTS token script

To give the possibility to each component to speak each other’s, you need to install the Docker component on VSTS. It will allow the communication between your VSTS and your Docker environment. On the marketplace of Visual Studio ( https://marketplace.visualstudio.com/items?itemName=ms-vscs-rm.docker ) click on Install:

Visual studio marketplace Docker Integration

Choose on which VSTS account to install the Docker Integration component:

Docker Integration component

Docker Integration procced the account

To continue, get a GitHub token who has permissions repo, user, admin:repo_hook :

GitHub personal access tokens

The next step is to associate your VSTS and your GitHub account. Open the project and click on Settings > Services:

VSTS Settings Services

Here, click on New Service Endpoint > Github:

VSTS New Service Endpoint Github

In the new window, provide the token that you generate before and the name associated with this token:

Add new GitHub service connection

Visual Studio Team Services new service endpoint

It is necessary to register the Docker registry, by clicking on New Service Endpoint > Docker Registry:

Visual Studio Team Services new service endpoint docker registry

Provide information of your registry, that you can find on Azure, in the menu Container Registry > Access Key:

add new docker registry connection

Visual Studio Team Services new service endpoint details

To finish this part, you need to add a new service, SSH. Give a name, the URL to connect that you can find on Azure, in the Container Service part, the port (2200 by default), the username that you provide when you created the ACS and finally, the private key used during the installation of the ACS:

update authentification private key ssh

Visual Studio Team Services new service endpoint details

The configuration part is now finished. Move to the next. We will start by creating the base of the build. Navigate to VSTS, in Build & Release. Click on New > Empty:

Visual Studio Team Services create new build definition

Click on Github and select Continuous integration. Choose the type of the agent, Default:

Visual Studio Team Services github continuous integration

On your new definition, click on Repository and select the Github account that you configured before, thus the repository that you want to use for the CD:

Visual Studio Team Services definition new empty definition

On Triggers tab, select Continuous Integration. This will activate the trigger when you will do a commit on the application:

Visual Studio Team Services New empty definition Continuous integration

Click on Save:

Visual Studio Team Services new empty definition save

My application, that I want to deploy, contains one image, nginx. I’ll create 2 Docker steps, one to send the image to ACS and one on ACR. Click on Add build step… in Build:

Visual Studio Team Services definition add build step

Choose Docker and click on Add 2 times (for ACS and ACR):

Visual Studio task catalog build docker compose

For the first build, select the connection to your registry, the action Build an image, the path to your Dockerfile who is on Github, the path to sources and to finish, the name of your image, with the full path to your registry:

Visual Studio Team Services build an image

For the push part of your Registry, select the connection to your registry, the action Push an image and the name of your full image to your registry:

Visual Studio Team Services push an image

To finish, you need to add the following step, only if you have a docker-compose.yml file, for multi-tiers applications. Otherwise, go to the next step:

  • Command Line ()
    • Tool: bash
    • Arguments: -c “sed -i ‘s/BuildNumber/$(Build.BuildId)/g’ sources/docker-compose.yml”

And for everyone, you need to add the step for the publication of the artifact, with sources:

  • Publish Build Artifacts
    • Path to publish: sources
    • Artifact Name: FloAppWebsite2
    • Artifact Type: Server

Visual Studio Team Services publish artifact

Click on Save to save the configuration.

After that, create the new configuration for the release, to push the container on your ACS. In Releases, click on + then choose Empty and finally, click on Next:

Visual Studio Team Services Create release definition

Your release definition will look like this:

Visual Studio Team Services Create release definition build

We will now create the artifact. In your release, click on Artifacts > Link an artifact source and provide another name. Click on Link:

Visual Studio Team Services Link an artifact source

Move it as Primary:

Visual Studio Team Services Releases artifacts

Now, click on Triggers and check the box Continuous Deployment, then select the new artifact that you created previously:

Visual Studio Team Services Release definition release triggers

Save. Click on Add tasks in Environments in your new release, then add an SSH task with the following command and uncheck the case Fail on STDERR:

The command will connect to the registry, download the image and deploy it if it doesn’t exist, or replace it if existing, with the last published version:

Visual Studio Team Services release definition environments

You need to add 3 variables:

  • username: contains the username to connect to the registry
  • password: contains the password associated with the user to connect to the registry
  • registry: contains the URL to connect to the registry

Visual Studio Team Services Release definitions variable groups

Don’t forget to save 🙂

We can now test our configuration. To start, modify your source code, and send it to GitHub. After few seconds, on your VM where the VSTS agent is running, you can see this:

source code to GitHub

And from the VSTS console, I can see that the Build step has been completed correctly:

Visual Studio Team Services Build succeeded

Same as the release:

Visual Studio Team Services All release definitions summary

And if I try to access to the URL that redistributes to Docker agents, I have this:

URL redistributed to Docker agents

I’ll now modify my index.html file, and send it on Github. From the VSTS agent, you can see this:

index.html file VSTS agent view

And from VSTS console, a new build, 35 (versus 34 before), is available:

VSTS console new build

And the release:

VSTS console all definitions summary release

The view from my WebApp:

Azure web application view

And in the movie:

https://www.youtube.com/watch?v=3h0rXjt1emg

To conclude, this new method will delight your developers but also admins.

Developers because they will be autonomous, and will just have to push their code changes on a Git to be able to deploy it into production.

And from the admin side, finished the repetitive tasks that are not always the most interesting 🙂

Related materials:

Views All Time
4
Views Today
9

Please rate this

To download the software products, please, make your choice below. An installer link and a license key will be sent to the e-mail address you’ve specified. If you consider StarWind Virtual SAN but are uncertain of the version, please check the following document Free vs. Paid. The recent build of Release Notes. A totally unrestricted NFR (Not For Resale) version of StarWind Virtual SAN is available for certain use cases. Learn more details here.



Return to all posts

New Big Data Services for Azure in Europe: Data Lake Analytics and Data Lake Store
Installing System Center Configuration Manager 1610 (Current Branch) on Windows Server 2016 with SQL Server 2016. PART 2
The following two tabs change content below.
Florent Appointaire
Florent Appointaire is Microsoft Engineer with 5 years of experience, specialized in Cloud Technologies (Public/Hybrid/Private). He is a freelance consultant in Belgium from the beginning of 2017. He is MVP Cloud and Datacentre Management. He is MCSE Private Cloud and Hyper-V certified. His favorite products are SCVMM, SCOM, Windows Azure pack/Azure Stack and Microsoft Azure.