Dans le monde moderne du développement logiciel, les pipelines d'intégration et de déploiement continus (CI/CD) sont devenus essentiels. Ils permettent aux équipes de développement de créer du code, de le tester et de déployer des modifications avec rapidité et efficacité. Parce qu'ils automatisent la création et le déploiement des applications, les pipelines CI/CD aident les équipes à améliorer la qualité du code, à réduire le nombre d'erreurs et à accélérer la mise sur le marché de nouvelles fonctions et applications.
Un runner GitLab est une application qui traite les tâches CI/CD sur GitLab.com et les instances GitLab auto-hébergées. GitLab.com fournit ses propres runners hébergés, lesquels sont partagés entre les utilisateurs du site, mais on peut également configurer des runners privés dédiés pour des projets via différents types d'installation. Les entreprises et individus qui souhaitent gérer leur propre infrastructure de pipelines dans le cloud peuvent utiliser l'opérateur GitLab Runner, disponible en tant qu'opérateur certifié Red Hat dans OpenShift, qui permet une installation cloud-native facile et rapide de runners GitLab.
Afin de montrer la simplicité et les fonctionnalités de l'opérateur GitLab Runner, il m'a semblé utile de mettre en avant certains développements intéressants de Fedora Linux et d'utiliser cet opérateur pour créer des images de base personnalisées pour Fedora Silverblue.
Fedora Silverblue est une distribution immuable de pointe de Fedora Linux. Depuis peu, son système hybride de gestion de paquets et d'images rpm-ostree
peut démarrer à partir de conteneurs OCI. Cette amélioration permet aux utilisateurs ou entreprises de créer leurs propres images de base personnalisées en utilisant les workflows Dockerfiles et Containerfiles qu'ils maîtrisent déjà.
Dans ce tutoriel, nous allons configurer un système de création entièrement automatisé pour les images Fedora Silverblue à l'aide de l'opérateur GitLab Runner.
Prérequis
Vous aurez besoin de quelques ressources déjà configurées et installées qui ne seront pas abordées ici :
- Un cluster OpenShift
- Une installation existante de Fedora Silverblue (si vous souhaitez utiliser les images personnalisées)
- Un compte GitLab.com
Installation et configuration de l'opérateur GitLab Runner
Dans la barre latérale de votre cluster OpenShift, cliquez sur l'en-tête Operators, puis sur OperatorHub. Recherchez l'opérateur GitLab Runner et cliquez sur la version certifiée (il existe une version communautaire, mais nous ne l'utiliserons pas ici). Avant de cliquer sur Install, vérifiez la section des prérequis figurant dans la description de l'opérateur. Vous devez d'abord installer cert-manager
:
oc apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.7.1/cert-manager.yaml
Cliquez ensuite sur Install pour installer l'opérateur GitLab Runner.
L'écran suivant vous invite à modifier les options d'installation par défaut. Si vous devez ou souhaitez utiliser un espace de noms spécifique, faites-le à cette étape. Autrement, conservez les options par défaut. Je vous conseille également de laisser l'option Update approval définie sur Automatic , car c'est l'un des principaux avantages de l'utilisation d'un opérateur.
Patientez jusqu'à la fin de l'installation, accédez ensuite à la section Installed Operators , puis à l'opérateur GitLab Runner. Vous verrez ici le même texte d'information que précédemment, ainsi qu'un lien sous Provided APIs qui permet de créer une instance de runner. Le texte d'information suivant contient des instructions pour associer vos runners à vos référentiels GitLab.
Création et enregistrement d'une instance de runner
1. Créer un secret de token d'enregistrement
Commençons par créer un secret avec un token d'enregistrement de GitLab que le nouveau runner utilisera pour s'enregistrer dans le référentiel. Ouvrez GitLab.com ou votre instance GitLab privée, puis ouvrez le référentiel à utiliser pour l'enregistrement. Accédez au menu Settings, puis CI/CD. Développez la section intitulée Runners , puis consultez la section Project runners. Elle contient le token d'enregistrement et l'adresse URL que vous utiliserez pour enregistrer l'instance de runner.
Si vous utilisez GitLab.com, vous pourrez voir la section Shared runners qui liste les runners publics fournis par GitLab.com. Désactivez les runners partagés pour ce projet, car nous utiliserons nos propres runners privés.
Créez le secret en indiquant le token d'enregistrement de votre référentiel dans le champ runner-registration-token
. Pour ce faire, vous pouvez utiliser la console web ou l'interface du terminal. J'ai créé un fichier nommé gitlab-runner-secret.yml
, que j'ai ajouté au cluster :
apiVersion: v1
kind: Secret
metadata:
name: gitlab-runner-secret
type: Opaque
stringData:
runner-registration-token: YOUR_TOKEN_HERE
oc apply -f gitlab-runner-secret.yml
2. Configurer le runner avec un objet ConfigMap
Avant de créer le runner, nous devons également créer un objet ConfigMap avec quelques paramètres personnalisés. En règle générale, les runners GitLab peuvent être configurés avec un fichier config.toml
. Dans le contexte de Kubernetes, il est possible d'ajouter ces paramètres personnalisés avec un objet ConfigMap qui contient le fichier config.toml
.
Étant donné que nous exécutons les conteneurs de création dans l'environnement d'un cluster OpenShift, nous devons nous assurer qu'ils s'exécutent sans privilèges supérieurs et en tant qu'utilisateur non root (remarque : il existe des moyens de contourner cet aspect si vous avez besoin d'un environnement de création doté de privilèges, mais nous utiliserons une configuration non root ici). Voici un exemple simple de fichier config.toml
qui spécifie que le pod du runner s'exécutera en tant qu'utilisateur non root 1000 :
[[runners]]
name = "gitlab-runner"
url = "https://gitlab.com"
executor = "kubernetes"
[runners.kubernetes]
[runners.kubernetes.pod_security_context]
run_as_non_root = true
run_as_user = 1000
Utilisez la commande suivante pour ajouter cette configuration au cluster en tant qu'objet ConfigMap :
oc create configmap my-runner-config --from-file=config.toml
3. Démarrer l'instance de runner
Nous pouvons maintenant créer l'instance de runner à proprement parler. Vous pouvez également effectuer cette opération à l'aide de la console web en cliquant sur Create instance sur la page de l'opérateur GitLab Runner ou à partir du terminal. Dans les deux cas, assurez-vous que la définition de ressource personnalisée comprend la bonne adresse URL de GitLab, le nom du secret du token d'enregistrement, le nom de l'objet ConfigMap, et que les balises comportent la mention « openshift » pour que les tâches soient bien transmises à votre cluster. Voici un exemple de définition de ressource personnalisée de base nommée gitlab-runner.yml
qui répond à tous nos critères :
apiVersion: apps.gitlab.com/v1beta2
kind: Runner
metadata:
name: gitlab-runner
spec:
gitlabUrl: https://gitlab.com
token: gitlab-runner-secret
tags: openshift
config: my-runner-config
Utilisez la commande suivante pour l'installer dans le cluster :
oc apply -f gitlab-runner.yml
Vous pouvez maintenant vérifier le statut du nouveau runner dans la console web ou à partir du terminal à l'aide de la commande oc get runners
. Il faut également vérifier les paramètres CI/CD du projet GitLab pour s'assurer que le runner est correctement lié au référentiel. Vous devez maintenant voir un runner sous Assigned project runners avec le même nom que la définition de ressource personnalisée qui a été créée et installée.
Utilisation du runner pour créer des images Silverblue
1. Définir les tâches du pipeline CI/CD GitLab
Le runner est installé, configuré et lié au projet. Écrivons maintenant le fichier GitLab CI qui définira la création d'images. GitLab fournit de nombreux exemples de sa structure de fichiers gitlab-ci.yml
pour différents types de projets. Créons notre propre fichier en utilisant buildah
pour créer nos images Silverblue.
Le fichier gitlab-ci.yml
que nous utiliserons se présente comme suit :
stages:
- build
buildah-build:
stage: build
tags:
- openshift
image: quay.io/buildah/stable
variables:
STORAGE_DRIVER: vfs
script:
- export HOME=/tmp
- buildah login --username "$CI_REGISTRY_USER" --password "$CI_REGISTRY_PASSWORD" "$CI_REGISTRY"
- buildah build -t "$CI_REGISTRY_IMAGE:latest" .
- buildah push "$CI_REGISTRY_IMAGE:latest"
- buildah logout "$CI_REGISTRY"
Ce fichier comporte plusieurs éléments importants.
- Comme indiqué précédemment, nous devons au moins inclure la balise
openshift
pour que les tâches soient sélectionnées par l'opérateur GitLab Runner. - Nous utilisons l'image Buildah stable et officielle hébergée dans Quay.io en tant qu'image de création.
- Nous avons défini le pilote de stockage sur
vfs
en raison des problèmes avec les systèmes de fichiers superposés. Pour le moment, l'utilisation devfs
reste la solution la plus simple. - Nous remplaçons
$HOME
par/tmp
pour nous assurer de pouvoir écrire le fichier, car la plupart des systèmes de fichiers de conteneurs dans OpenShift seront en lecture seule.
La dernière section, script
, est une liste des commandes que la tâche de création exécutera. Ici, nous utilisons les variables prédéfinies du fichier GitLab CI pour nous connecter au registre de conteneurs GitLab, créer et baliser l'image, puis envoyer l'image au registre avant de nous déconnecter.
2. Écrire le fichier Containerfile pour l'image Silverblue personnalisée
Après avoir ajouté le fichier gitlab-ci.yml
au référentiel, nous devons également ajouter le fichier Containerfile
que nous souhaitons créer. Pour l'image Fedora Silverblue personnalisée, je me suis appuyé sur l'excellent travail de la communauté Universal Blue . Ses membres ont travaillé sur différentes versions de Silverblue pour divers cas d'utilisation. Elles constituent une excellente ressource si vous ou votre équipe souhaitez créer des images de base personnalisées et immuables pour les systèmes Fedora Silverblue.
J'ai pensé qu'il serait utile de créer une image de base incluant les versions les plus récentes de tous les outils OpenShift et de l'opérateur que j'utilise au quotidien. Puisque nous allons la configurer de manière à être créée quotidiennement, l'image de base sera mise à jour avec les paquets Fedora les plus récents, et les outils OpenShift et de l'opérateur qui nécessitent des mises à jour manuelles en temps normal seront mis à jour automatiquement.
ARG FEDORA_MAJOR_VERSION=38
FROM quay.io/fedora-ostree-desktops/silverblue:${FEDORA_MAJOR_VERSION}
# Starting with Fedora 39, the new official location for these images is quay.io/fedora/fedora-silverblue
# See https://pagure.io/releng/issue/11047 for more information
# Install Openshift tools -- oc, opm, kubectl, operator-sdk, odo, helm, crc from official OpenShift sources
RUN curl -SL https://mirror.openshift.com/pub/openshift-v4/x86_64/clients/ocp/latest/opm-linux.tar.gz | tar xvzf - -C /usr/bin
RUN curl -SL https://mirror.openshift.com/pub/openshift-v4/x86_64/clients/operator-sdk/latest/operator-sdk-linux-x86_64.tar.gz | tar xvzf - --strip-components 2 -C /usr/bin
RUN curl -SL https://mirror.openshift.com/pub/openshift-v4/clients/oc/latest/linux/oc.tar.gz | tar xvzf - -C /usr/bin
RUN curl -SL https://mirror.openshift.com/pub/openshift-v4/x86_64/clients/helm/latest/helm-linux-amd64 -o /usr/bin/helm && chmod +x /usr/bin/helm
RUN curl -SL https://mirror.openshift.com/pub/openshift-v4/x86_64/clients/odo/latest/odo-linux-amd64 -o /usr/bin/odo && chmod +x /usr/bin/odo
RUN curl -SL https://mirror.openshift.com/pub/openshift-v4/x86_64/clients/crc/latest/crc-linux-amd64.tar.xz | tar xfJ - --strip-components 1 -C /usr/bin
# Install awscli
RUN curl -SL https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip -o awscliv2.zip && unzip awscliv2.zip && ./aws/install --bin-dir /usr/bin --install-dir /usr/bin
# Install overrides and additions, remove lingering files
RUN rpm-ostree install podman-docker
RUN rm -rf aws && \
rm -f awscliv2.zip && \
rm -f /usr/bin/README.md && \
rm -f /usr/bin/LICENSE
Voici un aperçu du contenu du fichier Containerfile :
- Pour commencer, nous indiquons la version de Fedora que nous souhaitons créer, ici la version actuelle et stable 38.
- Ensuite, nous indiquons l'image de base à utiliser, à savoir
silverblue:38
, après avoir remplacéFEDORA_MAJOR_VERSION
(consultez les commentaires du fichier Containerfile sur l'emplacement de ces images). - Dans la plus grande section, nous exécutons plusieurs commandes
curl
pour télécharger tous les programmes OpenShift à installer, en veillant à placer les fichiers binaires correspondants dans le répertoire/usr/bin
. - Nous installons également l'interface
awscli
, ce qui nécessite de décompresser le fichier.zip
et d'exécuter le script d'installation. - Enfin, nous utilisons le système
rpm-ostree
pour installerpodman-docker
à partir des référentiels de paquets Fedora (l'alias des commandesdocker
est remplacé parpodman
, pour les personnes habituées à exécuterdocker
), puis nous supprimons certains fichiers persistants liés à l'extraction de l'interfaceawscli
.
Comme mentionné précédemment, pour en savoir plus sur la personnalisation de Silverblue, consultez la page de la communauté Universal Blue. Ce workflow se base en grande partie sur le travail de ses membres, qui travaillent déjà sur de nombreuses nouvelles applications intéressantes de la fonctionnalité de démarrage à partir de conteneurs OCI dans Silverblue.
3. Utiliser et surveiller les tâches du pipeline
Ajoutez ce fichier Containerfile, ou tout autre fichier Containerfile ou Dockerfile que vous préférez créer, à la racine du référentiel du projet, car le fichier gitlab-ci.yml
indique que buildah
utilise le répertoire de travail actuel comme argument Containerfile. Selon la façon dont vous avez validé les modifications dans ce référentiel, il se peut que vous ayez déjà reçu des notifications concernant les tâches du pipeline ayant échoué ou, si vous validez tout en même temps, que la première tentative d'exécution de la tâche de création commence maintenant. Vous pouvez surveiller les journaux de création en accédant à l'en-tête CI/CD sur la page de votre projet sur GitLab.com, puis en cliquant sur Pipelines ou Jobs et en continuant de cliquer jusqu'à ce que vous voyiez le journal pour la tâche nommée buildah-build
.
Si tout a été configuré correctement, vous devez voir des journaux qui décrivent chaque étape des fichiers gitlab-ci.yml
et Containerfile écrits, et se terminent par « Job succeeded ». Si la tâche réussit, vous devriez également voir le conteneur terminé dans le registre du projet. Dans la barre de navigation à gauche, cliquez sur Packages and registries , puis sur Container Registry. Vous devriez voir une seule image portant le nom de votre projet avec une balise « latest ». Cette image se trouve dans registry.gitlab.com/{VOTRE_NOM_D'UTILISATEUR}/{NOM_DU_RÉFÉRENTIEL}
.
La tâche telle que nous l'avons écrite s'exécute à chaque validation dans la branche main
, mais vous pouvez personnaliser ce comportement dans le fichier gitlab-ci.yml
. Pour planifier des créations d'images régulières, accédez aux paramètres de CI/CD dans la section Schedule de la page du référentiel. Cliquez sur New schedule pour programmer votre pipeline. Pour en savoir plus sur la planification des pipelines GitLab.com, cliquez ici. Pour une image Silverblue personnalisée, il est probable que vous deviez programmer une création quotidienne au minimum pour suivre le rythme de création des images officielles.
Utilisation des images personnalisées
Pour utiliser cette image en tant que base de démarrage pour Silverblue, vous devez d'abord installer Fedora Silverblue à partir des images officielles si vous ne disposez pas d'une installation existante. Une fois que l'installation est terminée et que vous vous êtes connecté, vous pouvez redéfinir la base de l'installation sur l'image personnalisée.
Gardez à l'esprit que le démarrage à partir d'images OCI n'est encore qu'une fonction expérimentale. Vous devez donc faire preuve de bon sens si vous l'utilisez sur des machines personnelles ou de production. Si votre image personnalisée ne fonctionne pas comme prévu, vous devriez être en mesure de restaurer l'image de base d'origine. Pour vous assurer de ne pas supprimer cette base d'origine, vous pouvez exécuter la commande sudo ostree admin pool 0
pour épingler l'image actuelle. Cette opération permet de s'assurer que la référence n'est pas perdue lors des mises à jour ultérieures, car Silverblue ne conserve normalement que les références d'image actuelles et précédentes. Pour redéfinir la base sur l'image personnalisée, exécutez la commande suivante :
rpm-ostree rebase ostree-unverified-registry:registry.gitlab.com/{YOUR_USERNAME}/{YOUR_REPOSITORY_NAME}:latest
Procédez ensuite au redémarrage.
Vous pouvez ensuite vérifier que l'image personnalisée est exécutée en examinant le résultat de la commande rpm-ostree status
. Votre déploiement actuel, signalé par le cercle/point à gauche, doit afficher l'URI ostree-unverified-registry
de l'image personnalisée. Vous pouvez également essayer d'exécuter l'un des outils OpenShift ajoutés dans un terminal, comme oc
, operator-sdk
ou helm
.
Vous devez également voir le déploiement épinglé avec la référence de l'ancienne base dans le résultat de la commande rpm-ostree status
. Si vous souhaitez effectuer une restauration, exécutez la commande rpm-ostree rollback
et redémarrez. Pour plus d'informations sur l'administration de Fedora Silverblue, consultez la documentation.
Résultats
En partant du principe que tout s'est bien passé, vous disposez maintenant d'un pipeline CI/CD auto-hébergé exécuté sur le cluster OpenShift qui crée régulièrement de nouvelles images Silverblue personnalisées. Les runners ne nécessitent aucune intervention manuelle, sauf pour reconfigurer les balises de tâches de création ou en créer d'autres afin de gérer davantage de tâches simultanées. Les créations d'images commencent aux intervalles planifiés et lors de validations de nouveau code dans la branche main
. Si vous exécutez l'image personnalisée sur une installation Silverblue, il vous suffit d'exécuter la commande rpm-ostree update
pour extraire les mises à jour quotidiennes.
Cet exemple de tutoriel est une simple illustration des fonctionnalités de l'opérateur GitLab Runner et du système CI/CD de GitLab. Ils permettent tous deux de répondre à des besoins de CI/CD beaucoup plus complexes. En exécutant l'opérateur GitLab Runner certifié sur OpenShift, vous évitez une grande partie des tâches manuelles de configuration et de maintenance des runners, et vous pouvez consacrer plus de temps et d'énergie au contenu et à la configuration des créations d'images.
Tous les fichiers texte utilisés dans ce tutoriel figurent dans ce référentiel de référence. Vous trouverez également une liste de références utiles ci-dessous.
À propos de l'auteur
Contenu similaire
Parcourir par canal
Automatisation
Les dernières nouveautés en matière d'automatisation informatique pour les technologies, les équipes et les environnements
Intelligence artificielle
Actualité sur les plateformes qui permettent aux clients d'exécuter des charges de travail d'IA sur tout type d'environnement
Cloud hybride ouvert
Découvrez comment créer un avenir flexible grâce au cloud hybride
Sécurité
Les dernières actualités sur la façon dont nous réduisons les risques dans tous les environnements et technologies
Edge computing
Actualité sur les plateformes qui simplifient les opérations en périphérie
Infrastructure
Les dernières nouveautés sur la plateforme Linux d'entreprise leader au monde
Applications
À l’intérieur de nos solutions aux défis d’application les plus difficiles
Programmes originaux
Histoires passionnantes de créateurs et de leaders de technologies d'entreprise
Produits
- Red Hat Enterprise Linux
- Red Hat OpenShift
- Red Hat Ansible Automation Platform
- Services cloud
- Voir tous les produits
Outils
- Formation et certification
- Mon compte
- Assistance client
- Ressources développeurs
- Rechercher un partenaire
- Red Hat Ecosystem Catalog
- Calculateur de valeur Red Hat
- Documentation
Essayer, acheter et vendre
Communication
- Contacter le service commercial
- Contactez notre service clientèle
- Contacter le service de formation
- Réseaux sociaux
À propos de Red Hat
Premier éditeur mondial de solutions Open Source pour les entreprises, nous fournissons des technologies Linux, cloud, de conteneurs et Kubernetes. Nous proposons des solutions stables qui aident les entreprises à jongler avec les divers environnements et plateformes, du cœur du datacenter à la périphérie du réseau.
Sélectionner une langue
Red Hat legal and privacy links
- À propos de Red Hat
- Carrières
- Événements
- Bureaux
- Contacter Red Hat
- Lire le blog Red Hat
- Diversité, équité et inclusion
- Cool Stuff Store
- Red Hat Summit