pip en lançant:pip install ansible
ansible --version
=> 2.9.x
ansible all -m ping. Que signifie-t-elle ?-vvv pour mettre en mode très verbeux. Ce mode est très efficace pour débugger lorsqu’une erreur inconnue se présente. Que se passe-t-il avec l’inventaire ?ansible en vous connectant à votre machine localhost et en utilisant le module ping.hotelocal ansible_host=127.0.0.1 ansible_connection=local dans l’inventaire par défaut (le chemin est indiqué dans). Et pinguer hotelocal.python3 -m pip install --user argcomplete
activate-global-python-argcomplete --user
LXD est une technologie de conteneurs actuellement promue par Canonical (ubuntu) qui permet de faire des conteneur linux orientés systèmes plutôt qu’application. Par exemple systemd est disponible à l’intérieur des conteneurs contrairement aux conteneurs Docker.
Incus est le successeur de LXD, abandonné par ses devs à cause des choix de Canonical.
Affichez la liste des conteneurs avec incus list. Aucun conteneur ne tourne.
Maintenant lançons notre premier conteneur centos avec incus launch images:centos/7/amd64 centos1.
Listez à nouveau les conteneurs lxc.
Ce conteneur est un centos minimal et n’a donc pas de serveur SSH pour se connecter. Pour lancez des commandes dans le conteneur on utilise une commande LXC pour s’y connecter incus exec <non_conteneur> -- <commande>. Dans notre cas nous voulons lancer bash pour ouvrir un shell dans le conteneur : incus exec centos1 -- bash.
Nous pouvons installer des logiciels dans le conteneur comme dans une VM. Pour sortir du conteneur on peut simplement utiliser exit.
Un peu comme avec Docker, LXC utilise des images modèles pour créer des conteneurs. Affichez la liste des images avec incus image list. Trois images sont disponibles l’image centos vide téléchargée et utilisée pour créer centos1 et deux autres images préconfigurée ubuntu_ansible et centos_ansible. Ces images contiennent déjà la configuration nécessaire pour être utilisée avec ansible (SSH + Python + Un utilisateur + une clé SSH).
Supprimez la machine centos1 avec incus stop centos1 && incus delete centos1 –>
Nous avons besoin d’images Linux configurées avec SSH, Python et un utilisateur de connexion (disposant idéalement d’une clé ssh configurée pour éviter d’avoir à utiliser un mot de passe de connection)
Créons à partir des images du remotes un conteneur ubuntu et un autre centos:
incus launch ubuntu_ansible ubu1
incus launch centos_ansible centos1
id_ed25519 qui devrait être présente dans votre dossier ~/.ssh/. Vérifiez cela en lançant ls -l /home/stagiaire/.ssh.ubu1 et centos1 en ssh pour vérifier que la clé ssh est bien configurée et vérifiez dans chaque machine que le sudo est configuré sans mot de passe avec sudo -i.Lorsqu’on développe avec Ansible il est conseillé de le gérer comme un véritable projet de code :
inventory.cfg ou hosts et une configuration locale au projet ansible.cfgNous allons créer un tel projet de code pour la suite du tp1
tp1 sur le Bureau.Open Folder...Un projet Ansible implique généralement une configuration Ansible spécifique décrite dans un fichier ansible.cfg
ansible.cfg avec à l’intérieur:[defaults]
inventory = ./inventory.cfg
roles_path = ./roles
host_key_checking = false # nécessaire pour les labs ou on créé et supprime des machines constamment avec des signatures SSH changées.
stdout_callback = yaml
bin_ansible_callbacks = True
ansible.cfg et ajoutez à l’intérieur notre nouvelle machine hote1.
Il faut pour cela lister les conteneurs lxc lancés.incus list # récupérer l'ip de la machine
Générez une clé si elle n’existe pas avec ssh-keygen.
On va copier cette clé à distance avec ssh-copy-id.
Créez et complétez le fichier inventory.cfg d’après ce modèle:
ubu1 ansible_host=<ip>
[all:vars]
ansible_user=stagiaire
Ansible cherche la configuration locale dans le dossier courant. Conséquence: on lance généralement toutes les commandes ansible depuis la racine de notre projet.
Dans le dossier du projet, essayez de relancer la commande ad-hoc ping sur cette machine.
Ansible implique le cas échéant (login avec clé ssh) de déverrouiller la clé ssh pour se connecter à chaque hôte. Lorsqu’on en a plusieurs il est donc nécessaire de la déverrouiller en amont avec l’agent ssh pour ne pas perturber l’exécution des commandes ansible. Pour cela : ssh-add.
Créez un groupe adhoc_lab et ajoutez les deux machines ubu1 et centos1.
ping sur les deux machines.ansible.cfg. Cependant on peut aussi utiliser une connexion par mot de passe et préciser l’utilisateur et le mot de passe dans l’inventaire ou en lançant la commande.En précisant les paramètres de connexion dans le playbook il et aussi possible d’avoir des modes de connexion différents pour chaque machine.
adhoc_lab, centos_hosts et ubuntu_hosts avec deux machines dans chacun. (utilisez pour cela [adhoc_lab:children])[all:vars]
ansible_user=stagiaire
[ubuntu_hosts]
ubu1 ansible_host=<ip>
[centos_hosts]
centos1 ansible_host=<ip>
[adhoc_lab:children]
ubuntu_hosts
centos_hosts
Dans un inventaire ansible on commence toujours par créer les plus petits sous groupes puis on les rassemble en plus grands groupes.
Nous allons maintenant installer nginx sur nos machines. Il y a plusieurs façons d’installer des logiciels grâce à Ansible: en utilisant le gestionnaire de paquets de la distribution ou un gestionnaire spécifique comme pip ou npm. Chaque méthode dispose d’un module ansible spécifique.
Si nous voulions installer nginx avec la même commande sur des machines centos et ubuntu à la fois, impossible d’utiliser apt car centos utilise dnf. Pour éviter ce problème on peut utiliser le module package qui permet d’uniformiser l’installation (pour les cas simples).
N’hésitez pas consulter extensivement la documentation des modules avec leur exemple ou d’utiliser la commande de documentation ansible-doc <module>
become pour devenir root avant d’exécuter la commande (cf élévation de privilège dans le cours2)Commençons par installer les dépendances de cette application. Tous nos serveurs d’application sont sur ubuntu. Nous pouvons donc utiliser le module apt pour installer les dépendances. Il fournit plus d’option que le module package.
Créons un playbook rudimentaire pour installer nginx.
Relancez le playbook après avoir sauvegardé les modifications. Si cela ne marche pas, pourquoi ?
Re-relancez le playbook après avoir sauvegardé les modifications. Si cela ne marche pas, pourquoi ?
Re-relancez le même playbook une seconde fois. Que se passe-t-il ?
epel-release sur la machine centos.nginx. Que remarque-t-on ?systemd et l’option --check pour vérifier si le service nginx est démarré sur chacune des 2 machines. Normalement vous constatez que le service est déjà démarré (par défaut) sur la machine ubuntu et non démarré sur la machine centos.L’option --check sert à vérifier l’état des ressources sur les machines mais sans modifier la configuration`. Relancez la commande précédente pour le vérifier. Normalement le retour de la commande est le même (l’ordre peut varier).
Lancez la commande avec state=stopped : le retour est inversé.
Enlevez le --check pour vous assurer que le service est démarré sur chacune des machines.
Visitez dans un navigateur l’ip d’un des hôtes pour voir la page d’accueil nginx.
Il existe trois façon de lancer des commandes unix avec ansible:
le module command utilise python pour lancez la commande.
le module shell utilise un module python qui appelle un shell pour lancer une commande.
le module raw.
creates pour simuler de l’idempotence.Créez un fichier dans /tmp avec touch et l’un des modules précédents.
Relancez la commande. Le retour est toujours changed car ces modules ne sont pas idempotents.
Relancer l’un des modules shell ou command avec touch et l’option creates pour rendre l’opération idempotente. Ansible détecte alors que le fichier témoin existe et n’exécute pas la commande.
ansible adhoc_lab --become -m "command touch /tmp/file" -a "creates=/tmp/file"
Nous allons faire que la page d’accueil Nginx affiche des données extraites d’Ansible.
Pour cela nous allons partir à la découverte des variables fournies par Ansible.
Dans Ansible, on peut accéder à la variable ansible_facts : ce sont les faits récoltés par Ansible sur l’hôte en cours.
Pour explorer chacune de ces variables vous pouvez utiliser le module debug dans un playbook:
- name: show vars
debug:
msg: "{{ ansible_facts }}"
Vous pouvez aussi exporter les “facts” d’un hôte en JSON pour plus de lisibilité :
ansible all -m setup --tree ./ansible_facts_export
Puis les lire avec cat ./ansible_facts_export/votremachine.json | jq (il faut que jq soit installé, sinon tout ouvrir dans VSCode avec code ./ansible_facts_export).
jq pour extraire et visualiser des informations spécifiques à partir du fichier JSON. Par exemple, pour voir le type de virtualisation détecté :cat /tmp/ansible_facts/<nom_hôte_ou_IP>.json | jq '.ansible_facts.ansible_virtualization_type'
Nous allons faire que la page d’accueil Nginx affiche des données extraites d’Ansible.
tp1.yml avec à l’intérieur:- hosts: ubu1
tasks:
- name: ping
ping:
Lancez ce playbook avec la commande ansible-playbook <nom_playbook>.
Ajoutez une task utilisant le module systemd:, en ajoutant bien un nom (name:) à cette task, pour s’assurer que le service Nginx est bien lancé.
créons un fichier nommé nginx_index.j2 avec le contenu suivant :
Nom de l'hôte Ansible : {{ ansible_hostname }}
Système d'exploitation : {{ ansible_distribution }} {{ ansible_distribution_version }}
Architecture CPU : {{ ansible_facts['architecture'] }}
Ces variables sont des variables issues de l’étape de collecte de facts Ansible (si on ne les collecte pas, la task échouera).
template:, copiez le fichier nginx_index.j2 à l’emplacement de la configuration Nginx par défaut (c’est /var/www/html/index.html pour Ubuntu).--diff et --check, observez les changements qu’Ansible aurait fait au fichier.