MKA1 segue um modelo de implantação alinhado ao GitOps, onde o repositório Git é a fonte única da verdade para toda a infraestrutura e estado das aplicações. Cada implantação é uma transação atômica do Helm: se algum recurso não se tornar saudável, todo o release é revertido automaticamente, sem intervenção manual.Documentation Index
Fetch the complete documentation index at: https://docs.mka1.com/llms.txt
Use this file to discover all available pages before exploring further.
O que está ativo
Git como fonte única da verdade
Toda a plataforma MKA1 é definida como um único Helm chart (mka1-platform) armazenado no repositório Git infra-resources.
Nenhuma alteração chega ao cluster sem antes ser commitada e revisada via pull request.
- Helm chart e arquivos de valores definem todas as workloads, serviços, templates de segredos, HPA e PDB da plataforma.
- Overrides específicos por ambiente separam as configurações de staging e produção, compartilhando a mesma definição de chart.
- Segredos criptografados são gerenciados com SOPS e commitados junto com o chart, garantindo que até configurações sensíveis sejam rastreadas no histórico do Git.
Deploys atômicos com Helm
Os releases do Helm são executados com o parâmetro--atomic, que envolve toda a atualização em uma transação.
Se algum recurso do release falhar na verificação de prontidão, o Helm reverte automaticamente todo o release para a última revisão conhecida como estável.
--atomic— Se a atualização falhar em qualquer ponto, o Helm deleta os novos recursos e restaura o release anterior. O cluster nunca fica em um estado parcialmente implantado.--wait— O Helm espera que todos os Pods, Serviços e outros recursos estejam prontos antes de marcar o release como bem-sucedido.--timeout 15m— Um limite configurável impede que os deploys fiquem travados indefinidamente. Se a prontidão não for atingida dentro do tempo, o release é considerado falho e revertido.
Reconciliação automatizada via CI/CD
Workflows do GitHub Actions são acionados automaticamente a cada push nomain que modifica caminhos de infraestrutura.
O pipeline autentica com a AWS, configura o kubectl para o cluster EKS alvo e aplica o estado desejado definido no Git:
- Um desenvolvedor faz merge de um pull request no
main. - O GitHub Actions detecta a alteração e aciona o workflow de implantação.
- O workflow faz checkout do repositório no SHA do commit mesclado.
helm upgrade --install --atomicreconcilia o cluster para corresponder ao estado desejado definido no Git.- Se o estado desejado não puder ser alcançado, o rollback atômico garante que o cluster permaneça na última revisão bem-sucedida.
Histórico de deploys imutável
Cada release do Helm cria uma revisão versionada armazenada no cluster. Isso fornece uma trilha completa de auditoria do que foi implantado, quando e a partir de qual commit do Git.Como validamos
Validamos o fluxo GitOps inspecionando o estado do release Helm implantado e confirmando que ele corresponde à configuração definida no Git.main aciona um ciclo completo de reconciliação.
Se o estado do cluster divergir do estado desejado definido no Git, a próxima execução do pipeline corrige o desvio.