fr en fr en en fr fr fr fr en fr en en fr fr fr en hu en en en fr en en en fr fr fr fr fr fr fr fr fr fr fr fr fr fr fr fr fr en de fr fr en fr fr fr fr en en fr fr fr fr en fr fr fr fr fr en hu fr fr en fr fr fr fr en en fr fr fr en fr en fr fr en fr fr fr fr fr fr fr fr fr fr fr fr fr fr en fr fr fr fr en en fr fr en fr fr en fr
L’Infrastructure as Code est un ensemble de mécanismes permettant de gérer, par des fichiers descripteurs ou des scripts, […] une infrastructure à part entière, de l’instance au réseau, […].
Souvent plébiscité dans le cadre du cloud computing, l’Infrastructure as Code offre aux développeurs la possibilité de pouvoir automatiser leurs déploiements, et ainsi éviter toute configuration manuelle ; tout en évitant de devoir écrire d’eux-mêmes les appels aux interfaces de programmation. Cette technologie est donc une réponse aux besoins des entreprises en termes de passage à l’échelle des applications, mais également pour l’automatisation et la simplification des infrastructures des projets informatiques. Également, l’Infrastructure as Code rentre dans la mouvance plus générale du DevOps.
L’IaC est donc une étape intéressante pour la mise en place et maintenance de notre système d’information.
Rien n’est de plus embêtant que de faire la configuration initiale d’un serveur :
Installation des applications de base
Configuration SSH (ajout des clés…)
On fait tout le temps la même chose ! Cela déborde même en script !
Le problème des scripts est souvent de gérer les cas d’erreurs (L’ajout du repository de Docker s’est-il bien déroulé ? Dans le cas contraire, je vais installer la version des dépôts d’Ubuntu, ce que je ne souhaite pas car pas assez à jour)…
De plus, quand on met en place un service, on essaye tant bien que mal d’apporter une documentation sur comment cela a été mis en place pour pouvoir ainsi le refaire si nécessaire. L’utilisation de docker compose m’as fait comprendre l’importance de cela.
Toutes ces réflexions révèlent l’essence même de ce site.
C’est en 2015 que Red Hat annonce le rachat d’Ansible et le met sur le devant de la scène. Ansible est un logiciel libre qui s’utilise notamment pour faire de l’IaC, de la gestion de configuration et l’exécution de tâches.
Un peu plus de détail sur la page Wikipédia et sur le site officiel.
Vous avez peut-être déjà entendu parler de ses concurrents :
Nous allons donc voir ici comment on peut utiliser efficacement ce logiciel pour nous faciliter notre vie de bidouilleur de l’informatique.
On installe donc Ansible. Pour cela, on va ajouté le PPA, mettre à jour notre liste des paquets existants et installer le logiciel.
sudo apt-add-repository --yes --update ppa:ansible/ansible sudo apt update sudo apt install ansible
Vous pouvez aussi l’installer avec PIP :
pip install --user ansible
J’ai remarqué que mon Ansible utilisait Python 2.7.17 alors que j’ai bien la version 3.6.9 sur mon WSL…
Je préfère utiliser dès le début la version utilisant Python3 histoire de pas avoir d’ennuis plus tard à cause d’un fin de support ou autre.
J’ai alors désinstallé Ansible, installé PIP3 et ainsi Ansible :
# sudo apt remove ansible sudo apt install python3-pip pip install --user ansible
Bien sûr le lancement de la commande ansible --version ne fonctionne pas et me donne un joli “command not found”.
Cela est dû au fait que le dossier où Ansible s’est installé (~/.local/bin) n’est pas dans la variable PATH.
Mais en consultant le fichier ~/.profile, je vois bien la section correspondante.
Je remets donc à jour mon shell avec un source ~/.profile et voici donc le résultat d’une nouvelle exécution de la commande ansible --version :
1 2 3 4 5 6
$ ansible --version ansible 2.9.6 config file = /etc/ansible/ansible.cfg [...] python version = 3.6.9 (default, Nov 7 2019, 10:44:02) [GCC 8.3.0]
Effectuons le test basique de ping :
1 2 3 4 5 6
$ ansible localhost -m ping localhost | SUCCESS => { "changed": false, "ping": "pong" }
Ce test est un test en mode d’exécution ad hoc.
On utilise le module ping qui fait partie de la grande liste des modules d’Ansible.
Nous allons nous voir comment générer un ensemble de tâches a exécuter via ce qu’Ansible définit comme un Playbook.
On peut faire une analogie avec Docker où un docker run correspond au mode ad hoc et un docker compose au Playbook.
Il est possible d’ajouter sa liste d’hôtes dans le fichier /etc/ansible/hosts dans le format INI, mais on va plutôt le faire dans un fichier YAML.
Je me suis positionné dans un répertoire de travail ~/projets/ansible ou j’ai créer le fichier d’inventaire que j’ai nommé hotes.yaml
1 2 3 4 5
all: hosts: 192.168.92.17: 192.168.92.4: sadara.scrample.xyz:
Cet inventaire est l’exemple le plus simple que je peux proposé, si vous êtes déterminé, aller voir la section sur la documentation officielle.
J’ai créé un fichier livres.yaml dont le contenu est le suivant :
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
- name: Installation du serveur hosts: all remote_user: root tasks: - name: Installation de Git apt: name=git update_cache=yes - name: Installation de Vim apt: name=vim - name: Add user "nagios" user: name: nagios shell: /bin/bash append: yes comment: "Nagios User" state: present become: true - name: Add Nagios SSH Key authorized_key: user: "nagios" key: "ssh-ed25519 BHIwxeOQq6nTGgEJ0+7s5VHbubL29xPFij+rlxdgHBU= nagios@kaishin" state: present - name: Installation des plugins Nagios apt: name=nagios-plugins update_cache=yes
Le Playbook se lit donc de la manière suivante :
Je me connecte sur chaque serveur (all) en tant que root pour effectuer les actions suivantes :
J’installe git via le gestionnaire apt en mettant au préalable le cache à jour (update_cache=yes) . J’installe aussi vim.
J’ajoute un utilisateur “nagios” ayant pour shell de base /bin/bash.
J’ajoute la clé publique ssh-ed25519 BHIwxeOQq6nTGgEJ0+7s5VHbubL29xPFij+rlxdgHBU= nagios@kaishin au fichier ~/.ssh/authorized_key de l’utilisateur nagios.
J’installe les plugins nagios (nagios-plugins) via le gestionnaire apt.
On lance donc le playbook avec la commande suivante :
ansible-playbook -i hotes.yaml livre.yaml
Il est important de noter qu’un Playbook est de nature idempotente. Cela veut dire que l’on peut lancer le Playbook plusieurs fois sans problème. Si les tâches sont déjà accomplies, on ne les refait pas. Dans le cas de l’exemple du dessus, on ne va pas réinstaller les paquets et recréer un utilisateur à chaque lancement du playbook.
Voyez ici le résultat d’un énième lancement d’un playbook :
Exemple de retour d’un Playbook
Anglais ou français, il faut choisir…
On voit bien que dans le récapitulatif, il n’y a rien de modifié.
Nous avons donc vu une approche d’Ansible ainsi que de ces Playbook.
Il existe une bibliothèque communautaire en ligne nommée Ansible Galaxy qui permet de récupérer les scripts des autres.
Vous remarquerez que les Playbooks de la communauté suivent un format de fichiers structurés. Cet article étant une introduction à Ansible, je ne suis pas allé dans ce sens.