En 2016, j'ai retiré Google Analytics de ce blog pour ne pas me rendre complice de la plus grande machine à aspirer les données personnelles. À la place, j'analysais les journaux de mes serveurs¹ avec GoAccess. Depuis quelques années, les statistiques ne veulent plus rien dire, malgré mes tentatives pour filtrer les robots : les robots pilleurs des IA gonflent le nombre de visiteurs à environ 2 000 par jour. J'ai fini par adopter GoatCounter, une plateforme libre de mesure d'audience, respectueuse de la vie privée. J'ai remplacé le client JavaScript pour filtrer les robots de façon plus agressive et ajouté une solution de repli en CSS. Pour gagner en fiabilité, j'ai écrit un proxy local, installé sur chacun des cinq serveurs web qui hébergent ce blog. La suite de cet article détaille comment ces éléments s'articulent et comment je déploie l'ensemble sur NixOS. ❄️

Pourquoi GoatCounter ?

GoatCounter ne collecte aucune donnée personnelle : au lieu de stocker l'adresse IP du lecteur ou de s'appuyer sur des cookies, il crée un identifiant de session valide 8 heures à partir de l'agent utilisateur et de l'adresse IP. Ses fonctionnalités sont modestes, mais suffisantes pour un blog. Pour un aperçu de l'interface, l'auteur de GoatCounter propose une instance publique pour son site. Une version en ligne permet de l'essayer avant de l'héberger soi-même. Avec un seul binaire et une base de données SQLite, GoatCounter est l'une des solutions auto-hébergées les plus légères. Parmi les alternatives respectueuses de la vie privée figurent, par ordre croissant de complexité, Umami, Plausible et Rybbit.

Client JavaScript sur mesure

GoatCounter fournit un petit client JavaScript : 2 189 octets une fois minifié et compressé avec gzip. Il embarque des fonctionnalités dont je ne me sers pas : un compteur de visites, le suivi des clics, divers réglages, etc. Je le remplace par cette fonction pour enregistrer une visite :

const count = ({ event, title } = {}) => {
  const params = new URLSearchParams({
    p: event || location.pathname,
    t: title || document.title,
    r: document.referrer,
    q: location.search,
    s: document.documentElement.clientWidth,
    e: !!event,
    rnd: Math.random().toString(36).slice(2, 7),
  });
  fetch(`/count?${params}`, { keepalive: true }).catch(() => {});
};

Pour filtrer les robots², je vais plus loin en exigeant une interaction de l'utilisateur, une idée reprise de Bear Blog.

let sendHit = () => (sendHit = () => {}, count());
["touchmove", "mousemove", "keydown", "pointerdown"].forEach((eventName) =>
  document.addEventListener(eventName, sendHit, {
    once: true,
    passive: true,
  }),
);

Si un lecteur a désactivé JavaScript dans son navigateur, j'enregistre la visite à l'aide d'une image CSS. La pseudo-classe :hover ne la charge qu'après une interaction, une autre astuce piquée à Bear Blog. Environ 2 % de mes visiteurs entrent dans cette catégorie³.

<!DOCTYPE html>
<html lang="en" class="nojs">
  <head>
    <script>
      // Le code JavaScript de ce blog requiert ES6
      if ("noModule" in HTMLScriptElement.prototype)
        document.documentElement.classList.remove("nojs");
    </script>
  </head>
  <body>
  <!-- ... -->
    <style>
      .nojs body:hover {
        border-width: 0;
        border-image: url('/count?p=/en/blog/2026-kpi-goodhart&t=Building...&r=NoJS&e=false');
      }
    </style>
  </body>
</html>

Là où GoAccess annonçait environ 2 000 visiteurs par jour, GoatCounter compte moins de 200 humains⁴. Je suppose que ces pilleurs privilégient le moindre effort : si le contenu est accessible sans obstacle, comme sur ce blog, ils ne vont pas lancer une usine à gaz qui déclencherait une page vue. Même les robots qui exécutent JavaScript, comme Googlebot avec son Chromium sans interface, n'interagissent pas avec la page et ne déclenchent jamais les événements que j'écoute. La « preuve d'humanité » par l'interaction que j'utilise me semble pouvoir durer⁵.

route /count {
  log_skip
  @nojsbot {
    query r=NoJS
    not header Sec-Fetch-Dest image
  }
  respond @nojsbot 204
  reverse_proxy 127.0.0.3:8087 {
    # …
  }
}

Proxy local

Cinq serveurs à travers le monde en Europe et en Amérique du Nord servent le contenu de ce site, mais GoatCounter ne tourne que sur l'un d'eux. Pour ne pas perdre la trace des visiteurs quand GoatCounter est indisponible, j'exécute un proxy local qui écoute sur le même point de terminaison /count. Sur chaque serveur, il conserve les visites en mémoire, avec un tampon assez grand pour tenir plusieurs jours en cas d'indisponibilité. Il les envoie par lots au serveur amont via le point de terminaison authentifié /api/v0/count.

J'ai proposé le code du proxy dans la pull request #909. Le mainteneur de GoatCounter a refusé de maintenir cet amas de code pour un cas d'usage aussi niche. Développant moi aussi des logiciels libres, j'adopte souvent la même position pour mes propres projets : l'effort ponctuel d'un contributeur peut se transformer en engagement sur le long terme pour le mainteneur.

J'expose le point de terminaison du proxy sur le domaine de ce site pour échapper aux bloqueurs de publicité. Cela donne l'impression que je ne respecte pas le choix du lecteur, mais comme GoatCounter respecte la vie privée, je trouve cela acceptable.

location = /count {
  access_log off;
  proxy_pass http://127.0.0.3:8087/count;
  proxy_pass_request_headers off;
  proxy_set_header Accept-Language $http_accept_language;
  proxy_set_header User-Agent $http_user_agent;
  proxy_set_header X-Real-Ip $remote_addr;
}

Déploiement sur NixOS

Mes serveurs web tournent sous NixOS, une distribution Linux déclarative avec une gestion de configuration intégrée. Je gère ce petit troupeau avec Colmena, un outil de déploiement sans état pour NixOS. Ma configuration est disponible sur GitHub.

Déployer des applications dans des conteneurs

Pour une meilleure isolation, chaque application tourne dans un conteneur léger et éphémère, propulsé par systemd-nspawn. Chaque conteneur exécute une instance allégée de NixOS. Un module encapsule les options containers de NixOS pour éviter de répéter les mêmes options pour chaque application⁶. Les conteneurs partagent la pile réseau de l'hôte : l'isolation supplémentaire ne vaut pas la complexité accrue. Pour les alléger, je désactive aussi quelques services non essentiels.

{ config, lib, ... }:
let
  cfg = config.luffy.containers;
in
{
  # Réglages configurables pour notre module
  options.luffy.containers = lib.mkOption {
    default = { };
    description = "Ephemeral containers sharing the host network.";
    type = lib.types.attrsOf (lib.types.submodule {
      options = {
        config = lib.mkOption {
          type = lib.types.deferredModule;
          default = { };
          description = "NixOS configuration of the container.";
        };
      };
    });
  };

  # Traduit nos options en conteneurs NixOS
  config = {
    containers = lib.mapAttrs
      (name: container: {
        ephemeral = true;
        autoStart = true;
        privateNetwork = false;
        extraFlags = [ "--resolv-conf=replace-host" ];
        config = {
          imports = [ container.config ];
          networking.firewall.enable = false;
          system.stateVersion = config.system.stateVersion;
          systemd.services = {
            console-getty.enable = false;
            systemd-logind.enable = false;
            systemd-oomd.enable = false;
          };
        };
      })
      cfg;
  };
}

Pour configurer une instance GoatCounter tournant dans un conteneur et écoutant sur 127.0.0.4:8088, nous importons le module⁷ et déclarons le conteneur dans l'ensemble d'attributs config.luffy.containers :

{ pkgs, config, ... }: {
  imports = [ ./modules/container.nix ];
  config.luffy.containers.goatcounter = {
    config = {
      services.goatcounter = {
        enable = true;
        address = "127.0.0.4";
        port = 8088;
        proxy = true;
      };
    };
  };
}

Comme les conteneurs sont éphémères, il faut conserver les données persistantes dans des répertoires de l'hôte. Nous ajoutons une option mounts et demandons aux conteneurs de NixOS d'exposer les répertoires ainsi configurés via l'option bindMounts.

{ config, lib, ... }:
let
  cfg = config.luffy.containers;
in
{
  options.luffy.containers = lib.mkOption {
    type = lib.types.attrsOf (lib.types.submodule {
      options = {
        mounts = lib.mkOption {
          type = lib.types.listOf lib.types.str;
          default = [ ];
          description = "Host directories mounted read-write at the same place.";
        };
      };
    });
  };

  config = {
    containers = lib.mapAttrs
      (name: container: {
        bindMounts =
          lib.genAttrs container.mounts (path: { hostPath = path; isReadOnly = false; });
      })
      cfg;
  };
}

Par exemple, pour conserver la base de données de GoatCounter dans le répertoire /var/db/goatcounter de l'hôte, nous ajoutons ce répertoire à l'option mounts et modifions la définition du service pour indiquer à GoatCounter où trouver la base de données.

{ config, ... }:
let
  databaseDirectory = "/var/db/goatcounter";
in {
  config.luffy.containers.goatcounter = {
    mounts = [ databaseDirectory ];
    config = {
      services.goatcounter = {
        extraArgs = [ "-db=sqlite+${databaseDirectory}/db.sqlite" ];
      };
    };
  };
}

Un conteneur peut aussi avoir besoin de secrets. Colmena peut envoyer des secrets sans les stocker dans /nix. Nous ajoutons une option keys à nos conteneurs. Elle prend un ensemble d'attributs associant le nom de chaque secret à la commande qui le fournit. Ensuite, le module déclare les secrets requis à Colmena dans l'option deployment.keys, fait dépendre le conteneur de la présence des secrets, puis les attache au conteneur.

{ config, lib, ... }:
let
  cfg = config.luffy.containers;
in
{
  options.luffy.containers = lib.mkOption {
    type = lib.types.attrsOf (lib.types.submodule {
      options = {
        keys = lib.mkOption {
          type = lib.types.attrsOf (lib.types.listOf lib.types.str);
          default = { };
          description = "Secrets, as a command to run locally. They are mounted in /etc.";
        };
      };
    });
  };

  config = {
    # Colmena place chaque secret dans `/var/keys` et le rend accessible
    # au groupe "keys".
    deployment.keys = lib.concatMapAttrs
      (_: container: lib.mapAttrs
        (_: keyCommand: {
          inherit keyCommand;
          group = "keys";
          permissions = "0640";
          destDir = "/var/keys";
        })
        container.keys)
      cfg;

    # Le conteneur ne peut démarrer que si les secrets requis sont disponibles.
    systemd.services = lib.mapAttrs'
      (name: container:
        let
          units = map (key: "${key}-key.service") (lib.attrNames container.keys);
        in
        lib.nameValuePair "container@${name}" {
          requires = units;
          after = units;
        })
      cfg;

    # Attache chaque secret dans le conteneur.
    containers = lib.mapAttrs
      (name: container: {
        bindMounts = lib.mapAttrs'
          (key: _: lib.nameValuePair "/etc/${key}" {
            hostPath = "/var/keys/${key}";
            isReadOnly = true;
          })
          container.keys;
      })
      cfg;
  };
}

Par exemple, GoatCounter a besoin d'identifiants pour télécharger la base de données GeoIP. Je fournis une commande locale pour récupérer le secret depuis mon gestionnaire de mots de passe et je l'expose dans le conteneur via le fichier d'environnement /etc/goatcounter.env.

{ pkgs, config, ... }: 
let
  keyCommand = variable: [
    "${pkgs.runtimeShell}"
    "-c"
    "pass show personal/nixops/secrets | grep '^${variable}='"
  ];
in {
  config.luffy.containers.goatcounter = {
    keys."goatcounter.env" = keyCommand "GOATCOUNTER_GEODB";
    config = {
      systemd.services.goatcounter.serviceConfig = {
        EnvironmentFile = "/etc/goatcounter.env";
        SupplementaryGroups = [ "keys" ];
      };
    };
  };
}

Serveur GoatCounter

Nixpkgs fournit déjà un paquet pour GoatCounter. En surchargeant les attributs src et vendorHash, je réutilise sa définition pour ma version personnalisée avec le proxy :

{ goatcounter, fetchFromGitHub }:
goatcounter.overrideAttrs (_: {
  src = fetchFromGitHub {
    owner = "vincentbernat";
    repo = "goatcounter";
    rev = "feature/proxy";
    hash = "sha256-dJRlQlFu3tjcEgabT1LEbyFrasJlhmYu4L/T7EkoNcY=";
  };
  vendorHash = "sha256-c9Q5OrbZR+q6pD3SgPPWe8JUzcZco1AVUKGaV61k5DE=";
})

J'ai écrit un module NixOS pour encapsuler GoatCounter : la définition du conteneur, celle du service et les secrets. Le module accepte les options suivantes : package, serve.enable, serve.listenAddress, serve.port et serve.databaseFile. J'ai déjà détaillé la configuration du conteneur dans la section précédente. Finalement, j'ai choisi de ne pas réutiliser le module GoatCounter de NixOS : il est plutôt simple et le réécrire permet de me protéger de changements futurs inattendus.

{ config, pkgs, lib, ... }:
let
  cfg = config.luffy.goatcounter;
  databaseDirectory = builtins.dirOf cfg.serve.databaseFile;
  chown = "${pkgs.coreutils}/bin/chown -R";
in {
  config.luffy.containers.goatcounter = {
    config.systemd.services.goatcounter = {
      description = "GoatCounter Web Analytics";
      wantedBy = [ "multi-user.target" ];
      serviceConfig = {
        EnvironmentFile = "/etc/goatcounter.env";
        SupplementaryGroups = [ "keys" ];
        DynamicUser = true;
        Restart = "always";
        ExecStart = lib.escapeShellArgs [
          (lib.getExe cfg.package)
          "serve"
          "-listen=${cfg.serve.listenAddress}:${toString cfg.serve.port}"
          "-tls=none"
          "-db=sqlite+${cfg.serve.databaseFile}"
          "-automigrate"
        ];
        # Donne la base de données à l'utilisateur dynamique "goatcounter".
        ExecStartPre = "+${chown} goatcounter:goatcounter ${databaseDirectory}";
        ReadWritePaths = databaseDirectory;
      };
    };
  };
}

Le bout de code suivant configure GoatCounter pour écouter sur 127.0.0.4:8088 :

{
  luffy.goatcounter = {
    serve = {
      enable = true;
      listenAddress = "127.0.0.4";
      port = 8088;
    };
  };
}

La dernière étape consiste à configurer nginx pour exposer GoatCounter sur Internet. Je désactive le point de terminaison /count, car sa fonction est assurée par le proxy local.

{ config, ... }:
let
  cfg = config.luffy.goatcounter.serve;
in
{
  services.nginx.virtualHosts."goatcounter.luffy.cx" = {
    forceSSL = true;
    locations = {
      "/" = {
        proxyPass = "http://${cfg.listenAddress}:${toString cfg.port}";
      };
      "= /count".extraConfig = ''
        return 404;
      '';
    };
  };
}

Proxy GoatCounter

Le même module NixOS configure le proxy local, avec les options suivantes : proxy.enable, proxy.listenAddress, proxy.port et proxy.site (le site qui reçoit les lots de pages vues). Le proxy local n'a aucune donnée persistante, mais il a besoin de la clé d'API pour s'authentifier auprès de l'instance principale de GoatCounter : son conteneur utilise l'option keys, mais pas l'option mounts.

{ config, pkgs, lib, ... }:
let
  cfg = config.luffy.goatcounter;
  keyCommand = _: [ "…" ];
in
{
  config.luffy.containers.goatcounter-proxy = {
    keys."goatcounter-proxy.env" = keyCommand "GOATCOUNTER_API_KEY";
    config.systemd.services.goatcounter = {
      description = "GoatCounter Proxy.";
      wantedBy = [ "multi-user.target" ];
      serviceConfig = {
        EnvironmentFile = "/etc/goatcounter-proxy.env";
        SupplementaryGroups = [ "keys" ];
        DynamicUser = true;
        Restart = "always";
        ExecStart = lib.escapeShellArgs [
          (lib.getExe cfg.package)
          "proxy"
          "-site=${cfg.proxy.site}"
          "-listen=${cfg.proxy.listenAddress}:${toString cfg.proxy.port}"
          "-ratelimit=10/1"  # 10 requêtes par seconde par IP
        ];
      };
    };
  };
}

Sur chaque serveur, j'active le proxy local avec le bout de code suivant. La configuration nginx présentée plus haut expose le point de terminaison /count sous le même domaine que mon blog.

{
  luffy.goatcounter = {
    proxy = {
      enable = true;
      site = "goatcounter.luffy.cx";
      listenAddress = "127.0.0.3";
      port = 8087;
    };
  };
}

Sauvegarde de la base de données SQLite avec Litestream

Litestream est un outil de réplication en continu pour les bases de données SQLite. Il compresse les changements placés dans le journal d'écriture anticipée (WAL) situé à côté de la base de données et les envoie vers une destination distante. J'encapsule sa configuration dans un module NixOS, qui prend un ensemble d'attributs databases associant un nom au chemin de la base de données à sauvegarder.

Litestream tourne lui aussi dans un conteneur. Je monte les bases de données à répliquer, ainsi que les secrets pour pousser les sauvegardes vers une storage box de Hetzner via SFTP :

{ config, pkgs, lib, ... }:
let
  cfg = config.luffy.litestream;
  databaseDirs = lib.unique (map builtins.dirOf (builtins.attrValues cfg.databases));
in
{
  config = lib.mkIf (cfg.databases != { }) {
    luffy.containers.litestream = {
      mounts = databaseDirs;
      keys."litestream.env" = [
        "${pkgs.runtimeShell}"
        "-c"
        "pass show personal/nixops/secrets | grep '^SQLITE_BACKUP_'"
      ];
    };
  };
}

Dans le conteneur, je configure Litestream à travers les options services.litestream de NixOS :

• des instantanés complets chaque jour, conservés 15 jours ;
• trois niveaux de compactage pour les transactions : 5 minutes, 30 minutes et 3 heures ;
• la reprise automatique⁸ ;
• un réplica stocké dans un répertoire portant le nom de l'hôte ;
• des identifiants lus depuis /etc/litestream.env et exposés par expansion de variables.

{ config, pkgs, lib, ... }:
let
  cfg = config.luffy.litestream;
in
{
  config.luffy.containers.litestream = {
    config = {
      # Les bases de données appartiennent à des utilisateurs dynamiques, dont
      # l'UID n'est pas connu ici : Litestream tourne donc en root.
      systemd.services.litestream.serviceConfig = {
        User = lib.mkForce "root";
        Group = lib.mkForce "root";
      };
      # Utilise le service NixOS.
      services.litestream = {
        enable = true;
        environmentFile = "/etc/litestream.env";
        settings = {
          auto-recover = true;
          snapshot = {
            interval = "24h";
            retention = "360h";
          };
          levels = [
            { interval = "5m"; }
            { interval = "30m"; }
            { interval = "3h"; }
          ];
          dbs = lib.mapAttrsToList
            (name: path: {
              inherit path;
              replica = {
                type = "sftp";
                host = "\${SQLITE_BACKUP_HOST}";
                user = "\${SQLITE_BACKUP_USER}";
                password = "\${SQLITE_BACKUP_PASSWORD}";
                host-key = "\${SQLITE_BACKUP_HOSTKEY}";
                path = "${config.networking.hostName}/${name}";
              };
            })
            cfg.databases;
        };
      };
    };
  };
}

Pour sauvegarder la base de données de GoatCounter, je déclare un attribut goatcounter dans luffy.litestream.databases avec pour valeur le chemin de la base de données :

{ config, ... }:
let
  cfg = config.luffy.goatcounter.serve;
in
{
  luffy.litestream.databases.goatcounter = cfg.databaseFile;
}

Sur le serveur SFTP, nous pouvons inspecter le travail de Litestream, avec les transactions compactées et les instantanés complets :

❯ ls web02/goatcounter/ltx
web02/goatcounter/ltx/0
web02/goatcounter/ltx/1
web02/goatcounter/ltx/2
web02/goatcounter/ltx/3
web02/goatcounter/ltx/9
❯ ls -lh web02/goatcounter/ltx/1
29.1K Sep  5 01:25 0000000000003f2a-0000000000003f2b.ltx
72.4K Sep  5 02:03 0000000000003f2c-0000000000003f2d.ltx
63.3K Sep  5 02:24 0000000000003f2e-0000000000003f2f.ltx
[…]
❯ ls -lh web02/goatcounter/ltx/9
 8.5M Sep  5 02:00 0000000000000001-0000000000003f2b.ltx
 8.5M Sep  6 02:03 0000000000000001-0000000000004008.ltx
 8.6M Sep  7 02:03 0000000000000001-00000000000043a8.ltx
[…]

Nous pouvons restaurer la base de données depuis la sauvegarde avec quelques commandes shell. D'abord, nous arrêtons les conteneurs. Ensuite, nous mettons de côté la base de données endommagée, invoquons litestream restore depuis le bon environnement et redémarrons les conteneurs⁹.

# systemctl stop container@goatcounter container@litestream
# mv /var/db/goatcounter/db.sqlite{,.old}
# ( . /etc/nixos-containers/litestream.conf ; 
>   set -a ; . /var/keys/litestream.env ; set +a ;
>   $SYSTEM_PATH/sw/bin/litestream \
>     restore -config $SYSTEM_PATH/etc/litestream.yml /var/db/goatcounter/db.sqlite)
# ls -lh /var/db/goatcounter/db.sqlite
-rw-r--r-- 1 root root 20M Sep 20 07:33 /var/db/goatcounter/db.sqlite
# systemctl start container@goatcounter container@litestream

Dix ans après avoir retiré Google Analytics, les statistiques en JavaScript sont de retour sur ce blog, mais sans stocker de cookies ni d'adresses IP, et sans se reposer sur un tiers. J'écris d'abord pour moi, notamment parce que cela me permet de creuser un sujet et de m'y référer des années plus tard. Cependant, en savoir un peu plus sur mes lecteurs humains est un bonus appréciable, y compris sur ceux qui n'activent pas JavaScript. 🐐

Une PKI hors ligne renforce la sécurité en isolant physiquement l'autorité de certification des menaces réseau. Une YubiKey est une solution économique pour stocker un certificat racine. Vous avez également besoin d'un environnement isolé pour les opérations sur l'autorité de certification racine.

Ce billet décrit un système PKI hors ligne utilisant les composants suivants :

• 2 YubiKeys pour l'autorité de certification racine (avec une validité de 20 ans) ;
• 1 YubiKey pour l'autorité de certification intermédiaire (avec une validité de 5 ans) ;
• 1 carte Libre Computer Sweet Potato comme nano-ordinateur isolé.

Si nécessaire, il est possible d'ajouter plus de YubiKeys comme sauvegarde de l'autorité de certification racine. Ce n'est pas utile pour l'autorité de certification intermédiaire car vous pouvez en générer une nouvelle si l'actuelle est détruite.

La partie logicielle

offline-pki est une petite application Python pour gérer une PKI hors ligne. Elle s'appuie sur yubikey-manager pour gérer les YubiKeys et sur cryptography pour les opérations cryptographiques non exécutées par les YubiKeys. L'application a certains choix de conception opiniâtres. Notamment, la cryptographie est codée en dur pour utiliser la courbe elliptique NIST P-384.

La première étape consiste à réinitialiser toutes vos YubiKeys :

$ offline-pki yubikey reset
This will reset the connected YubiKey. Are you sure? [y/N]: y
New PIN code:
Repeat for confirmation:
New PUK code:
Repeat for confirmation:
New management key ('.' to generate a random one):
WARNING[pki-yubikey] Using random management key: e8ffdce07a4e3bd5c0d803aa3948a9c36cfb86ed5a2d5cf533e97b088ae9e629
INFO[pki-yubikey]  0: Yubico YubiKey OTP+FIDO+CCID 00 00
INFO[pki-yubikey] SN: 23854514
INFO[yubikit.management] Device config written
INFO[yubikit.piv] PIV application data reset performed
INFO[yubikit.piv] Management key set
INFO[yubikit.piv] New PUK set
INFO[yubikit.piv] New PIN set
INFO[pki-yubikey] YubiKey reset successful!

Ensuite, générez l'autorité de certification racine et créez autant de copies que vous voulez :

$ offline-pki certificate root --permitted example.com
Management key for Root X:
Plug YubiKey "Root X"...
INFO[pki-yubikey]  0: Yubico YubiKey CCID 00 00
INFO[pki-yubikey] SN: 23854514
INFO[yubikit.piv] Data written to object slot 0x5fc10a
INFO[yubikit.piv] Certificate written to slot 9C (SIGNATURE), compression=True
INFO[yubikit.piv] Private key imported in slot 9C (SIGNATURE) of type ECCP384
Copy root certificate to another YubiKey? [y/N]: y
Plug YubiKey "Root X"...
INFO[pki-yubikey]  0: Yubico YubiKey CCID 00 00
INFO[pki-yubikey] SN: 23854514
INFO[yubikit.piv] Data written to object slot 0x5fc10a
INFO[yubikit.piv] Certificate written to slot 9C (SIGNATURE), compression=True
INFO[yubikit.piv] Private key imported in slot 9C (SIGNATURE) of type ECCP384
Copy root certificate to another YubiKey? [y/N]: n

Vous pouvez examiner le résultat :

$ offline-pki yubikey info
INFO[pki-yubikey]  0: Yubico YubiKey CCID 00 00
INFO[pki-yubikey] SN: 23854514
INFO[pki-yubikey] Slot 9C (SIGNATURE):
INFO[pki-yubikey]   Private key type: ECCP384
INFO[pki-yubikey]   Public key:
INFO[pki-yubikey]     Algorithm:  secp384r1
INFO[pki-yubikey]     Issuer:     CN=Root CA
INFO[pki-yubikey]     Subject:    CN=Root CA
INFO[pki-yubikey]     Serial:     1
INFO[pki-yubikey]     Not before: 2024-07-05T18:17:19+00:00
INFO[pki-yubikey]     Not after:  2044-06-30T18:17:19+00:00
INFO[pki-yubikey]     PEM:
-----BEGIN CERTIFICATE-----
MIIBcjCB+aADAgECAgEBMAoGCCqGSM49BAMDMBIxEDAOBgNVBAMMB1Jvb3QgQ0Ew
HhcNMjQwNzA1MTgxNzE5WhcNNDQwNjMwMTgxNzE5WjASMRAwDgYDVQQDDAdSb290
IENBMHYwEAYHKoZIzj0CAQYFK4EEACIDYgAERg3Vir6cpEtB8Vgo5cAyBTkku/4w
kXvhWlYZysz7+YzTcxIInZV6mpw61o8W+XbxZV6H6+3YHsr/IeigkK04/HJPi6+i
zU5WJHeBJMqjj2No54Nsx6ep4OtNBMa/7T9foyMwITAPBgNVHRMBAf8EBTADAQH/
MA4GA1UdDwEB/wQEAwIBhjAKBggqhkjOPQQDAwNoADBlAjEAwYKy/L8leJyiZSnn
xrY8xv8wkB9HL2TEAI6fC7gNc2bsISKFwMkyAwg+mKFKN2w7AjBRCtZKg4DZ2iUo
6c0BTXC9a3/28V5aydZj6rvx0JqbF/Ln5+RQL6wFMLoPIvCIiCU=
-----END CERTIFICATE-----

Ensuite, vous pouvez créer un certificat intermédiaire avec offline-pki yubikey intermediate et l'utiliser pour signer des certificats en fournissant leur CSR à offline-pki certificate sign. Soyez prudent et inspectez la CSR avant de la signer, car seul le nom du sujet peut être remplacé. Consultez la documentation pour plus de détails. Obtenez les options disponibles en utilisant l'option --help.

La partie matérielle

Pour garantir que les opérations sur les autorités de certification racine et intermédiaire sont isolées du réseau, une solution économique consiste à utiliser une carte ARM64. Le Libre Computer Sweet Potato est une alternative plus ouverte au célèbre Raspberry Pi¹.

J'interagis avec lui via un convertisseur USB vers série :

$ tio /dev/ttyUSB0
[16:40:44.546] tio v3.7
[16:40:44.546] Press ctrl-t q to quit
[16:40:44.555] Connected to /dev/ttyUSB0
GXL:BL1:9ac50e:bb16dc;FEAT:ADFC318C:0;POC:1;RCY:0;SPI:0;0.0;CHK:0;
TE: 36574

BL2 Built : 15:21:18, Aug 28 2019. gxl g1bf2b53 - luan.yuan@droid15-sz

set vcck to 1120 mv
set vddee to 1000 mv
Board ID = 4
CPU clk: 1200MHz
[…]

L'assemblage Nix

Pour coller tout ensemble, j'utilise Nix avec un Flake fournissant :

• un paquet pour l'application offline-pki, avec la complétion pour le shell ;
• un shell de développement, incluant une version éditable de l'application offline-pki ;
• un module NixOS pour configurer la PKI, réinitialisant le système à chaque démarrage ;
• une image QEMU pour les tests ;
• une image de carte SD à utiliser sur le Sweet Potato ou une autre carte ARM64.

# Exécuter localement l'application
nix run github:vincentbernat/offline-pki -- --help
# Exécuter l'application dans une machine virtuelle QEMU
nix run github:vincentbernat/offline-pki\#qemu
# Construire l'image d'une carte SD pour Sweet Potato ou un Raspberry Pi
nix build --system aarch64-linux github:vincentbernat/offline-pki\#sdcard.potato
nix build --system aarch64-linux github:vincentbernat/offline-pki\#sdcard.generic
# Obtenir un shell de développement avec l'application
nix develop github:vincentbernat/offline-pki

Caddy est un serveur web libre écrit en Go. Il gère automatiquement les certificats TLS et propose une syntaxe de configuration simple. Les utilisateurs peuvent étendre ses fonctionnalités via des modules pour ajouter, par exemple, la limitation de débit, la mise en cache et l'intégration à Docker.

Bien que Caddy soit disponible dans Nixpkgs, l'ajout de modules supplémentaires n'est n'était pas simple¹. Le processus de compilation nécessite un accès Internet, ce que Nix refuse pendant la compilation pour garantir la reproductibilité. Lorsqu'on essaie de construire la dérivation suivante en utilisant xcaddy, un outil pour compiler Caddy avec des modules supplémentaires, cela échoue avec cette erreur : dial tcp: lookup proxy.golang.org on [::1]:53: connection refused.

{ pkgs }:
pkgs.stdenv.mkDerivation {
  name = "caddy-with-xcaddy";
  nativeBuildInputs = with pkgs; [ go xcaddy cacert ];
  unpackPhase = "true";
  buildPhase =
    ''
      xcaddy build --with github.com/caddy-dns/powerdns@v1.0.1
    '';
  installPhase = ''
    mkdir -p $out/bin
    cp caddy $out/bin
  '';
}

Les dérivations à sortie fixe (fixed-output derivations) constituent une exception à cette règle et obtiennent un accès réseau pendant la compilation. Elles doivent spécifier leur hash de sortie. Par exemple, la fonction fetchurl produit une dérivation à sortie fixe :

{ stdenv, fetchurl }:
stdenv.mkDerivation rec {
  pname = "hello";
  version = "2.12.1";
  src = fetchurl {
    url = "mirror://gnu/hello/hello-${version}.tar.gz";
    hash = "sha256-jZkUKv2SV28wsM18tCqNxoCZmLxdYH2Idh9RLibH2yA=";
  };
}

Pour créer une dérivation à sortie fixe, vous devez définir l'attribut outputHash. L'exemple ci-dessous montre comment obtenir le code source de Caddy, avec certains modules activés, comme une dérivation à sortie fixe en utilisant xcaddy et go mod vendor.

pkgs.stdenvNoCC.mkDerivation rec {
  pname = "caddy-src-with-xcaddy";
  version = "2.8.4";
  nativeBuildInputs = with pkgs; [ go xcaddy cacert ];
  unpackPhase = "true";
  buildPhase =
    ''
      export GOCACHE=$TMPDIR/go-cache
      export GOPATH="$TMPDIR/go"
      XCADDY_SKIP_BUILD=1 TMPDIR="$PWD" \
        xcaddy build v${version} --with github.com/caddy-dns/powerdns@v1.0.1
      (cd buildenv* && go mod vendor)
    '';
  installPhase = ''
    mv buildenv* $out
  '';

  outputHash = "sha256-F/jqR4iEsklJFycTjSaW8B/V3iTGqqGOzwYBUXxRKrc=";
  outputHashAlgo = "sha256";
  outputHashMode = "recursive";
}

Avec une dérivation à sortie fixe, c'est à nous de nous assurer que la sortie est toujours la même :

• xcaddy ne compile pas le programme et conserve le code source² ;
• nous spécifions la version de Caddy que nous voulons construire ;
• nous spécifions la version de chaque module demandé.

Vous pouvez utiliser cette dérivation pour remplacer l'attribut src dans pkgs.caddy :

pkgs.caddy.overrideAttrs (prev: {
  src = pkgs.stdenvNoCC.mkDerivation { /* ... */ };
  vendorHash = null;
  subPackages = [ "." ];
});

Consultez l'exemple complet dans le dépôt Git. Pour une intégration dans un Flake, vous pouvez utiliser github:vincentbernat/caddy-nix comme surcouche à Nixpkgs :

{
  inputs = {
    nixpkgs.url = "nixpkgs";
    flake-utils.url = "github:numtide/flake-utils";
    caddy.url = "github:vincentbernat/caddy-nix";
  };
  outputs = { self, nixpkgs, flake-utils, caddy }:
    flake-utils.lib.eachDefaultSystem (system:
      let
        pkgs = import nixpkgs {
          inherit system;
          overlays = [ caddy.overlays.default ];
        };
      in
      {
        packages = {
          default = pkgs.caddy.withPlugins {
            plugins = [ "github.com/caddy-dns/powerdns@v1.0.1" ];
            hash = "sha256-F/jqR4iEsklJFycTjSaW8B/V3iTGqqGOzwYBUXxRKrc=";
          };
        };
      });
}

Il y a quelques années, j'ai réduit mon infrastructure personnelle au strict minimum. Jusqu'en 2018, elle représentait une douzaine de conteneurs tournant sur un seul serveur Hetzner¹. J'ai migré mon courriel vers Fastmail et mes zones DNS vers Gandi. Il ne me restait plus que mon blog à héberger. À ce jour, ma petite infrastructure est composée de 4 machines virtuelles exécutant NixOS sur Hetzner Cloud et Vultr, d'une poignée de zones DNS sur Gandi et Route 53, et de quelques distributions CloudFront. Elle est gérée par CDK pour Terraform (CDKTF), tandis que les déploiements de NixOS sont gérés par NixOps.

Dans cet article, je présente brièvement Terraform, CDKTF et l'écosystème Nix. J'explique également comment utiliser Nix pour accéder à ces outils dans votre shell afin de les utiliser rapidement.

CDKTF : infrastructure en tant que code

Terraform est un outil d'« infrastructure en tant que code ». Vous pouvez définir votre infrastructure en déclarant des ressources avec le langage HCL. Ce dernier possède quelques fonctionnalités supplémentaires, comme des boucles permettant de déclarer plusieurs ressources à partir d'une liste, des fonctions intégrées que vous pouvez appeler dans les expressions et l'expansion de variables dans les chaînes de caractères. Terraform s'appuie sur un large ensemble de fournisseurs pour gérer les ressources.

Gérer des serveurs

Voici un court exemple utilisant le fournisseur pour Hetzner Cloud pour créer une machine virtuelle :

variable "hcloud_token" {
  sensitive = true
}
provider "hcloud" {
  token = var.hcloud_token
}

resource "hcloud_server" "web03" {
  name = "web03"
  server_type = "cpx11"
  image = "debian-11"
  datacenter = "nbg1-dc3"
}

resource "hcloud_rdns" "rdns4-web03" {
  server_id = hcloud_server.web03.id
  ip_address = hcloud_server.web03.ipv4_address
  dns_ptr = "web03.luffy.cx"
}

resource "hcloud_rdns" "rdns6-web03" {
  server_id = hcloud_server.web03.id
  ip_address = hcloud_server.web03.ipv6_address
  dns_ptr = "web03.luffy.cx"
}

L'expressivité de HCL est assez limitée et je trouve qu'un langage généraliste est plus pratique pour décrire les ressources. C'est là qu'intervient CDK pour Terraform : vous pouvez gérer votre infrastructure à l'aide de votre langage de programmation préféré, notamment TypeScript, Go et Python. Voici l'exemple précédent utilisant CDKTF et TypeScript :

import { App, TerraformStack, Fn } from "cdktf";
import { HcloudProvider } from "./.gen/providers/hcloud/provider";
import * as hcloud from "./.gen/providers/hcloud";

class MyStack extends TerraformStack {
  constructor(scope: Construct, name: string) {
    super(scope, name);

    const hcloudToken = new TerraformVariable(this, "hcloudToken", {
      type: "string",
      sensitive: true,
    });
    const hcloudProvider = new HcloudProvider(this, "hcloud", {
      token: hcloudToken.value,
    });

    const web03 = new hcloud.server.Server(this, "web03", {
      name: "web03",
      serverType: "cpx11",
      image: "debian-11",
      datacenter: "nbg1-dc3",
      provider: hcloudProvider,
    });
    new hcloud.rdns.Rdns(this, "rdns4-web03", {
      serverId: Fn.tonumber(web03.id),
      ipAddress: web03.ipv4Address,
      dnsPtr: "web03.luffy.cx",
      provider: hcloudProvider,
    });
    new hcloud.rdns.Rdns(this, "rdns6-web03", {
      serverId: Fn.tonumber(web03.id),
      ipAddress: web03.ipv6Address,
      dnsPtr: "web03.luffy.cx",
      provider: hcloudProvider,
    });
  }
}

const app = new App();
new MyStack(app, "cdktf-take1");
app.synth();

La commande de cdktf synth génère un fichier de configuration pour Terraform, terraform plan prévisualise les changements et terraform apply les applique. Maintenant que vous disposez d'un langage généraliste, vous pouvez utiliser des fonctions.

Gérer des enregistrements DNS

Si l'utilisation de CDKTF pour 4 serveurs web peut sembler un peu exagérée, il en va tout autrement lorsqu'il s'agit de gérer quelques zones DNS. Avec DNSControl, qui utilise JavaScript comme langage, j'ai pu définir la zone bernat.ch avec ce bout de code :

D("bernat.ch", REG_NONE, DnsProvider(DNS_BIND, 0), DnsProvider(DNS_GANDI),
  DefaultTTL('2h'),
  FastMailMX('bernat.ch', {subdomains: ['vincent']}),
  WebServers('@'),
  WebServers('vincent');

Cela produit 38 enregistrements. Avec CDKTF, j'écris :

new Route53Zone(this, "bernat.ch", providers.aws)
  .sign(dnsCMK)
  .registrar(providers.gandiVB)
  .www("@", servers)
  .www("vincent", servers)
  .www("media", servers)
  .fastmailMX(["vincent"]);

Toute la magie est située dans les fonctions appelées. Vous pouvez regarder le fichier dns.ts dans le dépôt cdktf-take1 pour comprendre comment cela fonctionne. Rapidement :

• Route53Zone() crée une zone sur Route 53 ;
• sign() signe la zone avec une clé de signature ;
• registrar() inscrit la zone auprès du registre de domaines et configure DNSSEC ;
• www() crée les enregistrements A et AAAA pour les serveurs web ;
• fastmailMX() crée les enregistrements MX et d'autres enregistrements liés pour configurer Fastmail en tant que fournisseur de courriel.

Voici le contenu de la fonction fastmailMX(). Elle génère quelques enregistrements et retourne la zone en cours pour faciliter le chaînage :

fastmailMX(subdomains?: string[]) {
  (subdomains ?? [])
    .concat(["@", "*"])
    .forEach((subdomain) =>
      this.MX(subdomain, [
        "10 in1-smtp.messagingengine.com.",
        "20 in2-smtp.messagingengine.com.",
      ])
    );
  this.TXT("@", "v=spf1 include:spf.messagingengine.com ~all");
  ["mesmtp", "fm1", "fm2", "fm3"].forEach((dk) =>
    this.CNAME(`${dk}._domainkey`, `${dk}.${this.name}.dkim.fmhosted.com.`)
  );
  this.TXT("_dmarc", "v=DMARC1; p=none; sp=none");
  return this;
}

Je vous encourage à parcourir le dépôt pour plus de détails !

À propos de Pulumi

Ma première tentative autour de Terraform a été d'utiliser Pulumi. Vous pouvez trouver cette tentative sur GitHub. C'est assez similaire à ce que je fais actuellement avec CDKTF. La principale différence est que j'utilise Python au lieu de TypeScript² car ce dernier ne m'était pas familier à l'époque.

Pulumi est antérieur à CDKTF et il utilise une approche légèrement différente. CDKTF génère une configuration pour Terraform (au format JSON au lieu de HCL), laissant la planification, la gestion des états et le déploiement à ce dernier. Il est donc lié aux limites de ce qui peut être exprimé par Terraform, notamment lorsque vous devez transformer des données obtenues d'une ressource à une autre³. Pulumi a besoin de fournisseurs spécifiques pour chaque ressource. De nombreux fournisseurs encapsulent des fournisseurs Terraform.

Bien que Pulumi offre une bonne expérience utilisateur, je suis passé à CDKTF car écrire des fournisseurs pour Pulumi est une corvée. CDKTF ne nécessite pas de passer par cette étape. En dehors des grands acteurs (AWS, Azure et Google Cloud), l'existence, la qualité et la fraîcheur des fournisseurs Pulumi sont inégales. La plupart des fournisseurs s'appuient sur un fournisseur Terraform et il se peut qu'ils soient en retard de quelques versions, qu'il leur manque quelques ressources ou qu'ils présentent des bogues qui leur sont propres.

Lorsqu'un fournisseur n'existe pas, vous pouvez en écrire un à l'aide de la bibliothèque pulumi-terraform-bridge. Le projet Pulumi fournit un modèle à cet effet. J'ai eu une mauvaise expérience avec celui-ci lors de l'écriture de fournisseurs pour Gandi et Vultr : le Makefile installe automatiquement Pulumi en utilisant curl | sh et ne fonctionne pas avec /bin/sh. Il y a un manque d'intérêt pour les contributions communautaires⁴ ou même pour les fournisseurs pour les acteurs tiers.

NixOS & NixOps

Nix est un langage de programmation purement fonctionnel. Nix est aussi le nom du gestionnaire de paquets qui est construit au-dessus du langage Nix. Il permet aux utilisateurs d'installer des paquets de manière déclarative. nixpkgs est un dépôt de paquets. Vous pouvez installer Nix au-dessus d'une distribution Linux ordinaire. Si vous voulez plus de détails, une bonne ressource est le site officiel, notamment la section « Apprendre ». La courbe d'apprentissage est rude, mais la récompense est grande.

NixOS : distribution Linux déclarative

NixOS est une distribution Linux construite au-dessus du gestionnaire de paquets Nix. Voici un bout de configuration pour ajouter quelques paquets :

environment.systemPackages = with pkgs;
  [
    bat
    htop
    liboping
    mg
    mtr
    ncdu
    tmux
  ];

Il est possible de modifier une dérivation⁵ existante pour utiliser une version différente, activer une fonctionnalité spécifique ou appliquer un correctif. Voici comment j'active et configure Nginx pour désactiver le module stream, ajouter le module de compression Brotli et ajouter le module d'anonymisation des adresses IP. De plus, au lieu d'utiliser OpenSSL 3, je continue à utiliser OpenSSL 1.1⁶.

services.nginx = {
  enable = true;

  package = (pkgs.nginxStable.override {
    withStream = false;
    modules = with pkgs.nginxModules; [
      brotli
      ipscrub
    ];
    openssl = pkgs.openssl_1_1;
  });

Si vous avez besoin d'ajouter certaines modifications, c'est également possible. À titre d'exemple, voici comment j'ai corrigé en avance les failles de sécurité découvertes en 2019 dans Nginx en attendant que cela soit corrigé dans NixOS⁷ :

services.nginx.package = pkgs.nginxStable.overrideAttrs (old: {
  patches = old.patches ++ [
    # HTTP/2: reject zero length headers with PROTOCOL_ERROR.
    (pkgs.fetchpatch {
      url = https://github.com/nginx/nginx/commit/dbdd[…].patch;
      sha256 = "a48190[…]";
    })
    # HTTP/2: limited number of DATA frames.
    (pkgs.fetchpatch {
      url = https://github.com/nginx/nginx/commit/94c5[…].patch;
      sha256 = "af591a[…]";
    })
    #  HTTP/2: limited number of PRIORITY frames.
    (pkgs.fetchpatch {
      url = https://github.com/nginx/nginx/commit/39bb[…].patch;
      sha256 = "1ad8fe[…]";
    })
  ];
});

Si cela vous intéresse, jetez un coup d'œil à ma configuration relativement réduite : common.nix contient la configuration à appliquer sur tous les serveurs (SSH, utilisateurs, paquets communs), web.nix contient la configuration pour les serveurs web et isso.nix exécute Isso dans un conteneur systemd.

NixOps : outil de déploiement pour NixOS

Sur un seul nœud, la configuration de NixOS se trouve dans le fichier /etc/nixos/configuration.nix. Après l'avoir modifiée, vous devez exécuter la commande nixos-rebuild switch. Nix va chercher toutes les dépendances possibles dans le cache binaire et construit le reste. Il crée une nouvelle entrée dans le menu du chargeur de démarrage et active la nouvelle configuration.

Pour gérer plusieurs nœuds, il existe plusieurs options, dont NixOps, deploy-rs, Colmena et morph. Je ne les connais pas toutes, mais de mon point de vue, les différences ne sont pas si importantes. Il est également possible de construire un tel outil soi-même car Nix fournit les blocs de construction les plus importants : nix build et nix copy. NixOps est l'un des premiers outils publiés mais je vous encourage à explorer les alternatives.

La configuration de NixOps est écrite avec le langage Nix. Voici une configuration simplifiée pour déployer znc01.luffy.cx, web01.luffy.cx et web02.luffy.cx, à l'aide des fonctions server et web :

let
  server = hardware: name: imports: {
    deployment.targetHost = "${name}.luffy.cx";
    networking.hostName = name;
    networking.domain = "luffy.cx";
    imports = [ (./hardware/. + "/${hardware}.nix") ] ++ imports;
  };
  web = hardware: idx: imports:
    server hardware "web${lib.fixedWidthNumber 2 idx}" ([ ./web.nix ] ++ imports);
in {
  network.description = "Luffy infrastructure";
  network.enableRollback = true;
  defaults = import ./common.nix;
  znc01 = server "exoscale" [ ./znc.nix ];
  web01 = web "hetzner" 1 [ ./isso.nix ];
  web02 = web "hetzner" 2 [];
}

Connecter le tout avec Nix

L'écosystème Nix est une solution unifiée aux différents problèmes liés à la gestion des logiciels et des configurations. Les environnements de développement déclaratifs et reproductibles en constituent une caractéristique très intéressante. Cela ressemble aux environnements virtuels de Python, mais ils ne sont pas spécifiques à un langage.

Courte introduction aux « flakes » Nix

J'utilise les « flakes », une nouvelle fonctionnalité de Nix qui améliore la reproductibilité en fixant toutes les dépendances et en isolant le processus de construction. Bien que cette fonctionnalité soit marquée comme expérimentale⁸, elle est de plus en plus populaire et vous pouvez trouver flake.nix et flake.lock à la racine de certains dépôts.

A titre d'exemple, voici le contenu du flake.nix livré avec Snimpy, un outil SNMP interactif pour Python reposant sur libsmi, une bibliothèque C :

{
  inputs = {
    nixpkgs.url = "nixpkgs";
    flake-utils.url = "github:numtide/flake-utils";
  };
  outputs = { self, ... }@inputs:
    inputs.flake-utils.lib.eachDefaultSystem (system:
      let
        pkgs = inputs.nixpkgs.legacyPackages."${system}";
      in
      {
        # nix build
        packages.default = pkgs.python3Packages.buildPythonPackage {
          name = "snimpy";
          src = self;
          preConfigure = ''echo "1.0.0-0-000000000000" > version.txt'';
          checkPhase = "pytest";
          checkInputs = with pkgs.python3Packages; [ pytest mock coverage ];
          propagatedBuildInputs = with pkgs.python3Packages; [ cffi pysnmp ipython ];
          buildInputs = [ pkgs.libsmi ];
        };
        # nix run + nix shell
        apps.default = { 
          type = "app";
          program = "${self.packages."${system}".default}/bin/snimpy";
        };
        # nix develop
        devShells.default = pkgs.mkShell {
          name = "snimpy-dev";
          buildInputs = [
            self.packages."${system}".default.inputDerivation
            pkgs.python3Packages.ipython
          ];
        };
      });
}

Si Nix est installé sur votre système :

• nix run github:vincentbernat/snimpy exécute Snimpy ;
• nix shell github:vincentbernat/snimpy fournit un shell avec Snimpy prêt à être utilisé ;
• nix build github:vincentbernat/snimpy construit le paquet Python ;
• nix develop . fournit un shell pour développer autour de Snimpy depuis un clône du dépôt⁹.

Pour plus d'informations sur les flakes, regardez le tutoriel de Tweag.

Nix et CDKTF

A la racine du dépôt que j'utilise pour CDKTF, il y a un fichier flake.nix pour configurer un shell avec Terraform et CDKTF installés et avec les variables d'environnement nécessaires pour automatiser mon infrastructure.

Terraform est déjà présent dans nixpkgs, mais je dois appliquer une rustine sur le fournisseur Gandi. Ce n'est pas un problème avec Nix !

terraform = pkgs.terraform.withPlugins (p: [
  p.aws
  p.hcloud
  p.vultr
  (p.gandi.overrideAttrs
    (old: {
      src = pkgs.fetchFromGitHub {
        owner = "vincentbernat";
        repo = "terraform-provider-gandi";
        rev = "feature/livedns-key";
        hash = "sha256-V16BIjo5/rloQ1xTQrdd0snoq1OPuDh3fQNW7kiv/kQ=";
      };
    }))
]);

CDKTF est écrit en TypeScript. J'ai un fichier package.json avec toutes les dépendances nécessaires, y compris celles pour utiliser TypeScript comme langage cible :

{
  "name": "cdktf-take1",
  "version": "1.0.0",
  "main": "main.js",
  "types": "main.ts",
  "private": true,
  "dependencies": {
    "@types/node": "^14.18.30",
    "cdktf": "^0.13.3",
    "cdktf-cli": "^0.13.3",
    "constructs": "^10.1.151",
    "eslint": "^8.27.0",
    "prettier": "^2.7.1",
    "ts-node": "^10.9.1",
    "typescript": "^3.9.10",
    "typescript-language-server": "^2.1.0"
  }
}

J'utilise Yarn pour obtenir un fichier yarn.lock qui peut ensuite être utilisé directement pour construire la dérivation contenant toutes les dépendances :

nodeEnv = pkgs.mkYarnModules {
  pname = "cdktf-take1-js-modules";
  version = "1.0.0";
  packageJSON = ./package.json;
  yarnLock = ./yarn.lock;
};

L'étape suivant est de générer les fournisseurs CDKTF à partir des fournisseurs Terraform et de les inclure dans une dérivation :

cdktfProviders = pkgs.stdenvNoCC.mkDerivation {
  name = "cdktf-providers";
  nativeBuildInputs = [
    pkgs.nodejs
    terraform
  ];
  src = nix-filter {
    root = ./.;
    include = [ ./cdktf.json ./tsconfig.json ];
  };
  buildPhase = ''
    export HOME=$(mktemp -d)
    export CHECKPOINT_DISABLE=1
    export DISABLE_VERSION_CHECK=1
    export PATH=${nodeEnv}/node_modules/.bin:$PATH
    ln -nsf ${nodeEnv}/node_modules node_modules

    # Build all providers we have in terraform
    for provider in $(cd ${terraform}/libexec/terraform-providers; echo */*/*/*); do
      version=''${provider##*/}
      provider=''${provider%/*}
      echo "Build $provider@$version"
      cdktf provider add --force-local $provider@$version | cat
    done
    echo "Compile TS → JS"
    tsc
  '';
  installPhase = ''
    mv .gen $out
    ln -nsf ${nodeEnv}/node_modules $out/node_modules
  '';
};

Enfin, nous définissons l'environnement de développement :

devShells.default = pkgs.mkShell {
  name = "cdktf-take1";
  buildInputs = [
    pkgs.nodejs
    pkgs.yarn
    terraform
  ];
  shellHook = ''
    # No telemetry
    export CHECKPOINT_DISABLE=1
    # No autoinstall of plugins
    export CDKTF_DISABLE_PLUGIN_CACHE_ENV=1
    # Do not check version
    export DISABLE_VERSION_CHECK=1
    # Access to node modules
    export PATH=$PWD/node_modules/.bin:$PATH
    ln -nsf ${nodeEnv}/node_modules node_modules
    ln -nsf ${cdktfProviders} .gen

    # Credentials
    for p in \
      njf.nznmba.pbz/Nqzvavfgengbe \
      urgmare.pbz/ivaprag@oreang.pu \
      ihyge.pbz/ihyge@ivaprag.oreang.pu; do
        eval $(pass show $(echo $p | tr 'A-Za-z' 'N-ZA-Mn-za-m') | grep '^export')
    done
    eval $(pass show personal/cdktf/secrets | grep '^export')
    export TF_VAR_hcloudToken="$HCLOUD_TOKEN"
    export TF_VAR_vultrApiKey="$VULTR_API_KEY"
    unset VULTR_API_KEY HCLOUD_TOKEN
  '';
};

Les dérivations listées dans buildInputs sont disponibles dans le shell fourni. Le contenu de shellHook est exécuté lors du démarrage du shell. Il établit des liens symboliques pour rendre disponible l'environnement JavaScript construit à une étape précédente, ainsi que les fournisseurs CDKTF générés. Il exporte également toutes les informations d'identification¹⁰.

J'utilise également direnv avec un fichier .envrc pour passer automatiquement dans l'environnement de développement. Cela permet également à ce dernier d'être disponible depuis Emacs, notamment lors de l'utilisation de lsp-mode pour obtenir les complétions. nix develop . permet aussi d'activer manuellement l'environnement.

J'utilise les commandes suivantes pour déployer¹¹ :

$ cdktf synth
$ cd cdktf.out/stacks/cdktf-take1
$ terraform plan --out plan
$ terraform apply plan
$ terraform output -json > ~-automation/nixops-take1/cdktf.json

La dernière commande produit un fichier JSON contenant les données nécessaires pour finir le déploiement avec NixOps.

NixOps

Le fichier JSON exporté par Terraform contient la liste des serveurs avec quelques attributs :

{
  "hardware": "hetzner",
  "ipv4Address": "5.161.44.145",
  "ipv6Address": "2a01:4ff:f0:b91::1",
  "name": "web05.luffy.cx",
  "tags": [
    "web",
    "continent:NA",
    "continent:SA"
  ]
}

Dans le fichier network.nix, cette liste est importée et transformée en un ensemble d'attributs décrivant les serveurs. Une version simplifiée ressemble à cela :

let
  lib = inputs.nixpkgs.lib;
  shortName = name: builtins.elemAt (lib.splitString "." name) 0;
  domainName = name: lib.concatStringsSep "." (builtins.tail (lib.splitString "." name));
  server = hardware: name: imports: {
    networking = {
      hostName = shortName name;
      domain = domainName name;
    };
    deployment.targetHost = name;
    imports = [ (./hardware/. + "/${hardware}.nix") ] ++ imports;
  };
  cdktf-servers-json = (lib.importJSON ./cdktf.json).servers.value;
  cdktf-servers = map
    (s:
      let
        tags-maybe-import = map (t: ./. + "/${t}.nix") s.tags;
        tags-import = builtins.filter (t: builtins.pathExists t) tags-maybe-import;
      in
      {
        name = shortName s.name;
        value = server s.hardware s.name tags-import;
      })
    cdktf-servers-json;
in
{
  // […]
} // builtins.listToAttrs cdktf-servers

Pour web05, on obtient ceci :

web05 = {
  networking = {
    hostName = "web05";
    domainName = "luffy.cx";
  };
  deployment.targetHost = "web05.luffy.cx";
  imports = [ ./hardware/hetzner.nix ./web.nix ];
};

Comme pour CDKTF, à la racine du dépôt que j'utilise pour NixOps, il y a un fichier flake.nix pour fournir un shell avec NixOps configuré. Comme NixOps ne supporte pas les déploiements progressifs, j'utilise généralement ces commandes pour déployer sur un unique serveur¹² :

$ nix flake update
$ nixops deploy --include=web04
$ ./tests web04.luffy.cx

Si les tests se déroulent sans soucis, je déploie les autres nœuds un par un avec la commande suivante :

$ (set -e; for h in web{03..06}; do nixops deploy --include=$h; done)

La commande nixops deploy déploie tous les serveurs en parallèle et peut donc provoquer une panne si tous les serveurs Nginx sont indisponibles au même moment.

Cet article est en chantier depuis trois ans. Le contenu a été mis à jour et affiné au fur et à mesure de mes expérimentations. Il y a encore beaucoup à explorer¹³, mais j'estime que le contenu est désormais suffisant pour être publié ! 🎄

Ce court article documente la façon dont je fais tourner Isso, le système de commentaires utilisé par ce blog, à l'intérieur d'un conteneur Docker sur NixOS, une distribution Linux construite sur Nix. Nix est un gestionnaire de paquets déclaratif pour Linux et d'autres systèmes Unix.

Bien que NixOS 20.09 intègre une dérivation pour Isso, elle est malheureusement cassée et repose sur Python 2. Comme j'utilise également un fork d'Isso, j'ai construit ma propre dérivation, fortement inspirée de celle dans master¹ :

issoPackage = with pkgs.python3Packages; buildPythonPackage rec {
  pname = "isso";
  version = "custom";

  src = pkgs.fetchFromGitHub {
    # Use my fork
    owner = "vincentbernat";
    repo = pname;
    rev = "vbe/master";
    sha256 = "0vkkvjcvcjcdzdj73qig32hqgjly8n3ln2djzmhshc04i6g9z07j";
  };

  propagatedBuildInputs = [
    itsdangerous
    jinja2
    misaka
    html5lib
    werkzeug
    bleach
    flask-caching
  ];

  buildInputs = [
    cffi
  ];

  checkInputs = [ nose ];

  checkPhase = ''
    ${python.interpreter} setup.py nosetests
  '';
};

Je veux faire tourner Isso via Gunicorn. À cet effet, je construis un environnement Python combinant Isso et Gunicorn. Je peux alors invoquer ce dernier avec "${issoEnv}/bin/gunicorn" à la manière d'un environnement Python virtuel

issoEnv = pkgs.python3.buildEnv.override {
    extraLibs = [
      issoPackage
      pkgs.python3Packages.gunicorn
      pkgs.python3Packages.gevent
    ];
};

Avant de construire une image Docker, je dois aussi définir le fichier de configuration d'Isso :

issoConfig = pkgs.writeText "isso.conf" ''
  [general]
  dbpath = /db/comments.db
  host =
    https://vincent.bernat.ch
    http://localhost:8080
  notify = smtp
  […]
'';

NixOS inclut un outil pratique permettant de construire une image Docker sans utiliser de Dockerfile :

issoDockerImage = pkgs.dockerTools.buildImage {
  name = "isso";
  tag = "latest";
  extraCommands = ''
    mkdir -p db
  '';
  config = {
    Cmd = [ "${issoEnv}/bin/gunicorn"
            "--name" "isso"
            "--bind" "0.0.0.0:${port}"
            "--worker-class" "gevent"
            "--workers" "2"
            "--worker-tmp-dir" "/dev/shm"
            "--preload"
            "isso.run"
          ];
    Env = [
      "ISSO_SETTINGS=${issoConfig}"
      "SSL_CERT_FILE=${pkgs.cacert}/etc/ssl/certs/ca-bundle.crt"
    ];
  };
};

Comme nous faisons référence à la dérivation issoEnv dans config.Cmd, toute la dérivation, y compris Isso et Gunicorn, est copiée à l'intérieur de l'image Docker. Il en va de même pour issoConfig, le fichier de configuration que nous avons créé précédemment, et pkgs.cacert, la dérivation contenant les certificats racines. L'image résultante pèse 171 Mo une fois installée, ce qui est comparable à l'image Debian Buster générée par le Dockerfile officiel.

NixOS dispose d'une abstraction pour déployer les conteneurs Docker. Elle n'est pas actuellement documentée dans le manuel de NixOS, mais vous pouvez consulter le code source du module pour connaître les options disponibles. J'ai choisi d'utiliser Podman au lieu de Docker comme moteur car cela évite d'avoir à lancer un démon supplémentaire.

virtualisation.oci-containers = {
  backend = "podman";
  containers = {
    isso = {
      image = "isso";
      imageFile = issoDockerImage;
      ports = ["127.0.0.1:${port}:${port}"];
      volumes = [
        "/var/db/isso:/db"
      ];
    };
  };
};

Un fichier de configuration pour systemd est automatiquement créé pour exécuter et superviser le conteneur :

$ systemctl status podman-isso.service
● podman-isso.service
     Loaded: loaded (/nix/store/a66gzqqwcdzbh99sz8zz5l5xl8r8ag7w-unit->
     Active: active (running) since Sun 2020-11-01 16:04:16 UTC; 4min 44s ago
    Process: 14564 ExecStartPre=/nix/store/95zfn4vg4867gzxz1gw7nxayqcl>
   Main PID: 14697 (podman)
         IP: 0B in, 0B out
      Tasks: 10 (limit: 2313)
     Memory: 221.3M
        CPU: 10.058s
     CGroup: /system.slice/podman-isso.service
             ├─14697 /nix/store/pn52xgn1wb2vr2kirq3xj8ij0rys35mf-podma>
             └─14802 /nix/store/7vsba54k6ag4cfsfp95rvjzqf6rab865-conmo>

nov. 01 16:04:17 web03 podman[14697]: container init (image=localhost/isso:latest)
nov. 01 16:04:17 web03 podman[14697]: container start (image=localhost/isso:latest)
nov. 01 16:04:17 web03 podman[14697]: container attach (image=localhost/isso:latest)
nov. 01 16:04:19 web03 conmon[14802]: INFO: connected to SMTP server
nov. 01 16:04:19 web03 conmon[14802]: INFO: connected to https://vincent.bernat.ch
nov. 01 16:04:19 web03 conmon[14802]: [INFO] Starting gunicorn 20.0.4
nov. 01 16:04:19 web03 conmon[14802]: [INFO] Listening at: http://0.0.0.0:8080 (1)
nov. 01 16:04:19 web03 conmon[14802]: [INFO] Using worker: gevent
nov. 01 16:04:19 web03 conmon[14802]: [INFO] Booting worker with pid: 8
nov. 01 16:04:19 web03 conmon[14802]: [INFO] Booting worker with pid: 9

Pour terminer, nous configurons Nginx pour qu'il transmette les requêtes à destination de comments.luffy.cx au conteneur. NixOS offre une intégration simple pour mettre en place un certificat géré par Let's Encrypt.

services.nginx.virtualHosts."comments.luffy.cx" = {
  root = "/data/webserver/comments.luffy.cx";
  enableACME = true;
  forceSSL = true;
  extraConfig = ''
    access_log /var/log/nginx/comments.luffy.cx.log anonymous;
  '';
  locations."/" = {
    proxyPass = "http://127.0.0.1:${port}";
    extraConfig = ''
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_set_header Host $host;
      proxy_set_header X-Forwarded-Proto $scheme;
      proxy_hide_header Set-Cookie;
      proxy_hide_header X-Set-Cookie;
      proxy_ignore_headers Set-Cookie;
    '';
  };
};
security.acme.certs."comments.luffy.cx" = {
  email = lib.concatStringsSep "@" [ "letsencrypt" "vincent.bernat.ch" ];
};

Bien que je rencontre encore des difficultés avec Nix et NixOS, je suis convaincu que c'est ainsi qu'une infrastructure déclarative doit être conçue. J'aime le fait d'avoir en un seul fichier contenant la dérivation pour construire Isso, la configuration, l'image Docker, la définition du conteneur et la configuration Nginx. Le langage Nix permet à la fois de construire des paquets et de gérer des configurations.

De plus, l'image Docker est mise à jour automatiquement comme un hôte NixOS normal. Cela résout un problème qui affecte l'écosystème Docker : plus d'images périmées ! Ma prochaine étape est de combiner cette approche avec Nomad, un orchestrateur pour déployer et gérer les conteneurs.