Faites le travail de première installation avec cloud-init

Ce qui s'exécute, et quand

Chaque image Linux embarque cloud-init. Au premier démarrage, il lit les user-data attachés à votre commande, les applique une fois, puis écrit un marqueur pour ne plus jamais les réexécuter. Tout cela se produit avant que vous ayez pu taper quoi que ce soit, ce qui est le but : la fenêtre entre l'existence d'une instance et sa configuration est la fenêtre que vous ne devriez pas avoir.

Validez le document avant de commander. Le vérificateur de schéma détecte l'erreur d'indentation qui vous coûterait sinon une reconstruction :

cloud-init schema --config-file user-data.yaml --annotate

Des user-data qui font les choses utiles

#cloud-config
hostname: edge-01
fqdn: edge-01.example.com
timezone: UTC

users:
  - name: deploy
    groups: [sudo]
    shell: /bin/bash
    sudo: "ALL=(ALL) NOPASSWD:ALL"
    ssh_authorized_keys:
      - ssh-ed25519 AAAAC3Nza... deploy@laptop

ssh_pwauth: false
disable_root: true

package_update: true
package_upgrade: true
packages:
  - nftables
  - vnstat
  - mtr-tiny

write_files:
  - path: /etc/ssh/sshd_config.d/10-local.conf
    permissions: "0644"
    content: |
      PermitRootLogin no
      PasswordAuthentication no
      AllowUsers deploy

runcmd:
  - [systemctl, enable, --now, nftables]
  - [systemctl, restart, ssh]

La première ligne n'est ni un commentaire ni optionnelle. Sans #cloud-config, le document est ignoré en silence et l'instance démarre comme si vous n'aviez rien attaché.

Sur AlmaLinux, groups: [sudo] devient groups: [wheel] et le service à redémarrer est sshd. Tout le reste est identique.

Observer son fonctionnement

cloud-init status --long
journalctl -u cloud-final -b
less /var/log/cloud-init-output.log

Le journal vous indique quelle étape a échoué. cloud-init-output.log contient la sortie réelle de vos entrées runcmd, ce qui est l'endroit où se trouve la raison.

N'y mettez pas de secrets

Les user-data restent lisibles depuis l'intérieur de l'instance pendant toute sa durée de vie :

cloud-init query userdata

Tout ce qui s'y trouve est accessible à tout processus qui atteint root, et à quiconque restaure un snapshot du disque. Utilisez-les pour installer un identifiant qui récupère le secret, pas pour transporter le secret.

Tester sans brûler une instance

cloud-init clean --logs --reboot

Cela supprime le marqueur, les journaux et le cache de la source de données, puis redémarre dans un premier démarrage propre. Exécutez-le sur une instance jetable. Exécutez-le en production et vous découvrirez ce que fait votre runcmd la deuxième fois, ce qui est rarement ce qu'il a fait la première.

Où s'arrêter

cloud-init est conçu pour l'amorçage et n'a aucune idée de l'état que la machine devrait avoir demain. Utilisez-le pour atteindre le point où vos véritables outils de gestion peuvent prendre le relais : une clé, un réseau, un agent. Arrêtez-vous là. Soixante lignes, c'est un user-data sain, et six cents, c'est un système de gestion de configuration sans moyen de converger.

cloud-init query -a
cloud-init query ds.meta_data

L'ID d'instance, le code du site, le nom d'hôte et les adresses attribuées au démarrage s'y trouvent tous, ce dont un script a besoin lorsqu'il doit s'enregistrer quelque part sans encore savoir où il s'est réveillé.