Une introduction aux scripts Cloud-Config

Le programme + cloud-init + disponible sur les distributions récentes (uniquement Ubuntu 14.04 et CentOS 7 au moment de l’écriture) est capable de consommer et d’exécuter des données depuis le champ + user-data + du https: // www.digitalocean.com/community/tutorials/an-inintroduction-to-droplet-metadata[DigitalOcean service de métadonnées]. Ce processus se comporte différemment en fonction du format des informations trouvées. L’un des formats les plus populaires pour les scripts dans + user-data + est le format de fichier * cloud-config *.

Les fichiers cloud-config sont des scripts spéciaux conçus pour être exécutés par le processus cloud-init. Celles-ci sont généralement utilisées pour la configuration initiale au tout premier démarrage d’un serveur. Dans ce guide, nous discuterons du format et de l’utilisation des fichiers cloud-config.

Le format + cloud-config + implémente une syntaxe déclarative pour de nombreux éléments de configuration courants, facilitant ainsi la réalisation de nombreuses tâches. Il vous permet également de spécifier des commandes arbitraires pour tout ce qui ne relève pas des capacités déclaratives prédéfinies.

Cette approche du «meilleur des deux mondes» permet au fichier de se comporter comme un fichier de configuration pour les tâches courantes, tout en conservant la souplesse d’un script pour des fonctionnalités plus complexes.

Pour définir de nouveaux utilisateurs sur le système, vous pouvez utiliser la directive + utilisateurs + que nous avons vue dans le fichier exemple ci-dessus.

Le format général des définitions d’utilisateurs est:

Chaque nouvel utilisateur devrait commencer par un tiret. Chaque utilisateur définit des paramètres dans des paires clé-valeur. Les clés suivantes sont disponibles pour la définition:

Outre des informations de base, telles que la clé + nom +, il vous suffit de définir les zones dans lesquelles vous déviez de la valeur par défaut ou fournissez les données nécessaires.

Les utilisateurs doivent comprendre que les champs + passwd + ne doivent * pas * être utilisés dans les systèmes de production, à moins que vous ne disposiez d’un mécanisme pour modifier immédiatement la valeur donnée. Comme pour toutes les informations soumises en tant que données utilisateur, le hachage restera accessible à * tout * utilisateur du système pendant toute la durée de vie du serveur. Sur du matériel moderne, ces hachages peuvent facilement être craqués en un laps de temps trivial. Exposer même le hasch est un énorme risque de sécurité qui ne devrait pas être pris sur des machines qui ne sont pas jetables.

Pour un exemple de définition d’utilisateur, nous pouvons utiliser une partie de l’exemple + cloud-config + ci-dessus:

Pour définir des groupes, vous devez utiliser la directive + groups +. Cette directive est relativement simple dans la mesure où elle nécessite simplement une liste des groupes que vous souhaitez créer.

Une extension optionnelle à ceci est de créer une sous-liste pour n’importe lequel des groupes que vous créez. Cette nouvelle liste définira les utilisateurs qui doivent être placés dans ce groupe:

Pour les comptes utilisateur existants (le compte + root + est le plus pertinent), un mot de passe peut être fourni à l’aide de la directive + chpasswd +.

La syntaxe de base ressemble à ceci:

La directive contient deux clés de tableau associatif. La clé + list + contiendra un bloc qui liste les noms de compte et les mots de passe associés que vous souhaitez attribuer. La clé + expire + est un booléen qui détermine si le mot de passe doit être changé au premier démarrage ou non. La valeur par défaut est «True».

Une chose à noter est que vous pouvez définir un mot de passe sur “RANDOM” ou “R”, ce qui générera un mot de passe aléatoire et l’écrira dans + / var / log / cloud-init-output.log +. Gardez à l’esprit que ce fichier est accessible à tout utilisateur du système, il n’est donc plus sécurisé.

Afin d’écrire des fichiers sur le disque, vous devriez utiliser la directive + write_files +.

Chaque fichier devant être écrit est représenté par un élément de liste sous la directive. Ces éléments de liste seront des tableaux associatifs qui définissent les propriétés de chaque fichier.

Les seules clés requises dans ce tableau sont + path +, qui définit l’emplacement où écrire le fichier, et + content +, qui contient les données que vous souhaitez que le fichier contienne.

Les clés disponibles pour configurer un élément + write_files + sont les suivantes:

Par exemple, nous pourrions écrire un fichier sur + / test.txt + avec le contenu:

La partie du + cloud-config + qui accomplirait ceci ressemblerait à ceci:

Pour gérer les packages, gardez à l’esprit quelques paramètres et directives connexes.

Pour mettre à jour la base de données apt sur les distributions basées sur Debian, vous devez définir la directive + package_update + sur «true». Ceci est synonyme d’appeler + apt-get update depuis la ligne de commande.

La valeur par défaut est "true", vous n’avez donc à vous soucier de cette directive que si vous souhaitez la désactiver:

Si vous souhaitez mettre à niveau tous les packages sur votre serveur après le démarrage initial, vous pouvez définir la directive + package_upgrade +. Cela ressemble à une + apt-get upgrade + exécutée manuellement.

Ceci est défini sur "false" par défaut, alors assurez-vous de le définir sur "true" si vous souhaitez que la fonctionnalité:

Pour installer des packages supplémentaires, vous pouvez simplement lister les noms de package à l’aide de la directive “packages”. Chaque élément de la liste doit représenter un paquet. Contrairement aux deux commandes ci-dessus, cette directive fonctionnera avec les distributions gérées ou bien gérées par apt.

Ces articles peuvent prendre l’une des deux formes suivantes. Le premier est simplement une chaîne avec le nom du paquet. La seconde forme est une liste avec deux éléments. Le premier élément de cette nouvelle liste est le nom du package et le second élément est le numéro de version:

La directive “packages” définira + apt_update + sur true, remplaçant tout paramètre précédent.

Vous pouvez gérer les clés SSH dans la directive + users +, mais vous pouvez également les spécifier dans une section + ssh_authorized_keys + dédiée. Ceux-ci seront ajoutés au fichier registered_keys du premier utilisateur défini.

Cela prend le même format général de la spécification de clé dans la directive + utilisateurs +:

Vous pouvez également générer les clés privées du serveur SSH à l’avance et les placer sur le système de fichiers. Cela peut être utile si vous voulez donner à vos clients les informations sur ce serveur au préalable, ce qui lui permettra de faire confiance au serveur dès sa mise en ligne.

Pour ce faire, nous pouvons utiliser la directive + ssh_keys +. Cela peut prendre les paires de clés pour les clés RSA, DSA ou ECDSA en utilisant les sous-éléments + rsa_private +, + rsa_public +, '+ dsa_private + ,' + dsa_public +, et + + ecdsa_public + `.

Étant donné que le formatage et les sauts de ligne sont importants pour les clés privées, veillez à utiliser un bloc avec une touche de canal lorsque vous les spécifiez. De plus, vous * devez * inclure les lignes de clé début et fin pour que vos clés soient valides.

Si votre infrastructure repose sur des clés signées par une autorité de certification interne, vous pouvez configurer vos nouvelles machines pour faire confiance à votre cert de CA en injectant les informations du certificat. Pour cela, nous utilisons la directive + ca-certs +.

Cette directive comporte deux sous-éléments. Le premier est + remove-defaults +, qui, lorsqu’il est défini sur true, supprimera toutes les informations de confiance de certificat normales incluses par défaut. Cela n’est généralement pas nécessaire et peut entraîner des problèmes si vous ne savez pas ce que vous faites, utilisez-le avec prudence.

Le deuxième élément est + Trusted +, qui est une liste, chacune contenant un certificat d’autorité de certification approuvé:

Si vous avez configuré vos propres serveurs DNS que vous souhaitez utiliser, vous pouvez gérer le fichier resolv.conf de votre serveur en utilisant la directive + resolv_conf +. Cela ne fonctionne actuellement que pour les distributions basées sur RHEL.

Sous la directive + resolv_conf +, vous pouvez gérer vos paramètres avec les éléments + nameservers +, + searchdomains +, + domain + et + options +.

La directive + nameservers + devrait prendre une liste des adresses IP de vos serveurs de noms. La directive + searchdomains + prend une liste de domaines et de sous-domaines dans lesquels effectuer la recherche lorsqu’un utilisateur spécifie un hôte mais pas un domaine.

+ Domain + définit le domaine devant être utilisé pour toutes les demandes non résolues, et + options + contient un ensemble d’options pouvant être définies dans le fichier resolv.conf.

Si vous utilisez la directive + resolv_conf +, vous devez vous assurer que la directive + manage-resolv-conf + est également définie sur true. Si vous ne le faites pas, vos paramètres seront ignorés:

Si aucune des actions gérées fournies par + cloud-config + ne fonctionne comme vous le souhaitez, vous pouvez également exécuter des commandes arbitraires. Vous pouvez le faire avec la directive + runcmd +.

Cette directive prend une liste d’éléments à exécuter. Ces éléments peuvent être spécifiés de deux manières différentes, ce qui affectera leur traitement.

Si l’élément de liste est une simple chaîne, l’intégralité de l’élément sera transmise au processus de shell + sh + à exécuter.

L’autre option consiste à transmettre une liste dont chaque élément sera exécuté de la même manière que les commandes + execve +. Le premier élément sera interprété comme la commande ou le script à exécuter et les éléments suivants seront transmis en tant qu’arguments pour cette commande.

La plupart des utilisateurs peuvent utiliser l’un ou l’autre de ces formats, mais la flexibilité vous permet de choisir la meilleure option si vous avez des exigences particulières. Toute sortie sera écrite dans la sortie standard et dans le fichier + / var / log / cloud-init-output.log +:

Dans certains cas, vous souhaiterez arrêter ou redémarrer votre serveur après avoir exécuté les autres éléments. Vous pouvez le faire en configurant la directive + power_state +.

Cette directive comporte quatre sous-éléments pouvant être définis. Ce sont + delay,` + timeout`, + message et` + mode + `.

Le + delay + spécifie combien de temps à l’avenir le redémarrage ou l’arrêt devrait avoir lieu. Par défaut, ce sera «maintenant», ce qui signifie que la procédure commencera immédiatement. Pour ajouter un délai, les utilisateurs doivent spécifier, en minutes, la durée devant passer à l’aide du format ++ <num_of_mins> +.

Le paramètre + timeout + prend une valeur sans unité qui représente le nombre de secondes à attendre pour que cloud-init se termine avant d’initier le compte à rebours + delay +.

Le champ + message + vous permet de spécifier un message qui sera envoyé à tous les utilisateurs du système. Le + mode + spécifie le type d’événement de puissance à initier. Cela peut être «mettre hors tension» pour éteindre le serveur, «redémarrer» pour le redémarrer, ou «arrêter» pour laisser le système décider quelle est la meilleure action à prendre (généralement un arrêt):

Les exemples ci-dessus représentent certains des éléments de configuration les plus courants disponibles lors de l’exécution d’un fichier + cloud-config +. Il existe des fonctionnalités supplémentaires que nous n’avons pas abordées dans ce guide. Celles-ci incluent la configuration de la gestion de la configuration, la configuration de référentiels supplémentaires et même l’enregistrement avec une URL externe lors de l’initialisation du serveur.

Vous pouvez en savoir plus sur certaines de ces options en consultant le répertoire + / usr / share / doc / cloud-init / examples +. Pour un guide pratique vous aidant à vous familiariser avec les fichiers + cloud-config +, vous pouvez suivre notre tutoriel à l’adresse https://www.digitalocean.com/community/tutorials/how-to-use-cloud-config-for- your-initial-server-setup [comment utiliser cloud-config pour compléter la configuration de base du serveur] ici.