quentin.dufour.io/_posts/2023-04-11-fabriquer-des-conteneurs-légers-depuis-une-ci-cd.md
Quentin 8d000c365d
All checks were successful
continuous-integration/drone/push Build is passing
Update Article “2023-04-11-fabriquer-des-conteneurs-légers-depuis-une-ci-cd”
2023-04-11 09:16:59 +00:00

3.3 KiB

layout title date status sitemap category description
post Fabriquer et publier des conteneurs depuis une CI/CD 2023-04-11T10:51:40.008+02:00 draft true developpement 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 ici.

J'ai pas mal travaillé sur la CI/CD de Garage, 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, 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 !

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 :

# 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";
      };