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

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.

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.