Aprender · Arquitetura

Red Hat Ansible Automation Platform 2.7

Os componentes da plataforma, o que cada um faz, como se organizam numa arquitetura Enterprise e como a automação alcança outras regiões e redes segmentadas. Feito para responder com segurança quando perguntarem em reunião — conferido na doc oficial 2.7.

Analogia: pense no AAP como um aeroporto de automação — a torre de controle (gateway) organiza tudo, os terminais executam voos (controller/EDA), o depósito guarda os aviões prontos (hub/EE) e a malha de rotas (mesh) leva a automação a destinos distantes.

Parte 1

Os componentes — o que são e para que servem

Cada peça tem um papel. "Obrigatório" = a plataforma não roda sem ele; "opcional" = agrega valor, mas dá para viver sem no início.

Componente	O que é	Para que serve	Papel
Platform gateway	A porta de entrada única — uma só UI e uma só API, com login central.	Autenticação, autorização e roteamento; unifica Controller, Hub e EDA sob um endereço e uma identidade.	obrigatório
Automation Controller	O motor de execução — quem roda os jobs.	Guarda job templates, inventories, credentials, projetos (Git), agendamentos e RBAC; dispara a automação nos nós de execução.	obrigatório
Private Automation Hub	O almoxarifado interno de conteúdo.	Hospeda internamente collections e Execution Environments, com curadoria (certified/validated); fonte confiável e offline-friendly.	nas topologias testadas
Event-Driven Ansible (EDA)	O piloto automático por eventos.	Executa rulebooks (se evento X → ação Y) a partir de fontes (monitoração, webhooks, filas): detectar → decidir → remediar.	incluído na 2.7
Automation Mesh	A malha de rotas que distribui o trabalho, inclusive por redes separadas.	Rede overlay peer-to-peer (protocolo Receptor) que leva a execução a sites/regiões remotas via nós control/hybrid/execution/hop.	essencial multi-site
Execution Environment (EE)	Uma imagem de contêiner com Ansible + collections + dependências.	Ambiente imutável e versionado onde a automação roda ("roda igual em qualquer lugar"). Criado com ansible-builder.	obrigatório
PostgreSQL	O banco de dados da plataforma.	Estado de Controller, Hub, EDA, gateway e métricas. Instalador = PostgreSQL 15; externo = 15/16/17 com ICU.	obrigatório
Redis	A memória rápida / fila da plataforma.	Cache e enfileiramento para o gateway e o EDA (lançamento de jobs). Colocado nos nós; em cluster HA no enterprise.	obrigatório na 2.7
Automation Analytics / Insights	O painel gerencial (uso e saúde da automação).	Uso e saúde da plataforma; alimenta o dashboard via metrics service local. O Automation Savings Planner (valor/ROI) é roadmap — não ofertado nesta fase.	opcional (recomendado)
Ansible Lightspeed	Assistente de IA que gera tarefas Ansible a partir de linguagem natural.	Acelera a criação de playbooks/roles. Add-on separado.	opcional

Ferramentas de desenvolvimento do ecossistema (não são serviços do cluster): ansible-builder (constrói EEs), ansible-navigator (roda/depura), ansible-lint + molecule (qualidade/testes), ansible-core (o motor).

Parte 2

Arquitetura Enterprise — control plane × execution plane

Separar quem pensa de quem executa é o princípio da escala: você adiciona capacidade de execução sem mexer no cérebro da plataforma.

● Control plane (pensa)

Platform gateway — UI/API/login
Automation Controller — orquestra jobs
Private Automation Hub — conteúdo
EDA Controller — eventos
Redis + PostgreSQL + metrics — estado e fila

Guarda estado, agenda, autentica e decide.

● Execution plane (executa)

Execution nodes — rodam os EEs contra os hosts
Hop nodes — alcançam redes/regiões remotas

Onde a automação acontece. É aqui que você escala capacidade (mais nós / forks).

Growth × Enterprise (topologias testadas · containerizadas)

Aspecto	Growth	Enterprise
Objetivo	Começar; footprint pequeno, sem redundância	Produção resiliente, alto volume, HA
Formato	All-in-One: todos os componentes numa VM única	Multi-VM, componentes separados e replicados
PostgreSQL	Gerenciado pelo instalador (PostgreSQL 15)	Externo (cliente), 15/16/17 com ICU
Redis	Colocado na VM única	Cluster HA (mín. 6 VMs); externo não suportado
Load balancer	—	HAProxy na frente do gateway
Redundância	Não	gateway ×2 · controller ×2 · hub ×2 · EDA ×2 · execution ×2

Topologia ENTERPRISE testada — inventário de nós (Plan AAP 2.7, p.17-18)

CONTROL PLANE                          EXECUTION PLANE
├─ 2 × Platform gateway (+Redis)       ├─ 1 × Hop node (mesh)
├─ 2 × Automation controller           └─ 2 × Execution node (mesh)
├─ 2 × Private automation hub (+Redis)
├─ 2 × Event-Driven Ansible (+Redis)   EXTERNOS (fora do AAP)
├─ 1 × Metrics service                 ├─ 1 × PostgreSQL (externo)
                                       └─ 1 × HAProxy (load balancer)

Total: 12 VMs do AAP + DB externo + HAProxy · Redis HA exige ≥ 6 VMs

Parte 3

Comunicação entre regiões e redes segmentadas

O Automation Mesh é uma rede overlay peer-to-peer que espalha o trabalho por workers distribuídos, usando o protocolo Receptor (TCP 27199). O control plane não fala direto com cada host remoto — entrega o trabalho a nós da malha, que o encaminham até o destino.

Tipos de nó

Control — origina/controla jobs; não executa.
Hybrid — controla e executa.
Execution — só executa (roda o EE contra os hosts). Escala aqui.
Hop — não executa; só repassa (relay) o tráfego entre segmentos de rede.

Por que existem hop nodes

Em multi-site, o control plane muitas vezes não tem rota direta para os hosts de uma rede isolada (DMZ, planta, filial, nuvem). O hop node fica na fronteira: o Controller fala com o hop, o hop fala com os execution nodes do outro lado. Você automatiza a região remota abrindo apenas um link (o de mesh), em vez de expor a rede toda.

REGIÃO CENTRAL (control plane)        FRONTEIRA       REGIÃO REMOTA / rede isolada
┌──────────────────────────┐        ┌──────────┐       ┌───────────────────────────┐
│ Controller / gateway …   │══27199══▶│ Hop node │══27199═▶│ Execution node ─▶ hosts   │
└──────────────────────────┘        └──────────┘       └───────────────────────────┘
        (control plane)            (relay Receptor)          (execution plane)

Sentido das conexões: a doc descreve comunicação bidirecional pelo link Receptor; quem inicia a conexão TCP é definido no inventário pela relação de peers (receptor_peers) — é isso que permite respeitar o sentido que o firewall exige. O SSH (22) é usado só do nó instalador → nós, para instalar/atualizar; não é o canal de execução.

Ponto para o cliente: a malha automatiza sites remotos sem VPN ampla nem abrir a rede inteira — só o link Receptor (27199) entre o hop e o control plane. O sentido definitivo de iniciação deve ser desenhado com o time de rede (confirmar na seção Automation mesh da doc 2.7 conforme o diagrama de firewall).