Toute la puissance de GitLab CI pour démontrer les playbooks Ansible avec l'infrastructure comme approche de code.
GitLab CI est un outil efficace pour une grande variété de scénarios, y compris l'infrastructure sous forme de code. GitLab peut être utilisé avec différents outils, mais dans cette démo, nous prendrons Ansible, car c'est précisément ce que les développeurs utilisent le plus souvent lorsqu'ils abordent «l'infrastructure en tant que code». Voici une démo avec deux routeurs du cours sur les réseaux Ansible .
La beauté de GitLab CI est que le code du playbook Ansible peut être modifié et fourni sans installer de dépendances localement. Un projet de démonstration qui entraîne la mise à jour mensuelle des chaînes SNMP sur tous les appareils conformément à notre politique de sécurité peut être entièrement réalisé sur GitLab.com , notre service d'hébergement de code.
Pour commencer, ouvrez le playbook Ansible, où il y a 4 tâches:
- Recueillir des faits sur les routeurs - collecter des faits sur les routeurs.
- Version d'affichage - version d'affichage
- Afficher le numéro de série
- Configurer SNMP - Configurer SNMP.
Dans cette démo, nous nous concentrerons sur la configuration des chaînes SNMP, pour lesquelles vous devez suivre quelques étapes simples.
À partir du tableau des tâches
Tout plan sur GitLab commence de la même manière: avec une tâche . Ainsi, la première étape du workflow GitLab consiste à vérifier le tableau des tâches dans le projet ansible-demo . Sur le tableau des tâches de démo ansible, nous voyons déjà la tâche: changer les lignes SNMP sur tous les routeurs . La tâche a un lien vers la page wiki de la politique de sécurité de GitLab, où elle indique que les lignes SNMP doivent être mises à jour chaque mois, et pour les opérations en lecture seule et en lecture et écriture, il devrait y avoir différentes lignes.
La politique de sécurité de GitLab prescrit la mise à jour mensuelle des chaînes SNMP.
Ensuite, vous devez vérifier que les commandes de configuration des chaînes SNMP dans la démonstration avec deux routeurs ne violent pas la politique de sécurité GitLab décrite dans la tâche.
Les commandes de configuration des chaînes SNMP sont disponibles sur le playbook Ansible.
Revenez ensuite à la tâche, attribuez-la à vous-même et modifiez le raccourci de tâches à doing dans le panneau de droite ou faites simplement glisser la tâche sur le tableau d'une colonne à l'autre.
Création d'une demande de fusion
Vous devez maintenant créer une demande de fusion à partir de la tâche. Assurez-vous que la demande de fusion a un indicateur Work in Progress (WIP) afin qu'elle ne pénètre pas dans l'Assistant prématurément. Au lieu de nous connecter localement, nous utilisons l' IDE Web GitLab car les modifications apportées aux lignes SNMP sont mineures.
- Ouvrez la section de démonstration CI / CD.
- Accédez au playbook Ansible.
- Modifiez la section SNMP comme suit:
- Veuillez noter que différentes lignes sont configurées pour RO et RW conformément à la politique de sécurité GitLab décrite dans la tâche .
Commit commit
Vous avez mis à jour la ligne SNMP conformément aux instructions et vous devez maintenant valider les modifications. Ouvrez une comparaison des modifications parallèles pour vous assurer que la demande de fusion contient la dernière validation.
L'outil de comparaison parallèle montre visuellement les changements.
Résultats
La validation des modifications lancera automatiquement le pipeline GitLab CI. Il effectuera les tâches suivantes:
- Vérification de la syntaxe
- Essais.
- Tester les changements dans un environnement de laboratoire / artificiel.
Nous voyons la progression et la sortie de chaque travail dans le pipeline GitLab CI qui met à jour SNMP.
La sortie de votre tâche montre que les mises à jour SNMP dans l'environnement artificiel ont réussi.
Toutes ces tâches seront lancées et documentées dans la demande de fusion.
Les coches indiquent que la tâche dans le pipeline GitLab CI est terminée.
Connectez-vous ensuite aux routeurs pour une démonstration et voyez les changements.
Les changements dans les chaînes SNMP RO et RW sont reflétés dans les routeurs.
Examen de la demande de fusion
Vous pouvez effectuer une étape supplémentaire - l' approbation de la demande de fusion . Si vous configurez l'approbation, plusieurs utilisateurs pourront vérifier les modifications avant leur mise en production.
La demande de fusion peut être configurée pour qu'un autre utilisateur vérifie vos travaux avant qu'ils n'apparaissent dans l'assistant.
Transfert au maître
Les modifications peuvent être soumises à l'assistant immédiatement après le test. Un assistant est la branche principale qui contient le code de l'espace de travail.
Lorsque vous êtes prêt, cliquez sur le bouton Resolve Work In Progress . Cliquez ensuite sur Merge .
Lorsque vous activez l'état WIP, la demande de fusion peut être envoyée à l'assistant et la tâche peut être fermée.
Le nouveau pipeline exécutera tous les tests que vous avez effectués à l'étape supplémentaire de lancement du playbook en production.
Gardez une trace des progrès et des journaux sur l'écran du pipeline. Une fois le processus terminé, connectez-vous aux routeurs qui fonctionnent et vérifiez que les lignes SNMP ont changé.
Magic GitLab CI
Tout cela est possible grâce à la magie de GitLab CI. Les pipelines GitLab CI sont une série de tâches séquentielles qui effectuent tout le nécessaire pour tester et implémenter le code Ansible.
La configuration complète de GitLab CI tient dans un simple fichier YAML, qui est stocké dans le .gitlab-ci.yml .
Dans cette démo, le .gitlab-ci.yml contient 3 étapes.
- Déployer (Déploiement): crée un réseau simulé avec deux routeurs dans AWS à l'aide d'Ansible.
- Démo: Effectue un playbook qui changera les lignes SNMP.
- Détruire: détruit un réseau simulé avec deux routeurs.
GitLab CI commence par une image de base. Dans ce cas, nous utilisons l'image Docker, qui contient tout le code nécessaire et les dépendances Ansible. Indiquez les commandes qui seront exécutées à chaque étape et les dépendances.
Un fichier YAML simple contient trois étapes de GitLab CI.
La phase de démonstration de GitLab CI, qui exécute le playbook Ansible.
Nous avons regardé à l'intérieur du pipeline et avons vu comment vous pouvez utiliser GitLab CI pour créer une infrastructure en tant que code sans même installer les dépendances Ansible sur votre ordinateur. Ceci n'est qu'un exemple de la manière dont GitLab CI peut être utilisé pour implémenter l'infrastructure en tant que code. Voir la vidéo pour un guide complet: