Implement continuous deployment of your app using Kubernetes to Azure Container Service

Last Update: 6/29/2017

| Team Services |

Continuous deployment (CD) means starting an automated deployment process whenever a new successful build is available. Here. we'll show you how to set up continuous delivery of a Docker based app by using Visual Studio Team Services to a Kubernetes cluster running in Azure Container Service.

Azure Container Service (ACS) allows to deploy and manage containers using Kubernetes, Docker Swarm, Mesosphere DC/OS orchestrators. You can deploy these three orchestrators on Azure by using the portal, an Azure Resource Manager template, or the Azure CLI.

The Azure Container Registry (ACR) is an implementation of the open source Docker Registry. ACR is now available as an Azure Service and is fully compatible with all three orchestrators. ACR is used as a private registry to store Docker images for enterprise applications, instead of needing to use the public Docker Hub.

Get set up

Begin with a CI build

Before you begin, you'll need a CI build that publishes your app. To set up CI for your specific type of app, see:

Modify your build to create a Docker container

Next, you'll need to modify your build definition to create a Docker container for deployment using ACS.

  1. Add two instances of the Docker task to the end of your build definition.

  2. Add one instance of the Publish Build Artifacts task to the end of your build definition.

  3. Configure the tasks as follows:

    Build: Docker
    Build: Docker Build the container image from the Docker file.

    • Container Registry type: Azure Container Registry

    • Azure Subscription: Select a connection from the list under Available Azure Service Connections or create a more restricted permissions connection to your Azure subscription. For more details, see Azure Resource Manager service endpoint.

    • Azure Container Registry: Select the target Azure container registry.

    • Action: Build an image

    • Image name: Enter the name for your Docker image.

    • Qualify Image Name: Checked

    • Additional Image Tags: $(Build.BuildId)

    Build: Docker
    Build: Docker Push the container image to a container registry.

    • Container Registry type: Azure Container Registry

    • Azure Subscription: Select a connection from the list under Available Azure Service Connections or create a more restricted permissions connection to your Azure subscription. For more details, see Azure Resource Manager service endpoint.

    • Azure Container Registry: Select the target Azure container registry.

    • Action: Push an image

    • Image name: Enter the name of your Docker image.

    • Qualify Image Name: Checked

    • Additional Image Tags: $(Build.BuildId)

    Build: Publish Build Artifacts Build: Publish Build Artifacts - Publish the Kubernetes configuration files used for creating the deployment and service in the cluster. These files are added to the repository.

    • Path to Publish: k8config

    • Artifact name: yaml

    • Artifact Type: Server

  4. Save your build definition.

Define and test your CD release process

Continuous deployment (CD) means starting an automated release process whenever a new successful build is available. Your CD release process picks up the artifacts published by your CI build and then deploys them.

  1. Open the Releases tab of the Build & Release hub, open the + drop-down in the list of release definitions, and choose Create release definition

  2. Select the Deploy to Kubernetes cluster template and choose Next.

  3. In the Artifacts section, make sure your CI build definition for the Docker package is selected as the artifact source.

  4. Select the Continuous deployment check box, and then choose Create.

  5. Add two more instances of the Deploy to Kubernetes task to your release definition. This task uses the kubectl command to execute operations on a Kubernetes cluster.

  6. Configure the tasks as follows:

    Deploy: Deploy to Kubernetes Deploy: Deploy to Kubernetes - Create the deployment and secret.

    • Container Registry type: Azure Container registry

    • Azure Subscription: Select a connection from the list under Available Azure Service Connections or create a more restricted permissions connection to your Azure subscription. For more details, see Azure Resource Manager service endpoint.

    • Azure Container registry: Select the Azure container registry to which you pushed your container images.

    • Secret name: Name of the Docker registry secret. You can use this secret name in the Kubernetes YAML configuration file.

    • Command: apply (you can run any kubectl command)

    • Use Configuration file: Checked

    • Configuration file: Select the deployment.yaml file that was published as an artifact from the build. Example: $(System.DefaultWorkingDirectory)/Kubernetes-ACS-CI/yaml/deployment.yaml

    Deploy: Deploy to Kubernetes Deploy: Deploy to Kubernetes - Create the service using the yaml file.

    • Container Registry type: Azure Container registry

    • Azure Subscription: Select a connection from the list under Available Azure Service Connections or create a more restricted permissions connection to your Azure subscription. For more details, see Azure Resource Manager service endpoint.

    • Azure Container registry: Select the Azure container registry to which you pushed your container images.

    • Secret name: Name of the Docker registry secret. You can use this secret name in the Kubernetes YAML configuration file.

    • Command: apply

    • Use Configuration file: Checked

    • Configuration file: Select the service.yaml file that was published as an artifact from the build. Example: $(System.DefaultWorkingDirectory)/Kubernetes-ACS-CI/yaml/service.yaml

    Deploy: Deploy to Kubernetes Deploy: Deploy to Kubernetes
    Update with the latest image.

    • Container Registry type: Azure Container registry

    • Azure Subscription: Select a connection from the list under Available Azure Service Connections or create a more restricted permissions connection to your Azure subscription. For more details, see Azure Resource Manager service endpoint.

    • Azure Container registry: Select the Azure container registry to which you pushed your container images.

    • Secret name: Name of the Docker registry secret. You can use this secret name in the Kubernetes YAML configuration file.

    • Command: set

    • Arguments: Arguments to pass to teh command. For example, image deployment/coreserverdeployment core-server=image:tag where you are using a private registry (so the image name must be prefixed with the container registry name). We also use the Build Id to tag our images here, so the image:tag value will be {your-acr-name}.azurecr.io/docker-dotnetcore:$(Build.BuildId). docker-dotnetcore is the image name used in the build.

  7. Edit the name of the release definition, choose Save, and choose OK. Note that the default environment is named Environment1, which you can edit by clicking directly on the name.

You're now ready to create a release, which means to start the process of running the release definition with the artifacts produced by a specific build. This will result in deploying the build to Azure:

  1. Choose + Release and select Create Release.

  2. Select the build you just completed in the highlighted drop-down list and choose Create.

  3. Choose the release link in the popup message. For example: "Release Release-1 has been created".

  4. Open the Logs tab to watch the release console output.

Q&A

Why use the Build ID as the tag when deploying?

In this example, we used the kubectl set image command with the Build ID as the tag. Using the Build ID as the tag has an added advantage of traceability. Avoid using the latest tag with the container image. An alternate approach is to modify the YAML file with the Build ID used to tag the image.

How do I define separate environments for my release?

The Kubernetes namespace allows complete separation of resources and management within the same cluster. So namespace can be used to create multiple environments such as Dev, QA, and Production in the same ACS Kubernetes cluster.

I use Team Foundation Server on-premises and I don't see some of these features. Why not?

Some of these features are available only on Visual Studio Team Services and not yet available on-premises. Some features are available on-premises if you have upgraded to the latest version of TFS.

Help and support