cloud-init est le standard de fait pour initialiser des instances cloud lors de leur premier démarrage. Quand vous lancez une instance et lui passez un script user-data, c’est cloud-init qui l’interprète et l’exécute : il crée des utilisateurs, écrit des fichiers, installe des paquets, monte des disques ou démarre des services.
La combinaison idéale est claire : la golden AMI contient ce qui ne change pas —système d’exploitation, runtime, durcissement— et user-data apporte ce qui varie selon l’environnement ou l’instance : configuration, secrets injectés, rôle. Vous réutilisez ainsi une seule image dans de nombreux contextes.
Deux façons d’écrire user-data
user-data accepte plusieurs formats ; les deux plus courants sont le script shell et le cloud-config.
- Script shell : commence par
#!/bin/bash. Simple et direct pour des tâches rapides. - cloud-config : commence par
#cloud-configet utilise du YAML déclaratif. Plus propre, lisible et idempotent pour configurer utilisateurs, paquets, fichiers et commandes.
Exemple de cloud-config
Un #cloud-config typique déclare des sections comme packages: (paquets à installer),
write_files: (fichiers de configuration), runcmd: (commandes finales) et users:
(comptes et clés). Étant déclaratif, il est plus facile à relire et à maintenir qu’un
long script.
Bonnes pratiques
- Gardez user-data court : s’il grossit trop, cela devrait probablement être intégré dans l’AMI.
- Idempotence : concevez les commandes pour que les réexécuter ne casse rien.
- Ne mettez jamais de secrets en clair dans user-data : c’est lisible depuis les métadonnées de l’instance. Injectez-les depuis Secrets Manager, Parameter Store ou Vault à l’exécution.
- Protégez l’accès aux métadonnées : utilisez IMDSv2 pour limiter le vol d’identifiants via SSRF.
- Journalisez et déboguez : les logs de cloud-init
(
/var/log/cloud-init-output.log) sont votre meilleur ami quand quelque chose échoue.
Baking ou booting : où mettre quoi
| Va dans l’AMI (baking) | Va dans user-data (booting) |
|---|---|
| Système d’exploitation et correctifs | Configuration spécifique à l’environnement |
| Runtime, agents et durcissement | Variables et paramètres par instance |
| Logiciels stables et lourds | Enregistrement dans le cluster et découverte |
| Tout ce qui est long à installer | Injection de secrets à l’exécution |
Règle d’or : ce qui est stable et lent se cuit ; ce qui est variable et léger passe au démarrage.
Erreurs courantes qui coûtent des heures
- Mettre dans user-data ce qui devrait être dans l’image, d’où des démarrages lents et fragiles.
- Exposer des secrets en clair dans les métadonnées.
- Supposer que user-data se réexécute à chaque démarrage : par défaut, il ne tourne qu’au premier.
- Ne pas consulter les logs de cloud-init quand l’instance « ne fait pas ce qu’elle devrait ».
Questions fréquentes
user-data s’exécute-t-il à chaque redémarrage ?
Par défaut, seulement au premier démarrage. On peut configurer cloud-init pour exécuter certaines parties à chaque démarrage, mais il vaut mieux le faire sciemment et de manière idempotente.
Est-il sûr de passer des mots de passe dans user-data ?
Non. user-data est lisible depuis les métadonnées de l’instance. Utilisez un gestionnaire de secrets et injectez-les à l’exécution, et protégez les métadonnées avec IMDSv2.
cloud-init ne fonctionne-t-il que sur AWS ?
Non. cloud-init est multiplateforme et fonctionne sur AWS, Azure, GCP et d’autres, ce qui en fait un outil idéal pour automatiser le démarrage de façon portable.
Chez imaxe.cloud, nous concevons des images pensées pour se combiner à cloud-init, afin qu’une seule AMI vous serve dans de nombreux scénarios.
