Concepts
Les termes utilisés dans cette documentation, chacun avec un lien vers sa page
Glossaire
Les termes utilisés dans cette documentation :
| Terme | Signification |
|---|---|
| Formulaire | Une définition YAML qui recueille des saisies et exécute un playbook, un modèle ou un workflow |
| Champ de formulaire | Une saisie d’un formulaire, comme text, enum ou checkbox ; sa valeur devient une extravar |
| Catégorie | Un groupe dans l’arborescence des formulaires affichée sur la page Formulaires, défini dans config.yaml |
| Rôle | Un ensemble d’utilisateurs et de groupes ; un formulaire liste les rôles qui peuvent le voir et l’exécuter, default pour tout le monde |
| Expression | Du JavaScript qui calcule la valeur d’un champ, dans le navigateur (runLocal: true) ou sur le serveur |
| Extravars | Les variables envoyées au playbook ou au modèle, construites à partir des valeurs des champs |
| Identifiant | Un accès enregistré, chiffré avec ENCRYPTION_SECRET : un utilisateur et un mot de passe (plus hôte, port, base de données), ou depuis la 7.3.0 l’adresse et les secrets d’un annuaire LDAP, d’un fournisseur SSO, d’un runner ou d’un HashiCorp Vault |
| Coffre de secrets | Une connexion à HashiCorp Vault ou CyberArk qui fournit l’utilisateur et le mot de passe d’un identifiant |
| Job | Une exécution d’un formulaire, avec son statut, ses extravars et sa sortie, conservée dans l’historique des jobs |
| Runner | L’endroit où un job s’exécute, ajouté sous Connexions > Runners : rte pour les playbooks, awx (AWX, ou la variante aap ou ascender), semaphore, rundeck ou jenkins pour les modèles et les jobs. Un formulaire en choisit un avec runner:, ou s’exécute sur le runner par défaut rte (playbooks) ou awx (modèles) |
| RTE | Un environnement d’exécution (runtime environment) : le serveur AnsibleForms démarré avec AF_ROLE=rte dans son propre conteneur, à côté de python et d’ansible, qui exécute les playbooks d’un runner de type rte |
| Point d’approbation | Une pause dans un job jusqu’à ce qu’un utilisateur ayant un rôle d’approbation l’approuve ou le rejette |
| Workflow | Un graphe de playbooks, d’approbations et d’autres workflows liés en cas de succès, en cas d’échec ou toujours, dans la syntaxe d’AWX |
| Formulaire multi-étapes | Obsolète depuis la 7 : un formulaire qui exécute plusieurs playbooks ou modèles à la suite ; un workflow le remplace |
| Canal de notification | Un serveur de messagerie, un webhook Slack ou Teams, un chat Telegram ou un webhook vers lequel partent les notifications et les demandes d’approbation |
| Concepteur | L’éditeur dans le navigateur pour les formulaires, les playbooks, les inventaires et les workflows, qu’une seule personne utilise à la fois |
| Sous-formulaire | Un ensemble réutilisable de champs qui décrit les lignes d’un champ list ou l’objet d’un champ yaml |
| config.yaml | Le fichier qui contient les catégories, les rôles et les constantes ; les formulaires sont dans leurs propres fichiers |
| Seed de configuration | Un fichier YAML (CONFIG_SEED_PATH) qui déclare les objets d’administration, comme les runners et les identifiants |
| Dossier persistant | Le dossier qui contient les fichiers qu’AnsibleForms doit conserver entre les redémarrages et les mises à niveau |