Création de pipelines GitLab CI/CD avec l’intégration AWS / Blogs / Perficient

Création de pipelines GitLab CI/CD avec l’intégration AWS

GitLab CI/CD (Continuous Integration/Continuous Deployment) est un ensemble d’outils puissants et intégrés dans GitLab qui automatise le cycle de vie de développement logiciel (SDLC). Il simplifie le processus de création, de test et de déploiement du code, permettant aux équipes de fournir des logiciels de haute qualité plus rapidement et plus efficacement.

Comprendre GitLab CI/CD

Démarrer avec GitLab CI/CD est simple. Commencez par créer un compte GitLab et mettre en place un projet pour votre application si vous n’en avez pas puis installez et configurez un GitLab Runner, un outil chargé d’exécuter les tâches définies dans votre fichier .gitlab-ci.yml. Le programme d’exécution gère la création, les tests et le déploiement de votre code, garantissant ainsi que le pipeline fonctionne comme prévu. Cette configuration rationalise votre processus de développement et permet d’automatiser efficacement les flux de travail.

Qu’est-ce qu’un pipeline GitLab ?

Un pipeline automatise le processus de création, de test et de déploiement d’applications. CI (Continuous Integration) signifie fusionner régulièrement les modifications de code dans un référentiel partagé. Le CD (Continuous Deployment/Delivery) automatise la publication de l’application sur son environnement cible.

CODE associé: Au cours de cette étape, vous transférez vos modifications de code local vers le référentiel distant et validez toutes les mises à jour ou modifications.

Pipeline CI: Une fois vos modifications de code validées et fusionnées, vous pouvez exécuter les tâches de build et de test définies dans votre pipeline. Une fois ces tâches terminées, le code est prêt à être déployé dans les environnements de test et de production.

Termes importants dans GitLab CI/CD

1. Fichier .gitlab-ci.yaml

Un fichier .gitlab-ci.yml dans un référentiel GitLab est utilisé pour définir la configuration du pipeline d’intégration continue/déploiement continu (CI/CD). Ce fichier contient des instructions sur la création, le test et le déploiement de votre projet.

2. Gitlab-Runner

Dans GitLab CI/CD, un « runner » fait référence à l’agent qui exécute les tâches définies dans la configuration du pipeline .gitlab-ci.yml. Les coureurs peuvent être partagés ou spécifiques au projet.

Voici comment fonctionnent les coureurs :

1. Coureurs partagés: GitLab fournit des exécuteurs partagés disponibles pour tous les projets au sein d’une instance GitLab. Ces exécuteurs sont gérés par les administrateurs GitLab et peuvent être utilisés par n’importe quel projet. Les coureurs partagés sont pratiques si nous ne voulons pas configurer et gérer nos propres coureurs.
2. Coureurs spécifiques: Nous pouvons également mettre en place nos propres coureurs dédiés à notre projet. Ces exécuteurs peuvent être déployés sur notre infrastructure (par exemple, des serveurs sur site, des instances cloud) ou en utilisant diverses méthodes telles que Docker, Kubernetes, Shell ou Docker Machine. Les exécuteurs spécifiques offrent plus de contrôle sur l’environnement d’exécution et peuvent être personnalisés pour répondre aux besoins spécifiques de notre projet.

3. Pipeline:

Les pipelines sont constitués de tâches et d’étapes :

• Emplois définissez ce que vous voulez faire. Par exemple, testez les modifications du code ou déployez dans un environnement de développement.
• Les emplois sont regroupés en étapes. Chaque étape contient au moins un travail. Les étapes courantes incluent la création, le test et le déploiement.
• Vous pouvez exécuter le pipeline manuellement ou à partir du travail de planification du pipeline.

Tout d’abord, cela signifie manuellement la validation directe, lorsque vous fusionnez ou validez des modifications dans le pipeline de code, déclenchez directement.

Et deuxièmement, en utilisant des règles pour cela, vous devez créer une tâche planifiée.

4. Planifier le travail:

Nous utilisons des tâches planifiées pour automatiser l’exécution du pipeline. Pour créer une tâche planifiée, procédez comme suit :

1. Accédez aux paramètres de planification: Accédez à Créer, sélectionnez Planifications de pipeline, puis cliquez sur Créer une nouvelle planification.
2. Configurer les détails de la planification:
   1. Description: saisissez un nom pour la tâche planifiée.
   2. Fuseau horaire de Cron: Définissez le fuseau horaire en fonction de vos besoins.
   3. Modèle d’intervalle: définissez la planification cron pour déterminer quand le pipeline doit s’exécuter. Si vous préférez l’exécuter manuellement en cliquant sur le bouton de lecture lorsque nécessaire, décochez le bouton Activer à la fin.
   4. Branche cible: Spécifiez la branche où la tâche cron sera exécutée.
3. Ajouter des variables: Incluez toutes les variables mentionnées dans la section règles de votre fichier .gitlab-ci.yml pour garantir que le pipeline fonctionne correctement.
   1. Clé de variable d’entrée = SCHEDULE_TASK_NAME
   2. Valeur de la variable d’entrée = prft-deployment

Démo

Conditions préalables pour GitLab CI/CD

• Compte et projet GitLab : Vous avez besoin d’un compte GitLab actif et d’un référentiel de projet pour stocker votre code source et configurer des workflows CI/CD.
• Environnement du serveur : Vous devriez avoir accès à un environnement de serveur, comme un cloud AWS, sur lequel vous installez gitlab-runner.
• Contrôle des versions : L’utilisation d’un système de contrôle de version comme Git est essentielle pour gérer efficacement votre code source. Avec Git et un référentiel GitLab, vous pouvez facilement suivre les modifications, collaborer avec votre équipe et revenir aux versions précédentes si nécessaire.

Configurer Gitlab-Runner

• Lancez une instance AWS EC2 avec le système d’exploitation de votre choix. Ici, j’ai utilisé Ubuntu. Configurez l’instance avec les paramètres de base en fonction de vos besoins.
• Connectez-vous en SSH à l’instance EC2 et suivez les étapes ci-dessous pour installer GitLab Runner sur Ubuntu.

1. sudo apt install -y curl
2. boucle -L https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh | sudo bash
3. sudo apt installer gitlab-runner

Après avoir installé GitLab Runner, procédez à son enregistrement. Accédez à GitLab, accédez à Paramètresalors CI/CDet sous Coureurscliquez sur les trois points pour accéder aux options d’inscription.

Et copiez-collez le cmd ci-dessous :

Exécutez la commande suivante sur votre instance EC2 et fournissez les détails nécessaires pour configurer le programme d’exécution en fonction de vos besoins :

1. URL: Appuyez sur Entrée pour le conserver par défaut.
2. Jeton: Utilisez le jeton par défaut et appuyez sur Entrée.
3. Description: Ajoutez une brève description du coureur.
4. Balises: C’est critique ; les noms de balises définissent votre GitLab Runner et sont référencés dans votre fichier .gitlab-ci.yml.
5. Remarques: Ajoutez des notes supplémentaires si nécessaire.
6. Exécuteur: Choisissez Shell comme exécuteur.

Vérifiez l’état du GitLab-runner et l’état actif à l’aide de la commande ci-dessous :

• vérification de gitlab-runner
• liste des coureurs gitlab

Vérifiez également que gitlab-runner est actif dans gitlab :

Accédez à GitLab, puis accédez à Paramètres et sélectionnez Coureurs GitLab.

Configurer le fichier gitlab-ci.yaml

• Étapes : étapes qui définissent la séquence dans laquelle les tâches sont exécutées.
• Build-job : ce travail est exécuté lors de la phase de construction, la première étape d’exécution.
  • Étape : construire
  • Scénario:
    • Echo « Compilation du code… »
    • Faites écho à « Compilation terminée. »
  • Règles:
    • si : ‘$CI_PIPELINE_SOURCE == « planification » && $SCHEDULE_TASK_NAME == « prft-deployment »‘
  • Balises :
• Deploy-job : ce travail est exécuté lors de la phase de déploiement.
  • Étape : déployer #Il ne s’exécutera que lorsque les deux tâches de la tâche de construction et de la tâche de test (si ajoutée) auront été terminées avec succès.
  • scénario:
    • Echo « Déploiement de l’application… »
    • Echo « Application déployée avec succès. »
  • Règles:
    • si : ‘$CI_PIPELINE_SOURCE == « planification » && $SCHEDULE_TASK_NAME == « prft-deployment »‘
  • Balises :

Remarque : Si nécessaire, vous pouvez ajouter une tâche de test similaire aux tâches BUILD et DEPLOY.

Exécuter le pipeline

Puisque la tâche Cron est déjà configurée dans le planning, cliquez simplement sur le bouton Jouer bouton pour déclencher automatiquement votre pipeline.

Pour vérifier l’état du pipeline, accédez à Build, puis à Pipeline. Une fois le travail de build terminé avec succès, le travail de test démarrera et une fois le travail de test terminé, le travail de déploiement démarrera.

Sortir

Nous avons terminé avec succès les tâches BUILD & DEPLOY.

Créer un travail

Déployer la tâche

Conclusion

Comme nous pouvons le voir, le pipeline de tâches BUILD & DEPLOY a réussi.

Nous avons fourni un bref aperçu des pipelines GitLab CI/CD et une démonstration pratique de la façon dont ses composants fonctionnent ensemble. Espérons que tout se passe bien de votre côté !