forked from quentin/quentin.dufour.io
Update Article “2023-04-11-fabriquer-des-conteneurs-légers-depuis-une-ci-cd”
This commit is contained in:
parent
066528502e
commit
8d000c365d
1 changed files with 56 additions and 4 deletions
|
|
@ -1,21 +1,73 @@
|
||||||
---
|
---
|
||||||
layout: post
|
layout: post
|
||||||
title: Fabriquer des conteneurs légers depuis une CI/CD
|
title: Fabriquer et publier des conteneurs depuis une CI/CD
|
||||||
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 des conteneurs légers depuis une CI/CD implique
|
description: Construire et publier des conteneurs légers et multi-plateformes
|
||||||
plusieurs défis à relever, on les adresse un par un ici.
|
depuis une CI/CD implique plusieurs défis à relever, on les adresse un par un
|
||||||
|
ici.
|
||||||
---
|
---
|
||||||
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é.
|
||||||
|
|
||||||
Si la question du cache et des artefacts binaires est passionnante, nous allons la garder pour un autre billet de blog, et nous focaliser sur **comment construire des conteneurs légers et les envoyer sur un registre Docker statique** dans ce billet. Si vous ne voyez pas ce que j'entends par registre statique, allez donc [jeter un coup d'oeil à mon précédent billet !](https://quentin.dufour.io/blog/2023-04-06/un-registre-statique-docker-avec-garage/)
|
Si la question du cache et des artefacts binaires est passionnante, nous allons la garder pour un autre billet de blog, et nous focaliser sur **comment construire des conteneurs légers, multi-plateforme et les publier** dans ce billet. Si vous ne voyez pas ce que j'entends par registre statique, allez donc [jeter un coup d'oeil à mon précédent billet !](https://quentin.dufour.io/blog/2023-04-06/un-registre-statique-docker-avec-garage/)
|
||||||
|
|
||||||
|
Alors maintenant qu'on a notre périmètre, décortiquons le:
|
||||||
|
|
||||||
|
- **léger** : c'est à dire qui embarque le strict minimum. Bien souvent, on peut se contenter d'un binaire statique.
|
||||||
|
- **multi-plateforme :** un seul tag d'image permettra à des gens sur ARM comme sur X86_64 d'utiliser votre logiciel
|
||||||
|
- **publier** : on publier les conteneurs sur un registre, ici nous verrons comment faire sur le docker hub mais aussi sur notre registre statique à base de Garage
|
||||||
|
|
||||||
|
_À noter qu'il y a un dernier point qui ne sera pas abordé dans ce billet qui sera sans aucun doute beaucoup trop long de toute manière, c'est comment gérer la garbage collection de nos artifacts._
|
||||||
|
|
||||||
|
## Une build file avec Nix Flake
|
||||||
|
|
||||||
|
Pour ce billet, on va prendre comme un exemple un programme en go que j'ai écrit, Albatros, ma propre CI/CD (ça devient déjà meta). L'avantage de prendre comme exemple un programme en Go, c'est que ça se cross compile facilement. Voilà un extrait du fichier `flake.nix` de notre projet :
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
```hcl
|
||||||
|
# declare the go module of this package, allow for cross compilation
|
||||||
|
gopkg = arch: (pkgs.buildGoModule rec {
|
||||||
|
pname = "albatros-go-module";
|
||||||
|
version = "0.9";
|
||||||
|
CGO_ENABLED = 0;
|
||||||
|
# ...
|
||||||
|
}).overrideAttrs (old: old // { GOOS = "linux"; GOARCH = arch; });
|
||||||
|
|
||||||
|
# logic to build static binaries
|
||||||
|
albatrosStaticBin = arch: pkgs.stdenv.mkDerivation {
|
||||||
|
pname = "albatros";
|
||||||
|
version = "0.9";
|
||||||
|
unpackPhase = "true";
|
||||||
|
installPhase = ''
|
||||||
|
cp `find ${gopkg arch}/bin -name albatros` $out
|
||||||
|
'';
|
||||||
|
};
|
||||||
|
|
||||||
|
# logic to build docker containers
|
||||||
|
docker = staticBin: arch: pkgs.dockerTools.buildImage {
|
||||||
|
name = "dxflrs/albatros";
|
||||||
|
architecture = arch;
|
||||||
|
config = {
|
||||||
|
Cmd = [ "${staticBin}" ];
|
||||||
|
};
|
||||||
|
};
|
||||||
|
|
||||||
|
# map nixos/llvm arch to golang arch
|
||||||
|
archmap = {
|
||||||
|
"aarch64-linux" = "arm64";
|
||||||
|
"x86_64-linux" = "amd64";
|
||||||
|
"i686-linux" = "386";
|
||||||
|
"armv6l-linux" = "arm";
|
||||||
|
};
|
||||||
|
```
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
|
||||||
Loading…
Reference in a new issue