Dans ma chaîne d’intégration continue j’utilise Docker in docker alias Dind afin de maximiser l’isolation de la phase test du build. Cette phase test consiste en une construction (dans le cas d’une application avec docker-compose un simple lancement) qui se veut répétable en partant de rien c’est-à-dire sans aucun effet de bord de cache docker. Dind est alors une solution.
Malheureusement comme le démon docker utilisé à chaque construction est vierge cette étape de test est relativement longue. La capture ci-dessous montre les 2 premières étapes (stage) de la construction (test et déploiement en environnent de préprod) qui prennent 57 min dont 44 min juste pour la phase de test dans DIND.
Les construction avec Dind nécessite beaucoup de téléchargement d’images puisque elle part de rien. Une première action est de limiter les téléchargements distant en ayant sur le réseau local des proxy cache de registry. Cette solution est abordée dans le billet https://blog.bressure.net/2020/04/15/perennite-des-images-externes-docker/
SSD
L’utilisation de SSD permet d’accélérer les entrées/sorties disque. En effet cela permet de passer de quelques dizaines de Mo/s à plusieurs centaines de Mo/s ! Les resultats sont très convaincants puisque les 2 premieres étapes du build se font désormais en 5 min contre 57 auparavant. La phase utilisant Dind prend 4 min au lieu de 44 min auparavant. On divize par 10 le temps de construction.
tempfs
Une autre solution à explorer est l’utilisation d’un système de fichier en RAM: tempfs.
Pour le gitlab-runner bootstrap on voit à peu près quel répertoire placer en RAM mais pour le gitlab-runner dockerisé il faudra sans doute faire une gymnastique pour trouver le répertoire et il faudrait sans doute le monter sur l’hôte. Quand à la version du build utilisant DIND il faudrait mettre en RAM le répertoire /var/lib/docker de DIND.
Tags: Docker ssd