[Cours] - Ansible part-1

content/blog/cours/ansible/ansible-environnement-cle-en-main.md

@@ -0,0 +1,106 @@
+---
+type:               "post"
+title:              "Ansible - Un environnement de travail clé en main avec Lazy Ansible."
+date:               "2023-11-22"
+lastModified:       ~
+tableOfContent:     true
+description:        "Utilisation de la recipe Lazy Ansible du projet Manala pour mettre en oeuvre un environnement de travail dédié Ansible."
+
+thumbnail:          "content/images/blog/thumbnails/lazy-ansible-workspace.jpg"
+tags:               ["cours", "ansible", "automation", "manala"]
+categories:         ["cours", "ansible"]
+authors:            ["gfaivre"]
+---
+
+## Préambule
+
+Les environnements dits « lazy » issus du projet [Manala](https://github.com/manala/manala-recipes) sont des outils destinés à mettre en oeuvre de manière rapide des environnements de travail.
+
+Leur finalité étant **multiple**:
+
+- Être en capacité de déployer un environnement sans être familier avec l'outil cible;
+- Ne pas avoir à installer et/ou modifier sa configuration locale (sur la machine de travail);
+- Disposer d'environnements homogènes de manière à favoriser le collaboratif.
+
+Dans le cadre de travaux autour d'Ansible ou si vous suivez la partie « cours » nous utiliserons la « recipe » qui lui est dédiée (https://github.com/manala/manala-recipes/tree/master/lazy.ansible), son utilisation nécessite l'installation de [Manala](https://manala.github.io/manala/installation/).
+
+## Pré-requis
+
+- Un environnement [Docker / Docker compose](https://docs.docker.com/engine/install/) fonctionnel
+- Manala installé
+
+## Mise en route 
+
+La mise en place d'un nouvel environnement en utilisant Manala est relativement simple, il nous suffit de l'initialiser dans un répertoire dédié (cela peut-être un projet existant) à l'aide de la commande `manala init`. 
+
+Démonstration ci-dessous:
+
+<figure>
+    <img src="content/images/blog/2023/ansible/lazy-ansible/manala_init.gif">
+    <figcaption>
+      <span class="figure__legend">Création d'un environnement Ansible avec Manala.</span>
+    </figcaption>
+</figure>
+
+Nous disposons ainsi d'un environnement Ansible « **conteneurisé** » utilisable en quelques secondes sans n'avoir **rien à installer sur nos postes** (à l'exception de docker bien évidemment).
+Et pour ceux et celles qui doivent faire avec plusieurs versions d'Ansible dans leur quotidien, cela permet d'avoir des environnements **isolés et dédiés** à certaines versions de l'outils.
+
+## Fichiers de configuration
+
+Il est bien évidemment possible à partir des fichiers de configuration Manala, d'agir sur les configurations d'ansible mais également [la configuration SSH](/blog/cours/utiliser-la-configuration-ssh-client).
+
+Pour cela il faudra modifier le fichier `.manala.yaml` qui doit, après la manipulation précédente, se trouver à la racine de votre répertoire de travail.
+
+!!! success "Prendre en compte vos modifications"
+    Si vous modifiez les fichiers de configuration comme indiqué ci-dessous il faudra penser à utiliser la commande `manala up` afin que vos modifications soient bien prises en compte.
+
+### Configurer Ansible 
+
+Il est possible d'interagir sur la configuration Ansible à partir de la section suivante: 
+
+```yaml
+system:
+    ansible:
+        version: 2.15.5
+        config: |
+            [defaults]
+            control_path_dir = /tmp/ansible/cp
+            [privilege_escalation]
+            become = True
+            become_flags = -H -S
+            [ssh_connection]
+            control_path = /tmp/%%h-%%r
+```
+
+On notera qu'il est possible d'agir sur la version d'ansible utilisée dans notre conteneur Docker mais également sur les directives de configuration propres à Ansible (https://docs.ansible.com/ansible/latest/reference_appendices/config.html).
+
+!!! info "Le fichier ansible.cfg"
+    Les modifications de configuration comme ci-dessus se traduisent par l'ajout de directives dans le fichier `/etc/ansible/ansible.cfg`. Il est possible de surcharger ce fichier en placant un fichier du même nom à la racine des répertoires de travail de vos projets permettant ainsi l'introduction de directives spécifiques à chacun d'entre eux.
+
+### Configurer SSH
+
+Concernant SSH le fonctionnement est le même, on retrouve une section dédiée au sein du fichier `.manala.yaml` qui nous permettra de jouer sur les directives de configuration SSH:
+
+```yaml
+ssh:
+    config: |
+        Host *
+            User debian
+            ForwardAgent yes
+```
+
+Et vous voilà en quelques lignes en capacité d'utiliser un environnement Ansible.
+
+### Configurer GIT
+
+Toujours dans le même fichier, la section cette fois-ci sera la suivante:
+
+```yaml
+git:
+    config: |
+        # Silence false positive dubious ownership errors
+        #[safe]
+        #directory = *
+```
+
+Vous voilà prêt à attaquer [Ansible](/blog/cours/ansible/ansible-premiers-pas) ;)

content/blog/cours/ansible/ansible-premiers-pas.md

@@ -0,0 +1,154 @@
+---
+type:               "post"
+title:              "Ansible - Découverte et premiers pas."
+date:               "2023-11-23"
+lastModified:       ~
+tableOfContent:     true
+description:        "Dans ce premier cours à destination des étudiants et/ou néophytes, nous verrons ce qu'est Ansible ainsi qu'un exemple très simple de son utilisation."
+
+thumbnail:          "content/images/blog/thumbnails/Get-started-with-Ansible.jpg"
+tags:               ["cours", "ansible", "automation"]
+categories:         ["cours"]
+authors:            ["gfaivre"]
+---
+
+## Préambule
+
+Ce cours est utilisé dans le cadre de TP au sein de l'IUT Lyon 1. Il est notamment dispensé à des étudiants peu ou pas familiers avec les stratégies d'automatisation et de déploiement des infrastructures.
+Bien que très axé débutants il peut également représenter une possibilité de monter « rapidement » pour certaines équipes sur les principes fondamentaux d'Ansible afin de disposer du bagage minimal nécessaire à son utilisation.
+
+Il s'agit bien évidemment de supports à vocation pédagogique qui **ne sont pas toujours transposables** à une activité professionnelle.
+
+## Prérequis
+
+Afin d'aborder les différents concepts du cours il est recommandé de disposer:
+- D'au moins deux machines virtuelles accessibles via **SSH** (idéalement 4);
+- **[Docker et Docker compose](https://docs.docker.com/engine/install/)** installés sur la machine de travail (Docker Desktop pour [Windows](https://docs.docker.com/desktop/install/windows-install/) et [OSX](https://docs.docker.com/desktop/install/mac-install/));
+- D'une installation d'Ansible récente (2.15.5), s'il est possible de l'installer localement je recommanderais plutôt d'utiliser le [**Lazy Ansible**](/blog/cours/ansible/ansible-environnement-cle-en-main) du projet [**Manala**](https://github.com/manala/)..
+- D'une paire de clés SSH que vous aurez pris soin de générer (voir [ici](/blog/cours/cle-ssh-principes-de-base)) si vous n'en disposez pas déjà.
+- D'un répertoire de travail, de mon côté ça sera `workspace/ansible` (très original oui), son nom importe peu, l'idée est que vous sachiez vous y retrouver;
+
+Pour ceux qui utilisent Windows, il est possible d'[utiliser WSL pour faire fonctionner les conteneurs Docker](/blog/cours/docker-avec-windows-et-wsl), une machine virtuelle Linux fonctionne encore mieux, libre à vous d'utiliser l'un ou l'autre.
+
+## Mise en route
+
+Première étape avant de pouvoir rentrer dans le vif du sujet, nous aurons besoin de mettre en place un environnement de travail dédié à nos travaux.
+
+## Infrastructure
+
+Pour pouvoir configurer nos serveurs, il nous faudra... des serveurs, ou plutôt des machines virtuelles pour leur facilité à être arrêtées, détruites et reconstruites.
+N'importe quel fournisseur de cloud public peut faire l'affaire, utilisez celui avec lequel vous avez le plus d'affinités.
+
+Dans le cadre de l'IUT nous utiliserons OpenStack, solution OpenSource qui a fait ses preuves et qui plus est disponible dans l'enceinte de l'université, c'est également la solution technique utilisée par le [Public Cloud d'OVHCloud](https://www.ovhcloud.com/fr/public-cloud/).
+C'est donc sur cette base que je présenterai les étapes suivantes, au demeurant, parfaitement transposables chez d'autres fournisseurs.
+
+Nous travaillerons avec deux environnements distincts, « *Staging* » et « *Production* » qui embarqueront chacune une instance applicative (qui portera donc le code d'une application) et une instance destinée aux données (et donc chargée de faire fonctionner notre serveur de base de données).
+Si vous êtes limité en terme de création d'instances, il est envisageable de n'avoir qu'une instance par environnement, celle-ci embarquant **l'applicatif et les données**.
+
+## Environnement local
+
+Les étapes suivantes seront donc à exécuter à partir de votre machine.
+
+### Se connecter avec le client SSH
+
+Considérant que vous remplissez les prérequis et que vous avez créé vos instances distantes nous allons pour commencer initier une « simple » connexion SSH vers notre instance.
+
+```
+ssh [email protected]
+```
+
+Si vous rencontrez des soucis .. forbidden (exemple) ré-essayez en ajoutant explicitement le chemin vers la clé.
+
+```
+ssh -i ~/.ssh/ed25519 [email protected]
+```
+
+!!! info "Utilisateur sous Windows"
+    Pour rappel aux utilisateurs de Windows vous trouverez ce répertoire `.ssh` dans `C:\Users\MonNomUtilisateur\`
+
+### Configuration du client SSH
+
+Afin d'éviter d'avoir à spécifier le chemin vers la clé à chaque connexion et afin d'affiner la configuration de notre client nous pouvons également définir un fichier `~/.ssh/config` contenant les directives suivantes:
+
+```
+Host 192.168.140.*
+  Port 22
+  User debian
+  IdentityFile ~/.ssh/keyfile
+  IdentitiesOnly yes
+  ForwardAgent yes
+```
+
+Celles-ci sont relativement compréhensibles, précisons tout de même pour les deux dernières:
+
+- `IdentitiesOnly` indique à SSH de n'envoyer au serveur **QUE** la clé définie à la directive `IdentityFile` quand bien même vous disposez d'autres clés dans votre répertoire `~/.ssh`
+- `ForwardAgent` permet d'activer le transfert d'identité vers l'agent SSH du serveur
+
+Cette configuration vous permet d'indiquer certaines directives de manière automatique pour un ou plusieurs hôtes distants, pour en savoir plus concernant les fichiers de configuration SSH vous pouvez aller jeter un oeil [ici](/blog/cours/utiliser-la-configuration-ssh-client)
+
+### Utilisation de l'agent SSH
+
+La prochaine étape est l'utilisation d'un service spécifique à SSH, **l'agent**.
+
+L'agent SSH sur la plupart des systèmes UNIX est lancé au démarrage de votre machine, toutefois si ça n'est pas le cas, il est possible de le démarrer avec la commande `eval 'ssh-agent'`.
+Son rôle est de permettre de stocker de manière sécurisée votre/vos clés privées SSH (rappelez-vous c'est la partie que l'on ne partage pas !) mais également d'assurer le transfert de cette clé privée en toute sécurité vers les serveurs distants auxquels vous tenterez de vous connecter.
+
+#### Ajouter une clé dans l'agent
+
+L'ajout d'une clé dans un agent est trivial et se fait à l'aide de la commande `ssh-add ~/.ssh/my_private_key`. 
+
+Si vous avez protégé votre clé avec une phrase de passe elle vous sera demandée par l'agent au moment de son ajout.
+Afin de vérifier que votre clé a bien été ajoutée à votre agent vous pouvez lister les clés contenues à l'intérieur avec la commande `ssh-add -l` qui devrait vous donner une sortie équivalente à la suivante:
+
+```
+rix@debian:~$ ssh-add -l 
+4096 SHA256:knyjFlzIWukj77PBs0V+mO4eKD9mnSITOkYfYvgvZcQ /home/rix/.ssh/gfaivre-iut (RSA)
+```
+Cette étape, complétée par la directive `ForwardAgent` contenue dans notre fichier de configuration SSH (pour rappel `~/.ssh/config`) va nous permettre lorsque nous nous connectons à un serveur distant de transférer notre clé privée vers l'agent de ce même serveur.
+
+De cette manière notre clé privée sera même disponible sur le serveur auquel nous nous connectons, nous aborderons l'utilité de cette configuration plus tard.
+
+### Communication Ansible <> serveurs distants
+
+Notre environnement étant « prêt » testons à présent la bonne communication avec nos serveurs distants en utilisant le module `ping` d'Ansible.
+
+À partir de ce moment et sauf instruction contraire nous partirons du principe que nous évoluons à l'intérieur de notre répertoire de travail (`workspace/ansible` donc ;)) pour saisir nos commandes et créer notre arborescence de projet.
+
+!!! info "Les modules Ansible"
+    Dans la terminologie Ansible, les « modules » sont des morceaux de code pouvant être utilisés soit directement dans la ligne de commande (avec l'option `-m`, soit dans une section `task` d'un « playbook »). Ils peuvent prendre en charge des arguments avec une syntaxe classique `key=value`.
+
+Pour pouvoir effectuer notre premier test nous allons donc créer un fichier que nous appellerons `hosts.yml` contenant (à adapter en fonction du réseau sur lequel sont déployées vos machines virtuelles): 
+
+```
+all:
+  hosts:
+    ansible-vm-01:
+      ansible_host: 192.168.140.30
+      ansible_user: debian
+```
+
+Attention à l'indentation et faites attention de bien utiliser des espaces pour celle-ci.
+
+Pour terminer nous lançons notre conteneur docker « lazy » avec un `make sh` et y exécutons la commande `ansible -i hosts.yml all -m ping`, qui utilise le module **ping** d'ansible pour vérifier que l'on arrive bien à se connecter à l'instance distante.
+
+Ce qui nous donne: 
+
+<figure>
+    <img src="content/images/blog/2023/ansible/ansible-part-1/ansible-ping.gif">
+    <figcaption>
+      <span class="figure__legend">Utilisation du module ping avec Ansible.</span>
+    </figcaption>
+</figure>
+
+!!! danger "Le module ping"
+    Bien que son nom puisse porter à confusion, il s'agit là d'un module propre à Ansible et qui n'a rien à voir avec la commande système du même nom. Pour rappel, la commande système envoie un paquet ICMP (ECHO_REQUEST) à une machine distante et attend en retour un paquet du même type (ECHO_RESPONSE) indiquant le bon état de la liaison réseau.
+    Le module Ansible quant à lui se connecte via SSH à la machine distante et y vérifie la bonne configuration de Python.
+
+
+Cette dernière étape me permet d'introduire un concept que nous verrons dans la section suivante, celui des *inventaires* ! 
+
+## Aller plus loin avec les sources:
+
+- https://docs.ansible.com/ansible/latest/module_plugin_guide/modules_intro.html
+- https://www.ssh.com/academy/ssh/agent
+

content/blog/cours/docker-avec-windows-et-wsl.md

@@ -76,7 +76,7 @@ Pour terminer la commande `docker ps` devrait vous renvoyer l'écran ci-dessous:
     </figcaption>
 </figure>
 
-## Allez plus loin avec les sources
+## Aller plus loin avec les sources
 
 - https://learn.microsoft.com/fr-fr/windows/wsl/basic-commands
 - https://learn.microsoft.com/fr-fr/training/modules/wsl/wsl-introduction/

content/blog/cours/utiliser-la-configuration-ssh-client.md

@@ -196,7 +196,7 @@ Host server-hostname-1
     On remarquera son utilisation dans l'exemple ci-dessus. Il s'agit du **hash [SHA1](https://en.wikipedia.org/wiki/SHA-1)** des tokens %l%h%p%r (Respectivement le nom d'hôte local (`%l`), le nom d'hôte distant (`%h`), le port de connexion distant (`%p`) et pour finir le nom d'utilisateur distant utilisé (`%r`)).
     L'utilisation du token `%C` assurant à la fois, l'unicité de la connexion et l'obfuscation de ses détails sur le système de fichiers.
 
-## Pour aller plus loin:
+## Aller plus loin avec les sources
 
 - Recommandations pour un usage sécurisé d'OpenSSH par l'ANSSI: [https://www.ssi.gouv.fr/uploads/2014/01/NT_OpenSSH.pdf](https://www.ssi.gouv.fr/uploads/2014/01/NT_OpenSSH.pdf)
 - https://man.openbsd.org/ssh_config