Como posso criar um ambiente de compilação completamente descartável?

Question

Suponha que eu tenha uma nova instalação de uma distribuição comum do Linux. Eu faço o download de um tarball contendo o código-fonte de um aplicativo da web que gostaria de criar e hospedar. O projeto é um pouco moderno, então eu preciso instalar pacotes do sistema para Node.js / npm e Ruby / gem. Eu tenho que npm install -g algumas coisas, gem install outros, e quando todos os pré-requisitos estão presentes eu posso construir a aplicação para produzir .js e .css arquivos que podem ser servidos por um servidor web.

Agora que tenho o aplicativo criado, gostaria de remover tudo o que tinha de instalar para chegar a esse ponto. Não preciso da fonte original, nem dos compiladores JS / CSS nem das dependências agora compilado no artefato de compilação, e em alguns casos eu nem preciso mais do Node.js / Ruby instalado. Não tenho intenção de recompilar o código tão cedo, e se esse dia chegar, simplesmente reinstalarei os pré-requisitos.

Estou procurando uma maneira simples de "derrubar" todas as alterações que tive que fazer no sistema para criar o aplicativo. Ou seja, retorne o sistema para o estado em que estava antes de fazer o download do tarball, mas permita que o artefato de construção final permaneça. (Seria ótimo se o processo fosse de propósito geral o suficiente para permitir que um fluxo de trabalho similar funcionasse para a compilação C / C ++, não obstante os problemas de biblioteca compartilhada.)

Eu olhei para chroot, o que pode se encaixar no projeto, mas realmente parece um exagero. Eu também considerei construir em uma VM, extrair o artefato de compilação e simplesmente excluir a máquina, mas isso me parece ineficiente também. Existe algum tipo de recurso de "instantâneo" do sistema de arquivos que possa se encaixar neste caso de uso, ou uma maneira de dizer aos vários gerenciadores de pacotes que trabalhem exclusivamente em um diretório temporário descartável dedicado?

    

Answer 1

Você tem algumas opções.

O método tradicional é simplesmente instalar manualmente tudo a partir do código-fonte em seu diretório pessoal e, em seguida, excluir itens quando estiver pronto. Isso tem a vantagem de funcionar em qualquer distro e pode utilizar as bibliotecas do sistema, se você já tiver algumas das dependências instaladas, mas a desvantagem de que muitas vezes é complicado criar algumas coisas certas.

A maioria dos gerenciadores de pacotes também tem a capacidade de instalar em um caminho específico, normalmente definido por meio de uma opção de linha de comando ou de uma variável de ambiente. Eu sei com certeza que o emerge, o pacman e o DNF suportam isso, e eu tenho certeza que o Zypper também. Ao lidar com sistemas baseados em dpkg, você também tem a opção de usar o programa debootstrap para gerar um chroot (use-o para inicializá-lo, então faça um chroot nele e use o gerenciador de pacotes instalado para incluir os pacotes que você precisar. / p>

Existem também algumas opções específicas de distribuição também, sendo as duas grandes:

1. SUSE, quando instalado no BTRFS < tem a capacidade de capturar instantaneamente o sistema antes e depois das transações do gerenciador de pacotes. Isso pode ser usado com algum esforço para alcançar o que você está pedindo, embora eu não possa ajudar muito em explicar exatamente como, porque eu não uso o SUSE regularmente.
2. O gerenciador de pacotes Nix usado no NixOS permite 'perfis' por usuário, que são conjuntos essencialmente personalizáveis de pacotes instalados. Estes podem ser criados, modificados, comutados e destruídos à vontade pelo usuário associado (e você não precisa ser root para usá-los) e, assim, fornecer outra opção rápida para fazer isso.

Answer 2

Chroots simples, contêineres e VMs não são "excessivos". Esse tipo de tarefa é uma das coisas para as quais elas servem - na verdade, elas são essenciais se você quiser evitar fazer alterações irreversíveis em seu sistema. E contêineres e VMs são tão fáceis de usar hoje em dia, que não há realmente nenhuma razão para não fazer isso. Em suma, eles fornecem um ambiente de construção completamente isolado do resto do sistema.

De fato, usar instantâneos de sistema de arquivos para atualizar / instalar coisas no seu sistema principal, construir seu software e reverter para o instantâneo anterior é um exagero. Também é muito grosseiro e potencialmente perigoso para este trabalho ... há muito mais acontecendo em seu sistema a qualquer momento do que apenas compilar um programa (por exemplo, todos os tipos de tarefas em segundo plano, daemons, cron jobs, etc. ou você pode ter baixado e-mail e excluído do servidor pop / imap, ou criado / editado arquivos que não são totalmente relacionados à construção deste programa) - ALL do que será revertido quando você reverter para o instantâneo anterior. As capturas instantâneas do sistema de arquivos são uma boa ideia e uma ferramenta útil, mas são mais bem usadas como parte de uma boa estratégia de backup e / ou recuperação de dedo gordo do que como uma maneira de alternar dinamicamente entre diferentes ambientes operacionais.

A maioria dos sistemas de gerenciamento de contêineres e de VMs (por exemplo, docker , lxc , virsh , virt-manager e muitos mais) facilitam a reinicialização de cada execução com um novo slate, para que você comece exatamente o mesmo ambiente de construção original a cada vez. As imagens de disco da VM geralmente são armazenadas em um formato que pode ser instantâneo e clonado (por exemplo, qcow2 ou zFS do ZFS. Até mesmo um arquivo de imagem de disco bruto pode ser copiado e, opcionalmente, compactado). Você pode fazer o mesmo com um chroot, mas você precisa excluir o chroot e recriá-lo você mesmo (por exemplo, com um arquivo .tar.gz do chroot).

Um processo de configuração e construção bastante básico iniciaria um chroot, um contêiner ou uma VM. Esse pode ser um ambiente de construção genérico que você configura conforme necessário para cada job de construção ou um que esteja pré-configurado para construir apenas um programa específico. Então, use-o para construir seu software e, finalmente, copie para onde ele vai rodar (e / ou construa um pacote para sua distro - se isso parecer muito trabalho, pegue um saque em checkinstall ).

docker em particular tem algumas ferramentas interessantes para automatizar a criação de seu contêiner de criação perfeito e / ou personalizar um contêiner de construção específico com base em um contêiner genérico.

Também é possível automatizar todo o processo de inicialização de uma VM ou contêiner, enviar um trabalho para ele para compilar e, em seguida, desmontá-lo novamente. Existem inúmeras implementações existentes desta ideia, genericamente referidas como build bots (existe um popular programa em Python chamado buildbot , mas o nome, a ideia e as implementações de trabalho existiam muito antes de serem escritas pela primeira vez em 2003). Os robôs de construção são uma parte essencial da Integração contínua (IC) . BTW, falando de CI, o open source GitLab é uma ferramenta muito boa que permite que você execute sua própria fonte semelhante ao github repositório & rastreador de problemas combinado com várias tarefas relacionadas a CI, como criação, teste e implantação automatizados.

Em conclusão , e para responder à sua pergunta: Existem muitas, muitas maneiras de create a completely discardable build environment como você solicitou, e muitas delas estão disponíveis pré-empacotadas para várias distribuições linux (mas você ' Ainda preciso entender como eles funcionam e configurá-los). A parte difícil é decidir exatamente o que você quer dizer com isso, quais recursos você precisa e quanto deseja automatizar.

Outro fator importante, é claro, quanto tempo / esforço vale a pena gastar com isso - por exemplo, Isso é para um laboratório de software doméstico, uma pequena empresa ou startup, ferramentas para ajudá-lo a fazer o seu trabalho que o seu empregador não vê necessidade ou um grande projeto para toda a sua equipe de desenvolvimento ou para toda a empresa?

PS: se você está se perguntando por que todos os links que forneci são para a wikipedia em vez de links diretos para páginas específicas de projetos ou empresas, isso é mais uma visão conceitual do que uma recomendação de um software específico . As páginas da Wikipédia têm links diretos e, mais importante, têm links para softwares semelhantes, páginas de comparação de software e vários conceitos inter-relacionados. Este não é um tópico simples com apenas uma resposta fácil de aprender. Quanto mais você souber, mais fácil será tomar boas decisões que atendam às suas necessidades particulares.