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

#aws #cloud #docker #programming

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: