Tools/Ansible/Infrastructure As Code

Accueil	SysAdmin	Hobbies

Ansible - Infrastructure As Code

L'un des concepts clés de DevOps est la notion d'infrastructure sous forme de code. Au lieu de gérer votre infrastructure manuellement, vous définissez et créez vos systèmes en exécutant votre code d'automatisation. Red Hat Ansible Automation est un outil clé qui peut vous aider à mettre en oeuvre cette approche.

Si les projets Ansible sont le code utilisé pour définir l'infrastructure, un système de contrôle de version tel que Git doit être utilisé pour suivre et contrôler les modifications apportées au code.

Le contrôle de version vous permet de mettre en oeuvre un cycle de vie pour les différents stades de votre code d'infrastructure, comme le développement, l'assurance qualité et la production. Vous pouvez valider les modifications apportées à une branche et tester ces modifications dans les environnements de développement et d'assurance qualité non critiques. Une fois que les modifications vous conviennent, vous pouvez les fusionner avec le code de production principal et appliquer les modifications à votre infrastructure de production.

GIT

Documentation officielle de GIT

Références rapides de GIT

Principales commandes GIT
Commande	Description
git clone URL	Cloner un projet Git existant à partir du dépôt distant à l'URL dans le répertoire courant.
git status	Afficher l'état des fichiers modifiés et indexés dans l'arborescence de travail.
git add file	Indexer un fichier nouveau ou modifié pour la prochaine validation.
git rm file	Indexer la suppression d'un fichier pour la prochaine validation.
git commit	Valider les fichiers indexés dans le dépôt local avec un message descriptif.
git push	Transmettre par push au dépôt distant les modifications apportées au dépôt local.
git pull	Extraire les mises à jour du dépôt distant vers le dépôt local et les fusionner dans l'arborescence de travail.
git revert commit_ref	Créer une validation en annulant les modifications dans la validation référencée. Le hachage de validation qui identifie la validation peut être utilisé, même s'il existe d'autres moyens de référencer une validation.

Présentation de GIT

Git est un système de contrôle de version distribué (DVCS, Distributed Version Control System) qui permet aux développeurs de gérer les modifications apportées aux fichiers d'un projet de manière collaborative. Chaque révision d'un fichier est validée dans le système. Les anciennes versions des fichiers peuvent être restaurées, et un journal de l'auteur des modifications est conservé. Les systèmes de contrôle de version présentent de nombreux avantages, notamment :

• la possibilité de réviser et de restaurer les anciennes versions des fichiers ;
• la possibilité de comparer deux versions du même fichier pour identifier les modifications ;
• un enregistrement ou un journal de l'auteur des modifications, ainsi que le moment où ces modifications ont été apportées ;
• des mécanismes permettant à plusieurs utilisateurs de modifier des fichiers de manière collaborative, de résoudre les modifications conflictuelles et de fusionner les modifications ensemble.

Git est un système de contrôle de version distribué. Chaque développeur peut commencer par cloner un projet partagé existant à partir d'un dépôt distant. Le clonage d'un projet crée une copie complète du dépôt distant d'origine en tant que dépôt local. Il s'agit d'une copie locale de l'intégralité de l'historique des fichiers dans le système de contrôle de version, et pas seulement de l'instantané le plus récent des fichiers de projet.

Le développeur apporte des modifications dans une arborescence de travail, qui est une extraction d'un seul instantané du projet. Un ensemble de modifications connexes est ensuite indexé et validé dans le dépôt local. À ce stade, aucune modification n'a été apportée au dépôt distant partagé. Lorsque le développeur est prêt à partager son activité, il transmet par push les modifications au dépôt distant. Sinon, si le dépôt local est accessible à partir du réseau, le propriétaire du dépôt distant peut extraire les modifications du dépôt local du développeur vers le dépôt distant. De même, lorsqu'un développeur est prêt à mettre à jour son dépôt local avec les dernières modifications apportées au dépôt distant, il peut extraire les modifications du dépôt distant et les fusionner dans le dépôt local. Pour utiliser Git de manière efficace, un utilisateur doit connaître les trois états possibles d'un fichier dans l'arborescence de travail : modifié, indexé ou validé.

• Modifié : la copie du fichier dans l'arborescence de travail a été éditée et diffère de la version la plus récente figurant dans le dépôt.
• Indexé : le fichier modifié a été ajouté à une liste de fichiers modifiés pour être validé en tant qu'ensemble, mais il n'a pas encore été validé.
• Validé : le fichier modifié a été validé dans le dépôt local.

Une fois le fichier validé dans le dépôt local, la validation peut être transmise par push au dépôt distant ou extraite par celui-ci.

DESCRIPTION DE LA CONFIGURATION GIT INITIALE

Étant donné que les utilisateurs de Git modifient fréquemment des projets avec plusieurs contributeurs, Git enregistre le nom et l'adresse électronique de l'utilisateur à chacune des validations. Ces valeurs peuvent être définies au niveau projet, mais les paramètres par défaut globaux peuvent également être définis pour un utilisateur. La commande git config contrôle ces paramètres. L'utilisation de cette commande avec l'option --global gère les paramètres par défaut de tous les projets Git auxquels l'utilisateur contribue en enregistrant les paramètres dans son fichier ~/.gitconfig.

[user@demo ~]$ git config --global user.name 'Franck H'
[user@demo ~]$ git config --global user.email frh@host.example.com

Si bash est le shell de l'utilisateur, un autre paramètre facultatif, qui est utile, consiste à configurer votre invite de façon à ce qu'elle soit automatiquement modifiée pour signaler l'état de votre arborescence de travail. La méthode la plus simple consiste à utiliser le script git-prompt.sh fourni avec le paquetage git. Pour modifier votre invite de shell de cette façon, ajoutez les lignes suivantes au fichier ~/.bashrc. Si votre répertoire courant se trouve dans une arborescence de travail Git, le nom de la branche Git actuelle de l'arborescence de travail est affiché entre parenthèses. Si vous disposez de fichiers non suivis, modifiés ou indexés qui ne sont pas validés dans votre arborescence de travail, l'invite indique ce qui suit :

• (branch *) signifie qu'un fichier suivi est modifié
• (branch +) signifie qu'un fichier suivi est modifié et indexé avec git add
• (branch %) signifie que les fichiers non suivis se trouvent dans votre arborescence
• Des combinaisons de marqueurs sont possibles, telles que (branch *+)

source /usr/share/git-core/contrib/completion/git-prompt.sh
export GIT_PS1_SHOWDIRTYSTATE=true
export GIT_PS1_SHOWUNTRACKEDFILES=true
export PS1='[\u@\h \W$(declare -F __git_ps1 &>/dev/null && __git_ps1 " (%s)")]\$ '

LE WORKFLOW GIT

Lorsque vous travaillez sur des projets partagés, l'utilisateur Git clone un dépôt existant en amont à l'aide de la commande git clone. Le nom de chemin d'accès ou l'URL fourni détermine le dépôt qui est cloné dans le répertoire courant. Une arborescence de travail est également créée de sorte que le répertoire des fichiers soit prêt pour des révisions. Étant donné que l'arborescence de travail n'est pas modifiée, son état initial est propre. Par exemple, la commande suivante clone le dépôt project.git sur git.lab.example.com, avec une connexion à l'aide du protocole SSH et d'une authentification en tant qu'utilisateur git :

[user@demo ~]$ git clone git@git.lab.example.com:project.git

NOTE Un autre moyen de démarrer le workflow Git consiste à créer un projet privé à l'aide de la commande git init. Lorsqu'un projet est lancé de cette manière, aucun dépôt distant n'est créé.

Lors de la phase de développement, des fichiers sont créés et les fichiers existants sont modifiés dans l'arborescence de travail. L'arborescence de travail passe alors à un état modifié.

• La commande git status affiche des informations détaillées sur les fichiers de l'arborescence de travail qui sont modifiés, mais non indexés, non suivis (nouveau) ou indexés pour la validation suivante.
• La commande git add indexe les fichiers, en les préparant à être validés. Seuls les fichiers qui sont indexés dans la zone d'indexation sont enregistrés dans le dépôt lors de la validation suivante. Si un utilisateur travaille sur deux modifications en même temps, les fichiers peuvent être organisés en deux validations pour un meilleur suivi des modifications. Un ensemble demodifications est indexé et validé, puis les autres modifications sont indexées et validées.
• La commande git rm supprime un fichier du répertoire de travail et indexe également sa suppression du dépôt pour la validation suivante.
• La commande git reset supprime de la zone d'indexation un fichier qui a été ajouté pour la prochaine validation. Cette commande n'a aucun effet sur le contenu du fichier dans l'arborescence de travail.
• La commande git commit valide les fichiers indexés dans le dépôt Git local. Un message de journal doit être fourni pour expliquer les raisons pour lesquelles l'ensemble actuel de fichiers indexés est enregistré. Si vous ne spécifiez pas de message, la validation est abandonnée. Les messages de journal ne doivent pas être longs, mais ils doivent être explicites pour être utiles.

IMPORTANT La commande git commit en elle-même ne valide pas automatiquement les fichiers modifiés dans l'arborescence de travail. La commande git commit -a indexe et valide les fichiers modifiés en une seule étape. Cependant, cette commande n'inclut aucun fichier non suivi (nouvellement créé) dans le répertoire. Lorsque vous ajoutez un nouveau fichier, vous devez explicitement git add ce fichier pour l'indexer la première fois, de sorte qu'il soit suivi pour les futures commandes git commit -a.

NOTE Les messages de validation explicites et concis sont essentiels pour conserver un historique clair d'un projet Ansible. Il existe de nombreuses façons de créer un bon message de validation, mais la plupart d'entre elles reprennent les trois points suivants : La première ligne doit être un résumé court (généralement inférieur à 50 caractères) de la raison de la validation. Une ligne vierge suit, puis le reste du message doit expliquer tous les détails et les raisons de la validation. Le cas échéant, ajoutez des références à un problème ou à des entrées relatives au suivi des fonctions. Ces références étendent le message de validation avec du texte supplémentaire, des personnes associées ou un historique.

• La commande git push envoie au dépôt distant les modifications apportées au dépôt local. Afin de coordonner les tâches avec Git, tous les développeurs doivent transmettre par push leur travail au même dépôt distant partagé.

Pour que les transmissions par push de Git puissent fonctionner, il convient de définir la méthode push par défaut. La commande suivante définit la valeur simple de la méthode par défaut de transmission par push. Il s'agit de l'option la plus sûre pour les débutants.

[user@demo ~]$ git config --global push.default simple

• La commande git pull extrait les validations à partir du dépôt distant et les ajoute au dépôt local. Elle fusionne également les modifications apportées aux fichiers dans votre arborescence de travail.

Cette commande doit être fréquemment exécutée pour que les modifications apportées au projet par les autres utilisateurs dans le dépôt distant soient constamment à jour.

NOTE Une autre méthode pour effectuer des validations à partir du dépôt distant git fetch consiste à télécharger les modifications du dépôt distant dans votre dépôt local, puis à utiliser git merge pour fusionner les modifications de la branche de suivi dans votre branche actuelle.

Notions de branches

Les modifications apportées à un dépôt Git sont regroupées en validations. Une validation contient toutes les informations dont Git a besoin pour créer et gérer l'historique de l'ensemble du dépôt, notamment :

• Un ID unique pour la validation, sous la forme d'une chaîne de 40 caractères hexadécimaux. Cet ID est le hachage SHA-1 du contenu de la validation.
• La liste des fichiers du dépôt qui ont changé et les modifications apportées à chacun d'eux. Les modifications peuvent être des ajouts ou des soustractions de lignes, des changements de noms ou des suppressions.

• L'ID de la validation parente. Autrement dit, l'ID de la validation définissant l'état du dépôt avant d'appliquer les modifications de validation actuelles.
• L'auteur et le créateur (ou validateur) de la validation.
• Enfin, mais très important, une validation inclut également une liste de références. Une référence ressemble à un pointeur nommé vers la validation. La plupart des références courantes sont des balises et des branches.

La commande git commit génère une nouvelle validation avec toutes les modifications ajoutées lors de l'étape d'indexation à l'aide de la commande git add. Vous pouvez imaginer un dépôt Git comme un graphique de validation, et les branches comme des références à des validations.

La figure ci-dessus décrit un exemple de dépôt Git contenant 11 validations. Les validations les plus récentes se trouvent à droite, les flèches pointent vers les anciennes validations. Il contient trois branches (master, feature/1 et feature/2) et une balise unique (tag/1.0). La référence HEAD est la validation actuelle dans l'arborescence de travail locale. Si vous modifiez votre arborescence de travail, indexez-la à l'aide de la commande git add et validez-la à l'aide de la commande git commit. Une nouvelle validation est créée avec la validation la plus récente en tant que parent, et HEAD est déplacé pour pointer vers la nouvelle validation.

Création de branches

Des branches différentes dans Git permettent à différents flux de travail d'évoluer en parallèle sur le même dépôt Git. Les validations pour chaque flux de travail sont ajoutées uniquement à cette branche. Utilisez la commande git branch pour créer une branche à partir de la validation HEAD actuelle. Cette commande crée une référence pour la nouvelle branche, mais elle ne définit pas la référence HEAD actuelle sur cette branche. Utilisez la commande git checkout pour déplacer HEAD vers la branche appropriée.

Dans l'exemple précédent, la validation la plus récente pour la branche master (et HEAD à ce stade) a été validée 5749661, qui a eu lieu à un moment donné dans le passé. Un utilisateur a exécuté la commande git branch feature/1, ce qui a créé la branche feature/1. Ensuite, l'utilisateur a exécuté git checkout feature/1 pour indiquer que des validations ultérieures doivent être apportées à cette branche. Enfin, l'utilisateur a indexé et effectué deux validations dans la branche feature/1, les validations 60c6c2c et 8f7c801. Après avoir exécuté ces commandes, HEAD a été au point de validation 8f7c801 et les nouvelles validations ont été ajoutées à la branche feature/1. Ensuite, l'utilisateur a voulu ajouter des validations à la branche master. Après avoir déplacé HEAD vers la dernière validation sur cette branche, en exécutant la commande git checkout master, deux nouvelles validations ont été effectuées : 96e9ce7 et 44bd644. HEAD a pointé vers 44bd644, et les validations ont été ajoutées à la branche master.

Fusion de branches

Lorsque le travail est terminé sur une branche, la branche peut être fusionnée avec la branche d'origine. Cela permet de travailler en parallèle sur les nouvelles fonctions et les nouveaux correctifs de bogue, tandis que la branche principale est exempte de travail incomplet ou non testé.

Dans l'exemple précédent, il a été déterminé que toutes les modifications apportées à feature/2 doivent être fusionnées dans la branche master. Autrement dit, quelqu'un a souhaité que la validation la plus récente de master soit le résultat de toutes les validations des deux branches.

Ce résultat a été obtenu en commençant par exécuter la commande git checkout master pour s'assurer qu'HEAD soit sur la branche master validée, e8ce346. Ensuite, la commande git merge feature/2 a été exécutée. Cette commande a créé une validation, 5749661, rassemblant toutes les validations de feature/2, ainsi que toutes les validations à partir de master. HEAD a été déplacé vers la dernière validation.

Parfois, les modifications apportées à plusieurs branches ne peuvent pas être automatiquement fusionnées, car chaque branche apporte des modifications aux mêmes parties des mêmes fichiers. Cette situation est appelée un conflit de fusion et doit être résolue manuellement en modifiant les fichiers concernés.

Création de branches à partir d'anciennes validations

Utilisez la commande git checkout pour déplacer HEAD vers n'importe quelle validation. Par exemple, la commande git checkout 790dd94 déplace HEAD vers cette validation. Ensuite, une nouvelle branche commençant par cette validation peut être créée à l'aide des commandes git branch et git checkout. Par exemple, il est possible de créer une branche à partir d'une validation spécifique pour ignorer d'autres modifications récentes apportées à une branche. Vous pouvez créer une branche et basculer vers celle-ci en une seule étape, en exécutant la commande git checkout avec l'option -b :

[user@demo ~]$ git checkout -b feature/2
Switched to a new branch 'feature/2'

NOTE Si vous avez besoin d'une validation à un moment ultérieur donné, vous pouvez utiliser git tag pour placer une étiquette pense-bête sur celle-ci (comme tag/1.0 dans l'exemple), puis exécuter la commande git checkout sur cette balise pour basculer vers la validation souhaitée.

Transmission par push de branches à des dépôts distants

Initialement, toutes les branches que vous créez existent uniquement dans votre dépôt local. Si vous souhaitez les partager avec des utilisateurs du dépôt distant d'origine que vous avez clonés, vous devez les transmettre par push au dépôt comme vous le feriez pour une validation.

La méthode la plus courante pour y parvenir consiste à utiliser la commande git push avec l'option --set-upstream (ou -u) pour créer une branche sur le dépôt distant qui sera suivi par votre branche locale actuelle.

Par exemple, pour transmettre par push votre nouvelle branche feature/2 à votre dépôt distant, exécutez les commandes suivantes :

[user@demo ~]$ git checkout feature/2
Switched to branch 'feature/2'
[user@demo ~]$ git push --set-upstream origin feature/2

Le dépôt distant d'origine fait normalement référence au dépôt Git que vous avez initialement cloné. Cette commande indique que vous souhaitez transmettre par push la branche actuelle au dépôt, en créant feature/2 et en configurant Git de sorte que la commande git push sur cette branche transmette par push des validations au dépôt distant. L'exécution de la commande git pull sur cette branche entraîne l'extraction et la fusion de toutes les validations du dépôt distant dans votre copie locale de la branche.

Création de la structure des projets Ansible dans Git

Chaque projet Ansible doit disposer de son propre dépôt Git. La structure des fichiers dans ce dépôt doit suivre les pratiques recommandées pour Ansible documentées à l'adresse Ansible playbooks, best practices.

Par exemple, la structure du répertoire peut ressembler à ceci :

site.yml        # MASTER PLAYBOOK includes other playbooks
webservers.yml  # playbook for webserver tier
dbservers.yml   # playbook for dbserver tier
library/        # for custom modules (optional)
filter_plugins/ # for custom filter plugins (optional)
roles/          # directory for roles
  webserver/    # a particular role
           tasks/
                 main.yml         # tasks for the role, can include other files
           defaults/
                    main.yml      # default low-priority variables for the role
           templates/
                    httpd.conf.j2 # a Jinja2 template used by the role
           files/
                 motd             # a file used by the role
           handlers/
                   main.yml       # handlers used by the role
           meta/
                main.yml          # role information and dependencies
...additional roles...

IMPORTANT Une bonne gestion des rôles demandent de la réflexion. Si vos rôles sont gérés dans le cadre du playbook, il peut être utile de les conserver dans le playbook. Cependant, la plupart des rôles sont destinés à être partagés par plusieurs projets, et si chaque projet dispose de sa propre copie de chaque rôle, ils peuvent diverger, annulant ainsi les avantages de l'utilisation des rôles.

Un rôle doit disposer de son propre dépôt Git. Certaines personnes essaient d'inclure des dépôts de rôle dans leurs dépôts de projet en utilisant une fonction avancée de Git appelée sousmodules. Étant donné que les sous-modules peuvent être difficiles à gérer correctement, cette approche n'est pas recommandée. Une meilleure approche consiste à configurer votre projet avec un répertoire vide roles/ et à utiliser ansible-galaxy pour remplir ce répertoire avec la version la plus récente des rôles à partir de leurs dépôts Git avant d'exécuter les playbooks. Assurez-vous qu'aucun sous-répertoire ne soit validé dans roles/ en plaçant un fichier README dans le répertoire expliquant ce que vous faites et en validant un fichier .gitignore en haut du dépôt Git de votre projet pour indiquer à Git d'ignorer les répertoires dans roles/ :

roles/*/*