Wie es funktioniert

Die Teile einer Installation, was bei einem Start passiert und wo Daten aufbewahrt werden

  1. Architektur
    1. Gebaut mit
  2. Was passiert, wenn Sie ein Formular starten
  3. Wo was gespeichert wird

Architektur

AnsibleForms ist ein Node.js-Server, der die Webanwendung und eine REST-API bereitstellt, gestützt auf eine MySQL-Datenbank. Er liest Formulare aus YAML-Dateien und führt selbst nichts aus: er übergibt jeden Job an einen Runner. Ein Playbook geht an einen Ihrer RTE-Container (Laufzeitumgebung), der ansible-playbook ausführt, und eine Vorlage oder ein Job geht an AWX, AAP, Ascender, Semaphore, Rundeck oder Jenkins:

Architektur von AnsibleForms Der Browser und ein optionaler MCP-Client sprechen mit dem AnsibleForms-Server. Der Server speichert seine Daten in MySQL und im persistenten Ordner und verbindet sich mit Datenquellen, Secret Stores, Git-Repositories, Anmeldeanbietern, Benachrichtigungskanälen, Syslog-Servern und einem optionalen Modellanbieter. Seine Runner übergeben jedes Playbook an einen von einem oder mehreren RTE-Containern, jeweils über einen WebSocket, die ansible-playbook ausführen und die Ausgabe an den Server zurücksenden, und jede Vorlage oder jeden Job an AWX, AAP, Ascender, Semaphore, Rundeck oder Jenkins. Browser Formulare, Designer, Jobs, Chat MCP-Client optional AnsibleForms-Server Node.js / Express Web-App und REST-API Formulare, Ausdrücke Workflows, Zeitpläne MCP-Server (optional) Runner geben Jobs an ihren Runner Datenquellen Datenbanken, APIs, Dateien Secret Stores HashiCorp Vault, CyberArk Git-Repositories Formulare, Playbooks, Config Anmeldeanbieter LDAP, Entra ID, OIDC Benachrichtigungen Mail, Slack, Teams, Webhooks Syslog-Server Protokoll, Audit-Trail Modellanbieter optional, Chat-Assistent Persistenter Ordner Config, Formulare, Playbooks MySQL / MariaDB Jobs, Benutzer, Anmeldedaten RTE-Container starten ansible-playbook AWX / AAP / Ascender Semaphore, Rundeck, Jenkins Playbooks, WebSocket Vorlagen, Jobs

Die Komponenten im Diagramm haben jeweils eine eigene Rolle:

Komponente Rolle
Browser Die Vue-Webanwendung: die Formulare, der Designer, die Job-Historie und die Einstellungen
AnsibleForms-Server Wertet die Formulare aus, zeichnet die Jobs auf, führt die Workflows und die Zeitpläne aus, übergibt jeden Job an seinen Runner und verfolgt ihn, und stellt die REST-API bereit
Runner Wo Jobs laufen, hinzugefügt unter Verbindungen > Runner: ein Formular nennt einen mit runner: <name> oder verwendet den Standard-Runner seines Typs (siehe Runner)
RTE-Container Ein oder mehrere Container mit Laufzeitumgebung, derselbe Server mit AF_ROLE=rte gestartet: jeder führt ansible-playbook für Ansible-Formulare aus, mit den Python-Bibliotheken und Collections seines Images, und sendet die Ausgabe und den Endstatus über einen WebSocket an den Server zurück, ohne Datenbank-Anmeldedaten (siehe Wie die RTE läuft)
AWX / AAP / Ascender, Semaphore, Rundeck, Jenkins Runner für Vorlagen und Jobs: AWX-Formulare starten eine Job- oder Workflow-Vorlage, Formulare für Semaphore, Rundeck und Jenkins starten einen ihrer Jobs, und der Server verfolgt seine Ausgabe
MySQL / MariaDB Enthält die Jobs und ihre Ausgabe, die Benutzer, die Anmeldedaten und die Verbindungen; nur der Server liest und schreibt sie
Persistenter Ordner Enthält config.yaml, die Formulardateien, die Playbooks, die Protokolle und die Backups
Datenquellen Füllen die Felder: Datenbankabfragen, REST-APIs, Dateien und andere Funktionen
Secret Stores Liefern Benutzer und Passwort von Anmeldedaten zum Zeitpunkt der Verwendung, siehe Secret Stores
Git-Repositories Halten die Formulare, die Playbooks und config.yaml unter Versionskontrolle
Anmeldeanbieter Melden die Benutzer an: LDAP, Entra ID und OIDC, neben den lokalen Benutzern
Benachrichtigungskanäle Transportieren die Benachrichtigungen und die Genehmigungsanfragen: Mail, Slack, Microsoft Teams, Telegram oder ein Webhook
Syslog-Server Empfangen das Protokoll und den Audit-Trail, während sie geschrieben werden, siehe Syslog
MCP-Client, Chat Optional, beide standardmäßig aus: der MCP-Server und der Chat-Assistent, der einen Modellanbieter braucht

Standardmäßig betreibt ein Container den Server, die Web-App und die Hintergrundarbeit gemeinsam, neben einer RTE. Für mehrere App-Knoten hinter einem Load Balancer, einen Worker für die Hintergrundarbeit und mehr RTEs siehe Skalierung.

Gebaut mit

Server und Weboberfläche bauen auf diesen Komponenten auf:

Teil Technologie
Server Node.js und Express
Datenbank MySQL oder MariaDB
Weboberfläche Vue 3, mit Bootstrap 5 und Font Awesome

Was passiert, wenn Sie ein Formular starten

Ein Start durchläuft dieselben Schritte, ob er aus dem Browser oder über die REST-API kommt:

  1. Laden : der Server sendet nur die Formulare, die die Rollen des Benutzers erlauben, und wertet Server-Ausdrücke aus
  2. Übermitteln : der Browser macht aus den Feldwerten Extravars und sendet sie an POST /api/v2/job
  3. Prüfen : der Server lädt das Formular für die Rollen des Benutzers neu und prüft, bei eingeschalteter Startvalidierung, die Werte
  4. Aufzeichnen : der Job wird mit dem Status running gespeichert, und seine ID wird den Extravars als __jobid__ hinzugefügt
  5. Genehmigen : ein Formular mit einem approval-Punkt wartet, bis ein Genehmiger den Job annimmt
  6. Anmeldedaten : für ein Playbook liest die App (nie die RTE) die Anmeldedaten des Formulars aus der Datenbank oder einem Secret Store
  7. Ausführen : der Job geht an seinen Runner, den, den das Formular mit runner: nennt, oder den Standard seines Typs. Für ein Playbook sendet die App den Job über den WebSocket der RTE an ihre RTE, mit den für sie versiegelten Anmeldedaten, und die RTE führt ansible-playbook aus (siehe Wie die RTE läuft), und AWX, AAP, Ascender, Semaphore, Rundeck oder Jenkins führt eine Vorlage oder einen Job aus. Ein Workflow führt seine Knoten aus, jeden als eigenen Job auf seinem eigenen Runner
  8. Verfolgen : der Server speichert die Ausgabe in der Datenbank, sobald sie ankommt, bei einem Playbook von der RTE über ihren Socket gesendet, oder von den anderen Runnern gelesen. Die Formularseite liest den Job alle zwei Sekunden neu, und die Seite Jobs verfolgt ihn live, während der Server jede Änderung ankündigt
  9. Beenden : der Job erhält seinen Endstatus, und seine notifications gehen per Mail und an seine Benachrichtigungskanäle hinaus, wenn das Formular sie anfordert

Wo was gespeichert wird

AnsibleForms hält seinen Zustand an zwei Orten: in der MySQL-Datenbank und im persistenten Ordner. Sichern Sie beide.

In der Datenbank

Die Datenbank, AnsibleForms, wird beim ersten Start angelegt (sofern ALLOW_SCHEMA_CREATION nicht 0 ist) und enthält:

  • die Jobs, ihre Extravars und ihre Ausgabe, die Zeitpläne und die gespeicherten Jobs
  • die lokalen Benutzer, die Gruppen und die API-Tokens
  • die Anmeldedaten, verschlüsselt mit ENCRYPTION_SECRET, und die Verbindungen zu Secret Stores
  • die Runner, die Benachrichtigungskanäle (Mail eingeschlossen), die Syslog-Server sowie die Einstellungen für LDAP, SSO, Repositories und den Chat-Assistenten
  • das Audit-Protokoll

Im persistenten Ordner

Er ist /app/dist/persistent im Image und server/persistent aus dem Quellcode; jeder Pfad hat seine eigene Variable:

Standardpfad Variable Inhalt
config.yaml CONFIG_PATH Die Kategorien, die Rollen und die Konstanten
forms/ FORMS_FOLDER_PATH Die Formulardateien, .yaml oder .yml, nach Belieben in Unterordnern
playbooks/ ANSIBLE_PATH Die Playbooks der ansible-Formulare und ihr Arbeitsverzeichnis
repositories/ REPO_PATH Die Klone der Git-Repositories
forms_backups/ FORMS_BACKUP_PATH Die Kopien, die der Designer vor dem Speichern anlegt
backups/ BACKUP_PATH Die Datenbank-Backups
uploads/ UPLOAD_PATH Die über file-Felder hochgeladenen Dateien
logs/ LOG_PATH ansibleforms.log und ansibleforms.errors.log
certificates/ HTTPS_CERT, HTTPS_KEY Das Zertifikat und der Schlüssel, wenn HTTPS 1 ist
.env   Die von den Einstellungsseiten gespeicherten Umgebungsvariablen (sofern ALLOW_ENV_EDIT nicht 0 ist)

Der erzeugte SSH-Schlüssel liegt in HOME_PATH, standardmäßig außerhalb des persistenten Ordners.