Getting started with CI\/CD pipelines and Kubernetes<\/h2>\n
We understand that one of the biggest blockers to adopting DevOps practices with containers and Kubernetes is setting up the required \u201cplumbing\u201d. We believe developers should be able to go from a Git repo to an app running inside Kubernetes in as few steps as possible. With Azure Pipelines, we aim at making this experience straightforward, automating the creation of the CI\/CD definitions, as well as the Kubernetes manifest.<\/p>\n
When you create a new pipeline, Azure DevOps automatically scans the Git repository and suggests recommended templates for container-based application. Using the templates, you have the option to automatically configure CI\/CD and deployments to Kubernetes.<\/p>\n
- \n
- Start by selecting your repository which has your application code and Dockerfile.
![\"Selecting](\"https:\/\/devblogs.microsoft.com\/devops\/wp-content\/uploads\/sites\/6\/2019\/05\/select-repo-1.png\")
<\/li>\n - Azure Pipelines analyzes the repository and suggests the right set of YAML templates, so you don\u2019t need to configure it manually.
\nFor example, here we\u2019ve identified that the repository has a Node.js application and a Dockerfile. Azure Pipelines then suggests multiple templates, including \u201cDocker image\u201d (for CI only: build the Docker image and push it to a registry), and \u201cDeploy to Azure Kubernetes Service\u201d (which includes both CI and CD).
\n![\"Selecting](\"https:\/\/devblogs.microsoft.com\/devops\/wp-content\/uploads\/sites\/6\/2019\/05\/configure.png\")
<\/li>\n - Once you select the AKS template, you will be asked for the names of the AKS cluster, container registry and namespace; these are the only inputs you need to provide. Azure Pipelines auto-fills the image name and service port.
\n![\"Kubernetes](\"https:\/\/devblogs.microsoft.com\/devops\/wp-content\/uploads\/sites\/6\/2019\/05\/deploy.png\")
<\/li>\n - The platform then auto-generates the YAML file for Azure Pipelines, and the Kubernetes manifest for deploying to the cluster. Both will be committed to your Git repository, so you get full configuration-as-code.
\n![\"Review](\"https:\/\/devblogs.microsoft.com\/devops\/wp-content\/uploads\/sites\/6\/2019\/05\/save-and-run.png\")
<\/li>\n<\/ol>\nThat\u2019s it! You\u2019ve configured a pipeline for an AKS cluster in four steps.<\/p>\n
Azure Pipelines offers then a set of rich views to monitor the progress and the pipeline execution summary.<\/p>\n
![\"Pipeline](\"https:\/\/devblogs.microsoft.com\/devops\/wp-content\/uploads\/sites\/6\/2019\/05\/setupci.png\")
<\/p>\nAzure Pipelines\u2019 getting started experience takes care of creating and configuring the pipeline without the user needing to know any of the Kubernetes concepts. Developers only need a code repo with a Dockerfile. Once the pipeline is set up you can modify its definition by using the new YAML editor, with support for IntelliSense smart code completion. You have full control, so you can add more steps like testing, or even bring in your Helm charts for deploying apps.<\/p>\n
As we are launching this new experience in preview, we are currently optimizing it for Azure Kubernetes Service (AKS) and Azure Container Registry (ACR). Other Kubernetes clusters, for example running on-premises or in other clouds, as well as other container registries, can be used, but require setting up a Service Account and connection manally. We are working on an improved UI to simplify adding other Kubernetes clusters and Docker registries in the next few months.<\/p>\n
Deploying to Kubernetes<\/h2>\n
Azure Pipelines customers have been able to deploy apps to Kubernetes clusters by using the built-in tasks for kubectl and Helm. It\u2019s also possible to run custom scripts to achieve the same results. While both those methods can be effective, they also come with some quirks that are necessary to make deployments work correctly. For example, when you are deploying a container image to Kubernetes, the image tag keeps changing with each pipeline run. Customers need to ensure they\u2019re using some tokenization to update their Helm chart or Kubernetes manifest files. Simply running the command could also result in scenarios where pipeline run was successful (because the command returned successfully), but the app deployment failed for other reasons, for example an imagePullSecret value not set. Solving these issues would require writing more scripts to check the state of deployments.<\/p>\n
To simplify this, we are introducing a new \u201cDeploy Kubernetes manifests<\/strong>\u201d task, available in preview. This task goes beyond just running commands, solving some of the problems that customers face when deploying to Kubernetes. It includes features such as deployment strategies, artifact substitution, metadata annotation, manifest stability check, and secret handling.<\/p>\n
When you use this task to deploy to a Kubernetes cluster, the task annotates the Kubernetes objects with CI\/CD metadata like the pipeline run ID. This helps with traceability: in case you want to know how and when a specific Kubernetes object was created, you can just look that up with the annotation details of the Kubernetes objects (like pod, deployment, etc).<\/p>\n
We have improved the Kubernetes service connection to cover all the different ways in which you can connect and deploy to a cluster. We understand that Kubernetes clusters are often used by multiple teams, deploying different microservices, and a key requirement is to give each team permission to a specific namespace.<\/p>\n
The new Kubernetes manifest task can be defined as YAML too, for example:<\/p>\n
steps:\n- task: \"KubernetesManifest@0\"\n displayName: \"Deploy\"\n inputs:\n kubernetesServiceConnection: \"someK8sSC1\"\n namespace: \"default\"\n manifests: \"manifests\/*\"\n containers: 'foobar\/demo:$(tagVariable)'\n imagePullSecrets: |\n some-secret\n some-other-secret\n<\/code><\/pre>\nNow you can connect to the Kubernetes cluster by using Service Account details or by passing on the kubeconfig file. Alternatively, for users of Azure Kubernetes Service, you can use the Azure subscription details to have Azure DevOps automatically create a Service Account scoped to a specific cluster and namespace.<\/p>\n
Hybrid and multi-cloud support<\/h2>\n
You can use our Kubernetes features irrespective of where your cluster is deployed to, including on-premises and on other cloud providers, enabling simple application portability. It also supports other Kubernetes-based distributions such as OpenShift. You can use Service Accounts to target any Kubernetes cluster, as described in the documentation<\/a>.<\/p>\n
Get started & feedback<\/h2>\n
This\u00a0feature will be rolled out\u00a0for\u00a0all accounts\u00a0over the next few days. To enable it, go to the\u00a0preview features page<\/a>\u00a0and turn on the toggle\u00a0for\u00a0“Multi-stage pipelines”.<\/p>\n
You can get started with Azure Pipelines<\/a> by creating a free account. Azure Pipelines, part of Azure DevOps, is free for individuals and small teams of up to five.<\/p>\n
Additionally, if you\u2019re looking for a way to get started quickly with Kubernetes, Azure Kubernetes Service provides a fully-managed Kubernetes cluster running on the cloud; try it out with a free Azure trial account<\/a>. After that, check out the full documentation<\/a> available on integrating Azure Pipelines with Kubernetes.<\/p>\n