Semaphore UI et GitLab CI/CD

GitLab.com fournit l'hébergement Git, la CI/CD et les services associés sous forme de service géré. Pour GitLab Self-Managed, les installations par paquets Linux, Docker ou Kubernetes incluent plusieurs services qui coopèrent, notamment PostgreSQL, Redis et des workers d'arrière-plan. Une équipe qui exploite déjà GitLab peut utiliser cette installation pour son automatisation sans ajouter un autre service web.

Semaphore UI peut fonctionner sous forme de binaire autonome, de paquet Linux natif, de conteneur Docker ou de déploiement Kubernetes, avec son service applicatif et sa base de données. Les binaires natifs du serveur couvrent aussi macOS, Windows et FreeBSD. Une équipe qui a uniquement besoin d'une interface d'automatisation dispose ainsi d'une application plus légère à déployer à côté de son hébergement Git existant.

La plateforme du serveur et celle des workers sont deux choix distincts. GitLab Runner peut fonctionner notamment sous Windows et macOS, alors que le serveur GitLab Self-Managed pris en charge fonctionne sous Linux. L'exécution d'Ansible nécessite un environnement de contrôle compatible, tel que Linux, WSL ou un runner Linux, même lorsque le service web de Semaphore UI fonctionne sous Windows.

Les jobs GitLab exécutent les commandes définies dans le YAML du pipeline, à l'aide des outils installés sur le runner ou fournis par une image de conteneur. Ansible, Terraform/OpenTofu et Terragrunt peuvent donc participer au même pipeline que les tests et les déploiements, ou à un pipeline de maintenance indépendant. GitLab documente aussi des composants OpenTofu et des workflows d'infrastructure pour les modifications revues dans des merge requests.

Semaphore UI propose des modèles de tâches dédiés à Ansible, Terraform/OpenTofu, Terragrunt, Bash, PowerShell et Python. Les ingénieurs sélectionnent le dépôt, les réglages de l'outil, les identifiants et les variables partagées dans l'interface, tandis que le code d'automatisation reste dans Git. Une tâche de provisionnement Terraform ou une vérification de disponibilité en Python peut s'exécuter seule, selon une planification ou dans un workflow. Ce modèle convient aux équipes qui souhaitent conserver leurs réglages de lancement partagés dans Semaphore UI et proposer des opérations préparées via l'interface. Le YAML de pipeline est utile lorsque les modifications de l'orchestration elle-même, notamment l'ordre et la configuration des jobs, doivent faire l'objet d'une revue de code et d'un historique de versions.

Pour le provisionnement, Semaphore UI Pro ajoute un backend HTTP d'état avec workspaces, historique de versions et gestion dans l'interface. L'état partagé Terraform/OpenTofu peut rester avec les opérations IaC préparées, sans nécessiter un autre service. L'état Terraform/OpenTofu géré par GitLab est disponible dans Free et prend également en charge un backend HTTP et le verrouillage. Les backends externes existants restent possibles dans les deux produits. Les commandes plan et apply par défaut de Semaphore UI désactivent le verrouillage sauf si elles sont modifiées. La prise en charge par le backend ne suffit donc pas à l'activer pour ces exécutions.

Introduire Semaphore UI n'impose pas de déplacer les dépôts. Un projet peut enregistrer plusieurs dépôts Git avec leurs propres URL, branches et identifiants, puis sélectionner celui qui convient dans chaque modèle. GitLab CI/CD fonctionne également avec des hébergeurs Git externes : l'intégration de dépôts externes de Premium et Ultimate crée un projet GitLab miroir. La configuration du pipeline peut se trouver à un autre chemin, dans un autre projet ou à une URL YAML externe, et un job peut cloner explicitement un autre dépôt. Les pipelines GitLab appartiennent toujours à un projet GitLab. Le projet d'opérations de Semaphore UI peut ainsi coexister avec les hébergeurs Git de l'équipe, tandis que GitLab reste une option pour les pipelines de livraison comme de maintenance.

GitLab définit les jobs dans le YAML du pipeline. Son éditeur de pipelines valide et visualise cette configuration, et son Pipeline Wizard génère un fichier de configuration enregistré dans un dépôt. Le formulaire Task Template de Semaphore UI enregistre une opération en sélectionnant son outil, son dépôt, son inventaire et ses groupes de variables, sans définition YAML CI/CD. Cette différence concerne la manière dont les ingénieurs maintiennent la procédure enregistrée. Les deux produits peuvent lancer les jobs existants manuellement avec des entrées ou selon une planification, sans nouveau commit à chaque exécution.

Les entrées de pipeline GitLab sont des paramètres typés déclarés en YAML, avec des valeurs par défaut, des choix autorisés et une validation par expression régulière. Les variables CI/CD de groupe et de projet fournissent une configuration réutilisable, avec notamment une portée par environnement. Un collègue renseigne ces entrées lorsqu'il lance le pipeline préparé, tandis que la planification du pipeline fournit la configuration des exécutions sans intervention.

Semaphore UI conserve la configuration réutilisable dans le modèle de tâche, l'inventaire sélectionné et les groupes de variables. Les formulaires exposent les valeurs de lancement avec des champs obligatoires, une vérification des entiers et des choix prédéfinis. Ils ne proposent pas les règles d'expressions régulières configurables de GitLab. Par exemple, un ingénieur peut préparer une opération sur un service avec des choix pour son nom, l'état souhaité et l'environnement. Le collègue remplit ce formulaire, lance la tâche et consulte son état et sa sortie. Le playbook implémente l'action demandée, tandis que les ressources partagées fournissent le dépôt, les hôtes et les détails de connexion.

Semaphore UI relie également les modèles Build et Deploy. Un build enregistre une version et un déploiement sélectionne une version issue d'un build réussi ou démarre automatiquement après sa réussite. L'automatisation publie et récupère le paquet ou l'image dans le stockage choisi par l'équipe. GitLab représente cette livraison au moyen de jobs de pipeline, de références d'artefacts et d'environnements de déploiement, avec des résultats de tests et de livraison intégrés.

La même configuration permet des exécutions sans intervention. Un modèle de vérification des certificats peut s'exécuter chaque nuit sur l'inventaire de l'environnement et signaler un échec lorsque le playbook détecte un certificat proche de l'expiration. Une expression cron comme 0 2 * * * le programme chaque jour à 02:00 dans le fuseau horaire de l'ordonnanceur, UTC par défaut. Les planifications ponctuelles couvrent une fenêtre de maintenance prévue. GitLab peut également planifier le même playbook à l'aide d'une planification de pipeline et d'entrées configurées.

Semaphore UI fait de l'inventaire une ressource de projet nommée que les modèles peuvent partager. Il peut contenir de l'INI/YAML modifiable, référencer un fichier dans Git ou utiliser les plugins d'inventaire dynamique d'Ansible. L'inventaire sélectionné conserve aussi les références d'identifiants d'hôte et, le cas échéant, de sudo, de sorte que modifier la configuration des cibles n'oblige pas à éditer chaque opération de maintenance.

GitLab peut utiliser les mêmes fichiers Ansible et plugins de découverte. Un job récupère l'inventaire depuis son dépôt ou une autre source configurée, installe le plugin de découverte nécessaire et transmet les entrées sélectionnées à Ansible. Les deux peuvent découvrir les hôtes via des API cloud ou d'autres systèmes pris en charge par les plugins Ansible installés. Semaphore UI se distingue par son objet d'inventaire réutilisable et ses paramètres de connexion dans l'interface d'exploitation.

Pour une tâche de rétablissement sur un seul serveur, un limit Ansible autorisé restreint l'exécution sans créer de nouvel inventaire. Cela sélectionne des hôtes au sein d'une même tâche, plutôt que de découper automatiquement le parc en jobs indépendants. Un inventaire dans Git reste utile dans l'un ou l'autre produit lorsque ses modifications doivent être revues.

Les GitLab Runners exécutent les jobs avec des exécuteurs shell, Docker ou Kubernetes. Semaphore UI peut exécuter les tâches sur son serveur applicatif ou sur un runner proche des systèmes administrés. Les deux permettent de placer l'exécution dans un réseau privé tout en hébergeant l'interface commune ailleurs.

GitLab prend en charge des runners propres à un projet et le routage des jobs par tags. Semaphore UI Pro ajoute des runners affectés aux projets, le routage par tags et l'exécution Docker par tâche. Enterprise ajoute l'exécution des tâches dans Kubernetes. Ces réglages permettent de sélectionner une capacité d'exécution disposant de la connectivité et des dépendances nécessaires. Installer le serveur applicatif dans un conteneur reste une décision distincte du choix d'un environnement conteneurisé pour chaque job.

Les workflows de Semaphore UI relient les opérations enregistrées lorsqu'une procédure utilise plusieurs outils. Une tâche OpenTofu peut créer un environnement, une tâche Ansible configurer ses hôtes et une tâche Python l'enregistrer dans un autre système. Les branches de réussite et d'échec orientent l'étape suivante, et une approbation peut suspendre la séquence avant une modification. Les modèles restent utilisables séparément pour la maintenance ultérieure. Lancer un diagnostic n'impose donc pas de rejouer toute la procédure de provisionnement.

L'éditeur de workflows de Semaphore UI permet de relier les modèles enregistrés et de configurer leurs chemins de réussite ou d'échec sur un graphe. L'éditeur de pipelines de GitLab modifie et valide le YAML, puis visualise les jobs et les dépendances needs qui en résultent. Cette visualisation aide à examiner la procédure, mais modifier ses connexions revient à modifier la configuration du pipeline. Cette différence compte lorsqu'un opérateur souhaite assembler visuellement des procédures existantes plutôt que maintenir leur orchestration en YAML.

GitLab peut transmettre des valeurs calculées aux jobs suivants via des artefacts de rapport dotenv, par exemple une version déployée ou l'URL d'un environnement. Les données JSON complexes ou multilignes utilisent plutôt un artefact de fichier ordinaire. Le provisionnement et la configuration peuvent transmettre des valeurs structurées entre les tâches Semaphore UI. Une sortie Terraform/OpenTofu contenant l'adresse d'un nouvel hôte peut ainsi devenir une entrée de l'opération suivante. Dans la version 2.20, la collecte des sorties couvre Ansible set_stats, les sorties Terraform/OpenTofu/Terragrunt et le JSON produit par Bash, PowerShell ou Python avec l'exécuteur local sur le serveur ou un runner distant. Les exécuteurs de tâches Docker et Kubernetes ne produisent pas ces sorties de workflow. Le modèle destinataire déclare l'entrée, que son playbook ou sa configuration d'inventaire utilise ensuite pour cibler le nouvel hôte.

GitLab peut suspendre un pipeline au moyen d'un job manuel bloquant dans toutes les offres. Configurez when: manual avec allow_failure: false, car les jobs manuels facultatifs ne bloquent pas le pipeline. Les approbations de déploiement de Premium et Ultimate ajoutent des exigences d'approbation attribuées indépendamment pour les environnements protégés. Dans Semaphore UI 2.20, l'approbation d'un workflow dépend du droit d'exécuter les tâches du projet. Un rôle d'approbateur distinct est annoncé pour la version 2.21. Utilisez les approbations d'environnements protégés de GitLab lorsqu'une séparation des droits d'approbation gérée indépendamment est nécessaire.

Les fichiers suivent un autre chemin. Un paquet compilé ou un plan Terraform enregistré doit être stocké à un endroit accessible à l'opération suivante, ou transféré explicitement. Les artefacts de jobs de GitLab couvrent déjà cette partie d'un pipeline de livraison. Lorsque Semaphore UI gère le déploiement, son automatisation peut récupérer l'artefact publié à partir de la version ou du digest fourni par la CI. GitLab conserve ainsi les résultats du build, tandis que les opérations ultérieures sur les hôtes utilisent les inventaires, les identifiants et l'historique d'exécution de Semaphore UI.

Les composants CI/CD de GitLab regroupent une configuration de pipeline versionnée et réutilisable, y compris des séquences de jobs. Semaphore UI réutilise des modèles de tâches individuels, tandis que la séquence est définie dans chaque workflow et ne peut pas être insérée comme un workflow imbriqué. Les composants sont utiles lorsque de nombreux pipelines de livraison doivent partager un processus de plusieurs étapes maintenu en commun. Le modèle de Semaphore UI convient lorsque les équipes réutilisent surtout les opérations sous-jacentes et les relient différemment pour le provisionnement, le déploiement ou la restauration.

GitLab utilise des rôles de groupe et de projet, avec des contrôles supplémentaires pour les branches et les environnements protégés. Le rôle Developer standard permet d'exécuter des pipelines, mais aussi de pousser du code vers des branches non protégées. Pour un accès limité au déploiement, sans ces droits de contribution au code, Premium et Ultimate permettent d'inviter des groupes ayant le rôle Reporter et de leur donner accès à un environnement protégé. Les équipes qui délèguent des opérations via GitLab configurent explicitement ce périmètre de déploiement.

Semaphore UI donne à l'équipe d'exploitation son propre périmètre de projet, regroupant modèles, inventaires, dépôts, identifiants et groupes de variables. Community sépare déjà l'administration du projet de l'exécution : les Task Runners peuvent lancer les modèles du projet et disposent d'un accès en lecture seule aux autres ressources. Les ingénieurs maintiennent la configuration préparée, tandis que leurs collègues exécutent les procédures rendues disponibles dans le projet.

Les rôles personnalisés et les permissions par modèle d'Enterprise permettent d'affiner encore ce périmètre. Un collègue du support peut avoir le rôle de base Guest et un rôle personnalisé lui accordant l'exécution d'un modèle précis de redémarrage, plutôt qu'un accès Task Runner à tout le projet. L'ingénieur prépare l'inventaire, les identifiants et les options de lancement. Ce modèle est utile lorsque l'action déléguée est plus précise qu'une appartenance à l'ensemble du projet d'exploitation.

Le formulaire est l'interface de la procédure, pas un substitut à ses règles d'accès. Le code d'automatisation et les paramètres que l'on autorise à modifier au lancement doivent limiter l'opération aux cibles prévues. Les permissions de modèle de Semaphore UI ne fournissent pas des droits distincts sur les inventaires et les identifiants permettant de combiner arbitrairement les ressources.

GitLab Self-Managed prend en charge LDAP et OpenID Connect. GitLab propose également une authentification à deux facteurs au niveau du compte. Semaphore UI Pro fournit un TOTP local et prend en charge LDAP et OIDC. L'identité centralisée vérifie qui se connecte, tandis que les rôles de projet et les permissions de modèles définissent toujours les opérations que cette personne peut exécuter.

Les jobs GitLab utilisent des variables CI/CD qui peuvent être masquées ou cachées. Les intégrations de secrets externes de Premium demandent des valeurs à des services tels que HashiCorp Vault, AWS Secrets Manager, Azure Key Vault et Google Cloud Secret Manager. GitLab 19.5 propose aussi un Secrets Manager fondé sur OpenBao pour Premium et Ultimate, facturé via GitLab Credits pour les licences en ligne, avec un module complémentaire pour les licences Self-Managed hors ligne. Les jobs demandent explicitement ses secrets. L'accès est contrôlé par les permissions configurées et consigné dans les événements d'audit.

Le Key Store de Semaphore UI distingue les clés SSH des identifiants de type utilisateur/mot de passe, qui comprennent les mots de passe et les jetons d'accès. Un dépôt sélectionne l'identifiant utilisé pour récupérer son code, un inventaire Ansible sélectionne les identifiants des hôtes et éventuellement de sudo, et le modèle peut utiliser un mot de passe Ansible Vault. Ces relations font partie de l'opération enregistrée. Un collègue qui lance une tâche de renouvellement de certificat ou de maintenance d'un service n'a donc pas à coller chaque secret de connexion dans le formulaire.

Pour une équipe qui exploite déjà un coffre-fort, Semaphore UI Pro s'intègre à HashiCorp Vault et OpenBao. Enterprise ajoute AWS Secrets Manager, Azure Key Vault et Devolutions Server. Pour le même déploiement, GitLab fournit les secrets au moyen de variables de job ou d'intégrations de secrets configurées. Semaphore UI rattache les références d'identifiants aux dépôts, aux inventaires et aux modèles. Les opérateurs réutilisent ainsi les connexions préparées au lancement. Une commande peut aussi récupérer directement un secret lorsqu'aucune intégration native ne couvre le service nécessaire, cette récupération étant configurée et maintenue par l'équipe.

Pour OpenBao et Devolutions Server, Semaphore UI propose des intégrations nommées au Key Store dans Pro et Enterprise, respectivement. Les jobs GitLab peuvent récupérer une valeur OpenBao via sa CLI ou une entrée Devolutions Credentials via son API. L'équipe maintient l'authentification, la récupération et l'injection dans le job, au lieu de sélectionner une connexion enregistrée dans le Key Store. Cette approche est viable lorsque le coffre-fort et le code du job existants couvrent déjà la procédure.

Semaphore UI Enterprise s'intègre à CyberArk via l'API REST PVWA. Un job GitLab exécutant Ansible peut récupérer des identifiants CyberArk via la collection cyberark.pas et Central Credential Provider, à condition de configurer la collection et l'authentification applicative dans l'environnement du job. Ces intégrations utilisent différentes interfaces CyberArk. Il faut donc choisir celle qui correspond au service CyberArk exploité par l'équipe.

Semaphore UI conserve l'état de la tâche, les détails du lancement, la révision du dépôt et la sortie. Pro ajoute une synthèse intégrée par hôte et par tâche Ansible, qui facilite l'identification des hôtes concernés par une vérification échouée sur le parc. GitLab conserve les journaux des jobs et peut afficher les résultats Ansible via des artefacts de rapport JUnit configurés. Les rapports de tests alimentent aussi les vues des merge requests et des pipelines, utiles lorsque les vérifications d'infrastructure font partie d'une revue de code.

Pour les revues d'accès et l'investigation d'incidents, Semaphore UI enregistre les authentifications, les modifications de ressources et l'activité des tâches lorsque la journalisation d'audit est activée. Sa vue d'audit administrateur couvre plusieurs projets dans toutes les éditions. GitLab Premium et Ultimate proposent des pages d'audit de groupe et de projet, tandis que l'historique des comptes de Free couvre les connexions réussies. Les permissions d'audit et les types d'événements de GitLab suivent les périmètres du groupe, du projet et de l'instance.

Semaphore UI Pro ajoute le filtrage, l'export CSV ou JSONL et la transmission via TLS Syslog ou Splunk HEC. GitLab Ultimate diffuse les événements d'audit de groupe en JSON vers des destinations externes. Les deux peuvent alimenter un système de gestion des informations et des événements de sécurité, ou SIEM, mais ces événements et leur périmètre diffèrent de la sortie ordinaire des jobs.

Semaphore UI fournit une API de tâches authentifiée et des points d'entrée d'intégration. Des règles de correspondance filtrent les requêtes, puis des extracteurs associent les en-têtes ou les champs du corps aux entrées de la tâche. GitLab expose des API de déclenchement de pipelines et des URL de webhook qui lancent un pipeline pour une branche ou un tag. Ses intégrations de projet relient aussi les événements de livraison aux outils de suivi de tickets et aux services externes. Une alerte de supervision peut donc lancer un diagnostic préparé sans nouveau commit de code.

Semaphore UI propose des canaux de notification par e-mail, Slack, Microsoft Teams, Telegram, Rocket.Chat, DingTalk et Gotify. Les modèles et les alertes de projet choisissent la destination des résultats. GitLab fournit des intégrations de projet telles que les notifications Microsoft Teams, les e-mails d'état des pipelines et son application Slack. Un lien de notification permet aux collègues d'examiner une exécution, mais ne constitue pas en lui-même une approbation depuis le chat.

Les deux produits proposent une documentation publique et des API que des assistants comme Claude Code et Codex peuvent consulter pour rédiger une configuration ou examiner la sortie d'un job. Le YAML de pipeline de GitLab donne à l'assistant la configuration de livraison, tandis que l'API de Semaphore UI expose l'opération enregistrée et ses ressources de projet. Cela permet d'aider à la configuration et au dépannage, sans garantir automatiquement la justesse des modifications générées.

GitLab 19.5 inclut un serveur MCP généralement disponible, dont les outils dépendent de l'accès et des fonctionnalités sous licence. Semaphore UI dispose d'un connecteur MCP communautaire pour son API et a annoncé une prise en charge officielle de MCP dans Pro pour la version 2.21.0. L'accès du connecteur dépend du compte et des identifiants fournis. L'assistant doit donc recevoir un périmètre adapté à l'opération.