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:
Cet article n'est pas encore publié. Cet aperçu est disponible uniquement dans cet environnement mais n'apparaîtra en production qu'à partir du 27 novembre 2023
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érents 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 ;)).
+
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 jeux 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'inventaire dynamiques que nous verrons plus tard.
-
Les inventaires, on le verra permettre également de structurer / hiérarchiser nos machines en utilisant une notion de groupe.
+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 la commande:
Un inventaire n'est en fait ni plus ni moins d'un ou plusieurs fichiers spécifiant 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 guider par le besoin métier bien éviemment on pourra citer comme contraintes par exemple:
+
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 de machines)
-
Leur localisation géographique (Pays, ville...)
+
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.
@@ -352,24 +363,24 @@
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:
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.
+
Reprendre les différents fichiers contenu dans notre répertoire inventories et les compiler en un seul et même fichier hosts.yml.
+
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),
+
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 amenez à 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 « pattern » sont très simple et vous devriez en reconnaitre certains:
+
Le « wildcard » * par exemple qui désignera n'importe quelle valeur 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 :!.s
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 ;)).
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.
+ 
+ 
+ 
+
+ Une typo ? + Modifier cet article sur Github +
+