cloud-init è lo standard di fatto per inizializzare le istanze in cloud durante il primo avvio. Quando lanci un’istanza e le passi uno script di user-data, è cloud-init a interpretarlo ed eseguirlo: crea utenti, scrive file, installa pacchetti, monta dischi o avvia servizi.
La combinazione ideale è chiara: la golden AMI contiene ciò che non cambia —sistema operativo, runtime, hardening— e user-data porta ciò che varia per ambiente o per istanza: configurazione, segreti iniettati, ruolo. Così riutilizzi una sola immagine in molti contesti.
Due modi di scrivere user-data
user-data accetta vari formati; i due più comuni sono lo script di shell e il cloud-config.
- Script di shell: inizia con
#!/bin/bash. Semplice e diretto per compiti rapidi. - cloud-config: inizia con
#cloud-confige usa YAML dichiarativo. Più pulito, leggibile e idempotente per configurare utenti, pacchetti, file e comandi.
Esempio di cloud-config
Un tipico #cloud-config dichiara sezioni come packages: (pacchetti da installare),
write_files: (file di configurazione), runcmd: (comandi finali) e users: (account e
chiavi). Essendo dichiarativo, è più facile da rivedere e mantenere di uno script lungo.
Buone pratiche
- Tieni user-data piccolo: se cresce troppo, probabilmente andrebbe cotto nella AMI.
- Idempotenza: progetta i comandi in modo che rieseguirli non rompa nulla.
- Non mettere mai segreti in chiaro in user-data: è leggibile dai metadati dell’istanza. Iniettali da Secrets Manager, Parameter Store o Vault a runtime.
- Proteggi l’accesso ai metadati: usa IMDSv2 per mitigare il furto di credenziali via SSRF.
- Registra e debugga: i log di cloud-init (
/var/log/cloud-init-output.log) sono il tuo miglior amico quando qualcosa fallisce.
Baking o booting: dove mettere ogni cosa
| Va nella AMI (baking) | Va in user-data (booting) |
|---|---|
| Sistema operativo e patch | Configurazione specifica dell’ambiente |
| Runtime, agenti e hardening | Variabili e parametri per istanza |
| Software stabile e pesante | Registrazione nel cluster e discovery |
| Tutto ciò che è lento da installare | Iniezione di segreti a runtime |
Regola d’oro: ciò che è stabile e lento si cuoce; ciò che è variabile e leggero va all’avvio.
Errori comuni che costano ore
- Mettere in user-data ciò che dovrebbe stare nell’immagine, con avvii lenti e fragili.
- Esporre segreti in chiaro nei metadati.
- Supporre che user-data si rieseguo a ogni avvio: di default gira solo al primo.
- Non guardare i log di cloud-init quando l’istanza «non fa quello che dovrebbe».
Domande frequenti
user-data si esegue a ogni riavvio?
Di default solo al primo avvio. Si può configurare cloud-init per eseguire certe parti a ogni avvio, ma conviene farlo in modo consapevole e idempotente.
È sicuro passare password in user-data?
No. user-data è leggibile dai metadati dell’istanza. Usa un gestore di segreti e iniettali a runtime, e proteggi i metadati con IMDSv2.
cloud-init funziona solo su AWS?
No. cloud-init è multipiattaforma e funziona su AWS, Azure, GCP e altri, il che lo rende ideale per automatizzare l’avvio in modo portabile.
In imaxe.cloud progettiamo immagini pensate per combinarsi con cloud-init, così che una sola AMI ti serva in molti scenari.
