rede5/infracloud
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
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

22 KiB
Raw Blame History

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:

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):

# 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:

# 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):

# 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

# 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.

# 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:

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:

# 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

# 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

# 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:

# 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:

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

Documento atualizado em: 2026-02-23