arnaudlevy/quentin.dufour.io
1
0
Fork 0
forked from quentin/quentin.dufour.io
Code Pull requests 1 Activity

Update Article “2023-04-11-fabriquer-des-conteneurs-légers-depuis-une-ci-cd”

Browse source
This commit is contained in:
Quentin 2023-04-11 09:45:46 +00:00
parent 9d650fbcf1
commit e9cda41017
1 changed files with 20 additions and 9 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

29
_posts/2023-04-11-fabriquer-des-conteneurs-légers-depuis-une-ci-cd.md
View file

@ -1,13 +1,13 @@
--- ---
layout: post layout: post
title: Fabriquer et publier des conteneurs depuis une CI/CD title: Fabriquer et publier des conteneurs sans daemon Docker
date: 2023-04-11T10:51:40.008+02:00 date: 2023-04-11T10:51:40.008+02:00
status: draft status: draft
sitemap: true sitemap: true
category: developpement category: developpement
description: Construire et publier des conteneurs légers et multi-plateformes description: Construire et publier des conteneurs légers et multi-plateformes
depuis une CI/CD implique plusieurs défis à relever, on les adresse un par un depuis une CI/CD implique plusieurs défis à relever quand on a pas de daemon
ici. Docker à disposition, je vous partage mes réflexions.
--- ---
J'ai pas mal travaillé sur la CI/CD de [Garage](https://garagehq.deuxfleurs.fr/), et force est de constater qu'on a rencontré un nombre incroyable de problèmes. Entre autre, on a noté que les builds Rust sans cache sont trop lents par rapport à nos attentes, qu'il n'y avait pas de solution légère pour gérer les artefacts binaires et enfin que construire un conteneur quand on a un CI/CD à base de Docker, ça n'était pas possible car on n'avait pas accès au daemon docker ni la possibilité de faire du “docker in docker” de manière à peu près sécurisé. J'ai pas mal travaillé sur la CI/CD de [Garage](https://garagehq.deuxfleurs.fr/), et force est de constater qu'on a rencontré un nombre incroyable de problèmes. Entre autre, on a noté que les builds Rust sans cache sont trop lents par rapport à nos attentes, qu'il n'y avait pas de solution légère pour gérer les artefacts binaires et enfin que construire un conteneur quand on a un CI/CD à base de Docker, ça n'était pas possible car on n'avait pas accès au daemon docker ni la possibilité de faire du “docker in docker” de manière à peu près sécurisé.
@ -61,18 +61,29 @@ packages = builtins.mapAttrs (name: value: {
}) archmap; }) archmap;
``` ```
Ce fichier est relativement simple à lire une fois qu'on sait comment le lire. Ici, on va construire par rafinement successif les outils pour construire notre conteneur. Le premier bloc consiste en une fonction qui permet de compiler un module Go à partir de la recette fournie par la bibliothèque standard NixOS. Je dis bien une fonction, car ce bloc prend en paramètre `arch` qui contient l'architecture cible de notre module. Ainsi, si on lui passe `arm64` on aura un binaire qui fonctionne sur les processeurs ARM 64 bits, si on passe `386`, on aura un binaire pour les vieux PC x86 32 bits, etc. _On peut consulter le fichier en entier_ [_sur la forge_](https://git.deuxfleurs.fr/quentin/albatros/src/commit/d9facbb79c4551d90359c46b9f5d485c1503253a/flake.nix) _d'Albatros_.
Dans les blocs suivants, on raffine donc ce premier module. On va d'abord avoir une fonction qui va extraire le binaire statique du module généré par Go, ensuite une fonction Docker qui va mettre ce binaire statique dans un conteneur. Ce fichier est relativement simple à lire une fois qu'on sait comment l'aborder.
Enfin, on va déclarer quelles architectures on choisit de supporter, là j'en ai choisi 4. On va donc faire une boucle (`mapAttrs`) pour générer le conteneur Docker qui va bien pour chaque architecture. En fait on construit par rafinement successif. Le premier bloc consiste en une fonction qui permet de compiler un module Go à partir de la recette fournie par la bibliothèque standard NixOS. Je dis bien une fonction, car ce bloc prend en paramètre `arch` qui contient l'architecture cible de notre module. Ainsi, si on lui passe `arm64` on aura un binaire qui fonctionne sur les processeurs ARM 64 bits, si on passe `386`, on aura un binaire pour les vieux PC x86 32 bits, etc.
Dans les blocs suivants, on raffine donc ce premier module. On va d'abord avoir une fonction qui va extraire le binaire statique du module généré par Go, ensuite une fonction Docker qui va mettre ce binaire statique dans un conteneur.
Enfin, une fois notre logique définie, on va déclarer quelles architectures on choisit de supporter, là j'en ai choisi 4. On va donc faire une boucle (`mapAttrs`) pour générer le conteneur Docker qui va bien pour chaque architecture.
## Créer les artefacts avec nix build ## Créer les artefacts avec nix build
On peut ensuite créer nos différentes archives Docker, en précisant le chemin de sortie pour s'y retrouver :
```bash
nix build .#packages.x86_64-linux.docker.albatros -o albatros.amd64.tar.gz
nix build .#packages.armv6l-linux.docker.albatros -o albatros.arm.tar.gz
nix build .#packages.aarch64-linux.docker.albatros -o albatros.arm64.tar.gz
nix build .#packages.i686-linux.docker.albatros -o albatros.386.tar.gz
```
## Construire notre image multi-arch
Dans le monde des conteneurs, une image multiarch est juste une indirection, un fichier qui contient une liste de manifest avec des tags pour leur OS et leur architecture. Il faut donc créer un fichier qui liste le manifest de chacune de nos 4 images.
Problème : aujourd'hui il n'est pas facile de construire un manifest multi-arch sans daemon docker.