Una lección sobre contenerizar scripts de shell

Artículo original ↗ Discusión en Hacker News ↗

Los esfuerzos por reducir una imagen Docker para una herramienta bash de 500 líneas destacan la compensación entre tamaños de imagen mínimos y mantenibilidad a largo plazo. Los comentaristas advierten que copiar manualmente binarios y bibliotecas compartidas en una imagen `scratch` o basada en Alpine puede crear contenedores frágiles y difíciles de depurar, que se rompen con actualizaciones del sistema, por un ahorro de espacio solo marginal frente a una imagen base sencilla de 30 MB. La conversación se amplía a cuándo está justificado contenerizar scripts de shell simples, abordando alternativas como binarios estáticos, BusyBox, Nix y gestores de paquetes tradicionales, así como herramientas para analizar y optimizar imágenes.

Tamaño de imagen vs. complejidad

  • Muchos piensan que la imagen inicial de ~31 MB ya es “lo suficientemente pequeña”; reducirla aún más hasta ~17 MB no merece la complejidad adicional para la mayoría de los usos en producción.
  • Varios comentaristas prefieren aceptar una imagen de 30–40 MB antes que mantener un Dockerfile frágil y altamente afinado.
  • Otros disfrutan del ejercicio de optimización como herramienta de aprendizaje y valoran explorar qué es lo mínimamente necesario para ejecutar el script.

Copiar binarios y bibliotecas compartidas

  • Fuerte crítica a copiar binarios y archivos .so directamente de una imagen Alpine a otra (o a scratch) y sobrescribir las rutas del sistema para lib/bin.
  • Preocupaciones: desajuste de versiones, enlaces simbólicos rotos, incompatibilidades sutiles a medida que evolucionan las imágenes base, e imágenes frágiles que pueden romperse silenciosamente más adelante.
  • Algunos sostienen que esto se mitiga en parte cuando el origen y el destino usan la misma versión base, pero otros consideran el patrón como una reinvención “anti‑gestor de paquetes”.

Alpine, reproducibilidad y fijación de versiones

  • Se describe Alpine como hostil a la fijación de versiones y a las compilaciones reproducibles a largo plazo: los paquetes y los índices desaparecen rápidamente.
  • Recomendación: no usar Alpine si necesitas compilaciones Docker reproducibles y amigables con la caché; las imágenes Debian basadas en snapshots se citan como una dirección más prometedora.

Alternativas para imágenes pequeñas

  • Las sugerencias incluyen:
    • Binarios estáticos o compilaciones de BusyBox en lugar de copiar muchas herramientas individuales.
    • Usar Nix para definir imágenes de forma declarativa; funciona, puede ser muy pequeño, pero a menudo arrastra closures grandes (por ejemplo, “gitMinimal” sigue siendo grande) y añade complejidad.
    • Reescribir la herramienta en un lenguaje compilado con un único binario estático, si alguien está dispuesto a invertir el esfuerzo.

Seguridad, confianza y auditoría

  • Debate sobre si “scripts de shell aleatorios” o “imágenes Docker aleatorias” son más seguros.
  • Puntos a favor de los scripts: más fáciles de leer y de pasar por herramientas como ShellCheck.
  • Puntos a favor de los contenedores: aislamiento mediante namespaces y controles de volumen/red, con herramientas como Dive para inspeccionar el contenido.
  • Contraargumento: los contenedores no son barreras de seguridad fuertes; existen escapes, y auditar imágenes completas junto con las capas base no es trivial.

Utilidad de contenerizar un script de shell

  • Algunos consideran que contenerizar un script bash de 500 líneas que solo necesita herramientas estándar es excesivo.
  • Otros argumentan que los contenedores simplifican la gestión de dependencias y hacen que las herramientas sean reproducibles en muchas máquinas.
  • Se plantean preocupaciones prácticas: aún necesitas un envoltorio (script/alias/compose) para montar el directorio de trabajo y hacer que el uso sea ergonómico.