No cenário atual de desenvolvimento e infraestrutura, onde containers se tornaram padrão, o tamanho das imagens Docker é um fator crítico para eficiência. Um desenvolvedor enfrentou exatamente esse problema ao buscar uma ferramenta simples: uma imagem Docker do cURL com suporte nativo ao protocolo HTTP/3 para testes. A solução encontrada inicialmente, apesar de funcional, apresentava um peso considerável de mais de 600 megabytes, algo desproporcional para uma ferramenta de linha de comando. Essa constatação foi o ponto de partida para um projeto de otimização radical.
O desafio de testar HTTP/3 em ambientes padrão
A adoção do HTTP/3, o protocolo de internet mais recente baseado no QUIC, promete melhorias significativas em velocidade e segurança, especialmente em conexões instáveis. No entanto, sua implementação e teste ainda encontram barreiras práticas. Muitas distribuições Linux, como o Ubuntu em suas versões estáveis, não oferecem pacotes nativos do cURL compilados com suporte ao HTTP/3. Para desenvolvedores e administradores de sistemas que precisam validar configurações de servidor ou simplesmente experimentar o novo protocolo, essa falta de suporte direto cria um obstáculo imediato.
A solução inicial e seu custo em espaço
A alternativa mais rápida para contornar a limitação do sistema operacional hospedeiro é recorrer a containers. A comunidade Docker Hub oferece uma vasta gama de imagens pré-construídas. Foi assim que o desenvolvedor encontrou uma imagem funcional de cURL com HTTP/3. Com um simples comando docker run, era possível executar requisições puras HTTP/3 ou com fallback automático, solucionando o problema técnico. Contudo, o preço dessa conveniência era um arquivo de imagem superior a 600MB. Em um contexto de CI/CD (Integração Contínua e Entrega Contínua), pipelines de deploy ou mesmo para desenvolvedores com espaço limitado em máquinas locais, puxar e armazenar uma imagem de tamanho tão grande para uma tarefa pontual se torna um overhead inaceitável.
Por que imagens grandes são um problema para ferramentas CLI
Ferramentas de linha de comando (CLI), por natureza, devem ser leves e portáteis. Elas são frequentemente usadas em scripts automatizados, dentro de estágios efêmeros de pipelines ou em microservices que executam uma única tarefa específica. Uma imagem de 600MB para o cURL, mesmo com suporte adicional, contradiz esses princípios. O grande volume aumenta o tempo de pull dos registries, consome mais espaço em cache nos nodes de orquestradores como Kubernetes e eleva os custos de transferência de rede em ambientes de nuvem. A otimização não é apenas uma questão de elegância de código, mas de eficiência operacional e economia de recursos.
A estratégia de otimização com multi-stage builds
Diante do problema, a decisão foi criar uma nova imagem do zero, com o foco absoluto na minimização do tamanho final. A técnica escolhida foi o uso de multi-stage builds, um recurso poderoso do Docker. Esse método permite usar uma imagem temporária, maior e completa, para compilar o software e suas dependências. Em um estágio posterior, apenas os binários e bibliotecas essenciais são copiados para uma imagem final mínima, descartando todos os pacotes de desenvolvimento, compiladores e arquivos intermediários desnecessários para a execução.
Selecionando a base mínima para a imagem final
A escolha da imagem base é crucial. Em vez de usar uma distribuição completa como Ubuntu ou Alpine (que, apesar de pequena, ainda carrega um gerenciador de pacotes), a opção foi por uma imagem “distroless” ou extremamente minimalista. Essas imagens contêm apenas o estritamente necessário para executar o aplicativo, frequentemente apenas o binário em um ambiente de tempo de execução (runtime) como o glibc. Essa abordagem elimina shells, ferramentas de sistema e outros componentes que, embora úteis para debugging, incham a imagem para uma ferramenta que deve apenas executar e terminar.
Resultado: cURL com HTTP/3 em apenas 20MB
O esforço de otimização rendeu um resultado dramático. A nova imagem, batizada de tiny-curl-http3, foi reduzida para aproximadamente 20MB, uma economia de mais de 96% em relação à solução original de 600MB. Além da drástica redução de tamanho, o projeto garante funcionalidade completa: suporte nativo ao HTTP/3 via QUIC, capacidade de fazer requisições puras com a flag --http3-only e também requisições com fallback automático usando --http3. A imagem é publicada no Docker Hub sob o repositório overdigo/tiny-curl-http3 e seu código-fonte está disponível como open-source no GitHub.
Compatibilidade com arquiteturas AMD64 e ARM64
Um diferencial importante da imagem otimizada é sua compatibilidade multi-arquitetura. Ela suporta tanto a tradicional AMD64 (x86_64) quanto a ARM64, que é a arquitetura dominante em Macs com Silicon da Apple, servidores AWS Graviton e muitos dispositivos IoT. Essa dualidade garante que desenvolvedores em diferentes ecossistemas possam usar a mesma ferramenta sem preocupação, tornando-a verdadeiramente portátil. O build multi-arch é gerenciado através de manifestos do Docker, que direcionam o pull correto de acordo com a plataforma do host.
Como utilizar a imagem otimizada em testes
A utilização da imagem é direta e segue a filosofia Unix de fazer uma coisa e fazer bem. Para um teste rápido da versão e dos recursos compilados do cURL, o comando é: docker run -it --rm overdigo/tiny-curl-http3 curl -V. Para executar uma requisição HTTP/3 pura, testando a conectividade com um servidor que suporte o protocolo (como o blog da Cloudflare usado no exemplo), o comando é: docker run -it --rm overdigo/tiny-curl-http3 curl -IL --http3-only https://blog.cloudflare.com. Já para um teste do mundo real, onde o cliente tenta HTTP/3 e faz fallback para versões anteriores se necessário, o comando apropriado é: docker run -it --rm overdigo/tiny-curl-http3 curl -IL --http3 https://exemplo.com.
O impacto na eficiência de pipelines de CI/CD
A adoção de uma imagem tão reduzida tem efeitos tangíveis em ambientes de desenvolvimento modernos. Em um pipeline de CI/CD que precise validar a configuração de um load balancer ou a resposta de um serviço via HTTP/3, o estágio que utiliza essa imagem será executado significativamente mais rápido. O tempo para puxar a imagem do registry cai de minutos para segundos. O consumo de espaço em cache nos runners é minimizado, permitindo que mais jobs coexistam. Para empresas com milhares de execuções diárias, essa otimização se traduz em redução de custos computacionais e de armazenamento.
O código aberto como vetor de melhoria contínua
O projeto está disponível publicamente no GitHub, seguindo a filosofia open-source. Isso não apenas permite verificação e auditoria do código, mas também incentiva a colaboração da comunidade. Outros desenvolvedores podem sugerir melhorias, reportar issues ou mesmo fazer fork do projeto para criar variantes ainda mais especializadas. A transparência do build, mostrando exatamente como as dependências são obtidas e compiladas, é uma boa prática de segurança, permitindo que usuários entendam o que estão executando em seus ambientes.
A criação da imagem tiny-curl-http3 vai além de um simples exercício técnico. Ela representa uma resposta prática a um problema comum na era dos containers: o bloat, ou inchaço desnecessário de imagens. Demonstra que, com as técnicas corretas—multi-stage builds, escolha criteriosa de imagens base e foco no binário final—é possível entregar funcionalidade completa com uma fração mínima do tamanho original. Para profissionais de DevOps, SREs e desenvolvedores, essa otimização é um lembrete de que a eficiência na camada de infraestrutura é um componente fundamental para sistemas ágeis, sustentáveis e econômicos, onde cada megabyte salvo se multiplica em escala.
