DEV Community: César Augusto de Fázio

Tudo sobre OCI Resource Manager: Automatize sua Infraestrutura de Nuvem

César Augusto de Fázio — Thu, 27 Aug 2026 16:30:32 +0000

O que é o OCI Resource Manager?
O OCI Resource Manager é um serviço totalmente gerenciado da Oracle Cloud Infrastructure que automatiza o provisionamento de recursos utilizando o Terraform. Ele armazena o estado da infraestrutura (.tfstate) de forma centralizada e segura, oferece travamento automático de estado (state locking), integra-se com repositórios Git e executa planos de automação sem depender das máquinas dos desenvolvedores.

Lidar com conflitos de estado no Terraform é quase um rito de passagem para qualquer profissional de DevOps ou Engenharia de Infraestrutura. Se você já trabalhou em equipe sem uma estratégia sólida de travamento de estado, certamente já se deparou com o famoso erro de state lock ou, na pior das hipóteses, com a péssima sensação de ter sobrescrito as alterações do seu colega… ou do seu chefe.

O problema central do Terraform tradicional não é o código em si, mas lidar com o arquivo .tfstate. Ele guarda o estado desejável da sua infraestrutura. Se duas pessoas executam o comando terraform apply ao mesmo tempo na mesma infraestrutura com um estado local, o resultado costuma ser catastrófico.

É exatamente aí que entra o OCI Resource Manager. Com ele, você escreve sua infraestrutura em Terraform e a Oracle Cloud executa as ações por você dentro do próprio console ou via CLI/API: de forma gerenciada, escalável, com controle de acesso granular e sem complicações.

Por que usar o OCI Resource Manager?

Vamos comparar a experiência tradicional do Terraform rodando na sua máquina com o modelo gerenciado do OCI Resource Manager. O OCI Resource Manager conta tanto com uma interface gráfica do console quanto com uma CLI.

O que você fazia antes...	O que o OCI Resource Manager faz por você
Escrevia o código (Terraform) no seu computador e editava as mudanças manualmente em um repositório local.	Você escreve o código uma única vez e faz o upload para a nuvem. Quando for editar, pode fazê-lo tanto via repositório local quanto via console.
Instalava Terraform na sua máquina.	Acessa um serviço da própria Oracle pelo navegador ou pelo CLI.
Salvava o arquivo de senhas e chaves em uma pasta no seu PC.	Você cadastra as senhas dentro do serviço, de forma segura e escondida (integrando ao OCI Vault).
Digitava comandos no terminal (`terraform plan` e `terraform apply`) para ver o que ia mudar e depois aplicar.	Você clica em botões: "Plan" (simula a mudança) e "Apply" (aplica a mudança).
Guardava o "mapa" da sua infraestrutura (o famoso state file) em uma pasta local ou num bucket.	O serviço guarda esse mapa automaticamente para você. Não precisa se preocupar com isso.
Tinha que lembrar qual versão do Terraform estava usando.	O serviço já oferece suporte com as versões atualizadas. Você só se preocupa com o código.
Se alguém mais tentasse mexer ao mesmo tempo, dava conflito e você precisava resolver na mão.	O serviço tranca a execução automaticamente. Se um já está rodando, o próximo espera na fila.
O histórico do que foi feito ficava só no seu terminal (se você fechou, perdeu).	Fica um histórico completo dentro do serviço. Você pode ver o que foi feito na semana passada, por quem, e deu certo ou errado.

Em resumo, o OCI Resource Manager é um espaço seguro dentro da nuvem da Oracle onde você coloca seus códigos de infraestrutura (Terraform). Em vez de apenas rodar comandos no seu computador, você tem a opção de visualizar tudo pelo console. Ele guarda todo o histórico, cuida das senhas por você, e impede que duas pessoas mexam ao mesmo tempo e bagunce tudo.

Conceitos-Chave do OCI Resource Manager

Para entendermos melhor o OCI Resource Manager, precisamos nos familiarizar melhor com seus recursos e dependências.

1. Configuration Source Provider

É o melhor ponto de conexão entre o Resource Manager e onde o seu código Terraform reside. Em vez de fazer upload manual de arquivos, você pode conectar o OCI diretamente ao seu provedor de controle de versão (VCS).

Há suporte para:

Repositórios Git Públicos e Privados: GitHub, GitLab, Bitbucket Cloud e Bitbucket Server.
OCI DevOps Code Repository: O repositório nativo de código da Oracle Cloud.
Repositórios On-Premises ou Privados: Conexão segura via Private Endpoints dentro da sua VCN.

2. Configuration

Trata-se do conjunto de arquivos Terraform (com extensões .tf ou .tf.json). Uma configuração válida é composta por três elementos principais:
Variables (variables.tf): Parâmetros dinâmicos que podem ser ajustados via console ou arquivo .tfvars.
Resources (main.tf): Os componentes de nuvem que você deseja criar (por exemplo: instâncias, redes, bancos de dados).
Providers (providers.tf): A declaração dos provedores (especialmente o Provider OCI).

3. Stacks

A Stack é o coração do OCI Resource Manager. Ela isola e representa um conjunto de recursos da OCI agrupados para gerenciar um ciclo de vida comum. Dentro de uma Stack você encontra:

O código Terraform (vindo de um repositório Git, uma pasta do seu computador ou pacote .zip).
O arquivo de estado atualizado (.tfstate).
As variáveis configuradas para aquele ambiente (Dev, Staging, Prod).
O histórico completo e os logs das execuções (jobs) passadas.

Importante: quando você criar sua stack, não necessariamente ela precisa ter um .tfstate importado. Deixe que a OCI cuide de criar isso para você.

a) Actions (Ações disponíveis nas Stacks)

As ações representam o ciclo de vida do Terraform executado na nuvem:

Plan: Compila a configuração e mostra as mudanças planejadas sem alterar a nuvem.
Apply: Aplica as alterações aprovadas e provisiona os recursos declarados.
Destroy: Remove todos os recursos gerenciados por aquela Stack.
Drift Detection: Compara a infraestrutura real com o arquivo de estado e aponta recursos que foram alterados manualmente fora do OCI Resource Manager.
Import State: Permite trazer recursos já existentes na OCI para dentro da gestão da Stack. Também permite trazer os recursos que foram alterados manualmente como parte da Stack.

b) Jobs

Cada vez que você dispara uma Action (como um Plan ou Apply), o OCI Resource Manager cria um Job. O Job passa pelos seguintes status:

Accepted -> In Progress -> Succeeded / Failed

(Em caso de interrupção: Cancelling -> Cancelled).

4. Templates

São configurações Terraform pré-prontas que facilitam o provisionamento rápido de arquiteturas complexas.

Templates Criados pela Oracle

Soluções prontas para subir clusters Kubernetes (OKE), bancos de dados Autonomous DB ou redes completas com poucos cliques.

Os templates estão disponíveis diretamente no Console da Oracle Cloud e na documentação oficial. Ao criar um novo Stack no serviço Resource Manager, você poderá navegar e selecionar entre diversos templates fornecidos pela Oracle.

Aqui estão alguns dos repositórios mais relevantes mantidos pela Oracle e pela comunidade:

Repositório (Organização)	Descrição
oracle-quickstart	Esta é a organização oficial da Oracle para "quick starts". Aqui você encontra exemplos prontos para diversos cenários, como deployments de aplicações e integrações com soluções de terceiros.
oracle-japan	Este repositório contém um template da comunidade da Oracle no Japão, focado em preparar o ambiente para um hands-on do OKE (Oracle Container Engine for Kubernetes). É um ótimo exemplo de como a comunidade contribui.

Templates Privados

Modelos padronizados criados pela sua própria equipe para reutilização em diferentes projetos ou clientes.

Como Utilizar

Vamos passar agora para um exemplo prático. Suponha que você queira criar uma VCN (Virtual Cloud Network) e uma Subnet na Oracle Cloud utilizando o OCI Resource Manager.

Passo 1: Definir o Código Terraform

Crie um arquivo chamado main.tf com o seguinte conteúdo:

# provider.tf / main.tf - Declaracao de VCN e Subnet simples na OCI

terraform {
  required_version = ">= 1.0.0"
  required_providers {
    oci = {
      source  = "oracle/oci"
      version = ">= 4.0.0"
    }
  }
}

variable "compartment_ocid" {
  type        = string
  description = "OCID do Compartment onde os recursos serão criados"
}

variable "vcn_cidr" {
  type        = string
  default     = "10.0.0.0/16"
  description = "Bloco CIDR da VCN"
}

resource "oci_core_vcn" "impacto_vcn" {
  compartment_id = var.compartment_ocid
  cidr_blocks    = [var.vcn_cidr]
  display_name   = "VCN-Automated-ORM"
  dns_label      = "impactovcn"
}

resource "oci_core_subnet" "public_subnet" {
  compartment_id    = var.compartment_ocid
  vcn_id            = oci_core_vcn.impacto_vcn.id
  cidr_block        = "10.0.1.0/24"
  display_name      = "Subnet-Publica"
  dns_label         = "publicsub"
  security_list_ids = [oci_core_vcn.impacto_vcn.default_security_list_id]
}

output "vcn_id" {
  value = oci_core_vcn.impacto_vcn.id
}

Não esqueça de criar seu próprio variables.tf com suas variáveis OCID do seu próprio OCI para subir sua stack.

Passo 2: Criar a Stack no Console OCI

Acesse o Console da Oracle Cloud e navegue até Developer Services > Resource Manager > Stacks.

Selecione o Compartment correto onde a Stack será gerenciada. Depois clique em Create Stack.

Escolha a fonte da sua configuração. Faça upload de um arquivo .zip contendo seu código Terraform, ou conecte a um repositório Git (GitHub, GitLab, OCI DevOps).

Boa prática: Dê nome e descrição à sua Stack, adicione Tags que ajudem a identificar e monitorar a Stack via OCI Notifications e outros serviços.

Configure as variáveis: O Resource Manager identificará a variável compartment_ocid e permitirá que você selecione o Compartment em uma lista suspensa.

Clique em Next e finalize a criação.

Passo 3: Executar Plan e Apply

Na página da Stack criada, clique no botão Plan. Aguarde o Job mudar de In Progress para Succeeded e revise os logs para confirmar os recursos que serão criados.

Após validar o plano, clique em Apply.

O OCI Resource Manager executará o provisionamento e travará o estado durante o processo. Ao final, você verá as saídas (outputs) com os IDs da VCN e da Subnet recém-criadas.

Quando usar o OCI Resource Manager?

Se a sua empresa tem:

Times multidisciplinares (Devs, Redes, Banco de Dados).
Auditoria pesada (Bancos, Governo, Seguros) que exigem rastro imutável de quem aprovou cada mudança.
Uma equipe central de Cloud Platform que quer entregar infraestrutura como serviço, sem dar chaves de API na mão dos times.

...então o OCI Resource Manager torna-se muito superior ao Terraform CLI, porque ele transforma IaC de um exercício de linha de comando em um portal de autosserviço.

Se você precisa de Governança, Segurança e Rastreabilidade, o OCI Resource Manager é perfeito para seu compliance corporativo.

Conclusão

O OCI Resource Manager resolve de forma nativa e elegante um dos maiores gargalos das equipes de DevOps: a gestão descentralizada do arquivo de estado do Terraform. Ao abstrair o backend remoto e centralizar as execuções diretamente na nuvem da Oracle, ele garante segurança, rastreabilidade e elimina os riscos de concorrência.

Se você já utiliza ou planeja utilizar a Oracle Cloud Infrastructure, adotar o Resource Manager é o passo natural para amadurecer sua governança de Infraestrutura como Código (IaC) sem precisar investir tempo configurando infraestruturas de CI/CD complexas apenas para rodar o Terraform.

Perguntas Frequentes (FAQ)

1. O OCI Resource Manager cobra pelo uso?

Não. O OCI Resource Manager é um serviço gratuito fornecido pela Oracle Cloud Infrastructure. Você paga apenas pelos recursos de infraestrutura (como instâncias, volumes e bancos de dados) que o Terraform provisiona na sua conta.

2. Posso usar módulos externos do Terraform Registry no Resource Manager?

Sim. Se o seu código Terraform referenciar módulos públicos ou privados, o Resource Manager fará o download das dependências automaticamente durante a fase de inicialização do Job (como seria com terraform init).

3. O que acontece se duas pessoas tentarem rodar um Apply na mesma Stack?

O Resource Manager possui um sistema nativo de State Locking. O segundo Job entrará em fila ou será recusado até que o primeiro Job seja concluído, evitando corrupção de estado ou sobrescrita acidental de recursos.

4. O que é e para que serve o Drift Detection no OCI Resource Manager?

O Drift Detection compara a infraestrutura configurada no arquivo de estado (.tfstate) com o estado real dos recursos na nuvem. Ele gera um relatório identificando se alguém fez alterações manuais (via console da OCI) fora do Terraform.

5. Posso importar uma infraestrutura que já existe na OCI para o Resource Manager?

Sim. Você pode utilizar a funcionalidade Import State dentro da Stack para mapear recursos já existentes no seu Compartment para o estado do Terraform gerenciado pelo Resource Manager.

OCI Cost Anomaly Detection

César Augusto de Fázio — Wed, 12 Aug 2026 15:23:30 +0000

Chega de esperar até o final do mês para saber quanto a nuvem gastou ou vigiar todo dia em busca de picos de gastos. O OCI Cost Anomaly Detection é uma nova funcionalidade gratuita que monitora os custos em tempo real, identifica gastos fora da curva e alerta imediatamente por e-mail.

O OCI Cost Anomaly Detection é um recurso gratuito da Oracle Cloud Infrastructure que utiliza modelos de aprendizado de máquina para analisar padrões de consumo na tenancy, prever custos diários e identificar desvios atípicos de gastos. Ele permite criar monitores personalizados e enviar alertas automáticos por e-mail quando os limites configurados são ultrapassados.

Vamos falar um pouco mais sobre essa ferramenta.

Visão Geral do OCI Cost Anomaly Detection

Antes de começar, vamos entender os três conceitos principais: Monitoramento, Detecção e Alerta.

Cost Monitor

Define o que será analisado. O OCI já possui monitores padrão para cada combinação de tenancy, serviço e região. Por exemplo, monitorar toda a tenancy, um serviço específico como Compute, ou recursos com uma tag específica.

Algoritmo de Detecção

O OCI Cost Anomaly Detection usa machine learning para prever o custo diário (ou semanal, anual…). Ele detecta anomalias quando o custo real se desvia significativamente do previsto.

Alert Subscriptions

Você escolhe quando e para quem enviar notificações por e-mail, baseados em um limite de variação absoluto (em moeda) e/ou percentual (%).

Uma rápida comparação entre OCI Cost Anomaly Detection vs. OCI Budgets

Você pode estar pensando: "para quê vou usar esta ferramenta? Já tenho isso com OCI Budgets".

Funcionalidade	OCI Cost Anomaly Detection	OCI Budgets
Método de Análise	Aprendizado de máquina (padrões comportamentais)	Limite fixo definido manualmente
Gatilho de Alerta	Desvios inesperados em relação à previsão	Porcentagem fixa do orçamento atingida
Caso de Uso Principal	Identificar recursos esquecidos e picos atípicos	Controlar o teto financeiro do mês
Custo do Serviço	Gratuito	Gratuito

Configurando o OCI IAM

Para criar e visualizar monitores de anomalia, você precisa de permissões no nível da Tenancy (Root Compartment). Como esses recursos atuam em toda a infraestrutura, permissões concedidas em outros compartimentos não funcionam.

Para criar a política:

No console do OCI, acesse Identity & Security > Policies.
Confirme se está no Compartimento Root da Tenancy.
Clique em Create Policy.

Política para Administradores:

Allow group <nome_do_seu_grupo> to manage costad-family in tenancy
Allow group <nome_do_seu_grupo> to read usage-report in tenancy
Allow group <nome_do_seu_grupo> to read organizations-family in tenancy

Política apenas para Visualização (Read-Only):

Allow group <nome_do_seu_grupo> to read costad-family in tenancy
Allow group <nome_do_seu_grupo> to read usage-report in tenancy
Allow group <nome_do_seu_grupo> to read organizations-family in tenancy

Menu do OCI Cost Anomaly Detection

No menu de navegação do console, entre em Billing & Cost Management e clique em Cost Anomaly Detection.

Cost Anomalies

Lista todas as anomalias detectadas pelo sistema, mostrando a data do evento, o desvio estimado em valor monetário e o monitor responsável pela identificação.

Cost Monitors

Aqui estão seus detectores de custo. O OCI cria um monitor padrão listando todos os recursos da sua tenancy.

Você pode criar um monitor personalizado para analisar um grupo específico de recursos. Por exemplo, apenas o compartimento de desenvolvimento ou apenas recursos com uma tag específica.

Lembre-se: um novo monitor precisa de 60 dias de dados históricos para começar a funcionar e detectar anomalias.

Notification Groups

Cada detector de custos pode enviar alertas e notificações. Se uma anomalia for detectada e a variação de custo exceder o limite de alerta, um alerta por e-mail será enviado ao grupo de notificação. Um e-mail é enviado uma vez por dia para cada evento de anomalia.

Criando um Cost Monitor no OCI

Em Billing & Cost Management, Cost Anomaly Detection, clique em Cost Monitors. No meu exemplo, vou criar um Cost Monitor para detectar Load Balancers, porque o Terraform nunca se livra deles, então monitorá-los me avisa de que devem ser deletados antes que seja tarde.

Selecione Tenancy e Compartimento alvo!

Quais recursos posso monitorar? Aqui estão alguns exemplos.

Posso monitorar o Load Balancer por hora e se ele estiver ligado por duas boas horas (não costumo usar Load Balancers na minha Tenancy), o sistema me avisa.

Em um ambiente de produção, você pode fazer melhor do que eu e monitorar a taxa fixa de disponibilidade do Load Balancer e o custo variável por banda do Load Balancer.

Em seguida, prepare a notificação.

Você então atribui o alerta a um grupo de notificações ou cria um novo.

Passo a passo de criação:

Acesse Billing & Cost Management > Cost Anomaly Detection e clique em Cost Monitors.
Clique em Create Cost Monitor.
Selecione a Tenancy e o Compartimento onde os recursos estão alocados.
Defina os critérios de filtro. Em um ambiente de testes, você pode filtrar pelo serviço de Load Balancer para detectar alterações em intervalos curtos.
Já em ambientes de produção, vale a pena detalhar a análise monitorando tanto a taxa fixa de disponibilidade do Load Balancer quanto o custo variável associado ao consumo de banda.
Configure as regras do limite de alerta por valor percentual ou absoluto.
Por fim, vincule o monitor a um Notification Group existente ou cadastre os e-mails da sua equipe de operações para receber os alertas.

Perguntas Frequentes (FAQ)

O que é o OCI Cost Anomaly Detection?

É um recurso nativo e gratuito da Oracle Cloud Infrastructure que utiliza machine learning para monitorar hábitos de consumo, identificar picos anômalos de gasto e enviar alertas automáticos por e-mail.

O serviço OCI Cost Anomaly Detection é gratuito?

Sim. O OCI Cost Anomaly Detection não possui custos adicionais. Ele está disponível para todas as contas e tenancies do OCI sem cobrança por monitor criado ou e-mail enviado.

Qual é a diferença entre OCI Budgets e Cost Anomaly Detection?

O OCI Budgets trabalha com um valor fixo definido pelo usuário (como um teto de gastos mensal). O Cost Anomaly Detection usa inteligência artificial para detectar desvios em relação à média histórica, identificando picos inesperados mesmo que você ainda esteja dentro do orçamento global.

Quanto tempo um novo Cost Monitor leva para começar a disparar alertas?

O algoritmo precisa de um histórico contínuo de uso (até 60 dias de telemetria) para treinar o modelo e estabelecer o que é considerado um gasto regular na sua conta.

CI/CD Pipeline na Oracle Cloud com GitOps

César Augusto de Fázio — Fri, 31 Jul 2026 15:21:04 +0000

Depois de lidar com uns trinta bloqueios no SonarQube, tratar vulnerabilidades com Trivy e resolver race conditions no Terraform, implementando uma pipeline CI/CD na Oracle Cloud Infrastructure (OCI) com GitHub Actions, ArgoCD e Oracle Container Registry (OCIR).

Trago aqui uma pipeline de CI/CD com GitOps para Kubernetes (OKE) que combina GitHub Actions, SonarQube para análise estática, Trivys, OCIR e ArgoCD (com ArgoCD Image Updater). O Terraform provisiona a infraestrutura em camadas para evitar problemas.

Arquitetura da Build Pipeline

A pipeline de build é dividida em 4 partes:

Testes Unitários: O GitHub Actions usa pytest com relatório de cobertura de código.
Análise de Qualidade: O SonarQube valida o código e bloqueia a build caso não atinja a qualidade que ele espera.
Análise de Segurança: O Trivy escaneia o sistema de arquivos e as imagens de contêiner em busca de vulnerabilidades.
Containerização e Publicação: A imagem da aplicação é gerada e enviada ao Oracle Container Registry (OCIR).

Deploy Pipeline: Entrega Contínua com GitOps

Em vez de executar scripts manuais de implantação ou chamadas diretas via kubectl, a entrega da aplicação usa GitOps.

O cluster Oracle Kubernetes Engine (OKE) roda o ArgoCD e o ArgoCD Image Updater.
O ArgoCD Image Updater vigia o repositório OCI Registry em busca de novas tags de imagem.
Ao detectar uma nova imagem, o repositório Git de manifesto é atualizado automaticamente.
O ArgoCD aplica o estado desejado no cluster Kubernetes sem intervenção humana direta nem permissão de escrita do GitHub Actions no cluster.

Provisionamento com Terraform em 4 Camadas

O Terraform só valida se o recurso existe na API do Kubernetes naquele instante, não se ele está funcional e reconciliado. É aí que mora a race condition.

Para resolver isso, os manifestos foram dividida em quatro camadas independentes executadas em ordem:

Camada	Nome	Responsabilidade	Dependência
01	`01-infra`	Redes e o cluster OKE	VCN (que eu já criei antes)
02	`02-k8s-base`	Instalação do ArgoCD via Helm	Requer cluster OKE ativo
03	`03-k8s-addons`	Configuração do ArgoCD Image Updater	Requer ArgoCD instalado
04	`04-apps`	Manifestos de aplicações e rotas do ArgoCD	Requer ArgoCD e Addons prontos; Container Registry (que eu já criei manualmente)

Dividi os arquivos .tf em pastas distintas e executei o terraform apply sequencialmente para que a API do Kubernetes se preparasse para receber recursos do Helm antes e configurasse a aplicação dos manifestos depois.

Aprendizados

1. Hash no SonarQube e GitHub Actions

O SonarQube recusava meu código para atender a critérios rigorosos de segurança e reprodutibilidade. Entendi que as ações do GitHub Actions devem ser referenciadas pelo hash commit completo em vez de tags mutáveis de versão:

# Recomendado: Imutável e seguro contra Supply Chain Attacks
- uses: actions/checkout@1e31de5234b9f8995739874a8ce0492dc87873e2

# Evitar em produção: Tags podem ser alteradas no repositório de origem
- uses: actions/checkout@v4.0.0

O mesmo princípio aplica-se ao pip, fixando o hash dos pacotes via pip-compile --generate-hashes para impedir a execução de dependências adulteradas.

2. Trivy

Imagens padrão muitas vezes tem vulnerabilidades a nível do sistema operacional. Para evitar falhas na verificação do Trivy sem comprometer o pipeline de CI/CD, o melhor seria usar ChainGuard. Na ausência deste, o melhor é utilizar imagens base minimalistas como Distroless ou Alpine Linux.

3. Execução sem Privilégios no Dockerfile (Non-Root User)

Os alertas do SonarQube também me mostraram que executar contêineres como root expõe o host a riscos de container escape. O Dockerfile deve explicitar a criação de um usuário sem privilégios administrativos:

FROM python:3.11-slim

RUN groupadd -r appgroup && \
    useradd -r -g appgroup -s /sbin/nologin appuser

WORKDIR /app
COPY . /app/

RUN chown -R appuser:appgroup /app && \
    chmod -R 755 /app

USER appuser

CMD ["python", "main.py"]

Por que utilizar Oracle Cloud Infrastructure (OCI)?

Custo-benefício: A OCI oferece alta performance com menor custo operacional.
Fim dos Noisy Neighbors: Cada OCPU entrega um núcleo físico exclusivo, o que evita quedas de rendimento por outras instâncias computacionais (noisy neighbors, ou vizinhos barulhentos).
Taxa de Egress: A OCI oferece 10 TB mensais de transferência de saída de dados sem custo adicional, além de taxas moderadas depois dos 10 TB.
Zero-Trust Networking: Redes VCN nativas e integração direta entre o OKE e o OCIR simplificam o isolamento do ambiente.

No Futuro

Graças à natureza granular dos manifestos Terraform, posso integrar mais recursos futuros.

Monitoramento e Observabilidade do Cluster

A própria infraestrutura do plano de controle do OKE coleta métricas automaticamente e as envia para o OCI Monitoring. Para um monitoramento aprofundado dos Pods, do estado dos objetos do cluster ou para clusters fora do OKE, utiliza-se o OCI Management Agent. Também pode-se usar Prometheus e Grafana/Zabbix. Para coletar stout e sterr, também pode-se usar OCI Kubernetes Monitoring Solution.

Segurança

Para uma segurança mais rígida e complementar ao Trivy, pode-se usar OCI Cloud Guard (que centraliza alertas de segurança em um único painel) e OCI Vulnerability Scanning Service (que analisa imagens de contêineres enviadas ao OCIR).

Aceito mais sugestões!

FAQ

O que é GitOps e qual a diferença para o CI/CD tradicional?

O GitOps é stateful: em vez do pipeline executar comandos diretamente no cluster, um agente interno monitora o repositório Git e aplica automaticamente as alterações. Enquanto em um CI/CD tradicional pode gerar desalinhamento se alguém alterar o ambiente de produção, no GitOps, o repositório Git sempre revela exatamente o código em produção.

Por que especificar hashes SHA-256 em dependências do GitHub Actions?

Anotar dependências com o SHA-256 garante imutabilidade. Se a tag de uma ação pública (ex: v4) for sobrescrita por um código malicioso, o uso do commit hash impede que o pipeline execute a versão comprometida.

Por que usar o ArgoCD Image Updater em vez de apenas ArgoCD?

O ArgoCD sozinho não atualiza tags automaticamente. O Image Updater automatiza a atualização de tags. Ele reduz a necessidade de o GitHub Actions ter permissão direta no cluster, melhorando a segurança.

Por que a infraestrutura foi dividida em pastas em vez de usar depends_on nos módulos do Terraform?

A separação física das pastas garante a inicialização sequencial e limpa. O uso do provedor Kubernetes/Helm no Terraform exige que o endpoint da API do Kubernetes já esteja acessível durante a fase de planejamento (terraform plan). Se o cluster OKE e as rotas Helm estiverem no mesmo estado/pasta, o terraform apply falhará na primeira execução porque o provedor tentará se conectar a uma API que ainda nem existe.

Por que optar pelo OKE em vez de provisionar um cluster Kubernetes "do zero" (Unmanaged) via Terraform na OCI?

O OKE é um serviço gerenciado onde a Oracle arca com os custos e a manutenção do Control Plane (Master Nodes), garantindo alta disponibilidade, atualização de versão da API e integração nativa com o OCI Registry e Load Balancers. Isso economiza horas de administração de infraestrutura e reduz os custos operacionais.

Enterprise AI na OCI Dedicated Cloud: Guia Completo e Funcionamento

César Augusto de Fázio — Sat, 25 Jul 2026 00:01:54 +0000

A Oracle expandiu suas capacidades de Inteligência Artificial para a OCI Dedicated Cloud, permitindo a execução de cargas de trabalho de IA generativa diretamente no data center do cliente. Essa infraestrutura atende a requisitos rígidos de soberania de dados, governança e conformidade em setores altamente regulados.

Enterprise AI na OCI Dedicated Cloud combina serviços de IA generativa gerenciados pela Oracle com a infraestrutura dedicada rodando dentro do data center do cliente. Ela oferece isolamento físico dos dados, latência em milissegundos e controle total de conformidade, mantendo o mesmo plano de gerenciamento e ferramentas da nuvem pública OCI.

O que é Enterprise AI e OCI Dedicated Cloud?

Enterprise AI (IA Empresarial) engloba soluções de inteligência artificial projetadas para grandes organizações, com foco em automação, governança, segurança e alinhamento com dados internos.

Diferente de ferramentas voltadas ao consumidor, a IA para empresas funciona integrada a sistemas legados (ERPs, CRMs e bancos de dados) sob rigorosos controles de privacidade.

A OCI Dedicated Cloud (ou Dedicated Region) é a entrega de toda a infraestrutura da Oracle Cloud Infrastructure como uma região dedicada de uso exclusivo, instalada fisicamente na infraestrutura indicada pelo cliente.

Característica	OCI Pública	OCI Dedicated Cloud
Localização física	Data centers da Oracle	Data center do cliente
Isolamento	Lógico (multitenant)	Físico e lógico (single-tenant)
Latência	Variável pela distância	Ultrabaixa (local)
Soberania de dados	Restrita às regiões fiscais	Total (dados mantidos no perímetro)
Catálogo de serviços	Todos os serviços OCI	Idêntico à nuvem pública (100+ serviços)
Modelo de cobrança	Faturamento por uso	Consumo com compromisso mínimo

A gestão da infraestrutura continua a cargo da equipe de engenharia da Oracle. Alertas automáticos acionam o suporte técnico para substituição presencial da peça mediante autorização do cliente.

Recursos de IA e Opções de Modelos

A infraestrutura dedicada suporta implantações de modelos de linguagem de grande porte (LLMs) em hardware acelerado, incluindo GPUs dedicadas.

O ambiente inclui suporte a:

Modelos avançados: Suporte ao NVIDIA Nemotron 3 Ultra e modelos abertos como Qwen e Gemma.
Recuperação e reordenamento: Cohere Rerank 4 para arquiteturas RAG (Retrieval-Augmented Generation).
Clusters dedicados: Execução sob demanda ou em ambientes de computação isolados.

A OCI Dedicated Cloud é Air-Gapped?

Não, a OCI Dedicated Cloud exige uma conexão de rede com a nuvem pública da Oracle para separar duas camadas, o Control Plane e o Data Plane.

Control Plane (Plano de Controle): Gerencia a infraestrutura, atualizações de software e telemetria remota por meio de conexões criptografadas.
Data Plane (Plano de Dados): Processa e armazena os dados do cliente exclusivamente no perímetro da rede local.

Os dados e sistemas da empresa não transitam pela internet pública, apenas a gestão de infraestrutura.

Fonte

Opção Air-Gapped: OCI Isolated Region

Para cenários militares, agências de inteligência ou governos que exigem isolamento absoluto de rede, a Oracle disponibiliza a OCI Isolated Region. Esse modelo é desconectado da internet e é mantido por equipes técnicas com credenciamento de segurança específico.

Como configurar a CLI e o Terraform para OCI Dedicated Cloud

Como a OCI Dedicated Cloud opera em um Realm dedicado, as chamadas de API devem ser direcionadas para os endpoints específicos do ambiente local em vez das URLs padrão da nuvem pública.

Ajuste no arquivo de configuração da OCI CLI

No arquivo de configuração local (~/.oci/config), defina o endpoint do realm correto:

[DEFAULT]
user=ocid1.user.oc1..example
fingerprint=xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx
key_file=~/.oci/oci_api_key.pem
tenancy=ocid1.tenancy.oc1..example
region=us-ashburn-1
# Adicione o endpoint especifico do Realm Dedicado
endpoint=https://iaas.<realm-domain>.oraclecloud.com

Configuração do Provedor no Terraform

No provedor Terraform, especifique o parâmetro de customização de endpoints para redirecionar as chamadas para a Dedicated Region:

# A melhor prática
provider "oci" {
  realm_specific_service_endpoint_template_enabled = true
}

# Se não funcionar
provider "oci" {
  endpoints = {
    iaas = "https://iaas.<seu-realm-domain>.oraclecloud.com"
  }
}

Essa configuração é especialmente importante para serviços como o Object Storage, que podem ter padrões de endpoint diferentes.

Se você não inserir nenhuma dessas informações, somente com as suas credenciais e sua região, o sistema é capaz de inferir que você pertence a uma realm e a qual, mas a preferência é sempre explicitar ao Terraform com realm_specific_service_endpoint_template_enabled.

FAQ: Dúvidas Frequentes sobre OCI Dedicated Cloud

O que é OCI Dedicated Cloud?

A OCI Dedicated Cloud é uma solução em que a Oracle instala e gerencia uma região completa da Oracle Cloud Infrastructure dentro do data center do cliente, garantindo uso 100% dedicado, isolamento físico e controle total sobre a residência dos dados.

A OCI Dedicated Cloud é air-gapped (totalmente isolada da internet)?

Não. A OCI Dedicated Cloud padrão mantém uma conexão segura com a nuvem da Oracle para o plano de controle (gerenciamento e patches). No entanto, o plano de dados permanece 100% dentro do perímetro local do cliente.

Qual a diferença entre OCI Dedicated Cloud e OCI Isolated Region?

A OCI Dedicated Cloud possui conexão para gerenciamento remoto do plano de controle. A OCI Isolated Region é totalmente desconectada da internet (air-gapped), projetada para defesa e segurança nacional, com operação local por pessoal credenciado.

Posso usar as mesmas ferramentas de automação da nuvem pública?

Sim. Conceitos como Tenancies, Compartments, VCNs e IAM permanecem idênticos. OCI CLI, Terraform e SDKs funcionam da mesma forma, exigindo apenas a alteração dos URLs de endpoint no arquivo de configuração do Realm dedicado.

Além do Prompt: Por que decidi ir a fundo no ONE AI For Tech e na OCI

César Augusto de Fázio — Mon, 13 Jul 2026 20:12:42 +0000

Vamos ser sinceros: o mercado já saturou de rodar o ChatGPT. O desafio atual da engenharia de software é construir sistemas autônomos, integrados e que resolvam dores reais de negócio sem falir a empresa com o consumo de tokens.

Eu confesso que adiei o quanto pude os meus estudos focados em IA. Queria garantir que a minha base de infraestrutura, nuvem e engenharia de software estivesse sólida primeiro. Enquanto a maioria fez o caminho inverso (correu para a IA sem nem saber como funciona um banco de dados e hoje vive refém de prompts mágicos), eu esperei.

Esse momento chegou com o ONE AI For Tech, uma parceria entre Oracle, Alura e FIAP. Decidi entrar de cabeça porque a proposta deles bate exatamente com o que eu acredito: menos hype de prompts e mais arquitetura de sistemas inteiros. Vou te contar como está sendo essa experiência.

O que é o ONE AI For Tech?

Para contextualizar, essa é uma formação prática e gratuita do programa Oracle Next Education (ONE). O foco é preparar profissionais para o mundo real de IA Gen, Agentes Inteligentes e automação. O programa começou em maio com duas imersões intensivas e agora entrou na fase Tech AI Builder, onde o bicho pega de verdade: usamos IA Generativa e a infraestrutura da Oracle Cloud Infrastructure (OCI) para criar soluções de ponta.

As Duas Primeiras Imersões

Para me aquecer, passei por duas etapas que somaram o low-code à IA. Isso foi o que rolou:

1. A Imersão IA (Alura)

O objetivo aqui foi construir um sistema multiagentes autônomo voltado para o mercado de trabalho. Dividido em 4 dias intensivos, o ecossistema funcionava assim:

Aula 01: Criamos o agente coordenador do sistema.
Aula 02: Desenvolvemos um segundo agente focado em varrer a internet atrás de vagas alinhadas com o usuário.
Aula 03: Um terceiro agente entrava em ação para analisar o perfil do profissional, achar os gaps de conhecimento e montar um plano de estudos personalizado.
Aula 04: Integração final. Foram três agentes cooperando entre si (um caçando vagas, outro analisando perfis e o terceiro desenhando o plano).

2. A Imersão ONE

Aqui o foco mudou para a maturidade da aplicação: RAG, transformação de documentos em embeddings e automação.

Aprendemos conceitos de chunking (fragmentação de texto) e usamos o n8n para criar fluxos de ingestão de dados.

Depois conectamos a IA a um banco MySQL, misturando dados estruturados (SQL) com não estruturados (RAG) para dar respostas mais personalizadas.

Enfim, conectamos tudo à API do Telegram via Webhooks, aplicando travas de segurança (guardrails) e gerenciando o contexto por ID de sessão.

Startups Tentam Vender o que Eu Construí em Dias

Pare e pense comigo por um segundo. Nessas duas imersões, eu saí com um produto pronto na mão; exatamente o tipo de Chatbot com RAG e leitura de banco de dados que muitas startups ambiciosas tentam vender a preço de ouro em eventos de tecnologia.

Só que chatbots simples não trazem retorno real. O que dá ROI de verdade são sistemas agênticos complexos que resolvem gargalos operacionais.

E é exatamente aí que entra a segunda fase da trilha: o Tech AI Builder. É um cardápio completo (e não obrigatório, você monta sua estratégia) composto por 5 formações:

Nivelamento (Machine Learning e Python)
Desenvolvimento e Orquestração com IA Generativa (SDD e Context Engineering)
Engenharia de Agentes e Automação com IA (Unindo n8n, APIs e workflows avançados)
Inteligência de Dados e RAG Avançado
Oracle Cloud Infrastructure (OCI) para gerenciar tudo isso na nuvem.

O desafio final é criar um sistema agêntico que rode usando o OCI.

Mas afinal, o que diabos é um "Sistema Agêntico"?

Ao contrário de um chatbot tradicional que apenas reage a comandos, um sistema agêntico é uma arquitetura onde a IA tem autonomia para perceber o ambiente, tomar decisões, acionar ferramentas externas (como APIs e bancos de dados) e executar tarefas complexas em sequência para atingir um objetivo, sem precisar de supervisão humana a cada clique.

Ao invés de esperar resposta do prompt, as IAs resolvem problemas de forma autônoma.

A Armadilha do Hype e o Dreno de Tokens

Muitas empresas enfiam IA em tudo quanto é canto só para agradar investidores ou surfar a onda. Isso vira um dreno financeiro danado.
A IA consome token, e muitos tokens custam caro. Se a aplicação não justificar sua existência gerando ROI claro (seja aumentando receita ou reduzindo custos operacionais), ela é só desperdício de capital.

Inclusive, abordei exatamente esse ponto na palestra que dei recentemente no TDC AI Summit.

Por que a OCI e não outra nuvem?

A Oracle Cloud Infrastructure (OCI) se destaca muito. Para processar modelos pesados, você precisa de performance bare metal, que é a especialidade do OCI. Além disso, a OCI tem o melhor custo-benefício do mercado em taxas de egress (saída de dados), o que protege a saúde financeira da aplicação a longo prazo.

Sou um defensor do modelo híbrido e de estratégias multi-nuvem. Vejo a OCI como a melhor opção para rodar workflows complexos (e caros!) em nuvem, combinada com ambientes on-premise dedicados para aqueles dados ultra sensíveis que exigem isolamento estrito, governança e conformidade severa.

A jornada no Tech AI Builder está só começando, e o desafio agora é mpntar uma arquitetura de alta performance. Vamos ver até onde essa toca do coelho vai.

Conclusão

Construir produtos inteligentes é sobre arquitetura, custo-benefício e entrega de valor real. A infraestrutura de nuvem, a orquestração de agentes e o controle de custos é o que vai pesar a partir de agora.
No final das contas, o ONE AI For Tech vale a pena por um motivo bem prático: ele trata a IA pelo que ela realmente é: uma engrenagem (bem complexa, por sinal) dentro da arquitetura de software moderna.

O objetivo é garantir que quando você decidir plugar um modelo de linguagem no seu produto, você saiba gerenciar a latência, proteger a privacidade dos dados e, principalmente, evitar que a fatura da nuvem vire um pesadelo de custos impossíveis de justificar para o negócio.

Perguntas Frequentes (FAQs)

O que é o ONE AI For Tech?

O ONE AI For Tech é uma formação prática, gratuita e imersiva focada no desenvolvimento de soluções utilizando Inteligência Artificial, Agentes Inteligentes e computação em nuvem. Trata-se de uma especialização que faz parte do programa Oracle Next Education (ONE), realizada em uma parceria estratégica entre a Oracle, a Alura e a FIAP.

Quem pode participar do programa?

O programa é desenhado tanto para iniciantes na área de tecnologia (através das fases de nivelamento e imersões iniciais) quanto para profissionais que já possuem uma base sólida em infraestrutura ou desenvolvimento de software e desejam se especializar na criação e orquestração de arquiteturas agênticas complexas.

O que é ensinado na fase Tech AI Builder?

Esta fase avançada do ONE AI For Tech é composta por 5 grandes frentes de aprendizado: nivelamento em Machine Learning e Python; desenvolvimento e orquestração de IA Generativa; engenharia de agentes e automação (usando n8n e APIs); inteligência de dados com RAG avançado; e administração de workloads utilizando a infraestrutura da Oracle Cloud Infrastructure (OCI).

Preciso ter conhecimento prévio de programação?

Para as imersões iniciais (Imersão IA e Imersão ONE), não foi obrigatório ter experiência prévia em código, O foco estava em entender a lógica, o fluxo de dados e ferramentas low-code. No entanto, para tirar o máximo proveito das trilhas avançadas do ONE AI For Tech, ter noções de lógica, bancos de dados e APIs ajuda muito a construir sistemas prontos para produção.

Qual é o papel da Oracle Cloud Infrastructure (OCI) no programa?

A OCI é a infraestrutura de nuvem que viabiliza o deploy e a escala dessas soluções de IA. No ONE AI For Tech, você aprende a gerenciar aplicações na nuvem da Oracle aproveitando diferenciais críticos para projetos de IA, como a performance de instâncias bare metal para processamento pesado e taxas de egress altamente competitivas, que evitam que o consumo de dados inviabilize financeiramente o seu produto.

ABAP não é para qualquer um. E a OCI é para quem quer o melhor do SAP.

César Augusto de Fázio — Fri, 26 Jun 2026 00:56:39 +0000

O mundo SAP é muito reservado. O SAP ABAP é mais difícil de achar em comparação com outras linguagens de programação por algumas razões.

Primeiro, o ambiente SAP é complexo. Usa-se ABAP em contexto empresariais bem específicos e a curva de aprendizado é muito grande para iniciantes (primeiro entender SAP e então SAP ABAP).

Embora haja muito conhecimento disponível (como o Dagaz e os SAPeiros), não é tão fácil de achar como conhecimento sobre Python ou Java.

Além disso, ABAP é voltado para o ecossistema SAP, o que significa que seu uso e relevância são limitados para esse ambiente.

Então porquê aprender SAP ABAP?

Porque não é todo mundo que sabe. Ironicamente, essa escassez de profissionais e de uso é o que torna aprender ABAP uma vantagem para o profissional e para a empresa que busca estabilidade.

Saber ABAP sinaliza um compromisso de longo prazo com a plataforma SAP e um conhecimento de negócio difícil de ser replicado. Estar imerso nas regras de negócio é um ticket só de ida para a senioridade.

De acordo com o especialista em SAP S/4 HANA, Roberto Martinelli, quando você aprende SAP ABAP, quando você se interessa pelo negócio da empresa, você aprende o processo. Mesmo que a empresa customize muitas coisas, ela funciona dentro de um determinado padrão.

Do lado da empresa, aplicar SAP evita a constante reengenharia das aplicações para acompanhar a escalabilidade e leva a empresa a adotar as melhores práticas. A SAP possui soluções prontas e específicas para indústrias (como manufatura, automotivo, farmacêutico) que poucos igualam em profundidade. E há templates SAP para qualquer setor, varejo, extração e refinamento de petróleo...

Perspectiva	Vantagem	Impacto na Carreira
Profissional	Escassez de profissionais qualificados	Menor concorrência e maior valorização no mercado
Profissional	Sinaliza compromisso de longo prazo com a plataforma SAP	Perfil considerado estável e confiável por empregadores
Profissional	Imersão em regras de negócio	Ticket de ida para a senioridade — visão estratégica
Profissional	Aprendizado do processo de negócio (mesmo com customizações)	Capacidade de atuar em diferentes setores e projetos
Profissional	Conhecimento transferível entre indústrias (manufatura, varejo, petróleo, farmacêutico etc.)	Portfólio diversificado e empregabilidade ampliada
Empresa	Estabilidade e continuidade operacional	Redução de riscos com rotatividade de equipe
Empresa	Evita reengenharia constante de aplicações	Menor custo de manutenção e maior previsibilidade
Empresa	Adoção de melhores práticas SAP	Processos alinhados com padrões globais de mercado
Empresa	Templates prontos para setores específicos	Implantação mais rápida e com menos erros

E por quê OCI?

As vantagens centrais de utilizar a Oracle Cloud Infrastructure em sistema SAP são a performance excepcional para bancos de dados SAP, especialmente em ambientes de missão crítica, e um modelo de precificação mais competitivo.

Além disso, a Oracle tem uma parceria com a SAP que remonta a 1988, focada em otimizar aplicações SAP para rodarem no banco de dados Oracle.

A Oracle tem um conhecimento profundo do ecossistema SAP que pode acelerar significativamente o sistema, como compressão de dados, particionamento e a opção in-memory, que permite processamento em memória para aplicações SAP sem necessidade de modificar o código ABAP.

Além do mais, a Oracle possui sistemas projetados como o Oracle Exadata, indispensável para muitos dos maiores sistemas SAP ECC (ERP Central Component), BW (Business Warehouse) e NetWeaver. O Oracle Linux é o único capaz de rodá-los utilizando o banco de dados Oracle dentro de provedores de nuvem. Se você for usar esses sistemas na nuvem, precisará de uma licença Oracle Linux Premier Support.

Mas se você estiver no OCI, a assinatura do Oracle Linux Premier Support já está inclusa. Isso é uma economia muito grande, especialmente para empresas adotando o SAP NetWeaver.

Use OCI com seu sistema SAP se:

Tiver grandes sistemas SAP com cargas de bancos de dados pesadas
Precisa de otimização de performance e gestão de licenças
Busca modelo de assinatura com tudo incluso
Deseja performance superior tanto para bancos de dados Oracle quanto para bancos de dados SAP
Necessita de performance de bancos de dados superior sem mudar código ABAP

Conclusão

Por que estou falando de SAP ABAP e Oracle? Porque eu mesmo resolvi aprender SAP ABAP. E considerando que o SAP NetWeaver AS ABAP Developer Platform vai ficar fora de cenário no final de setembro deste ano, quero aprender o suficiente de SAP pra poder subir uma VM com SAP NetWeaver two-tier, seguindo a documentação da Oracle e registrando minhas experiências e impressões. Vamos ver se vai rolar!

Aprendendo Red Hat OpenShift e OCI pelo preço de um pastel

César Augusto de Fázio — Thu, 18 Jun 2026 17:05:45 +0000

Foi a primeira vez que eu tive que subir tanta infraestrutura de uma vez só. Fiquei receoso.

"Será que essa brincadeira de subir um cluster Red Hat OpenShift vai me custar caro?"

Por mais que a Oracle Cloud Infrastructure tenha uma boa fama devido ao preço, eu sabia do poder computacional que o Red Hat OpenShift ia demandar.

14 reais. É o preço de um pastel de feira aqui perto de casa.

E foi fácil subir? Sendo minha primeira vez subindo algo operacional dessa magnitude pra testes... não. Mas na segunda vai ser infinitamente mais fácil.

Porquê? Porque está tudo abstraído. ISO minimalista, por volta dos 150MB; configuração do cluster e das tags simplificada pelo OCI Resource Manager (o Terraform super dotado com formulário da Oracle) + o Red Hat Assisted Manager.

Confira o passo-a-passo aqui: https://github.com/ShlomoChanoch/openshift-oci. Está tudo documentado, e também possui links para a documentação oficial.

O que também me surpreendeu foi aprender o conceito de oCPUs enquanto eu subia as instâncias.

A Oracle criou algo chamado oCPU (Oracle Compute Unit). que é a unidade de medida de computação da Oracle usada na OCI.

Diferente de outros serviços de nuvem, a Oracle vincula seu poder computacional diretamente ao hardware para garantir desempenho.

Isso significa que:

1 OCPU = 1 núcleo físico de processador (com multithreading ativado).

Em uma arquitetura x86, isso equivale a 2 vCPUs (unidades de CPU virtual) em relação padrão da indústria.

"Tá, mas qual a vantagem de um oCPU? Ela custa o mesmo preço que duas vCPUs?" Não, na verdade é mais poder computacional por um preço mais acessível.

Além disso, o núcleo que você paga é dedicado ao uso da sua instância computacional. Sem disputa de performance entre VMs diferentes.

Isso me lembra o título daquele livro: "Scrum: Como fazer o dobro do trabalho na metade do tempo", do Jeff Sutherland.

É o dobro de CPU pela metade do preço.