Arch Linux agora oferece imagens Docker reproduzíveis bit por bit

• Imagens Docker do Arch Linux com reprodutibilidade bit por bit passam a ser oferecidas, estendendo ao Docker o mesmo marco alcançado há alguns meses nas imagens WSL
• As imagens são distribuídas com a tag dedicada repro e, para garantir a reprodutibilidade, as chaves do pacman são removidas, então não é possível usar o pacman imediatamente no estado padrão
• Para instalar ou atualizar pacotes dentro do contêiner, é necessário recriar o keyring, o que pode ser inicializado com pacman-key --init && pacman-key --populate archlinux
• A reprodutibilidade é verificada por correspondência de digest entre builds e por comparação com diffoci, junto com ajustes como build determinístico do rootFS, normalização de timestamps e remoção do cache auxiliar do ldconfig
• O procedimento de reprodução pode ser consultado em REPRO.md e, no futuro, isso pode evoluir para rebuilds e verificação automáticos por meio de um servidor rebuilder, além da publicação de logs e resultados de build

---

Conteúdo principal

• As imagens Docker do Arch Linux agora são fornecidas em formato reproduzível bit por bit, estendendo ao Docker o mesmo marco alcançado há alguns meses nas imagens WSL
• Essas imagens são distribuídas com a tag repro dedicada e, para garantir a reprodutibilidade, é necessário remover as chaves do pacman da imagem, então não é possível usar o pacman imediatamente
  • Até que uma solução adequada seja definida, essa limitação faz com que elas sejam oferecidas primeiro em uma tag separada
• Para instalar ou atualizar pacotes dentro do contêiner, primeiro é preciso recriar o keyring executando pacman-key --init && pacman-key --populate archlinux
  • Na primeira execução, isso pode ser feito de forma interativa ou em uma instrução RUN no Dockerfile que use essa imagem como base
  • No Distrobox, isso pode ser tratado com um pre-init hook, como em distrobox create -n arch-repro -i docker.io/archlinux/archlinux:repro --pre-init-hooks "pacman-key --init && pacman-key --populate archlinux"
• A reprodutibilidade bit por bit da imagem é confirmada pela correspondência de digest entre builds e validada com podman inspect --format '{{.Digest}}' <image> e comparação com diffoci
• Como reproduzir essa imagem Docker pode ser visto em REPRO.md

Implementação e ajustes

• O maior desafio foi construir de forma determinística o rootFS base da imagem Docker, reutilizando o mesmo processo das imagens WSL, que compartilham o sistema de build do rootFS
  • O commit relacionado ao WSL pode ser visto aqui
• Entre os ajustes específicos para Docker, um deles foi definir SOURCE_DATE_EPOCH e alinhar também o LABEL org.opencontainers.image.created do Dockerfile a esse valor
• No estágio do Dockerfile, foi removido o arquivo de cache auxiliar do ldconfig, var/cache/ldconfig/aux-cache, que causava não determinismo na imagem gerada
• Ao usar docker build ou podman build, são aplicadas normalizações de timestamp com as opções --source-date-epoch=$SOURCE_DATE_EPOCH e --rewrite-timestamp
  • Como exemplo, foi apontado o problema de horários diferentes em etc/, etc/ld.so.cache, etc/os-release, sys/, var/cache/, var/cache/ldconfig/, proc/, dev/
• O conjunto completo das mudanças relacionadas pode ser visto com mais detalhes no diff do merge request do repositório archlinux-docker
• Como próximo passo, está sendo considerado montar um rebuilder em servidor para as imagens Docker, as imagens WSL e futuras imagens reproduzíveis, com rebuilds automáticos periódicos, verificação de reprodutibilidade e publicação de logs e resultados de build

[GN⁺]

Comentários do Hacker News

• É bom ver esse tipo de confiança
  Rodei Arch Linux no WSL 2 por quase 1 ano e foi excelente, depois usei Arch nativo por cerca de 5 meses e também fiquei muito satisfeito
  Ainda uso Arch nativo até hoje, e testo meus dotfiles com uma imagem Docker do Arch em um sistema de arquivos limpo
  Quando preciso de testes de ponta a ponta configurando até um ambiente de desktop completo, rodo Arch em uma VM
  Tenho muitos problemas, mas pelo menos o Arch em si não é um deles

  • Fiquei curioso se também existe staged rollout ou rollback para mudanças nos dotfiles
    Eu estava procurando uma configuração de dotfiles nível enterprise com métricas do Prometheus e health probes, então isso me soou exatamente assim
  • Obrigado por dar suporte a outras distros, e também por compartilhar isso
    Eu nunca tinha achado que precisava disso, mas assim que vi passei a precisar
  • Fiquei curioso se você também já usou NixOS ou flakes
    Se sim, queria ouvir qual foi a sua impressão

• Acho que todos os contêineres Docker deveriam ter sido assim desde o começo
  Rodar apt-get update durante a etapa de docker build é quase um antipadrão

  • Mas vira exceção se você usar https://github.com/reproducible-containers/repro-sources-lis...
    Já usei e funcionou muito bem
  • De qualquer forma, nada disso é totalmente confortável
    Se você não atualiza, o contêiner acumula problemas de segurança conhecidos; se atualiza, a reprodutibilidade quebra
    Reprodutibilidade é claramente algo legal e traz vantagens de segurança, mas quando um contêiner passa de um mês talvez já comece a parecer um antipadrão, e uma vida útil máxima medida em dias talvez seja mais apropriada
  • Sei que é um antipadrão, mas não sei qual seria a alternativa quando você precisa instalar software
    A ideia seria baixar código-fonte tagueado e compilar tudo manualmente com gcc?
  • Não concordo em tratar isso como uma regra absoluta
    Contêineres reproduzíveis são ótimos, mas nem sempre são necessários, e existem muitos casos em que faz todo sentido rodar apt-get dentro do contêiner e não se preocupar com reprodutibilidade
  • Isso fica ainda mais difícil porque muitas distros apagam versões antigas dos repositórios assim que sai uma versão nova
    Claro, ainda dá para buscar em archives

• Imagens reproduzíveis muitas vezes parecem um recurso que só traz satisfação emocional no dia a dia, mas chega o dia em que isso se torna indispensável
  Nós já tivemos duas imagens que deveriam ser idênticas produzindo uma diferença de 3 bytes no timestamp em máquinas diferentes, e por causa disso perdemos uma tarde inteira fazendo bisect na direção errada
  Não foi algo glamouroso, mas foi uma vitória claramente valiosa

  • Fiquei curioso sobre como exatamente uma diferença de timestamp acabou levando a uma falha

• Acho que provavelmente dá para encaixar alguma coisa que anuncie para todo mundo que você usa Arch no pipeline de CI/CD
  Junto com o fato de que você faz Crossfit, claro

  • Isso me lembra um koan
    Se você encontra uma pessoa vegana, praticante de CrossFit e usuária de Arch, o que ela vai te contar primeiro?
  • Nunca entendi por que alguém teria orgulho de dizer que não usa Slackware

• Dá para ver informações sobre Reproducible Builds aqui
  https://reproducible-builds.org/
  A comunidade relacionada de Bootstrappable Builds está aqui
  https://bootstrappable.org/

• Fico pensando se sistemas como Arch ou Alpine, que são sistemas operacionais mutáveis bem projetados, podem no longo prazo vencer algo como o NixOS
  Scripts de instalação têm mais expressividade do que linguagens de configuração declarativa e, em geral, também não são mais verbosos

  • Nesse caso talvez fosse melhor usar Guix
    Você ganha uma linguagem de configuração declarativa e, ao mesmo tempo, uma linguagem de programação Turing-completa e agradável de usar
  • Fiquei curioso sobre o que exatamente significa strictly more powerful

• Li o texto e parece bem legal, mas fiquei com a impressão de que ele mistura Dockerfile e imagem docker como se fossem a mesma coisa
  Talvez tivesse sido mais fácil construir diretamente o arquivo tar da imagem com algo como o nix em vez de usar Dockerfile; claro, seria algo mais de nicho, mas ainda assim pareceria mais limpo

• Pequena observação: acho mais correto usar o termo OCI Image
  Funciona perfeitamente no podman também

  • Sou meio iniciante para acompanhar todo o contexto desta seção de comentários, mas isso me pareceu um ponto bem esclarecedor

• Tenho um respeito enorme pelas pessoas que de fato tornaram isso possível
  O tempo e o esforço necessários para produzir uma manchete assim são muito maiores do que parece

• Totalmente à parte, mas havia uma animação naquela página que fazia quase todos os elementos descerem cerca de 20 pixels por aproximadamente 1 segundo
  Como o layout estava claramente chacoalhando diante dos meus olhos, achei que isso naturalmente detonaria o CLS, mas o CLS real era 0
  Isso me fez pensar se CLS é uma métrica enganosa

  • Isso acontece por causa de animações intencionais
    O CLS lida com mudanças durante a renderização inicial, então mesmo que pareça um deslocamento de layout, não é o tipo de coisa que entra no CLS
  • Isso não é um layout shift
    É um movimento causado por CSS transition, uma mudança previsível, então não é contabilizado como layout shift