cloud-init

J'ai commencé à utiliser Debian en juin 2001 avec la version 2.2 Potato. J'ai découvert fin 2004 le projet Ubuntu porté par l'entreprise Canonical et ça m'a tout de suite plu. En avril 2005, j'ai migré avec la version Ubuntu 5.04 Hoary Hedgehog.

Je trouvais cela incroyable qu'un milliardaire, Mark Shuttleworth, lui-même développeur Debian, investisse une grande partie de sa fortune dans le Linux Desktop.

J'étais adepte de Canonical : j'utilisais et promouvais Bazaar, Launchpad, puis Upstart en 2006.

À cette époque, j'aurais rêvé de travailler chez Canonical que j'admirais, mais je n'ai pas tenté ma chance : mon niveau d'anglais ne le permettait pas.

Ma confiance en Canonical a commencé à basculer vers 2012-2013. Je constatais qu'ils étaient seuls à coder Unity sans contribuer à GNOME Shell, à maintenir Upstart alors que systemd gagnait du terrain. La polémique autour de Dash fin 2012 a ajouté au malaise. Mais le vrai point de bascule a été en 2013, quand Canonical a décidé de lancer Mir de son côté et d'abandonner Wayland.

Voici les projets de Canonical qui n'ont pas réussi à s'imposer :

• Bazaar : outil de gestion de versions distribué pour le développement logiciel

  • Projet alternatif devenu mainstream : Git
  • Lancement : 26 mars 2005
  • Date mainstream Git : 7 avril 2005 (premier commit) ; adoption massive ~2008-2010
  • Mort : Dernière release stable 2016 ; support Launchpad totalement arrêté le 1er septembre 2025

• Upstart : système d'init pour Linux, remplaçant SysV

  • Projet alternatif devenu mainstream : systemd
  • Lancement : 24 août 2006 (Ubuntu 6.10)
  • Date mainstream systemd : 6 juillet 2010 (version 1) ; adoption massive ~2014-2015
  • Mort : Annonce d'abandon le 14 février 2014 ; remplacé effectivement dans Ubuntu 15.04 (avril 2015)

• Mir : serveur d'affichage graphique pour le desktop Linux

  • Projet alternatif devenu mainstream : Wayland
  • Lancement : Annoncé le 4 mars 2013
  • Date mainstream Wayland : 30 septembre 2008 ; adoption par GNOME, KDE ~2015-2017
  • Mort (desktop) : 5 avril 2017 (reconverti ensuite vers l'IoT/embarqué, toujours maintenu dans ce créneau)

• Unity : environnement de bureau pour Ubuntu

  • Projet alternatif devenu mainstream : GNOME Shell
  • Lancement : ~2010 (Ubuntu 10.10 Netbook Edition, puis 11.04 desktop)
  • Date mainstream GNOME Shell : 6 avril 2011 (GNOME 3.0)
  • Mort : 5 avril 2017

• Snap : système de packaging universel pour Linux

  • Projet alternatif devenu mainstream : Flatpak
  • Lancement : 2014-2016 (lancé avec Ubuntu Core/16.04)
  • Date mainstream Flatpak : mars 2015 (sous le nom xdg-app), renommé mai 2016 ; adoption par Fedora ~2016-2018
  • Toujours actif en 2026 (coexiste avec Flatpak)

Hors d'Ubuntu, seul cloud-init a réussi à s'imposer.

Dans la communauté du logiciel libre, une critique revient souvent sur Canonical, celle de garder la mainmise sur ses projets, d'utiliser un projet comme levier pour renforcer l'adoption de ses autres projets, et de freiner les contributions avec des CLA restrictifs comme le Canonical Contributor Agreement. C'est un constat que je partage. Je pense que ces pratiques, qui rendent les projets non conviviaux au sens d'Ivan Illich, expliquent en grande partie pourquoi ils échouent. Canonical n'a pas le savoir-faire de Red Hat pour construire une communauté qui porte un projet.

C'est triste à dire, mais depuis ce constat, j'en suis venu à penser qu'adopter un projet porté par Canonical, c'est parier sur le mauvais cheval. Depuis 2014, je ne m'intéresse plus du tout à leurs projets.

Cette note fait partie de la série de notes : "J'ai étudié et testé CoreOS et je suis tombé dans un rabbit hole 🙈".

Note précédente : "Système de mise à jour d'Android, Chrome OS, MacOS et MS Windows".

---

Première version de CoreOS Container Linux en 2013

La première version de CoreOS Container Linux sortie en 2013 utilisé la méthode A/B (seamless) system updates inspirée de manière transparente à Chrome OS :

Upgrading CoreOS is a bit different than the usual distros. Our update system is based on ChromeOS. The big difference is that we have two root partitions; lets call them root A and root B. Initially your system is booted into the root A partition and CoreOS begins talking to the update service to find out about new updates. If there is an update available it is downloaded and installed to root B.

source

D'après ce repository coreos/coreos-overlay, CoreOS Container Linux était basé sur les packages de Gentoo.

---

Première version d'Ignition en 2016

En avril 2016, l'équipe CoreOS a publié la première version de ignition, outil toujours utilisé en 2025 par Fedora CoreOS.

Ignition is a utility created to manipulate disks during the initramfs. This includes partitioning disks, formatting partitions, writing files (regular files, systemd units, etc.), and configuring users. On first boot, Ignition reads its configuration from a source of truth (remote URL, network metadata service, hypervisor bridge, etc.) and applies the configuration.

source

ignition est un système qui ressemble à cloud-init, mais qui est exécuté seulement une seule fois, lors du premier boot et est lancé en tout premier, avant même systemd.

Depuis 2019, les fichiers json ignition ne sont plus édités manuellement grâce à l'outil butane qui convertit des fichiers YAML butane en fichiers json ignition.

Voici la documentation de butane qui vous permet de voir les actions que peut effectuer ignition : https://coreos.github.io/butane/specs/.

À la différence de cloud-init, ignition fonctionne à un niveau plus bas. La spec Butane Fedora CoreOS v1.6.0 permet par exemple de configurer les partitions, le Raid, LUKS encryption…

Voici dans mon playground un exemple de son utilisation : atomic-os-playground/create-coreos-custom-iso.sh.

---

Note suivante : "2014-2018 approche alternative avec Atomic Project".

Je viens de publier le playground suivant : qemu-fedora-workstation-playground.

Je suis particulièrement satisfait d'avoir mis en place ce playground, car il concrétise plusieurs objectifs que je m'étais fixés depuis longtemps :

• Cela fait plusieurs années que je souhaite à remplacer Vagrant par une solution plus minimaliste. Je souhaite réduire mon utilisation d'outils basés sur Ruby.
  J'ai, par exemple, effectué une tentative en février 2023 basée sur virsh.
• Utiliser une VM Fedora Workstation pour tester ma configuration dotfiles basée sur chezmoi :
  • Par exemple ici
  • et ici : How do you test your configuration on a bare OS? Docker? Distrobox? Vagrant?

Finalement, la solution était assez simple à mettre en place et elle est très performante.

Ma VM Fedora Workstation affiche l'écran d'ouverture de session GNOME Display Manager en moins de 19s.

Voici une traduction en français de qemu-fedora-workstation-playground.

Voici les dépendances à installer :

$ sudo dnf install -y \
    qemu-system-x86 \
    qemu-system-common \
    qemu-img \
    qemu-img-extras \
    cloud-utils \
    mesa-dri-drivers \
    libguestfs-tools

Pour simplifier, la méthode que je présente est basée uniquement sur QEMU.

Je télécharge la version 41 de Fedora dans sa version "cloud" :

$ wget https://download.fedoraproject.org/pub/fedora/linux/releases/41/Cloud/x86_64/images/Fedora-Cloud-Base-Generic-41-1.4.x86_64.qcow2 -O fedora-41-base.qcow2

À partir de cette image de base, je crée une image de type couche (layer) que j'utilise pour effectuer mes opérations sur la machine virtuelle. Cette approche me permet de revenir facilement en arrière (rollback) en cas de problème, annulant ainsi les modifications apportées à la VM.

$ qemu-img create -f qcow2 -b fedora-41-base.qcow2 -F qcow2 fedora-working-layer.qcow2
$ ls -s1h *.qcow2
469M fedora-41-base.qcow2
196K fedora-working-layer.qcow2

Je prépare un fichier cloud-init qui permet de configurer le mot de passe et ma clé SSH :

$ cat <<'EOF' > cloud-init.yaml
#cloud-config
users:
  - name: fedora
    plain_text_passwd: password
    lock_passwd: false
    shell: /bin/bash
    sudo: ALL=(ALL) NOPASSWD:ALL
    ssh_authorized_keys:
      - ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQDEzyNFlEuHIlewK0B8B0uAc9Q3JKjzi7myUMhvtB3JmA2BqHfVHyGimuAajSkaemjvIlWZ3IFddf0UibjOfmQH57/faxcNEino+6uPRjs0pFH8sNKWAaPX1qYqOFhB3m+om0hZDeQCyZ1x1R6m+B0VJHWQ3pxFaxQvL/K+454AmIWB0b87MMHHX0UzUja5D6sHYscHo57rzJI1fc66+AFz4fcRd/z+sUsDlLSIOWfVNuzXuGpKYuG+VW9moiMTUo8gTE9Nam6V2uFwv2w3NaOs/2KL+PpbY662v+iIB2Yyl4EP1JgczShOoZkLatnw823nD1muC8tYODxVq7Xf7pM/NSCf3GPCXtxoOEqxprLapIet0uBSB4oNZhC9h7K/1MEaBGbU+E2J5/5hURYDmYXy6KZWqrK/OEf4raGqx1bsaWcONOfIVXbj3zXTUobsqSkyCkkR3hJbf39JZ8/6ONAJS/3O+wFZknFJYmaRPuaWiLZxRj5/gw01vkNVMrogOIkQtzNDB6fh2q27ghSRkAkM8EVqkW21WkpB7y16Vzva4KSZgQcFcyxUTqG414fP+/V38aCopGpqB6XjnvyRorPHXjm2ViVWbjxmBSQ9aK0+2MeKA9WmHN0QoBMVRPrN6NBa3z20z1kMQ/qlRXiDFOEkuW4C1n2KTVNd6IOGE8AufQ== contact@stephane-klein.info
ssh_pwauth: true
EOF
$ cloud-localds cloud-init.img cloud-init.yaml

Lancement de la VM avec :

• accélération graphique
• configuration d'une interface réseau virtuelle avec la redirection d'un port ssh
• partage d'un dossier entre l'hôte et la VM

$ qemu-system-x86_64 \
    -m 8G \
    -smp 4 \
    -enable-kvm \
    -drive file=fedora-working-layer.qcow2,format=qcow2 \
    -device virtio-vga-gl \
    -display gtk,gl=on \
    -nic user,hostfwd=tcp::2222-:22 \
    -drive file=cloud-init.img,format=raw \
    -fsdev local,id=fsdev0,path=$(pwd)/shared/,security_model=mapped-file \
    -device virtio-9p-pci,fsdev=fsdev0,mount_tag=host_share

Cette VM est accessible via ssh, comme avec Vagrant :

$ ssh-keygen -R "[localhost]:2222"
$ ssh -o StrictHostKeyChecking=no -p 2222 fedora@localhost
Warning: Permanently added '[localhost]:2222' (ED25519) to the list of known hosts.
[fedora@localhost ~]$

Et voici comment à partir de la VM je peux monter le dossier partagé :

[fedora@localhost ~]$ sudo mkdir -p /mnt/host_share
[fedora@localhost ~]$ sudo mount -t 9p -o trans=virtio,version=9p2000.L host_share /mnt/host_share
[fedora@localhost ~]$ ls /mnt/host_share/ -lha
total 0
drwxr-xr-x. 1 fedora fedora 16 Mar  9 11:44 .
drwxr-xr-x. 1 root   root   20 Mar  9 11:45 ..
-rw-r--r--. 1 fedora fedora  0 Mar  9 11:44 .gitkeep

J'ai ensuite lancé les commandes suivantes pour installer les packages pour avoir une Fedora Workstation :

$ sudo localectl set-keymap fr-bepo # J'utilise un clavier Bépo
$ sudo dnf update -y
$ sudo dnf install -y @gnome-desktop @workstation-product gnome-session-wayland-session
$ sudo systemctl set-default graphical.target
$ sudo reboot

Et voici le résultat :

Je vais pouvoir intégrer cette méthode à https://github.com/stephane-klein/dotfiles afin de développer et tester mes scripts d'installation chezmoi dans un environnement contrôlé et reproductible, garantissant un comportement déterministe. Desktop configuration as code 🙂.

Le qemu-fedora-workstation-playground contient des scripts pour automatiser les opérations présentées :

• /scripts/up.sh
• /scripts/enter-in-vm.sh
• /scripts/setup-shared-folder.sh
• /scripts/install-vm-workstation.sh

Je pense que cette méthode pourra remplacer Vagrant dans plusieurs de mes projets.