Nix, um construtor de imagens Docker melhor que o construtor de imagens do Docker

Nix é melhor que o construtor de imagens do Docker

• O Nix tem três aspectos: gerenciador de pacotes, linguagem e sistema operacional.
• Há vantagens em usar o Nix para criar imagens Docker em vez do próprio construtor de imagens do Docker.
• O Nix permite conhecer antecipadamente todas as dependências necessárias no processo de build e possibilita compilar mesmo sem conexão com a internet.

Vantagens do Nix

• Com o Nix, é possível criar imagens Docker de forma mais eficiente.
• O Nix divide as dependências em um número mínimo de camadas Docker, refletindo apenas as mudanças mínimas nas atualizações.
• Quando vários serviços estão no mesmo repositório, eles podem compartilhar camadas Docker entre si, aumentando a eficiência.

Exemplo do serviço de citações de Douglas Adams

• É explicado o processo de empacotar um programa Go com Nix e convertê-lo em uma imagem Docker.
• É possível criar uma imagem em camadas usando a função dockerTools.buildLayeredImage.
• Como resultado, obtém-se uma imagem de contêiner comum, que pode ser implantada em qualquer lugar.

Opinião do GN⁺

• Usar o Nix pode melhorar bastante o gerenciamento de dependências e a reprodutibilidade dos builds no processo de desenvolvimento de software.
• Em comparação com o Docker, o Nix pode economizar tempo e recursos no longo prazo graças à natureza determinística dos builds.
• No entanto, os novos conceitos e a forma de uso do Nix podem ser um pouco difíceis para iniciantes, e pode haver dificuldades para integrá-lo aos pipelines de CI/CD existentes.
• Ao adotar essa tecnologia, é necessário considerar um período de treinamento e adaptação dentro da equipe, além da compatibilidade com a infraestrutura existente.
• Outra ferramenta com funcionalidades semelhantes ao Nix é o Guix, que também oferece gerenciamento de pacotes e builds determinísticos.

[GN⁺]

Comentários do Hacker News

• Tentei várias vezes gostar do Nix, mas acho que chegou a hora de desistir.

  • Tenho dois sistemas usando Nix, mas tenho medo de mexer neles.
  • Em teoria, o Nix é idempotente e determinístico, mas se você não entender exatamente toda a parte das dependências, pode acabar encontrando resultados estranhos e erros que não ajudam.
  • A documentação é muito ruim, e os tutoriais ajudam só em parte.
  • A força do Docker está no próprio caos: com apenas um entendimento básico de shell e gerenciador de pacotes, dá para construir quase qualquer coisa com facilidade.

• Nix e NixOS estão em um estado parecido com o do git antes do GitHub.

  • A ideia básica se apoia em uma ciência da computação mais séria do que o SVN e o Docker atuais.
  • A situação pode ter mudado com o lançamento do flox, que é fácil de usar.
  • Sem flakes e nix-command, o Nix não faz sentido, e ambos são experimentais e vêm desativados por padrão.
  • Nix/NixOS ou algo parecido vai colocar o Docker nesse mesmo estado, mas isso não vai acontecer antes de chegar o momento GitHub.

• Passei 2 a 3 dias tentando construir imagens Docker no Darwin, e este artigo parece estar zombando de mim.

  • O Nix é a melhor ferramenta para alcançar o que você quer, mas às vezes tem cantos obscuros que drenam a alma.

• Falta no post do blog uma explicação de por que camadas Docker compartilhadas são úteis.

  • Elas são úteis por causa do cache. Quanto mais imagens compartilham a mesma camada, melhor o cache funciona.
  • O Nix já armazena dependências por hash, então as camadas são sempre idênticas, com a mesma versão e configuração.

• A experiência de construir imagens Docker para aplicações Java com Nix não foi muito agradável.

  • Depois que o gradle2nix foi descontinuado, não há uma alternativa clara para construir imagens Docker de aplicações Java baseadas em Gradle.

• É útil se você já adotou o Nix, e espero que soluções de gerenciamento de pacotes mais declarativas, como Nix ou Guix, se popularizem.

  • Se você quer adotar Nix aos poucos enquanto usa Docker, existe uma abordagem alternativa de construir a configuração do Nix mantendo o Dockerfile.

• Como engenheiro de plataforma, eu queria gostar do Nix, mas ele não é fácil para todo mundo.

  • Por exemplo, prefiro adicionar pacotes com algo como devbox add python@3.11.

• O Nix é incompatível com o upstream a ponto de exigir um esforço considerável de empacotamento para a maioria das bibliotecas.

  • No caso de bibliotecas C ou C++ complexas, embrulhar tudo para o Nix acaba sendo uma parte significativa do trabalho.

• Recentemente tentei construir uma imagem base de CI com Nix, mas a imagem ficou grande demais e alguns jobs não funcionaram direito por causa de problemas de linking.

  • Para construir imagens multiarquitetura, ele realmente tenta executar na outra arquitetura, e isso só oferece suporte à virtualização de hardware com qemu.

• Estou usando o Dagger, e ele resolve a maior parte dos problemas como a segunda tentativa dos criadores do Docker.

  • Você pode escrever pipelines na linguagem que já usa e aproveitar recursos avançados do BuildKit, como grafo de camadas e cache avançado.