Définir et utiliser des variables dans le cadre d'une approche CI/CD s'avère une méthode très flexible. Ces variables sont d'une grande utilité pour contrôler les jobs et les pipelines, tout en vous permettant d'éviter de coder en dur des valeurs directement dans votre fichier de configuration .gitlab-ci.yml
.
Dans GitLab CI/CD, les variables peuvent être utilisées pour personnaliser les jobs en définissant et en stockant des valeurs spécifiques. Pour définir vos variables CI/CD dans GitLab, accédez à Paramètres >> CI/CD >> Variables ou définissez-les simplement dans le fichier .gitlab-ci.yml
. Sachez que les variables servent également d'alternative aux valeurs codées en dur.
Utiliser des variables s’avère particulièrement utile pour configurer des services tiers dans différents environnements de déploiement, tels que l'environnement de test (testing
), l'environnement de préproduction (staging
), l'environnement de production (production
), et plus encore. Pour modifier les services liés à ces environnements, il suffit de changer simplement la variable qui pointe vers le point de terminaison d'API associé aux services. Vous pouvez également utiliser des variables pour configurer les jobs et les rendre disponibles en tant que variables d'environnement dans les jobs lorsqu'ils s'exécutent.
Découvrez dans cet article tout ce que vous devez savoir sur les variables d’environnement afin de mieux comprendre leur fonctionnement et leur portée.
La relation entre les variables et les environnements
Le processus de développement logiciel comprend plusieurs étapes destinées à tester un produit avant de le déployer et de le mettre à disposition des utilisateurs. Les environnements sont utilisés pour définir ces étapes, qui peuvent différer d'une équipe à l'autre, voire d'une entreprise à l'autre.
Les variables, quant à elles, sont des valeurs de données susceptibles de changer à la suite d'une interaction entre un utilisateur et un produit. Par exemple, son âge, ses préférences ou toute autre information qui pourrait déterminer l'étape suivante qui lui sera présentée dans le flux de tâches du produit.
Le terme variable d'environnement fait souvent référence à des variables définies dans un environnement donné, mais en dehors de l'application. Les variables dans GitLab CI/CD offrent aux équipes de développement la possibilité de configurer des valeurs dans le code. L'intérêt principal étant de garantir sa flexibilité. Ces variables permettent aux utilisateurs de modifier une application déployée dans un certain environnement sans toucher au code. Il est possible d'exécuter des tests en toute simplicité ou même d'intégrer des services tiers en modifiant une variable d'environnement de configuration en dehors de l'application.
La portée des variables dans l'approche CI/CD
Variables définies dans .gitlab-ci.yml
Les variables qui doivent être disponibles dans l'environnement du job peuvent être ajoutées à GitLab. Ces variables CI/CD stockent la configuration du projet ne contenant pas de données sensibles, comme l'URL de la base de données dans le fichier .gitlab-ci.yml
. Réutilisez cette variable dans plusieurs jobs ou scripts, là où la valeur est nécessaire. Si la valeur change, vous n'avez besoin de mettre à jour la variable qu'une seule fois. Le changement se reflète ensuite partout où la variable est utilisée.
Variables CI/CD au niveau du projet
Un cran au-dessus des exigences spécifiques au dépôt, vous pouvez définir des variables CI/CD dans les paramètres du projet, afin qu'elles soient disponibles dans les pipelines CI/CD. Celles-ci sont stockées en dehors du dépôt (c'est-à-dire qu'elles ne figurent pas dans le fichier .gitlab-ci.yml
), mais peuvent néanmoins être utilisées dans les scripts et la configuration CI/CD. Le stockage des variables en dehors du fichier .gitlab-ci.yml
limite ces valeurs à la portée du projet uniquement, sans les enregistrer en texte brut dans le projet.
Variables CI/CD au niveau du groupe et de l'instance
Certaines variables sont pertinentes à l'échelle du groupe ou de l'instance et peuvent être utiles à tous les projets associés à un groupe ou à une instance spécifique. Définissez les variables dans les paramètres du groupe ou de l'instance afin que tous les projets de ces portées puissent utiliser les variables sans avoir besoin d'en connaître la valeur ou de les recréer pour chaque projet de portée inférieure. Par exemple, une valeur commune à plusieurs projets se gère facilement si elle ne doit être mise à jour qu'à un seul endroit. Alternativement, plusieurs projets peuvent utiliser un mot de passe spécifique sans avoir besoin de connaître la valeur du mot de passe lui-même.
Jobs et pipelines en tant qu'environnements
En plus d'être utilisées comme des variables d'environnement, les variables dans GitLab CI/CD fonctionnent également dans la portée du fichier de configuration .gitlab-ci.yml
pour définir le comportement du pipeline, indépendamment de son environnement. Les variables peuvent être stockées dans les paramètres du projet/groupe/instance et mises à la disposition des jobs dans les pipelines.
Par exemple :
job:
rules:
- if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
script:
- echo "This job ran on the $CI_COMMIT_BRANCH branch."
La variable ($CI_COMMIT_BRANCH)
dans la section du script s'exécute dans la portée du job dans lequel elle a été définie. Cette portée est l'« environnement du job », ce qui signifie que lorsque le job se lance, le GitLab Runner démarre un conteneur Docker et exécute le job dans cet environnement. Le runner met cette variable (et toutes les autres variables prédéfinies ou personnalisées) à la disposition du job et peut également afficher leur valeur dans les données de sortie du log si nécessaire.
Toutefois, la variable est aussi utilisée dans la section if:
pour déterminer quand le job doit s'exécuter. Il ne s'agit pas en soi d'un environnement, c'est pourquoi nous les appelons variables CI/CD. Elles peuvent être utilisées pour configurer dynamiquement vos jobs CI/CD, ainsi que comme variables d'environnement lorsque le job est en cours d'exécution.
Variables prédéfinies
Un certain nombre de variables sont prédéfinies lorsqu'un pipeline GitLab CI/CD démarre. Un utilisateur peut immédiatement accéder aux valeurs pour des éléments tels que les validations, le projet ou les détails du pipeline sans avoir à définir les variables elles-mêmes.
Variables CI/CD personnalisées
Lors de la création d'une variable CI/CD dans les paramètres, GitLab offre à l'utilisateur plus d'options pour configurer la variable. Utilisez ces options de configuration supplémentaires pour exercer un contrôle plus strict sur les variables plus sensibles :
Portée de l'environnement : si une variable ne doit être utilisée que dans un environnement spécifique, définissez-la pour qu'elle soit disponible uniquement dans cet environnement. Par exemple, vous pouvez définir un jeton de déploiement pour qu'il ne soit disponible que dans l'environnement production
.
Variables protégées : comme pour la portée de l'environnement, vous pouvez définir une variable pour qu'elle ne soit disponible que lorsque le pipeline s'exécute sur une branche protégée, comme votre branche par défaut.
Type de variable : certaines applications nécessitent que la configuration leur soit transmise sous la forme d'un fichier. Si une application nécessite cette configuration, définissez simplement le type de variable comme « Fichier ». Cette configuration de la variable CI/CD signifie que lorsque le runner rend la variable disponible dans l'environnement, il l'écrit dans un fichier temporaire et stocke le chemin d'accès au fichier en tant que valeur. Un utilisateur peut ensuite transmettre le chemin d'accès au fichier à toutes les applications qui en ont besoin.
En plus des éléments énumérés pour définir et utiliser les variables, GitLab a introduit une fonctionnalité qui génère des variables préremplies lorsqu'un pipeline doit être exécuté manuellement. Les variables préremplies réduisent les risques d'erreur et facilitent l'exécution du pipeline.
Variables masquées : les variables masquées sont des variables CI qui ont été cachées dans les job logs pour empêcher l'affichage de leur valeur.
Variables masquées et cachées : introduites dans GitLab 17.4, les variables masquées et cachées offrent la même fonctionnalité de masquage des job logs et gardent la valeur cachée dans l'interface utilisateur des paramètres. Nous ne recommandons pas d'utiliser ces deux types de variables pour les informations sensibles (comme les secrets), car elles peuvent être exposées par inadvertance.
Secrets
Un secret est un identifiant de connexion sensible qui doit rester confidentiel. Voici des exemples de secrets :
- Mots de passe
- Clés SSH
- Jetons d'accès
- Tout autre type d'identifiants de connexion dont la divulgation pourrait porter préjudice à l'entreprise
GitLab permet actuellement à ses utilisateurs d'utiliser des secrets externes dans l'intégration continue (CI), en tirant parti de HashiCorp Vault, Google Cloud Secret Manager et Azure Key Vault pour gérer de manière sécurisée les clés, les tokens et d'autres secrets au niveau du projet. Les utilisateurs peuvent ainsi séparer ces secrets des autres variables CI/CD pour des raisons de sécurité.
Gestionnaire de secrets de GitLab
En plus de fournir une assistance pour les secrets externes dans la CI, GitLab prévoit également de proposer une solution native de gestion des secrets permettant de stocker les secrets de manière pratique et sécurisée au sein de sa plateforme. Cette solution aidera également les clients à utiliser les secrets stockés dans les composants et les environnements spécifiques à GitLab, ainsi qu'à gérer facilement les accès au niveau des groupes d'espaces de nommage et des projets.
Pour en savoir plus sur le gestionnaire de secrets de GitLab, consultez notre article « Le gestionnaire de secrets natif de GitLab renforce la sécurité de la chaîne d'approvisionnement logicielle ».
Avertissement : cet article de blog contient des informations relatives aux produits, fonctionnalités et caractéristiques à venir. Il est important de noter que les informations contenues dans cet article de blog ne sont fournies qu'à titre informatif. Veuillez ne pas vous fier à ces informations à des fins d'achat ou de planification. Comme pour tout projet, les éléments mentionnés dans cet article sont susceptibles de changer ou d’être retardés. Le développement, la sortie et le calendrier de tout produit ou fonctionnalité restent à la seule discrétion de GitLab.