Entrega de Containers Ubuntu: Redução de Bloat com Imagens OCI Minimalistas para ISVs

Introdução
A necessidade de entregar aplicações containerizadas de forma rápida e segura tem colocado pressão sobre os ISVs (Independent Software Vendors) que utilizam Ubuntu como base. A nova iniciativa "Cut bloat, not features" traz ao ecossistema Ubuntu ferramentas e práticas para gerar imagens OCI (Open Container Initiative) mínimas, reduzindo o ruído de CVEs e eliminando pontos cegos dos scanners. Este artigo aprofunda o que mudou, como isso impacta servidores de produção – VPS, nuvem pública ou privada – e fornece um roteiro prático para administradores de sistemas que desejam adotar essas imagens sem sacrificar a estabilidade ou a segurança do kernel.

O que há de novo no Ubuntu?
A Canonical lançou um conjunto de metapacotes e scripts de build que permitem criar imagens base ultra‑esbeltas a partir do Ubuntu 24.04 LTS. Entre as novidades estão:
- O pacote **ubuntu-base-minimal** que inclui apenas o conjunto essencial de bibliotecas do glibc, busybox e util‑linux.
- Ferramentas de **debootstrap** aprimoradas para gerar rootfs com tamanho inferior a 30 MB.
- Integração nativa com o **Docker BuildKit** e o **LXD image server**, possibilitando a publicação automática de imagens OCI certificadas.
- Suporte a assinaturas de imagem via **cosign** e verificação de vulnerabilidades com o scanner **Trivy** embutido no pipeline CI/CD.
Essas mudanças visam eliminar o "bloat" tradicional das imagens Ubuntu, que frequentemente carregam pacotes de desenvolvimento, documentação e dependências não utilizadas.

Impacto prático para Sysadmins
Para quem gerencia VPS ou clusters Kubernetes, a redução de tamanho das imagens tem efeitos imediatos:
- **Menor tempo de pull**: imagens de 30 MB são baixadas em segundos mesmo em links de rede limitados, acelerando rollouts e escalonamento automático.
- **Redução de superfície de ataque**: menos pacotes significa menos vetores de exploração e menos falsos positivos em relatórios de CVE.
- **Economia de armazenamento**: em ambientes onde centenas de pods são criados diariamente, a diferença pode chegar a dezenas de gigabytes por semana.
- **Melhor previsibilidade de custos**: provedores de nuvem cobram por transferência de dados e armazenamento; imagens menores reduzem a fatura.
Além disso, a nova política de assinatura de imagens garante que apenas artefatos verificados sejam implantados, simplificando a conformidade com normas como ISO 27001 ou PCI‑DSS.

Como construir imagens OCI minimalistas
A seguir, um exemplo de pipeline CI que gera uma imagem mínima baseada em Ubuntu 24.04:
```bash
# 1. Preparar o diretório de build
mkdir -p build/rootfs && cd build

# 2. Utilizar debootstrap com o metapacote minimal
sudo debootstrap --variant=minbase --include=ubuntu-base-minimal focal rootfs http://archive.ubuntu.com/ubuntu/

# 3. Remover caches e arquivos desnecessários
sudo chroot rootfs apt-get clean && rm -rf /var/lib/apt/lists/*

# 4. Criar Dockerfile enxuto
cat > Dockerfile <<'EOF'
FROM scratch
COPY rootfs/ /
CMD ["/bin/bash"]
EOF

# 5. Build com BuildKit e squash para reduzir camadas
DOCKER_BUILDKIT=1 docker build --squash -t myorg/app:minimal .

# 6. Assinar a imagem
cosign sign --key cosign.key myorg/app:minimal

# 7. Verificar vulnerabilidades
trivy image myorg/app:minimal
```
O uso do flag `--squash` consolida todas as camadas em uma única, reduzindo ainda mais o tamanho final. A assinatura com **cosign** garante integridade e origem da imagem antes de enviá‑la ao registro.

Integração com Docker e LXD
Docker e LXD compartilham o mesmo formato OCI, permitindo que a mesma imagem mínima seja utilizada em ambos os runtimes. Para LXD, basta publicar a imagem no **image server**:
```bash
lxc image import myorg_app_minimal.tar.gz --alias ubuntu/minimal
lxc launch ubuntu/minimal mycontainer
```
Em ambientes Kubernetes, a imagem pode ser referenciada diretamente no manifesto:
```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: webapp
spec:
replicas: 3
template:
spec:
containers:
- name: web
image: myorg/app:minimal
ports:
- containerPort: 8080
```
A compatibilidade garante que a mesma política de redução de bloat seja aplicada em workloads de contêineres de longa duração (LXD) e em pods efêmeros (Docker/K8s).

Considerações de segurança do kernel
Embora a redução de pacotes seja benéfica, o kernel Ubuntu continua sendo o mesmo. Contudo, ao usar imagens mínimas, é crucial garantir que módulos essenciais (e.g., `overlay`, `nf_conntrack`) estejam disponíveis no host. Recomenda‑se:
- Habilitar **AppArmor** com perfis padrão para containers (`docker run --security-opt apparmor=unconfined`).
- Utilizar **seccomp** profiles restritivos (`--security-opt seccomp=profile.json`).
- Manter o kernel atualizado via **unattended-upgrades** para receber patches de CVE críticos.
Além disso, a assinatura de imagens impede que imagens adulteradas introduzam backdoors no kernel, reforçando a cadeia de confiança.

Conclusão – Estabilidade em produção
A estratégia "Cut bloat, not features" traz para o Ubuntu um caminho sólido para criar containers OCI menores, mais rápidos e com menor ruído de vulnerabilidades. Para sysadmins, a adoção dessas imagens significa menor tempo de deploy, economia de recursos e um ambiente de produção mais previsível. Ao combinar debootstrap minimal, BuildKit, assinatura com cosign e scanners como Trivy, é possível garantir que a redução de tamanho não comprometa a estabilidade nem a segurança do kernel. Em ambientes corporativos, a prática recomendada é migrar gradualmente workloads críticos para as novas imagens, validar a compatibilidade em um staging controlado e, finalmente, promover a mudança para produção, assegurando que os SLAs de disponibilidade sejam mantidos.