Aller au contenu principal

Maitrisez les templates Gitlab CI/CD

Dans le domaine du DevOps, l'efficacité et la fiabilité des processus de Continuous Integration/Continuous Deployment (CI/CD) sont importants. GitLab, en tant que plateforme intégrée, offre des outils puissants pour automatiser ces processus. Cependant, avec le nombre et la complexité croissants des projets, la gestion des pipelines CI/CD peut devenir fastidieuse et sujette à erreurs. C'est là qu'intervient le concept de templates des pipelines GitLab CI/CD.

Mais pourquoi donc ?​

La factorisation des pipelines consiste à créer et à réutiliser des portions de code de pipeline pour en faciliter la maintenance. Cette approche s'aligne sur le principe DRY (Don't Repeat Yourself) de la programmation, visant à réduire la répétition du code source. En factorisant les pipelines, les équipes de développement peuvent mettre à jour des processus complexes en un seul endroit, garantissant ainsi une plus grande cohérence et facilité de gestion.

En outre, traiter le code des pipelines avec la même rigueur que le code de l'application elle-même est essentiel pour assurer la sécurité et l'optimisation. Dans un environnement où les déploiements fréquents et les changements rapides sont la norme, les pipelines CI/CD doivent être conçus pour être à la fois robustes et flexibles.

Notions importantes​

Avant de voir comment créer des templates Gitlab CI/CD, il est important d'introduire quelques notions.

Extends​

extends permet à un job d'hériter des configurations d'un autre, tout en lui permettant d'ajouter ou de surcharger certaines parties de cette configuration. Cela aide à éviter les répétitions et à garder les pipelines DRY (Don't Repeat Yourself).

Imaginons que vous ayez une configuration de base pour tous les jobs de test :

# .test_base.yml
.test_base:
  stage: test
  script:
    - echo "Exécution des pré-tests..."

Un job spécifique de test unitaire pourrait étendre cette base :

unit_test:
  extends: .test_base
  script:
    - echo "Exécution des tests unitaires..."
    - run-unit-tests.sh

Dans cet exemple, unit_test hérite du stage test et du script initial de .test_base, tout en ajoutant ses propres étapes de script.

Les ancres YAML​

Les ancres YAML sont une fonctionnalité du langage YAML (YAML Ain't Markup Language) qui permet de réutiliser des parties d'un document YAML. Cette fonctionnalité est particulièrement utile pour éviter la répétition de structures de données similaires et pour maintenir des configurations cohérentes dans de grands fichiers YAML, comme ceux souvent utilisés dans la configuration des pipelines CI/CD, les fichiers Docker Compose, etc.

Comment Fonctionnent les Ancres YAML ?​

  1. Définition d'une Ancre (&) :
    • Une ancre est définie en utilisant le symbole & suivi d'un nom unique. Elle marque une section du YAML que vous souhaitez réutiliser ailleurs.
    • Exemple : &default_settings.
  2. Référencement d'une Ancre (*) :
    • Pour utiliser ou référencer l'ancre ailleurs dans le document, vous utilisez le symbole * suivi du nom de l'ancre.
    • Exemple : *default_settings.
  3. Merge Key (<<) :
    • La clé spéciale << est utilisée pour indiquer que toutes les propriétés de l'ancre référencée doivent être fusionnées dans le dictionnaire courant.
    • C'est utile pour combiner les configurations de base avec des configurations supplémentaires.

Exemple Pratique​

Voici un exemple simple pour illustrer l'utilisation des ancres :

.job_template: &job_configuration
  image: ruby:2.6
  services:
    - postgres
    - redis

test1:
  <<: *job_configuration
  script:
    - test1 project

test2:
  <<: *job_configuration
  script:
    - test2 project

Cela peut être utile si on souhaite utiliser deux template de job dans un job :

.job_template: &job_configuration
  script:
    - test project
  tags:
    - dev

.postgres_services:
  services: &postgres_configuration
    - postgres
    - ruby

.mysql_services:
  services: &mysql_configuration
    - mysql
    - ruby

test:postgres:
  <<: *job_configuration
  services: *postgres_configuration
  tags:
    - postgres

test:mysql:
  <<: *job_configuration
  services: *mysql_configuration

On peut aussi l'utiliser pour étendre des variables, mais aussi les scripts :

variables: &global-variables
  SAMPLE_VARIABLE: sample_variable_value
  ANOTHER_SAMPLE_VARIABLE: another_sample_variable_value

# a job that must set the GIT_STRATEGY variable, yet depend on global variables
job_no_git_strategy:
  stage: cleanup
  variables:
    <<: *global-variables
    GIT_STRATEGY: none
  script: echo $SAMPLE_VARIABLE
astuce

Ma préférence va à l'utilisation des extends car le code est plus lisible qu'avec les ancres.

Créer et inclure des templates Gitlab-ci​

Dans un premier temps, on peut développer ses templates dans un projet et les inclure localement. Une fois cette phase de développement terminé, il sera temps de passer par une solution de centralisation des templates.

Templates locaux​

Prenons l'exemple d'un template pour les tests unitaires. Vous pouvez créer un fichier unit_tests.yml contenant la configuration suivante :

# unit_tests.yml
unit_tests:
  stage: test
  script:
    - echo "Exécution des tests unitaires..."
    - ./run-unit-tests.sh

Dans votre fichier principal .gitlab-ci.yml, vous pouvez inclure ce template comme suit :

include:
  - local: '/templates/unit_tests.yml'

stages:
  - build
  - test
  - deploy

build_job:
  stage: build
  script:
    - echo "Construction du projet..."

# L'utilisation du template pour les tests unitaires
unit_tests:
  extends: .unit_tests

Voici un autre exemple pour un template de déploiement :

# deployment.yml
deployment:
  stage: deploy
  script:
    - echo "Déploiement de l'application..."
    - ./deploy-script.sh

Et son inclusion dans le pipeline principal :

include:
  - local: '/templates/deployment.yml'

# ... Autres configurations ...

# Utilisation du template pour le déploiement
deploy_job:
  extends: .deployment

Templates centralisés​

Pour stocker les différents composants de votre template, créez tout simplement un projet gitlab indépendant. Créez-y vos fichiers yaml.

Par exemple, nous voulons définir un template d'installation de packages nodejs (le premier commentaire est le nom du projet suivi du nom du fichier) :

# template-ci/install.yml

install:
  script:
    - npm install

Ensuite dans vos projets d'applications, il suffit d'inclure dans votre .gitlab-ci.yml un appel à ce script.

# mon-app1/.gitlab-ci.yml

include:
  - project: 'template-ci'
    file: 'install.yml'
    ref: 'master'

Vous remarquez certainement la balise ref. Elle permet de pointer vers une branche du projet de template. Cela va vous permettre de pouvoir faire évoluer votre ci sans impacter toute votre production. En effet, dans un projet précis, vous pourrez utiliser une branche de votre template pour le faire évoluer par exemple. Vous pourriez également créer des branches pour des variantes de votre template de ci/cd.

Conditionnement des include​

Depuis la version 14.3 de gitlab, il est possible de conditionner les include par des règles.

include:
  - local: builds.yml
    rules:
      - if: '$INCLUDE_BUILDS == "true"'

Bonnes pratiques​

Dans l'écosystème DevOps, les pipelines CI/CD ne sont pas de simples bouts de code ; ils sont une part essentielle de la base de code. Cela signifie qu'ils doivent être traités avec la même rigueur que le code source de l'application. La gestion de ces pipelines implique :

  1. Versionnage : Tout comme le code source, les pipelines doivent être versionnés. Cela permet de suivre les modifications, de revenir à des versions antérieures en cas de problème et de comprendre l'évolution du pipeline au fil du temps.
  2. Revue de Code : Les modifications apportées aux fichiers de pipeline doivent passer par des revues de code. Cela assure une vérification par les pairs et aide à maintenir la qualité et la sécurité du pipeline.
  3. Tests Automatisés : Les pipelines devraient être testés pour vérifier leur fiabilité. Cela peut inclure des tests d'intégration pour s'assurer que le pipeline fonctionne correctement dans différents environnements.
  4. Documentation : Une documentation claire est essentielle pour assurer que les pipelines soient compréhensibles et maintenables. Elle devrait inclure des informations sur la structure du pipeline, son fonctionnement et les modifications apportées au fil du temps.
  5. Exposer vos templates : C’est bien d’avoir des templates mais il faut s’assurer que les utilisateurs puissent les trouver facilement. C'est là qu'intervient un outil comme R2DevOps qui permet d'afficher un catalogue de templates de manière simplifié et structuré. R2DevOps permet aussi de d'identifier où et comment sont utilisés les templates.

Outils indispensables​

To be continuous​

"To Be Continuous" est une plateforme conçue pour améliorer et simplifier la gestion des pipelines CI/CD dans GitLab. Elle offre plusieurs fonctionnalités clés pour optimiser la mise en œuvre et la maintenance des pipelines :

  1. Facilité d'Utilisation : La plateforme propose un ensemble de templates GitLab CI développés et maintenus par des experts en DevOps et en technologie, permettant de construire des pipelines CI/CD de pointe en quelques minutes. Elle est conçue pour être facile à utiliser, même pour ceux qui ne maîtrisent pas GitLab CI, en suivant simplement le guide et en incluant les templates nécessaires.
  2. Modularité : Les utilisateurs peuvent construire leur pipeline de projet en assemblant tous les templates requis. Cette approche modulaire permet une personnalisation et une adaptabilité accrues pour répondre aux besoins spécifiques de chaque projet.
  3. Sécurité et Outils de Qualité : La plateforme facilite l'utilisation d'outils de sécurité et de qualité, tels que le contrôle de la qualité du code, l'analyse statique de la sécurité des applications (SAST), la vérification des dépendances, la gestion des licences et les tests d'application dynamiques (DAST).
  4. Workflows Git Modernes : Les templates supportent des workflows DevOps modernes, tels que les branches de fonctionnalités et Gitflow, ce qui rend la plateforme adaptable à diverses méthodologies de développement.
  5. Mise à Jour et Extensibilité : La plateforme suit attentivement chaque nouvelle version de GitLab CE pour intégrer de nouvelles fonctionnalités dans ses templates. Elle est également configurable et extensible, fonctionnant avec une configuration minimale tout en pouvant être adaptée pour répondre à des besoins spécifiques.
  6. Environnements de Révision : "To Be Continuous" offre des environnements de révision dynamiquement créés dans le cloud, qui hébergent le développement en cours, équivalant strictement à la fonctionnalité de Review Apps de GitLab.
  7. Documentation et Exemples : Tous les templates sont accompagnés d'une documentation étendue et la plateforme fournit également une grande variété d'exemples de projets pour illustrer leur utilisation et les meilleures pratiques.

En résumé, "To Be Continuous" se positionne comme une solution complète pour la gestion des pipelines CI/CD, offrant facilité d'utilisation, modularité, outils de sécurité avancés, prise en charge de workflows Git modernes, mise à jour continue, environnements de révision dynamiques, ainsi qu'une documentation et des exemples complets pour guider les utilisateurs.

Plus d'infos​

R2DevOps​

R2DevOps est une solution innovante pour optimiser la gestion des pipelines CI/CD, en intégrant des fonctionnalités avancées qui améliorent à la fois la sécurité et l'efficacité.

Cette plateforme propose un catalogue de templates, qui est une ressource inestimable pour les développeurs et les administrateurs système, offrant une vaste gamme de modèles préconfigurés, dont ceux de to be continuous, adaptés à divers aspects des pipelines CI/CD. L'utilisation de ces templates permet non seulement un gain de temps considérable en réduisant le temps de configuration, mais assure également une cohérence accrue dans la mise en œuvre des pipelines à travers différents projets.

En parallèle, R2DevOps met l'accent sur la conformité, la sécurité et la maintenabilité. L'audit de conformité automatique joue un rôle clé en assurant que les pipelines respectent les normes et les meilleures pratiques de l'entreprise. Cette fonction fournit des rapports détaillés qui mettent en lumière les domaines nécessitant des améliorations, offrant ainsi une orientation claire pour les ajustements futurs.

La sécurité des données est une préoccupation majeure dans tout environnement DevOps et R2DevOps y répond par sa capacité à détecter les secrets et les variables non protégées au sein de tous les projets. Cette fonctionnalité scanne automatiquement les projets pour identifier les mots de passe, clés API, et tokens susceptibles d'être exposés et alerte les équipes en cas de détection. La plateforme fournit également des recommandations pour sécuriser ces secrets et variables, renforçant ainsi la protection des données. D'ailleurs, j'ai remarqué que ces secrets se trouvent le plus souvent dans des projets que l'on qualifierait d'annexes comme des POC's.

En outre, la détection de code malveillant est une autre facette essentielle de la sécurité des pipelines avec R2DevOps. La plateforme effectue une analyse automatisée pour repérer toute image potentiellement dangereuse. Cette précaution est cruciale pour prévenir les attaques de sécurité et les compromissions de code avant qu'elles ne posent un risque significatif, garantissant ainsi que les pipelines restent sécurisés et fiables.

Les développeurs de R2DevOps améliorent sans cesse leur plateforme et beaucoup de nouveautés sur la partie sécurité et conformité sont prévues :

  • Analyse des scripts avec ShellCheck
  • Analyse des dépendances à la recherche de vulnérabilités
  • Analyse des runners (souvent obsolétes)
  • Un dashboard affichant l'état de l'ensemble des pipelines

En conclusion, l'intégration de R2DevOps dans la gestion de vos pipelines CI/CD apporte une amélioration notable tant en termes d'efficacité que de sécurité. Avec ses fonctionnalités de pointe, R2DevOps permet aux équipes de maintenir des pipelines CI/CD non seulement efficaces, mais également conformes aux normes de sécurité et de conformité de l'entreprise, conduisant ainsi à une qualité et une fiabilité accrues des processus de développement et de déploiement.

Plus d'infos​

Conclusion​

En conclusion, la factorisation des pipelines CI/CD dans GitLab, en utilisant des templates, des fonctionnalités avancées comme extends et les ancres YAML, et en adhérant à des pratiques de gestion rigoureuses, transforme radicalement l'efficacité et la sécurité des processus de développement et de déploiement. L'adoption de plateformes telles que R2DevOps et "To Be Continuous", avec leurs vastes catalogues de templates facilite cette transformation. En intégrant ces pratiques et outils, les équipes DevOps peuvent construire des systèmes CI/CD robustes, évolutifs et conformes aux normes de l'industrie, garantissant ainsi une livraison de logiciels de haute qualité et sécurisée.