Como funciona

As partes de uma instalação, o que acontece num lançamento, e onde os dados são guardados

  1. Arquitetura
    1. Construído com
  2. O que acontece quando lança um formulário
  3. Onde as coisas são guardadas

Arquitetura

O AnsibleForms é um servidor Node.js que serve a aplicação web e uma API REST, apoiado por uma base de dados MySQL. Lê os formulários de ficheiros YAML e não executa nada por si: entrega cada tarefa a um runner. Um playbook vai para um dos seus contentores RTE (ambiente de execução), que executa ansible-playbook, e um template ou job vai para o AWX, AAP, Ascender, Semaphore, Rundeck ou Jenkins:

Arquitetura do AnsibleForms O navegador e um cliente MCP opcional comunicam com o servidor AnsibleForms. O servidor guarda os seus dados no MySQL e na pasta persistente, e liga-se a fontes de dados, cofres de segredos, repositórios git, fornecedores de início de sessão, canais de notificação, servidores syslog e um fornecedor de modelos opcional. Os seus runners entregam cada playbook a um de um ou mais contentores RTE, cada um através de um WebSocket, que executam o ansible-playbook e devolvem a saída ao servidor, e cada template ou job ao AWX, AAP, Ascender, Semaphore, Rundeck ou Jenkins. Navegador formulários, designer, tarefas, chat Cliente MCP opcional Servidor AnsibleForms Node.js / Express Aplicação web e API REST Formulários, expressões Workflows, agendamentos Servidor MCP (opcional) Runners entregam as tarefas ao runner Fontes de dados BD, APIs REST, ficheiros Cofres de segredos HashiCorp Vault, CyberArk Repositórios git formulários, playbooks, config Fornecedores de login LDAP, Entra ID, OIDC Notificações email, Slack, Teams, webhooks Servidores syslog o registo, a auditoria Fornecedor de modelos opcional, assistente de chat Pasta persistente config, formulários, playbooks MySQL / MariaDB tarefas, utilizadores, credenciais Contentores RTE executam ansible-playbook AWX / AAP / Ascender Semaphore, Rundeck, Jenkins playbooks, WebSocket templates, jobs

Os componentes do diagrama têm cada um a sua função:

Componente Função
Navegador A aplicação web em Vue: os formulários, o Designer, o histórico de tarefas e as definições
Servidor AnsibleForms Avalia os formulários, regista as tarefas, executa os workflows e os agendamentos, entrega cada tarefa ao seu runner e acompanha-a, e serve a API REST
Runners Onde as tarefas são executadas, adicionados em Ligações > Runners: um formulário indica um com runner: <name>, ou usa o runner predefinido do seu tipo (consulte Runners)
Contentores RTE Um ou mais contentores de ambiente de execução, o mesmo servidor iniciado com AF_ROLE=rte: cada um executa ansible-playbook para os formulários ansible, com as bibliotecas python e as coleções da sua imagem, e devolve a saída e o estado final ao servidor através de um WebSocket, sem credenciais da base de dados (consulte Como o RTE é executado)
AWX / AAP / Ascender, Semaphore, Rundeck, Jenkins Runners para templates e jobs: os formulários AWX lançam um job template ou um workflow template, os formulários Semaphore, Rundeck e Jenkins lançam um dos seus jobs, e o servidor acompanha a sua saída
MySQL / MariaDB Contém as tarefas e a sua saída, os utilizadores, as credenciais e as ligações; só o servidor a lê e escreve
Pasta persistente Contém o config.yaml, os ficheiros de formulários, os playbooks, os registos e as cópias de segurança
Fontes de dados Preenchem os campos: consultas a bases de dados, APIs REST, ficheiros e outras funções
Cofres de segredos Fornecem o utilizador e a palavra-passe de uma credencial no momento da utilização, consulte Cofres de segredos
Repositórios git Mantêm os formulários, os playbooks e o config.yaml sob controlo de versões
Fornecedores de login Iniciam a sessão dos utilizadores: LDAP, Entra ID e OIDC, ao lado dos utilizadores locais
Canais de notificação Transportam as notificações e os pedidos de aprovação: email, Slack, Microsoft Teams, Telegram ou um webhook
Servidores syslog Recebem o registo e o registo de auditoria à medida que são escritos, consulte Syslog
Cliente MCP, chat Opcionais, ambos desligados por predefinição: o servidor MCP e o assistente de chat, que precisa de um fornecedor de modelos

Por predefinição, um contentor executa o servidor, a aplicação web e o trabalho em segundo plano em conjunto, ao lado de um RTE. Para vários nós da aplicação por trás de um balanceador de carga, um worker que executa o trabalho em segundo plano, e mais RTEs, consulte Escalar.

Construído com

O servidor e a interface web assentam nestes componentes:

Parte Tecnologia
Servidor Node.js e Express
Base de dados MySQL ou MariaDB
Interface web Vue 3, com Bootstrap 5 e Font Awesome

O que acontece quando lança um formulário

Um lançamento passa pelos mesmos passos, venha do navegador ou da API REST:

  1. Carregar : o servidor envia apenas os formulários que as funções do utilizador permitem, e avalia as expressões do servidor
  2. Submeter : o navegador transforma os valores dos campos em extravars e envia-os para POST /api/v2/job
  3. Verificar : o servidor volta a carregar o formulário para as funções do utilizador e, com a validação do lançamento ativa, verifica os valores
  4. Registar : a tarefa é guardada com o estado running, e o seu ID é adicionado às extravars como __jobid__
  5. Aprovar : um formulário com um ponto de approval espera até que um aprovador aceite a tarefa
  6. Credenciais : para um playbook, a aplicação (nunca o RTE) lê as credenciais do formulário a partir da base de dados ou de um cofre de segredos
  7. Executar : a tarefa vai para o seu runner, aquele que o formulário indica com runner: ou o predefinido do seu tipo. Para um playbook, a aplicação envia a tarefa ao seu RTE através do WebSocket do RTE, com as credenciais seladas para ele, e o RTE executa ansible-playbook (consulte Como o RTE é executado), e o AWX, AAP, Ascender, Semaphore, Rundeck ou Jenkins executa um template ou um job. Um workflow executa os seus nós, cada um como uma tarefa própria no seu próprio runner
  8. Acompanhar : o servidor guarda a saída na base de dados à medida que chega, enviada pelo RTE através do seu socket no caso de um playbook, ou lida a partir dos outros runners. A página do formulário volta a ler a tarefa a cada dois segundos, e a página Tarefas acompanha-a em direto à medida que o servidor anuncia cada alteração
  9. Terminar : a tarefa recebe o seu estado final, e as suas notifications são enviadas por email e para os seus canais de notificação quando o formulário as pede

Onde as coisas são guardadas

O AnsibleForms guarda o seu estado em dois sítios: a base de dados MySQL e a pasta persistente. Faça cópias de segurança de ambos.

Na base de dados

A base de dados, AnsibleForms, é criada no primeiro arranque (a menos que ALLOW_SCHEMA_CREATION seja 0) e contém:

  • as tarefas, as suas extravars e a sua saída, os agendamentos e as tarefas guardadas
  • os utilizadores locais, os grupos e os tokens de API
  • as credenciais, cifradas com ENCRYPTION_SECRET, e as ligações aos cofres de segredos
  • os runners, os canais de notificação (incluindo o email), os servidores syslog, e as definições de LDAP, SSO, repositórios e do assistente de chat
  • o registo de auditoria

Na pasta persistente

É /app/dist/persistent na imagem e server/persistent a partir do código-fonte; cada caminho tem a sua própria variável:

Caminho predefinido Variável Conteúdo
config.yaml CONFIG_PATH As categorias, as funções e as constantes
forms/ FORMS_FOLDER_PATH Os ficheiros de formulários, .yaml ou .yml, em subpastas se quiser
playbooks/ ANSIBLE_PATH Os playbooks dos formulários ansible, e o seu diretório de trabalho
repositories/ REPO_PATH Os clones dos repositórios git
forms_backups/ FORMS_BACKUP_PATH As cópias que o Designer faz antes de guardar
backups/ BACKUP_PATH As cópias de segurança da base de dados
uploads/ UPLOAD_PATH Os ficheiros carregados através de campos file
logs/ LOG_PATH ansibleforms.log e ansibleforms.errors.log
certificates/ HTTPS_CERT, HTTPS_KEY O certificado e a chave, quando HTTPS é 1
.env   As variáveis de ambiente guardadas a partir das páginas de definições (a menos que ALLOW_ENV_EDIT seja 0)

A chave SSH gerada fica em HOME_PATH, fora da pasta persistente por predefinição.