Arch Linux ahora ofrece imágenes de Docker reproducibles bit por bit

• Ya están disponibles imágenes de Docker de Arch Linux con reproducibilidad bit por bit, extendiendo a Docker el mismo hito que se logró hace unos meses con las imágenes de WSL
• Las imágenes se distribuyen con una etiqueta dedicada, repro, y para garantizar la reproducibilidad se eliminan las claves de pacman, por lo que pacman no puede usarse de inmediato en el estado predeterminado
• Para instalar o actualizar paquetes dentro del contenedor, es necesario regenerar el keyring; se puede inicializar con pacman-key --init && pacman-key --populate archlinux
• La reproducibilidad se verifica mediante la coincidencia del digest entre compilaciones y con comparaciones usando diffoci; además, se aplicaron ajustes como compilaciones determinísticas del rootFS, normalización de marcas de tiempo y eliminación de la caché auxiliar de ldconfig
• El procedimiento de reproducción puede consultarse en REPRO.md, y a futuro podría ampliarse con servidores rebuilder para recompilación y verificación automáticas, además de la publicación de logs y resultados de compilación

---

Contenido clave

• La imagen de Docker de Arch Linux ahora se ofrece en una forma reproducible bit por bit, extendiendo al lado de Docker el mismo hito que se alcanzó hace unos meses con la imagen de WSL
• Esta imagen se distribuye con la etiqueta dedicada repro y, para garantizar la reproducibilidad, fue necesario eliminar las claves de pacman de la imagen, por lo que pacman no puede usarse inmediatamente
  • Hasta que exista una solución adecuada, esta limitación hace que por ahora se ofrezca como una etiqueta separada
• Para instalar o actualizar paquetes dentro del contenedor, primero hay que ejecutar pacman-key --init && pacman-key --populate archlinux para regenerar el keyring
  • En la primera ejecución puede hacerse de forma interactiva, o ejecutarse en una instrucción RUN de un Dockerfile que use esta imagen como base
  • En Distrobox, puede manejarse con un pre-init hook como este: distrobox create -n arch-repro -i docker.io/archlinux/archlinux:repro --pre-init-hooks "pacman-key --init && pacman-key --populate archlinux"
• La reproducibilidad bit por bit de la imagen se confirma mediante la coincidencia del digest entre compilaciones, y se verifica con podman inspect --format '{{.Digest}}' <image> y comparaciones con diffoci
• Cómo reproducir esta imagen de Docker puede consultarse en REPRO.md

Implementación y ajustes

• El mayor desafío fue compilar de forma determinística el rootFS base para la imagen de Docker, y se reutilizó el mismo proceso que en la imagen de WSL, que comparte el sistema de compilación del rootFS
  • El commit relacionado de WSL puede verse aquí
• Entre los ajustes específicos para Docker, uno fue configurar SOURCE_DATE_EPOCH y hacer que la LABEL org.opencontainers.image.created del Dockerfile también siguiera ese valor
• En la imagen compilada se eliminó, en la etapa del Dockerfile, el archivo de caché auxiliar de ldconfig, var/cache/ldconfig/aux-cache, que provocaba no determinismo
• Al usar docker build o podman build, se aplica normalización de marcas de tiempo con las opciones --source-date-epoch=$SOURCE_DATE_EPOCH y --rewrite-timestamp
  • Como ejemplo, se mostraba el problema de que las horas de etc/, etc/ld.so.cache, etc/os-release, sys/, var/cache/, var/cache/ldconfig/, proc/ y dev/ quedaban registradas de forma distinta
• Todos los cambios relacionados pueden revisarse con más detalle en el diff del merge request del repositorio archlinux-docker
• Como siguiente paso, se está considerando construir en un servidor un rebuilder para la imagen de Docker, la imagen de WSL y futuras imágenes reproducibles, con el fin de realizar recompilaciones automáticas periódicas, verificar la reproducibilidad y publicar logs y resultados de compilación

[GN⁺]

Comentarios de Hacker News

• Da gusto ver este nivel de confianza
  Corrí Arch Linux en WSL 2 durante casi un año y me fue excelente, y después usé Arch nativo por unos 5 meses y también quedé muy satisfecho
  Sigo usando Arch nativo ahora mismo, y pruebo mis dotfiles con una imagen Docker de Arch sobre un sistema de archivos limpio
  Cuando necesito pruebas de extremo a extremo que incluso monten un entorno de escritorio completo, corro Arch en una VM
  Tengo muchos problemas, pero al menos Arch no es uno de ellos

  • Me pregunto si también hay staged rollout o rollback para cambios en los dotfiles
    Justo estaba buscando una configuración de dotfiles nivel enterprise con métricas de Prometheus y health probes, y esto suena exactamente a eso
  • Gracias por dar soporte a otras distros, y también por compartirlo
    Ni siquiera había pensado que necesitaba esto, pero en cuanto lo vi, lo necesité
  • Me pregunto si también has probado NixOS o flakes
    Si sí, me gustaría escuchar qué te parecieron

• Creo que todos los contenedores Docker debieron haber sido así desde el principio
  Ejecutar apt-get update en la etapa de docker build es casi un antipatrón

  • Aunque si usas https://github.com/reproducible-containers/repro-sources-lis..., sería una excepción
    Lo he usado yo mismo y funcionó bastante bien
  • De cualquier forma, ninguna de las dos opciones es totalmente cómoda
    Si no actualizas, se te acumulan problemas de seguridad conocidos en el contenedor, y si actualizas, se rompe la reproducibilidad
    La reproducibilidad sin duda es genial y también tiene ventajas de seguridad, pero una vez que el contenedor pasa del mes puede empezar a sentirse como un objetivo equivocado, y quizá una vida útil máxima medida en días sea más apropiada
  • Sé que es un antipatrón, pero no sé cuál sería la alternativa cuando necesitas instalar software
    Me pregunto si la idea es bajar código fuente etiquetado y compilarlo todo uno mismo con gcc
  • No estoy de acuerdo con verlo como una regla absoluta
    Los contenedores reproducibles son algo bueno, sí, pero no siempre son necesarios, y hay bastantes casos en los que puedes ejecutar apt-get dentro del contenedor sin preocuparte por la reproducibilidad
  • También se complica más porque muchas distros borran las versiones viejas del repo en cuanto sale una nueva
    Claro, siempre queda la opción de sacarlas del archivo histórico

• Las imágenes reproducibles muchas veces parecen una función que solo da satisfacción emocional en el día a día, pero llega el día en que de verdad la necesitas
  A nosotros nos pasó que dos imágenes que debían ser idénticas terminaron con una diferencia de 3 bytes en el timestamp entre máquinas distintas, y por eso perdimos toda una tarde haciendo bisect en la dirección equivocada
  No es algo vistoso, pero definitivamente fue una victoria valiosa

  • Me da curiosidad cómo una diferencia en el timestamp terminó provocando una falla

• Seguro podría meter algo para que todo el mundo se entere de que uso Arch en mi pipeline de CI/CD
  Supongo que también junto con el dato de que hago Crossfit

  • Me recuerda a este koan
    Si te encuentras con un vegano que hace CrossFit y además es usuario de Arch, ¿qué es lo primero que te va a decir?
  • Nunca he entendido por qué alguien se sentiría orgulloso de no usar Slackware

• Aquí pueden ver información sobre Reproducible Builds
  https://reproducible-builds.org/
  Y la comunidad estrechamente relacionada de Bootstrappable Builds está aquí
  https://bootstrappable.org/

• Me pregunto si sistemas como Arch o Alpine, que son sistemas operativos mutables bien diseñados, podrían terminar superando a largo plazo a algo como NixOS
  Porque los scripts de instalación son más expresivos que un lenguaje de configuración declarativa, y por lo general tampoco son más verbosos

  • En ese caso, mejor usar Guix
    Tienes un lenguaje de configuración declarativa, y al mismo tiempo un lenguaje de programación completo de Turing y cómodo de escribir
  • Me pregunto qué significa exactamente strictly more powerful

• Leí el artículo y se ve bastante bien, pero da la impresión de que mezcla Dockerfile con docker image
  Creo que habría sido más fácil construir directamente el archivo tar de la imagen con algo como nix en vez de usar Dockerfile; claro, sería un poco más de nicho, pero también habría quedado más limpio

• Como detalle menor, creo que sería más correcto usar el término OCI Image
  También funciona perfectamente en podman

  • En esta sección de comentarios ando un poco novato y no sigo todo el contexto, pero esto me pareció un punto bastante revelador

• Mi enorme respeto para quienes hicieron esto realmente posible
  El tiempo y esfuerzo que se necesita para lograr un titular como este es mucho mayor de lo que uno imagina

• Es un tema totalmente aparte, pero esa página tiene una animación donde, durante 1 segundo, casi todos los elementos bajan unos 20 píxeles
  Viendo el layout moverse frente a mis ojos, pensé que iba a destrozar el CLS, pero el CLS real era 0
  Entonces me hizo preguntarme si CLS será una métrica engañosa

  • Eso pasa por tratarse de una animación intencional
    CLS se ocupa de cambios durante el renderizado inicial, así que aunque parezca un desplazamiento del layout, no es del tipo que cuenta para CLS
  • Eso no es un layout shift
    Es movimiento causado por una CSS transition, un cambio predecible, y por eso no se cuenta como layout shift