J'ai décidé de rationaliser mon processus de mise à jour pour les systèmes clients que je prends en charge ainsi que pour mes propres appareils Linux. Alors qu'une série de scripts complexes m'ont bien servi pendant longtemps, les avantages d'utiliser Ansible pour cette tâche sont tout simplement trop nombreux pour être ignorés.
Dans la première partie de cette série d'articles, j'ai discuté du processus de mise à jour proprement dit, établi la structure de mon playbook et présenté des mots-clés et des commentaires. Le playbook contient trois pièces. Chaque jeu gère une catégorie de systèmes. Play 1 gère mon contrôleur Ansible (mon poste de travail principal), tandis que Plays 2 et 3 gèrent les serveurs et tous les postes de travail restants.
Commençons ce deuxième article en examinant la deuxième pièce.
La deuxième pièce
Voici l'intégralité de la deuxième pièce. Le but de ce jeu est d'effectuer des mises à jour sur le pare-feu et le serveur.
Le pare-feu doit être opérationnel pendant que les serveurs (et tous les autres hôtes) sont mis à jour afin qu'ils puissent avoir accès à Internet pour télécharger les packages de mise à jour. Le serveur doit fonctionner pendant que le pare-feu et les autres hôtes sont mis à jour pour fournir des services DHCP et de noms. Pour ce faire, ce jeu met à jour ces deux hôtes un par un.
Les noms de ces deux hôtes sont contenus dans le [all_servers] groupe dans le /etc/ansible/hosts fichier d'inventaire.
#######################################################################
#######################################################################
# Play 2 - Do servers
#######################################################################
#######################################################################
- name: Play 2 - Install updates for servers yorktown and wally
hosts: all_servers
serial: 1
remote_user: root
vars:
run: false
reboot: false
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
#######################################################################
# 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"
- name: Update the man database
command: mandb
when: run
- name: Reboot if necessary and reboot extra variable is true
reboot:
when: (check.stdout | regex_search('reboot will be required')) and reboot == "true" and run == "true" [ Vous pourriez également aimer : Une introduction à Ansible Tower ]
Toute cette deuxième pièce est presque la même que la première, à l'exception de deux lignes.
série :Cette instruction supplémentaire indique à Ansible d'exécuter cette lecture sur un hôte à la fois, c'est-à-dire en série plutôt qu'en parallèle. Si tous_les_serveurs groupe dans l'inventaire contenait dix serveurs, je pouvais utiliser une limite plus élevée, par exemple deux, afin que ce jeu soit exécuté contre deux serveurs à la fois. Dans ce cas, j'ai besoin de wally , le pare-feu, doit être opérationnel afin que yorktown serveur a accès à Internet pour télécharger les packages mis à jour. Peu importe la séquence de mise à jour de ces deux hôtes tant qu'ils ne sont pas effectués simultanément.
redémarrer :Ansible a une capacité de redémarrage intégrée, de sorte que nous pouvons l'utiliser dans ce jeu au lieu de la commande Linux poweroff. La caractéristique essentielle de la fonction de redémarrage Ansible est qu'elle vérifie que le redémarrage a réussi, que l'hôte distant est opérationnel et que la communication SSH fonctionne à nouveau. Le délai d'attente par défaut pour cela est de 10 minutes, après quoi Ansible génère une erreur.
La troisième pièce
Et voici la troisième pièce. Cette lecture met à jour tous les hôtes restants sur mon réseau. Les noms de ces hôtes sont contenus dans les [postes de travail] groupe de /etc/ansible/hosts fichier d'inventaire.
#######################################################################
#######################################################################
# Play 3 - Do all workstations except david
#######################################################################
#######################################################################
- name: Play 3 - Install updates for all workstations except david
hosts: workstations
strategy: free
remote_user: root
vars:
run: false
reboot: false
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
#######################################################################
# 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"
- name: Reboot if necessary and reboot extra variable is true
reboot:
when: (check.stdout | regex_search('reboot will be required')) and reboot == "true" and run == "true" Il n'y a qu'un seul changement dans ce playbook autre que la liste des hôtes.
stratégie :Le gratuit stratégie indique à Ansible d'effectuer librement les tâches de ce jeu. Les tâches de ce jeu sont exécutées sur chaque hôte aussi rapidement que l'hôte peut les faire. Cela signifie que certains hôtes peuvent terminer la dernière tâche bien avant que d'autres hôtes plus lents aient terminé même la première tâche du playbook. Cela peut sembler être une sorte de libre pour tous lorsque vous lisez le flux de données STDOUT.
Chaque stratégie est un plugin distinct, et il existe quelques autres plugins qui peuvent être utilisés avec ce mot-clé. La valeur par défaut est linéaire , qui exécute chaque tâche sur tous les hôtes avant de passer à la tâche suivante. Le host_pinned plugin effectue toutes les tâches de la lecture sur chaque hôte avant de passer à l'hôte suivant. Le débogage le plugin exécute des tâches de manière interactive afin que le jeu puisse être débogué.
Exécuter le playbook
J'exécute ce playbook à l'aide de la commande :
# ansible-playbook -e "run=true reboot=true" doUpdates.yml
Le -e option signifie "variables supplémentaires". Ici, il spécifie les valeurs des deux variables définies dans chaque jeu. Dans ce cas, définissez-les tous les deux sur true permet d'effectuer les mises à jour et d'effectuer le redémarrage (mise hors tension) si nécessaire.
Je ne reproduirai pas le STDOUT flux de données ici car il est assez long.
Réflexions finales
Avec quelques modifications pour refléter les détails de votre réseau, ce playbook peut être utilisé pour automatiser vos tâches de mise à jour. Effectuer des mises à jour à l'aide d'un playbook similaire au mien est un bon moyen de commencer à utiliser Ansible. Bien qu'il utilise plusieurs mots-clés pouvant effectuer des tâches complexes, il s'agit d'un playbook relativement simple. J'ai commencé avec juste le premier jeu pour mettre à jour mon poste de travail personnel, et le reste était principalement du copier/coller, avec quelques modifications mineures pour répondre aux besoins des différents groupes d'hôtes.
Oui, il y a d'autres façons de faire cela. J'aurais probablement pu utiliser différentes tâches en utilisant des conditions dans un ou deux jeux au lieu de trois jeux. Ou j'aurais pu utiliser des conditions et des blocs pour gérer différemment la gestion d'hôtes spécifiques. Personnellement, je pense que les jeux individuels aident à séparer suffisamment la logique pour que changer la façon dont les tâches sont gérées dans un jeu n'affecte pas les autres. À mon avis, cette séparation est également plus élégante car la logique globale est plus simple à écrire, à comprendre et plus facile à gérer.
[ Un guide gratuit de Red Hat :5 étapes pour automatiser votre entreprise. ]
Ressources
Le document le plus complet et le plus utile que j'ai trouvé est le guide de l'utilisateur d'Ansible sur le site Web d'Ansible. Ce document est conçu comme une référence et non comme un guide pratique ou un document de démarrage.
Opensource.com a publié de nombreux articles sur Ansible au fil des ans, et j'ai trouvé la plupart d'entre eux très utiles pour mes besoins. Le site Web Red Hat Enable Sysadmin contient également de nombreux articles Ansible que j'ai trouvés utiles.
Il existe également des pages de manuel intéressantes mais concises.