Pipeline de Infraestrutura ADS OCI¶

Este repositório contém a infraestrutura como código (IaC) para implantar e gerenciar recursos na Oracle Cloud Infrastructure (OCI) usando Terragrunt e Terraform.

Introdução¶

O Pipeline de Infraestrutura ADS OCI foi projetado para provisionar e gerenciar recursos de infraestrutura em múltiplos ambientes (ferramentas, homologação e produção) na Oracle Cloud Infrastructure. Utiliza o Terragrunt como uma camada sobre o Terraform para proporcionar funcionalidades adicionais e melhorar a experiência do desenvolvedor ao trabalhar com múltiplos módulos e ambientes do Terraform.

O projeto segue uma abordagem estruturada para o provisionamento de infraestrutura com: - Clara separação de ambientes - Módulos reutilizáveis - Arquivos de configuração para personalização de implantações - Gerenciamento de estado remoto no OCI Object Storage

Funcionalidades¶

Suporte a múltiplos ambientes: Ambientes de Ferramentas (Tools), Homologação (HML) e Produção (PRD)
Arquitetura modular: Módulos Terraform reutilizáveis para diferentes componentes de infraestrutura
Gerenciamento do Oracle Kubernetes Engine (OKE): Criação e configuração de clusters OKE
Ferramentas DevOps: Inclui ArgoCD, Vault, External Secrets, Monitoramento e mais
Segurança de infraestrutura: Implementa políticas IAM do OCI e KMS para gerenciamento de segredos
Gerenciamento de estado remoto: Armazena o estado do Terraform no OCI Object Storage
Gerenciamento de dependências: Sequenciamento adequado da criação de recursos através de dependências

Requisitos¶

Terraform ~> 1.10
Terragrunt
Terramate
Conta Oracle Cloud Infrastructure (OCI) com permissões apropriadas
OCI CLI configurado com os perfis necessários
AWS CLI (para acesso ao armazenamento de objetos OCI compatível com S3)
kubectl (para interações com Kubernetes)
helm (para implantação de aplicações Kubernetes)

Instalação¶

Clone este repositório: bash git clone https://github.com/ads-saude/ads-oci-infra-pipeline.git cd ads-oci-infra-pipeline
Configure as variáveis de ambiente necessárias: ```bash

Configuração OCI¶

export OCI_NAMESPACE="gr9qdgmg7kig" # Seu namespace OCI export OCI_REGION="sa-saopaulo-1" # Sua região OCI export OCI_STATE_BUCKET="STH-CE-terraform-state" # Bucket para estado do Terraform export OCI_COMPARTMENT_ID="ocid1.compartment.oc1..aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" # ID do compartimento OCI export OCI_CLI_PROFILE="sth-sa-admin" # Profile da OCI CLI, altere para perfil configurado na CLI OCI

Configuração AWS (para compatibilidade com OCI S3)¶

export AWS_ACCESS_KEY_ID="your_aws_access_key_id" # Service account user customer key export AWS_SECRET_ACCESS_KEY="your_aws_secret_access_key" # Service account user customer key

Ou configure o perfil AWS CLI¶

export AWS_PROFILE="sth-sa-admin" # Profile AWS CLI compatível com OCI S3 ```

Bootstrap do ambiente (configuração inicial):

O processo de bootstrap configura os recursos iniciais necessários na OCI antes de executar o Terraform/Terragrunt. Você pode executar todo o processo com um único comando ou executar os scripts individualmente para mais controle.

Namespaces de Tags para OKE¶

Um componente crítico do bootstrap é a criação de namespaces de tags na OCI. Estes namespaces são necessários para o módulo OKE poder adicionar tags aos recursos criados. Cada ambiente utiliza seu próprio namespace:

Ambiente Tools: STH-CE-OKE-TOOLS
Ambiente HML: STH-CE-OKE-HML
Ambiente NOX (Produção): STH-CE-OKE-NOX

Vault Global¶

O bootstrap também cria a vault GLOBAL que é usada para armazenar segredos compartilhados entre os ambientes:

vault-GLOBAL: Vault para segredos compartilhados entre ambientes

Nota: As vaults específicas de cada ambiente (vault-TOOLS, secrets-TOOLS, secrets-HML, secrets-NOX) são criadas automaticamente pelo Terraform durante o deploy dos respectivos ambientes e não precisam ser criadas no bootstrap.

Execução completa do bootstrap:¶

bash cd bootstrap ./00-bootstrap-oke.sh --tags STH-CE-OKE-TOOLS,STH-CE-OKE-HML,STH-CE-OKE-NOX \ --buckets $OCI_STATE_BUCKET \ --vaults vault-GLOBAL \ --compartment-id $OCI_COMPARTMENT_ID --profile $OCI_CLI_PROFILE

Execução individual dos scripts de bootstrap:¶

Você também pode executar cada etapa do bootstrap separadamente:

Criação de Tags - Cria namespaces de tags e definições de tags na OCI (necessário para o módulo OKE): ```bash cd bootstrap

Execute uma vez para cada namespace necessário¶

./01-create-tags.sh --tag STH-CE-OKE-TOOLS \ --compartment-id $OCI_COMPARTMENT_ID \ --profile $OCI_CLI_PROFILE

./01-create-tags.sh --tag STH-CE-OKE-HML \ --compartment-id $OCI_COMPARTMENT_ID \ --profile $OCI_CLI_PROFILE

E assim por diante para cada ambiente¶

`` Esse script cria um namespace de tags com as seguintes definições essenciais: -cluster_autoscaler: Permissões para autoscaler do cluster -pool: Grupo de recursos com configuração compartilhada -role: Função de um recurso -state_id`: ID de estado do Terraform associado a um recurso

Criação da Vault Global - Cria a vault GLOBAL e sua master key: bash cd bootstrap ./02-create-vaults.sh --vault-name vault-GLOBAL \ --compartment-id $OCI_COMPARTMENT_ID \ --profile $OCI_CLI_PROFILE A vault GLOBAL é usada para armazenar segredos compartilhados entre os ambientes. As vaults específicas de cada ambiente são criadas automaticamente pelo Terraform durante o deploy.
Criação de Buckets - Cria buckets para armazenamento de estado do Terraform: bash cd bootstrap ./03-create-buckets.sh --bucket-name $OCI_STATE_BUCKET \ --compartment-id $OCI_COMPARTMENT_ID \ --profile $OCI_CLI_PROFILE

IMPORTANTE: O bootstrap deve ser executado apenas uma vez para criar os recursos necessários para a execução do pipeline. Cada script verifica se os recursos já existem antes de tentar criá-los novamente.

Relação com os módulos Terraform: - O módulo OKE utiliza o namespace de tags para adicionar tags aos recursos criados na OCI - A vault GLOBAL é usada para armazenar segredos compartilhados entre os ambientes - As demais vaults e chaves de criptografia específicas de cada ambiente serão criadas automaticamente pelo Terraform - Os demais módulos dependem dos recursos criados pelo bootstrap para funcionarem corretamente

Uso¶

Execução com Terragrunt¶

O projeto utiliza Terragrunt para gerenciar ambientes e módulos. Para aplicar alterações a um ambiente e módulo específicos:

```bash

Navegue até o ambiente e módulo¶

cd infrastructure/environments/[ambiente]/[módulo]

Inicialize o Terragrunt¶

terragrunt init

Planeje as alterações¶

terragrunt plan

Aplique as alterações¶

terragrunt apply ```

Exemplo para implantar OKE no ambiente de ferramentas: bash cd infrastructure/environments/tools/oke terragrunt apply

Execução com Terramate¶

Recomenda-se o uso do Terramate para fazer o deploy dos ambientes, pois ele respeita a ordem de dependências entre os módulos e os executa na sequência correta:

Deploy de todos os ambientes:¶

bash terramate run --terragrunt -- terragrunt apply -input=false -auto-approve

Deploy do ambiente global:¶

bash terramate run --terragrunt --tags="global" -- terragrunt apply -input=false -auto-approve

Deploy de um ambiente específico (ex: tools):¶

bash terramate run --terragrunt --tags="tools" -- terragrunt apply -input=false -auto-approve

Deploy de um módulo específico em um ambiente específico (ex: oke no ambiente tools):¶

bash terramate run --terragrunt --tags="tools:oke" -- terragrunt apply -input=false -auto-approve

Nota sobre tags no Terramate: - , (vírgula) significa OU (OR) - : (dois pontos) significa E (AND)

Exemplo para deploy de módulos sentry OU argocd no ambiente tools: bash terramate run --terragrunt --tags="tools:sentry,tools:argocd" -- terragrunt apply -input=false -auto-approve

Configuração¶

Configuração Global¶

O arquivo root.hcl contém a configuração global para todos os ambientes, incluindo: - Configuração de estado remoto no OCI Object Storage - Configurações comuns de provedores - Variáveis e inputs globais

Configuração Comum¶

O arquivo infrastructure/environments/common.hcl contém configurações compartilhadas entre todos os ambientes:

terraform inputs = { compartment_id = "ocid1.compartment.oc1..aaaaaaaamhcjz4cxzg5ooqcpgjd5nwaul5atlfeljy4lh5kafzlj2sqqmcwq" tenancy_id = "ocid1.tenancy.oc1..aaaaaaaai7a72s5jgxce6rik7qna2nx2j3flclxvvrkg3mojvxmrjz3hmf6q" global_vault_id = "ocid1.vault.oc1.sa-saopaulo-1.fftxlml7aaeb2.abtxeljrjgwpkh27c5e7cjaqunto2vxwiwk5ageb56ktqpcz26wor667mmwq" global_master_key_id = "ocid1.key.oc1.sa-saopaulo-1.fftxlml7aaeb2.abtxeljri6obcmtdaymksk7neohkvehgfwpnftktiwoox6khj4jg6ktjtqwa" kiali_config_secret_id = "ocid1.vaultsecret.oc1.sa-saopaulo-1.amaaaaaaf6sskwya7xsjc7wj5xhxxdgdhzaori6nd4locygg6afvcdyk7iza" alert_config_secret_id = "ocid1.vaultsecret.oc1.sa-saopaulo-1.amaaaaaaf6sskwyaq6dmwmfcue5ypb5chta546mupmgbysnp3ucyz6ymssja" otel_collector_bearer_token_secret_name = "ESO-signoz-otel-collector-bearer-token" cert_manager_issuer = "le-prd" }

Explicação das variáveis de configuração comum:

compartment_id: ID do compartimento OCI onde todos os recursos são criados. Usado por todos os módulos que interagem com a API da OCI.

Os domínios públicos não ficam mais centralizados em common.hcl. No estado atual do pipeline, eles são definidos nos módulos e ambientes específicos, por exemplo:

config/tools/argocd/config.hcl: domain = "nox.app.br"
config/tools/vault/config.hcl: vault_host = "vault.nox.app.br"
config/tools/monitoring/config.hcl: otel_endpoint = "https://otel.nox.app.br:443"
config/hml/istio/config.hcl e config/nox/istio/config.hcl: domain = "nox.app.br"
compartment_id: ID do compartimento OCI onde todos os recursos são criados. Usado por todos os módulos que interagem com a API da OCI.
tenancy_id: ID do tenant OCI principal. Usado para autenticação e permissões em todos os módulos OCI.
global_vault_id: ID da vault GLOBAL criada durante o bootstrap. Usada pelo módulo External Secrets para acessar segredos compartilhados entre ambientes.
global_master_key_id: ID da chave mestra da vault GLOBAL. Usada para criptografia/descriptografia de segredos.
kiali_config_secret_id: ID do segredo contendo a configuração do Kiali (dashboard de visualização para Istio). Usado pelo módulo Istio.
alert_config_secret_id: ID do segredo contendo a configuração de alertas. Usado pelo módulo de Monitoramento.
otel_collector_bearer_token_secret_name: Nome do segredo do External Secrets contendo o token para autenticação do coletor OpenTelemetry. Usado pelo módulo SignOz para configurar observabilidade.
cert_manager_issuer: Nome do emissor de certificados Let's Encrypt usado pelo Cert-Manager. Usado pelo módulo oke-extras para configurar o Cert-Manager.

Configuração Específica por Ambiente¶

Cada ambiente possui seu próprio arquivo env.hcl:

Ambiente Global¶

```terraform

infrastructure/environments/global/env.hcl¶

inputs = {} ```

O ambiente global não requer variáveis específicas, pois utiliza apenas as configurações comuns.

Ambiente de Ferramentas (Tools)¶

```terraform

infrastructure/environments/tools/env.hcl¶

inputs = { suffix = "TOOLS" env = "tools" lb_publlic_ip = "" } ```

Ambiente de Homologação¶

```terraform

infrastructure/environments/hml/env.hcl¶

inputs = { suffix = "HML" env = "hml" lb_publlic_ip = "" } ```

Ambientes de Produção¶

```terraform

infrastructure/environments/noxtec/env.hcl¶

inputs = { suffix = "NOX" env = "nox" lb_publlic_ip = "" }

infrastructure/environments/sotech/env.hcl¶

inputs = { suffix = "STH" env = "sth" lb_publlic_ip = "" } ```

Explicação das variáveis específicas por ambiente:

suffix: Sufixo usado para nomear recursos OCI específicos do ambiente. Usado em todos os módulos para diferenciar recursos entre ambientes.
env: Nome do ambiente em minúsculas, usado como identificador nos scripts e configurações. Referenciado em vários módulos para determinar comportamentos específicos por ambiente.
lb_publlic_ip: Endereço IP público para o Load Balancer (quando aplicável). Deixado em branco quando o Load Balancer é criado automaticamente ou quando não é necessário um IP estático.

Ambientes¶

Ambiente Global¶

O ambiente global contém recursos compartilhados entre todos os ambientes: - IAM (Identity and Access Management): Gerencia políticas de acesso à OCI, grupos de usuários e permissões - GitHub Runners: Executores auto-hospedados do GitHub Actions para CI/CD

Diretório: infrastructure/environments/global/

infrastructure/environments/global/ ├── github-runner/ └── iam/

Ambiente de Ferramentas (Tools)¶

O ambiente de ferramentas é usado para ferramentas e serviços DevOps compartilhados. Inclui: - OKE (Oracle Kubernetes Engine): Cluster Kubernetes dedicado para ferramentas - OKE Extras: Componentes adicionais como Ingress NGINX e Cert-Manager - OKE Kubeconfig: Gerenciamento do arquivo de configuração para acesso ao cluster - OCI KMS: Gerenciamento de vaults e chaves de criptografia - ArgoCD: Plataforma GitOps para implantação contínua de aplicações - Vault: Gerenciamento centralizado e seguro de secrets - External Secrets: Sincronização de secrets entre Vault e Kubernetes - Monitoring: Stack de monitoramento com Prometheus, Grafana e Alertmanager - SonarQube: Análise estática de qualidade de código - Sentry: Plataforma para monitoramento e rastreamento de erros - SignOz: Plataforma completa de observabilidade (métricas, traces e logs) - SSH Keys: Gerenciamento de chaves SSH para acesso aos recursos

Diretório: infrastructure/environments/tools/

infrastructure/environments/tools/ ├── argocd/ ├── external-secrets/ ├── monitoring/ ├── oci-kms/ ├── oke/ ├── oke-extras/ ├── oke-kubeconfig/ ├── sentry/ ├── signoz/ ├── sonarqube/ ├── ssh-keys/ └── vault/

Ambiente de Homologação (HML)¶

O ambiente de homologação é usado para testes e validação antes da implantação em produção: - OKE (Oracle Kubernetes Engine): Cluster Kubernetes para aplicações em homologação - OKE Extras: Componentes adicionais como Ingress NGINX e Cert-Manager - OKE Kubeconfig: Gerenciamento do arquivo de configuração para acesso ao cluster - OCI KMS: Gerenciamento de vaults e chaves de criptografia - SSH Keys: Gerenciamento de chaves SSH para acesso aos recursos - Istio: Malha de serviços para gerenciamento de tráfego, segurança e observabilidade - External Secrets: Sincronização de secrets entre OCI Vault e Kubernetes - Monitoring: Stack de monitoramento com Prometheus, Grafana e Alertmanager - Namespaces: Gerenciamento de namespaces Kubernetes para isolamento de aplicações - Tenants: Configuração específica por tenant para isolamento de recursos

Diretório: infrastructure/environments/hml/

infrastructure/environments/hml/ ├── external-secrets/ ├── istio/ ├── monitoring/ ├── namespaces/ ├── oci-kms/ ├── oke/ ├── oke-extras/ ├── oke-kubeconfig/ ├── ssh-keys/ └── tenants/

Ambientes de Produção¶

Os ambientes de produção são separados por cliente:

Produção Noxtec (NOX)¶

Diretório: infrastructure/environments/noxtec/

infrastructure/environments/noxtec/ ├── external-secrets/ ├── istio/ ├── monitoring/ ├── namespaces/ ├── oci-kms/ ├── oke/ ├── oke-extras/ ├── oke-kubeconfig/ ├── ssh-keys/ └── tenants/

Produção Sotech (STH)¶

Diretório: infrastructure/environments/sotech/

infrastructure/environments/sotech/ ├── external-secrets/ ├── istio/ ├── monitoring/ ├── namespaces/ ├── oci-kms/ ├── oke/ ├── oke-extras/ ├── oke-kubeconfig/ ├── ssh-keys/ └── tenants/

Ambos os ambientes de produção incluem: - OKE (Oracle Kubernetes Engine): Cluster Kubernetes para aplicações em produção - OKE Extras: Componentes adicionais como Ingress NGINX e Cert-Manager - OKE Kubeconfig: Gerenciamento do arquivo de configuração para acesso ao cluster - OCI KMS: Gerenciamento de vaults e chaves de criptografia específicas do ambiente - SSH Keys: Gerenciamento de chaves SSH para acesso aos recursos - Istio: Malha de serviços para gerenciamento de tráfego, segurança e observabilidade - External Secrets: Sincronização de secrets entre OCI Vault e Kubernetes - Monitoring: Stack de monitoramento com Prometheus, Grafana e Alertmanager - Namespaces: Gerenciamento de namespaces Kubernetes para isolamento de aplicações - Tenants: Configuração específica por tenant para isolamento de recursos

Módulos¶

O projeto utiliza uma estrutura modular onde cada ambiente (global, tools, hml, noxtec, sotech) implementa os módulos necessários para sua finalidade. Os módulos são aplicados em cada ambiente conforme a necessidade.

Módulos por Ambiente¶

Ambiente Global¶

github-runner: Configura runners auto-hospedados do GitHub Actions
iam: Gerencia políticas e permissões IAM da OCI

Ambiente de Ferramentas (Tools)¶

argocd: Implanta ArgoCD para fluxos de trabalho GitOps
external-secrets: Integra secrets do Vault com Kubernetes
monitoring: Configura Prometheus, Grafana e Alertmanager
oci-kms: Gerencia vaults e chaves de criptografia na OCI
oke: Provisiona e configura o cluster Kubernetes (OKE)
oke-extras: Instala componentes adicionais como Ingress e Cert-Manager
oke-kubeconfig: Gerencia o arquivo kubeconfig para acesso ao cluster
sentry: Implanta o Sentry para monitoramento de erros
signoz: Configura o SignOz para observabilidade completa
sonarqube: Implanta o SonarQube para análise de qualidade de código
ssh-keys: Gerencia chaves SSH para acesso aos recursos
vault: Implanta o HashiCorp Vault para gerenciamento seguro de secrets

Ambientes de Homologação e Produção (HML, NOX, STH)¶

external-secrets: Integra secrets do OCI Vault com Kubernetes
istio: Implanta a malha de serviços Istio
monitoring: Configura Prometheus, Grafana e Alertmanager
namespaces: Gerencia namespaces Kubernetes para isolamento
oci-kms: Gerencia vaults e chaves de criptografia na OCI
oke: Provisiona e configura o cluster Kubernetes (OKE)
oke-extras: Instala componentes adicionais como Ingress e Cert-Manager
oke-kubeconfig: Gerencia o arquivo kubeconfig para acesso ao cluster
ssh-keys: Gerencia chaves SSH para acesso aos recursos
tenants: Gerencia configurações específicas por tenant

Descrição Detalhada dos Módulos¶

argocd: Plataforma GitOps para implantação contínua de aplicações seguindo o princípio de infraestrutura como código.
external-secrets: Sincroniza secrets de fontes externas (Vault, OCI KMS) com Kubernetes Secrets.
github-runner: Configura e gerencia runners auto-hospedados do GitHub Actions para execução de workflows CI/CD.
iam: Gerencia políticas IAM do OCI, grupos, compartimentos e permissões de acesso.
istio: Implementa malha de serviços para gerenciamento de tráfego, segurança e observabilidade entre microserviços.
monitoring: Configura infraestrutura de monitoramento com Prometheus para métricas, Grafana para visualização e Alertmanager para notificações.
namespaces: Cria e gerencia namespaces Kubernetes para isolamento lógico de aplicações.
oci-kms: Configura o serviço de gerenciamento de chaves da OCI, incluindo vaults e master keys.
oke: Provisiona e configura clusters Oracle Kubernetes Engine (OKE) com node pools, políticas e recursos associados.
oke-extras: Instala componentes adicionais no cluster OKE como Ingress NGINX, Cert-Manager e outros operadores essenciais.
oke-kubeconfig: Gerencia a criação e atualização do arquivo kubeconfig para acesso administrativo aos clusters.
sentry: Plataforma para monitoramento de erros e performance de aplicações em tempo real.
signoz: Plataforma de observabilidade que combina métricas, traces e logs para debugging de aplicações.
sonarqube: Ferramenta de análise estática de código para identificar bugs, vulnerabilidades e code smells.
ssh-keys: Gerencia pares de chaves SSH para acesso seguro aos recursos de infraestrutura.
tenants: Configura recursos específicos por tenant, incluindo namespaces e permissões.
vault: Implementa HashiCorp Vault para armazenamento seguro de secrets, gerenciamento de credenciais e controle de acesso.

Arquivos de Configuração¶

Os arquivos de configuração para cada ambiente e módulo estão localizados no diretório config/:

config/ ├── global/ │ ├── github-runner/ │ └── iam/ ├── hml/ │ ├── external-secrets/ │ ├── istio/ │ ├── monitoring/ │ ├── namespaces/ │ ├── oci-kms/ │ ├── oke/ │ ├── oke-extras/ │ └── tenants/ ├── noxtec/ │ ├── external-secrets/ │ ├── istio/ │ ├── monitoring/ │ ├── namespaces/ │ ├── oci-kms/ │ ├── oke/ │ ├── oke-extras/ │ └── tenants/ ├── sotech/ │ ├── external-secrets/ │ ├── istio/ │ ├── monitoring/ │ ├── namespaces/ │ ├── oci-kms/ │ ├── oke/ │ ├── oke-extras/ │ └── tenants/ └── tools/ ├── argocd/ ├── external-secrets/ ├── monitoring/ ├── oci-kms/ ├── oke/ ├── oke-extras/ ├── sentry/ ├── signoz/ ├── sonarqube/ └── vault/

Cada módulo em um ambiente lê sua configuração do diretório correspondente no diretório config/. Por exemplo, o módulo ArgoCD no ambiente de ferramentas lê sua configuração de config/tools/argocd/.

Exemplo de Configuração: Cluster OKE¶

A configuração do cluster OKE é dividida em múltiplos arquivos para melhor organização:

```terraform

config/tools/oke/cluster.hcl¶

state_id = "TOOLS" cluster_name = "OKE-TOOLS"

cluster_freeform_tags = { "Env" = "TOOLS", "Project" = "STH" }

vcn_id = "ocid1.vcn.oc1.sa-saopaulo-1.amaaaaaaf6sskwyakaooitbaawmussbtdp7iylypgsf4ky2syxdfzhgjf5ja" compartment_id = "ocid1.compartment.oc1..aaaaaaaamhcjz4cxzg5ooqcpgjd5nwaul5atlfeljy4lh5kafzlj2sqqmcwq" tenancy_id = "ocid1.tenancy.oc1..aaaaaaaai7a72s5jgxce6rik7qna2nx2j3flclxvvrkg3mojvxmrjz3hmf6q" home_region = "sa-saopaulo-1" region = "sa-saopaulo-1"

kubernetes_version = "v1.32.1"

... configurações adicionais do cluster¶

```

```terraform

config/tools/oke/node-pools.hcl¶

worker_pools = { workers = { shape = "VM.Standard.E5.Flex", ocpus = 4, memory = 32, autoscale = false, size = 3, # ... configurações adicionais do node pool } } ```

Execução Local¶

Para executar o projeto localmente:

Certifique-se de ter os pré-requisitos necessários instalados (Terraform, Terragrunt, OCI CLI, AWS CLI, kubectl, helm)
Configure as credenciais OCI usando:
Configuração da OCI CLI (~/.oci/config)
Variáveis de ambiente
Configure o perfil AWS CLI para compatibilidade com OCI S3: bash aws configure --profile sth-sa-admin
Exporte as variáveis de ambiente necessárias: bash export AWS_PROFILE=sth-sa-admin export OCI_REGION=sa-saopaulo-1
Execute comandos terragrunt para o módulo desejado: bash cd infrastructure/environments/tools/oke terragrunt plan terragrunt apply

Solução de Problemas¶

Credenciais OCI ausentes: Verifique se a CLI OCI está configurada corretamente ou defina as variáveis de ambiente necessárias
Problemas de bloqueio de estado: Verifique se há bloqueios de estado presos no OCI Object Storage e libere-os, se necessário
Falhas de dependências: Verifique se todas as dependências foram aplicadas adequadamente antes de aplicar módulos dependentes

Contribuindo¶

Clone o repositório
Crie uma branch de feature
Faça suas alterações
Envie um pull request

Licença¶

Este projeto é licenciado sob os termos do arquivo LICENSE incluído.