L'année dernière, j'ai rédigé une petite série d'articles de blog au sujet de l'utilisation d'Azure Container Instances pour obtenir un agent Azure Pipelines en quelques minutes (ici, ici et ici). A cette occasion, j'ai reçu une excellente question en commentaire qui m'a fait avouer que mon environnement de build favori reste indéniablement mon propre agent de build self-hosted dans une VM Azure.

Dans cet article, j'aimerais expliquer quels sont les avantages que je vois dans cette solution, et aussi comment la mettre en place en quelques minutes via la ligne de commande docker-machine

Agent self-hosted vs agent hébergé par Microsoft

tl;dr: Avec un agent self-hosted, vous obteniez un système de build plus rapide et plus facile à déboguer.

1. Lorsque mes collègues me disent "Ma build prend trop de temps, comment est-ce que je peux la rendre plus rapide ?", très souvent ma première réaction est "Et si tu mettais en place ta propre machine de build ?". La différence de rapidité peut s'expliquer de manière très simple : les agents hébergés par Microsoft sont créés et détruits à chaque build, ce qui signifie qu'on ne bénéficie pas forcément du cache standard de nombreux systèmes (bien que la récente fonctionnalité de Pipelines caching peut y aider, même dans des scénarios avec Docker).
   Avec votre propre machine de build, vous pouvez accélérer :

   • La récupération du code source: au lieu de refaire un gros git clone, un simple git pull sera effectué, comme n'importe quel développeur l'aurait fait.
   • Le temps de compilation: au lieu de faire un Rebuild de chaque projet, un simple Build sera effectué sur les projets modifiés et les projets dépendants de ceux-ci.
   • Le temps de récupération des packages: au lieu de tous les télécharger à chaque fois, le pipeline pourra se baser en premier lieu sur le cache de package global de la machine de build (ce qui permet de juste copier les packages au lieu de les télécharger), mais aussi de réutiliser les packages déjà présents depuis la dernière build, avec un simple ajout/mise à jour des nouveaux packages modifiés.
   • Le temps de build docker: la génération d'images docker peut s'appuyer sur le cache des images, ainsi que sur le cache des étapes de build docker (expliqué brièvement dans l'article Docker : Optimisation d'une SPA React aspnetcore avec Visual Studio)

2. "La build a pété ! Est-ce que l'on peut avoir un expert ALM/DevOps pour la réparer ?". J'ai pas mal entendu cette phrase par le passé. Pour moi, la machine de build reste un moyen d'automatiser des tâches qui sont habituellement effectuées par les développeurs manuellement. Et du coup, je m'attends à ce que la machine de build soit identique à un poste de développeur avec les mêmes outils, IDE, dépendances, etc. installées. Ainsi, si la build échoue, il suffit pour la réparer de se connecter à la machine de build, exécuter Visual Studio ou la ligne de commande exécutée pendant la build, et déboguer. Au final avoir accès à une machine de build similaire à un poste de développeur peut rendre la build plus facile à fixer.

3. Le dernier point moins important, et très dépendant de votre organisation : comme souvent les agents hébergés par Microsoft sont un peu le choix "par défaut" de chaque nouvelle pipeline, les files d'attente qui leur sont associées sont souvent très occupées, et il faut attendre que plusieurs pipelines se terminent avant d'y avoir enfin accès...
   Donc si vous avez la chance d'avoir à votre disposition quelques pipelines (en ayant accès à quelques licences Visual Studio Enterprise, en ajoutant une pipeline self-hosted par licence, ou en en achetant pour 12,65€ la pipeline), configurer votre propre agent self-hosted vous permet d'avoir accès à votre propre pool d'agent, et donc votre propre agent queue indépendante, et ainsi arrêter de devoir attendre que vos pipelines exécutées sur des agents hébergés par Microsoft se terminent.

Note : Ne vous méprenez pas, je trouve toujours les agents hébergés par Microsoft plus adaptés pour démarrer, ainsi que pour les builds pour lesquels la durée d'exécution n'est pas trop un souci. Je considère presque que construire sa propre machine de build est un scénario avancé, et si vous n'êtes pas trop familier avec tout ça, je vous recommande de rester sur les agents hébergés par Microsoft, qui restent très pratiques.

Convaincu ? Voyons maintenant ensemble comment construire votre machine de build Docker en quelques minutes !

Comment construire une machine de build Docker en quelques minutes

Il y a 2 ans, j'avais écrit un article de blog au sujet de la création d'une machine de build Docker dans Azure. Mais il se trouve que depuis, j'ai trouvé un autre moyen plus simple et plus rapide de faire la même chose en utilisant la ligne de commande docker-machine

Attention : plus simple et plus rapide ne veut pas dire parfait dès le départ (en terme de maintenabilité, sécurité, etc.). Il est toujours nécessaire de comprendre les nombreux concepts sous-jacents (ssh, docker, Azure, etc.). Par contre on obtient un environnement qui fonctionne plus rapidement, et on pourra l'améliorer petit à petit :)

Mais sans plus attendre, ci-dessous un exemple de script que j'utilise pour créer ma machine de build Docker :

@ECHO OFF

SET PREFIX=myapp
SET ENV=build
SET LOC=WestEurope
SET AZURE_SUBSCRIPTION=7c6bed95-1337-1664-abcd-aa4691816e72
SET RG=%PREFIX%-rg-%ENV%
SET VM_NAME=%PREFIX%-dockermachine-%ENV%
SET AZUREVM_SIZE=Standard_D4s_v3
SET ADMIN_USER=myadmin

REM Création d'une machine de build docker avec la ligne de commande docker-machine (Installée avec Docker Desktop)
CALL docker-machine create --driver azure --azure-subscription-id %AZURE_SUBSCRIPTION% --azure-resource-group %RG% --azure-location %LOC% --azure-ssh-user %ADMIN_USER% --azure-size "%AZUREVM_SIZE%" %VM_NAME%

REM Afficher les variables d'environnement à configurer pour pouvoir se connecter directement au service Docker de la machine de builde distante
CALL docker-machine env %VM_NAME%

J'espère que les commentaires sont suffisamment parlants. La dernière ligne de commande docker-machine env devrait afficher les variables d'environnement à utiliser pour se connecter directement au service Docker de la machine de build distante.

Une fois notre machine de build opérationnelle, nous allons ensuite avoir besoin d'avoir un agent Azure Pipelines dessus. On pourrait tout à fait partir sur une installation standard d'agent Azure Pipelines sur un Linux comme décrit dans la doc Self-hosted Linux agents, mais cela voudrait dire que nous aurions besoin de "polluer" notre VM avec nos dépendances de dev, la gestion des conflits de version des outils installés, etc.

Comme nous utilisons Docker, une meilleur approche (selon moi) serait d'exécuter un agent de build à l'intérieur d'un conteneur Docker !

Pour cela, on aura besoin de se connecter au service docker de la machine de build, puis exécuter le script suivant :

@ECHO OFF

SET PREFIX=myapp
SET ENV=build
SET VM_NAME=%PREFIX%-dockermachine-%ENV%

SET AZP_URL=https://dev.azure.com/vfabing/
SET AZP_TOKEN=7wzr66gqzjq42kjsjvdpyhl3zhello7dh3fhbopimdpxkkmyaigq
SET AZP_POOL=%PREFIX%-pool
SET AZP_AGENT_NAME=%VM_NAME%-01
SET AZP_AGENT_DOCKER_IMAGE=vfabing/azure-pipelines-agent-dotnet-core-sdk

REM Démarrer un agent Azure Pipelines dans un conteneur Docker
docker run -d --restart=always -e AZP_URL=%AZP_URL% -e AZP_TOKEN=%AZP_TOKEN% -e AZP_POOL=%AZP_POOL% -e AZP_AGENT_NAME=%AZP_AGENT_NAME% %AZP_AGENT_DOCKER_IMAGE%

Note : Si vous souhaitez plus d'information sur la création de votre propre image de conteneur pour un agent Azure Pipelines, vous pouvez jeter un coup d’œil à mon article # Azure Pipelines : Comment ajouter un agent de build avec Azure Container Instances - partie 2 : Agent Custom

Et voilà ! :)

Note 2 : Si vous souhaitez que votre agent de build puisse également builder des images docker depuis Azure Pipelines, vous aurez besoin de rajouter 2 paramètres supplémentaires à la commande docker run qui sont -v /var/run/docker.sock:/var/run/docker.sock -v /usr/bin/docker:/usr/bin/docker. Cependant, ces 2 paramètres ont de lourds impacts niveau sécurité comme mentionné par la documentation de Microsoft, donc c'est à garder en tête.

Conclusion

J'espère que cet article vous a donné plus d'information sur les machines de build Docker avec Azure DevOps. N'hésitez pas à réagir dans les commentaires, ou sur Twitter @vivienfabing, et que le code soit avec vous !