Interface Terraform : Semaphore UI et Gaia

Gaia sépare son application web Java, sa base MongoDB et son runner d'exécution. Le runner lance Terraform dans des conteneurs Docker ou des pods Kubernetes, avec une limite configurable de jobs parallèles. Docker Compose assemble ces services. Un chart Helm expérimental offre une option d'installation Kubernetes.

Semaphore UI fonctionne sous forme de binaire ou de paquet natif, ainsi que dans Docker ou Kubernetes. Une équipe qui déplace l'automatisation courante hors des ordinateurs des ingénieurs peut commencer sur un serveur existant et utiliser le même service pour le provisionnement Terraform et la maintenance Ansible. Le mode d'exécution choisi détermine si des conteneurs de jobs sont nécessaires.

Gaia exécute les modules Terraform via une séquence de commandes Terraform générée. Les provisioners Terraform peuvent appeler Ansible ou des programmes en ligne de commande lorsque l'image du runner ou la cible distante fournit les outils nécessaires. Cela permet de configurer une ressource nouvellement provisionnée, mais la commande reste liée à une exécution Terraform plutôt que de devenir une opération Gaia indépendante. La construction standard des commandes ne fournit pas de modèle distinct OpenTofu ou Terragrunt.

Semaphore UI possède des modèles directs pour Ansible, Terraform/OpenTofu, Terragrunt, Bash, PowerShell et Python. Une équipe peut créer l'infrastructure avec OpenTofu, configurer les paquets avec Ansible et lancer une vérification de disponibilité en Python. Plus tard, la configuration Ansible ou une opération de maintenance PowerShell peut s'exécuter seule, sans démarrer un autre cycle Terraform. Le backend d'état intégré de Pro conserve aussi l'état Terraform/OpenTofu et son historique à côté de ces jobs.

L'auteur d'un module Gaia définit le dépôt source, la version de Terraform et le schéma des variables. Les utilisateurs créent des stacks à partir du module et fournissent les valeurs et l'identifiant cloud adaptés à leur environnement. La stack devient une instance durable avec son propre état et ses jobs, ce qui convient à un catalogue d'infrastructures demandées indépendamment. Gaia valide les valeurs obligatoires et des expressions régulières configurables. Les formulaires Semaphore UI valident les champs obligatoires, les entiers et les choix, sans règle configurable équivalente par expression régulière.

Semaphore UI appelle l'opération enregistrée un Task Template. Elle regroupe un dépôt, la configuration de l'outil, les variables ainsi que les inventaires et identifiants nécessaires. Des groupes de variables nommés réutilisent les paramètres d'environnement entre modèles, tandis que les champs du formulaire collectent les entrées au lancement. Un modèle de redémarrage de service peut par exemple proposer un choix de service et d'environnement au lieu de demander au collègue de construire une commande. Un modèle de provisionnement peut utiliser le même principe pour les paramètres d'environnement.

Gaia exécute plan, apply et destroy avec le module, les entrées et les identifiants cloud configurés dans la stack. Son backend intégré conserve l'état de cette stack, tandis que sa page rassemble les sorties et l'historique des jobs. Des environnements de test distincts peuvent donc conserver un état et des enregistrements d'exécution indépendants, même s'ils proviennent du même module.

Semaphore UI utilise un modèle de tâche pour sélectionner le dépôt, le workspace et la configuration Terraform/OpenTofu. Les groupes de variables réutilisent les paramètres entre jobs liés, et les formulaires collectent les entrées au lancement. Un ingénieur peut préparer une seule fois une opération de provisionnement d'environnement, puis permettre aux collègues de la demander via cette configuration enregistrée. Chaque environnement a aussi besoin de ses propres variables, identifiants et état de backend. Gaia les représente par des instances de stacks distinctes. Dans Semaphore UI, l'équipe prépare la configuration correspondante de modèle, de workspace et de backend. L'isolation des workspaces dépend du backend. Sélectionner un workspace ne sépare donc pas l'état avec tous les backends. Terragrunt et OpenTofu sont des choix de modèles directs aux côtés de Terraform.

L'état constitue une partie distincte de cette configuration. Gaia inclut un backend d'état pour chaque stack sans licence commerciale. Semaphore UI utilise le backend configuré dans le code Terraform/OpenTofu. Pro fournit aussi un backend HTTP d'état intégré avec historique et gestion dans l'interface. Conserver ce backend dans Semaphore UI place l'état partagé à côté des jobs qui le modifient, plutôt que d'ajouter un autre service d'état.

Aucun des deux produits n'applique par défaut un fichier de plan précédemment enregistré. Gaia 2.4.0 affiche le résultat de la planification, mais sa commande apply n'utilise pas le fichier de plan enregistré. L'exécution par défaut de Semaphore UI lance également plan et apply séparément. Si l'approbation doit porter sur le changement exact proposé, la procédure nécessite un stockage et une réutilisation explicites du plan.

Gaia conserve les ressources et les sorties Terraform avec chaque stack. Une sortie Terraform peut fournir l'adresse d'hôte nécessaire à un provisioner ou à un autre système, mais elle ne crée pas de ressource d'inventaire Ansible dans l'interface Gaia. Ansible appelé via un provisioner doit recevoir ou générer son inventaire dans cette automatisation.

Semaphore UI stocke les inventaires Ansible comme des ressources de projet réutilisables. Les équipes peuvent modifier une définition statique, utiliser un fichier Git ou laisser des plugins d'inventaire Ansible découvrir les hôtes à l'exécution. Le même inventaire peut servir aux déploiements, aux correctifs et aux vérifications de certificats. Cela est particulièrement utile lorsque le provisionnement n'est que le début du travail et que les opérateurs reviennent sur un parc existant pendant toute sa durée de vie.

Gaia sépare l'application de son runner. Le runner demande les étapes Terraform en attente et les exécute dans des conteneurs Docker ou des pods Kubernetes, avec une concurrence configurable. Il peut fonctionner près de l'infrastructure privée s'il peut atteindre l'API Gaia et les services utilisés par le module. L'image choisie fournit Terraform et les programmes supplémentaires nécessaires aux provisioners.

Semaphore UI peut exécuter les jobs sur son serveur applicatif ou sur des runners proches des cibles. Une petite installation peut ainsi commencer sans plateforme de conteneurs, tandis qu'une plus grande atteint différents réseaux via des runners. Pro ajoute les runners de projet et l'exécution Docker, tandis qu'Enterprise ajoute les pods Kubernetes par job. Installer l'application web dans Docker et exécuter chaque job dans son propre conteneur restent deux choix distincts.

Semaphore UI enregistre les planifications cron et ponctuelles sur les modèles préparés. Une sauvegarde nocturne, une vérification récurrente de certificats ou un job de correctifs peut réutiliser l'inventaire, les identifiants et les réglages de lancement choisis par l'auteur. Les exécutions manuelles et planifiées apparaissent ensuite dans le même historique.

Gaia 2.4.0 ne comporte pas d'interface de planification. Un ordonnanceur externe peut créer un job RUN ou DESTROY via POST /api/stacks/{id}/{jobType}, puis démarrer son plan via POST /api/jobs/{jobId}/plan. Appliquer le changement nécessite un POST distinct vers /api/jobs/{jobId}/apply après la fin du plan. L'ordonnanceur doit gérer ce cycle et examiner le résultat final, plutôt que d'assimiler la création d'un identifiant de job à une exécution terminée.

Gaia guide une stack à travers la planification et l'application. Son interface propose une confirmation distincte après le plan, y compris pour détruire une stack. Les provisioners Terraform peuvent effectuer des actions supplémentaires dans ce cycle, et un système externe peut coordonner plusieurs jobs via l'API. Gaia ne fournit pas de graphe visuel d'opérations Ansible, Terraform et de scripts réutilisables indépendamment.

Semaphore UI relie les modèles enregistrés au moyen d'un workflow visuel, avec approbation et chemins de réussite et d'échec. Un déploiement peut provisionner l'infrastructure, attendre une approbation, configurer les hôtes et lancer une vérification, tandis que chaque modèle reste disponible pour la maintenance ultérieure. Les valeurs collectées peuvent être transmises entre étapes avec l'exécuteur local sur le serveur ou un runner. Les fichiers générés et les plans Terraform enregistrés nécessitent toujours un stockage accessible ou un transfert explicite. Aucun des deux produits n'applique par défaut un plan Terraform précédemment enregistré.

Gaia utilise des organisations pour partager les modules, avec des rôles administrateur et utilisateur. Un auteur peut rendre une définition Terraform approuvée disponible à une équipe, tandis que les utilisateurs fournissent la configuration de leurs propres stacks. Les intégrations GitHub et GitLab combinent connexion OAuth2 et importation de dépôts. LDAP est également pris en charge.

Semaphore UI Community organise l'automatisation partagée dans des projets. Les rôles de projet contrôlent qui peut voir, exécuter ou modifier l'automatisation du projet. Les collègues autorisés à exécuter peuvent lancer un déploiement, une sauvegarde ou un job de maintenance et consulter le résultat. L'ingénieur prépare l'opération, tandis que le collègue utilise sa configuration enregistrée et ses entrées de lancement.

Enterprise ajoute les rôles personnalisés et les permissions d'exécution par modèle lorsque l'accès doit se limiter à certaines opérations. Une équipe peut par exemple déléguer un modèle de redémarrage sans donner à l'opérateur des droits généraux d'édition du projet. Ce périmètre résulte conjointement des permissions du rôle et de la configuration de l'opération, et non du formulaire seul. Pro ajoute la connexion LDAP et OIDC pour les équipes utilisant un fournisseur d'identité central. Semaphore UI Pro ajoute aussi l'authentification à deux facteurs TOTP pour les comptes locaux.

Gaia fournit des identifiants cloud pour AWS, Google Cloud et Azure. Son intégration Vault facultative utilise le moteur Transit pour le chiffrement et peut demander des identifiants AWS dynamiques à un moteur de secrets Vault. Ces identifiants servent au cycle de vie des stacks Terraform.

Le Key Store de Semaphore UI prend en charge les identifiants utilisés dans les procédures de l'équipe, notamment les clés SSH et les mots de passe des hôtes Ansible. Une opération préparée référence ces entrées stockées au lieu de demander à l'opérateur de coller les identifiants à chaque lancement. Pro ajoute la récupération de secrets dans HashiCorp Vault et OpenBao. Enterprise ajoute les intégrations AWS Secrets Manager, Azure Key Vault et Devolutions Server, ainsi que CyberArk via son API PVWA.

Un environnement peut par exemple utiliser un identifiant cloud pour le provisionnement et une clé SSH pour sa configuration Ansible ultérieure. Ces identifiants restent distincts et associés à l'opération concernée. Les deux plateformes peuvent fonctionner avec Vault, mais le chiffrement et les identifiants dynamiques de Gaia diffèrent de la récupération d'un secret stocké pour un job. Les types d'identifiants intégrés de Gaia n'incluent pas de connecteurs pour les autres magasins de secrets mentionnés. Le code Terraform peut récupérer des secrets via ses propres sources de données ou des commandes externes. Cette récupération est alors configurée et maintenue dans l'automatisation plutôt que dans l'interface d'identifiants de Gaia.

Gaia enregistre l'utilisateur, l'état, les horaires et les étapes plan/apply d'un job de stack. Cet historique aide à examiner les changements de provisionnement d'un environnement et à analyser la sortie Terraform. Il s'agit d'un enregistrement d'opérations de stack, pas d'une interface de rapports par hôte Ansible ni d'audit administratif.

Semaphore UI conserve l’historique des tâches pour tous les outils pris en charge. Les synthèses Ansible de Pro ajoutent les résultats par hôte et par tâche, permettant à un opérateur d’identifier les serveurs sur lesquels une mise à jour ou une vérification de certificat a échoué. Son journal d’audit enregistre les connexions et les actions administratives prises en charge séparément de la sortie des tâches. Une équipe qui assure à la fois le provisionnement et la maintenance des hôtes peut ainsi analyser ces opérations dans le même service, sans considérer l’état Terraform comme un compte rendu de chaque action effectuée sur un serveur. Pro ajoute le filtrage et l’export des événements d’audit, notamment vers Syslog et Splunk HEC pour alimenter le SIEM de l’équipe.

Gaia importe des modules depuis GitHub ou GitLab et expose des API pour les stacks, les jobs et leurs résultats. Un pipeline CI ou un service de demandes externe peut créer un job de stack, lancer la planification et décider quand appliquer le plan. Une configuration pilotée par webhook nécessite un adaptateur qui effectue ces appels et suit leur résultat. Semaphore UI fournit une API REST et des webhooks d’intégration entrants qui filtrent les requêtes et associent leurs valeurs aux paramètres des tâches préparées.

Une équipe qui conserve le catalogue Terraform de Gaia peut utiliser une intégration API pour déclencher un modèle Ansible de configuration ou de maintenance dans Semaphore UI après le provisionnement. Semaphore UI gère alors l’inventaire, les identifiants et l’historique d’exécution de cette opération. Cette connexion doit être mise en place par l’équipe, ce n’est pas une intégration Gaia–Semaphore native. Les deux projets publient également leur documentation et leur code source, qu’un assistant de programmation peut consulter pour ébaucher cette connexion ou analyser la configuration et la sortie des jobs.