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:
+
+
+
+ Création d'un environnement Ansible avec Manala.
+
+
+
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.
Il est bien évidemment possible à partir des fichiers de configuration Manala, d'agir sur les configurations d'ansible mais également la configuration SSH.
+
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.
+
+
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.
+
+ 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.
+
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:
Première étape vers l'utilisation d'Ansible, les inventaires. Ils sont le point d'entrée vers vos infras et sont donc central au pilotage de vos instances / serveurs.
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ésenté 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.
Afin de pouvoir attaquer nos différentes machines, Ansible a besoin d'un référentiel de celles-ci avec un minimum d'informations les concernants (histoire de savoir comment s'y connecter par exemple ;)).
+
C'est là qu'entre en jeu les inventaires. Il existe deux façons de constituer des inventaires, la première est manuelle, et consiste à écrire ni plus ni moins la liste des machines que l'on souhaites manager on parle dans ce cas d'inventaire statique.
+
La deuxième méthode introduit un principe de « reconnaissance » des machines disponibles, dans ce cas de figure on constituera nos inventaires de manière automatique, on parle dans ce cas d'inventaires dynamiques que nous verrons plus tard.
+
Les inventaires permettent également de structurer / hiérarchiser nos machines en utilisant une notion de groupe.
+Ansible propose plusieurs plugins capablent de gérer des inventaires de machines, ils sont consultables à l'aide de la commande:
+
ansible-doc -t inventory -l
+
Qui devrait vous renvoyer la liste suivante:
+
02:48:02 lazy@ansible_env lazy → ansible-doc -t inventory -l
+ansible.builtin.advanced_host_list Parses a 'host list' with ranges
+ansible.builtin.auto Loads and executes an inventory plugin specified in a YAML config
+ansible.builtin.constructed Uses Jinja2 to construct vars and groups based on existing inventory
+ansible.builtin.generator Uses Jinja2 to construct hosts and groups from patterns
+ansible.builtin.host_list Parses a 'host list' string
+ansible.builtin.ini Uses an Ansible INI file as inventory source
+ansible.builtin.script Executes an inventory script that returns JSON
+ansible.builtin.toml Uses a specific TOML file as an inventory source
+ansible.builtin.yaml Uses a specific YAML file as an inventory source
+
Dans notre cas nous nous appuyerons essentiellement sur le plugin yaml.
Un inventaire n'est en fait ni plus ni moins qu'un ou plusieurs fichiers contenant des informations concernant le parc de machines que l'on souhaite piloter.
+
En terme de structure vous rencontrerez énormément de façons de faire, celles-ci étant bien évidemment guider par le besoin métier, on pourra citer comme contraintes par exemple:
+
+
La taille des infrastructures (le nombre d'éléments qui la constitue);
+
Leur localisation géographique (pays, ville...);
+
Le besoin d'adresser finement un groupe de machines et pas un autre...
+
+
Bref tout est imaginable à ce niveau.
+En ce qui nous concerne nous interviendrons sur un parc plutôt modeste puisque pour nos travaux nous utiliserons au maximum 4 machines.
+
Nous allons donc commencer par créer un répertoire qui leur sera dédié appelé inventories nous déplacerons ensuite le fichier hosts.yml que nous avions créé précédemment.
+
Vous devriez donc disposer d'une arborence similaire à la suivante:
ansible_become: Permet de forcer l'escalade de privilèges;
+
ansible_become_method: Permet de spécifier la méthode d'escalade des privilèges;
+
ansible_become_user: Permet de spécifier l'utilisateur cible de l'escalade de privilèges;
+
ansible_become_pass: Permet de spécifier le mot de passe de l'utilisateur cible de l'escalade de privilèges (encore une fois, on préfera la méthode par clés SSH).
À présent que nous avons effectuer un petit tour rapide du propriétaire, nous allons « étoffer » notre inventaire initial en ajoutant une deuxième machine comme ci-dessous:
En ajoutant une machine et en jouant la commande ansible -i inventories/hosts.yml all -m ping nous devrions voir qu'ansible considère bien nos deux machines:
+
+
+
+ Utilisation du module ping sur deux machines.
+
+
+
+
Hôte local
+
+ Il est bien évidemment possible d'interroger notre propre machine à l'aide d'Ansible, en modifiant relativement simplement notre fichier d'inventaire. Attention toutefois à ce que vous faites puisque vous pouvez directement impacter la configuration et donc le fonctionnement de votre machine.
+
+
+
Exemple de fichier d'inventaire pour piloter une machine locale:
À retenir:
+Ansible utilise une arborescence ou figurera toujours:
+
+
Un groupe all: C'est le groupe racine auquel appartiendra toutes vos machines sans exception (On remarquera avec cette information que lorsque nous avons utilisé la commande ansible -i inventories/hosts.yml all -m ping, all indiquait donc le groupe cible).
+
Un groupe ungrouped: Groupe auquel sera affectée toute machine n'appartenant à aucun groupe (exception faites de all bien évidemment);
+
+
Dans notre exemple ci-dessus on voit donc bien que nos deux machines font bien partie du groupe webservers.
+
+
Fichiers d'inventaire multiples
+
+ Si l'option -i d'Ansible prend un fichier d'inventaire en paramètre elle peut également prendre un répertoire et dans ce cas Ansible considérera l'ensemble des fichiers présents dans le répertoire.
+ Ce fonctionnement offre la possibilité avec des infrastructures composées de nombreuses machines de pouvoir les séparer dans plusieurs fichiers en fonction de différents critères.
+
Vous aurez compris que si l'on aborde le sujet c'est qu'il est d'importance... pour l'illustrer créons un nouveau fichier d'inventaire que l'on nommera misc.yml contenant:
Une fois ces modifications faites, rejouez la commande ansible-inventory --list -i inventories vous devriez constater de subtils changements au niveau des informations que vous affiche Ansible.
L'ajout de la clé ansible_port sur notre première instance;
+
La modification de l'adresse IP de la seconde.
+
+
Qu'en retenir ?
+
L'utilisation du Yaml comme langage de définition introduit une notion d'arborescence au niveau de vos clés, il faut ainsi voir la définition de votre machine comme un tableau multidimensionnel indexé.
Que l'ajout d'une clé entraine l'ajout d'un élément à notre tableau pour la clé concernée (Dans notre cas l'ajout de la clé ansible_port);
+
Que la modification de la valeur d'une clé écrase sa valeur précédente (Dans notre cas la modification de l'IP de notre machine).
+
+
Conclusion: Lorsque l'on utilise des fichiers d'inventaire multiples il vaut bien prendre en compte leur ordonnancement, la dernière valeur déclarée pour une clé étant celle qui sera retenu dans notre tableau final.
+
+
Groupes de groupes
+
+ La hiérarchie de groupe d'un inventaire peut avoir plusieurs niveaux. Il est donc possible d'avoir de l'imbrication de groupes. Attention toutefois à ne pas en abuser afin de ne vous perdre dans des arborescence trop complexes.
+
+
+
Complétons pour finir notre inventaire groups.yml afin d'obtenir le contenu suivant:
Reprendre les différents fichiers contenu dans notre répertoire inventories et les compiler en un seul et même fichier hosts.yml, les autres fichiers ne sont finalement plus utiles et peuvent être supprimés.
+
Souvenez-vous vous pouvez tester un fichier d'inventaire en particulier en le passant en paramètre de la commande ansible-inventory: ansible-inventory --list -i inventories/hosts.yml.
Nous avons vu qu'il existait différent plugin permettant de « lire » un inventaire (si,si au tout début), essayez d'écrire le même inventaire mais à un format différent (format ini par exemple).
Notre infrastructure est modeste, mais vous serez parfois amenés à travailler avec des infrastructures d'envergure et serez dans l'obligation de « cibler » certaines machines ou groupes de machines.
+Il est ainsi possible d'indiquer explicitement à Ansible quelles sont les machines à considérer pour une action donnée.
+
Certains « patterns » sont très simple et vous devriez en reconnaitre certains:
+
Le « wildcard » * par exemple qui désignera n'importe quelle valeur et qui est utilisable au sein d'une valeur de clé ip ou hostname (192.168.140.* ou encore *.example.com).
+
Ceux que vous rencontrerez le plus souvent: :, :& ou encore :!.
L'opérateur :! permettra de cibler une machine qui est dans un groupe mais pas dans un autre par exemple membre du groupe webservers mais non présente dans le groupe production.
Il est bien évidemment possible de combiner les opérateurs prenez toutefois garde aux expressions trop complexes qui gêneront à la compréhension et pourront être source d'erreur !
+
On peut donc imaginer des choses comme cibler les machines du groupe webservers OU staging mais qui ne sont pas dans production (On est d'accord, ça n'a aucune sens c'est pour l'exemple ;)).
Nous aurons donc vu que les inventaires bien qu'à priori relativement simples, peuvent amener une forme de complexité sur des infrastructures volumineuses, leur organisation peut donc vite devenir stratégique notamment dans l'optique de faciliter la maintenance du parc piloté par Ansible.
+
Dans la prochaine étape nous aborderons une nouvelle notion d'Ansible, les playbooks qui nous permettront d'écrire nos première tâches !
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.
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 du projet Manala..
+
D'une paire de clés SSH que vous aurez pris soin de générer (voir ici) 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 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.
+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.
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 debian@XXX.XXX.XXX.XXX
+
Si vous rencontrez des soucis .. forbidden (exemple) ré-essayez en ajoutant explicitement le chemin vers la clé.
+
ssh -i ~/.ssh/ed25519 debian@XXX.XXX.XXX.XXX
+
+
Utilisateur sous Windows
+
+ Pour rappel aux utilisateurs de Windows vous trouverez ce répertoire .ssh dans C:\Users\MonNomUtilisateur\
+
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
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.
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:
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.
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.
+
+
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):
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:
+
+
+
+ Utilisation du module ping avec Ansible.
+
+
+
+
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 !
La très grande majorité des accès serveurs sont aujourd'hui basés sur leur utilisation, au dela de l'aspect fluidité et sécurité, elle ouvre également la possibilité d'authorisation multiple (sur plusieurs serveurs), de révocation et de signature des accès facilités.
+
+
Secure Shell (SSH)
+
+ Secure Shell (SSH) est à la fois un programme informatique et un protocole de communication sécurisé.
+ Le protocole de connexion impose un échange de clés de chiffrement en début de connexion. Par la suite, tous les segments TCP sont authentifiés et chiffrés. Il devient donc impossible d'utiliser un sniffer pour voir ce que fait l'utilisateur.
+ Le protocole SSH a été conçu avec l'objectif de remplacer les différents protocoles non chiffrés comme rlogin, telnet, rcp et rsh.
+
Le principe de l'authentification par clés repose, comme explicité sur les différents liens ci-dessus, par la création d'une paire de clés asymétriques.
+L'une de ces clés sera votre clé publique à déployer sur les machines auxquelles vous avez le droit de vous connecter, l'autre, votre clé privée. Et comme son nom l'indique, celle-ci est à vous et rien qu'à vous ; elle ne se partage pas. JAMAIS.
+
Deux notions de base avant de se lancer pour bien comprendre ce que l'on fait:
+
+
Il existe plusieurs types d'algorithmes de signature numérique, les plus répandus étant RSA et Ed25519;
+
Il est possible de spécifier la longueur de vos clés, ce paramètre est essentiel à leur robustesse.
+
+
Il est recommandé, à la date de rédaction de cet article, d'utiliser l'algorithme Ed25519 qui a plusieurs avantages comparativement à RSA:
+
+
Robustesse accrue;
+
Plus petite taille de clés;
+
Génération des clés plus rapide.
+
+
ssh-keygen -t ed25519 -a 150 -C "courriel@example.com"
+
+
+
+ Génération d'une paire de clé SSH
+
+
+
L'option -C permet d'ajouter un commentaire à votre clé, pratique notamment pour identifier le propriétaire d'une clé publique coté serveur.
+
+
Phrase de passe
+
+ Bien que facultative, il est « extrêmement vachement recommandé » de disposer d'une phrase de passe sur vos clés SSH (dans le cadre des cours et pour gagner du temps il est possible de s'en passer si vous n'utilisez pas votre clé en dehors de ceux-ci).
+
+
+
Cette commande vous aura généré deux fichiers dans le répertoire ~/.ssh/ (sauf si vous l'avez modifié bien évidemment):
+
+
id_ed25519.pub (comme son extension l'indique c'est votre clé publique);
+
id_ed25519 votre clé privée (on remarquera les droits qui lui sont appliqués 0600, en effet seul votre utilisateur doit y avoir accès).
+
+
+
Générer une clé RSA
+
+ Ed25519 n'étant de temps en temps pas supporté (surtout par les anciens systèmes) il est parfois nécessaire de générer une paire de clé RSA (on remarquera la longueur de clé de 4096 bits recommandée à date de rédaction de l'article):
+ ssh-keygen -t rsa -a 150 -b 4096
+
C'est un peu la finalité.
+Imaginons un serveur pour lequel votre clé est autorisée à se connecter (pour rappel fichier authorized_keys), nous pouvons initier une connexion à l'aide de la commande:
+
ssh user@server_address
+
Cette commande aura donc pour effet « d'ouvrir » une connexion sur un serveur distant via le protocol SSH vous permettant de saisir des lignes de commande directement sur ce serveur et donc de l'administrer.
+
+
+
+ Ouverture d'une session sur un serveur distant
+
+
+
Cette exemple montre l'ouverture d'une session avec l'utilisateur debian sur le serveur ayant pour adresse IP 146.59.243.95.
+
Plusieurs choses à retenir à cette étape:
+
+
Par défaut ssh parcourt les clés SSH privées disponibles dans le répertoire ~/.ssh afin de les proposer au serveur auquel vous essayez de vous connecter.
+
Vous optenez en retour la première fois que vous vous connectez un message vous demandant de confirmer la connexion vers le serveur distant (Host key checking).
Si vous disposez de plusieurs clés SSH et que vous ne souhaitez pas que l'ensemble de vos clés privées soient soumises au serveur distant vous pouvez spécifier quelle clé utiliser en utilisant l'option -i.
Ansible est une plateforme open-source de gestion de configuration et d'automatisation des tâches.
+Elle permet aux administrateurs système mais aussi aux développeurs de définir des configurations, des déploiements et des actions à effectuer sur des serveurs et des infrastructures de manière reproductible.
+
Ansible se distingue par sa simplicité d'utilisation grâce à sa syntaxe déclarative en YAML, qui décrit l'état souhaité du système. Il n'exige aucune installation d'agent sur les machines cibles, fonctionne via SSH ou d'autres protocoles, et offre une grande flexibilité pour automatiser des opérations complexes, la gestion de configurations, et le déploiement d'applications.
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+
+
+ Une typo ? + Modifier cet article sur Github +
+