Ansible est un outil d’automatisation qui parfois peut s’avérer complexe, mais qui mérite clairement votre attention si-vous administrez un grand nombre de serveur. Dans ce présent article, nous allons voir comment réaliser des actions de maintenance basiques sur plusieurs instances « slave » (ubuntu 20.04/22.04).
Voilà à quoi va ressembler mon petit lab’ :
- Kali linux (192.168.130.128), Instance (contrôleur de noeud) qui va piloter le déploiement de mes actions sur les autres serveurs :
- Ubuntu 22.04 – 192.168.130.144
- utilisateur : user (droits sudo)
- Ubuntu 20.04 – 192.168.130.139
- utilisateur : user (droits sudo)
- Ubuntu 22.04 – 192.168.130.144
Petit prérequis pour avoir un workflow « click and go take a coffe » :
- Utiliser l’authentification ssh par couple de clé privée/publique
Pour rappel voici comment réaliser ceci :
ssh-keygen # Génération d'une clé SSH "basique" si vous n'en avez pas
ssh-copy-id [email protected] # copie de cette clé sur l'instance 1
ssh-copy-id [email protected] # copie de cette clé sur l'instance 1Les couples de clés ssh sont stocké dans cet emplacement (par défaut) :
ls ~/.ssh/
id_rsa
id_rsa.pubI. Installation d’ansible sur votre machine « pilote »
Bien, maintenant passons aux choses sérieuses. Ce qui est top avec ansible, c’est qu’il agit comme un orchestrateur par l’intermédiaire du protocole très populaire SSH. On dit qu’il est « agentless », (pas besoin d’installer un programme « agent » client sur les machines concernées)
Sur ma Kali, je vais donc procéder à l’installation d’ansible de cette manière :
sudo apt update && sudo apt install ansible -yVoici une des arborescence « type » à utiliser pour ansible. Vous n’êtes pas forcément obligé de la respecter, mais sachez que c’est une des plus courantes. Sur Kali, celle-ci ne se crée pas automatiquement de mémoire. Vous devrez donc peut-être la créer à la main…
Les ressources qui vont nous interesser dans le contexte de l’article sont les suivantes :
- inventory/hosts
- roles/update/update.yml
II. Préparez votre environnement
cd /etc/ansible/Astuce : Afin de vous faciliter la vie, utilisez un éditeur de code comme VSCode afin d’interagir avec vos fichiers plus facilement. Par ailleurs, je vous encourage à utiliser l’extension VSCode « YAML » afin de vous aider dans la rédaction de vos playbooks ainsi que dans la gestion des fichiers connexes.
Dans mon fichier inventory/hosts, je vais donc créer deux « groupes ».
- [lab1]
- [lab2]
L’avantage de faire des groupes ansible permet de cibler précisément sur quel « pool » de serveur vous souhaitez effectuer vos actions de maintenance, afin d’avoir une architecture système propre et bien « splitté ».
Dans un premier temps, je vais effectuer un simple test de connectivité (piiiing) sur le groupe « lab1 » (contenant uniquement l’IP 192.168.130.144)
ansible --inventory-file inventory/hosts -m ping lab1 -u user
À contrario, je peux aussi effectuer le même test pour le groupe « lab2 » (contenant uniquement l’IP 192.168.130.139)
ansible --inventory-file inventory/hosts -m ping lab2 -u user
Enfin, si vous souhaitez effectuer ce test de connectivité sur toutes vos instances, alors vous pouvez utiliser le mot-clé « all » à la place d’un nom de groupe.
ansible --inventory-file inventory/hosts -m ping all -u user
II. Executez des commandes « one line » sur plusieurs instances en même temps
Eh oui, vous n’avez pas forcément besoin d’utiliser des scripts au format .yml (appellé playbooks) tout le temps avec ansible. Certes, c’est moins propre mais si vous souhaitez exécuter ponctuellement une instruction, cela sera plus rapide.
On ne va pas se le cacher, la quasi-totalité des actions de maintenance à réaliser requiers des privilèges plus importants que de simples droits utilisateurs. Par défaut, je vais donc suffixer ma commande avec les options suivantes :
- -K : Cet argument permet d’interagir avec notre « shell distant », et ainsi de préfixer chaque commande par sudo pour le compte en question (user dans mon cas). Attention celui-ci doit évidement disposer de droit sudo afin que cela puisse fonctionner 😉
- Le mot de passe est à saisir manuellement dès lors que vous avez saisi la commande !
- -become-user : Cela permet de dire explicitement à ansible « Je souhaiterais devenir l’utilisateur suivant » (root dans notre cas)
Détails des autres options ci-dessous…
cd /etc/ansible/ansible --inventory-file inventory/hosts -m shell -a "apt update -y" all -u user -become-user -K
- –inventory-file : Emplacement du fichier hosts (à utiliser uniquement, si vous n’êtes pas dans le même dossier que celui-ci)
- -m : module à utiliser : Ici je vais utiliser le module « shell » classique. à la suite de cet argument, on retrouvera le nom du groupe (lab1, lab2, ou all dans mon cas)
- -a : argument à transmettre au module utilisé (ici le module est shell)
- -u : utilisateur (distant) avec lequel je vais me connecter sur les machines « ansiblé ». Pour mes deux serveurs (.139, .144)
L’instruction à l’écran « BECOME Password » vous invite à saisir le mot de passe du compte avec lequel vous vous connectez. Celui-ci doit disposer de droits « sudo ».
Méfiez-vous de l’option « all ». En effet, dans mon cas cela fonctionne car j’ai exactement la même configuration (utilisateurs/mots de passe) sur chacune de mes instances. Je passe en premier lieu par un compte classique avant de « m’élever » en tant que root. Vous trouverez beaucoup de ressources/tuto sur le net qui « passe » uniquement le compte root. Par principe, cela n’est pas une bonne pratique que se connecter directement « as root » sur un serveur bien que la plupart utilisent l’auth SSH clé privée/publique ce qui limite drastiquement l’impact.
Encore faut-il « forcer » l’authentification exclusive clé privée/clé publique, ce qui n’est pas souvent le cas… pour plus d’info : https://le-guide-du-secops.fr/2020/09/25/configurer-le-service-ssh-avec-uniquement-lauthentification-par-paire-de-cles-privee-publique-linux/
III. Mettez à jours vos serveurs directement avec le module apt !
Il y deux méthodes dit « classique » pour effectuer des actions de maintenance à savoir :
- Utiliser un playbook (À utiliser lorsque plusieurs vous souhaitez exécuter plusieurs tâches d’administration « séquentiel »)
- Exécuter une commande « One liner » sans passer par un playbook (à utiliser uniquement pour un, voire deux enchainements de commande, car cela devient beaucoup trop verbeux après)
- Utilisez le module « shell »
- Ou utiliser un module ansible (apt dans mon cas) dédié pour votre action si celui-ci existe. L’avantage de cette option est qu’en cas d’erreur, ce module produira plus de logs, et donc cela sera plus facile pour vous de résoudre le problème.
Sans Playbook
ansible --inventory-file inventory/hosts -m apt -a "upgrade=yes update_cache=yes" lab1 -u user -become-user -K
Si-vous souhaitez effectuer vos tests sur plusieurs groupes en même temps, utiliser une virgule pour inclure chacun de vos groupes : lab1,lab2
ansible --inventory-file inventory/hosts -m apt -a "upgrade=yes update_cache=yes" lab1,lab2 -u user -become-user -KAvec playbook(s)
Rappel sur la notion de playbook :
Un playbook Ansible est un script au format .yml qui décrit une configuration ou un ensemble de tâches à exécuter sur un ou plusieurs hôtes. Il permet de formaliser l’automatisation de la configuration/maintenance d’X instances.
Dans mon cas, je vais effectuer les deux actions suivantes, mais on aurait très bien pu avoir une dizaine de tâches voir plus :
- Créer un fichier dans le dossier /tmp/ et lister le contenu de ce dossier
- Mettre à jour mon serveur (nécessite des droits sudo)
sudo gedit /etc/ansible/roles/update/update.yml - name: Ansible playbook tasks automations
hosts: all
become: true
tasks:
- name: Create a test file in /tmp/
shell:
"echo \"Hello world !\" >> /tmp/test ; ls -l /tmp/test"
- name: Update the system
apt:
update_cache: yes
upgrade: yesDès lors, je vais exécuter la commande suivante afin de « jouer » mon playbook sur mes deux instances !
ansible-playbook --inventory-file inventory/hosts -u user -become-user -K roles/update/update.yml
Si-vous souhaitez avoir un résultat plus détaillé, je vous invite à saisir l’un des arguments supplémentaires ci-après :
-v (peu verbeux, action par défaut)
-vv (très verbeux, utilisé en cas de troublshooting)
-vvv (très verbeux, utilisé en cas de troublshooting complexe) J’espère que ce didacticiel vous aura plu. Désormais ansible sera moins étranger pour vous et j’espère que vous avez compris la puissance de cet outil surtout pour l’administration système… :p
++
Geoffrey
III. Sources
- https://www.clickittech.com/tutorial/how-to-manage-linux-servers-with-ansible
- https://www.jeffgeerling.com/blog/2018/updating-all-your-servers-ansible
- Et bien d’autres que j’ai oublié de noter
0 commentaire