Deploy em Duas Etapas (Fase 4)

Na Fase 4, o agente implanta as ferramentas em duas etapas lógicas de dependência. A ordem importa: a aplicação só sobe depois que seu banco está pronto.

Etapa 1 — Stateful First

O agente cria o manifesto do PostgreSQL via CloudNativePG. O Kubernetes agenda esse pod exclusivamente no rke-db-00, porque o manifesto carrega o bloco canônico de affinity + tolerations.

sequenceDiagram
    participant Ag as Agente
    participant K as Kubernetes
    participant DB as rke-db-00
    participant App as rke-app-01/02
    Ag->>K: 1. aplica Cluster CNPG (stateful)
    K->>DB: agenda PostgreSQL (affinity + toleration)
    DB-->>K: banco pronto + Service (ClusterIP)
    Ag->>K: 2. aplica app (stateless)
    K->>App: agenda frontend/backend
    App->>DB: conecta via Service interno

Etapa 2 — Stateless Second

Com o banco no ar, o agente implanta o frontend/backend da aplicação, que é agendado nos nós rke-app-01 ou rke-app-02. A aplicação se conecta ao banco interno pelo Service (ClusterIP) fornecido pelo operador.

# A aplicação stateless referencia o Service do banco — nunca um IP fixo
env:
  - name: DATABASE_URL
    value: postgres://app@nextcloud-db-rw.nextcloud.svc.cluster.local:5432/nextcloud

Por que esta ordem

• Dependência real: sem banco, a aplicação não inicia de forma saudável.
• Idempotência: se a aplicação for recriada, o banco (com seus dados) permanece intacto no rke-db-00.
• Separação de cargas: stateful e stateless vivem em nós distintos, como exige o princípio de separação de cargas.

Veja o padrão de deploy das aplicações para o passo a passo aplicado a GitLab, Nextcloud e Penpot.