rede5/infracloud
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
infracloud/inventcloud/invista/nexus/OCI-NETWORK-ANALYSIS.md
Tiago Ribeiro 7fd9fd0294 docs: atualiza OCI-NETWORK-ANALYSIS com double-check OCI CLI 2026-03-01 
- Confirma 3 DRG attachments: ATT-VCN-Shared, ATT-VCN-DEV, ATT-VCN-OKE-DEV
- Adiciona recursos em DEV (OKE>DEV): api-gateway-mfe-dev PUBLIC 147.15.97.158
- Corrige: api-gateway-nexus-dev em cmp-dev-nexus com 0 deployments
- Recomendação atualizada: usar gateway compartilhado VCN-DEV para MSs e MFEs

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
2026-03-01 18:24:34 -03:00

10 KiB
Raw Blame History

OCI - Análise de Rede e Compartments (DEV Nexus)

Data: 2026-02-25 | Responsável: Tiago Ribeiro Contexto: Análise realizada para suporte à geração de scripts Terraform via Resource Discovery (demanda: Ana Guadagnin)

1. Mapa de Compartments

Estrutura Confirmada

invistacloud (root)
├── cmp-top-invista
│   └── cmp-dev-inv
│       └── cmp-dev-nexus  ✅ ATIVO — recursos do ambiente DEV
│
└── OKE
    └── DEV                ← VCNs de rede ficam neste compartment
        └── cmp-dev-nexus  🗑️ DELETADO em 2026-02-25 (estava vazio)

Recursos em cmp-dev-nexus (cmp-top-invista > cmp-dev-inv)

Verificado via OCI CLI 2026-03-01

Recurso Nome Estado
OKE Cluster cls-dev-nexus ACTIVE — v1.34.1
OKE Cluster cls-dev-barramento ACTIVE — v1.34.1
OKE Cluster cls-dev-observabilidade ACTIVE — v1.34.1
Compute (workers) oke-* (9x VM.Standard.E4.Flex) RUNNING
Load Balancers 5x (OKE-managed) ACTIVE
API Gateway api-gateway-nexus-dev (10.6.0.123, PRIVATE) ACTIVE — 0 deployments

⚠️ api-gateway-nexus-dev existe e está ativo mas sem nenhum deployment/rota configurada. Hostname: dnqe6ufrommkqxtfp7k2ehrbmu.apigateway.sa-saopaulo-1.oci.customer-oci.com

Recursos em DEV (OKE > DEV)

Recurso Nome Estado
VCN vcn-oke (10.110.0.0/16) AVAILABLE — Terraform ✅
VCN vcn-oke (10.120.0.0/16) AVAILABLE — legado/orphan ⚠️
API Gateway api-gateway-mfe-dev (147.15.97.158, PUBLIC) ACTIVE — 1 deployment (mfe-user)
Object Storage mfe-shell-dev AVAILABLE

2. Rede — Situação Atual

VCNs em Uso

VCN CIDR Compartment Uso Gerenciada por
vcn-oke 10.110.0.0/16 OKE > DEV OKE clusters (DEV Nexus) Terraform (tf_oci_clusters)
VCN-DEV 10.6.0.0/16 cmp-dev-inv API Gateway + outros serviços Manual
vcn-oke 10.120.0.0/16 OKE > DEV Clusters legado dev-cls-1/2/3 Terraform

Subnets da vcn-oke (10.110.0.0/16) — VCN ativa dos clusters

Subnet CIDR Tipo Uso
sbn-workers-1 10.110.0.0/20 Pública OKE worker nodes
sbn-workers-2 10.110.16.0/20 Pública OKE worker nodes
sbn-workers-3 10.110.32.0/20 Pública OKE worker nodes
sbn-lb-1 10.110.128.0/20 Pública Load Balancers OKE
sbn-lb-2 10.110.144.0/20 Pública Load Balancers OKE
sbn-api-gateway 10.110.192.0/20 Privada Criada para API Gateway — não utilizada

Subnets da VCN-DEV (10.6.0.0/16)

Subnet CIDR Tipo Uso atual
SBNT-DEV 10.6.0.0/24 Privada API Gateway api-gateway-nexus-dev
SBNT-DEV-AUTOMATION 10.6.1.0/24 Privada Automação
SBNT-DEV-LB 10.6.3.0/24 Privada Load Balancer outros serviços

Topologia Atual (cross-VCN via DRG)

Internet
    │
    ▼
API Gateway (api-gateway-nexus-dev)
    │
    └── SBNT-DEV (10.6.0.0/24) ── VCN-DEV (10.6.0.0/16)
                                        │
                                       DRG ← comunicação cross-VCN
                                        │
                                   vcn-oke (10.110.0.0/16)
                                        │
                    ┌───────────────────┼───────────────────┐
                    │                   │                   │
              sbn-workers-1/2/3    sbn-lb-1/2        sbn-api-gateway
               (OKE nodes)        (LBs OKE)          (vazia / disponível)

3. Ações Realizadas em 2026-02-25

3.1 ✅ Compartment duplicado vazio — DELETADO

Problema: Existiam 2 compartments cmp-dev-nexus:

  • OKE > DEV > cmp-dev-nexus — vazio, sem uso, criado por ciclo anterior do Terraform
  • cmp-top-invista > cmp-dev-inv > cmp-dev-nexus — com todos os recursos ativos

Verificação: 0 VCNs, 0 instâncias, 0 clusters, 0 LBs, 0 API Gateways no vazio.

Ações:

  • Compartment vazio deletado via OCI CLI
    • OCID deletado: ocid1.compartment.oc1..aaaaaaaardqptx2truouyqtmj2awx5seh2rorh6xw4fszv2sqq7tmbohglnq
    • Status final OCI: DELETED (renomeado para cmp-dev-nexus.ebThJ41h)
  • Terraform corrigido: adicionado create_cluster_compartment = false em environments/dev/terraform.ci.tfvars
    • Repo: tf_oci_clusters | Commit: 5a127e3a | Branch: main
    • Motivo: evitar que o Terraform recrie o compartment automaticamente no próximo apply

3.2 ✅ 8 VCNs orphans — DELETADAS

Problema: 8 VCNs vcn-oke (10.110.0.0/16) abandonadas no compartment OKE > DEV, geradas por ciclos anteriores de create/destroy de clusters OKE sem destruição dos recursos de rede.

Verificação:

  • 0 VNICs / instâncias em todas
  • 0 DRG attachments em todas
  • Nenhuma no Terraform state atual → necessária exclusão manual

Recursos removidos (por VCN, x8):

Recurso Quantidade total
Subnets (sbn-workers-1/2/3, sbn-lb-1/2) 40
Route Tables (rt-public, rt-workers) 16
Security Lists (sl-lb, sl-workers) ~16
DHCP Options (dhcp-oke-dns) 8
Internet Gateways (igw-oke) 8
NAT Gateways (nat-oke) 8
Service Gateways (sgw-oke) 8
VCNs 8

4. Problema Pendente — Desalinhamento Arquitetural de Rede

Situação

O api-gateway-nexus-dev está em uma VCN diferente dos clusters OKE que ele serve:

Componente VCN Compartment
api-gateway-nexus-dev VCN-DEV (10.6.0.0/16) — subnet SBNT-DEV cmp-dev-inv
cls-dev-nexus / cls-dev-barramento / cls-dev-observabilidade vcn-oke (10.110.0.0/16) OKE > DEV

A comunicação entre API Gateway e OKE ocorre via DRG-Invista-Shared — as 3 VCNs têm DRG attachment confirmado via OCI CLI (2026-03-01):

Attachment VCN CIDR Compartment
ATT-VCN-Shared VCN-Shared 10.8.0.0/16 cmp-shared-inv
ATT-VCN-DEV VCN-DEV 10.6.0.0/16 cmp-dev-inv
ATT-VCN-OKE-DEV vcn-oke 10.110.0.0/16 OKE > DEV

Por que VCN-DEV não é adequada para OKE

Limitação Detalhe
Sem Internet Gateway Workers não conseguem puxar imagens de container
Sem NAT Gateway Sem egress para internet em subnets privadas
Subnets /24 muito pequenas 254 IPs por subnet — insuficiente para node pools + pods
Não gerenciada pelo Terraform Criada manualmente, sem padronização

5. Opções para Resolução

Opção A — Migrar API Gateway para vcn-oke ⭐ Recomendada

Mover o api-gateway-nexus-dev para a subnet sbn-api-gateway (10.110.192.0/20) que já existe dentro da vcn-oke — criada pelo Terraform especificamente para esse fim (enable_api_gateway_mfe = true).

Benefícios:

  • API Gateway e OKE na mesma VCN — comunicação direta sem DRG
  • sbn-api-gateway já provisionada e disponível
  • Alinha com a arquitetura gerenciada pelo Terraform
  • Reduz custo (sem tráfego cross-VCN pelo DRG)
  • Simplifica troubleshooting

Limitação: API Gateway no OCI não permite troca de subnet in-place — é necessário recriar.

Passos para migração:

  1. Criar novo API Gateway em sbn-api-gateway (vcn-oke) 
    oci api-gateway gateway create \
  --compartment-id "ocid1.compartment.oc1..aaaaaaaahycc62za6ikthlhauvarvbdixc7xpjjmcrame3cirhu2kz74ddma" \
  --display-name "api-gateway-nexus-dev" \
  --subnet-id "<ocid-sbn-api-gateway>" \
  --endpoint-type "PUBLIC"
  2. Reconfigurar todos os Deployments e Routes no novo gateway
  3. Atualizar DNS (Cloudflare) apontando para o novo endpoint hostname
  4. Validar funcionamento de todas as rotas
  5. Remover o gateway antigo (api-gateway-nexus-dev em VCN-DEV)

Referência subnet destino:

Nome: sbn-api-gateway
CIDR: 10.110.192.0/20
VCN:  vcn-oke (10.110.0.0/16) — compartment OKE > DEV

Opção B — Manter situação atual (DRG)

Manter API Gateway na VCN-DEV conectado via DRG à vcn-oke. Funcional, sem risco imediato.

Prós: Zero impacto — nenhuma mudança necessária Contras: Latência adicional via DRG, custo de tráfego inter-VCN, maior complexidade de troubleshooting

Opção C — Migrar toda a rede OKE para VCN-DEV ❌ Não recomendada

Recriar os clusters OKE usando a VCN-DEV como base.

Por que não: Exigiria adicionar IGW + NAT à VCN-DEV, expandir subnets para /20, recriar 3 clusters com downtime — alto risco e esforço sem benefício claro sobre a Opção A.

6. Recomendação Final (atualizada 2026-03-01)

Recomendação recebida: usar gateway compartilhado (VCN-DEV)

Foi recebida recomendação de NÃO criar um gateway dedicado em vcn-oke e sim usar o api-gateway-nexus-dev (gateway compartilhado na rede VCN-DEV) para ambos os fluxos — backend MSs e MFEs frontend.

Arquitetura alvo:

Internet → Cloudflare → LB Test_Crivo_Dev (VCN-Shared)
              │ DRG-Invista-Shared
              ▼
     VCN-DEV (rede compartilhada, cmp-dev-inv)
              ▼
     api-gateway-nexus-dev (10.6.0.123, PRIVATE)
     ├─► /api/* → OKE Internal LB → Ingress NGINX → Pods
     └─► /mfe-*/* → Object Storage (mfe-*-dev buckets)

O que precisa ser feito:

  1. Criar deployments no api-gateway-nexus-dev para os MSs (/api/auth, /api/user, etc.)
  2. Criar deployments no api-gateway-nexus-dev para os MFEs (rotas SPA)
  3. Configurar DNS Cloudflare com hostname dnqe6ufrommkqxtfp7k2ehrbmu.apigateway...
  4. Avaliar manter ou remover o api-gateway-mfe-dev (PUBLIC, vcn-oke)

Opção A original — ainda válida como alternativa

A opção de migrar api-gateway-nexus-dev para sbn-api-gateway (vcn-oke) continua válida se a preferência for centralizar tudo em vcn-oke. Mas a recomendação recebida é o oposto: centralizar em VCN-DEV.

Referências

  • Repo Terraform: tf_oci_clusters (Azure DevOps — CN-Squad / Invista FIDC - Nexus)
  • Compartment DEV Nexus OCID: ocid1.compartment.oc1..aaaaaaaahycc62za6ikthlhauvarvbdixc7xpjjmcrame3cirhu2kz74ddma
  • VCN oke OCID: ocid1.vcn.oc1.sa-saopaulo-1.amaaaaaasks3yliapqrmikfzagpgqohuzjqik3hx63w7r2uajiqv5krvxkda
  • VCN-DEV OCID: ocid1.vcn.oc1.sa-saopaulo-1.amaaaaaasks3yliatoq6uvqqak3kax775ksd2jastvgsbiki7mgj6jzue6dq

Atualizado em: 2026-03-01 — Double-check completo via OCI CLI