Formularze
Definiowanie formularzy, które wypełniają twoi użytkownicy
Dla autorów formularzy: jak formularze zapisuje się w YAML, skąd są ładowane i jakie właściwości ma każdy typ formularza.
Formularze są sercem AnsibleForms. Każdy formularz to interfejs webowy, który zbiera dane od użytkownika i na ich podstawie uruchamia playbook Ansible, szablon AWX, AAP lub Ascender, szablon Semaphore, zadanie Rundeck lub Jenkins albo workflow.
Formularze definiuje się w plikach YAML w folderze formularzy. Każdy plik YAML zawiera jeden formularz lub listę formularzy, a do ich porządkowania można używać podfolderów.
WIDEO: Utwórz swój pierwszy formularz
Struktura formularza
Każdy formularz w AnsibleForms konfiguruje się zestawem właściwości. Wspólne właściwości wymienia właściwości dotyczące wszystkich typów formularzy; strony poszczególnych typów opisują dodatkowe.
Jak ładowane są formularze
AnsibleForms ładuje formularze z następujących miejsc:
- Z REPOZYTORIÓW : wszystkie repozytoria z włączonym przełącznikiem „Używać do formularzy?” (obsługiwanych jest wiele repozytoriów)
- Formularze ze wszystkich włączonych repozytoriów są scalane automatycznie.
- W każdym repozytorium najpierw sprawdzany jest podfolder
forms/. - Jeśli podfolder
forms/nie istnieje, używany jest katalog główny repozytorium. - Formularze utworzone w projektancie i jeszcze niewypchnięte są przechowywane w folderze przejściowym (
FORMS_STAGING_PATH) i ładowane razem z nimi.
- Z FOLDERU LOKALNEGO : lokalny folder
forms/(FORMS_FOLDER_PATH), gdy żadne repozytorium nie ma włączonego „Używać do formularzy?”
Uwaga: Gdy „Używać do formularzy?” jest włączone w kilku repozytoriach, wszystkie ich formularze są scalane. Nazwy formularzy muszą być unikalne we wszystkich repozytoriach, aby uniknąć konfliktów.
Gdzie działa formularz
Typ formularza decyduje o rodzaju runnera, na którym działa jego zadanie: RTE dla ansible, runner AWX dla awx, aap i ascender oraz runner własnego typu dla semaphore, rundeck i jenkins.
runner: <name>w formularzu wybiera runner tego typu po nazwie; bez tego zadanie działa na domyślnym runnerze danego typu.- Runner wyłączony w Połączenia > Runnery powoduje błąd zadania, niezależnie od tego, czy formularz go wskazuje, czy jest on domyślny. Zadanie nigdy nie przechodzi na inny runner.
- Gdy jedna z ról użytkownika ma listę
runnerswconfig.yaml, zadanie może działać tylko na runnerze wymienionym przez taką rolę, w przeciwnym razie zostaje odrzucone. Role bez tej listy go nie ograniczają, a administrator nigdy nie jest ograniczony.
W tej sekcji
Na kolejnych stronach szczegółowo opisano właściwości formularzy:
| Strona | Czego dotyczy |
|---|---|
| Wspólne właściwości | Właściwości dotyczące wszystkich typów formularzy (name, description, help, type, fields) |
| Formularze Ansible | Właściwości specyficzne dla type: ansible |
| Formularze AWX | Właściwości specyficzne dla type: awx |
| Formularze Semaphore | Właściwości specyficzne dla type: semaphore, który uruchamia szablon Semaphore |
| Formularze Rundeck | Właściwości specyficzne dla type: rundeck, który uruchamia zadanie Rundeck |
| Formularze Jenkins | Właściwości specyficzne dla type: jenkins, który buduje zadanie Jenkins |
| Formularze wieloetapowe | Właściwości specyficzne dla type: multistep, przestarzałego na rzecz workflow |
| Formularze workflow | Właściwości specyficzne dla type: workflow, który uruchamia workflow |
| Kreator | Podział danych formularza na kilka stron (działa z każdym wykonywalnym typem formularza) |
| Podformularz | Podformularze używają tylko wspólnych właściwości |
| Punkty zatwierdzenia | Wstrzymanie zadania do czasu zatwierdzenia (approval) |
| Powiadomienia | Wysyłanie e-maili i wiadomości na kanały przy stanie zadania lub zdarzeniach (notifications) |
| Akcje stanu zadania | Działania na formularzu, gdy zadanie zmienia stan (onSubmit, onSuccess, …) |