Pendências¶

TLDR: bypass de CI pra desfazer depois, débito técnico real (não gambiarra descartável), rotação de senha planejada, a rotina de operação contínua ainda por criar, e o trabalho maior da organização (arquivar repositório, consolidar serviço, padronizar GitOps) ainda não retomado. RabbitMQ foi desligado em 2026-08-24. Cada item tem uma condição clara de quando resolver, não fica em aberto pra sempre sem critério.

Esta página existe pelo mesmo motivo de Estado fora do git: decisão deliberada de adiar algo é diferente de esquecer que ela existe. Toda vez que um bypass, gate desligado, ou solução temporária entrar no repositório, uma linha entra aqui antes de considerar o trabalho terminado.

Bypasses de CI a desfazer¶

Ordem deliberada, decisão do usuário em 2026-08-21: corrigir os bypasses de CI desta seção só depois de todo o resto do backlog deste documento estar resolvido, não antes e não em paralelo. Motivo prático: promover um check de continue-on-error: true pra bloqueante quebra merge de qualquer PR (inclusive da sessão paralela que também trabalha neste repositório) até o baseline estar limpo, então mexer aqui cedo demais é fonte de atrito sem necessidade. Melhor deixar por último, quando o resto já estiver estável.

misconfig (trivy) em security.yml está continue-on-error: true desde 2026-08-21. Motivo: a primeira varredura real achou securityContext ausente em postgres, mariadb, minio, adminer (namespace dados), rabbitmq e redis-server, achado real, mas cada imagem tem UID/GID próprio, corrigir errado quebra o container. Condição pra reverter pra bloqueante: cada Deployment listado abaixo, em "Débito técnico: securityContext", corrigido e validado contra o serviço real.
Todos os checks de codigo-e-infra em quality.yml (yamllint, ansible-lint, jscpd, kubeconform, shellcheck, actionlint, zizmor, cspell, ast-grep, kubescape) são continue-on-error: true desde que o job foi criado, nunca foram bloqueantes. Condição pra promover cada um: revisar o baseline de achados daquele check especificamente, zerar o que for real, só então tirar o continue-on-error (ver Qualidade de código e infraestrutura).
argocd/apps/operators/cert-manager não existe mais, exclusões correspondentes removidas: resolvido em 2026-08-21, efeito colateral da migração do cert-manager pro chart oficial (ver auditoria de chart oficial abaixo). cert-manager tirado de skip-dirs (trivy, security.yml), --exclude-namespaces (kubescape, quality.yml; o chart oficial já define securityContext por padrão, resolvendo também o débito de securityContext ausente pra esse componente específico), --ignore (jscpd), ignore (.yamllint), ignorePaths (.cspell.config.yaml), ignores da regra no-comments-yaml do ast-grep (bloco inteiro removido, já que não sobrou nenhuma exceção; cnpg nunca precisou dessa exclusão específica). argocd/apps/operators/cnpg continua excluído dos mesmos checks (exceto kubescape, que ver abaixo), permanente por natureza (RBAC amplo e conteúdo exigido pelo próprio operador vendorizado, ver Foundation) até esse operador também migrar pro chart oficial. find -not -path na geração manual do kube-diagrams (não é CI, ver Topologia declarada do cluster) ainda precisa de conferência/ajuste separado (não coberto por este item).

Licença do repositório¶

Este repositório não tinha LICENSE: resolvido em 2026-08-21, criado LICENSE (MIT, mesmo texto do management-service, Copyright (c) 2024-present LADESA e Colaboradores) e linkado no README.md.

Segurança do próprio Argo CD¶

Achados da auditoria de 2026-08-21 (ver Aprender: Argo CD). O detalhe dos que seguem em aberto fica no inventário privado apontado por Estado fora do git.

TLS real na UI/API do Argo CD: resolvido. Estava em HTTP puro sem redirect (confirmado ao vivo com curl, HTTP 200 completo na porta 80) e, na 443, caía no certificado autoassinado padrão do Traefik. Corrigido com server.ingress.tls: true + annotation cert-manager.io/cluster-issuer: ladesa-ro-issuer-production; certificado real do Let's Encrypt confirmado (argocd-server-tls, válido até 2026-11-19).
resources (requests/limits) em todos os componentes do Argo CD: resolvido, mas revelou um achado maior, registrado no inventário privado. Também desligados dex/notifications (rodavam sem nenhuma configuração real) e zerado applicationSet.replicas (nenhum ApplicationSet existe no cluster).
TLS real em infisical.ladesa.com.br, portainer.ladesa.com.br e adminer.ladesa.com.br: resolvido em 2026-08-21, mesmo padrão do Argo CD (tls: + cert-manager.io/cluster-issuer: ladesa-ro-issuer-production), certificados reais do Let's Encrypt confirmados ao vivo pros três. O Ingress do adminer não existia no git (criado fora de banda pela UI do Portainer, io.portainer.kubernetes.ingress.owner: unknown), trazido pro git agora em argocd/foundation/dados/adminer.yaml. Pegadinha real descoberta no processo: portainer/infisical têm seu Ingress gerado por chart Helm com values embutido direto no manifest da Application (argocd/applications/), e esse manifest só é aplicado no cluster quando a Application root é sincronizada (ver "O padrão app-of-apps"); sincronizar foundation-portainer/foundation-infisical direto, sem sincronizar root primeiro, aplicou os recursos usando o spec.source.helm.values antigo, ainda em cache no objeto Application, produzindo um "sucesso" que não mudou nada. Só percebido conferindo o Ingress ao vivo depois, não confiando no argocd app diff --core (que também não renderirizou o chart Helm corretamente nesse modo, mais um motivo pra sempre verificar o recurso real, não só a saída do comando).
TLS real em sso.ladesa.com.br: resolvido em 2026-08-21, na mesma mudança que migrou o provedor de identidade pro Argo CD. Servia em HTTP puro, e o 443 caía no certificado autoassinado padrão do Traefik. Agora serve certificado da Let's Encrypt emitido pelo ladesa-ro-issuer-production, o mesmo emissor dos outros nove certificados do cluster, declarado em gitops/apps/sso/values-production.yaml do repositório satélite. O HTTP continua respondendo, ver o item sobre o issuer do OIDC no inventário privado.
Achados desta revisão que seguem em aberto: descritos no inventário privado apontado por Estado fora do git, e não aqui. Quem for trabalhar neles consulta lá. Conforme cada um for corrigido, a descrição completa volta pra esta página, porque problema resolvido pode ser documentado por inteiro sem servir de mapa pra ninguém.

Revisão de segurança: portas, `Ingress` e `Service` expostos¶

Levantamento completo feito em 2026-08-21, a pedido explícito do usuário ("revisão de segurança de tudo o que está liberado: portas no host, ingress, services"). Metodologia: nada assumido, cada achado testado ao vivo (nc/curl de fora do node, não só lendo configuração).

Achados desta revisão que seguem em aberto: descritos no inventário privado apontado por Estado fora do git, e não aqui. Quem for trabalhar neles consulta lá. Conforme cada um for corrigido, a descrição completa volta pra esta página, porque problema resolvido pode ser documentado por inteiro sem servir de mapa pra ninguém.
NodePorts e LoadBalancer do cluster, achado positivo: todos os Service desse tipo foram testados ao vivo de fora do node e estão bloqueados de verdade, só 22, 80 e 443 respondem. Corrige uma suposição antiga em Foundation, que atribuía o bloqueio a um NAT que não existe. Sem ação necessária, achado só de correção de registro. O detalhe fica no inventário privado apontado por Estado fora do git.

Débito técnico: `securityContext` ausente¶

Acompanha o item acima. Um item por serviço, porque a correção de cada um é independente (UID diferente, risco de quebrar não é o mesmo):

argocd/foundation/dados/postgres.yaml: resolvido pela migração pro CloudNativePG em 2026-08-21 (o operador roda com usuário fixo não-root por padrão), arquivo removido do repositório, ver Foundation.
argocd/foundation/dados/mariadb.yaml: resolvido em 2026-08-21, migrado pro mariadb-operator, arquivo removido do repositório, ver Foundation.
argocd/foundation/dados/minio.yaml: resolvido em 2026-08-21. A imagem Silo não define nenhum usuário não-root no Dockerfile (roda como uid=0 por padrão, sem convenção própria, igual ao MinIO upstream), então foi escolhido uid=1000/gid=1000 arbitrário. Backup do hostPath feito antes (tar czf, ~19KB, só .minio.sys vazio, confirmado sem bucket real), chown -R 1000:1000 /root/dados/vols/miniodata/ no node (autorizado explicitamente pelo usuário, ação bloqueada pelo classificador de modo automático), depois securityContext adicionado ao Deployment. Validado: id ao vivo no pod confirma uid=1000, servidor Silo iniciou sem erro de permissão em /data.
argocd/foundation/dados/adminer.yaml: resolvido em 2026-08-21. id ao vivo confirmou que a imagem já roda como uid=100(adminer) gid=101(adminer) por padrão, sem hostPath nem estado nenhum, então runAsNonRoot: true/runAsUser: 100/runAsGroup: 101 só formaliza o que já acontecia; validado com rollout limpo (1/1 Running, sem restart).
argocd/foundation/rabbitmq/deployment.yaml: resolvido em 2026-08-21 pela migração pro RabbitMQ Cluster Operator, que já roda com runAsNonRoot: true, runAsUser: 999, readOnlyRootFilesystem: true, capabilities dropadas por padrão. O deployment.yaml legado foi removido em 2026-08-24 junto do desligamento completo do RabbitMQ (ver Desligar o RabbitMQ), fechando este item de verdade.
argocd/foundation/redis/deployment.yaml: resolvido em 2026-08-21. id ao vivo confirmou que a imagem Bitnami já roda como uid=1001/gid=0 por padrão (convenção Bitnami de UID arbitrário compatível com OpenShift), então runAsNonRoot: true/runAsUser: 1001/fsGroup: 0 só formaliza o que já acontecia. Validado depois do rollout: DBSIZE (1856 chaves) e as 23 conexões BullMQ do Infisical intactas, nenhum dado perdido no restart.

Rotação de senha planejada¶

Ver Estado fora do git, rotação preventiva pro procedimento de cada item. Itens específicos que valem rotação assim que a condição bater, não só "algum dia":

As 4 roles do Postgres (ladesa, infisical, api-dev, sso-production): depois que a migração pro CloudNativePG estiver concluída e confirmada (o processo de import descriptografa a senha de cada role em memória volátil no node, mesmo nunca gravando em disco ou git, defesa em profundidade justifica rotacionar depois, não só confiar que não vazou).
Senha do Ansible Vault: sem condição de gatilho específica ainda, cadência a definir pela equipe (ver rotação preventiva).
As duas deploy keys (infrastructure, infrastructure-vault): mesma cadência a definir, ou imediatamente se alguém que teve acesso ao node sair da equipe (ver ciclo de vida de acesso).

Rotina de operação contínua a criar¶

Hoje só existe documentação de bootstrap (rodar uma vez, do zero até o cluster de pé, ver Bootstrap mínimo na VM). Falta a contraparte de manutenção contínua: uma seção própria, separada do bootstrap, cobrindo o que se repete depois que o cluster já está rodando.

Rotação de senha recorrente, cobrindo os dois universos de segredo deste repositório, não só um: os de bootstrap (Ansible Vault, ver acima) e os gerenciados pelo Infisical (mariadb-env, minio-env, rabbitmq-config, os próprios segredos internos do Infisical). Definir cadência, quem executa, e o procedimento exato pra cada categoria (os dois não se resolvem do mesmo jeito: um é ansible-vault + scripts/create-from-cluster, o outro é a UI/API do Infisical).
Acompanhamento de saúde do cluster (o que checar, com que frequência, o que fazer se algo estiver fora do esperado) ainda não tem escopo definido, precisa ser desenhado antes de virar documentação.
Revisão dos bypasses e afrouxamentos de CI registrados nesta página (ver Bypass e afrouxamento de CI): reler a seção "Bypasses de CI a desfazer" acima e achar o que já tem condição de reversão satisfeita, não deixar acumular.
Revisão de versão de cada ferramenta do stack de CI (ver Versões desatualizadas das ferramentas de bootstrap pro equivalente do lado Ansible/Helm/k3s): as ferramentas hermitizadas em .config/hermit/hermit-packages/*.hcl e as actions pinadas por hash nos workflows, conferindo se algum release novo já passou da janela de cooldown de 7 dias.
Revisão de licença de cada ferramenta do stack de CI (ver Licenças das ferramentas de CI): licença pode mudar numa atualização de versão, não só na adoção inicial, o caso real do gitleaks-action v2 (MIT pra licença própria) é o motivo desta linha existir.
Inventário do node, percorrendo três superfícies item por item: pacotes instalados, units habilitadas no systemd, e sockets em escuta. Pra cada item, as mesmas três perguntas: quem é o dono, ainda serve, e a exposição de rede dele é compatível com quem alcança aquela interface. O desfecho é uma das três saídas de sempre, declarar, restringir, ou remover. Apoiado por scripts/inventariar-node.sh, previsto na próxima leva, que torna a passada repetível em vez de depender de quem lembra dos comandos. Achado com implicação de segurança vai pra quem opera o node, não pra esta página.
Decidir onde essa seção mora: docs/operacao/ ganha uma página nova (ex.: manutencao.md), ou vira parte de Checklist com uma segunda tabela, separada da de bootstrap.

Modernização de Applications do `argocd/foundation`¶

Levantamento feito em 2026-08-21, pesquisando estado atual de cada tecnologia antes de propor qualquer mudança (mesmo cuidado da migração do Postgres pro CloudNativePG, que já está concluída, ver Foundation). Cada item precisa do mesmo processo cuidadoso (pesquisa, plano, cluster descartável, dead man switch) antes de ir pra produção, nenhum aqui é "só trocar o YAML".

argocd/foundation/dados/minio.yaml: resolvido em 2026-08-21, imagem trocada pro Silo (fork comunitário mantido pelo projeto Pigsty, drop-in, mesmo CLI/env vars/formato de dado). Investigação achou que este MinIO nunca teve uso real (.minio.sys só, zero bucket, nenhum consumidor no cluster referenciando as credenciais), então a troca foi direta, sem migração de dado. De quebra, resolveu os 9652 restarts históricos do pod antigo (erro crônico "drive /data offline", não reproduzido no Silo).
argocd/foundation/dados/mariadb.yaml: resolvido em 2026-08-21, migrado pro mariadb-operator (Helm, mesmo padrão de chart externo do Infisical). Sem import de dado (diferente do Postgres): investigação achou zero database de aplicação, só schemas de sistema, senha do root preservada via rootPasswordSecretKeyRef. Ver Foundation.
argocd/foundation/rabbitmq/deployment.yaml: resolvido em 2026-08-21. Achado urgente que motivou a migração: a imagem docker.io/bitnami/rabbitmq:3.12 não existe mais (docker pull retorna not found, confirmado ao vivo), o repositório docker.io/bitnami foi descontinuado e apagado em 2025. Mitigado de imediato trocando pra docker.io/bitnamilegacy/rabbitmq:3.12 (pinada por digest), depois migrado por completo pro RabbitMQ Cluster Operator oficial (argocd/foundation/rabbitmq-operator/, release manifest vendorizado v2.22.4, mesmo padrão do cert-manager/CNPG, sem Helm). RabbitmqCluster novo (argocd/foundation/ladesa-ro-production-rabbitmq-cluster/) com import nativo de definitions (rabbitmqctl export_definitions, senhas preservadas como password_hash, nunca em texto puro, segredo cifrado em infrastructure-vault). Achado não documentado em lugar nenhum: o startup probe padrão do operador (/api/health/checks/reached-target-cluster-size) só existe a partir do RabbitMQ 4.2.4, causando 404 permanente em qualquer versão anterior (inclusive 3.13); resolvido com a annotation rabbitmq.com/legacy-startup-probe: "true", documentada oficialmente pra esse cenário. Cutover de produção feito trocando o selector de rabbitmq-amqp/rabbitmq-web pro novo pod (kubectl patch, sem Argo CD, mesma cautela do Postgres/MariaDB) e reconectando os consumidores reais (managements-service, timetable-generator-dev) com rabbitmqctl close_all_connections no broker antigo, verificado ao vivo (rabbitmqctl list_connections) antes e depois. Application do cluster promovida pra automated. Legado removido em 2026-08-24: o Deployment/PVC/Service antigos (argocd/apps/messaging/rabbitmq/) foram apagados junto do desligamento completo do RabbitMQ, depois de confirmar zero conexões e zero consumidores ao vivo (ver Desligar o RabbitMQ).
argocd/foundation/cert-manager/cert-manager-v1.16.2.yaml: resolvido em 2026-08-21, atualizado pra v1.21.1 (release estável mais recente na data), ver Foundation. Sobrou lixo inofensivo: a v1.21 removeu o Role/RoleBinding cert-manager-tokenrequest (RBAC de um recurso que este cluster nunca usou, nenhum Issuer/ClusterIssuer referencia serviceAccountRef), Argo CD sinalizou como requires pruning mas o argocd app sync --prune foi bloqueado pelo classificador de modo automático desta sessão. Os dois objetos continuam no cluster, sem efeito nenhum (não concedem nada que algo use); remover é seguro quando alguém rodar argocd app sync foundation-cert-manager --prune manualmente.
argocd/foundation/redis/deployment.yaml: avaliado em 2026-08-21, decisão: manter single instance, sem operador. Investigação ao vivo (CLIENT LIST no broker, nomes de fila decodificados de base64) achou que este Redis não é só cache: é o backend de fila do BullMQ usado internamente pelo Infisical (23 conexões ativas, filas como secret-rotation, dynamic-secret-revocation, audit-log, ca-crl-rotation, secret-full-repo-scan, entre outras, todas do mesmo cliente). Isso mudaria a decisão se não houvesse persistência, mas appendonly yes (AOF) já está ativo e a PVC (redis-pvc, 5Gi, local-path) já sobrevive a um restart de pod sem perda (1856 chaves confirmadas ao vivo), então o requisito real de durabilidade já está atendido pela configuração atual, HA/Sentinel/Cluster não é necessário pra esse risco específico. Achado à parte, sem urgência: a imagem é bitnami/redis sem tag (latest implícito, ainda puxável e atualizado há poucos dias, diferente do caso do RabbitMQ), o que é reprodutibilidade ruim (atualização silenciosa a cada restart de pod) mas não indisponibilidade iminente; pinar numa versão+digest específicos fica como item de robustez, não como bloqueio.
argocd/foundation/dados/adminer.yaml: ferramenta de debug simples, não precisava de operador. securityContext já resolvido (ver acima), Ingress com TLS real trazido pro git também (ver "Segurança do próprio Argo CD" acima).

Débito técnico: organização de pastas e arquivos em `argocd/`¶

Levantado em 2026-08-21, a pedido explícito do usuário ("analise outros débitos técnicos e registre, seja criativo e meticuloso"). Nada aqui quebra nada hoje, é dívida de legibilidade/manutenção, mas com o repositório crescendo (14 Application já em argocd/applications/) fica mais caro de corrigir quanto mais tempo passar.

Recursos vivos que o git não declara, levantados em 2026-08-21¶

Varredura feita no fim da migração do management-service, cruzando todo Deployment, StatefulSet, DaemonSet, Ingress, Service, CronJob e PersistentVolumeClaim do cluster contra a anotação argocd.argoproj.io/tracking-id. O que aparece aqui é o que sobrou fora do Argo CD depois de três repositórios migrados.

rabbitmq-ingress, no namespace ladesa-ro-production, existia só no cluster: resolvido em 2026-08-24, removido junto do resto do RabbitMQ (ver Desligar o RabbitMQ). Nunca esteve em argocd/, então não havia o que declarar, só apagar (kubectl delete ingress rabbitmq-ingress -n ladesa-ro-production).
Seis Secret de release Helm órfãos, resquício de instalação imperativa que o Argo CD já substituiu. Três vieram das migrações de 2026-08-21 (ladesa-ro-api, ladesa-ro-waha e ladesa-ro-docs, em ladesa-ro-development) e três são anteriores (portainer, infisical e secrets-operator-1735177689, este no namespace default). O Argo CD renderiza chart com helm template e não cria Secret de release, então nenhum deles tem dono: são histórico de um helm install que ninguém mais consulta, ocupando espaço no etcd e confundindo quem rodar helm list. O do ladesa-ro-sso já foi removido na migração do piloto, e serve de referência do que fazer com os outros. Não são urgentes nem perigosos, mas apagar um Secret de release é ação destrutiva e fica pra decisão explícita. Ficam de fora desta lista, por serem legítimos, o release do argocd (instalado pelo role de bootstrap) e os do traefik/traefik-crd (geridos pelo próprio k3s via HelmChart).
A instalação do próprio Argo CD não é gerida pelo Argo CD: os quatro Deployment, o StatefulSet do application-controller e o Ingress do argocd-server não carregam anotação de rastreio. É deliberado, o role argocd_bootstrap é quem instala, e auto-gestão traria o risco clássico de o Argo CD se derrubar num sync ruim e não ter como se levantar. Registrado aqui só pra que a ausência apareça como decisão e não como lacuna.

Não são achado: o StatefulSet mariadb do namespace dados e o rabbitmq-server de ladesa-ro-production nascem de CR de operador (MariaDB e RabbitmqCluster), e esses CR estão rastreados, então a cadeia de posse fecha. Os dois PersistentVolumeClaim do management-service estão fora de propósito, motivo documentado em Repositórios satélite.

Auditoria de `syncPolicy.automated`, 2026-08-21¶

Levantado a pedido do usuário ("o que mais não está automatizado ou idempotente, exigindo intervenção manual, e por que não está mapeado em pendências"). Das 14 Application, 7 estavam Manual sem razão documentada por trás da escolha (herdada, não decisão deliberada por app). Auditoria rodada com argocd app diff --core --hard-refresh duas vezes por app (pra pegar campo que muda a cada render, não só drift real) e, pras que usam chart remoto (histórico de diff pouco confiável nesse cenário, ver "O padrão app-of-apps"), conferência direta via kubectl get contra o valor esperado, independente da ferramenta.

dados, portainer, redis, secrets-operator: resolvido em 2026-08-21, promovidas pra automated: {prune: true, selfHeal: true}. Diff vazio nas duas rodadas, sem recurso órfão ao vivo (kubectl get all conferido por namespace), sem recriação depois do sync (idade de todo Deployment inalterada).
infisical tinha um bloqueio técnico real pra virar automated: resolvido em 2026-08-21. O chart infisical-standalone (templates/infisical.yaml, confirmado no fonte do chart) calcula os campos metadata.annotations.updatedAt e spec.template.metadata.annotations.updatedAt do Deployment com {{ now | date ... }}, timestamp do momento do render, deliberado no chart pra forçar rollout a cada helm upgrade. Cada argocd app diff produzia um valor "desejado" novo, nunca igual ao anterior (confirmado rodando duas vezes seguidas). Corrigido com ignoreDifferences nos dois jsonPointers (argocd/applications/platform/infisical.yaml). Verificado depois do deploy: diff estável nas duas rodadas seguintes (resíduo cosmético annotations: {}, mas Sync Status: Synced, não conta mais como drift). automated: {prune: true, selfHeal: true} ligado depois, confirmado Auto-Prune/Synced/Healthy, sem recriar o pod estável.
Achado à parte, no meio dessa verificação: o Deployment do Infisical estava com um rollout travado havia 2h13 (ReplicaSet novo Pending por Insufficient memory no node), causado por 3 syncs manuais nesta Application feitos por terceiro (argocd app history mostra 3 entradas hoje, 12:01/12:03/13:08 UTC; nenhum deles rodado nesta sessão, que só usou argocd app diff). Não derrubou o serviço (o pod antigo continuou Running/servindo, RollingUpdate nunca remove a versão antiga até a nova ficar pronta), mas nunca teria se resolvido sozinho, dado que o node não tem memória sobrando (mesmo achado já registrado em "Node sem folga de memória"). Corrigido com kubectl rollout undo --to-revision=<estável> (revisão-alvo confirmada antes via kubectl rollout history, não um undo cego de um passo só: o primeiro undo sem --to-revision voltou pra outra revisão também travada). Confirmado depois: 1/1 Running, rollout status successfully rolled out, site respondendo 200.
cert-manager-tokenrequest (Role+RoleBinding) órfão ao vivo em cert-manager: resolvido em 2026-08-21, removido do cluster (kubectl delete, backup salvo em /root/cert-manager-tokenrequest-backup.yaml no node). Investigação completa antes de remover: release notes oficiais do cert-manager v1.21.0 confirmam que esse RBAC foi removido oficialmente (adicionado no v1.16, motivado por um caso de uso de Route53 removido da documentação em 2024, só afeta quem usa o padrão não documentado serviceAccountRef.name apontando pro SA do controller). Confirmado que o ClusterIssuer deste cluster usa http01/Traefik, não Route53/Vault, não depende desse padrão. Confirmado também no próprio histórico deste repositório (git show 1b2b04b^:.../cert-manager-v1.16.2.yaml) que o manifesto vendorizado anterior criava esse RBAC e o bump pra v1.21.1 (mesma sessão) parou de declará-lo. Não é recurso de origem desconhecida, é sobra esperada do upgrade. argocd app diff no foundation-cert-manager veio vazio depois da remoção, cert-manager continuou 1/1 Running nos 3 pods, todos os Certificate do cluster seguiram Ready: True.
secrets-operator (pod default/secrets-operato-controller-manager-*) tinha histórico de milhares de restart: resolvido em 2026-08-21. Causa confirmada nos logs: o operador (baseado em controller-runtime) derrubava o próprio processo de propósito quando perdia a lease de liderança (dial tcp 10.43.0.1:443: connection refused, falha de leader election), padrão comum desses operadores em blip da API do k3s (reinício de node, upgrade, churn de CRD), não bug do Infisical. Investigado mais a fundo: controllerManager.replicas deste chart é fixo em 1 (helm show values infisical/secrets-operator), então não existe cenário de HA real que justifique leader election, a flag só existia pra proteger uma disputa entre réplicas que nunca acontece aqui. Corrigido sobrescrevendo controllerManager.manager.args no values da Application (argocd/applications/operators/secrets-operator.yaml) sem --leader-elect, removendo a classe de crash por completo (não é mitigação de timeout, é eliminação da causa). Risco aceito e documentado: se replicas for aumentado no futuro sem restaurar --leader-elect, duas réplicas processariam os mesmos recursos sem coordenação. Não é o caso hoje, e mudar replicas exigiria edição consciente do mesmo values. Verificado ao vivo: rollout limpo (pod novo 2/2 Running, 0 restarts), args confirmados sem a flag, logs mostrando reconciliação normal de todo InfisicalSecret, argocd app diff vazio.
rabbitmq (Deployment legado, ocioso) e cert-manager promovidos pra automated: resolvido em 2026-08-21. rabbitmq com prune: true (diff limpo em duas rodadas, zero risco real). cert-manager com prune: false (mesma mitigação do dados-mariadb/CNPG, chart não declara Namespace). Das 15 Application (14 + root), só root continua Manual, decisão permanente, não pendência (ver acima, "único gate humano antes de qualquer edição em argocd/applications/ virar mudança real").

Trabalho inicial da organização, ainda não retomado¶

Registrado em 2026-08-21: o objetivo original desta sessão, antes de focar em CI/qualidade do infrastructure, era um conjunto de mudanças maiores, que tocam mais de um repositório da organização. Investigação inicial (só leitura, nenhuma mudança feita ainda) registrada abaixo item por item:

Arquivar repositórios não usados da organização ladesa-ro no GitHub. Três saíram em 2026-08-21 junto da aposentadoria do gerador de horário (arquivado-timetable-generator, arquivado-messages, arquivado-protobufs), depois de conferir quem os referenciava. Falta levantar o resto (arquivar é reversível, mas ainda merece uma lista explícita, não um chute). Atenção a um efeito colateral do rename: o docs linka o antigo ladesa-ro/messages em três páginas publicadas e o management-service o referencia num script, e os dois seguem funcionando só por redirecionamento do GitHub, exatamente o estado que este documento já critica no item do arquivado-esteira-ci-cd.
Migrar a geração de horário e os arquivos .proto pro management-service: em andamento, não commitado. O management-service está na branch feat/timetable-generator-proto, com src/infrastructure.timetable-generator/proto/ inteiro não rastreado pelo git. O contrato .proto do serviço timetable-generator-v1 veio do repositório protobufs, e proto/.commands/generate builda um container fixado por versão (protoc + ts-proto) que gera TypeScript em proto/generated/ e C# em proto/generated-csharp/. A aposentadoria do serviço em 2026-08-21 (abaixo) resolveu a pendência do destino do C#, mas não tornando o generated-csharp descartável, e sim mudando o que ele é: em vez de um passo de sincronização com outro repositório, ele passa a ser parte do próprio monorepo, o lado C# do protocolo que o worker vai usar. O desenho alvo, definido pelo usuário, é monólito modular: a API conversa com um worker também em TypeScript, e esse worker executa o algoritmo C# como processo filho, mandando ServiceGenerateRequest serializado pelo stdin e lendo ServiceGenerateResponse do stdout. O .proto deixa de ser contrato entre serviços em rede e vira contrato entre processos na mesma máquina, o que ele já suporta sem mudança nenhuma: o arquivo não declara bloco service, só mensagens, e a delimitação fica por conta do EOF, uma mensagem por invocação. Continua valendo a pendência de declarar @bufbuild/protobuf como dependência real, já que hoje só o código gerado o importa em runtime, e some-se a ela a equivalente do outro lado, Google.Protobuf no projeto C# que compilar as classes geradas. Some-se a isso o que a varredura de 2026-08-21 achou: nada em src/ importa proto/generated/ nem o messages/schemas.ts, e o alvo nx codegen:timetable-generator:fresh aponta pra messages/commands/generate quando a pasta real é messages/.commands/, ou seja, está quebrado desde que foi escrito e ninguém percebeu porque ninguém o roda.
Aposentar o gerador de horário como serviço à parte: feito em 2026-08-21. Os três Deployment (ladesa-ro-timetable-api, ladesa-ro-timetable-generator, ladesa-ro-timetable-worker), os dois Service e o InfisicalSecret que produzia o config foram removidos do cluster, e os repositórios timetable-generator, messages e protobufs foram renomeados com o prefixo da convenção e arquivados. A decisão se apoiou em evidência colhida antes de apagar: as três filas de horário estavam zeradas, sem DLQ acumulada, nenhum Ingress público apontava pros serviços, e os logs dos três pods não mostravam nenhum processamento real, só health check. O achado que fechou a questão é que o ciclo já estava quebrado de qualquer jeito: o message-broker-subscribe.service.ts do management-service está inteiramente comentado, então a resposta que o gerador publicava em dev.timetable_generate.response nunca era lida por ninguém. Backup dos manifestos foi tirado antes da remoção, e o config não precisou de cópia porque o Infisical é a fonte. Sobra o usuário timetable-generator-dev no RabbitMQ, agora sem uso, deixado de propósito para não mexer no broker no mesmo passo.
Desligar o RabbitMQ: resolvido em 2026-08-24. A condição registrada em 2026-08-21, a folha de ponto deixar de depender do broker, foi atendida: o management-service migrou toda a mensageria (geração de horário e notificação de folha de ponto por WhatsApp, incluindo a fila folha_ponto.notificacao.whatsapp) para BullMQ sobre o próprio PostgreSQL da aplicação, sem broker externo. Confirmado ao vivo antes de remover: rabbitmqctl list_connections zerado (o pod antigo da API, rodando código anterior à migração por causa do achado em GitOps com tag mutável, ainda tinha 2 conexões abertas, resolvido reiniciando o deployment) e rabbitmqctl list_queues com zero mensagens/consumidores em todas as filas, inclusive as de horário e de folha de ponto. Nenhum pod do cluster, em nenhum namespace, referenciava RabbitMQ em variável de ambiente além do próprio broker. Removidos do git e do cluster: as três Application (foundation-rabbitmq-operator, foundation-rabbitmq, foundation-ladesa-ro-production-rabbitmq-cluster), os manifests em argocd/apps/messaging/rabbitmq/, argocd/apps/messaging/rabbitmq-cluster/ e argocd/apps/operators/rabbitmq-operator/, o whitelist rabbitmq.com/RabbitmqCluster em argocd/root/project.yaml, a referência ao segredo de bootstrap em ansible/inventory/host_vars/ldsa.yml, e o rabbitmq-ingress órfão (ver acima).
A criação de folha de ponto quebra se o broker estiver fora, e deixa estado inconsistente, achado em 2026-08-21 ao investigar se o RabbitMQ podia ser desligado. Em folha-ponto-create.command.handler.ts o await messageBrokerService.publishFolhaPontoCreated(payload) acontece depois de a folha já estar gravada no banco e antes do retorno, sem try. Como getBroker() lança ServiceUnavailableError quando não há conexão, uma indisponibilidade do broker faz o endpoint responder erro para um registro que já foi persistido: quem chamou entende que falhou, o banco entende que deu certo. Não é hipótese: o próprio broker caiu por dois minutos em 2026-08-21 às 23:29, e a API sobreviveu justamente porque a conexão é reestabelecida em laço com backoff, mas qualquer folha criada naquela janela teria caído nesse caminho. A publicação é notificação, não parte da transação, então o tratamento adequado é não deixar a falha dela derrubar a resposta. Some-se que a fila folha_ponto.notificacao.whatsapp está com zero consumidores, porque o serviço de assinatura do management-service está inteiramente comentado, ou seja, hoje a mensagem é publicada e nunca lida.
Padronizar o deployment com Argo CD nos repositórios restantes da organização, substituindo o push imperativo do chart application (Stakater) por uma pasta gitops. Confirmado em 2026-08-21, não é só o management-service: ladesa-ro/authentication-service (SSO) e ladesa-ro/docs também usam o mesmo padrão imperativo (helm upgrade -i --repo https://stakater.github.io/stakater-charts application, disparado direto por .github/workflows/build-deploy*.yml, sem GitOps, sem syncPolicy, sem histórico de reconciliação), achado ao investigar por que dois serviços da organização não tinham TLS (ver "Segurança do próprio Argo CD" acima). O authentication-service é o caso mais extremo, o values de produção nem fica num arquivo do repositório, é uma variável de ambiente do GitHub (DEPLOY_HELM_VALUES), editável só pela UI, sem PR nem histórico de revisão nenhum. Esse item e o Débito técnico: organização de pastas e arquivos em argocd/ acima andam juntos: a convenção gitops/applications/<categoria>/ + gitops/apps/<categoria>/<app>/ é a mesma pensada pros dois, e o próprio infrastructure.git já tem agora um precedente vivo de chart Helm local funcionando (argocd/apps/data/dados-postgres-cluster/, argocd/apps/messaging/rabbitmq-cluster/, resolvido em 2026-08-21), referência concreta pra quando esses repositórios satélite adotarem o mesmo padrão. argocd/apps//argocd/foundation/ deste repositório renomeados pra argocd/applications//argocd/apps/ também em 2026-08-21, batendo com o nome exato usado aqui (gitops/applications/+gitops/apps/). A convenção de referência já validada em produção noutro contexto, a seguir aqui: Piloto concluído em 2026-08-21 com o authentication-service, seguindo o padrão de três camadas documentado em Repositórios satélite e inspirado numa implementação de referência que já rodava noutro projeto. Depois do piloto migraram o docs e o management-service (este com duas Application, ladesa-ro-api e ladesa-ro-waha, porque são dois releases Helm distintos), ambos com diff vazio na adoção. web fechou o backlog em 2026-08-22, o único que exigiu apagar e recriar em vez de update in-place: usava manifesto cru com spec.selector na forma {app: ladesa-ro-web}, o chart do Stakater rotula por app.kubernetes.io/name, e spec.selector de Deployment é imutável (mesmo achado já registrado na migração do Redis, ver Aprender: Argo CD). Deployment e Ingress antigos apagados de propósito antes do primeiro sync, cutover confirmado com o site real respondendo. Os quatro repositórios de time (authentication-service, docs, management-service, web) estão sob Argo CD agora, o runner self-hosted dev-deploy perdeu o último consumidor e foi desligado (ver logo abaixo). O timetable-generator saiu da conta em 2026-08-21 por ter sido aposentado, não migrado.
Uma pasta gitops/ (não argocd/), com duas subpastas: gitops/applications/, só manifests Application/AppProject do Argo CD, organizados por categoria (ex.: business/, monitoring/, operators/, security/, system/, mais projects/ pros AppProject); e gitops/apps/, os charts Helm e values de verdade que cada Application aponta, no mesmo esquema de categoria.
Um app-of-apps por cluster de destino, não uma lista mantida à mão: uma única Application raiz com source.path: gitops/applications e directory: {recurse: true}, deixando o próprio Argo CD descobrir todo Application/AppProject aninhado, ao contrário do argocd/applications/ atual deste repositório (uma Application por arquivo, listada manualmente).
Pra um repositório de serviço único (o caso do management-service): gitops/apps/<serviço>/ vira um chart Helm próprio, local, que declara o chart application do Stakater como dependência (uma instância aliased por processo, quando o serviço tem mais de um, por exemplo API mais worker mais job de migração), acrescentando só os templates que o chart genérico não cobre (HTTPRoute, secret do Infisical). gitops/envs/<ambiente>/applications/<serviço>.yaml é a Application de fato, com values-<ambiente>.yaml e syncPolicy.automated: {prune: true, selfHeal: true}, substituindo o helm upgrade -i disparado por CI por reconciliação pull-based de verdade.
Falta decidir, quando este item for retomado, o que exatamente muda na estrutura atual deste repositório (argocd/applications/, argocd/apps/, argocd/root/) pra adotar esse mesmo esquema de categoria, e se o infrastructure também ganha uma pasta gitops/ própria ou se a mudança de nome fica só nos repositórios de serviço individual.

GitOps com tag mutável não reinicia o pod sozinho, achado real em 2026-08-22¶

docs e management-service já adotaram o padrão gitops/ descrito em Trabalho inicial da organização, ainda não retomado acima, cada um com sua própria Application reconciliada automaticamente (syncPolicy.automated: {prune: true, selfHeal: true}). Achado ao verificar uma migração de conteúdo no ladesa-ro/docs: depois do merge, o workflow [DEV] Build & Push completou com sucesso, publicando uma imagem nova em ghcr.io/ladesa-ro/docs/docs:development, mas o site em docs.ladesa.com.br continuou servindo o conteúdo antigo (confirmado com cache-busting, não é cache de CDN/navegador).

Causa: gitops/apps/docs/values-development.yaml usa pullPolicy: Always com uma tag mutável (tag: development). pullPolicy: Always só força um novo pull quando o pod é (re)criado, não reinicia sozinho um pod que já está rodando só porque o conteúdo da imagem no registry mudou. O Argo CD não detecta isso como diff nenhum (a string da tag continua development, igual antes e depois), então selfHeal não dispara. O mesmo padrão (pullPolicy: Always + tag mutável development, sem mecanismo de restart) existe em gitops/apps/api/values-development.yaml do management-service, mesma classe de risco, não confirmado ao vivo ainda.

Confirmar se management-service tem o mesmo problema: confirmado em 2026-08-24, ao acompanhar o deploy da migração de mensageria. O pod ladesa-ro-api continuava rodando há 2 dias e 22 horas depois do merge e da imagem :development nova já publicada, só a imagem do timetable-worker (Deployment novo, criado do zero, sem pod anterior pra comparar) atualizou sozinha. kubectl rollout restart deployment/ladesa-ro-api -n ladesa-ro-development manual foi necessário pra pod novo pegar o código migrado.
Decidir o mecanismo de correção: resolvido em 2026-08-28. Levantamento completo das opções (tag/digest imutável via CI, Argo CD Image Updater, Kargo, Argo Rollouts) e a decisão tomada, digest sha256 computado pelo build e promovido via PR automático (GITHUB_TOKEN, sem PAT dedicado), estão registrados em Rollout de imagens, incluindo a seção de hardening futuro (quando reavaliar Image Updater e Kargo).
Implementado em docs e management-service: .github/workflows/build-push.dev.yml dos dois repositórios ganhou um step que resolve o digest da imagem publicada e abre (ou atualiza, se já existir) um PR trocando tag: development por digest: sha256:... no values-development.yaml correspondente, branch fixa por satélite, sempre reaproveitando o mesmo PR em vez de acumular um por push. web e authentication-service ainda não migraram: mesmo padrão a replicar, o authentication-service já tem um promote.yml parcialmente pronto pra esse exato mecanismo (nunca confirmado se funciona), vale reaproveitar antes de escrever do zero.
Enquanto web/authentication-service não migram, o restart depois de um build novo continua manual nesses dois: kubectl rollout restart deployment/<nome> -n <namespace> (ou equivalente via argocd app actions run <app> restart).

Versões desatualizadas das ferramentas de bootstrap¶

Levantado em 2026-08-21, contra o que está fixado em ansible/inventory/host_vars/ldsa.yml. Ordem deliberada: upgrade de versão só depois de todo o resto ao redor já modernizado e validado (os itens acima), nunca como primeiro passo, e sempre com o mesmo processo de contingência já usado na migração do Postgres (cluster/ambiente descartável, dead man switch, backup confirmado antes de aplicar em produção).

k3s: resolvido em 2026-08-21, atualizado de v1.33.3+k3s1 pra v1.36.3+k3s1 (salto direto, changelog das três linhas 1.34/1.35/1.36 conferido, nenhuma mudança de ruptura afeta este cluster: o único aviso real, renomeação do provider kubernetesIngressNginx pra kubernetesIngressNGINX no Traefik, só importa pra quem customiza esse HelmChartConfig, que não é o nosso caso, só usamos ingressClassName: traefik). Backup do datastore sqlite feito antes (systemctl stop k3s, cp -a /var/lib/rancher/k3s/server/db, systemctl start k3s, ~529MB, em /root/k3s-upgrade-backup/) por não existir sqlite3 CLI no node pra um backup online. Achado colateral, não é bug do k3s: o reinstall regenerou /etc/rancher/k3s/k3s.yaml do zero, o que apagou um namespace: argocd que estava setado no contexto do kubectl (usado pelo argocd ... --core), causando configmap "argocd-cm" not found até kubectl config set-context --current --namespace=argocd ser refeito.
Helm: resolvido em 2026-08-21, atualizado de v3.18.6 pra v4.2.4. Reavaliado o risco depois de checar o uso real: só roda um helm upgrade --install argocd ... --version ... --values -, sem --atomic/--force/post-renderer/plugin (as únicas coisas que quebram de v3 pra v4), e os outros charts do cluster (Infisical, mariadb-operator) são renderizados pelo Argo CD internamente, não pelo binário helm do node. Formato de release no cluster não mudou, helm list -n argocd seguiu enxergando a release criada em v3 sem migração nenhuma. Suporte de segurança do v3 acaba em 2026-11-11, motivo real pra não adiar demais.
Argo CD (chart argo/argo-cd): resolvido em 2026-08-21, atualizado de 10.3.3 pra 10.4.0. Risco confirmado baixo antes de aplicar: mesma versão do app (v3.5.1), diff do chart só adiciona uma opção de VPA recommender opcional que não usamos. Rollout limpo, todos os pods do argocd saudáveis depois.
secrets-operator (Infisical): resolvido em 2026-08-28, atualizado de 0.8.0 pra 0.11.8. O sidecar kubeRbacProxy foi removido entre as versões, metrics passou a bind direto com RBAC embutido no manager; override manual de args (apontava pro modelo antigo) removido, chart usa o default novo.
Postgres engine (CNPG): resolvido em 2026-08-28, atualizado de 18.0 pra 18.6 (6 patches). instances: 1 neste cluster, sem réplica: o restart do pod primário causou breve indisponibilidade real do banco (Keycloak perdeu conexão por ~1 minuto durante a janela), esperado e sem dado perdido, cluster confirmado Ready logo depois.
Portainer: resolvido em 2026-08-28, chart 1.0.59 pra 245.0.0, imagem EE 2.21.5 pra 2.45.0. Schema de image/service/ingress idêntico entre as versões, só features novas opcionais adicionadas.
Infisical platform (infisical-standalone): resolvido em 2026-08-28, imagem v0.99.0-postgres pra v0.164.1 (~65 minors). Achado ao vivo: o pod novo ficou preso em Init:Error, causa era um initContainer órfão (migration-init, imagem k8s-wait-for) deixado por um helm install manual anterior ao Argo CD assumir o release, nunca limpo porque o Server-Side Apply do Argo CD só reivindica campos que ele mesmo define, nunca remove campo de outro field manager. Corrigido removendo o campo direto (kubectl patch ... --type=json, remove em spec.template.spec.initContainers). Login e InfisicalSecret confirmados sincronizando depois.

Trocar de CNI, considerar depois¶

Registrado em 2026-08-21, ligado a um achado em aberto da "Revisão de segurança" acima, descrito no inventário privado. O mecanismo, que é genérico e vale pra qualquer cluster k3s, está em Aprender: firewalld: o firewalld não consegue restringir o tráfego que chega no Traefik via hostPort (chain FORWARD, dominada pelo kube-router, sem solução oficial do k3s pra isso). Uma opção que pode resolver de vez, ainda não avaliada a fundo: adotar Cilium (ou CNI equivalente com enforcement próprio) no lugar do flannel + kube-router atuais. Cilium substitui o kube-proxy/kube-router por um dataplane eBPF próprio e tem features dedicadas exatamente pra esse cenário (CiliumClusterwideNetworkPolicy com host firewall, toEntities: host, controle de tráfego que entra via NodePort/LoadBalancer antes mesmo de virar Service), então não compete com nada por ordem de chain iptables do jeito que o firewalld compete hoje.

Nada disso foi pesquisado a fundo ainda (versão compatível com k3s v1.36.3+k3s1, esforço de migração do flannel existente, se dá pra trocar sem downtime, se resolve mesmo o caso específico de hostPort do svclb-traefik ou só de NodePort/LoadBalancer normal). Trocar de CNI num cluster de produção de nó único é uma mudança de alto risco (rede inteira do cluster depende disso), mesmo cuidado de sempre antes de tocar (pesquisa dedicada, cluster/ambiente descartável se possível, dead man switch). Não é pra fazer sem esse processo completo.

Importação do estado do node pro Ansible, primeira leva¶

Registrado em 2026-08-21. É a contraparte de "Mapear operação de rotina/manutenção pro Ansible" abaixo, e as duas não são a mesma coisa: aquela é sobre transformar procedimento em código, esta é sobre trazer pro git o estado que já existe no node desde antes deste repositório. Esta pode andar antes porque não depende do backlog de argocd/ estar resolvido, o estado do sistema operacional não muda quando a organização de pastas do Argo CD muda.

Os roles pacotes-base e sistema são a primeira leva. O que ficou deliberadamente em aberto:

Débito editorial: log de incidente dentro de Aprender¶

Registrado em 2026-08-21. aprender/index.md declara que a seção ensina conceitos "de forma geral, sem depender de nenhuma decisão específica de nenhum projeto", e Diátaxis reforça que fato específico de um cluster real pertence a Arquitetura, não a Explicação. Na prática aprender/argocd.md tem seis seções datadas de 2026-08-21 que são log de incidente deste cluster: o syncPolicy padronizado, a organização por categoria, o wrapper chart, a migração do cert-manager, o incidente do --prune com o CNPG, o rename de topo e a correção de causa raiz do Namespace.

Mover o log de incidente de aprender/argocd.md pra Arquitetura, deixando em Aprender só a lição genérica. Não é urgente e não é exposição, são lições de engenharia legítimas, só estão no lugar errado segundo a regra que o próprio repositório declara. Condição pra fechar: decidir se viram uma página nova em arquitetura/ ou se cada uma vai pro documento de arquitetura correspondente, e então mover preservando os links de entrada. O mesmo padrão já foi aplicado, em menor escala, ao tirar o achado de segurança dessas páginas.

Ferramentas e práticas candidatas, levantadas dos guias¶

Registrado em 2026-08-21, a outra metade do mesmo pedido que originou a seção de importação acima. Levantamento feito cruzando as páginas de Aprender com guias externos: o guia de hardening CIS do k3s, a documentação de segurança do GitHub Actions e do Argo CD, os princípios do OpenGitOps e o ferramental da OpenSSF.

Cada linha é candidato, não decisão tomada. Toda ferramenta nova passa antes pelos portões que este repositório já se impõe: licença conferida, versão fixada no hermit, release com no mínimo 7 dias, verbete no dicionário do cspell, e zero comentário nos arquivos de configuração. E todo check novo nasce não bloqueante, pela mesma regra que rege a seção de bypasses acima.

Mapear operação de rotina/manutenção pro Ansible, considerar por último¶

Registrado em 2026-08-21, pedido explícito do usuário, deliberadamente o último item da lista (depende do resto do backlog estar resolvido primeiro, senão mapeia procedimento que ainda vai mudar). Hoje o Ansible deste repositório (ansible/roles/: k3s, firewalld, vault_repo, argocd_bootstrap, self_pull_timer) cobre só o bootstrap (rodar uma vez, do zero até o cluster de pé, ver Bootstrap mínimo na VM). A contraparte de operação contínua não existe como código nenhum, é uma sequência de comando kubectl/ssh/argocd executada manualmente e documentada em prosa (quando documentada), não repetível de forma idempotente. Isso já está parcialmente reconhecido em "Rotina de operação contínua a criar" acima, mas aquela seção é sobre decidir onde a documentação mora; este item é sobre o que dessa operação vale a pena virar Ansible de verdade, não só prosa.

Candidatos reais, levantados só de olhar pro que já foi feito manualmente nesta sessão (lista de partida, não exaustiva, o próprio item pede uma análise antes de decidir o que entra):

Rotação de senha (Ansible Vault, deploy keys, roles do Postgres, segredos do Infisical): hoje cada rotação é uma sequência de comando ad-hoc no node (openssl, ansible-vault encrypt, kubectl pra reconciliar). Virar um role/playbook parametrizado (ansible-playbook rotacionar-segredo.yml -e alvo=postgres-role-x) reduziria o risco de esquecer um passo no meio de uma rotação sob pressão.
Backup de datastore antes de upgrade (o padrão usado pro sqlite do k3s nesta sessão: systemctl stop, cp -a, systemctl start): hoje é comando manual toda vez que alguém for atualizar o k3s. Virar uma task/role reaproveitável evita repetir o mesmo raciocínio (e o mesmo risco de esquecer um passo) na próxima atualização.
Sync do root/Application do Argo CD depois de um git pull: hoje é ssh + git pull --ff-only + argocd app sync root --core digitado à mão a cada mudança, com a pegadinha real já documentada (sincronizar root antes da Application filha, ver Aprender: Argo CD) dependendo de quem está operando lembrar na hora.
Sweep de saúde pós-mudança (kubectl get pods -A sem nada fora de Running/Completed, argocd app list --core tudo Synced/Healthy): repetido manualmente depois de cada sync nesta sessão inteira, candidato natural a virar um único comando/task, talvez até um health-check reaproveitado pelo item "Acompanhamento de saúde" já registrado acima.
Renovação/verificação do dead man switch (systemd-run --on-active=...): o padrão já é consistente entre os usos desta sessão (firewalld, RabbitMQ), mas cada vez foi escrito na mão no terminal; um role/template parametrizado (comando-de-revert, janela-de-tempo) reduziria a chance de errar a sintaxe do systemd-run numa hora de pressão real.

Por que só ao final: mapear procedimento operacional pro Ansible antes do resto do backlog estar resolvido significa documentar/automatizar um estado que ainda vai mudar (ex.: a reorganização de argocd/ muda o comando de sync; a auditoria de chart oficial muda o que existe pra fazer backup antes de tocar). Fazer isso por último evita reescrever o mesmo role duas vezes.

Mecanismo de rollout de imagens trocado de digest-via-PR pra Argo CD Image Updater, 2026-08-28¶

A correção registrada em "GitOps com tag mutável" foi implementada na mesma manhã como digest imutável + PR automático (GITHUB_TOKEN), e substituída na mesma tarde. Motivo: em docs e management-service, todo push em development, ambiente sem razão nenhuma pra exigir aprovação humana pra ver o próprio código rodando, passou a esperar alguém clicar em "Approve", por causa do ruleset de main que já existia antes desta correção, não introduzido por ela.

Mecanismo final: Argo CD Image Updater instalado como componente de foundation, aplicando a atualização direto na Application (write-back-method: argocd, sem commit, sem PR), com webhook do GHCR configurado pra reduzir o delay do polling padrão a segundos. Detalhe completo, incluindo a análise de segurança do endpoint exposto, em Rollout de imagens.

docs e management-service migrados: anotações na Application, ImageUpdater CR único cobrindo namePattern: "ladesa-ro-*". Confirmado ao vivo em 2026-08-28: application.deployment.image.digest aplicado via parâmetro Helm nos 3 satélites (docs, api, timetable-worker).
web migrado: mesmas anotações, PR web#790.
authentication-service ainda não migrado: mesmas anotações a replicar, nenhuma peça de infraestrutura nova necessária (o ImageUpdater CR já cobre qualquer satélite ladesa-ro-* novo).
Webhook de organização no GitHub ainda não criado: token gh local não tinha o escopo admin:org_hook; pedido de elevação (gh auth refresh -s admin:org_hook) expirou sem aprovação a tempo. Falta: aprovar o fluxo de dispositivo e rodar a criação do webhook (evento package, URL https://image-updater.ladesa.com.br/webhook?type=ghcr.io). Até lá, o Image Updater funciona só por polling (padrão do controller, tipicamente ~2min).
Webhook de organização criado: id 671516711, evento package, active: true.
Projeto foundation-image-updater-w0cw criado no Infisical, chave webhook.ghcr-secret registrada em prod.

Webhook do GitHub pro `argocd-server`, reduzindo o delay de `root`, 2026-08-28¶

Diferente do webhook do GHCR (que acorda o Image Updater), este é pro próprio argocd-server: reduz o delay do ciclo de polling padrão do Argo CD pra detectar mudanças em main do infrastructure (o que afeta principalmente o root, hoje sem automated.selfHeal reativo a webhook, só a polling).

root ganhou syncPolicy.automated: argocd/root/application.yaml, PR #7, mergeado e aplicado no cluster pelo self-pull-timer. root confirmado Synced/Healthy com automated.selfHeal ativo.
Webhook de organização no GitHub criado: evento push, URL https://argocd.ladesa.com.br/api/webhook.
Secret do webhook (webhook.github.secret em argocd-secret) aplicado no cluster: manifest cifrado em infrastructure-vault (secrets/k8s/argocd/webhook-github-secret.yaml), o self-pull-timer já reconciliou sozinho, chave confirmada presente em argocd-secret.

Image Updater estava instalado mas 100% inerte desde o PR #5, achado ao vivo em 2026-08-28¶

Achado ao investigar por que o Image Updater não estava atualizando docs/api/timetable-worker apesar das anotações e do PR #6 (fix de watch.namespaces) já mergeados: a Application foundation-image-updater estava presa em OutOfSync/Failed desde a instalação, erro resource argocd-image-updater.argoproj.io:ImageUpdater is not permitted in project ladesa. Causa: argocd/root/project.yaml nunca ganhou ImageUpdater no namespaceResourceWhitelist quando o componente foi instalado. O ImageUpdater CR nunca sincronizou, e o pod, apesar de Running, nunca aplicou o watch.namespaces=argocd do PR #6, log mostrando "Watching controller namespace only" desde o dia da instalação.

Corrigido: PR #10, namespaceResourceWhitelist liberado, aplicado direto no cluster (kubectl apply) pra desbloquear na hora. Application confirmada Synced, pod novo já loga "Watching specific namespaces" namespaces=argocd.
Anomalia resolvida, causa era outra: o diagnóstico anterior (controller "não listando" as 3 apps) estava errado, era o nível de log info escondendo as linhas de debug e mostrando só o resumo final, que por coincidência também dizia "3". Subindo pra log.level: debug de verdade (via values.yaml, PR #10) apareceu a causa real: "Image '...' seems not to be live in this application, skipping". Isso é um bug conhecido do próprio Argo CD (Application.status.summary.images vazio pra toda Application do cluster, não só as 3), argoproj/argo-cd#27861. Mitigado com a anotação <alias>.force-update: "true" em docs/api/timetable-worker/web (PRs docs#15, management-service#1101, web#790). Faltava ainda a tag explícita (:development) na anotação image-list, sem ela o update-strategy: digest não tem versão pra ancorar a resolução do digest, corrigido nos mesmos PRs. Detalhe completo em Rollout de imagens. log.level revertido pra info depois do diagnóstico (PR #10 já mergeada com o valor de debug; revertido em PR separada). Confirmado ao vivo funcionando de ponta a ponta pros 3 satélites (application.deployment.image.digest aplicado via parâmetro Helm).
AppProject ladesa perdeu o whitelist do ImageUpdater de novo, sem causa raiz confirmada: depois de corrigido pelo PR #10 e aplicado com sucesso pelo self-pull-timer (confirmado no log do ansible-pull às 15:31:46, diff aplicado corretamente), o campo sumiu de novo da AppProject viva por volta de 15:57, travando o foundation-image-updater de novo com o mesmo erro is not permitted in project ladesa. Investigado: sem segunda definição do AppProject em outro arquivo, sem redefinição via configs.projects no Helm values do Argo CD, sem outra execução do ansible-pull nesse intervalo. O histórico de managedFields que poderia mostrar quem escreveu por último foi apagado sem querer pelo próprio kubectl apply (client-side) usado pra corrigir na hora, tanto o meu quanto o do Ansible usam client-side apply, que sempre colapsa pra um único manager kubectl-client-side-apply. Corrigido de novo manualmente. Se acontecer de novo, capturar kubectl get appproject ladesa -o yaml (incluindo managedFields) antes de corrigir, pra não perder o rastro de novo.