Aller au contenu
DevSecOps Logo DevSecOps Logo DevSecOps
Docs
Blog
Blog

Renovate automatise les maj de conteneurs

logo

MAJ : Remplacement de docker-dind par img.

Dans le billet précédent, je vous exposais comment j’utilise mon cluster kubernetes dans pour faire tourner mes runners gitlab. Je vous propose de voir comment utiliser ces runners pour builder, tester et valider des images de container.

Pour cela je vais utiliser quelques un des outils que je vous ai exposés :

  • renovate qui scrute les projets à la recherche de dépendances à mettre à jour
  • lastversion qui récupère la dernière version d’un produit
  • halodint pour valider la qualité d’écriture des Dockerfiles
  • container-structure-test pour valider le contenu d’une image
  • trivy pour valider que l’image produite ne contient des vulnérabilités.

Tous ces outils, je vais les mettre en oeuvre dans un pipeline gitlab-ci pour qu’à chaque nouvelle version détectée par renovate (run schédulé) un build d’une nouvelle image soit produite et validée. Restera plus qu’à accepter la merge Request créé par Renovate pour que l’image soit poussé dans votre registry Docker.

gitlab kubernetes runners docker

Paramétrage de Docker (ancienne version -> plus utilisé -> passage à img)

Pour que Docker soit accessible depuis les jobs Gitlab je dois l’exposer en mode TCP.

Il faut éditer le fichier /etc/docker/daemon.json pour ajouter dans les hosts le mode tcp sur le port 2375 (non sécurisé tls = false) :

{
  "hosts": ["unix:///var/run/docker.sock", "tcp://0.0.0.0:2375"],
  "tls": false,
  "insecure-registries": [
  ]
}

Pour surcharger les paramètres du service docker je crée un fichier override.conf dans le répertoire /etc/systemd/system/docker.service.d/ avec ce contenu :

[Service]
ExecStart=
ExecStart=/usr/bin/dockerd

On redémarre le service :

Terminal window
sudo systemctl restart docker

On teste qu’on arrive à se connecter en mode TCP :

Terminal window
export DOCKER_HOST=tcp://<ip de votre serveur docker>:2375
export DOCKER_TLS_CERTDIR=""


docker info
...


WARNING: API is accessible on http://0.0.0.0:2375 without encryption.
         Access to the remote API is equivalent to root access on the host. Refer
         to the 'Docker daemon attack surface' section in the documentation for
         more information: https://docs.docker.com/go/attack-surface/

Pour sécuriser le tout je devrais activer tls, mais je n’ai trouvé comment injecter le certificat dans le runner gitlab.

Création des images sans dind avec img

img ↗ est un projet qui est en fait une surcouche de buildkit, dont l’objectif est de permettre de construire des images sans privilège (sans root). Pour optimiser les temps de build, je vais l’utiliser avec l’option de sortie au format oci-tar. trivy et container-struct-test prennent en charge ce format.

Vous pouvez l’installer sur votre poste de travail :

Terminal window
sudo apt install libseccomp-dev uidmap
export IMG_SHA256= " cc9bf08794353ef57b400d32cd1065765253166b0a09fba360d927cfbd158088 "
curl -fSL " https://github.com/genuinetools../../../assets/releases/download/v0.5.11/img-linux-amd64 " -o " /usr/local/bin/img " \
 && echo "${IMG_SHA256 } /usr/local/bin/img" | sha256sum -c - \
 && chmod a+x "/usr/local/bin/img"

Bonne nouvelle pour les images à base d’alpine le package est disponible.

Terminal window
apk add img

Les options sont les mêmes que celle de la cli docker : build, tag, push, pull, login, logout, save.

Pour optimiser les temps de build, il est possible d’utiliser l’option --cache-from.

Création du groupe dans Gitlab

Je vais créer un groupe docker pour stocker deux sous-groupes images et template ainsi qu’un projet renovate-bot.

Ma structure ↗

Création de la registry Docker

La registry docker sera celle porté par le groupe images. J’ai déjà expliqué tout cela dans un précédent billet. N’oubliez de créer le PAT pour vous connecter à la registry (je lui ai donné tous les droits, mais je pense qu’on peut limiter).

Terminal window
docker login registry.gitlab.com -u <votre-compte> -p <votre-token>


Login Succeeded

Création des variables du groupe

Dans les settings CI/CD du groupe docker créer deux variables : DEPLOY_USER qui votre compte gitlab et DEPLOY_TOKEN qui est le PAT créé précédemment.

gitlab kubernetes runners docker

Création des images nécessaires au pipeline

Nous allons créer plusieurs qui seront utilisé dans le pipeline: hadolint, lastversion et container-structure-test. A la fin vous devriez obtenir ceci dans votre registry :

gitlab kubernetes runners docker

Création de l’image Lastversion

Cloner le projet lastversion ↗.

Terminal window
git clone https://gitlab.com/dockerfiles6/images/lastversion.git
cd lastversion
rm -rf .git

Vous ferez ainsi pour tous les projets !

On peut lancer le build :

Terminal window
export REGISTRY=<votre-registry-docker>
./build.sh
 ---> 951262b8e206


Successfully built 951262b8e206
Successfully tagged registry.gitlab.com/dockerfiles6/images/lastversion:2.0.1

En sortie vous devriez avoir le nom de l’image. Il reste plus qu’à pousser dans votre registry docker.

Terminal window
docker login registry.gitlab.com -u <votre-compte> -p <votre-token>


docker push ${REGISTRY}/lastversion:<version>

Un conseil jetez un œil au Dockerfile, je me suis bien amusé à l’écrire celui-là. J’explique tout dans ce billet sur l’optimisation des images python.

Création de l’image Img

On reprend le même principe. Cloner le projet img ↗.

Et faire comme précédemment.

Création de l’image Hadolint

On reprend le même principe. Cloner le projet hadolint ↗.

Et faire comme précédemment.

Création de l’image container-structure-test

On reprend le même principe. Cloner le projet container-structure-test ↗.

Et faire comme précédemment.

Ecriture du template de CI

Pour éviter de dupliquer du code, je vais utiliser un template de pipeline Gitlab.

On reprend le même principe. Cloner le projet ci-build ↗.

Quelques explications

Tout se passe dans le fichier build.yml :

variables:
  REGISTRY: registry.gitlab.com/dockerfiles6/images




stages:
  - lint
  - version
  - build
  - tests
  - push


lint:
  tags:
    - myrunner
  stage: lint
  image: registry.gitlab.com/dockerfiles6/images/hadolint:2.9.2
  script:
    - hadolint --ignore DL3018 --ignore DL3008 --ignore SC2015 --ignore=DL3041 Dockerfile


version:
  tags:
    - myrunner
  stage: version
  image: registry.gitlab.com/dockerfiles6/images/lastversion:2.2.2
  script:
    - export VERSION=$(lastversion ${SOURCE})
    - envsubst < test.yml > unittest.yml
    - echo "VERSION=$VERSION" >> build.env
  artifacts:
    reports:
      dotenv: build.env
    paths:
      - unittest.yml


build:
  tags:
    - myrunner
  stage: build
  image: registry.gitlab.com/dockerfiles6/images/img:0.5.11
  dependencies:
    - version
  script:
    - img build --cache-from registry.gitlab.com/dockerfiles6/images/${PRODUCT}:latest -o type=oci,dest=image.tar .
  artifacts:
    paths:
      - image.tar


trivy:
  tags:
    - myrunner
  stage: tests
  image:
    name: aquasec/trivy:0.24.4
    entrypoint: [""]
  dependencies:
    - version
    - build
  script:
    - trivy image --input image.tar


test:
  tags:
    - myrunner
  stage: tests
  image:
    name: registry.gitlab.com/dockerfiles6/images/container-structure-test:1.11.0
    entrypoint: [""]
  dependencies:
    - version
    - build
  script:
    - container-structure-test test --driver tar --image image.tar --config unittest.yml


push:
  tags:
    - myrunner
  rules:
    - if: $CI_COMMIT_BRANCH == "master"
    - if: $CI_COMMIT_BRANCH == "main"
  stage: push
  image: ${REGISTRY}/img:0.5.11
  dependencies:
    - version
  script:
    - img build --cache-from ${REGISTRY}/${PRODUCT}:latest -t ${REGISTRY}/${PRODUCT}:${VERSION} -t ${REGISTRY}/${PRODUCT}:latest .
    - echo "${DEPLOY_TOKEN}" | img login --username ${DEPLOY_USER} --password-stdin registry.gitlab.com
    - img push ${REGISTRY}/${PRODUCT}:${VERSION}
    - img push ${REGISTRY}/${PRODUCT}:latest
...

Les parties importantes :

  • La registry Docker ou sont stockés les images
variables:
  REGISTRY: registry.gitlab.com/dockerfiles6/images
  • on met une petite règle sur le job push qu’il ne s’exécute que sur la branche master ou main

Configuration de renovate pour ce projet

Il faut indiquer à Renovate qu’il faut regarder dans les fichiers de type *.yml. Ca se passe dans le fichier renovete.json :

{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "extends": ["config:base"],
  "gitlabci": {
    "fileMatch": ["^*.yml$"
    ]
  }
}

Pousser le tout dans votre groupe docker

  1. Créez un projet ci-build dans le sous-groupe template et pousser le contenu que vous aurez modifié.
  2. Créez des projets hadolint, lastversion et container-structure-test dans le sous-groupe images et poussez-y les projets. Normalement dans ces projets les pipelines vous se déclencher.

Et pour finir renovate

Renovate va scruter les projets qui sont déclarés dans sa configuration à la recherche de dépendances.

Création du projet

On reprend le même principe. Cloner le projet renovate-bot ↗

Terminal window
git clone https://gitlab.com/dockerfiles6/renovate-bot.git
cd renovate-bot
rm -rf .git

Editez le fichier config.js pour modifier les urls des projets dans la section repositories:

module.exports = {
  hostRules: [
    {
      hostType: "docker",
      matchHost: "registry.gitlab.com/dockerfiles6",
      username: process.env.DEPLOY_USER,
      password: process.env.DEPLOY_TOKEN,
    },
  ],
  endpoint: "https://gitlab.com/api/v4/",
  platform: "gitlab",
  gitUrl: "https",
  onboardingConfig: {
    extends: ["config:base"],
  },
  vulnerabilityAlerts: {
    labels: ["security"],
    schedule: "at any time",
  },
  repositories: [
    "dockerfiles6/template/ci-build",
    "dockerfiles6/images/hadolint",
    "dockerfiles6/images/ansible-lint",
    "dockerfiles6/images/lastversion",
    "dockerfiles6/images/container-structure-test",
    "dockerfiles6/images/img",
    "b4288/infra-as-code-homelab",
    "dockerfiles6/build-python-wheel"
  ],
};

Création des variables

Créez un second PAT gitlab et un PAT GitHub qui sera utilisé par renovate. Créez deux variables :

  • GITHUB_COM_TOKEN contenant le PAT Github
  • RENOVATE_TOKEN contenant le second PAT gitlab

gitlab kubernetes runners docker variables

Maintenant vous pouvez pousser le projet dans gitlab. Rien ne se lance, car le pipeline ne se lance que celui-ci vient de la source schedule.

Mise en place du scheduling

Pour éviter que renovate ne consomme les ressources quand j’en ai besoin, j’ai fait le choix de les scheduler de nuit. Dans le menu CI/CD > Schedules > [New schedule]

gitlab kubernetes runners docker schedule

On finit par [Save Pipeline]

Déclenchement d’un pipeline

Il suffit de cliquer que la petite icône [>]. Ensuite allez dans le menu CI/CD > Pipelines. Normalement ça tourne.

A la fin allez dans le groupe Docker et vérifier le compteur de Merge requests. S’il n’en y pas, c’est que renovate à rien retrouver à dire.

gitlab kubernetes runners docker schedule

Pour tester, remplacer par exemple l’image source du Dockerfile de lastversion. Et relancez !

Cliquez sur une d’entre elles.

gitlab kubernetes runners docker schedule

Si le pipeline s’est correctement déroulé alors vous pouvez [Merger]. Cela poussera la nouvelle version dans votre registry docker.

Reste à faire

Je dois trouver le moyen d’optimiser le temps de build en trouvant le moyen d’activer le cache dans les jobs de build.

J’aimerais trouver une solution pour me passer de lastversion et construire le numéro de version de l’image avec ce que retourne renovate.

Je pense qu’il y a moyen d’implémenter d’autres outils. Je le ferais si les idées me viennent comme l’outil kbld.

Plus loin

Si vous voulez modifier le template de build, créez une branche et modifier la référence dans le fichier .gitlab-ci.yml d’une image pour tester vos modifications.

Vous avez plus qu’à écrire plein de Dockerfile. C’est ce que je vous souhaite.