Ansible-grænseflade: Semaphore UI og Ansible Automation Platform (AAP)

AAP 2.6 understøtter containerbaseret Podman-installation på RHEL og Operator-baseret installation på OpenShift. Den ældre RPM-installer understøttes stadig på RHEL 9 i 2.6 til migrering, men er udfaset. Red Hat dokumenterer understøttede topologier og en produktlivscyklus for disse installationer. Kubernetes er ikke et krav for alle AAP-installationer.

Semaphore UI kan køre som binærfil eller systempakke på en eksisterende vært samt gennem Docker eller Kubernetes. Et team, der indfører en fælles Ansible-grænseflade, kan vælge en traditionel serverinstallation og genbruge de repositories og den infrastruktur, det allerede driver. Enterprise tilføjer høj tilgængelighed, når automatiseringstjenesten har brug for redundante applikationsinstanser. Semaphore UI-serveren kører også direkte på Windows, mens Ansible-eksekvering kræver WSL, en container eller en Linux-runner.

Semaphore UI kan dele patch- og udrulningsjobs fra en eksisterende server. AAP’s installationstopologi afhænger af de valgte komponenter og den eksekveringskapacitet, teamet skal vedligeholde.

AAP bruger Ansible-playbooks og execution environments, containerimages med Ansible-runtime og nødvendige afhængigheder. Terraform-integrationerne omfatter collections til koordinering af Terraform-tjenester, og playbooks kan kalde andre kommandolinjeværktøjer. Det er en sammenhængende model, når Ansible allerede orkestrerer hele proceduren.

Semaphore UI er også bygget omkring praktiske Ansible-operationer, men giver Terraform/OpenTofu, Terragrunt, Bash, PowerShell og Python deres egne Task Templates. Til Terraform/OpenTofu vælger en ingeniør repository, konfigurationsmappe, workspace og variabelgruppe i grænsefladen. IaC-værktøjet kører direkte uden en Ansible-playbook skrevet alene for at kalde det. En Ansible-udrulning, et Terraform-provisioneringsjob og en Python-kontrol kan derfor dele et projekt og samtidig beholde egne kørselsindstillinger.

Et midlertidigt testmiljø kan eksempelvis kræve oprettelse af infrastruktur efterfulgt af applikationskonfiguration og et parathedstjek. Semaphore UI holder trinnene i deres eksisterende værktøjer og forbinder dem gennem et workflow. Det er nyttigt for teams, hvis automatisering er vokset på tværs af flere repositories og sprog, men som stadig ønsker ét sted at starte og gennemgå operationen.

Konfigurér separate state/backend-adresser eller understøttede workspaces til udvikling, staging og produktion. Workspaceunderstøttelse afhænger af den valgte backend. Semaphore UI Pro kan selv hoste state gennem sin indbyggede HTTP-backend med versionshistorik og administration i grænsefladen. For et team, der opretter midlertidige miljøer, bliver provisioneringsskabelonen, dens state og den senere Ansible-konfiguration i én tjeneste. AAP’s dokumenterede Terraform-integrationer bruger Terraform-tjenester eller en konfigureret ekstern backend til state. Semaphore UI kan også beholde en ekstern backend, når teamet allerede har en.

Til en proces, der skal godkende og anvende præcis den gemte Terraform-plan, skal der konfigureres eksplicit lagring og genbrug af planen. Semaphore UI's standardeksekvering udfører plan og apply hver for sig, og dens standardkommandoer bruger -lock=false, medmindre dette tilsidesættes. At stille en state-backend til rådighed ændrer ikke de indstillinger for opgavekommandoerne.

En AAP Job Template gemmer projekt, playbook, inventar, legitimationsoplysninger og execution environment til en operation. Når den startes, oprettes et job. En survey indsamler de input, der er aktiveret for kørslen, så en operatør kan udføre en forberedt procedure uden at genskabe konfigurationen.

Semaphore UI bruger Task Templates til samme genanvendelige startmønster på tværs af Ansible og de øvrige automatiseringsværktøjer. En Ansible-skabelon vælger repository, playbook, inventar og legitimationsoplysninger. Navngivne variabelgrupper holder konfiguration, der genbruges på tværs af skabeloner, mens surveyfelter indsamler værdier til den enkelte kørsel. AAP kan genbruge variabler gennem inventarer og filer i Git.

Tænk på en procedure til servicegenstart, der deles med supportkolleger. En ingeniør forbereder playbook og miljøkonfiguration og beder derefter om tjenestens navn og en ændringsreference i startformularen. Kollegaen vælger operationen, angiver inputtene og kan følge status og output. Separate skabeloner kan stille en udrulning, backup eller certifikatfornyelse til rådighed med de samme projektressourcer.

Begge produkter planlægger også gemte skabeloner. AAP tilbyder engangs- og tilbagevendende tidsplaner, mens Semaphore UI understøtter cron-udtryk og engangskørsler med konfigurerede input. En backup, der bruges før et manuelt vedligeholdelsesvindue, kan også køre automatisk om natten. Teamet kan dermed genbruge en driftsprocedure frem for at vedligeholde en separat cron-kommando og konfiguration til webstart.

AAP synkroniserer inventarkilder til administrerede værter og grupper med gemte facts og konstruerede inventarer til mere omfattende Ansible-operationer. En operatør kan undersøge og administrere individuelle værtsoplysninger i samme platform, som bruges til at starte jobs. Det er nyttigt, når vedligeholdelse af oplysningerne og kombination af inventarkilder er en del af den daglige drift. AAP kan opdatere inventarkilder efter en tidsplan eller før start og valgfrit gemme værtsfacts i en administreret cache.

Semaphore UI genbruger statiske inventardefinitioner eller definitioner fra Git samt Ansible-discovery-plugins, herunder dem til NetBox og cloud-API’er. Operatører kan redigere INI/YAML-definitioner i grænsefladen eller beholde Git og ekstern discovery som kilde til værtsoplysninger. En skabelon vælger det nødvendige inventar, når operationen kører. Dynamisk discovery sker under eksekveringen. Ansibles konfigurerede fact-caching er fortsat tilgængelig, mens Semaphore UI ikke tilbyder en controlleradministreret fact-cache.

For et team, der allerede vedligeholder infrastrukturen uden for automatiseringsgrænsefladen, undgår dette at indføre endnu en proces til værtsadministration blot for at dele jobs. Samme inventar kan bruges til patching, certifikatkontroller og udrulning med separate skabeloner og input til hver operation. AAP’s synkroniserede værts- og gruppevisning er fortsat værdifuld, når operatørerne har brug for den administrerede visning frem for kun et inventar at køre imod.

Begge produkter gemmer referencer til legitimationsoplysninger sammen med den forberedte operation. En ingeniør kan konfigurere repositoryadgang, maskinlegitimationsoplysninger og andre hemmeligheder én gang og genbruge dem på tværs af udrulninger og vedligeholdelsesjobs. Kolleger, der starter operationen, behøver ikke angive oplysningerne igen ved hver kørsel.

AAP understøtter legitimationsobjekter og opslag af eksterne hemmeligheder, herunder integrationer med HashiCorp Vault, AWS Secrets Manager, Azure og CyberArk. Semaphore UI har en projektbaseret Key Store og forbinder HashiCorp Vault eller OpenBao i Pro. Enterprise tilføjer AWS Secrets Manager, Azure Key Vault, Devolutions Server og CyberArk gennem PVWA-API’et. AAP kan bruge Devolutions’ Ansible-collection i playbooks, når collectionen er installeret i execution environment. De indbyggede legitimationsforbindelser inkluderer ikke et dedikeret OpenBao-opslag. AAP tilbyder også forbindelser til Centrify Vault og Thycotic Secret Server eller DevOps Secrets Vault, som Semaphore UI ikke tilbyder som indbyggede lagre. En Ansible-lookup-collection eller en kommando kan hente hemmeligheder til en operation, når en platformforbindelse mangler, og integrationen vedligeholdes da i automatiseringen. Teams kan derfor vælge ud fra deres eksisterende vault og de forbindelser, de vil konfigurere i selve platformen.

AAP kører jobs i execution environments med Ansible og playbookens afhængigheder. Eksekveringsnoder udfører arbejdet adskilt fra kontroltjenesterne. Automation mesh forbinder noderne og kan bruge mellemliggende hopnoder til at nå eksterne netværk. Det understøtter en distribueret Ansible-infrastruktur med definerede eksekveringsimages og netværksveje.

Semaphore UI kan køre automatisering på sin server eller på runners tæt på målsystemerne. En runner i et privat netværk kan eksempelvis køre et Ansible-vedligeholdelsesjob mod lokale værter, mens den fælles grænseflade ligger et andet sted. Globale runners er tilgængelige i Community, mens Pro tilføjer projekttildelte runners og tagbaseret routing til forskellige eksekveringsmiljøer.

Et team kan begynde med direkte eksekvering og tilføje separate maskiner eller containere pr. opgave, når arbejdsbelastningen kræver det. Pro giver opgavekørsel i Docker, og Enterprise tilføjer opgavekørsel i Kubernetes. Det giver en tjeneste, der kører eksisterende playbooks, en vej fra én vært til adskilt eksekvering uden en automation mesh-installation. At containerisere applikationsserveren er et separat valg fra at containerisere hver opgave.

AAP Workflow Job Templates forbinder Job Templates, projektopdateringer, inventaropdateringer og andre workflows. Godkendelsestrin sætter en kørsel på pause, og Ansible set_stats-værdier kan overføres til senere jobs. Indlejring af et workflow er værdifuld, når flere procedurer deler en komplet sekvens, der bør vedligeholdes ét sted.

Semaphore UI-workflows forbinder Task Templates til Ansible, Terraform/OpenTofu, Terragrunt, Bash, PowerShell og Python direkte med grene for succes og fejl, godkendelser og forsinkelser. Et provisioneringsworkflow kan oprette infrastruktur med Terraform/OpenTofu, konfigurere den med Ansible og køre et parathedstjek i Python. Et vedligeholdelsesworkflow kan begynde med en backup, anvende opdateringer og køre kontrol med genbrug af skabeloner, som kolleger også kan starte hver for sig. AAP kan orkestrere samme procedure gennem Ansible Job Templates og Terraform-integrationer. Forskellen er, om hvert værktøjs kørselskonfiguration ligger i sin egen skabelon eller i playbooks og integrationer bag Ansible-jobs.

Semaphore UI 2.20 overfører Ansible set_stats-værdier, Terraform/OpenTofu/Terragrunt-output og JSON fra Bash, PowerShell eller Python til senere opgaveinput. En adresse eller ressourceidentifikator fra provisioneringen kan dermed blive input til næste operation. AAP overfører set_stats-værdier mellem Ansible-jobs. Begge giver nyttig værdioverførsel, og forskellen ligger i, hvordan resultatet produceres og bruges. Modtagerskabelonen erklærer inputtet, som dens playbook eller inventarkonfiguration derefter bruger til at ramme den nye vært.

AAP har en tildelbar Approve-rettighed til workflowgodkendelser. Semaphore UI 2.20 knytter godkendelse til retten til at køre projektopgaver. En separat godkenderrolle er annonceret til 2.21.0. Det er vigtigt, når godkendelsesansvaret kræver sin egen rettighed.

Et workflow til provisionering og konfiguration kan overføre indsamlede værdier mellem Semaphore UI-opgaver med den lokale executor, enten på serveren eller en ekstern runner. Docker- og Kubernetes-executors indsamler ikke disse output, så et workflow, der afhænger af dem, kræver en anden eksekveringsopsætning. Individuelle opgaveskabeloner kan fortsat genbruges på tværs af workflows. Hvis flere procedurer skal genbruge et helt workflow med flere trin, undgår AAP’s indlejrede workflows separat vedligeholdelse af sekvenserne. På begge platforme kræver filer som gemte Terraform-planer tilgængelig lagring eller en eksplicit overførsel mellem jobs.

AAP giver adgang til individuelle ressourcer og understøtter brugerdefinerede roller. Operatører kan få ret til at bruge bestemte inventarer og legitimationsoplysninger uafhængigt af jobskabeloner. Det passer til teams, hvis daglige arbejde omfatter at kombinere godkendte Ansible-ressourcer til nye operationer.

Semaphore UI organiserer adgang omkring projekter og forberedte operationer. Community-projektroller understøtter allerede en opdeling mellem ingeniører, der vedligeholder automatiseringen, og kolleger, der kører den. Et projekt kan samle teamets skabeloner til udrulning, backup og vedligeholdelse med de konfigurerede ressourcer.

Enterprise tilføjer brugerdefinerede roller og eksekveringsrettigheder på skabelonniveau, når adgang skal begrænses til udvalgte operationer. Supportmedarbejdere kan eksempelvis få en skabelon til servicegenstart, mens udrulning forbliver hos en anden rolle. Inventar, legitimationsoplysninger og aktiverede tilsidesættelser ved start er en del af den forberedte konfiguration. Det er en fokuseret model til delegering af operationer, mens AAP tilbyder uafhængige rettigheder på de underliggende ressourcer.

Begge understøtter LDAP-integration. Semaphore UI Pro tilbyder også OIDC-login, mens AAP understøtter OIDC, SAML og andre centralt konfigurerede identitetsudbydere. Semaphore UI tilbyder ikke en indbygget SAML-integration. Semaphore UI Pro tilføjer også TOTP-tofaktorgodkendelse til lokale konti.

Driftsresultater kommer først, når en kollega skal vide, om et udrulnings- eller vedligeholdelsesjob er færdigt. Begge produkter gemmer eksekveringsoutput og historik. Semaphore UI registrerer opgavestatus, repositoryrevision og startoplysninger, og Pro tilføjer en Ansible-værtsoversigt med fejlede opgaver pr. server. Efter et patch- eller certifikatjob kan operatøren identificere berørte værter og undersøge det tilsvarende output.

Administrativ audit har et andet formål. AAP’s aktivitetsstrøm registrerer ændringer af platformressourcer, og logintegrationer videresender job- og systemhændelser. Semaphore UI tilbyder en administrativ auditlog for login, rettighedsændringer og andre registrerede handlinger. Pro tilføjer filtre, fileksport og videresendelse via TLS Syslog eller Splunk HEC, så hændelserne kan indgå i organisationens sikkerhedsundersøgelser og SIEM-registreringer.

AAP’s automation hub distribuerer collections og eksekveringsimages med adgang til Red Hat Certified og valideret indhold. Event-Driven Ansible vurderer hændelser gennem rulebooks og udløser automatisering. Det er platformstjenester til at administrere og igangsætte automatisering på tværs af en organisation, ud over et indgående webhook til et gemt job.

Semaphore UI passer sammen med eksisterende CI-, overvågnings- og bestillingssystemer gennem sit REST-API og webhookintegrationer med matching og udtræk af input. En buildpipeline kan udgive en version og anmode om en forberedt udrulning, mens en hændelsesprocessor kan anmode om en diagnostisk operation. Semaphore UI holder operationens inventar, legitimationsoplysninger og eksekveringsregistrering. Kalderen håndterer godkendelse og kontrollerer opgaveresultatet, når den omgivende proces skal vente på afslutningen.

Både Semaphore UI og automation controller giver startformularer til forberedte jobs. AAP tilbyder også en separat installeret Ansible automation portal bygget på Red Hat Developer Hub med selvbetjeningskatalog, skabelonsynkronisering og tilpassede integrationer. Brugen af Developer Hub til denne portal er inkluderet i AAP-abonnementet. Til teams, der har brug for fælles jobeksekvering uden kataloget, tilbyder Semaphore UI en fokuseret grænseflade til Ansible og andre automatiseringsværktøjer.

AAP tilbyder en officiel MCP-server, der gør platformoperationer tilgængelige for kompatible assistenter. Den kan installeres sammen med platformen eller som selvstændig container. AAP tilbyder også en valgfri intelligent automatiseringsassistent i grænsefladen, forbundet med en konfigureret modeludbyder. Det udvider den integrerede platformstilgang til AI-assisteret drift.

Semaphore UI har en MCP-forbindelse fra fællesskabet til sit API og har annonceret officiel MCP-understøttelse til Pro i version 2.21.0. Claude Code eller Codex kan også bruge offentlig dokumentation, kildekode og API-definitioner til at hjælpe med at forberede skabeloner, skrive integrationskode eller undersøge en fejlet kørsel ud fra den leverede konfiguration og output. Et team kan bruge denne hjælp sammen med sin eksisterende automatiseringstjeneste uden at indføre en bredere platform.