Azure DevOps – Agent Azure Pipelines privatif dans un container Docker

Azure DevOps – Agent Azure Pipelines privatif dans un container Docker

Ce tutoriel décrit l’installation d’un agent Azure Pipelines dans un container Docker, afin de générer, publier et tester votre code, de manière indépendante et privative.

Prérequis

Afin de suivre correctement ce tutoriel, il est important d’avoir des notions de base sur :

  • L’IDE Visual Studio
  • La plateforme Azure DevOps
  • Docker (descente d’image, déploiement de container)
  • Administration simple de Linux (ici CentOS)

Présentation

L’agent Azure Pipelines permet de déporter la génération de son code au travers d’un job, effectuant le même travail qu’une génération dans Visual Studio, mais tout en respectant une une configuration, afin de garantir un résultat attendu.

Initialement, cet agent était disponible dans Team Foundation Server (TFS) et était connu sous le nom d’Agent TFS. Installé dans une infrastructure, il permettait d’être intégré à un worflow de type intégration continue, pour générer les projets de code désirés.

Depuis maintenant quelques années, Microsoft intègre TFS dans des services en ligne appelés Visual Studio Team Services (VSTS) puis Azure DevOps depuis fin 2018. L’ouverture de ces services de manière libre et gratuite aux développeurs, permet d’utiliser une plateforme puissante et novatrice en terme de gestion de projet, versionning de code, suivi de build, déploiement d’artefacts, etc…

Le tutoriel porte sur la brique Azure Pipelines

Certaines formules payantes existent dans Azure DevOps mais ne sont pas nécessaire dans un usage en tant que freelance à mon sens, et ne sont pas un prérequis pour le tutoriel ci-après.

Le but de ce tutoriel est donc de se familiariser avec la plateforme Azure DevOps, en particularité pour la gestion de build via Azure Pipelines.

Agent déporté, mais pour quoi faire ?

Confier la génération d’un projet de code à un agent a plusieurs utilités. Ne pas s’embêter à générer soit-même son code depuis son instance Visual Studio, apporter un automatisme post-build pour déposer les binaires dans un dépot spécifique, permettre a des personnes identifiées dans l’entreprise de déclencher des builds également, planifier des build en heures creuses, ….

Vous l’aurez compris, l’utilisation d’un agent Azure Pipelines apporte son lot fonctionnalité pour une équipe de développement et impose également une rigueur.

Avantages et inconvénients

Une telle solution apporte son lot d’avantages et inconvénients, et il est important de peser le pour et le contre.

Avantages

  • Agent privé disponible dans l’infrastructure propre de l’utilisateur (infra interne d’une entreprise ou vlan dédié par exemple)
  • Pas besoin de serveur TFS privé. On passe par Azure DevOps
  • Rapidité de mise en place à la demande via Docker (environ 2min)
  • Solution économique

Inconvénients

  • Image Docker importante (+10Go)
  • Nécessité de mise à jour de l’image (et du conteneur) au fil des releases MS
  • Nécessité d’être interconnecté avec l’infra pour la partie déploiement

Petites précisions : côté avantage un agent privatif apporte confidentialité et sécurité mais dans notre cas, le code (pour la partie versionning) reste hébergé sur Azure DevOps. Une confidentialité totale nécessite d’héberger soit même un serveur TFS. Côté inconvénients, la mise à jour des images et containers n’en est pas vraiment un, la manipulation est rapide avec Docker mais apporte un temps restreint d’interruption de service.

Installation et configuration

Pour déployer l’agent sur une instance Docker, il convient tout d’abord d’aller voir la page de définition de l’image sur le Hub Docker.

VSTS account & Personnal Access Token (PAT)

Un premier coup d’œil aux variables d’environnement vous indique la nécessité de posséder un compte Azure DevOps (encore appelé VSTS ici) et un token PAT.

docker run \
  -e VSTS_ACCOUNT=<name> \
  -e VSTS_TOKEN=<pat> \
  -d --name agent_azure_pipelines mcr.microsoft.com/azure-pipelines/vsts-agent

La valeur de la variable d’environnement ‘VSTS_ACCOUNT’ correspond au nom de votre espace Azure DevOps, pour ma part il s’agit de ktchup.

Le token d’accès personnel (PAT) s’obtient sur la plateforme également au niveau de votre profil. Je vous invite à suivre la doc Microsoft pour l’obtenir.

Utilisation avec TFS

Dans le cas où vous utilisez votre propre serveur TFS plutôt que Azure DevOps, il suffit d’utiliser les variables d’environnement prévues à cet effet. Attention, une variante de l’image est nécessaire d’où l’utilisation ici du tag ubuntu-16.04-tfs-2018 pour l’image Docker.

docker run \
  -e TFS_HOST=mytfs \
  -e VSTS_TOKEN=<pat> \
  -d mcr.microsoft.com/azure-pipelines/vsts-agent:ubuntu-16.04-tfs-2018

Une image, 37 variantes possibles

Dans le premier exemple d’utilisation de l’image, aucun tag n’est indiqué, la logique Docker veut donc que l’image taguée latest soit utilisée. Elle vous sera sûrement bien utile mais couvrira-t-elle tout vos besoins ? Pas sûr.

Les tags se décomposent ainsi:

  • OS : ubuntu 16.04 ou 14.04
  • Pack d’outils standard ou non
  • Prise en compte de docker dans docker ou non
    • si oui, docker 18.06 ou 17.12
  • tfs ou non
    • tfs 2018 u2 ou u3

Dans mon cas, je suis régulièrement amené à créer des images Docker de mes builds pour les publier ensuite dans un registre privé. De plus j’ai besoin des outils MSSQL de l’image standard. L’image taguée ubuntu-16.04-docker-18.06.1-ce-standard me sera donc nécessaire.

Pour cette image implémentant Docker, on parle alors de Docker dans Docker et un commutateur de volume est obligatoire pour que le container exposant l’image, communique avec mon Docker hôte.

docker run \
  --name vsts-agent \
  -e VSTS_ACCOUNT=<compte> \
  -e VSTS_TOKEN=<pat> \
  -e VSTS_AGENT='AGENT007' \
  -e VSTS_POOL='Private'\
  -e VSTS_WORK='/var/vsts/$VSTS_AGENT' \
  -v /data/vsts:/var/vsts \
  -v /var/run/docker.sock:/var/run/docker.sock \
  --name azure-pipelines-agent007 \
  -d mcr.microsoft.com/azure-pipelines/vsts-agent:ubuntu-16.04-docker-18.06.1-ce-standard

Dans cette instruction, j’utilise la variante de l’image décrite ci-avant, je spécifie le compte VSTS, le token PAT, je nomme l’agent AGENT007 que je classe dans le pool nommé Private et enfin je bind les volumes en conséquence. Attention, le pool Private a été créé au préalable. Si vous ne l’indiquez pas, l’agent sera simplement associé au pool Default.

On vérifie dans les logs du container Docker le bon lancement de l’agent par la commande :

docker logs azure-pipelines-agent007

On constate que l’agent fonctionne correctement est qu’il attends qu’un job soit en file d’attente. Une seconde vérification dans Azure DevOps me confirme la bonne prise en compte.

Le pool créé
Preuve que l’agent est créé et actif

L’agent est désormais prêt à être utilisé dans un job de build au travers de la solution Azure DevOps. Celui-ci est autonome et privé, et permet désormais de générer et déployer vos solutions applicatives sur votre propre infrastructure.

Laisser un commentaire