argocd-bootstrap

Bootstrap do Argo CD: o release Helm, os AppProjects ladesa e ladesa-satellites, e a Application root. Os values do release ficam em files/argocd-values.yaml, dentro deste mesmo role, não no root do repositório.

Fronteira de posse: este role é dono só do release Helm do Argo CD e dos manifests em argocd/root, os dois AppProjects e a Application root. Tudo que o root descobre em argocd/applications, recursivamente, é do próprio Argo CD, que sincroniza sozinho a partir daí. O Ansible nunca aplica nada dentro de argocd/apps ou argocd/applications diretamente, só o que está em argocd/root. Isso evita Helm e Argo CD disputando o mesmo recurso depois.

Dois AppProjects, não um só, por escopo de risco: ladesa cobre só infrastructure.git e os charts Helm que os serviços de foundation já usam hoje (Infisical, Portainer), com clusterResourceWhitelist largo (ClusterRole, ClusterRoleBinding, CustomResourceDefinition, os dois tipos de webhook), porque cert-manager e o Infisical Operator legitimamente precisam disso. ladesa-satellites cobre os cinco repositórios de time (web, docs, management-service, timetable-generator, authentication-service) mais o chart da Stakater, sem nenhum recurso cluster-wide além de Namespace. Sem essa separação, um commit malicioso ou uma credencial de CI comprometida em qualquer um desses cinco repositórios de time poderia criar um ClusterRoleBinding de cluster-admin ou um MutatingWebhookConfiguration interceptando qualquer pod do cluster, não só afetar o próprio namespace. Nenhum app-*.yaml desses repositórios existe ainda (ver Estrutura), então quando forem criados, devem declarar project: ladesa-satellites, nunca project: ladesa. Até lá, ladesa-satellites fica aplicado no cluster sem nenhuma Application referenciando ele, órfão de propósito, preparação adiantada pro item "Padronizar o deployment com Argo CD" (ver Pendências), não um recurso esquecido.

flowchart TB
    subgraph Ladesa["AppProject ladesa"]
        Infra[infrastructure.git] --> Whitelist1[clusterResourceWhitelist largo: ClusterRole, CRD, webhook]
    end
    subgraph Satellites["AppProject ladesa-satellites"]
        Times[5 repositórios de time] --> Whitelist2[sem recurso cluster-wide além de Namespace]
    end
    Times -.->|credencial comprometida| Contido[dano contido ao próprio namespace]

O role nunca faz helm upgrade --install cego. Antes de tocar no release, lê o que já está instalado e compara com o que este repositório declara, e só aplica se houver divergência real, o mesmo princípio de idempotência do resto do Ansible. Isso importa porque o ansible-pull roda sozinho, sem ninguém olhando: sem essa checagem, um ajuste manual feito pra debugar em produção seria desfeito na próxima execução sem aviso. O mesmo vale pro root.yaml, sempre com kubectl diff antes de kubectl apply.

flowchart TD
    Ciclo[ansible-pull roda sozinho, sem supervisão] --> Le[lê release já instalado]
    Le --> Compara{diverge do declarado?}
    Compara -->|não| NoOp[nada acontece, ajuste manual preservado]
    Compara -->|sim| Aplica[helm upgrade, kubectl diff antes de apply]

A versão do chart, 10.3.3, entrega o Argo CD v3.5.1. Confirmado em agosto de 2026, contra a documentação oficial de versões testadas do Argo CD, que essa linha (v3.5.x) é testada contra Kubernetes v1.33, a versão do k3s deste cluster na época. Se argocd_chart_versao for atualizado no futuro, vale reconferir essa compatibilidade contra a mesma documentação, essa afirmação não se atualiza sozinha.

files/argocd-values.yaml declara ingress em argocd.ladesa.com.br, seguindo o mesmo padrão de infisical.ladesa.com.br e portainer.ladesa.com.br. Esse hostname específico não veio de nenhum values já capturado do cluster, foi proposto por analogia. Conferi via dig que já resolve pros mesmos IPs dos outros dois, então é provável que exista um wildcard na zona DNS, mas vale confirmar visualmente que o Argo CD abre em https://argocd.ladesa.com.br depois do primeiro apply, já que essa parte específica não foi validada contra o estado real do cluster como o resto deste role foi.