Un repo pour les builder tous

Un repo et un sous-dossier par conteneur :

mon-beau-conteneur/
Dockerfile
Readme.md

un-autre/
Dockerfile
src/app.js

projet/conteneur1/
Dockerfile
projet/conteneur2/
Dockerfile
…

Jusque-là tout va bien ! Ensuite, ça se complique, comment faire pour faire le build ?

Solution de base, à chaque push de modifications, je refais tous les builds, j’ai donc un job par sous-répertoire.

Je pars du template de build docker :

…

docker-build:
  # Use the official docker image.
  image: docker:latest
  stage: build
  services:
    – docker:dind
  before_script:
    – docker login -u « $CI_REGISTRY_USER » -p « $CI_REGISTRY_PASSWORD » $CI_REGISTRY
  script:
  

    – docker build –pull t « $CI_REGISTRY_IMAGE:${tag} » mon-beau-conteneur/
    – docker push « $CI_REGISTRY_IMAGE:${tag} »

…

Fonctionnel mais pas fantastique, et surtout inutile.

La solution ce sont les parent-child pipelines :

Dans la CI parent, je lance un bash qui cherche quels sont les Dockerfiles modifiés, et qui génère un fichier avec l’ensemble des jobs pour build uniquement les concernés.

Le fichier .gitlab-ci.yml ressemble à ça :

…

stages:
– generate-build-jobs
– triggers

search-for-updates:
image: debian:bullseye-slim
stage: generate-build-jobs
before_script:
– chmod +x ./generate-jobs.sh
script: ./generate-jobs.sh
artifacts:
paths:
– « generated-jobs.yml »
rules:
– if: $CI_COMMIT_BRANCH
exists:
– « **/Dockerfile »

builds:
stage: triggers
trigger:
include:
– artifact: « generated-jobs.yml »
job: search-for-updates

…

Avec la règle, “if : changes”, le script se lance uniquement lorsqu’au moins un Dockerfile a changé.

J’aime bien debian, et j’ai besoin de bash, donc j’ai pris bulleye-slim comme image de base.

Le job lance le script, et lorsqu’il termine, il upload le fichier “generated-jobs.yml” en tant qu’“artifact”.

Il sera disponible pour le job “builds” qui grâce au mot-clef “trigger” lance tous les jobs contenus dans le fichier.

Voilà à quoi ressemble le script “generate_jobs.sh” :

…

#!/bin/bash
apt-get update
apt-get install -y git
# needed to do the diff between branches
git fetch –depth 50 origin main:main

if
] ; then
updatedFiles=$(git diff –name-only main…) # new branch
else
updatedFiles=$(git diff –name-only $CI_COMMIT_BEFORE_SHA $CI_COMMIT_SHA)
fi

for updatedFile in ${updatedFiles
}; do
echo « FILEPATH= »$updatedFile
if
] ; then # if I find a dockerfile
slashes=${updatedFile//
}
numberOfSlashes=$((${#slashes})) # to manage subdir
for ((depth=1;depth<=numberOfSlashes;depth++)); do currentDir=$(echo $updatedFile|cut -d/ -f$depth) if (( (depth > 1) && (depth <= numberOfSlashes) )); then name=$name »- » dirToBuild=$dirToBuild »/ » echo « name=> « $name
echo « dirSoBuild=> « $dirToBuild
fi
name=$name$currentDir
dirToBuild=$dirToBuild$currentDir
echo « name =>  » $name
echo « dirToBuild =>  » $dirToBuild
done
echo « name=> « $name
sed « s|==DIRTOBUILD==|${dirToBuild}|g » gitlab-ci-tpl.yml >> generated-jobs.yml
sed -i « s|==JOBNAME==|${name}|g » generated-jobs.yml
name= » »
dirToBuild= » »
fi
done

…

Le bash vérifie la liste des fichiers modifiés et pour chaque Dockerfile ajoute un job dans la child-pipeline : le fichier ”generated-jobs.yml”.

Pour ça, il fait juste un “sed“ pour le sous-répertoire à gérer. Il vérifie les fichiers modifiés entre les commit ou lorsque c’est une nouvelle branche, il compare avec la branche par défaut (variable disponible dans Gitlab ci $CI_DEFAULT_ BRANCH).

Mémo rapide

Le bash vérifie la liste des fichiers modifiés et pour chaque Dockerfile ajoute un job dans la child-pipeline : le fichier ”generated-jobs.yml”.

Pour ça, il fait juste un “sed“ pour le sous-répertoire à gérer.

Pour finir mon template de job :

Pour finir, voici mon template de job, très simple et basé sur un template de base :

…

docker-build-generated-==JOBNAME==:
# Use the official docker image.
image: docker:latest
stage: build
services:
– docker:dind
before_script:
– export DOCKER_BUILDKIT=1
– export CI_REGISTRY_IMAGE= »registry _name/==JOBNAME== »
– docker login -u « $CI_REGISTRY_USER » -p « $CI_REGISTRY_PASSWORD » $CI_REGISTRY
# Default branch leaves tag empty (= latest tag)
# All other branches are tagged with the escaped branch name (commit ref slug)
script:
– |
if
] ; then
tag= » »
echo « Running on default branch ‘$CI_DEFAULT_BRANCH’: tag = ‘master' »
else
tag= »$CI_COMMIT_REF_SLUG »
echo « Running on branch ‘$CI_COMMIT_BRANCH’: tag = $tag »
fi
– tag=$(date +’%Y%m%d%H%M%S’)$tag
– docker build –pull -t « $CI_REGISTRY_IMAGE:${tag} » ==DIRTOBUILD==
– docker push « $CI_REGISTRY_IMAGE:${tag} »
– echo ‘docker push « $CI_REGISTRY_IMAGE:${tag} »‘

…

Petites subtilités :

• Il faut un nom de job unique
• Il faut penser à mettre à jour le chemin de la registry
• Il faut que les noms de répertoires soient simples et propres (pas d’espaces, caractères spéciaux… Mais ça devrait toujours être le cas, non ? 😉)

Pour les petits malins; oui, je vous ai vu, vous qui vous dites, il est sympas, mais si je modifie que “un-autre/src/app.js” ça ne va pas faire le build, et vous avez raison !

Rappelons le contexte, nous avons mis dans ce repo les conteneurs qui ne bougent pas ou presque, et qui pour la plus grosse partie sont des images de base avec quelques packages ou configuration supplémentaires.

Donc, si votre source bouge régulièrement, il est certain qu’un repository de code spécifique est plus adapté; ceci étant dit, il y a quand même au moins deux solutions :

• Adapter le bash pour qu’une modification de **/src/* ajoute un job pour le sous répertoire concerné
• Simplement ajouter un commentaire au Dockerfile (date de dernière modification, version, incrément de build …) que vous pourrez modifier pour forcer le build

Conclusion

Voilà notre solution pour gérer nos petits conteneurs de la manière la plus automatisée et simple possible, sans multiplier les repository git, en utilisant au maximum la CI/CD de Gitlab, tout en restant sobre sur les ressources (éco-logique/nomique-ment plus sérieux).

Vos retours et vos remarques sur nos produits sont les bienvenues !