Semaphore (anciennement Ansible Semaphore, aujourd’hui Semaphore UI) est une interface web open source qui permet d’exécuter des playbooks Ansible depuis un navigateur, sans passer par la ligne de commande.

Écrit en Go, léger et autonome, il gère les inventaires, les identifiants, la planification, l’historique d’exécution et le contrôle d’accès, et sert d’alternative légère à AWX et à Ansible Automation Platform. Il prend aussi en charge Terraform, OpenTofu, Bash et PowerShell. 

Ce guide technique explique ce qu’est Semaphore, pourquoi l’associer à Ansible, ses concepts clés, son installation avec Docker, l’exécution et la planification de playbooks, l’usage de l’API, ainsi que les bonnes pratiques de sécurité. 

Qu’est-ce que Semaphore (anciennement Ansible Semaphore) ?

Semaphore est une application web open source qui fournit une couche de pilotage au-dessus d’Ansible. Plutôt que de lancer chaque playbook depuis un terminal, les équipes organisent dans un seul espace navigateur leurs projets, dépôts, inventaires, identifiants, modèles de tâches, planifications et historiques d’exécution.

Le projet, longtemps nommé Ansible Semaphore, a été rebaptisé Semaphore UI à mesure qu’il élargissait sa portée au-delà d’Ansible. 

Trois caractéristiques le définissent :

• Légèreté : écrit en Go, il tient dans un binaire unique et fonctionne avec très peu de ressources, là où des plateformes plus complètes demandent davantage.
• Polyvalence : au-delà des playbooks Ansible, il exécute aussi du code Terraform, OpenTofy, Bash et PowerShell.
• Non-intrusif : si vous utilisez déjà Ansible, Semaphore s’y greffe sans mofifier vos playbooks ni vos rôles existants.

Attention à ne pas le confondre avec Semaphore CI, une plateforme d’intégration continue qui n’a aucun lien avec ce projet, malgré le nom commun. 

Pourquoi utiliser Semaphore avec Ansible ?

Semaphore transforme Ansible, un outil en ligne de commande, en une plateforme accessible à toute une équipe ops. Voici les principaux bénéfices qu’il apporte au quotidien : 

• Une interface pour les non-initiés à la ligne de commande : les membres d’une équipe ops peuvent lancer des playbooks sans maîtriser le terminal.
• L’exécution en un clic : plus besoin de se connecte en SSH à un serveur et de taper des commandes, un bouton suffit.
• La planification : des expressions de type cron déclenchent automatiquement les playbooks récurrents (mises à jour, sauvegardes, tâches de maintenance).
• Le contrôle d’accès : on donne des droits aux collaborateurs sans partager les clés SSH qui sont conservées dans un magasin dédié.
• La traçabilité : chaque exécuriton est historisée, horodatée et accompagnée de sa sortie, ce qui facilite l’audit et le déblocage.
• Une empreinte minimale : un binaire unique, capable de tourner avec une faible quantité de mémoire, idéale du homelab à la PME.

Semaphore, AWX et Ansible Automation Platform : que choisir ? 

Le choix dépend du contexte. Semaphore vise la simplicité et la légèreté : il s’installe et s’exploite vite, sans infrastructure lourde.

AWX, successeur open source d’Ansible Tower, et Ansible Automation Platform, son édition commerciale soutenue par Red Hat, s’adressent aux organisations qui recherchent un écosystème complet, des fonctionnalités d’entreprise et un support contractuel.

Pour beaucoup d’équipes, Semaphore couvre le besoin réel sans la complexité d’AWX. 

Les concepts clés de Semaphore (Projet, Inventaire, Key Store…)

Avant de configurer votre premier projet, voici les notions essentielles pour se repérer dans l’interface et le vocabulaire de Semaphore :

• Projet : l’espace de travail qui regroupe tous les éléments d’un périmètre (dépôts, inventaires, identifiants et modèles de tâches).
• Dépôt (repository) : la source Git contenant vos playboks et vos rôles, que Semaphore clone pour exécuter les tâches.
• Inventaire : la liste des hôtes cibles, statique ou dynamique, sur lesquels les playbooks s’exécutent.
• Environnement : les variables supplémentaires passées à l’exécution, au format JSON, pour paramétrer un playbook sans le modifier.
• Key Store (magasin de clés) : le coffre qui stocke les secrets (clés SSH, mots de passe et identifiants) sans jamais les exposer aux utilisateurs.
• Task Template (modèle de tâche) : la définition d’une exécution (playbook, dépôt, inventaire, environnement, planification évènementelle et Type (Ansible, Terraform, Bash, etc.)).
• Schedule (planification) : une expression cron qui déclenche automatiquement un modèle de tâche.
• Teams et Runners : la gestion des droits par équipe et les agents d’exécution distribués pour lancer les tâches au plus près des cibles.

Comment installer Semaphore avec Docker ?

La méthode la plus rapide pour démarrer est Docker. Le fichier docker-compose ci-dessous lance Semaphore avec la base embarquée BoltDB, suffisante pour un test ou un petit usage. L’interface est ensuite accessible sur le port 3000. 

services: 

  semaphore: 

    image: semaphoreui/semaphore:latest 

    container_name: semaphore 

    ports: 

      - "3000:3000" 

    environment: 

      SEMAPHORE_DB_DIALECT: bolt 

      SEMAPHORE_ADMIN: admin 

      SEMAPHORE_ADMIN_NAME: Admin 

      SEMAPHORE_ADMIN_EMAIL: admin@example.com 

      SEMAPHORE_ADMIN_PASSWORD: a_changer 

    volumes: 

      - semaphore_data:/var/lib/semaphore 

volumes: 

  semaphore_data: 

On lance ensuite la pile avec docker compose up -d, puis on se connecte sur http://localhost:3000 avec le compte administrateur défini. Pour une installation par binaire ou paquet (.deb, .rpm), le compte administrateur se crée en ligne de commande : 

semaphore user add --admin \ 

  --login admin --name "Admin" \ 

  --email admin@example.com \ 

  --password 'a_changer' \ 

  --config /etc/semaphore/config.json 

Pour un usage en production, on remplace BoltDB par PostgreSQL ou MySQL, plus robustes et adaptés à la concurrence, et l’on place Semaphore derrière un reverse proxy (Nginx, par exemple) avec un certificat TLS. 

Comment exécuter un playbook Ansible dans Semaphore ?

Une fois connecté, l’exécution d’un playbook suit une séquence logique, du paramétrage au lancement. 

• Créer un projet : il servira de conteneur à tous les éléments de ce périmètre. 

• Ajouter le dépôt Git : renseignez l’URL du dépôt contenant vos playbooks et la branche à utiliser. 

• Enregistrer les clés dans le Key Store : ajoutez la clé SSH (ou les identifiants) permettant à Semaphore d’accéder au dépôt et aux hôtes cibles. 

• Définir l’inventaire : déclarez les hôtes cibles, en réutilisant un inventaire existant ou en le saisissant directement. 

• Configurer un environnement : ajoutez au format JSON les variables supplémentaires éventuelles. 

• Créer un modèle de tâche : indiquez le nom du playbook (chemin relatif au dépôt, par exemple site.yml), le dépôt, l’inventaire, l’environnement, et le type Ansible Playbook. 

• Lancer l’exécution : cliquez sur Run ; la sortie s’affiche en direct et l’exécution est archivée dans l’historique. 

Le prérequis technique à retenir : le serveur Semaphore doit disposer d’un accès SSH vers les hôtes gérés, et vos playbooks doivent résider dans un dépôt Git.

Un modèle de tâche accepte aussi des options familières d’Ansible, comme la limite d’hôtes ou les tags, ainsi que des variables saisies au lancement. 

Planifier et automatiser les exécutions des playbooks 

Au-delà du lancement manuel, Semaphore automatise les exécutions de trois façons :

• Les planifications utilisent des expressions cron pour déclencher un modèle de tâche à intervalle régulier, idéal pour les mises à jour ou les sauvegardes.
• Les webhooks permettent un déclenchement sur événement externe.
• Enfin, l’API REST autorise le déclenchement depuis un script ou un outil tiers, en s’authentifiant par un jeton : 

curl -X POST \ 

  -H "Authorization: Bearer VOTRE_TOKEN" \ 

  -H "Content-Type: application/json" \ 

  https://semaphore.example.com/api/project/1/tasks \ 

  -d '{"template_id": 1}'

Cette API ouvre la voie à l’intégration de Semaphore dans une chaîne CI/CD ou dans des automatisations plus larges, où il devient le moteur d’exécution des playbooks déclenché par d’autres systèmes. 

Comment sécuriser Semaphore en production ?

Une fois Semaphore en place, quelques réflexes permettent de sécuriser son usage en production et d’éviter les mauvaises surprises :

• Centraliser les secrets dans le Key Store : clés SSH, mots de passe et jetons y restent protégés et ne sont jamais partagés en clair avec les utilisateurs. 

• Appliquer le contrôle d’accès par équipe : donnez à chacun le niveau de droits strictement nécessaire, selon le principe du moindre privilège. 

• Exposer Semaphore derrière un reverse proxy et du TLS : ne jamais publier l’interface en clair ; un proxy Nginx avec certificat (Let’s Encrypt par exemple) protège les échanges. 

• Choisir la base selon l’usage : BoltDB pour un test, PostgreSQL ou MySQL en production pour la robustesse et la concurrence. 

• Sauvegarder la base : projets, identifiants, historiques et utilisateurs y sont stockés ; sans sauvegarde, une panne efface toute la configuration. 

• Isoler l’exécution avec des Runners : les agents distribués permettent de lancer les tâches au plus près des cibles et de cloisonner les environnements. 

Semaphore : les pièges à éviter

Plusieurs erreurs reviennent fréquemment lors de la prise en main de Semaphore. Les connaître en amont évite des désagréments en production :

• Confondre Semaphore UI et Semaphore CI : ce sont deux produits sans lien ; le premier pilote Ansible, le second fait de l’intégration continue. 

• Garder BoltDB en production : la base embarquée convient aux tests, pas à un usage multi-utilisateurs soutenu ; préférez PostgreSQL ou MySQL. 

• Exposer l’interface sans TLS : une interface qui manipule des secrets et des accès ne doit jamais être accessible en clair. 

• Oublier des dépendances Python : certaines fonctions exigent des modules comme passlib dans l’environnement Python ; leur absence provoque des échecs d’exécution. 

• Négliger les sauvegardes : toute la configuration vit dans la base de données ; sa perte équivaut à repartir de zéro. 

• Accorder des droits trop larges : ke confort d’une interface ne doit pas faire oublier la gestion fine des accès et des clés. 

FAQ : Semaphore et Ansible 

Semaphore est-il gratuit et open source ? 

Oui. Semaphore (Semaphore UI, anciennement Ansible Semaphore) est un projet open source, écrit en Go, que l’on auto-héberge librement. Il s’installe par Docker, par binaire ou par paquet système. 

Quelle différence entre Semaphore et AWX ou Ansible Tower ? 

Semaphore est une interface légère, simple à déployer et peu gourmande en ressources. AWX et Ansible Automation Platform sont des plateformes plus complètes et plus lourdes, orientées entreprise, avec un support commercial pour AAP. Semaphore convient aux équipes qui veulent une interface sans la complexité d’AWX. 

Faut-il modifier mes playbooks Ansible existants ? 

Non. Semaphore se greffe sur des playbooks et des rôles existants stockés dans un dépôt Git, sans modification. Il a seulement besoin d’un accès SSH vers les hôtes cibles. 

Semaphore sert-il uniquement à Ansible ? 

Non. Malgré son ancien nom, il exécute aussi du code Terraform, OpenTofu, Bash et PowerShell, via différents types de modèles de tâches. 

Comment automatiser l’exécution des playbooks ? 

De trois façons : des planifications cron pour les tâches récurrentes, des webhooks pour un déclenchement sur événement, et une API REST pour intégrer Semaphore dans une chaîne CI/CD ou un script. 

Quelle base de données utiliser ? 

BoltDB (embarquée) suffit pour un test ou un petit usage. En production, PostgreSQL ou MySQL sont recommandées pour la robustesse et la gestion de la concurrence.