Sujet : provisioning
-
Fichiers de réponses Windows (unattend.xml) : passes de configuration et emplacements où Setup les recherche
Un fichier de réponses unattend.xml fournit des paramètres à des passes de configuration précises de Windows Setup ; windowsPE, generalize, specialize et oobeSystem sont celles que le provisionnement sollicite le plus. Setup trouve le fichier selon un ordre de recherche implicite fixe et le met en cache dans %WINDIR%\Panther ; Windows System Image Manager crée ces fichiers et peut masquer, sans les chiffrer, les mots de passe de comptes locaux.
-
Commandes ad-hoc Ansible et mode check : un premier passage sûr sur un parc de machines
Une commande `ansible` ad-hoc exécute un module sur un ou plusieurs hôtes sans playbook ; associée à `--check --diff` et à un `--limit` restreint, elle permet à un agent de voir l'effet d'une modification sur un parc avant de l'appliquer.
-
Généraliser une image Windows avec Sysprep : /generalize, /oobe, /shutdown et la limite de réarmement
Sysprep /generalize supprime d'une installation Windows les informations propres à l'ordinateur, comme le SID et les périphériques configurés, afin de pouvoir déployer l'image sur d'autres machines. Depuis Windows 8.1/Server 2012, Sysprep peut être exécuté jusqu'à 1001 fois par image (3 fois sous Windows 7/Server 2008 R2), et les échecs de généralisation laissent des traces dans les journaux Panther sous System32\Sysprep.
-
Régénérer les clés d'hôte SSH et le machine ID d'un hôte Linux cloné
Un hôte Linux fraîchement cloné doit disposer de ses propres clés d'hôte SSH et de son propre machine ID avant de rejoindre un parc ; ssh-keygen -A et systemd-machine-id-setup permettent de les créer, mais sur un clone déjà démarré, un machine ID dupliqué exige l'écriture d'une nouvelle valeur puis un redémarrage. Rechercher les doublons sur l'ensemble du parc est la seule vraie vérification que le clonage n'a pas simplement copié les mêmes identifiants partout.
-
Préparer une image de référence Linux pour le clonage : clés d'hôte, machine-id, journaux et configuration réseau
Une image Linux destinée à être clonée de nombreuses fois ne doit contenir ni /etc/machine-id renseigné (ni /var/lib/dbus/machine-id obsolète), ni clés d'hôte SSH existantes, ni configuration réseau liée à une adresse MAC, ni état cloud-init. Sinon, chaque clone démarre avec les mêmes identifiants que les autres, et supprimer les clés d'hôte sans mécanisme de régénération au premier démarrage prive les clones de SSH.
-
Décommissionner un serveur en toute sécurité : le retirer de tous les systèmes qui lui font encore confiance
Décommissionner un serveur ne se résume pas à l'éteindre : DNS, supervision, tâches de sauvegarde, fiche d'inventaire et tout objet ordinateur de l'annuaire continuent de lui faire confiance ou de l'attendre tant que personne ne l'en retire explicitement. Le stockage exige en outre une méthode d'effacement réellement adaptée au type de support avant réutilisation ou mise au rebut.
-
Construire des images machine avec Packer : builders, provisioners, validate et build
HashiCorp Packer sépare les builders d'un template (la plateforme qui produit l'image) de ses provisioners (la configuration de la machine avant sa capture). `packer init` installe les plugins requis, `packer validate` vérifie la syntaxe et la configuration d'un template avant que `packer build` ne l'exécute, et marquer les variables comme sensibles garde les identifiants hors des templates et des logs.
-
Debian preseed et Ubuntu autoinstall : deux formats d'installation automatisée, non interchangeables
L'installateur de Debian s'automatise avec un fichier preseed qui répond aux questions debconf, tandis qu'Ubuntu Server (20.04+) et Desktop (23.04+) utilisent le format YAML autoinstall de Subiquity, fourni sous forme de user-data cloud-init ou de fichier autoinstall.yaml sur le support d'installation. Les deux formats ne sont pas portables d'une distribution à l'autre et doivent être validés avant toute installation sans surveillance.
-
Agents de provisionnement Windows au premier démarrage dans le cloud : EC2Launch v2, Azure VM Agent et cloudbase-init
AWS, Azure et la plupart des autres clouds embarquent dans leurs images Windows un petit agent qui traite les user data ou custom data au premier démarrage ; les agents courants sont EC2Launch v2, les agents de provisionnement et Windows VM d'Azure (qui enregistrent les custom data dans CustomData.bin sans les exécuter) et l'agent open source cloudbase-init. Chacun journalise à un emplacement différent, à vérifier lorsque le provisionnement semble avoir échoué sans bruit.
-
Liste de vérification après provisionnement, avant la remise d'un serveur
Un serveur qui démarre n'est pas pour autant prêt à porter une charge de production. Cette liste donne à un agent un ordre fixe de contrôles (heure, résolution de noms, niveau de correctifs, supervision, inscription à la sauvegarde, accès, analyse de référence) à exécuter avant de déclarer terminé un hôte fraîchement provisionné.
-
Gestion de configuration ou création d'images : là où l'idempotence et la dérive font la différence
Les outils de gestion de configuration ramènent à chaque exécution un système en fonctionnement vers un état déclaré, alors que la création d'une image machine (baking) fige cet état une fois pour toutes au moment du build. L'idempotence rend la première approche sûre à répéter, et choisir entre baking et configuration au démarrage revient à choisir où la dérive est tolérée.
-
Nommer, étiqueter et inventorier un nouveau serveur : une méthodologie pour les noms d'hôte et l'inventaire
Un serveur provisionné sans nom cohérent, sans étiquettes indiquant son propriétaire et sa finalité, et sans entrée dans un inventaire devient de fait une infrastructure non documentée dès que son concepteur passe à autre chose. Cette méthodologie décrit comment définir le nom d'hôte sous Linux et Windows, et ce que doit contenir une fiche d'inventaire minimale.
-
Piloter cloud-init sur une instance Debian ou Ubuntu neuve : user-data, status --wait et relances sans risque
cloud-init applique le user-data une seule fois, au premier démarrage ; `cloud-init status --wait` bloque jusqu'à la fin de cette exécution pour qu'un script de provisionnement n'entre pas en concurrence avec elle, `cloud-init schema --system` détecte un fichier user-data invalide avant le prochain démarrage, et `cloud-init clean` est la méthode documentée pour forcer une réexécution complète lors des tests.
Lisible par machine : JSON