Cómo funciona

Las partes de una instalación, qué ocurre en un lanzamiento y dónde se guardan los datos

  1. Arquitectura
    1. Construido con
  2. Qué ocurre al lanzar un formulario
  3. Dónde se guardan las cosas

Arquitectura

AnsibleForms es un servidor Node.js que sirve la aplicación web y una API REST, respaldado por una base de datos MySQL. Lee los formularios de archivos YAML y no ejecuta nada por sí mismo: entrega cada trabajo a un runner. Un playbook va a uno de tus contenedores RTE (runtime environment, entorno de ejecución), que ejecuta ansible-playbook, y una plantilla o un job va a AWX, AAP, Ascender, Semaphore, Rundeck o Jenkins:

Arquitectura de AnsibleForms El navegador y un cliente MCP opcional se comunican con el servidor de AnsibleForms. El servidor guarda sus datos en MySQL y en la carpeta persistente, y se conecta a fuentes de datos, almacenes de secretos, repositorios git, proveedores de inicio de sesión, canales de notificación, servidores syslog y un proveedor de modelos opcional. Sus runners entregan cada playbook a uno de uno o varios contenedores RTE, cada uno a través de un WebSocket, que ejecutan ansible-playbook y devuelven la salida al servidor, y cada plantilla o job a AWX, AAP, Ascender, Semaphore, Rundeck o Jenkins. Navegador formularios, diseñador, trabajos, chat Cliente MCP opcional Servidor de AnsibleForms Node.js / Express Aplicación web y API REST Formularios, expresiones Workflows, programaciones Servidor MCP (opcional) Runners entregan trabajos a su runner Fuentes de datos bases de datos, APIs, archivos Almacenes de secretos HashiCorp Vault, CyberArk Repositorios git formularios, playbooks, config Proveedores de login LDAP, Entra ID, OIDC Notificaciones correo, Slack, Teams, webhooks Servidores syslog el log, la auditoría Proveedor de modelos opcional, asistente de chat Carpeta persistente config, formularios, playbooks MySQL / MariaDB trabajos, usuarios, credenciales Contenedores RTE ejecutan ansible-playbook AWX / AAP / Ascender Semaphore, Rundeck, Jenkins playbooks, WebSocket plantillas, jobs

Cada componente del diagrama tiene su propio papel:

Componente Papel
Navegador La aplicación web Vue: los formularios, el Diseñador, el historial de trabajos y la configuración
Servidor de AnsibleForms Evalúa los formularios, registra los trabajos, ejecuta los workflows y las programaciones, entrega cada trabajo a su runner y lo sigue, y sirve la API REST
Runners Dónde se ejecutan los trabajos, añadidos en Conexiones > Runners: un formulario nombra uno con runner: <name>, o usa el runner predeterminado de su tipo (consulta Runners)
Contenedores RTE Uno o varios contenedores de entorno de ejecución, el mismo servidor arrancado con AF_ROLE=rte: cada uno ejecuta ansible-playbook para los formularios de Ansible, con las librerías de python y las colecciones de su imagen, y envía la salida y el estado final al servidor a través de un WebSocket, sin credenciales de base de datos (consulta Cómo se ejecuta el RTE)
AWX / AAP / Ascender, Semaphore, Rundeck, Jenkins Runners para plantillas y jobs: los formularios de AWX lanzan una plantilla de job o de workflow, los formularios de Semaphore, Rundeck y Jenkins lanzan uno de sus jobs, y el servidor sigue su salida
MySQL / MariaDB Contiene los trabajos y su salida, los usuarios, las credenciales y las conexiones; solo el servidor lee y escribe en ella
Carpeta persistente Contiene config.yaml, los archivos de formularios, los playbooks, los logs y las copias de seguridad
Fuentes de datos Rellenan los campos: consultas a bases de datos, APIs REST, archivos y otras funciones
Almacenes de secretos Proporcionan el usuario y la contraseña de una credencial en el momento de usarla, consulta Almacenes de secretos
Repositorios git Mantienen los formularios, los playbooks y config.yaml bajo control de versiones
Proveedores de inicio de sesión Inician la sesión de los usuarios: LDAP, Entra ID y OIDC, además de los usuarios locales
Canales de notificación Llevan las notificaciones y las solicitudes de aprobación: correo, Slack, Microsoft Teams, Telegram o un webhook
Servidores syslog Reciben el log y la pista de auditoría a medida que se escriben, consulta Syslog
Cliente MCP, chat Opcionales, ambos desactivados por defecto: el servidor MCP y el asistente de chat, que necesita un proveedor de modelos

Por defecto, un contenedor ejecuta a la vez el servidor, la aplicación web y el trabajo en segundo plano, junto a un RTE. Para varios nodos de aplicación detrás de un balanceador de carga, un worker que ejecuta el trabajo en segundo plano y más RTE, consulta Escalado.

Construido con

El servidor y la interfaz web se basan en estos componentes:

Parte Tecnología
Servidor Node.js y Express
Base de datos MySQL o MariaDB
Interfaz web Vue 3, con Bootstrap 5 y Font Awesome

Qué ocurre al lanzar un formulario

Un lanzamiento pasa por los mismos pasos tanto si viene del navegador como de la API REST:

  1. Carga : el servidor envía solo los formularios que permiten los roles del usuario, y evalúa las expresiones del servidor
  2. Envío : el navegador convierte los valores de los campos en extravars y las envía con POST /api/v2/job
  3. Comprobación : el servidor vuelve a cargar el formulario para los roles del usuario y, con la validación del lanzamiento activada, comprueba los valores
  4. Registro : el trabajo se guarda con el estado running, y su id se añade a las extravars como __jobid__
  5. Aprobación : un formulario con un punto de approval espera hasta que un aprobador acepta el trabajo
  6. Credenciales : para un playbook, la aplicación (nunca el RTE) lee las credenciales del formulario de la base de datos o de un almacén de secretos
  7. Ejecución : el trabajo va a su runner, el que el formulario nombra con runner: o el predeterminado de su tipo. Para un playbook, la aplicación envía el trabajo a su RTE por el WebSocket del RTE, con sus credenciales selladas para él, y el RTE ejecuta ansible-playbook (consulta Cómo se ejecuta el RTE), y AWX, AAP, Ascender, Semaphore, Rundeck o Jenkins ejecuta una plantilla o un job. Un workflow ejecuta sus nodos, cada uno como un trabajo propio en su propio runner
  8. Seguimiento : el servidor guarda la salida en la base de datos a medida que llega, enviada por el RTE a través de su socket en el caso de un playbook, o leída de los demás runners. La página del formulario vuelve a leer el trabajo cada dos segundos, y la página Trabajos lo sigue en directo a medida que el servidor anuncia cada cambio
  9. Fin : el trabajo recibe su estado final, y sus notifications se envían por correo y a sus canales de notificación cuando el formulario las pide

Dónde se guardan las cosas

AnsibleForms guarda su estado en dos sitios: la base de datos MySQL y la carpeta persistente. Haz copia de seguridad de ambos.

En la base de datos

La base de datos, AnsibleForms, se crea en el primer arranque (salvo que ALLOW_SCHEMA_CREATION sea 0) y contiene:

  • los trabajos, sus extravars y su salida, las programaciones y los trabajos guardados
  • los usuarios locales, los grupos y los tokens de API
  • las credenciales, cifradas con ENCRYPTION_SECRET, y las conexiones a los almacenes de secretos
  • los runners, los canales de notificación (incluido el correo), los servidores syslog, y los ajustes de LDAP, SSO, repositorios y asistente de chat
  • el registro de auditoría

En la carpeta persistente

Es /app/dist/persistent en la imagen y server/persistent desde el código fuente; cada ruta tiene su propia variable:

Ruta predeterminada Variable Contenido
config.yaml CONFIG_PATH Las categorías, los roles y las constantes
forms/ FORMS_FOLDER_PATH Los archivos de formularios, .yaml o .yml, en subcarpetas si quieres
playbooks/ ANSIBLE_PATH Los playbooks de los formularios ansible, y su directorio de trabajo
repositories/ REPO_PATH Los clones de los repositorios git
forms_backups/ FORMS_BACKUP_PATH Las copias que hace el Diseñador antes de guardar
backups/ BACKUP_PATH Las copias de seguridad de la base de datos
uploads/ UPLOAD_PATH Los archivos subidos mediante campos file
logs/ LOG_PATH ansibleforms.log y ansibleforms.errors.log
certificates/ HTTPS_CERT, HTTPS_KEY El certificado y la clave, cuando HTTPS es 1
.env   Las variables de entorno guardadas desde las páginas de configuración (salvo que ALLOW_ENV_EDIT sea 0)

La clave SSH generada está en HOME_PATH, fuera de la carpeta persistente por defecto.