DEV Community: Thiago Sagara

Amazon Athena: análises SQL diretas no S3 – quando usar, quanto custa e quais os limites

Thiago Sagara — Fri, 17 Oct 2025 14:59:44 +0000

Quando começei a trabalhar com AWS em 2021, nos meus estudos para a CCP via o S3 **como um Google Drive com **capacidade infinita (obviamente tinha uma visão beemm limitada de um cara que vinha de router bgp em Cisco). Contudo tenho notado que nos últimos anos, o S3 se consolidou como a espinha dorsal dos Data Lakes modernos na AWS, com cada vez mais funções e inovações.

Praticamente todo projeto de dados na AWS começa por lá: armazenando logs, relatórios financeiros, eventos de aplicações ou mesmo datasets públicos. Na prática ele deixou de ser um repositório passivo e virou o ponto de partida da inteligência de dados na nuvem.

O desafio agora não é mais guardar dados, e sim extrair valor deles sem clusters caros ou ETLs pesados.

É aí que entra o Amazon Athena. Lançado em 2016, como um serviço serverless de consultas SQL sobre o S3. Com ele, você não provisiona servidores, não paga por nós ociosos e obviamente não precisa configurar instâncias: apenas descreve o schema (e por traz ele usa o Glue Data Catalog) e consulta via SQL.

Nesse blog post quero mostrar como o Athena faz as queries no S3, como podemos deixar essa queries mais baratas e mais rápidas, e também quando utilizar esse combo é uma vantagem.

Cenário de estudo

Vamos usar um caso prático: temos um arquivo CSV com dados de filmes do IMDb armazenado no S3 com cerca de 10 MB, contendo colunas como título, ano, gênero e avaliação.

A ideia é analisar esses dados diretamente no S3 usando o Athena, sem precisar criar um banco de dados. Queremos responder perguntas como:

“Quais são os filmes mais bem avaliados por gênero?”
“Quantos filmes foram lançados por década?”

No começo, as consultas funcionam, mas são lentas e caras (o Athena precisa ler todo o CSV a cada execução). Então para resolver isso, aplicamos CTAS (Create Table As Select), convertendo o CSV para Parquet e criando partições por ano de lançamento, e assim reduzir tempo e custo.

Nosso objetivo: comparar a diferença entre consultar o CSV bruto e a versão otimizada em Parquet, analisando tempo de execução, volume de dados escaneado e custo em dólar.

Arquitetura por trás do Athena

Ok, o Athena além de ter um nome fanstástico foi algo totalmente revolucionário? A resposta direta: Não. Em resumo, ele funciona como a ponte entre o S3, onde os dados vivem, e as ferramentas que precisam deles.

Junto com ele tem o todo poderoso AWS Glue Data Catalog: que descreve o conteúdo, como se fose um mapa para o dataset (palavra bonita para o .csv), na prática ele é que vai dar significado ao .csv.

Ai temos o Presto (motor interno (Trino)): que é quem realmente executa as consultas em paralelo, lendo os arquivos diretamente do S3.

Visualmente, a arquitetura pode ser imaginada assim: o S3 armazena os dados (CSV, JSON, Parquet), o Glue Catalog descreve como esses dados estão estruturados, o Athena (Presto) executa as queries em workers temporários, e os resultados podem ser enviados para QuickSight, Redshift ou devolvidos ao S3.

Mão na massa: dataset do IMDb

Para entender na prática como o Athena trabalha, vamos usar um dataset real: baixei a base de filmes do IMDb e subi em um bucket no S3, a base possui filmes com informações como título, ano de lançamento, nota e país.

Nosso objetivo será analisar quantos filmes foram lançados por ano nas décadas de 1980 e 1990, comparando a execução entre uma base CSV e uma versão otimizada em Parquet com particionamento por ano.

Criando a tabela no Athena (CSV original no S3)

CREATE EXTERNAL TABLE IF NOT EXISTS imdb_movies (
    id STRING,
    title STRING,
    link STRING,
    year INT,
    duration STRING,
    rating_mpa STRING,
    rating_imdb STRING,
    vote STRING,
    budget STRING,
    gross_world_wide STRING,
    gross_us_canada STRING,
    gross_opening_weekend STRING,
    director STRING,
    writer STRING,
    star STRING,
    genre STRING,
    country_origin STRING,
    filming_location STRING,
    production_company STRING,
    language STRING,
    win STRING,
    nomination STRING,
    oscar STRING
)
ROW FORMAT SERDE 'org.apache.hadoop.hive.serde2.OpenCSVSerde'
WITH SERDEPROPERTIES (
  'separatorChar' = ',',
  'quoteChar' = '"'
)
LOCATION 's3://datanews-user-event/input/' 
TBLPROPERTIES ('skip.header.line.count'='1');

Esse comando informa ao Athena:

Onde estão os dados (LOCATION);
Que o formato é CSV (SERDE);
E quais colunas existem no arquivo.

Consultando quantos filmes foram lançados por ano (anos 80 e 90)

Agora podemos fazer a primeira consulta, (aqui ainda sem sem otimização).
Essa query irá contar quantos filmes existem por ano entre 1980 e 1999.

SELECT year, COUNT(*) AS total_filmes
FROM movies_csv
WHERE year BETWEEN 1980 AND 1999
GROUP BY year
ORDER BY year;

💡 Aqui o Athena vai ler o CSV inteiro, mesmo que a maioria dos registros não esteja dentro do período desejado.
Isso significa mais dados escaneados, mais tempo e mais custo.

Criando a tabela otimizada em Parquet com CTAS (filmes entre 80 e 90) Para melhorar a performance, vamos criar uma nova tabela em formato Parquet e particionada por ano. Usaremos o comando CTAS (Create Table As Select), que lê o dataset original, filtra os dados desejados e grava uma nova versão da tabela já otimizada no S3.

CREATE TABLE imdb_movies_80_90
WITH (
    format = 'PARQUET',
    external_location = 's3://datanews-user-event/ctas/',
    partitioned_by = ARRAY['year'],
    parquet_compression = 'SNAPPY'
) AS
SELECT
    id,
    title,
    director,
    year
FROM
    movies_csv
WHERE year BETWEEN 1980 AND 1999

O Athena criará automaticamente subpastas no S3 como:
s3://datanews-user-event/ctas/year=1980/ s3://datanews-user-event/ctas/year=1981/ ... s3://datanews-user-event/ctas/year=1999/
Cada partição conterá apenas os filmes daquele ano.

Consultando novamente a base otimizada Agora, basta rodar a mesma query de antes, mas sobre a nova tabela particionada:

SELECT year, COUNT(*) AS total_filmes
FROM imdb_movies_80_90
GROUP BY year
ORDER BY year;

O Athena agora só lê as partições necessárias (anos 80 e 90), em formato colunar e comprimido, em vez de varrer o CSV inteiro.
Isso pode reduzir o volume escaneado em até 90% e o tempo de execução em 3 a 5 vezes, dependendo do tamanho do dataset.

Resultado? O mesmo conjunto de dados, mas agora com consultas até 90% mais baratas e 3x mais rápidas.
O que muda não é o dado, é o formato e a forma como o Athena o lê.
Esse é o ponto em que o S3 deixa de ser apenas armazenamento e passa a ser plataforma de análise.

Comparações com outras soluções

Mas apenas o Athena consegue ler dados do S3? Não. Ele é muito bom para consultas ad-hoc (imagine o ad-hoc como um uber, ou seja, você solicita só quando precisa) e analises sob demanda, mas não é a escolha ideal para todos os cenários.

O Redshift Spectrum, por exemplo, também consultas dados no S3, mas depende de um cluster RedShift ativo, e é mais indicado para quem usa um data warehouse e quer estender o alcance das consultas.

O Amazon EMR, com Spark e Hive, é voltado a pipelines complexos e ETL massivos, também vai conseguir ler o S3, é mais fléxivel e muito mais poderoso, contudo exige uma manutenção e configuração mais pesada.

Custos e casos de uso

O Athena te cobra $5 por terrabyte escaneado proporcionalmente, ou seja, uma query que lê 1GB custa aproximadamente $0,005.

Simplicidade sedutora, posso dizer, mas perigosa.
Em números práticos, imagine um CloudTrail com 450GB de logs, que precisam ser analisados uma vez por semana:

CSV: 450 GB lidos × $5/TB = ~$9 por execução
Parquet: 110 GB lidos × $5/TB = ~$2.25

Essa diferença se repete toda semana, em um ano, são mais de $350 de economia só por mudar o formato.

Então utilize o Athena para contextos onde precisa da informação rápida ou quer manter a infra totalmente serveless. Exemplos:

BI e dashboards: junto com o QuickSight, gera relatórios em tempo real sem precisar mover dados.
Logs e auditoria: usado por equipes de segurança/redes para consultar CloudTrail, VPC Flow Logs e ALB Logs.
Data Lakes serverless: combinação de Glue + Athena + S3, criando um ecossistema de análise totalmente sem servidor.

Pontos importantes:

Cada query pode rodar no máximo por 30 minutos;
Os resultados (download) é limitado em 100MB (maiores só mandar para o S3 e fazer o download por lá);
Tem um soft-limit de 20 queries simultâneas por conta/região;

Bonus

quando NÃO utilizar o Athena:
Quando não usar o Athena:
Quando você precisa de queries complexas com muitos joins e aggregations;
Quando os dados precisam de atualizações frequentes (Athena é leitura, não transação);
Ou quando o custo por leitura começa a se igualar ao de um Redshift mantido ativo.

No fim, essa é a mentalidade por trás da nuvem moderna:
trazer a análise para os dados, e não os dados para a análise.
É o que faz o Athena ser tão poderoso — ele não é apenas uma ferramenta de consulta, mas um lembrete de que inteligência começa quando paramos de mover informação e começamos a escutá-la onde ela vive.

revisado por: Elisa Livramento

Blockchain e o Futuro do Sistema Financeiro Brasileiro: entre o Drex, Smart Contracts e a Nuvem da AWS

Thiago Sagara — Mon, 01 Sep 2025 20:07:28 +0000

Já imaginou poder ter a mesma liquidez da poupança em um imóvel, transferindo cotas digitais desse ativo com a mesma facilidade de enviar um pix? Esse é o tipo de transformação que o blockchain promete trazer ao mercado financeiro - e que o Bacen já está pavimentando com iniciativas como o Pix, o Open Finance e o DREX.

Não se trata apenas de inovação tecnológica, mas de uma mudança de paradigma: ativos, transações e contratos deixam de depender de sistemas centralizados para serem garantidos por uma rede distribuída, auditável e resistente a fraudes.

Ai vocês me perguntam: Mas o que é esse tal de BlockChain? O que isso muda na minha vida? E qual o papel ou como a AWS **pode ajudar, seja com o **Amazon Managed Blockchain (AMB) ou via nodes no EC2 ou EKS?

O que é Blockchain? é de comer ou é de beber?

O famoso e invisível Nakamoto descreveu o blockchain como um sistema de registro baseado em consenso distribuído, eliminando a necessidade de uma "entidade de confiança" única [Nakamoto, S. (2008). bitcoin: A peer-to-peer electronic cash system

Na prática, Blockchain é um nome bem bonitinho para um livro-caixa público e distribuído, em que cada página representa um bloco de transações (Block), e cada nova página só pode ser escrita se estiver matematicamente ligada à anterior (chain) e for aprovada por um consenso. Essa estrutura torna as informações imutáveis **e **transparentes, ou seja, uma vez registrada, a transação não pode ser alterada sem invalidar toda a sequência.

Beleza, falei um monte de coisas 'técnicas', e talvez vocês não tenham entendido absolutamente nada. Então imagine o blockchain como um livro de atas de uma assembléia de condomínio.

Cada reunião é registrada na ordem em que aconteceu (bloco).
Todos os condôminos recebem uma cópia idêntica da ata (nós da rede).
Para aprovar uma nova página, todos precisam concordar com o que está escrito (consenso).
Se alguém tentar alterar uma página antiga, todos os outros percebem imediatamente, pois suas cópias não batem.

A diferença é que, no Blockchain, esse livro de atas não é guardado em um arquivo ou gaveta, ele é** distribuído digitalmente, protegido por criptografia** e com assinaturas que garantem a autenticidade de cada decisão.

O detalhe técnico por trás da analogia é:

A 'página' é o bloco;
O 'encadeamento' entre as páginas é feito por funções hash criptográficas.
A 'assinatura de todos os condôminos' é o processo de consenso (Proof of Work, Proof of Stake, Proof of Authority e etc);
O 'livro inquebrável' é a garantia de imutabilidade do Ledger.

Perceba que na prática o processo de consenso é a alma do blockchain.

E o que eu tenho a ver com isso?

Despejei uma série de informações aqui, e talvez nesse momento você deve estar se perguntando: e o quiko?

Se pararem pra notar, as possibilidades de resoluções da tecnologia blockchain são bem interessantes, pois ela pode remodelar a forma como você interage com dinheiro, dados e até com o próprio Estado. Seus efeitos podem ser vistos tanto em facilidades quanto em novos desafios. Por exemplo:

Inclusão financeira: Em países em desenvolvimento, ou em guerra, onde milhões de pessoas não possuem conta bancária. O Blockchain permitiria criar carteiras digitais acessíveis apenas com um celular, ou mesmo 'decorando' uma sequência de 24 palavras. Reduzindo barreiras e entradas no sistema financeiro.
Rastreamento em cadeias de suplementos: Uma empresa conseguiria ter dados de uma matéria-prima desde os pequenos produtores até a chegada em sua fabrica. De fato a Nestle fez isso em 2020: Case Nestle BlockChain

Tokenização de bens: Imóveis, veículos e até obras de arte podem ser fracionadas digitalmente, permitindo que pessoas invistam em ativos a nivel de frações, permitindo que qualquer pessoa invista em ativos antes restritos a grandes investidores.
Maior confiança em serviços públicos: Subsídios como auxílio gás ou o bolsa família poderiam ser vinculados a smart contracts, e pagos em redes blockchain, onde todos sabem exatamente para onde o dinheiro foi - e sem espaço para desvios no meio do caminho.

Isso tudo ainda gera economia para o Mercado Financeiro. De acordo com Dan Tapscott, aproximadamente 30% o custo de back-office bancário é gasto apenas conciliando informações entre instituições. [Tapscott, D., & Tapscott, A. (2016). Blockchain Revolution]

Mas e o BACEN, onde entra nisso?

O Bacen não enxerga blockchain apenas como inovação experimental, mas como infraestrutura nacional estratégica e isso pode ser visto em dois produtos:

Pix (2020): Que apesar de não utilizar blockchain, prova a capacidade de criar sistemas em escala nacional com liquidação instantânea.
Drex: Que mesmo não sendo a nossa CBDC, ou seja, é o projeto para criação da moeda digital endógena brasileira, que servirá para:
- Controle mais eficiente das reservas bancárias;
- Compra/venda de frações de títulos públicos de forma atômica;

Em agosto de 2025 no evento Blockchain.Rio, o atual presidente do Bacen (Galipolo) confirmou que o DREX não é uma CDBC ("como a literatura clássica define") nem uma stablecoin, e sim uma ferramenta para tokenização de ativos (confirmando também que atualmente o Bacen não vai utilizar blockchain nessa fase).

Beleza. Mas o que a AWS tem a ver com isso?

Quando pensamos em como o Bacen ou mesmo um banco regional poderia operar o DREX para tokenizar ativos em escala nacional, a pergunta não é apenas qual blockchain usar, mas como sustentar essa infraestrutura sem se perder em custo e complexidade?

É aqui que entra o Amazon Managed Blockchain (AMB), um serviço da AWS que reduz o custo operacional de colocar blockchains em produção, utilizando o poder do EKS com KMS para servir como nós de rede em outras blockchains, uma vez que o AMB suporta Hyperledger Fabric, e o Bacen estuda implementar a Hyperledger Besu.

Até aqui tentei ser menos técnico, contudo agora vou ligar o modo 'escovador de bit'.

Solução para o Bacen

Falando primeiro sobre o AMB, ele não é simplesmente o blockchain da AWS, e sim um conjunto de serviços que permitem consumir ou criar redes permissionadas (hyperledger fabric), redes públicas (ethereum/polygon) e utilizar o AMB Query como a camada de analytics pronta para consultar de transações, saldos e históricos.

A vantagem em utilizar o AMB para o DREX, seria a governança distribuída, canais privados e uma ótima integração corporativa (dica para o Bacen). De fato a Hyperledger Fabric é a blockchain utilizada por alguns projetos de CBDCs como o DCash no Caribe, o Aber na Arábia Saudita, o Agila nas Filipinas e até o Venus (projeto de títulos) na França.

Amazon Managed Blockchain

No AMB além de criar as redes permissionadas, cada participante (membro) dela tem seu papel definido e controlado.

Elementos principais:

Network: é a rede Fabric, criada no AMB, onde ficam os membros;
Members: é a representação de uma organização participante (por exemplo Banco A, Banco B, Bacen). É nele que rodam os Peers e a CA, além da governança ser baseada nele.
Peer Nodes: Executam smart contracts (chaincode), validam transações e mantêm o ledger.
Certificate Authority(CA): emite credenciais digitais que identificam cada participante/nó.
Channels: Subredes privadas onde apenas membros autorizados trocam transações.

Além disso a integração com serviços como IAM (para definir quem pode fazer o que), KMS (que armazena as chaves criptográficas) e Cloudtrail (logs de auditoria) são simples de serem integradas.

Um possivel fluxo seria:

O Bacen criaria a Network Fabric no AMB e define o primeiro Member;
- Esse membro é o responsável por definir políticas de governança (quem pode ser convidado, como aprovar chaincodes, etc).
Bancos e fintechs entrariam como convidadas para ingressar na rede como novos membros (isso via AMB);
- Cada instituição ingressa como um Membro, com autonomia sobre seus nós e identidades.
Cada membro cria **Peers **para validar transações e hospedar chaincodes;
Um **CA **do AMB gera certificados para admins, peers e clientes;
Cada membro tem seu próprio CA, emitindo certificados para:
- Admins: que vão gerir a rede;
- Peer: que são os nós validadores;
- Clientes/aplicações: App que compra titulos do Tesouro, ou que consulta o saldo da reserva bancária;
São criados Channels, onde subsetores podem trocar informações privadas (ex.: liquidação de ativos tokenizados).
- Aqui o Bacen poderia criar channels privados para liquidação interbancária;
- Outra possibilidade, seria a criação de tokenização de ativos em um canal apenas com fintechs;
O _chaincode _(smart contract) é implantado nos peers e passa a reger a lógica de negócios;
- A cereja no bolo, onde seria feita a criação (mint) e a destruição/liquidação (burn) de tokens;
- Aqui o céu é o limite, podendo programar liquidações, transferências interbancárias e etc.;
Toda transação é assinada, validada pelos peers do canal e registrada no ledger imutável;

Resumindo, se o Bacen quisesse rodar um piloto de Drex com governança distribuída entre bancos, poderia montar a rede no Hyperleger Fabric via AMB, enquanto um banco privado poderia, ao mesmo tempo, usar o AMB Query para auditar movimentações tokenizadas sem manter servidores extras.

Mas porque fazer com AMB

A grande vantagem do AMB é ser um serviço gerenciado, e para a Bacen e grandes bancos e consórcios, o AMB tende a equilibrar governança + segurança + operação. Para fintechs e PoC, rodar em EKS/EC2 (ou usar provedores publicos) gera agilidade e controle, mas com um custo operacional, é claro. Abaixo comparo de uma forma melhor:

Critério	AMB	Nó próprio	Rede pública (Gnosis)
Operação	Totalmente gerenciado (patching, HA)	Você opera tudo (alto controle)	100% terceirizado
Segurança	IAM/KMS/VPC integrados	Você define hardening/chaves	Depende do provedor
Governança	Forte (ideal p/ consórcios/BCB)	Forte (se bem implementado)	Variável
Desempenho/Latência	Boa, mas dentro do modelo do serviço	Máximo controle (afinamento p2p, disco, rede)	Boa, mas sem garantias finas
Custo	Por nó/armazenamento/requests	EC2/EBS/EKS/operacional	Assinatura/uso (egress/limites)
Interoperabilidade	Fabric + públicos suportados (Eth/Polygon)	Total (você escolhe stack)	Boa em públicos; lock-in do provedor
Dados on-chain (analytics)	AMB Query (serverless multi-cadeia)	Você indexa (TheGraph/ETL)	Alguns provedores oferecem APIs

Conclusão

No contexto atual, o Amazon Managed Blockchain (AMB) aparece como uma opção estratégica para bancos e fintechs que precisam integrar-se rapidamente ao ecossistema, sem carregar o peso e manter toda a pilha de infra (considerando, é claro, o exemplo hipotético utilizado).
O AMB entrega:

Governança e compliance prontos para uso;
Escalabilidae sob demanda, sem a complexidade de clusters Kubernetes;
Integração direta com serviços AWS;

Contudo há limitações: adotar o AMB significa abrir mão de parte da flexibilidade e da independência que redes públicas ou nós próprios em EKS permitem. É um trade-off inevitável entre o controle total ou velocidade com governança pronta.

Por fim, a crítica é clara: o futuro do Drex, do mercado financeiro e da tokenização não será definido pela tecnologia, mas pela forma com que o Bacen, bancos e fintechs vão equilibrar centralização e abertura. Talvez o verdadeiro desafio não seja escolher entre Fabric, Besu, AMB ou EKS, mas sim entender quando usar cada abordagem.

Bitnami e o fim do repositório gratuito de imagens: o que muda para DevOps e Cloud Engineers?

Thiago Sagara — Wed, 27 Aug 2025 15:57:26 +0000

Em meados de julho/25 a comunidade de cloud e DevOps recebeu uma noticia um tanto quanto peculiar: a Bitnami anunciou alterações do seu repositório publico e gratuito de imagens ded containers e charts, o que na prática é um jeito 'maqueado' de descontinar o projeto open.

Para contextualizar, a Bitnami nasceu como uma empresa focada em simplificar a distribuição de aplicações open source, empacotando softwares em instalações fáceis, VMs, charts Helm e imagens Docker. Em 2019, foi adquirida pela VMware (hoje Broadcom), e desde então expandiu o catálogo de soluções.

Algumas das imagens mais conhecidas e amplamente usadas incluem:

PostgreSQL, MySQL e MariaDB: banco de dados para produção;
NGINX, Apache, Tomcat: Servidores web e de aplicação;
Redis, RabbitMQ e Kafka: Soluções de mensageria e cache;
Wordpress, Drupal, Magento: Aplicações open source populares;

A vantagem de pegar imagens open e empacota-las? Incorporação de boas práticas como segurança reforçada, facilidade na configuração para k8s e helm, imagens 'prontas' para produção bom tuning básico de performance, as imagens vinham acompanhadas de charts Helm ociciais da própria Bitnami, ou seja em resumo ela transformava software cru em software 'pronto para rodar em nuvem'.

Mas essa fase esta chegando ao fim.

Principais mudanças

Vejam que o repositório gratuito permanecerá existindo com o nome Bitnami Legacy Registry, contudo com algumas limitações, cito-as:

Não terá containers versionados;
Redução significativa no catalogo;
Não haverá updates de segurança;
Remoção das imagens de comunidade Debian-based;

Assim permanece gratuito imagens que eles chamaram de 'somente para desenvolvimento', com um catálogo limitado de aplicações, e todas apenas com a tag 'lastet' (o que nunca é uma boa opção para se ter em produção).

Com a versão paga, chamada de Bitnami Secure Images (BSI), ficou too o histórico da imagem (versões), bases com hardened, SBOMs e é claro updates de segurança e suporte. Tudo isso por um preço de $6.000/mês.

Impactos nos pipelines, charts e Helm

A mudança impacta diretamente pipelines de CI/CD, charts do Helm e manifestos Kubernetes que referenciam imagens da Bitnami. Projetos que até ontem "simplesmente funcionavam" podem começar a quebrar com erros de Image not found, ImagePullBackOff ou ErrImagePull.

Mas onde o impacto vai ser mais potente:

Pipelines de build/deploy: falhas ao puxar imagens já existentes, pois o código não terá a referencia correta;
Charts Helm: centenas de charts oficiais e derivados utilizam imagens da Bitnami como dependencia;
Ambientes Kubernetes: clusters rodando workloads baseados nessas imagens correm risco ded indisponibilidade em novos deploys;

Na prática essa alteração em um repositório tão importante para CI/Cs, charts e clustes em geral escala o evento para problema na cadeia de suprimentos.

Além do impacto técnico, a sensação de 'soco no estomago' na comunidade foi grande, e até injusto de certa forma. Usar a Bitnami ao invés de imagens oficiais tirava certo peso dos desenvolvedores e devOps, pois a imagem vinha com boas práticas adicionais, contudo também contava com bastante apoio da comunidaded na resolução de issues e documentação.

Receber o anuncio com a opção de 'migrar' em 45 dias é de uma falta de empatia gigante, e aqui nem acredito que capitalizar o trabalho é errado, mas sim a forma que isso foi feito. Para efeito e comparação em 2020 a RedHat anunciou mudança de foco para o CentOS, mas apenas em julho de 2024 ele entrou em EOL, na prática a RedHat ainda 'suportou' o projeto com atualizações de segurança e manutenção por 4 anos, o que deu a comunidade tempo para fazer forks e até iniciar outros projetos.

Opções urgentes

As opções para (pelo menos) ganhar tempo de uma solução mais robusta podem incluir fazer o cache local das imagens utilizadas atualmente com um docker save, ou utilizar repositórios privados como o AWS ECR ou o Harbor. Dessa forma é possivel congelar as versões críticas até que um plano de migração esteja definido.

Outra opção (um pouco mais kamikaze) é utilizar o repositório legado, e simplesmente substituir o código para bitnamilegacy/<image>. O problema disso: não tem updates, suporte e manutenção, além de existir a possibilidade de uma atualização da imagem, e por conta do latest você ter surpresas na aplicação.

Existe também a opção de fazer o subscribe do Bitnami Secure Image, contudo pagar por algo que antes era gratuito, pode exigir um estudo mais aprofundado das empresas para calcular o retorno de investimento e até a nova margem (a depender do tamanho da empresa). Note que $6.000/mês no Brasil pode significar o custo de TODA conta da AWS, o que na prática deixa inviável a escolha.

Opções definitivas

Pra resolver de forma definitiva é necessário identificar os workloads críticos que utilizam imagens bitnami, e classifica-los por impacto comercial. Dessa forma (com o impacto financeiro calculado) será possivel analisar o risco/retorno do custo da licença.

Se obter a licença não for uma opção, as alternativas são:

Imagens oficiais: Ou seja, utilizar o repositório oficial da imagem, como postgres, redis e etc;
Imagens da AWS: Usar RDS ou mesmo o ElastiCache é uma ótima opção para não ter esse tipo de problema;
Serviços Gerenciados: Para aplicações mais complexas como elasticsearch e kafka ou rabbitMQ, serviços como o OpenSearch e o Amazon MSK são opções ótimas;

Conclusão

Não que a comunidade precisasse de justificativa, uma vez que o produto precisa ser capitalizado, mas a explicação da Broadcom é que a mudança visa um repositório mais seguro e com suporte. Contudo a segurança não depende necessariamente de paywall.
Ferramentas como Trivy, Grype ou Clair já fazem analise de vulnerabilidade, assim bastaria incorpora-las na pipeline de CI/CD e até integrar com SCA para aumentar a analise.

Na prática, o movimento reflete mais uma estratégia a Broadcom pós-aquisição da VMware: monetizar ativos consolidados. O que, novamente, não acho errado, contudo o jeito com que foi feito (abrupto, sem períoo de transição claro e justo) deixará muitas empresas a merce de renovar por uma taxa grande, apenas para conseguir mais tempo para planejar a migração.

No fim, quem perde não são apenas os entusiastas de open source, mas também too o ecossistema que dependia da Bitnami, e assim aprendemos que ser cloud-native é também pensar em cenários onde até a Docker pode começar a cobrar pela disponibilidade.

Como verificar se possuo imagens bitnami

Cluster Kubernetes (tudo que ja virou pod):

kubectl get pods -A -o json \
| jq -r '.items[]
  | .metadata.namespace as $ns
  | .metadata.name as $name
  | (.spec.initContainers // []) + (.spec.containers // [])
  | .[].image
' | sort -u | grep -E '(^|/)bitnami/'

Cluster Kubernetes (tudo que ainda não virou pod):

kubectl get deploy,sts,ds,job,cronjob -A -o json \
| jq -r '.items[]
  | .metadata.namespace as $ns
  | .metadata.name as $name
  | (.spec.template.spec.initContainers // []) + (.spec.template.spec.containers // [])
  | .[].image
' | sort -u | grep -E '(^|/)bitnami/'

Helm:

helm ls -A -o json \
| jq -r '.[] | [.name,.namespace] | @tsv' \
| while IFS=$'\t' read -r rel ns; do
    echo "=== $ns/$rel ==="
    helm get values "$rel" -n "$ns" | grep -nE '(^\s*image:|repository:).*bitnami' || true
  done

Pipeline no Jenkins para procurar dependencias:

pipeline {
  agent any
  options { ansiColor('xterm') }
  environment {
    BITNAMI_REGEX = '(?i)(^|\\s|/)(bitnami)(/|:)'
  }
  stages {
    stage('Audit - Git Manifests') {
      steps {
        sh '''
          echo "[GIT] Procurando imagens/repo Bitnami..."
          set +e
          MATCHES=0

          # 1) Imagens em manifests YAML
          FOUND1=$(find . -type f -name "*.y*ml" -print0 \
            | xargs -0 -I{} yq -r '.. | select(has("image")) | .image' '{}' 2>/dev/null \
            | grep -E "$BITNAMI_REGEX" || true)
          if [ -n "$FOUND1" ]; then echo "$FOUND1" | sort -u | sed "s/^/[YAML IMG] /"; MATCHES=1; fi

          # 2) Helm/Chart deps
          FOUND2=$(git grep -nEi "(repository|repoURL):\\s*(oci://registry-1\\.docker\\.io/bitnamicharts|https?://charts\\.bitnami\\.com/bitnami)" || true)
          if [ -n "$FOUND2" ]; then echo "$FOUND2" | sed "s/^/[HELM REPO] /"; MATCHES=1; fi

          # 3) Dockerfiles
          FOUND3=$(git grep -nEi "FROM\\s+bitnami/" || true)
          if [ -n "$FOUND3" ]; then echo "$FOUND3" | sed "s/^/[DOCKERFILE] /"; MATCHES=1; fi

          if [ $MATCHES -ne 0 ]; then
            echo "✖ Encontrado Bitnami. Interrompendo pipeline."
            exit 2
          fi
          echo "✔ Nenhuma referência Bitnami encontrada no Git."
        '''
      }
    }

    stage('Audit - Cluster (opcional)') {
      when { expression { return env.KUBECONFIG?.trim() } }
      steps {
        sh '''
          echo "[CLUSTER] Vasculhando imagens em workloads..."
          set +e
          OUT=$(kubectl get deploy,sts,ds,job,cronjob -A -o json \
            | jq -r '.items[] | (.spec.template.spec.initContainers // []) + (.spec.template.spec.containers // []) | .[].image' \
            | sort -u | grep -E "$BITNAMI_REGEX" || true)
          if [ -n "$OUT" ]; then
            echo "$OUT" | sed "s/^/[K8S IMG] /"
            echo "✖ Cluster contém imagens Bitnami em workloads desejados."
            exit 3
          fi
          echo "✔ Nenhuma imagem Bitnami detectada em workloads."
        '''
      }
    }
  }
  post {
    always {
      archiveArtifacts artifacts: '**/audit*.log', allowEmptyArchive: true
    }
    failure {
      echo 'Falhou por referências Bitnami. Verifique os logs acima.'
    }
  }
}

Referências:

Entendendo Docker: o que é, como funciona e por que usar

Thiago Sagara — Wed, 30 Jul 2025 21:05:57 +0000

Repost do original: https://www.darede.com.br/entendendo-docker/ da Darede

O Docker é uma das melhores plataformas para o deploy de uma aplicação. Para entender sua funcionalidade, confira esse artigo em nosso blog!

A evolução do deploy de uma aplicação passou por vários processos. Inicialmente tínhamos um servidor físico para cada serviço, ou seja, havia um servidor, um sistema operacional e uma aplicação. Isso gera um aumento em manutenção de hardware, de atualização de patches de segurança ou upgrade da aplicação. Com a virtualização criamos uma camada de abstração do hardware, ou seja, podemos em UM hardware ter vários SOs, e consequentemente várias aplicações. Contudo a necessidade de gerenciamento do SO ainda existe (e ainda existe o SO do próprio hypervisor). Por fim chegamos ao container, ele eleva a abstração para o SO. Isto é, conseguimos abstrair o hardware e o sistema operacional, e deixar o container apenas para cuidar da aplicação. Nesse artigo vamos entender sobre o Docker.

Instalação (centos8)

Instalaremos o docker, e depois realizaremos o pull de uma imagem do tac_plus para servir como servidor de autenticação para nossos equipamentos.

Remova todas as versões de docker que possam estar habilitadas:

dnf remove docker \
docker-client \
docker-client-latest \
docker-common \
docker-latest \
docker-latest-logrotate \
docker-logrotate \
docker-engine

Desabilite o firewalld (por algum motivo ele impossibilita a resolução de DNS dentro dos containers)

systemctl disable firewalld

Adicione o repositório do docker

dnf config-manager --add-repo=https://download.docker.com/linux/centos/docker-ce.repo

Instale o docker com --nobest para compatibilidade com CentOS 8

dnf install --nobest docker-ce

Habilite o docker no sistema


systemctl start docker
systemctl enable docker

Teste o docker validando a versão

[root@devops ~]# docker version
Client: Docker Engine - Community
 Version:           19.03.11
 API version:       1.39
 Go version:        go1.13.10
 Git commit:        42e35e61f3
 Built:             Mon Jun  1 09:13:48 2020
 OS/Arch:           linux/amd64
 Experimental:      false


Server: Docker Engine - Community
 Engine:
  Version:          18.09.1
  API version:      1.39 (minimum version 1.12)
  Go version:       go1.10.6
  Git commit:       4c52b90
  Built:            Wed Jan  9 19:06:30 2019
  OS/Arch:          linux/amd64
  Experimental:     false
[root@devops ~]#

Comandos básicos

Com o Docker instalado vamos agora falar de alguns comandos básicos:

docker ps -a: Mostra todos os containers, tanto os em execução quanto os parados.
docker run: Executa um container com uma imagem especifica (no nosso caso o Hello-Worl
docker start|stop: Inicia um (ou mais) containeres parados, ou para um (ou mais) containers ativos.
docker rm: Remove um (ou mais) container. (voce pega a lista com o docker ps -a)
docker rmi: Remove um (ou mais) imagens. (voce pega a lista com o docker images)
docker container prune: Remove todos os containers que estão parados.
docker images: Mostra todas as images que voce ja fez o pull
docker exec -it: Roda um comando dentro do container (só o exec), e com a opção "-it" voce aloca um tty dentro do container, ou seja, é a opção para ter acesso a console do container. exemplo: docker exec -it hello-wold bash
docker network ls: Lista todas as redes criadas no Docker
docker run: Executa de fato (ou roda) o docker.

Por fim para testar, vamos subir um docker com o famoso hello-word:

[root@devops ~]# docker run hello-world
Unable to find image 'hello-world:latest' locally
latest: Pulling from library/hello-world
0e03bdcc26d7: Pull complete
Digest: sha256:d58e752213a51785838f9eed2b7a498ffa1cb3aa7f946dda11af39286c3db9a9
Status: Downloaded newer image for hello-world:latest


Hello from Docker!
This message shows that your installation appears to be working correctly.


To generate this message, Docker took the following steps:
 1. The Docker client contacted the Docker daemon.
 2. The Docker daemon pulled the "hello-world" image from the Docker Hub.
    (amd64)
 3. The Docker daemon created a new container from that image which runs the
    executable that produces the output you are currently reading.
 4. The Docker daemon streamed that output to the Docker client, which sent it
    to your terminal.


To try something more ambitious, you can run an Ubuntu container with:
 $ docker run -it ubuntu bash


Share images, automate workflows, and more with a free Docker ID:
 https://hub.docker.com/


For more examples and ideas, visit:
 https://docs.docker.com/get-started/


[root@devops ~]#

Xero no suvaco!!!