Fai il lavoro di prima accensione con cloud-init

Cosa viene eseguito, e quando

Ogni immagine Linux include cloud-init. Al primo avvio legge i user-data allegati al tuo ordine, li applica una volta e scrive un marcatore in modo che non venga mai più eseguito. Tutto ciò avviene prima che tu possa aver digitato qualsiasi cosa, che è il punto: la finestra tra l'esistenza di un'istanza e la sua configurazione è la finestra che non dovresti avere.

Valida il documento prima di ordinare. Il controllo dello schema rileva l'errore di indentazione che altrimenti ti costerebbe una ricostruzione:

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

Un user-data che fa le cose utili

#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 prima riga non è né un commento né opzionale. Senza #cloud-config il documento viene ignorato silenziosamente e l'istanza si avvia come se non avessi allegato nulla.

Su AlmaLinux, groups: [sudo] diventa groups: [wheel] e il servizio da riavviare è sshd. Tutto il resto è identico.

Osservarlo funzionare

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

Il journal ti dice quale fase è fallita. cloud-init-output.log contiene l'output effettivo delle tue voci runcmd, che è dove si trova il motivo.

Non metterci segreti

I user-data rimangono leggibili dall'interno dell'istanza per tutta la sua vita:

cloud-init query userdata

Qualsiasi cosa lì dentro è disponibile a qualsiasi processo che raggiunge root, e a chiunque ripristini uno snapshot del disco. Usalo per installare una credenziale che recupera il segreto, non per trasportare il segreto.

Testare senza bruciare un'istanza

cloud-init clean --logs --reboot

Questo rimuove il marcatore, i log e la datasource cache, poi si riavvia in un primo avvio pulito. Eseguilo su un'istanza usa e getta. Eseguilo in produzione e scoprirai cosa fa il tuo runcmd la seconda volta, che raramente è ciò che ha fatto la prima.

Dove fermarsi

cloud-init è per il bootstrap e non ha idea dello stato in cui la macchina dovrebbe essere domani. Usalo per raggiungere il punto in cui i tuoi strumenti reali possono prendere il controllo: una chiave, una rete, un agente. Fermati lì. Sessanta righe sono un user-data sano, e seicento sono un sistema di gestione della configurazione senza un modo per convergere.

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

L'ID dell'istanza, il codice del sito, l'hostname e gli indirizzi assegnati al boot vivono tutti lì, che è ciò di cui uno script ha bisogno quando deve registrarsi da qualche parte e non sa ancora dove si è svegliato.