Introdução
Um processo manual e demorado era o principal gargalo de um cliente que operava exclusivamente na Oracle Cloud. Para cada novo cliente final, era necessário provisionar um ambiente completo de forma manual: redes, bancos Oracle e MySQL, aplicação Oracle APEX e APIs PHP e sem migrations. Com uma equipe enxuta, esse processo levava até 3 meses, sendo mais de 30 dias apenas com infraestrutura. Ele não tinha github e as aplicações eram instaladas a partir de um ZIP (isso mesmo) um arquivo ZIP em cada servidor toda vez que criava um ambiente novo, fazia tudo na mão.
Neste artigo, conto como implementamos uma arquitetura GitOps multi-cluster com Terraform, Kubernetes, ArgoCD e Oracle Operator, que reduziu o provisionamento de novos ambientes para 20 minutos, mantendo segurança, versionamento, escalabilidade e total automação.
Cenário anterior
- Infraestrutura provisionada manualmente.
- Sem uso de Git, CI/CD ou pipelines.
- Para cada cliente final:
- Instância separada de banco Oracle (com APEX)
- APIs PHP rodando em máquinas separadas
- Banco MySQL separado
- Processos repetitivos, com alto risco de erro humano e sem rastreabilidade.
- Time pequeno sobrecarregado, gerando atrasos e impossibilidade de escalar.
Arquitetura atual
🔷 Cluster HUB (Infraestrutura Central)
- ArgoCD (para App of Apps)
- Github for SCM and Workflows
- Terraform para criação da infra OCI.
- Grafana e Prometheus (observabilidade centralizada)
- Bitwarden Vault (gestão de segredos)
- Pritunl VPN (acesso seguro)
- Ingress NGINX
- Cert Manager
- External DNS
- External Secrets
🟢 Clusters UAT e PRD (Workloads por cliente)
- Aplicações por cliente isoladas via namespace e/ou NodeGroups
- Operadores e serviços compartilhados:
- Ingress NGINX
- Cert Manager
- Oracle Operator
- KEDA
- External DNS
- Prometheus
- Cada namespace contém:
- Aplicação Oracle APEX
- APIs PHP
- MySQL (quando necessário)
- Configurações personalizadas via Kustomize
- Regras de RBAC, quotas e secrets isolados
Blueprint GitOps
- GitHub é o source of truth.
- Cada cliente é provisionado em um namespace dedicado no cluster UAT e PRD.
- O ArgoCD, rodando no HUB, aplica os manifestos em cada cluster com base em blueprints.
- O uso de Kustomize permite modificar variáveis específicas por cliente.
- Todo provisionamento é feito via GitOps, com histórico e rollback garantidos.
Como funciona a entrega de um novo cliente?
- Um novo cliente é fechado pelo time comercial.
- Um novo namespace é criado via commit em repositório Git.
- O ArgoCD sincroniza os blueprints no cluster correto (UAT ou PRD).
- Oracle Operator cria o banco Oracle e configura o Oracle APEX automaticamente.
- APIs PHP e banco MySQL são criados com Helm/Kustomize.
- DNS, certificados SSL, segredos e regras de RBAC são aplicados.
- Em 20 minutos o ambiente está pronto e funcionando.
Resultados
| Métrica | Antes | Depois |
|---|---|---|
| Tempo de provisionamento | Até 3 meses | 20 minutos |
| Escalabilidade | Limitada | Automática |
| Segurança e rastreabilidade | Inexistente | Total com GitOps |
| Erros operacionais | Frequentes | Quase nulos |
| Visibilidade e monitoramento | Manual | Grafana/Prometheus/KEDA |
| Custo humano por entrega | Elevado | Quase nulo |
🎯 Vantagens
Reutilização de padrões: Um único modelo serve como base para múltiplos clientes.
Velocidade e previsibilidade: Tudo padronizado, validado e rastreável via Git.
Escalabilidade: Provisionar centenas de ambientes é questão de scripts e commits.
Segurança: RBAC, quotas e secrets configurados automaticamente.
Lições aprendidas
- Kubernetes pode funcionar muito bem com Oracle APEX com o uso correto de operadores.
- GitOps traz velocidade, previsibilidade e confiança no processo.
- Multi-cluster com Hub-and-Spoke ajuda a separar responsabilidades e reduzir risco.
- Ter um cluster HUB para ferramentas e clusters para workloads melhora a gestão de recursos.
Próximos passos
- CI para APIs PHP com testes e deploys contínuos.
- Portal de autoatendimento para novos ambientes.
- Monitoramento por tenant com dashboards dinâmicos.
🔍 Diagrama da Arquitetura
GitOps Approach com Blueprints
📘 O que são Blueprints em GitOps?
No seu projeto, Blueprints são modelos declarativos versionados que definem a estrutura de provisionamento de um cliente dentro do Kubernetes. Eles são armazenados em Git e utilizados como fonte de verdade pelo ArgoCD para criar namespaces, bancos de dados, aplicações e serviços — tudo sob demanda, de forma padronizada.
🧱 O papel dos Blueprints na arquitetura
Cada Blueprint inclui:
Estrutura de namespace (com labels, quotas, RBAC)
Manifests para aplicações (Oracle APEX, APIs PHP)
Definição de PVCs e limites de recursos
Configuração de bancos de dados via Oracle Operator e MySQL
Secrets e ConfigMaps necessários
Integração com Cert Manager, External DNS, KEDA etc.
Exemplo de organização:
clientes/
├── cliente-xpto/
│ ├── namespace.yaml
│ ├── apex-db.yaml
│ ├── php-api-deployment.yaml
│ ├── mysql-db.yaml
│ ├── ingress.yaml
│ ├── kustomization.yaml
🔁 Fluxo GitOps com Blueprints
Time comercial fecha com um novo cliente.
Time de operações clona o blueprint base e adapta o nome do cliente.
Um commit é feito no Git com o novo blueprint sob gitops/clientes/xpto/uat ou gitops/clientes/xpto/prd (esses são os overlays) que apontam para uma base com os objetos do k8s gitops/clientes/base/
O ArgoCD (que vive no cluster HUB) detecta o novo caminho e aplica o conteúdo no cluster correto (UAT ou PRD).
Em poucos minutos, o namespace, banco, aplicação e todos os recursos estão provisionados.
🎯 Vantagens
Reutilização de padrões: Um único modelo serve como base para múltiplos clientes.
Velocidade e previsibilidade: Tudo padronizado, validado e rastreável via Git.
Escalabilidade: Provisionar centenas de ambientes é questão de scripts e commits.
Segurança: RBAC, quotas e secrets configurados automaticamente.
Recursos
Oracle DB Operator
O OracleDB Operator é um operador Kubernetes de código aberto criado para facilitar o provisionamento, gerenciamento e operação de bancos de dados Oracle dentro de clusters Kubernetes, seguindo os padrões do modelo Kubernetes Operator Pattern.
Ele abstrai a complexidade da instalação e administração do Oracle Database, permitindo que você crie e gerencie instâncias de banco de dados Oracle diretamente a partir de manifests YAML versionados, como parte de um fluxo GitOps com ferramentas como ArgoCD e Kustomize.
https://github.com/oracle/oracle-database-operator
https://blogs.oracle.com/coretec/post/oracle-database-now-containernative
✅ Principais Funcionalidades
Provisionamento automático de Oracle Database:
Versões suportadas: Oracle 12c, 19c, 21c (depende da imagem base utilizada).
Instalação com persistência via PVC.
Pode ser configurado com parâmetros de memória, CPU e configurações avançadas.
Criação de usuários e schemas
Possibilidade de definir usuários padrão, senhas e permissões no próprio YAML.
Suporte a Oracle APEX
Automatiza a instalação e configuração do APEX como aplicação web embutida.
Backup e restore
O operator inclue suporte para agendar backups automatizados via cron.
Monitoramento e liveness/readiness probes
Exposição de métricas via Prometheus
🧩 Recursos Customizados (CRDs)
O Operator cria alguns CRDs (Custom Resource Definitions) como por exemplo:
apiVersion: db.oracle.com/v1alpha1
kind: OracleDatabase
metadata:
name: cliente-x-db
spec:
edition: "enterprise"
version: "19c"
apex:
enabled: true
adminPassword: "SenhaSuperSegura"
storage:
size: 50Gi
resources:
requests:
memory: "4Gi"
cpu: "2"
limits:
memory: "8Gi"
cpu: "4"
Esse YAML cria uma nova instância de Oracle DB com APEX habilitado, configurado automaticamente.
🔄 GitOps e ArgoCD
Integrar o OracleDB Operator com ArgoCD permite que:
A criação de novos bancos seja desencadeada por um commit Git.
A configuração dos bancos, APEX, usuários e permissões fiquem versionadas.
A infraestrutura de dados se beneficie de auditoria, rollback, CI/CD e reprodutibilidade.
🚀 Benefícios para Arquiteturas Multi-Tenant
Em arquiteturas como a sua (multi-tenant com namespaces por cliente), o OracleDB Operator permite:
Criar uma instância de banco para cada cliente isoladamente.
Controlar o ciclo de vida de cada banco via YAML.
Compartilhar o operador no cluster, mantendo instâncias separadas por namespace.
Reduzir drasticamente o tempo de entrega e o risco de erros humanos.
Blueprints Structure
gitops
├── applicationsets
│ ├── infrastructure
│ │ └── helm-addons
│ │ ├── airflow
│ │ ├── keda
│ │ ├── prometheus
│ │ ├── uptimerobot
│ │ └── vaultwarden
│ │ └── repo
│ ├── template
│ └── workloads
├── bootstrap
│ └── projects
└── kustomize
├── infrastructure
│ ├── cert-manager
│ │ ├── hub
│ │ ├── prd
│ │ └── uat
│ ├── cluster-addons
│ │ ├── prd
│ │ └── uat
│ ├── external-dns
│ │ ├── hub
│ │ ├── prd
│ │ └── uat
│ ├── grafana
│ ├── imc
│ ├── ingress-nginx
│ ├── operators
│ │ ├── mysql
│ │ └── oracledb
│ ├── prometheus
│ └── rabbitmq
└── workloads
├── base
│ ├── apex
│ ├── api-1
│ ├── api-2
│ └── xpto-scripts
│ └── backup-cli
└── environments
├── demo
│ ├── prd
│ └── uat
├── client-1
│ ├── prd
│ └── uat
├── client-2
│ ├── prd
│ └── uat
├── client-3
│ ├── prd
│ └── uat
└── test
└── uat
Customer environment Application Set Example
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
name: demo
spec:
goTemplate: true
goTemplateOptions: ["missingkey=error"]
generators:
- list:
elements:
- cluster: xpto-uat
url: "https://168.77.99.106:6443"
values:
project: xpto-uat
environment: uat
- cluster: xpto-prd
url: "https://144.23.199.200:6443"
values:
project: xpto-prd
environment: prd
template:
metadata:
name: "xpto-demo-{{.values.environment}}"
spec:
project: "{{.values.project}}"
sources:
- path: gitops/kustomize/workloads/environments/demo/{{.values.environment}}
repoURL: git@github.com:xpto/devops.git
targetRevision: HEAD
destination:
server: "{{.url}}"
namespace: demo
syncPolicy:
retry:
backoff:
duration: 5s
factor: 2
maxDuration: 3m0s
limit: 2
syncOptions:
- ApplyOutOfSyncOnly=false
- CreateNamespace=true
ArgoCD Prints
Se você curtiu esse conteúdo ou está pensando em migrar workloads para Kubernetes, me chama no LinkedIn 👋
Top comments (0)