Chapitre 1 · 1.9
cloud-init personnalisé : configurer automatiquement votre VPS au premier démarrage
Avec cloud-init, vous fournissez lors de l'installation un fichier que votre VPS exécute lui-même au premier démarrage. Votre serveur installe ainsi immédiatement vos paquets habituels, crée votre propre utilisateur et exécute vos commandes. C'est pratique si vous réinstallez souvent ou si vous souhaitez toujours partir de la même base. Vous n'avez besoin ni d'API ni de terminal.
Où le saisir ?
- Ouvrez l'écran du VPS via Mes produits.
- Nouveau VPS : vous voyez le bloc Installez votre VPS (voir Installer votre VPS : système d'exploitation, mot de passe et clé SSH). Réinstallation : choisissez l'onglet Avancé et, sous Réinstallation, cliquez sur Réinstaller... (voir Réinstaller ou monter une ISO).
- Choisissez le système d'exploitation et saisissez le mot de passe root et, le cas échéant, votre clé SSH, comme d'habitude.
- Sous la clé SSH, cliquez sur cloud-init personnalisé. Le champ se déploie.
- Collez votre fichier dans le champ.
- Cliquez sur le bouton d'installation, par exemple Installer Debian 13, ou, en cas de réinstallation, sur Tout effacer et réinstaller.
Le mot de passe root ou la clé SSH reste nécessaire, même avec un cloud-init personnalisé. Ils vous permettent de toujours accéder au serveur, y compris via la console (voir La console : votre VPS dans votre navigateur).
Que peut contenir le fichier ?
Le champ accepte des user-data, le fichier que cloud-init lit au premier démarrage. La première ligne détermine de quoi il s'agit :
| Première ligne | De quoi s'agit-il ? |
|---|---|
#cloud-config | Des paramètres en YAML : paquets, utilisateurs, fichiers, commandes. C'est ce que vous utiliserez le plus souvent. |
#!, par exemple #!/bin/bash | Un script. Il s'exécute une seule fois en tant que root, à la fin du premier démarrage. |
#cloud-boothook | Un script qui s'exécute très tôt pendant le démarrage, et à nouveau à chaque démarrage. Réservé aux utilisateurs avancés. |
## template: jinja | Un modèle utilisant des variables de cloud-init. La ligne suivante contient alors #cloud-config ou #!. |
- 256 Ko maximum, et uniquement du texte (UTF-8).
- En YAML, l'indentation se fait avec des espaces, jamais avec des tabulations.
- Le réseau (IPv4 et IPv6) est géré par WebOké. Une network-config personnalisée n'est pas utilisée : n'y mettez donc aucun paramètre réseau.
Un exemple
Ce fichier met à jour tous les paquets, installe htop et fail2ban, crée l'utilisateur anna avec votre clé SSH et sudo, donne un nom personnalisé au serveur et règle le fuseau horaire :
#cloud-config
hostname: web1
fqdn: web1.example.com
package_update: true
package_upgrade: true
packages:
- htop
- fail2ban
users:
- default
- name: anna
shell: /bin/bash
sudo: "ALL=(ALL) NOPASSWD:ALL"
ssh_authorized_keys:
- ssh-ed25519 AAAAC3Nza... anna@laptop
runcmd:
- timedatectl set-timezone Europe/Amsterdam
Remplacez la clé par votre propre clé publique (voir Créer une clé SSH sous Windows, Mac et Linux). La ligne - default conserve l'utilisateur par défaut, afin que le mot de passe root et la clé SSH du formulaire continuent de fonctionner. Après le premier démarrage, connectez-vous avec ssh anna@203.0.113.10. Pour savoir comment désactiver ensuite la connexion en tant que root et configurer fail2ban, consultez Désactiver la connexion par mot de passe et en tant que root et fail2ban contre les tentatives de connexion par force brute.
Astuce : L'exemple est conçu pour Debian et Ubuntu. Sur AlmaLinux et Rocky Linux, htop et fail2ban se trouvent dans le dépôt supplémentaire EPEL. Supprimez-y packages et placez sous runcmd d'abord dnf install -y epel-release, puis dnf install -y htop fail2ban.
Que fournit WebOké de son côté ?
WebOké fournit toujours le nom d'hôte, le mot de passe root (uniquement sous forme de hash) et votre clé SSH. Votre fichier est fusionné avec ces éléments. Si vous définissez vous-même users, password, chpasswd ou ssh_authorized_keys, vos valeurs priment sur celles fournies par WebOké.
Attention : Si vous placez vous-même ssh_authorized_keys ou password au niveau supérieur de votre fichier, ils remplacent la clé et le mot de passe du formulaire. Indiquez alors vous-même la clé avec laquelle vous souhaitez vous connecter, sinon vous ne pourrez plus accéder au serveur que via la console.
Est-ce que cela a fonctionné ?
cloud-init s'exécute une seule fois, au premier démarrage après l'installation. Cela prend parfois quelques minutes de plus que l'installation elle-même, surtout si des paquets sont installés. Connectez-vous et vérifiez :
anna@web1:~$ cloud-init status --long
anna@web1:~$ sudo tail -n 30 /var/log/cloud-init-output.log
anna@web1:~$ sudo cloud-init schema --system
cloud-init status --longaffichestatus: donelorsque tout est terminé,runnings'il est encore en cours eterrorsi quelque chose s'est mal passé, avec l'erreur correspondante. Aveccloud-init status --wait, vous attendez qu'il ait terminé./var/log/cloud-init-output.logcontient la sortie de vos paquets, commandes et scripts. Vous trouverez plus de détails dans/var/log/cloud-init.log.cloud-init schema --systemvérifie que votre fichier ne contient pas d'erreurs. Si le YAML est incorrect, cloud-init ignore les parties qu'il ne comprend pas, sans que l'installation échoue.
Quelque chose s'est mal passé ? Corrigez-le manuellement sur le serveur, ou modifiez votre fichier et réinstallez. Attention toutefois : la réinstallation efface tout le contenu de votre VPS.
Bon à savoir
- Cela fonctionne avec tous les systèmes d'exploitation de la liste : Ubuntu 24.04 et 26.04, Debian 12 et 13, AlmaLinux 9 et 10 et Rocky Linux 9 et 10.
- Votre fichier est transmis de manière chiffrée et n'est pas conservé dans l'historique des tâches de votre VPS. N'y mettez toutefois pas de mots de passe ou d'autres secrets dont vous n'avez pas besoin.
- Toutes les possibilités sont décrites dans la documentation de cloud-init sur docs.cloud-init.io.
Attention : Le contenu de votre cloud-init relève de votre responsabilité. Le support n'examine pas votre fichier et ne vous aide pas à le rédiger ou à l'améliorer.
