infracloud/inventcloud/invista/nexus/OPERATIONS.md
2026-02-23 17:25:29 -03:00

500 lines
16 KiB
Markdown

# Historico de Operacoes - Infracloud
Registro de operacoes e incidentes na infraestrutura.
---
## 2026-02-23 - Investigacao: Acesso Publico MFE e Decisao de Arquitetura
### Contexto
Investigar como expor o MFE (mfe-user) publicamente para acesso via browser.
O API Gateway MFE provisionado anteriormente e PRIVATE (IP 10.110.198.250), sem IP publico.
### Descoberta 1: Como os Microservicos (ms-user, ms-poc) funcionam
```
Browser
-> DNS ms-user.dev.invista.com.br = 137.131.236.202 (A record, Cloudflare, PROXIED=false)
-> ingress-nginx-external-controller (LB publico OKE, IP 137.131.236.202)
-> Ingress rule (hostname match)
-> Service -> Pod (no cluster OKE)
```
A pipeline dos MSs:
1. Build + Push imagem pro OCIR
2. Deploy via ArgoCD no OKE
3. Template `cd/cloudflare-dns.yml` (repo `azure-pipelines-templates`, branch `feature/cd-deploy-oci-oke`):
- Pega IP do `ingress-nginx-external-controller` via kubectl
- Usa `CLOUDFLARE_API_TOKEN` (Variable Group `oci-terraform`) para chamar API Cloudflare
- Cria/atualiza registro A na zona `invista.com.br`
**IPs relevantes:**
- Ingress NGINX External: `137.131.236.202` (publico)
- Ingress NGINX Internal: `10.110.143.54` (privado)
### Descoberta 2: SRV-TUNNEL e Cloudflare Access
O dominio `crivo-dev.invista.com.br` resolve para IPs Cloudflare (104.26.6.132 etc.) e redireciona para `invistacloud.cloudflareaccess.com` (autenticacao).
```
Browser -> Cloudflare (proxy, IPs publicos)
-> Cloudflare Access (autenticacao)
-> Cloudflare Tunnel (cloudflared)
-> SRV-TUNNEL (10.6.0.145, OCI instance RUNNING)
-> LB Test_Crivo_Dev (10.8.4.127)
```
| Componente | Detalhe |
|-----------|---------|
| Cloudflare Account | `invistacloud` (sem acesso disponivel) |
| SRV-TUNNEL | OCID: `ocid1.instance.oc1.sa-saopaulo-1.antxeljrsks3ylic7eg7dezyq4rojzt7wvupizviezu2isazb6y6yncl2aza` |
| SRV-TUNNEL IP | 10.6.0.145 (privado, sem IP publico) |
| LB Test_Crivo_Dev | 10.8.4.127, VCN-Shared (10.8.0.0/16) |
### Descoberta 3: Template cloudflare-dns.yml
Encontrado no repo `azure-pipelines-templates`, branch `feature/cd-deploy-oci-oke`:
| Arquivo | Funcao |
|---------|--------|
| `cd/cloudflare-dns.yml` | Template Azure DevOps - pega IP do ingress, chama script |
| `cd/scripts/update_cloudflare_dns.sh` | Script bash - busca zone ID, cria/atualiza registro A via API Cloudflare |
O script:
1. Busca Zone ID de `invista.com.br` via API Cloudflare
2. Verifica se registro ja existe
3. Cria (POST) ou atualiza (PUT) registro A com TTL 60s
4. Usa `CLOUDFLARE_API_TOKEN` do Variable Group
### Problema: MFE nao tem IP publico
| | ms-user/ms-poc | mfe-user |
|--|---------------|----------|
| Onde roda | Pod no cluster OKE | Arquivos estaticos no bucket |
| Entrada | Ingress NGINX External (IP publico) | API Gateway PRIVATE (IP privado) |
| IP publico | 137.131.236.202 | Nenhum |
O MFE nao roda no cluster, roda no Object Storage via API Gateway.
Nao e possivel usar o mesmo ingress-nginx que os MSs usam.
### Decisao: API Gateway PUBLIC
**Solucao adotada**: Recriar o API Gateway como **PUBLIC** (em vez de PRIVATE).
O API Gateway PUBLIC recebe um IP publico da OCI, e o DNS pode apontar direto.
```
Browser
-> DNS mfe-user-dev.invista.com.br = <IP publico do API GW> (A record, Cloudflare)
-> API Gateway PUBLIC (IP publico, OCI)
-> Object Storage (bucket nexus-mfe-user-development)
-> index.html / assets Angular SPA
```
Vantagens:
- Mesmo padrao de DNS dos MSs (Cloudflare API + A record)
- Nao depende do Cloudflare Tunnel (conta invistacloud sem acesso)
- Nao precisa de VCN peering nem LB intermediario
### Acoes pendentes
1. Alterar Terraform: `endpoint_type = "PUBLIC"` no modulo api_gateway_mfe
2. Rodar pipeline para reprovisionar o API Gateway
3. Obter novo IP publico
4. Criar pipeline/script para configurar DNS via `CLOUDFLARE_API_TOKEN`
---
## 2026-02-23 - API Gateway MFE: Terraform, Pipeline, Rede e LB
### Contexto
Provisionamento completo do API Gateway MFE para servir micro frontends (Angular SPAs) via OCI Object Storage, incluindo modulo Terraform, correcao de pipeline, conectividade de rede (VCN peering) e configuracao do Load Balancer.
### 1. Modulo Terraform `api_gateway_mfe`
Criado modulo reutilizavel em `tf_oci_clusters/modules/api_gateway_mfe/`:
| Arquivo | Descricao |
|---------|-----------|
| main.tf | Gateway PRIVATE + Deployment com rotas SPA (index.html fallback + static files via Object Storage) |
| variables.tf | Inputs: compartment_id, subnet_id, env_name, mfe_deployments list, endpoint_type |
| outputs.tf | gateway_id, gateway_ip, gateway_hostname, deployment_endpoints |
| versions.tf | oracle/oci ~> 7.0 |
Integracao no ambiente dev:
- `environments/dev/api_gateway_mfe.tf` - module call com mfe-user deployment
- `environments/dev/terraform.ci.tfvars` - `enable_api_gateway_mfe = true`
- `modules/network/main.tf` - subnet `sbn-api-gateway` (10.110.192.0/20, condicional via `enable_api_gateway_subnet`)
### 2. Correcoes de Pipeline
#### S3 Backend - Credenciais desabilitadas
**Builds #5960, #5961**: Erro `UserDisabled` no backend S3.
- **Causa**: Customer Secret Key do `william.dias` estava desabilitada
- **Fix**: Criado novo Customer Secret Key para `danilo.duarte` via OCI CLI
- **Variable Group `oci-terraform` (ID 34)**: Atualizado `TF_STATE_ACCESS_KEY` e `TF_STATE_SECRET_KEY`
#### Propagacao de chave
**Build #5962**: Erro `SignatureDoesNotMatch` (chave ainda propagando). Resolvido aguardando ~2 min.
#### Bastion boot volume
**Build #5963**: Erro no apply - boot volume do bastion (47GB < 50GB minimo OCI).
- **Fix**: Adicionado `boot_volume_size_in_gbs = 50` em `source_details` do `oci_core_instance.bastion`
#### Sucesso
**Build #5964**: Todas as stages passaram (Bootstrap, DEV Plan, DEV Apply).
### 3. Recursos Provisionados
| Recurso | Valor |
|---------|-------|
| API Gateway | `api-gateway-mfe-dev` |
| OCID | `ocid1.apigateway.oc1.sa-saopaulo-1.amaaaaaasks3yliabdiquogy2pqyohas4wjopizv2xzgzrclmsvsh4x7ewea` |
| IP | 10.110.198.250 |
| Hostname | `guhal72tzyekzchzamhhi3lvgi.apigateway.sa-saopaulo-1.oci.customer-oci.com` |
| VCN | vcn-oke (10.110.0.0/16) |
| Subnet | sbn-api-gateway (10.110.192.0/20) |
| Deployment | deploy-mfe-user-dev (rotas / e /{path*}) |
### 4. VCN Peering (DRG)
O LB `Test_Crivo_Dev` esta na VCN-Shared (10.8.0.0/16), API Gateway na vcn-oke dev (10.110.0.0/16).
**Acoes realizadas:**
```bash
# 1. DRG Attachment criado
oci network drg-attachment create \
--drg-id "ocid1.drg.oc1.sa-saopaulo-1.aaaaaaaazuiluiavm3zcrzelqs2f3k3sdy3fka5yytwjua37a2ksn446deza" \
--display-name "ATT-VCN-OKE-DEV" \
--vcn-id "ocid1.vcn.oc1.sa-saopaulo-1.amaaaaaasks3yliapqrmikfzagpgqohuzjqik3hx63w7r2uajiqv5krvxkda"
# OCID: ocid1.drgattachment.oc1.sa-saopaulo-1.aaaaaaaaszldmalgmlnbfab7x7g2v336u64iwfvaiddbf7tea2dekso44kza
# State: ATTACHED
# 2. Route table rt-api-gateway atualizada
# Adicionada rota: 10.8.0.0/16 -> DRG (para retorno do trafego)
# 3. Security list sl-api-gateway atualizada
# Adicionadas regras ingress:
# 10.8.0.0/16 TCP 443 (LB VCN-Shared -> API GW HTTPS)
# 10.8.0.0/16 TCP 80 (LB VCN-Shared -> API GW HTTP)
```
**Nota**: RT-LB-SHARED (VCN-Shared) ja tinha rota `0.0.0.0/0 -> DRG`, portanto nao foi necessario alterar.
### 5. Load Balancer Test_Crivo_Dev
Configuracao adicionada (sem alterar regras existentes do Crivo):
```bash
# Backend set criado
bs-mfe-user-dev -> 10.110.198.250:443 (health check HTTP:443/)
# Routing policy crivo_routes - regra adicionada
mfe_user_dev: host == mfe-user-dev.invista.com.br -> bs-mfe-user-dev
```
**Configuracao final do LB:**
| Backend Set | Backends | Routing Rule |
|-------------|----------|-------------|
| Dev_Crivo_BS_80 | 10.4.0.116:80 | crivo-dev.invista.com.br |
| Dev_Crivo_BS_84 | 10.4.0.116:84 | crivo-dev-adm.invista.com.br |
| bs-mfe-user-dev | 10.110.198.250:443 | mfe-user-dev.invista.com.br |
### 6. Pendencias
- [ ] **DNS Cloudflare**: Criar registro `mfe-user-dev.invista.com.br` - sem acesso ao Cloudflare que gerencia `invista.com.br`
- [ ] **Terraform state**: O DRG attachment, route table e security list foram criados via CLI (fora do Terraform). Considerar importar ou adicionar ao Terraform para manter consistencia.
### Fluxo completo (quando DNS estiver configurado)
```
Browser -> Cloudflare (mfe-user-dev.invista.com.br)
-> LB Test_Crivo_Dev (10.8.4.127, VCN-Shared)
-> DRG-Invista-Shared (ATT-VCN-OKE-DEV)
-> API Gateway MFE (10.110.198.250, vcn-oke dev)
-> Object Storage (nexus-mfe-user-development bucket)
-> index.html / assets Angular SPA
```
---
## 2026-02-18 - Conexao Cluster OCI OKE e Troubleshooting
### Contexto
Usuario solicitou conexao ao cluster Kubernetes OCI OKE para verificar mudancas de commits e investigar problemas.
### Ferramentas Utilizadas
| Ferramenta | Versao | Localizacao |
|------------|--------|-------------|
| OCI CLI | 3.73.2 | C:\oci\bin\oci.exe |
| kubectl | v1.31.0 | C:\oci\bin\kubectl.exe |
| Git | - | C:\dev\infracloud |
### Passos Realizados
#### 1. Sincronizacao do Repositorio infracloud
```bash
# Local: C:\dev\infracloud
# Verificar commits de ontem
git log --oneline --since="yesterday"
# Commits encontrados:
# 26ce1f6 - docs: add mfe repos URLs to Azure DevOps connection docs
# 8379e6b - Add OCI and K3s cluster connection documentation
# fa2ff35 - Add Azure DevOps connection documentation
# Stash de mudancas locais (README.md modificado)
git stash
# Pull do remote
git pull
# Resultado: 25 arquivos atualizados, 1564 remocoes, 729 adicoes
# Resolver conflitos de merge no README.md
# Mescladas secoes: OCI + Conexoes + Azure DevOps
# Commit e push
git add -A
git commit -m "docs: add OCI documentation and resolve merge conflicts"
git push
# Commit: 3a615e1
```
#### 2. Conexao ao Cluster OCI OKE
O cluster ja estava configurado no kubeconfig local.
```bash
# Verificar contexto atual
kubectl config get-contexts
# Contexto: context-cobrewkvc3a
# Informacoes do cluster
kubectl cluster-info
# API Server: https://136.248.124.22:6443
```
**Cluster OCI OKE:**
| Propriedade | Valor |
|-------------|-------|
| API Server | https://136.248.124.22:6443 |
| Versao K8s | v1.34.1 |
| Nodes | 3 (10.110.10.16, 10.110.15.40, 10.110.2.160) |
| CNI | Flannel |
#### 3. Investigacao de Pods com Problema
**Estado inicial:**
```bash
kubectl get pods -A
```
| Namespace | Pod | Status |
|-----------|-----|--------|
| nexus-services | ms-auth-external-57f96d6d9d-7ksmr | CrashLoopBackOff |
| nexus-services | ms-parameters-666cd67f5-g9dh4 | CrashLoopBackOff |
| stream | nats-0 | ImagePullBackOff |
| default | dnscheck-* (varios) | Error |
**Diagnostico detalhado:**
```bash
# ms-auth-external
kubectl describe pod ms-auth-external-57f96d6d9d-7ksmr -n nexus-services
kubectl logs ms-auth-external-57f96d6d9d-7ksmr -n nexus-services --tail=50
# Erro: IAmazonCognitoIdentityProvider nao registrado
# Exit Code: 139 (SIGSEGV - Segmentation Fault)
# Causa: Nova versao da imagem :5744 sem configuracao AWS Cognito
```
```bash
# ms-parameters
kubectl describe pod ms-parameters-666cd67f5-g9dh4 -n nexus-services
kubectl logs ms-parameters-666cd67f5-g9dh4 -n nexus-services --tail=50
# Erro: Could not find a part of the path '/root/.oci/config'
# Exit Code: 139 (SIGSEGV)
# Causa: Nova versao da imagem :5474 sem configuracao OCI
```
```bash
# nats-0
kubectl describe pod nats-0 -n stream
# Erro: ImagePullBackOff
# Imagem: gru.ocir.io/grbb7qzeuoag/ms-auth-external/nats:5563
# Causa: Imagem nao existe no registry OCI
```
#### 4. Acao Corretiva - Rollback
A causa raiz foi deploy da branch `devops` com imagens quebradas.
**Rollback executado:**
```bash
# Rollback dos deployments
kubectl rollout undo deployment/ms-auth-external -n nexus-services
kubectl rollout undo deployment/ms-parameters -n nexus-services
# Scale down replicasets quebrados
kubectl scale replicaset \
ms-auth-external-796b45cb94 \
ms-auth-external-57f96d6d9d \
ms-parameters-666cd67f5 \
ms-parameters-9d5b74747 \
-n nexus-services --replicas=0
```
**Resultado:**
| Deployment | Replicaset | Imagem | Status |
|------------|------------|--------|--------|
| ms-auth-external | 5bb9fd69b5 | :5744 (versao estavel) | 2/2 Running |
| ms-parameters | 56c86b75 | :5474 (versao estavel) | 2/2 Running |
### Licoes Aprendidas
1. **Branch devops** esta fazendo deploy automatico de imagens sem testes adequados
2. **ms-auth-external** requer configuracao AWS Cognito (`IAmazonCognitoIdentityProvider`)
3. **ms-parameters** requer arquivo `/root/.oci/config` ou variaveis de ambiente OCI
4. **nats-0** precisa de imagem correta no registry OCI
### Acoes Futuras Recomendadas
- [ ] Implementar testes de healthcheck antes do deploy
- [ ] Adicionar gate de aprovacao na pipeline da branch devops
- [ ] Corrigir imagem do NATS no registry OCI
- [ ] Configurar AWS Cognito no ms-auth-external (se necessario)
- [ ] Configurar secrets OCI para ms-parameters
---
## 2026-02-18 - Analise dos Repositorios MFE no Azure DevOps
### Contexto
Reorganizacao dos repositorios MFE locais e analise de alteracoes feitas no dia 17/02/2026.
### Repositorios MFE Encontrados
Todos os repositorios estao no Azure DevOps Organization: **CN-Squad / Invista FIDC - Nexus**
| Repo | Branch Atual | Ultimo Commit | Data | Descricao |
|------|-------------|---------------|------|-----------|
| mfe-user | devops | `9ba92aa` | 17/02/2026 | OCI pipeline para static website |
| mfe-auth | devops | `9635bef` | 10/12/2025 | Atualizacao de ambiente |
| mfe-shell | devops | `ffa8be6` | 05/02/2026 | Ajuste de build |
| mfe-person | devops | `b7e9976` | 05/02/2026 | Validador CNPJ alfanumerico |
| mfe-poc | devops | `407fc21` | 17/02/2026 | Ajuste extensoes permitidas |
| mfe-formalization | devops | `176e846` | 15/01/2026 | Inicializacao mfe-formalization |
### Alteracoes de Pipeline em 17/02/2026
#### mfe-user - Novo Pipeline OCI
**Commit:** `9ba92aa`
**Arquivo criado:** `azure-pipelines-oci.yml`
Pipeline para hosting de MFE como static website no OCI:
```yaml
trigger:
branches:
include:
- devops
variables:
- group: oci-terraform
- group: mfe-credentials
stages:
- stage: Build
jobs:
- job: Build
steps:
- task: NodeTool@0
inputs:
versionSpec: '20.x'
- script: |
npm ci
npm run build:dev
- stage: UploadToOCI
jobs:
- job: Upload
steps:
- bash: |
# Upload para OCI Object Storage
BUCKET_NAME="nexus-mfe-user-dev"
oci os object put --bucket-name $BUCKET_NAME ...
```
**Recursos OCI utilizados:**
- Bucket: `nexus-mfe-user-dev`
- Variable Groups: `oci-terraform`, `mfe-credentials`
- Servico: Object Storage + API Gateway
#### mfe-poc - Commits de Merge
**Commits:** `407fc21`, `d3c22e7`
**PRs:** #1887, #1886
**Alteracao:** Ajuste para exibicao de tipos de extensoes permitidas
### Reorganizacao de Pastas Locais
Pastas com nomes incorretos foram movidas:
| Antes | Depois |
|-------|--------|
| `C:\dev\C:devrepos_mfe\mfe-user` | `C:\dev\mfe-user` |
| `C:\dev\C:devrepos_mfe\mfe-auth` | `C:\dev\mfe-auth` |
| `C:\dev\C:devrepos_mfe\mfe-shell` | `C:\dev\mfe-shell` |
| `C:\dev\C:devrepos_mfe\mfe-person` | `C:\dev\mfe-person` |
| `C:\dev\C:devrepos_mfe\mfe-poc` | `C:\dev\mfe-poc` |
| `C:\dev\C:devrepos_mfe\mfe-formalization` | `C:\dev\mfe-formalization` |
### Estrutura Final de Repositorios Locais
```
C:\dev\
├── mfe-user/ # Azure DevOps: CN-Squad/mfe-user
├── mfe-auth/ # Azure DevOps: CN-Squad/mfe-auth
├── mfe-shell/ # Azure DevOps: CN-Squad/mfe-shell
├── mfe-person/ # Azure DevOps: CN-Squad/mfe-person
├── mfe-poc/ # Azure DevOps: CN-Squad/mfe-poc
├── mfe-formalization/ # Azure DevOps: CN-Squad/mfe-formalization
├── ms-auth-external/ # Azure DevOps: CN-Squad/ms-auth-external
├── ms-auth-sso/ # Azure DevOps: CN-Squad/ms-auth-sso
├── ms-parameters/ # Azure DevOps: CN-Squad/ms-parameters
├── tf_oci_clusters/ # Azure DevOps: CN-Squad/tf_oci_clusters
├── nats-k8s-config/ # Azure DevOps: CN-Squad/nats-k8s-config
├── repos_mfe/ # azure-pipelines-templates
├── devrepos_mfe/ # azure-pipelines-templates
└── infracloud/ # GitHub: rede5/infracloud
```
---
## Referencias
- [CONNECTIONS.md](./CONNECTIONS.md) - Credenciais e conexoes
- [azure-devops/CONNECTION.md](./azure-devops/CONNECTION.md) - Azure DevOps CN-Squad
- [azure-devops/OCI-CONNECTION.md](./azure-devops/OCI-CONNECTION.md) - Configuracao OCI
---
*Documento atualizado em: 2026-02-23*