Update Article “2023-04-11-fabriquer-des-conteneurs-légers-depuis-une-ci-cd”
continuous-integration/drone/push Build is passing Details

This commit is contained in:
Quentin 2023-04-11 09:50:01 +00:00
parent 3c558087c9
commit 3b90999d55
1 changed files with 11 additions and 2 deletions

View File

@ -63,7 +63,7 @@ packages = builtins.mapAttrs (name: value: {
_On peut consulter le fichier en entier_ [_sur la forge_](https://git.deuxfleurs.fr/quentin/albatros/src/commit/d9facbb79c4551d90359c46b9f5d485c1503253a/flake.nix) _d'Albatros_.
Ce fichier est relativement simple à lire une fois qu'on sait comment l'aborder.
Ce fichier est relativement simple à lire une fois qu'on sait comment l'aborder.
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.
@ -86,4 +86,13 @@ nix build .#packages.i686-linux.docker.albatros -o albatros.386.tar.gz
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.
Problème : aujourd'hui il n'y a pas vraiment d'outils clé en main. Typiquement, [une issue sur skopeo](https://github.com/containers/skopeo/issues/1136) traine depuis 3 ans maintenant (2020) sans qu'elle n'ait jamais été résolue. On va essayer de bidouiller un truc de notre côté.
```bash
mkdir -p /tmp/albatros
skopeo --insecure-policy copy docker-archive:albatros.amd64.tar.gz dir:/tmp/albatros/amd64
```