Skip to content

Bootstrap de Pré-requisitos

Esta página reúne o que precisa existir antes do primeiro deploy do repositório ads-oci-infra-pipeline.

O foco aqui é operacional: o que o bootstrap cria sozinho, o que precisa ser criado manualmente em OCI Vault e quais integrações externas precisam existir antes de o pipeline começar a funcionar. A parte de rede, VCN, subnets, NAT e firewall fica fora deste escopo.

O que o bootstrap cria automaticamente

O script principal bootstrap/00-bootstrap-oke.sh só orquestra três tipos de recurso:

  1. Namespaces de tags OCI e suas tag keys.
  2. Vaults OCI e a master-key de cada vault.
  3. Buckets OCI usados pelo estado remoto.

Na prática, os scripts cobrem apenas a estrutura base:

  • 01-create-tags.sh: cria o namespace de tags e as chaves cluster_autoscaler, pool, role e state_id.
  • 02-create-vaults.sh: cria o vault e a chave master-key.
  • 03-create-buckets.sh: cria o bucket OCI.

Isso significa que o bootstrap nao cadastra credenciais, nao preenche payloads JSON e nao cria integrações externas como GitHub Apps, OAuth Apps ou tokens de terceiros.

O que precisa existir manualmente

Antes do primeiro run completo do pipeline, o ambiente precisa ter:

  1. Compartment e tenancy corretos para os stacks que serao aplicados.
  2. Vault global e master-key referenciados nos arquivos de configuração compartilhados.
  3. Secrets OCI Vault com payload preenchido manualmente.
  4. Apps e tokens externos já criados no GitHub.
  5. Credenciais de ferramentas externas, como Jira, GHCR, SonarQube e Sentry, já empacotadas nos secrets que o Terraform e o ESO vao consumir.

O ponto central dessa configuração compartilhada é infrastructure/environments/common.hcl, que referencia IDs globais como global_vault_id, global_master_key_id, kiali_config_secret_id, alert_config_secret_id, github_pipelines_secret_id e github_terraform_secret_id.

Importante

Os OCIDs vistos no repositório são exemplos da instalação atual, não um contrato universal. Para novos ambientes, o que importa é manter os nomes lógicos, os consumidores corretos e atualizar os arquivos .hcl com os IDs reais criados na sua tenancy.

OCI Vault: secrets manuais obrigatórios

Os secrets abaixo precisam ser criados ou preenchidos manualmente no OCI Vault antes que todos os módulos funcionem de ponta a ponta.

Secret Consumidor principal Conteúdo manual esperado Criado por script? Observação
ESO_ALERT_CONFIG Monitoring e alertmanager Webhooks de alerta Não Usado para integração com canais externos
ESO_ARGOCD_DEX_CONFIG ArgoCD clientID e clientSecret do OAuth App Não Necessário para login via Dex
ESO_ARGOCD_GITHUB_APP ArgoCD ID do app, installation IDs e private key Não Usado para repo creds GitHub
ESO_GHCR_REPO_CONFIG Charts e workloads Credenciais do GHCR Não Normalmente usuário e token do bot
ESO_IMAGE_PULL_SECRETS Clusters e ferramentas Auths para registries Não Alimenta pulls de imagens compartilhadas
ESO_IS_OCI_CONFIG Apps legadas e integrações OCI Config OCI, chaves e dados de Object Storage Não Secret de integração com OCI fora do runtime do Terraform
ESO_KIALI_CONFIG Kiali Config OpenID e signing key Não Consumido pelo addon do service mesh
ESO_SENTRY_CONFIG Sentry Senha admin, GitHub client/secret, webhook secret, mail password Não Exige integração manual prévia no GitHub
ESO_SIGNOZ_S3_CREDENTIALS Signoz Credenciais S3 compatíveis Não Necessário quando o storage usa credenciais externas
ESO_SONARQUBE_CONFIG SonarQube Senhas, JDBC, monitoring passcode e config GitHub ALM em base64 Não Parte do conteúdo depende de app GitHub criado antes
GITHUB_PIPELINE_SECRETS Pipelines GitHub Actions JSON por organização com credenciais de CI/CD Não Ponto principal para Jira, OCI CLI, OCIR e outros tokens
GITHUB_TERRAFORM_RW_SECRETS_TOKEN Módulo github-secrets Token GitHub com permissão de escrita nos repositórios Não Usado para publicar secrets no GitHub
GITHUB_RUNNER_ACCESS_TOKEN Runner OCI Token usado pelo runner para registro/autorização Não Referenciado pelo SECRET_ID do runner global

Os formatos completos de payload já existentes podem ser consultados em ../secrets/bootstrap.md e ../secrets/github.md.

GITHUB_PIPELINE_SECRETS: onde entram Jira e outras credenciais

O secret GITHUB_PIPELINE_SECRETS é o melhor resumo do que realmente precisa ser informado manualmente antes de o pipeline funcionar. Ele concentra um JSON por organização GitHub com credenciais como:

  • JIRA_API_TOKEN
  • JIRA_BASE_URL
  • JIRA_USER_EMAIL
  • OCI_CLI_CONFIG_BASE64
  • OCI_CLI_KEY_CONTENT_BASE64
  • OCI_CLI_TENANCY
  • OCI_CLI_USER
  • OCIR_USERNAME
  • OCIR_PASSWORD
  • OCI_AUTH_TOKEN
  • SONAR_TOKEN
  • ENCRYPTION_PASSWORD

Em outras palavras: Jira API keys, credenciais OCI CLI, dados de login no registry e parte dos segredos de automação de CI/CD não nascem no GitHub Actions. Eles precisam ser montados manualmente nesse secret do OCI Vault antes da primeira execução útil do pipeline.

GitHub: o que é manual e o que o Terraform cria depois

Existe uma diferença importante entre segredo manual e segredo materializado automaticamente.

O módulo infrastructure/modules/github-secrets lê três fontes do OCI Vault:

  1. O token GitHub usado para operar na organização.
  2. O JSON de GITHUB_PIPELINE_SECRETS da organização.
  3. O secret com as chaves de unseal e root_token do Vault.

A partir disso, o Terraform cria secrets de repositório no GitHub como:

  • VAULT_ADDR
  • VAULT_TOKEN
  • GH_BOT_TOKEN

Ou seja, esses valores não devem ser tratados como cadastro manual direto no GitHub UI. O passo manual correto é preencher o OCI Vault; o módulo Terraform replica para os repositórios quando aplicado.

Aplicações GitHub e integrações externas

Além dos secrets, alguns artefatos externos precisam existir antes de os módulos funcionarem corretamente.

ArgoCD

O módulo do ArgoCD depende de dois insumos manuais:

  1. Um OAuth App do GitHub para o Dex, cujo clientID e clientSecret vão para ESO_ARGOCD_DEX_CONFIG.
  2. Um GitHub App para acesso aos repositórios, cujo app ID, installation IDs por organização e private key vão para ESO_ARGOCD_GITHUB_APP.

Esse segundo secret é consumido pelo ExternalSecret que gera as credenciais de repositório no namespace do ArgoCD.

Runner OCI

O runner global em config/global/github-runner/config.hcl usa a variável de ambiente SECRET_ID. Ela aponta para um secret OCI que precisa existir antes do provisionamento do runner. Sem isso, a instância sobe sem o material necessário para autenticar e registrar o runner.

SonarQube

O módulo do SonarQube consome sonarqube_config_secret_id. Esse secret não carrega apenas senha e JDBC. Ele também precisa conter a configuração GitHub ALM em base64, porque o Terraform cria a integração com GitHub usando appId, clientId, clientSecret, key, privateKey e url extraídos desse conteúdo.

Sentry

O módulo do Sentry depende de sentry_config_secret_id e também de um GitHub App externo já criado. O chart consome chaves como:

  • github-private-key
  • github-webhook-secret
  • github-client-id
  • github-client-secret

Sem esse material, o release do Sentry até pode ser aplicado, mas a integração com GitHub fica incompleta.

Sequência recomendada de bootstrap

Uma ordem segura para subir um ambiente novo é:

  1. Criar os namespaces de tags OCI necessários.
  2. Criar o vault global e a master-key.
  3. Criar o bucket de state remoto.
  4. Criar e preencher os secrets manuais no OCI Vault.
  5. Criar os GitHub Apps, OAuth Apps, PATs e tokens externos necessários.
  6. Atualizar os arquivos .hcl com os OCIDs e nomes corretos do novo ambiente.
  7. Rodar primeiro os stacks globais.
  8. Validar que GitHub secrets, ESO e workloads passaram a consumir os secrets corretamente.

Referências rápidas

  • Formatos completos de secrets: ../secrets/bootstrap.md
  • GitHub Apps, OAuth Apps e segredos GitHub: ../secrets/github.md
  • Fluxo do pipeline de infraestrutura: ../pipelines/infra-pipeline.md
  • Consumo posterior no cluster via ESO: ../vault/eso-secrets.md