Jak to działa

Elementy instalacji, co dzieje się przy uruchomieniu i gdzie przechowywane są dane

  1. Architektura
    1. Z czego jest zbudowany
  2. Co się dzieje, gdy uruchamiasz formularz
  3. Gdzie wszystko jest przechowywane

Architektura

AnsibleForms to serwer Node.js, który udostępnia aplikację webową i API REST, z bazą danych MySQL. Odczytuje formularze z plików YAML i sam niczego nie uruchamia: każde zadanie przekazuje do runnera. Playbook trafia do jednego z Twoich kontenerów RTE (runtime environment), który uruchamia ansible-playbook, a szablon lub job trafia do AWX, AAP, Ascender, Semaphore, Rundeck lub Jenkins:

Architektura AnsibleForms Przeglądarka i opcjonalny klient MCP komunikują się z serwerem AnsibleForms. Serwer przechowuje dane w MySQL i w folderze trwałym oraz łączy się ze źródłami danych, magazynami sekretów, repozytoriami git, dostawcami logowania, kanałami powiadomień, serwerami syslog i opcjonalnym dostawcą modelu. Jego runnery przekazują każdy playbook do jednego z jednego lub kilku kontenerów RTE, każdy przez własny WebSocket; kontenery uruchamiają ansible-playbook i odsyłają wynik do serwera, a każdy szablon lub job trafia do AWX, AAP, Ascender, Semaphore, Rundeck lub Jenkins. Przeglądarka formularze, projektant, zadania, czat Klient MCP opcjonalny Serwer AnsibleForms Node.js / Express Aplikacja webowa i API REST Formularze, wyrażenia Workflow, harmonogramy Serwer MCP (opcjonalny) Runnery przekazują zadania runnerowi Źródła danych bazy danych, API, pliki Magazyny sekretów HashiCorp Vault, CyberArk Repozytoria git formularze, playbooki, config Dostawcy logowania LDAP, Entra ID, OIDC Powiadomienia poczta, Slack, Teams, webhooki Serwery syslog dziennik, ślad audytu Dostawca modelu opcjonalny, asystent czatu Folder trwały config, formularze, playbooki MySQL / MariaDB zadania, użytkownicy, poświadczenia Kontenery RTE uruchamiają ansible-playbook AWX / AAP / Ascender Semaphore, Rundeck, Jenkins playbooki, WebSocket szablony, joby

Każdy z elementów na diagramie ma własną rolę:

Element Rola
Przeglądarka Aplikacja webowa w Vue: formularze, Projektant, historia zadań i ustawienia
Serwer AnsibleForms Przetwarza formularze, zapisuje zadania, uruchamia workflow i harmonogramy, przekazuje każde zadanie jego runnerowi i śledzi je, a także udostępnia API REST
Runnery Miejsca, w których działają zadania, dodawane w Połączenia > Runnery: formularz wskazuje jeden przez runner: <name> albo używa domyślnego runnera swojego typu (zobacz Runnery)
Kontenery RTE Jeden lub kilka kontenerów środowiska uruchomieniowego, czyli ten sam serwer uruchomiony z AF_ROLE=rte: każdy uruchamia ansible-playbook dla formularzy ansible, z bibliotekami pythona i kolekcjami ze swojego obrazu, i odsyła wynik oraz stan końcowy do serwera przez jeden WebSocket, bez poświadczeń do bazy danych (zobacz Jak działa RTE)
AWX / AAP / Ascender, Semaphore, Rundeck, Jenkins Runnery dla szablonów i jobów: formularze AWX uruchamiają szablon joba lub workflow, formularze Semaphore, Rundeck i Jenkins uruchamiają jeden z ich jobów, a serwer śledzi jego wynik
MySQL / MariaDB Przechowuje zadania i ich wyniki, użytkowników, poświadczenia i połączenia; odczytuje ją i zapisuje tylko serwer
Folder trwały Przechowuje config.yaml, pliki formularzy, playbooki, dzienniki i kopie zapasowe
Źródła danych Wypełniają pola: zapytania do bazy danych, API REST, pliki i inne funkcje
Magazyny sekretów Dostarczają użytkownika i hasło poświadczenia w chwili użycia, zobacz Magazyny sekretów
Repozytoria git Utrzymują formularze, playbooki i config.yaml pod kontrolą wersji
Dostawcy logowania Logują użytkowników: LDAP, Entra ID i OIDC, obok użytkowników lokalnych
Kanały powiadomień Przenoszą powiadomienia i prośby o zatwierdzenie: poczta, Slack, Microsoft Teams, Telegram lub webhook
Serwery syslog Odbierają dziennik i ślad audytu na bieżąco, w miarę zapisywania, zobacz Syslog
Klient MCP, czat Opcjonalne, oba domyślnie wyłączone: serwer MCP i asystent czatu, który wymaga dostawcy modelu

Domyślnie jeden kontener uruchamia razem serwer, aplikację webową i pracę w tle, obok jednego RTE. Jeśli chcesz mieć kilka węzłów aplikacji za load balancerem, workera wykonującego pracę w tle i więcej RTE, zobacz Skalowanie.

Z czego jest zbudowany

Serwer i interfejs webowy są zbudowane z tych komponentów:

Część Technologia
Serwer Node.js i Express
Baza danych MySQL lub MariaDB
Interfejs webowy Vue 3, z Bootstrap 5 i Font Awesome

Co się dzieje, gdy uruchamiasz formularz

Uruchomienie przechodzi przez te same kroki, niezależnie od tego, czy pochodzi z przeglądarki, czy z API REST:

  1. Wczytanie : serwer wysyła tylko formularze, na które pozwalają role użytkownika, i oblicza wyrażenia serwerowe
  2. Wysłanie : przeglądarka zamienia wartości pól na extravars i wysyła je do POST /api/v2/job
  3. Sprawdzenie : serwer ponownie wczytuje formularz dla ról użytkownika i, gdy włączona jest walidacja przy uruchomieniu, sprawdza wartości
  4. Zapis : zadanie jest zapisywane ze stanem running, a jego id jest dodawane do extravars jako __jobid__
  5. Zatwierdzenie : formularz z punktem approval czeka, aż osoba zatwierdzająca zaakceptuje zadanie
  6. Poświadczenia : w przypadku playbooka aplikacja (nigdy RTE) odczytuje poświadczenia formularza z bazy danych lub z magazynu sekretów
  7. Uruchomienie : zadanie trafia do swojego runnera, tego, którego formularz wskazuje przez runner:, lub domyślnego dla swojego typu. W przypadku playbooka aplikacja wysyła zadanie do jego RTE przez WebSocket tego RTE, z poświadczeniami zaszyfrowanymi dla niego, a RTE uruchamia ansible-playbook (zobacz Jak działa RTE), natomiast AWX, AAP, Ascender, Semaphore, Rundeck lub Jenkins uruchamia szablon lub job. Workflow uruchamia swoje węzły, każdy jako osobne zadanie na własnym runnerze
  8. Śledzenie : serwer zapisuje wynik w bazie danych w miarę jego napływania, wysyłany przez RTE przez gniazdo w przypadku playbooka lub odczytywany z pozostałych runnerów. Strona formularza odczytuje zadanie co dwie sekundy, a strona Zadania śledzi je na żywo, gdy serwer ogłasza każdą zmianę
  9. Zakończenie : zadanie otrzymuje stan końcowy, a jego notifications są wysyłane pocztą i do jego kanałów powiadomień, gdy formularz o to prosi

Gdzie wszystko jest przechowywane

AnsibleForms przechowuje swój stan w dwóch miejscach: w bazie danych MySQL i w folderze trwałym. Twórz kopie zapasowe obu.

W bazie danych

Baza danych AnsibleForms jest tworzona przy pierwszym uruchomieniu (chyba że ALLOW_SCHEMA_CREATION ma wartość 0) i przechowuje:

  • zadania, ich extravars i wyniki, harmonogramy i zapisane zadania
  • użytkowników lokalnych, grupy i tokeny API
  • poświadczenia, zaszyfrowane kluczem ENCRYPTION_SECRET, oraz połączenia z magazynami sekretów
  • runnery, kanały powiadomień (łącznie z pocztą), serwery syslog oraz ustawienia LDAP, SSO, repozytoriów i asystenta czatu
  • dziennik audytu

W folderze trwałym

To /app/dist/persistent w obrazie i server/persistent przy instalacji ze źródeł; każda ścieżka ma własną zmienną:

Ścieżka domyślna Zmienna Zawartość
config.yaml CONFIG_PATH Kategorie, role i stałe
forms/ FORMS_FOLDER_PATH Pliki formularzy, .yaml lub .yml, w razie potrzeby w podfolderach
playbooks/ ANSIBLE_PATH Playbooki formularzy ansible i ich katalog roboczy
repositories/ REPO_PATH Klony repozytoriów git
forms_backups/ FORMS_BACKUP_PATH Kopie, które Projektant tworzy przed zapisem
backups/ BACKUP_PATH Kopie zapasowe bazy danych
uploads/ UPLOAD_PATH Pliki przesłane przez pola file
logs/ LOG_PATH ansibleforms.log i ansibleforms.errors.log
certificates/ HTTPS_CERT, HTTPS_KEY Certyfikat i klucz, gdy HTTPS ma wartość 1
.env   Zmienne środowiskowe zapisane ze stron ustawień (chyba że ALLOW_ENV_EDIT ma wartość 0)

Wygenerowany klucz SSH znajduje się w HOME_PATH, domyślnie poza folderem trwałym.