Containers on Azure as part of a CI/CD pipeline

In my previous posts I was speaking about the journey to go from setting up a container and ultimately publishing it in a continuous fashion to a registry using VSTS.

You may have noticed that a lot of time has elapsed since my last post, and there are a couple of reasons for that.

First of all, the impediment of work, secondly, I noticed a trend where it became fairly popular to blog about the journey from where I ended off and I hung back and followed those for a while.

Instead of me going ahead and creating a bunch of posts to show how to publish your container and run it in production, I’m going to hand it off to a bunch of other capable people :-)

To delve deeper, or just for more information, these are all good reads:

• Windows finally came to the party with Windows based containers
• Introduction to Azure Container Service for Kubernetes
• Walk through on managing a Kubernetes container service on Azure
• Webcasts giving a good overview of the DevOps processes around leveraging containers
• Create a CI/CD pipeline for containerized ASP.NET Core projects
• Setting up CI/CD for Docker Container Running in Kubernetes using VSTS
• Running Web API using Docker and Kubernetes
• Team Yoman generator by Donovan Brown, that will create most of the infrastructure for you
• Continuous Deployment, Kubernetes to Azure Container Service

And if you are interested in a brief discussion on how to move to a microservices based architecture this is a good read : Modernizing a Monolithic Application using Microservices and Azure

 

Deploy Docker images to a Private Azure Container Registry

This post continues the journey of creating a dotnet application, containerizing and ultimately deploying the image to production.

The first thing we need to do is to get the source into a source repository (I’m of course going to use VSTS), then we need to configure a build and then push the images to a registry. We will then be able to deploy the images from the registry to our hosts, but more on that later.
Note: Some of these steps may incur some cost, so I would highly recommend at the very least creating a Dev Essentials account. This should cover any costs while we are playing.

I’m assuming you have already pushed your code to a repository in VSTS, so the next step is to create an Azure account, if you have not got one already, and then to setup a container registry.

To create your own private azure container registry to publish the images to:

1. Login to azure
2. Select container registries
    
3. This should give you a list and you will need to click “add” to create a new container registry
4. Fill in the required details and create a new registry
5. Once created, open up the blade and select the Access Key settings. This should contain the registry name, login server and user name and password details (make sure the “Admin User” is enabled)
   

Now lets move on to VSTS.
First we need to “connect” VSTS and your container registry:

1. Login to your VSTS project and under settings, select the services configuration:
   
2. Using the details that were in the Access Key settings on the Azure container registry blade, create a docker registry service with your “Login Server” as the docker registry url and the user name and password:
   

Finally it is time to create the builds. As you would expect, go add a new “empty” build definition that links to your source repository. Instead of selecting the “Hosted” build queue, use the “Hosted Linux Preview” queue. Docker is not available on the normal hosted windows agents yet.
Add 2 command line tasks and 3 docker tasks:


Note: If you do not have the docker tasks, then you will need to go and install them from the market place
Now configure the tasks as follows:

Command Line 1	Tool: dotnet Arguments: restore Advanced/Working Folder : The folder that your source is located in. In my case it was $(build.sourcesdirectory)/dotnet_sample/
Command Line 2	Tool: dotnet Arguments : publish -c release -o $(build.sourcesdirectory)/dotnet_sample/output/ or an "output" folder under your source location Advanced/Working Folder : see above
Docker 1	Docker Registry Connection : the service connection that you created earlier Action : Build an image Docker File : The location of your docker file. In my case it was $(build.sourcesdirectory)/dotnet_sample/dockerfile Build Context: The location of your source code. In my case $(build.sourcesdirectory)/dotnet_sample Image Name: The name and tag that you want to give your image. In my case I just used dotnet_sample:$(Build.BuildId) Advanced/Working Folder : same as the other working folders
Docker 2	Docker Registry Connection : the service connection that you created earlier Action : Run a Docker Command Command : tag dotnet_sample:$(Build.BuildId) $(DockerRegistryUrl)/sample/dotnet_sample:$(Build.BuildId) the name must be the same as in the task above, and the $(DockerRegistryUrl) must be your Azure container registry url or login server Advanced/Working Folder : same as the other working folders
Docker 3	Docker Registry Connection : the service connection that you created earlier Action : Push an image Image Name : The name you passed in when tagging your container above. In my case it was $(DockerRegistryUrl)/sample/dotnet_sample:$(Build.BuildId) Advanced/Working Folder : same as the other working folders

Now you can save and queue the build. Hopefully it will look something like this:


If all has passed, a quick and easy way to see if your image is in your registry is to navigate to your docker registry’s catalogue url : “https://<<registry_url>>/v2/_catalog”. This will likely prompt you to login with the username and password that you setup previously and then you will download a json file. Opening this file will provide you with all the images hosted in your registry.

In this post we have moved from a locally created image to one residing in our private registry. In the next post we will continue the journey a bit further…

Windows joining in the containerization fun

So in the previous posts getting started, creating an application and configuring the container we saw how to install docker, create a sample application and deploy it and run it in a docker container.

Thus far the containers where a Linux flavor and believe it or not, we were running a dotnet application on it.

With Windows 10 (1511 November update or later) and  Windows Server 2016  and Docker Beta 26 or newer, it is possible to create windows containers.

In your system try right click on the docker icon and then select “Switch to Windows Containers”

Wait for it to complete.

Once it was switched over, then go back to the application that we created in <<link>> and edit the dockerfile.

Change the first line from FROM microsoft/dotnet to FROM microsoft/dotnet:nanoserver

Then, as before, run the following commands:

docker build . -t dotnet_sample --rm
docker run dotnet_sample –p 80:5000 

The simply navigate to http://localhost/ and voila!! you are not running your same application in a windows based container!

If you are skeptical about what platforms etc. you are running on, download this sample and edit the dockerfile and go to the “Docker” tab

 

As much fun as this is, the goal behind using containers is not to simply play with it on your machine. We want to automate the creation and deployment of the containers.

Next up I will show you how to automatically use VSTS to build and deploy to an Azure  Container host.