Il y a quelques semaines, j'ai commencé à utiliser Ansible pour simplifier les tâches administratives des multiples organisations que je soutiens. De plus, je souhaitais surtout simplifier la gestion de ma propre flotte de huit ou neuf hosts (le nombre exact change fréquemment). J'ai fait toute mon automatisation à l'aide de scripts Bash depuis que j'ai commencé à utiliser Linux. J'ai utilisé des scripts pour automatiser la distribution d'autres scripts d'automatisation des mises à jour, des fichiers de configuration système et utilisateur, des mises à niveau vers les nouvelles versions de Fedora et des mises à jour vers les nouvelles versions de Fedora. Et cela n'inclut pas toutes ces petites tâches ad hoc qui surviennent sur ce qui semble être une base horaire.
Les scripts continueront à jouer un rôle essentiel dans mon automatisation administrative. Cependant, Ansible semble pouvoir prendre en charge de nombreuses tâches et les faire bien mieux que même des scripts complexes. Tout tourne autour du playbook , et dans cet article, j'en crée un qui peut effectuer une mise à jour du système tout en tenant compte des différences système.
J'ai récemment écrit sur Mon premier jour d'utilisation d'Ansible. Si vous n'avez pas lu cet article, vous voudrez peut-être le faire avant de continuer avec celui-ci. Cet article suppose que vous avez une connaissance très basique de l'utilisation d'Ansible. Si vous avez lu mon article sur le lien ci-dessus, vous devriez pouvoir suivre ce texte sans difficulté.
Cet article est divisé en deux parties, alors assurez-vous de lire la seconde moitié. Dans cette section, nous allons définir certains concepts et termes Ansible importants, discuter des commentaires et implémenter la première partie du playbook. La deuxième partie continue avec les deux jeux restants, quelques informations de suivi et ma liste de ressources.
Le playbook de cet article ne nécessite pas l'installation de modules ou de collections Ansible au-delà de ceux intégrés par défaut. Ce playbook a été testé avec Ansible 2.9.14.
[ Les lecteurs ont également aimé : Ajouter un référentiel et installer un package à la manière d'Ansible ]
Qu'est-ce qu'un playbook ?
Pendant que j'écrivais cet article, je regardais également certaines sessions de l'AnsibleFest virtuel de cette année. Pendant que je regardais, j'ai développé ma propre description d'un livre de jeu - une qui a du sens pour moi. Cette description contient des extraits de sagesse de plusieurs présentateurs, ainsi que des livres et des articles de blog que j'ai lus.
Voici ma définition :
Un playbook Ansible est une description créée par l'homme de l'état souhaité d'un ou plusieurs ordinateurs. Ansible lit le playbook, compare l'état réel des ordinateurs avec l'état spécifié dans le playbook et exécute les tâches nécessaires pour amener ces ordinateurs à se conformer à l'état décrit dans le playbook.
Mises à jour
L'installation de mises à jour sur des hôtes Linux modernes est une tâche quasi constante, rendue importante par le nombre de correctifs de sécurité et d'améliorations de fonctionnalités qui sortent en permanence. Si certains logiciels, tels que le noyau, glibc ou systemd sont mis à jour, l'hôte doit également être redémarré. Certaines tâches supplémentaires doivent également être effectuées, telles que la mise à jour de la base de données des pages de manuel.
Bien que j'aie des installations de mise à jour automatisées avec un script sympa, certains de mes hôtes doivent être traités un peu différemment des autres. Par exemple, je ne souhaite pas mettre à jour simultanément mon pare-feu et mon serveur de messagerie/web/DHCP/DNS. Si le serveur redémarre, le pare-feu ne peut pas obtenir les informations dont il a besoin pour procéder à ses propres mises à jour, et les autres hôtes de mon réseau non plus. Si le pare-feu tombe en panne, l'accès aux référentiels Fedora externes est perdu pour mon serveur et tous les autres hôtes internes. Cela signifie attendre que ces deux hôtes redémarrent avant que les mises à jour puissent commencer sur les autres hôtes.
J'avais donc l'habitude de faire ces mises à jour en démarrant les scripts sur le pare-feu, puis en attendant qu'il se termine, puis en passant au serveur et en attendant qu'il se termine avant d'exécuter un petit programme en ligne de commande pour exécuter le script de mise à jour en séquence sur le reste de mes hôtes. J'aurais pu écrire ces dépendances dans mes scripts, mais mes premiers jours avec Ansible m'ont montré qu'il avait déjà ces capacités et bien d'autres qui rendraient ma tâche beaucoup plus simple. Vraiment - BEAUCOUP plus simple. Et globalement plus rapide, sans intervention de ma part.
La stratégie Ansible
Ansible utilise une stratégie de hub pour gérer les hôtes. Le logiciel Ansible est installé sur l'hôte qui agit en tant que contrôleur. Le logiciel Ansible côté client n'existe pas, il n'est donc pas nécessaire d'en installer sur les hôtes distants.
Ansible utilise SSH, qui est déjà installé par presque toutes les distributions Linux, pour communiquer avec des hôtes distants. Bien que les administrateurs système puissent choisir d'utiliser des mots de passe pour l'accès à distance aux hôtes, cela réduit certainement l'efficacité et la nature non interventionniste d'un outil comme Ansible. Ainsi, comme la plupart des autres administrateurs, j'utilise des paires de clés publiques/privées (PPKP), qui sont considérées comme plus sûres que les mots de passe et permettent l'automatisation des tâches pour un à des milliers d'hôtes distants sans intervention de l'administrateur.
Ansible envoie des commandes aux hôtes distants via SSH et utilise les résultats pour déterminer le succès de la commande. Il peut également utiliser ces résultats pour déterminer le prochain plan d'action à l'aide de la condition quand déclarations.
Définir les exigences
Comme tout programme, qu'il soit écrit en C, Python, Bash ou tout autre langage, je commence toujours par un ensemble d'exigences. Vous avez lu mon livre, The Linux Philosophy for SysAdmins, n'est-ce pas ? Cela est également vrai pour des outils comme Ansible. Je dois définir où je vais afin de pouvoir identifier quand je suis arrivé.
Voici les exigences pour mon playbook Ansible :
Jeu 1 :Manette Ansible
- Tout d'abord, installez les mises à jour sur le nœud de contrôle Ansible.
- Mettre à jour la base de données des pages de manuel.
- Éteignez si nécessaire. Ceci est différent pour mon nœud de contrôle que pour les autres hôtes en raison d'une carte mère étrange qui ne redémarre pas correctement.
- Connectez-vous après le redémarrage et relancez le playbook. Étant donné que le nœud de contrôle est déjà dans l'état souhaité, aucune autre action ne sera entreprise et la lecture 2 commencera.
Jeu 2 : Serveurs
- Installez les mises à jour sur les pare-feu et les serveurs en série, c'est-à-dire une à la fois.
- Mettre à jour la base de données des pages de manuel.
- Redémarrer si nécessaire.
- Attendez que le premier hôte redémarre, si nécessaire, avant de commencer le suivant.
Jeu 3 :Stations de travail
- Ne commencez pas à mettre à jour les postes de travail tant que les serveurs ne sont pas terminés.
- Installez les mises à jour sur chaque ordinateur fonctionnant simultanément en parallèle.
- Mettre à jour la base de données des pages de manuel.
- Redémarrer si nécessaire.
Oui, je sais qu'il y a d'autres façons de le faire. J'ai pensé à faire le contrôleur Ansible en dernier afin de ne pas avoir à redémarrer le playbook après le redémarrage du contrôleur. Mais la façon dont je fais les choses est de faire d'abord des mises à jour sur mon poste de travail principal, qui est également mon nœud de contrôle Ansible, puis de faire des tests avant de mettre à jour le reste des systèmes, donc cette stratégie fonctionne parfaitement pour cela. Vos besoins seront probablement différents des miens, vous devez donc utiliser la méthode qui vous convient le mieux. La particularité d'Ansible est qu'il est suffisamment flexible pour répondre à différents besoins.
Maintenant que j'ai les conditions requises pour une tâche, je peux commencer le playbook.
Syntaxe
Les playbooks Ansible doivent être conformes à la syntaxe et au formatage YAML standard. Les erreurs les plus fréquentes que j'ai rencontrées sont mes propres erreurs de formatage. Cela est généralement dû au fait que j'ai utilisé ou non des tirets au début, ou que j'ai utilisé la mauvaise indentation.
Les noms de jeu commencent dans la première colonne du livre de jeu, et chaque tâche suivante est mise en retrait par exactement deux espaces . Exactement deux espaces indentent chaque action dans une tâche, et les sous-tâches sont en outre indentées d'exactement deux espaces. Tout autre nombre d'espaces ou l'utilisation de tout espace blanc autre que les espaces, tels que les tabulations, générera une erreur d'exécution. Un espace blanc supplémentaire à la fin d'une ligne génère également une erreur.
Vous ferez des erreurs de formatage et apprendrez rapidement à voir les problèmes. Il existe des outils que je peux utiliser pour nous aider à localiser ces erreurs avant d'essayer d'exécuter des playbooks, et ils peuvent faire gagner beaucoup de temps à long terme.
Démarrer le playbook
Commençons donc un playbook qui effectuera ces tâches dans l'ordre requis. Les playbooks sont simplement des collections de tâches qui définissent l'état souhaité d'un hôte. Un nom d'hôte ou un groupe d'inventaire est spécifié au début du playbook et définit les hôtes sur lesquels Ansible exécutera le playbook.
Notre playbook contiendra trois jeux pour gérer chaque type d'hôte que j'ai identifié dans l'énoncé des exigences. Chaque lecture aura une logique un peu différente mais produira le même résultat :un ou plusieurs hôtes avec toutes les mises à jour installées.
Mon playbook s'appelle doUpdates.yml et se trouve dans le répertoire /root/ansible/Updates répertoire, que j'ai créé pour ce projet. Le programme Bash installé par les parties de ce playbook se trouve dans le répertoire /root/ansible/Updates/files répertoire.
Explorons ce manuel une section à la fois.
Définir ceci comme un fichier YAML
Je commence tout mon code avec des commentaires bien structurés afin que le nom du fichier et une courte description de ce playbook existent pour moi-même ou pour un autre administrateur système à l'avenir. Les playbooks peuvent contenir des commentaires, même si j'ai vu peu d'articles ou de livres qui en font mention.
En tant qu'administrateur système qui croit en la nécessité de tout documenter, je trouve que les commentaires peuvent être très utiles. Il ne s'agit pas tant de dire les mêmes choses dans les commentaires que dans le nom de la tâche, mais plutôt d'identifier le but des groupes de tâches et de s'assurer que j'enregistre mes raisons de faire certaines choses d'une certaine manière ou Commande. Cela peut aider à résoudre des problèmes de débogage à une date ultérieure lorsque j'aurais peut-être oublié ma pensée initiale. Comme dans Bash, les commentaires commencent par un # .
La fonction principale de cette première section est les trois tirets (--- ) qui sont utilisés pour le définir en tant que fichier YAML. Le yml l'extension sur le nom de fichier signifie YAML. J'ai vu quelques significations pour cela, mais mon pari est sur "Encore un autre langage de balisage", malgré le fait que j'ai vu certaines affirmations selon lesquelles YAML n'en est pas un.
########################################################################
# doUpdates.yml
#------------------------------------------------------------------
# This playbook installs all available RPM updates on the inventory hosts.
#
#
#------------------------------------------------------------------
#
# Change History
# Date Name Version Description
# 2020/10/01 David Both 00.00 Started new code
# 2020/10/10 David Both 01.00 First release code finished
# 2020/10/18 David Both 01.01 Minor changes to sequence and
# fix a couple minor problems.
#
########################################################################
--- La première pièce
Cette section suivante définit le premier jeu dans le playbook. Les playbooks peuvent avoir un ou plusieurs jeux, et le nôtre en a trois :un pour l'hôte de contrôle sur lequel Ansible est exécuté, un pour les deux serveurs de mon réseau et un pour le reste des postes de travail. Ensuite, je définis le premier jeu - après tout, c'est un playbook.
Notez que le jeu commence dans la colonne zéro, puis il y a une indentation stricte des lignes restantes dans le jeu. Aucun énoncé ne définit le début de la pièce. Ansible utilise la structure YAML rigide pour déterminer où commence chaque jeu et chaque tâche.
########################################################################
#######################################################################
# Play 1 - Do updates for host david
########################################################################
########################################################################
- name: Play 1 - Install updates on david - the Ansible controler
hosts: david
remote_user: root
vars:
run: false
reboot: false Nous rencontrerons fréquemment différents mots-clés, alors voici quelques explications que j'aurais aimé avoir lorsque j'ai commencé à travailler avec Ansible.
nom :Cette ligne est le nom de la lecture, et le nom de la lecture est affiché dans le flux de données STDOUT. Cela facilite l'identification de chaque jeu qui s'exécute pour garder une trace pendant que je regarde ou visualise le flux redirigé plus tard. Le mot-clé est requis pour chaque jeu et tâche, mais le contenu textuel est facultatif.
hôtes :Cela définit les noms d'hôtes sur lesquels le jeu sera exécuté. Il peut contenir une liste de noms d'hôtes séparés par des espaces ou le nom d'un groupe d'hôtes. Le groupe d'hôtes et les noms de tous les hôtes répertoriés doivent apparaître dans le fichier d'inventaire. Par défaut, c'est /etc/ansible/hosts mais peut être un autre fichier tant que vous utilisez le -i (--inventory ) option pour spécifier le fichier alternatif.
utilisateur_distant :Cette ligne n'est pas obligatoire, mais elle spécifie l'utilisateur sous lequel Ansible agira sur l'hôte distant. Si l'utilisateur sur l'hôte distant est le même que l'utilisateur sur l'hôte local, cette ligne n'est pas nécessaire. Par défaut, Ansible utilise le même ID utilisateur sur l'hôte distant que l'utilisateur qui exécute le playbook Ansible. Je l'utilise ici simplement à titre informatif. J'exécute la plupart des playbooks en tant que root sur l'hôte local, donc Ansible se connecte à l'hôte distant en tant que root.
vars :Cette section peut être utilisée pour définir une ou plusieurs variables, qui peuvent être utilisées comme dans n'importe quel langage de programmation. Dans ce cas, je les utilise dans des instructions conditionnelles "quand" plus tard dans le playbook pour contrôler le chemin d'exécution.
La portée des variables est limitée à la section dans laquelle elles sont définies. Dans ce cas, ils sont définis dans le jeu 1, ils sont donc limités à ce jeu. Si je veux les utiliser dans des jeux ultérieurs, je devrai les redéfinir dans chaque jeu dans lequel ils sont requis. Si une variable est définie dans une tâche, elle n'est disponible que dans cette tâche et pas dans le reste de cette partie.
Les valeurs variables peuvent être remplacées sur la ligne de commande en utilisant le -e (--extra_variables ) option pour spécifier une valeur différente. Nous verrons cela quand il sera temps d'exécuter le playbook.
Les tâches
C'est le début de la section des tâches pour le jeu 1. La tâche :le mot-clé est indenté d'exactement deux espaces. Chaque tâche doit avoir un nom déclaration, même s'il n'y a pas de texte pour le nom. Le texte facilite le suivi de la logique du playbook et s'affiche à l'écran pendant l'exécution pour m'aider à suivre la progression en temps réel.
tasks:
########################################################################
# Do some preliminary checking
########################################################################
- name: Install the latest version of the doUpdates script
copy:
src: /root/ansible/Updates/files/doUpdates
dest: /usr/local/bin
mode: 0774
owner: root
group: root
- name: Check for currently available updates
command: doUpdates -c
register: check
- debug: var=check.stdout_lines Cette première section contient trois tâches. La première tâche copie un programme Bash que j'ai écrit sur l'hôte cible. La seconde exécute le programme qui vient d'être installé et attribue (enregistre) le flux de données STDOUT à partir de doUpdates programme à la variable "vérifier". La troisième tâche imprime toutes les lignes STDOUT de la variable de contrôle à l'écran.
Examinons les nouveaux mots clés un peu plus en détail :
copier :Le mot-clé copy définit le début d'une strophe qui peut copier un ou plusieurs fichiers à partir d'un emplacement source spécifié (src ) vers un emplacement cible spécifié (dest ). Les mots clés de cette section définissent divers aspects de l'opération de copie et l'état final du fichier copié.
src :Il s'agit du chemin complet et du nom du fichier à copier. Dans ce cas, je ne vais copier qu'un seul fichier, mais il est facile de copier tous les fichiers d'un répertoire ou uniquement ceux qui correspondent à un modèle global de fichier. Le fichier source est généralement stocké dans un emplacement de l'arborescence de répertoires du concentrateur Ansible. Dans ce cas, le chemin complet vers mon fichier source se trouve dans /root/ansible/Updates/files/doUpdates .
dest :Il s'agit du chemin de destination sur le ou les hôtes cibles dans lesquels le fichier source sera copié.
mode :Le mot-clé mode définit le mode de fichier qui sera appliqué au fichier copié. Quel que soit le mode de fichier du fichier source, Ansible définira le mode de fichier sur celui spécifié dans cette instruction. Par exemple, rwxr_xr__ ou 0754 . Assurez-vous d'utiliser les quatre octets lorsque vous utilisez le format octal.
propriétaire :Il s'agit du compte propriétaire qui sera appliqué au fichier.
groupe :Il s'agit du compte de groupe qui sera appliqué au fichier.
commande :Toute commande shell Linux, script shell ou programme de ligne de commande avec des options et des arguments peut être utilisé avec ce mot-clé. J'ai utilisé le programme Bash qui vient d'être installé pour obtenir des informations difficiles à obtenir à l'aide des éléments intégrés Ansible, tels que dnf .
s'inscrire :Ce mot clé définit le STDOUT de la commande spécifiée ci-dessus dans une variable nommée "check". Le quand : mot clé peut interroger le contenu de cette variable. Il est ensuite utilisé comme conditionnel pour déterminer si la tâche dont il fait partie sera exécutée. Nous verrons cela dans la section suivante.
déboguer :imprime le contenu de la variable spécifiée à l'écran. Je l'utilise fréquemment comme outil de débogage. Je trouve cela utile pour le débogage. Indice, indice.
Maintenant un peu sur mes doUpdates Programme bash.
J'ai initialement écrit ce programme Bash pour effectuer les mises à jour que j'ai commencé à faire avec Ansible. Il contient du code qui détermine si des mises à jour sont disponibles. Il détermine également si le noyau, systemd ou glibc ont été mis à jour, chacun d'entre eux devant nécessiter un redémarrage pour prendre pleinement effet. Mon programme émet quelques lignes vers STDOUT que je peux utiliser dans Ansible comme conditionnel pour décider de redémarrer l'hôte cible. Je l'utilise dans cette section suivante, qui effectue les mises à jour réelles, et la suivante effectue une mise hors tension de mon poste de travail principal. Un code similaire effectue un redémarrage sur tous les autres hôtes, comme vous le verrez.
Le STDOUT de ce programme utilisé avec le -c L'option ressemble à ceci lorsque des mises à jour sont disponibles, mais un redémarrage n'est pas nécessaire. Je peux utiliser une expression régulière pour rechercher n'importe quel texte dans ce flux de données pour les chaînes de clés, qui peuvent être utilisées dans un lorsque :conditionnel pour déterminer si une tâche spécifique est effectuée.
TASK [debug] ******************************************************************************************************************************************
ok: [wally1] => {
"check.stdout_lines": [
"########## 48 updates ARE available for host wally1.both.org. ##########",
"########## Including: ##########",
"Last metadata expiration check: 1:47:12 ago on Tue 20 Oct 2020 01:50:07 PM EDT.",
"Updates Information Summary: available",
" 3 Security notice(s)",
" 2 Moderate Security notice(s)",
" 3 Bugfix notice(s)",
" 2 Enhancement notice(s)",
" 2 other notice(s)",
"########## A reboot will NOT be required after these updates are installed. ##########",
"Program terminated normally"
]
}
Cette section suivante immédiatement au-dessus effectue les mises à jour réelles si toutes les conditions dans le quand :déclaration sont vraies. Cette section utilise le dnf Ansible intégré gestionnaire de paquets.
########################################################################
# Do the updates.
########################################################################
# Install all available updates
- name: Install all current updates
dnf:
name: "*"
state: latest
when: (check.stdout | regex_search('updates ARE available')) and run == "true"
nf :Appelle le module intégré Ansible qui s'interface avec le gestionnaire de packages DNF. Bien qu'un peu limité dans ses capacités, il peut installer, supprimer et mettre à jour des packages. Une des limitations du module DNF est qu'il ne dispose pas du check-update une fonction. Par conséquent, je continue à utiliser mon programme Bash pour découvrir la liste des packages à mettre à jour et à partir de là, déterminer si un redémarrage (ou une mise hors tension) doit être effectué. Ansible intègre également YUM et APT.
nom :Fournit le nom du package sur lequel opérer. Dans ce cas, le caractère global du fichier * indique tous les packages installés.
état :La valeur "latest" pour ce mot-clé indique que tous les packages installés doivent être mis à niveau vers la version la plus récente. Certaines des autres options d'état sont "présent", ce qui signifie que le package est installé mais pas nécessairement la dernière version, et "absent", ce qui signifie supprimer le package s'il est installé.
quand :Cette expression conditionnelle spécifie les conditions qui doivent être remplies pour que cette tâche s'exécute. Dans ce cas, les mises à jour ne seront installées que lorsque la chaîne de texte définie dans l'expression régulière est présente dans la variable "check" précédemment enregistrée et que la variable "run" est définie sur "true".
Maintenant que les mises à jour ont été effectuées, je devrai peut-être redémarrer, alors voyons comment je peux gérer cela. La tâche suivante le fait pour nous.
Tout d'abord, j'ai un peu de documentation via des commentaires, qui décrit que j'ai effectué une mise hors tension plutôt qu'un redémarrage pour cet hôte en raison d'un problème matériel potentiel. C'est un exemple parfait de la raison pour laquelle nous devrions inclure des commentaires dans notre code et nos playbooks, car ils expliquent pourquoi ce jeu particulier est nécessaire et pourquoi il est différent des autres. C'est aussi un excellent exemple de la façon dont je peux traiter un hôte différemment des autres.
########################################################################
# Now poweroff host david because of MB problems that won't let it
# do a reboot without manual intervention. Need to see if I
# can figure out this problem and fix it but it is a hardware issue
# and this is just a temporary circumvention.
########################################################################
- name: Poweroff this host if necessary and reboot extra variable is true
command: poweroff
when: (check.stdout | regex_search('reboot will be required')) and reboot == "true" and run == "true"
Dans cette tâche, j'envoie le poweroff commande au lieu de l'action préférée de redémarrage de l'ordinateur. Je le fais pour la raison indiquée dans les commentaires :parce que la carte mère de mon poste de travail principal, qui est également mon hub Ansible, ne redémarre pas correctement. Cela est probablement dû à une mauvaise configuration de ma part plutôt qu'à tout type de dysfonctionnement. Je n'en ai pas encore découvert la raison car je trouve que le temps que j'ai déjà passé à rechercher et à modifier la configuration du BIOS a dépassé ma limite de tolérance, et je dois faire le travail. De temps en temps, j'y travaille un peu plus, mais cela ne vaut plus le temps supplémentaire.
L'exécution du playbook s'arrête après cette mise hors tension (ou redémarre si votre périphérique concentrateur Ansible redémarre correctement), de sorte que je dois le redémarrer une fois qu'il est finalement redémarré. Cette fois, parce que les mises à jour ont été installées, la mise hors tension ou le redémarrage ne se produit pas, et la lecture suivante est lancée.
Et ceci conclut la première partie.
[ Besoin d'en savoir plus sur Ansible ? Suivez un cours de présentation technique gratuit de Red Hat. Ansible Essentials :Présentation technique de la simplicité dans l'automatisation. ]
Conclusion
Nous avons couvert beaucoup d'informations ici et j'espère qu'une explication solide des mots-clés et des tâches a été utile. Mon opinion sur les commentaires est également claire :ils sont critiques. Play 1 lance notre playbook Ansible.
Dans la deuxième partie de cet article, nous conclurons le playbook avec deux jeux supplémentaires pour gérer le pare-feu et les serveurs, puis le reste des hôtes sur le réseau. Je fournirai également quelques détails et concepts de suivi.