infracloud/invista/nexus/OPERATIONS.md
Tiago Ribeiro ab9ae3f160 docs(nexus): registra migração API Gateway MFE e fixes de pipeline (2026-03-03)
- OPERATIONS.md: entrada completa com 4 fixes realizados:
  * modules/iam_domain/versions.tf (provider hashicorp vs oracle/oci)
  * ssh_public_key_path em hml/prod (../../config/ssh/ correto)
  * var.region -> var.oci_region e client_id -> name
  * migração API Gateways MFE para cmp-dev-nexus (PUBLIC, sbn-lb-1)
- OCI-DEV-NEXUS.md: corrige ssh_public_key_path na seção de tfvars
- PIPELINE-ANALISE.md: marca P6/P7 como resolvidos; atualiza tabela TF vs manual
2026-03-03 18:29:34 -03:00

634 lines
22 KiB
Markdown

# Historico de Operacoes - Infracloud
Registro de operacoes e incidentes na infraestrutura.
---
## 2026-03-03 — Pipeline Terraform: correção de providers e migração API Gateway MFE
### Contexto
Duas sessões de trabalho nesta data. Objetivos principais:
1. Identificar e corrigir pipeline Terraform falhando desde 2026-02-25
2. Migrar recursos MFE (API Gateways + buckets) do compartment `cmp-dev-inv` para `cmp-dev-nexus`
3. Renomear gateway de `api-gateway-mfe``api-gateway` (serve MFE + MS)
4. Corrigir caminhos SSH incorretos em HML e PROD
---
### Fix 1 — Pipeline falhando desde 2026-02-25: `hashicorp/oci` vs `oracle/oci`
**Sintoma:** Pipeline `terraform-tf_oci_clusters` falhava no `terraform init` com:
```
did not find a proper configuration for private key
with provider["registry.terraform.io/hashicorp/oci"]
```
**Causa raiz:** O módulo `modules/iam_domain/` era o único sem `versions.tf`. Sem essa declaração, o Terraform resolvia o provider `oci` para o alias legado `hashicorp/oci` (em vez de `oracle/oci`). O provider legado não aceitava a chave privada do Variable Group.
**Fix:** Criado `modules/iam_domain/versions.tf`:
```hcl
terraform {
required_providers {
oci = {
source = "oracle/oci"
version = "~> 7.0"
}
time = {
source = "hashicorp/time"
version = "~> 0.11"
}
}
}
```
**Commit:** `fix(iam_domain): adiciona versions.tf com oracle/oci como provider`
**Resultado:** Pipeline run 6270 — Bootstrap e Detect Changes passaram.
---
### Fix 2 — ssh_public_key_path incorreto em HML e PROD
**Sintoma:** HML e PROD Plans falhavam com:
```
Invalid value for "path" parameter: no file exists at "../../config/ci_ssh_key.pub"
```
**Causa:** `terraform.ci.tfvars` de HML e PROD apontavam para `../../config/ci_ssh_key.pub`, mas o arquivo está em `../../config/ssh/ci_ssh_key.pub` (subdiretório `ssh/`). DEV já usava o caminho correto.
**Fix:**
- `environments/hml/terraform.ci.tfvars`: `../../config/ci_ssh_key.pub``../../config/ssh/ci_ssh_key.pub`
- `environments/prod/terraform.ci.tfvars`: mesma correção
**Commit:** `fix(ci): corrige caminho ssh_public_key_path em hml e prod`
---
### Fix 3 — Variável `var.region` e atributo `client_id` (sessão anterior)
**Corrigido em sessão anterior (2026-03-03 manhã):**
- `api_gateway_mfe.tf`: `var.region``var.oci_region` (variável não declarada)
- `modules/iam_domain/main.tf`: `.client_id``.name` (atributo não suportado no provider v7)
---
### Migração — API Gateway MFE para cmp-dev-nexus
**Situação anterior:**
- 2 API Gateways PUBLIC em `cmp-dev-inv` (criados manualmente)
- 1 API Gateway PRIVATE em `cmp-dev-nexus` (criado manualmente, mfe-shell-dev)
- Bucket `mfe-shell-dev` em `cmp-dev-inv`
- Os outros 5 buckets MFE também estavam espalhados
**Ação:** Deletar todos os gateways MFE manuais via OCI CLI, recriar via Terraform em `cmp-dev-nexus`.
**Recursos deletados via OCI CLI:**
| Recurso | OCID (sufixo) | Compartment |
|---------|--------------|-------------|
| api-gateway-mfe-shell-dev (PUBLIC) | `…bdiquogy2pqy…` | cmp-dev-inv |
| api-gateway-mfe-dev (PUBLIC) | `…bjlibdhd5wqhf7…` | cmp-dev-inv |
| api-gateway-mfe-shell-dev (PRIVATE) | `…pkj6keuum…` | cmp-dev-nexus |
| Bucket mfe-shell-dev | (objetos bulk-deletados antes) | cmp-dev-inv |
> **PRESERVADO:** `api-gateway-nexus-dev` (PRIVATE, 11 deployments para backend MSes) — NÃO foi deletado.
**Mudanças no Terraform (`environments/dev/api_gateway_mfe.tf`):**
```hcl
# Antes:
compartment_id = local.compartment_id # cmp-dev-inv
subnet_id = module.network.api_gateway_subnet_id # sbn-api-gateway (PRIVADA)
display_name = "api-gateway-mfe" # nome: api-gateway-mfe-dev
# endpoint_type não definido (default PRIVATE)
# Depois:
compartment_id = local.cluster_compartment_id # cmp-dev-nexus
subnet_id = module.network.lb_subnet_ids[0] # sbn-lb-1 (PÚBLICA, obrigatória para PUBLIC GW)
endpoint_type = "PUBLIC"
display_name = "api-gateway" # nome: api-gateway-dev (genérico, serve MFE + MS)
```
**Mudanças no módulo (`modules/api_gateway_mfe/variables.tf`):**
- Removido atributo `hostname` do tipo `mfe_deployments` (não usado no main.tf, não fornecido pelos callers)
**Resultado esperado após apply (pipeline 6270 DEV Apply):**
- `api-gateway-dev` (PUBLIC) em `cmp-dev-nexus`, subnet `sbn-lb-1`
- 6 buckets `mfe-*-dev` em `cmp-dev-nexus`
- 6 deployments no gateway (um por MFE)
**Aprovação do DEV Apply:** Aprovada via API Azure DevOps em 2026-03-03T21:25:42Z.
---
### Por que PUBLIC Gateway requer subnet PÚBLICA
A subnet `sbn-api-gateway` (10.110.192.0/20) tem `prohibit_public_ip_on_vnic = true` — não pode hospedar API Gateway PUBLIC. A única opção é a `sbn-lb-1` (10.110.128.0/20), que é pública (mesma subnet dos OKE Load Balancers).
---
### Estado dos pipelines em 2026-03-03 (fim do dia)
| Pipeline run | Status | Motivo |
|-------------|--------|--------|
| 6270 Bootstrap | ✅ succeeded | — |
| 6270 DEV Plan | ✅ succeeded | — |
| 6270 DEV Apply | ⏳ em andamento | aprovado 21:25 BRT |
| 6270 HML Plan | ❌ falhou | ssh_public_key_path errado (corrigido em 6271) |
| 6270 PROD Plan | ❌ falhou | ssh_public_key_path errado (corrigido em 6271) |
| 6271 | 🔄 pending | aguarda conclusão do push às 21:26 BRT |
---
## 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*