[Update 04/02/2022]: Helm Repository Migration
The Helm Repository has been moved on 04/02/2022 to a new URL, visit the dedicated page for further details (Helm Repository).
In this article we will briefly explain which is the standard approach for installing Azure DevOps Agents, and which is our containerized solution for Kubernetes.
Azure DevOps (also known over the years as ALM or TFS) is a popular tool from Microsoft to manage Pipeline in CI/CD, in line with the DevOps culture (as the name suggests).
In all the CI/CD tools there is the concept of “Agent” (or “Runner”, or other depending on the tool used) which consists of the service, or the pool of services, which takes over the actual work of execution of the various tasks of our Pipeline.
On Azure DevOps, these services that have the role of mere executor, are logically grouped into 2 different entities named:
- Agent Pools: more transversal to different projects.
- Deployment Groups: linked to the project where they are created, and therefore not usable in others.
For other differences regarding these 2 types of grouping, I invite you to read the official documentation; regarding the agent instead, both of these 2 types are essentially based on the same application which will then be registered in 2 different ways depending on whether it must become part of an Agent Pool or a Deployment Group.
Once an Agent Pool or a Deployment Group has been defined, Azure DevOps automatically generates/provides us with the scripts in Powershell and Bash (therefore both Windows and Linux) to install and register the individual Agents of the chosen Pool/Group. Therefore, except for some initial registration parameter, the creation of the latter is quite easy; but confined to Virtual Machines.
What if we want to containerize our Agents instead?
Currently Azure DevOps does not provide an official Docker Container for their agents; and, now that we are in the middle of the Kubernetes era to orchestrate all our applications in the cloud, why not do the same with our Azure DevOps agents too?
In order to achieve this goal, we have built and published (respectively in our official Docker Registry and Helm Repository) 2 Docker Images and 2 Helm Charts that we are going to describe below:
Containerized Agents
azuredevops-agent
Docker image of the Azure DevOps Agent with “Agent Pool” registration.
Here below how to download and configure the version 1.1.0; instead, for the documentation and other versions, go here.
docker pull registry.gitlab.com/nevertheless.space/docker-registry/azuredevops-agent:1.1.0
Variabili di Ambiente
AZP_URL: Azure DevOps - URLAZP_TOKEN: Azure DevOps - Personal Access Token (PAT)AZP_AGENT_NAME: Azure DevOps - Agent Registration NameAZP_POOL: Azure DevOps - Name of the Agent Pool
azuredevops-deploymentgroup
Docker image of the Azure DevOps Agent with “Deployment Group” registration.
Here below how to download and configure the version 1.1.0; instead, for the documentation and other versions, go here.
docker pull registry.gitlab.com/nevertheless.space/docker-registry/azuredevops-deploymentgroup:1.1.0
Variabili di Ambiente
AZP_URL: Azure DevOps - URLAZP_TOKEN: Azure DevOps - Personal Access Token (PAT)AZP_AGENT_NAME: Azure DevOps - Agent Registration NameAZP_COLL_NAME: Azure DevOps - Name of the Deployment Group CollectionAZP_PRJ_NAME: Azure DevOps - Name of the Deployment Group ProjectAZP_DG_NAME: Azure DevOps - Name of the Deployment GroupAZP_DG_TAGS: Azure DevOps - Tags to associate with the agent- For example:
"tag1, tag2, tag3"
- For example:
Helm Charts
To facilitate the deployment in Kubernetes, Helm Charts have also been produced, which, starting from version 1.2.0, meet the needs of being able to:
- deploy our agents both as Deployments (Stateless) and as Stateful Set with its own dedicated disk; this will be possible by appropriately setting the
statefulSet.*variables of the Helm Chart. - schedule our pods only on specific nodes, and we can do it by appropriately setting the
nodeSelector.*variables of the Helm Chart. - define the number of agents to create, appropriately setting the Helm Chart
replicaCountvariable or scaling from Kubernetes. - set resource limits to our pods by appropriately setting the
limits.*variables of the Helm Chart.
Helm Repository initialization
To use our Chart Helm you need to connect to our Helm Repository:
helm repo add nevertheless.space https://helm.nevertheless.space
helm repo update
azuredevops-agent
Helm Chart of the Azure DevOps Agent with “Agent Pool” registration.
Below is shown how to install and configure version 1.2.0; for other versions instead, go here.
helm install -f values.yaml --namespace="<namespace_name>" --create-namespace "<my_release_name>" nevertheless.space/azuredevops-agent:1.2.0
Example of Values.yaml
# Chart: nevertheless.space/azuredevops-agent:1.2.0 - values.yaml
replicaCount: 1
azureDevOps:
url: "https://myazuredevops.com/tfs"
pool: "Agent-Pool-1"
pat: "XXXXXXXXXXXXXXXXXXXXX"
workingDir: "_work"
statefulSet:
enabled: false
storageClassName: "default"
storageSize: "20Gi"
limits:
enabled: false
requestedMemory: "128Mi"
requestedCPU: "250m"
memoryLimit: "1Gi"
CPULimit: "1"
nodeSelector:
enabled: false
key: "Kubernetes.io/hostname"
value: "eu-central-1.10.11.10.2"
azuredevops-deploymentgroup
Helm Chart of the Azure DevOps Agent with “Deployment Group” registration.
Below is shown how to install and configure version 1.2.0; for other versions instead, go here.
helm install -f values.yaml --namespace="<namespace_name>" --create-namespace "<my_release_name>" nevertheless.space/azuredevops-deploymentgroup:1.2.0
Example of Values.yaml
# Chart: nevertheless.space/azuredevops-deploymentgroup:1.2.0 - values.yaml
replicaCount: 1
azureDevOps:
url: "https://myazuredevops.com/tfs"
project: "Project 1"
collection: "Collection 2"
deploymentGroup: "Kubernetes-Agents"
pat: "XXXXXXXXXXXXXXXXXXXXX"
tags: "k8s, linux"
workingDir: "_work"
statefulSet:
enabled: false
storageClassName: "default"
storageSize: "20Gi"
limits:
enabled: false
requestedMemory: "128Mi"
requestedCPU: "250m"
memoryLimit: "1Gi"
CPULimit: "1"
nodeSelector:
enabled: false
key: "Kubernetes.io/hostname"
value: "eu-central-1.10.11.10.2"
Conclusion
In the Gitlab projects of our Docker Registry and Helm Repository you can find the source code and the various documentation, as well as contribute with reports or Merge Requests.