Ansible UI : comparaison d’AWX et de Semaphore UI

Le déploiement recommandé par AWX combine l'opérateur Kubernetes, PostgreSQL et l'exécution de tâches conteneurisées. Sa configuration Docker est destinée au développement et aux tests. Pour une équipe Kubernetes existante, l'opérateur suit un modèle opérationnel familier. L'introduction d'un cluster uniquement pour AWX ajoute une infrastructure à maintenir.

Semaphore UI prend aussi en charge Kubernetes via Helm, ainsi que l’installation par binaire, paquet natif ou Docker avec SQLite, MySQL ou PostgreSQL. Une installation autonome peut utiliser un serveur existant sans cluster, permettant de démarrer avec une infrastructure plus légère et de choisir le modèle d’exploitation.

Le système d'exploitation du serveur est distinct de l'exécution des tâches. Semaphore UI possède un binaire de serveur Windows natif, tandis qu’Ansible a toujours besoin de Linux, macOS, d'un conteneur approprié ou de WSL. Un runner Linux peut exécuter des tâches pour un service Web hébergé ailleurs. Les deux plates-formes peuvent gérer les cibles Windows via Ansible.

Pour une haute disponibilité, les options de mise à l'échelle d’AWX et le déploiement HA de Semaphore UI Enterprise nécessitent un basculement de base de données et une planification de récupération. Les installations déconnectées nécessitent en outre un chemin de livraison pour les packages, les images d'exécution, les mises à jour et toute activation de licence payante.

AWX maintient Ansible au centre de l'exécution. Les playbooks peuvent appeler Terraform/OpenTofu, Terragrunt, Bash, PowerShell ou Python via des modules ou des commandes lorsque l'environnement d'exécution contient les dépendances. Cela convient aux équipes qui décrivent déjà leur processus de provisionnement dans Ansible.

Semaphore UI donne à ces outils leurs propres modèles. Les équipes peuvent lancer directement l'automatisation existante et la combiner dans des workflows sans maintenir de playbooks supplémentaires simplement pour appeler un autre outil. Une tâche OpenTofu peut provisionner l'infrastructure, une tâche Ansible configurer les hôtes et une tâche Python effectuer une opération associée, le tout dans une seule interface.

Semaphore UI Pro propose un backend HTTP intégré pour le state Terraform/OpenTofu, ainsi que des workspaces et des options d’exécution. Les équipes peuvent conserver le state partagé dans Semaphore UI sans exploiter de backend distinct. Avec AWX, le processus Terraform utilise le backend configuré par l’équipe. La source d’inventaire Terraform State d’AWX lit le state pour découvrir les hôtes, mais ne le stocke pas.

L’exécution de Terraform dans Semaphore UI 2.20 présente deux limites importantes. Une exécution normale affiche un plan avant son application, mais n’enregistre pas automatiquement ce plan pour appliquer ensuite exactement le même fichier. Si l’approbation doit porter sur la modification précise proposée, configurez le processus pour enregistrer le plan et le transmettre à apply. Les commandes Terraform par défaut désactivent également le verrouillage du state, sauf modification explicite, même si le backend le prend en charge. Vérifiez ces deux paramètres pour les exécutions en production.

Dans AWX, un Job Template sélectionne un projet, un playbook, un inventaire et des identifiants, ainsi qu’un environnement d’exécution contenant les dépendances nécessaires. Dans Semaphore UI, un Ansible Task Template sélectionne un dépôt, un playbook et un inventaire, avec des Variable Groups réutilisables et les options Ansible dans le même formulaire. Les ingénieurs préparent cette configuration une seule fois. Leurs collègues peuvent ensuite lancer l’opération sans la reconstituer à chaque fois.

Les questionnaires de lancement permettent de fournir les paramètres sans modifier un playbook. AWX prend en charge des validations, notamment des limites de longueur du texte. Les Survey Variables de Semaphore UI proposent des champs typés, du texte multiligne, des secrets et des choix simples ou multiples. Les groupes de variables réutilisables séparent la configuration partagée des valeurs saisies au lancement. AWX permet de partager la configuration via les variables d’inventaire, d’hôte et de groupe ou des fichiers dans Git, sans objet Variable Groups distinct sélectionnable dans plusieurs modèles.

Les deux peuvent exécuter une autre branche du dépôt si la configuration l’autorise. AWX peut demander l’inventaire, les identifiants et d’autres paramètres au lancement. Semaphore UI permet, selon la configuration, de remplacer l’inventaire Ansible et les arguments de ligne de commande. Ces options offrent de la souplesse aux ingénieurs, tout en permettant de limiter les paramètres exposés pour les procédures approuvées.

Les planifications automatisent ces lancements. AWX utilise des paramètres de date de début, d'heure et de récurrence. Semaphore UI prend en charge les expressions cron et les exécutions uniques. Par exemple, 0 2 * * * s'exécute quotidiennement à 02h00 dans le fuseau horaire configuré du planificateur, qui est par défaut UTC. L’une ou l’autre approche peut gérer les sauvegardes, les contrôles d’hôte ou l’arrêt des machines hors production en dehors des heures de travail.

AWX conserve les enregistrements des hôtes et des groupes et les actualise via des tâches de mise à jour d'inventaire, à l'aide de fichiers statiques, de plugins d'inventaire Ansible ou de scripts exécutables. Semaphore UI permet aux équipes de modifier les inventaires INI/YAML ou de les charger à partir de Git, y compris un dépôt distinct. Les plugins et les scripts découvrent les hôtes lors de l'exécution. La principale distinction est de savoir si la plateforme gère un cycle de vie d’inventaire ou réutilise la configuration Ansible de l’équipe.

Par exemple, le plugin netbox.netbox.nb_inventory découvre les appareils et les machines virtuelles, filtre les cibles et crée des groupes à partir des données NetBox. NetBox reste la source de vérité. AWX ajoute des contrôles de mise à jour et des enregistrements stockés, tandis que Semaphore UI transmet la configuration à Ansible. Les deux utilisent le plugin Ansible plutôt qu’un connecteur NetBox natif distinct. D'autres sources incluent AWS, Azure et Google Cloud, et Semaphore UI documente un script Python hébergé par Git pour Consul.

Les inventaires construits d’AWX combinent des inventaires d’entrée enregistrés et gèrent les hôtes obtenus. Semaphore UI peut utiliser le plugin Ansible constructed pour créer des groupes et des variables à partir des sources précédentes. Les plugins de cache Ansible peuvent conserver les facts, mais Semaphore UI ne fournit pas le cache de facts géré d’AWX. Le stockage, l’expiration et le partage du cache entre runners restent à configurer dans Ansible.

Semaphore UI prévoit d’ajouter des rapports Ansible inspirés d’ARA dans la version 2.21.0. Ils compléteront les fonctions d’inventaire par une vue de chaque hôte et de son historique d’automatisation. Les opérateurs pourront ainsi voir quelles tâches ont été exécutées sur chaque serveur, à quel moment et où des échecs se sont produits.

Choisissez le modèle d'inventaire d’AWX lorsque les opérateurs doivent parcourir, actualiser et gérer les enregistrements d'hôtes sur la plateforme. Semaphore UI correspond à une configuration dans laquelle Git définit l'inventaire ou Ansible découvre des hôtes à partir de systèmes tels que NetBox et les API cloud au moment de l'exécution.

Les objets d'identification AWX et le Key Store de Semaphore UI fournissent des identifiants pour les tâches enregistrées sans qu'il soit nécessaire qu'un opérateur les colle à chaque lancement. Les deux s'intègrent à HashiCorp Vault, AWS Secrets Manager et Azure Key Vault, afin que les équipes puissent continuer à utiliser ces services existants.

D'autres intégrations distinguent les produits. AWX propose des types d'identifiants CyberArk Central Credential Provider, CyberArk Conjur et personnalisés. Semaphore UI fournit des intégrations dédiées OpenBao et Devolutions Server. La recherche Vault d’AWX peut fonctionner avec un service compatible, mais la compatibilité d’OpenBao doit être vérifiée pour l'opération requise.

Comparez l'intégration du coffre-fort que votre équipe utilise déjà, y compris sa méthode d'authentification et les types de secrets dont vos tâches ont besoin. Les services sans intégration intégrée peuvent nécessiter un code de récupération personnalisé.

AWX envoie le travail aux nœuds d'exécution, regroupés en groupes d'instances pouvant être attribués à des organisations, des inventaires ou des modèles. Semaphore UI exécute des tâches sur son serveur ou les envoie aux runners. Dans les deux modèles, les machines d'exécution peuvent être placées à proximité des systèmes cibles tandis que l'interface Web reste centralisée.

Un runner Semaphore UI dans un réseau privé peut appliquer des correctifs ou renouveler des certificats sans connexion directe du serveur Web aux hôtes. Les runners de projet réservent de la capacité à un projet, tandis que les tags des modèles ou inventaires dirigent les tâches vers les runners correspondants. Cela convient aux sites distribués et aux environnements clients. Les tags de routage sélectionnent les machines, mais ne garantissent pas l’isolation des réseaux ou des comptes cloud.

L’environnement d’exécution détermine ce qui peut fonctionner sur ces machines. AWX utilise des images d’environnement d’exécution contenant Ansible et ses dépendances, et les groupes de conteneurs peuvent créer un pod Kubernetes par tâche. Semaphore UI propose l’exécution de chaque tâche dans Docker avec Pro et dans Kubernetes avec Enterprise. Ces options sont distinctes de l’hébergement du service Web dans un conteneur. Les deux produits peuvent installer les rôles et collections Ansible déclarés dans le dépôt. Les autres bibliothèques et outils doivent être présents sur la machine d’exécution ou dans son image.

Les contrôles de concurrence limitent le travail simultané. AWX combine les paramètres de tâches simultanées avec la capacité d'exécution et les limites des groupes d'instances. Semaphore UI applique les limites des instances, des projets et des modèles.

AWX peut également diviser automatiquement un grand inventaire en tâches parallèles. Semaphore UI peut diviser le travail en exécutions distinctes avec les limites d'hôtes Ansible, avec des balises d'exécution sélectionnant les machines d'exécution. L’équipe maintient ces sous-ensembles et lancements. Pour les mises à jour progressives, le paramètre serial d’Ansible contrôle les lots séquentiels. Ceux-ci couvrent des exécutions ciblées et des déploiements par étapes, tandis que le découpage des tâches d’AWX répartit automatiquement le travail pour des opérations parallèles sur l’ensemble du parc.

Les workflows AWX relient les modèles de tâches Ansible entre eux. Les autres outils sont appelés via des playbooks. Semaphore UI connecte directement les modèles Ansible, Terraform/OpenTofu, Terragrunt, Bash, PowerShell et Python. Les deux prennent en charge les branches de réussite/échec et les approbations, de sorte qu'un processus de provisionnement peut s'interrompre avant un changement de production.

Les deux utilisent des graphes sans boucle. Aux jonctions, ils permettent d’exiger que les conditions de tous les prédécesseurs ou d’un seul d’entre eux soient satisfaites. AWX accepte plusieurs nœuds de départ. Semaphore UI démarre à partir d’un seul nœud et propose des nœuds de tâche, d’approbation, de délai et d’annotation.

AWX peut réutiliser l’intégralité d’un workflow dans un autre, conservant ainsi une procédure partagée en plusieurs étapes au même endroit. Il empêche l'exécution récursive et propose des étapes de mise à jour du dépôt et de l'inventaire. Semaphore UI réutilise des modèles de tâches individuels dans les workflows, mais ne peut pas intégrer un workflow en tant qu'étape. La différence est importante lorsque plusieurs déploiements partagent une procédure plutôt qu'une seule tâche.

AWX dispose d’un rôle d’approbateur attribuable séparément. Les administrateurs peuvent également approuver. Dans Semaphore UI 2.20, l’approbation dépend du droit d’exécuter les tâches du projet. La distinction est importante si l’équipe doit attribuer l’approbation indépendamment de l’exécution. Un rôle d’approbateur distinct est annoncé pour Semaphore UI 2.21 et n’entre pas dans ce comparatif.

Les deux permettent les approbations dans l’interface et via une API authentifiée. AWX fournit aussi un module Ansible. Une approbation interactive dans Slack nécessite une intégration appelant l’API, une simple notification ne suffit pas.

Les deux transmettent des valeurs aux tâches suivantes, comme l’adresse d’un hôte nouvellement provisionné. AWX expose les valeurs définies par set_stats dans le playbook sous forme de variables supplémentaires pour les tâches en aval, y compris sur les nœuds d’exécution. Un playbook peut ainsi récupérer le résultat d’un autre outil. Semaphore UI collecte les valeurs Ansible set_stats, les outputs de Terraform/OpenTofu/Terragrunt et le JSON produit par Bash, PowerShell ou Python. Il associe ensuite ces valeurs aux variables du questionnaire de destination, par correspondance de nom ou par association explicite.

Dans Semaphore UI 2.20, les sorties de workflow sont collectées sur le serveur et les runners distants utilisant l’exécuteur local. Les exécuteurs Docker et Kubernetes ne produisent pas encore de sorties de workflow. Les valeurs sont collectées après les tâches réussies. Les branches déclenchées en cas d’échec ne peuvent donc pas dépendre des sorties d’une tâche ayant échoué. Ces valeurs sont visibles par les utilisateurs autorisés à consulter la tâche et ne doivent pas contenir de secrets.

La transmission de valeurs ne transfère de fichiers dans aucun des deux produits. Si des étapes distinctes échangent un plan Terraform enregistré ou un autre artefact, prévoyez un stockage accessible aux deux. Réutiliser un runner ne garantit pas la conservation du répertoire de travail entre les tâches.

AWX accorde des autorisations indépendamment sur les inventaires, les identifiants et les modèles de tâches. Semaphore UI organise l'accès autour des projets, avec des rôles personnalisés Enterprise et des autorisations d'exécution au niveau du modèle pour une délégation plus fine. Un modèle préconfiguré peut exposer une opération approuvée à l'aide de l'inventaire, des identifiants et des paramètres d'exécution choisis.

Par exemple, Semaphore UI Enterprise peut donner au support accès à un modèle de redémarrage de service sur des serveurs de production déterminés. Un rôle de base Guest, associé à un rôle personnalisé sans autorisations à l’échelle du projet, peut accorder l’exécution de ce modèle. Limitez les possibilités de remplacer l’inventaire, les limites d’hôtes, les variables et les autres paramètres au lancement. Vérifiez aussi que d’autres rôles n’élargissent pas l’accès. Le modèle, les autorisations et l’automatisation définissent ensemble l’opération permise. Le questionnaire ne fait que recueillir les paramètres.

Cela permet de déléguer des opérations précises sans créer d’autorisations indépendantes sur les inventaires ou les identifiants au sein d’un projet. AWX convient davantage lorsque les opérateurs doivent combiner des ressources soumises à des règles d’accès distinctes. Les autorisations par modèle de Semaphore UI conviennent à un ensemble défini de procédures approuvées.

Les deux prennent en charge LDAP et OIDC pour la connexion. AWX prend également en charge SAML et s'appuie sur un fournisseur d'identité externe pour MFA. Semaphore UI offre une authentification locale à deux facteurs TOTP. Un fournisseur d'identité avec OIDC peut couvrir la connexion centralisée à Semaphore UI, tandis qu'une exigence uniquement SAML nécessite une autre approche d'intégration.

Les deux produits conservent l'historique des tâches et les résultats à des fins de dépannage. La visibilité de l'audit diffère : le flux d'activité d’AWX suit les autorisations de ressources et les rôles d'administrateur ou d'auditeur. La vue d'audit inter-projets de Semaphore UI est disponible pour les administrateurs, avec des événements stockés dans sa base de données lorsque l'enregistrement d'audit est activé.

Pour les investigations centralisées, la journalisation externe d’AWX transmet les événements d’activité, les journaux de tâches et les journaux serveur, notamment vers Splunk. Semaphore UI Pro ajoute des filtres d’audit, l’export en CSV ou JSONL et le transfert via TLS Syslog ou Splunk HEC. Les deux peuvent alimenter une plateforme de journalisation ou un système de gestion des informations et des événements de sécurité (SIEM).

La rétention locale utilise différents contrôles. AWX fournit un nettoyage planifié basé sur l'âge pour l'historique d'exécution et le flux d'activité. Semaphore UI conserve un nombre configuré de tâches récentes par modèle. Un système de journalisation central peut conserver les enregistrements au-delà de ces limites locales.

AWX fournit des webhooks de tâches intégrés pour GitHub et GitLab afin de déclencher l’automatisation depuis les dépôts. Semaphore UI propose des points de terminaison webhook génériques qui filtrent les requêtes selon des règles et en extraient les paramètres des tâches. Ils peuvent recevoir des événements de différents systèmes, tandis que les API REST des deux produits permettent l’accès à d’autres clients.

Pour les notifications sortantes, AWX propose l’e-mail, Slack, Rocket.Chat, Mattermost, PagerDuty, AWS SNS, Grafana, IRC, Twilio et les webhooks. Semaphore UI prend en charge l’e-mail (SMTP), Telegram, Slack, Microsoft Teams, Rocket.Chat, DingTalk et Gotify. Ces canaux transmettent les événements des tâches à des personnes ou à des services, tandis que les webhooks entrants de tâches déclenchent l’automatisation.

Un portail de services ou un système ITSM peut utiliser l’API REST de l’un ou l’autre produit pour lancer une tâche préparée et récupérer son résultat. Par exemple, un portail interne peut soumettre une demande de renouvellement de certificat à un modèle enregistré, puis informer le demandeur de son achèvement. Il s’agit d’une intégration par API configurée par l’équipe, et non d’un connecteur natif dédié.