¿Cómo podría crear un entorno de construcción completamente descartable?

Supongamos que tengo una nueva installation de una distribución común de Linux. Descargo un tarball que contiene el código fuente de una aplicación web que me gustaría build y alojar. El proyecto es algo moderno, por lo que requiere que instale packages de sistema para Node.js / npm y Ruby / gem. Tengo que npm install -g algunas cosas, gem install otras, y cuando todos los requisitos previos están presentes puedo build la aplicación para producir files .js y .css que pueden ser servidos por un server web.

Ahora que tengo la aplicación integrada, me gustaría eliminar todo lo que tenía que instalar para llegar a este punto: no necesito la fuente original, los comstackdores de JS / CSS ni las dependencies que ahora están comstackdas. el artefacto de construcción, y en algunos casos ni siquiera necesito instalar Node.js / Ruby. No tengo intención de volver a comstackr el código en el corto ploop, y si llega ese día, simplemente reinstalaré los requisitos previos.

Estoy buscando una manera simple de "derribar" todos los cambios que tuve que hacer en el sistema para build la aplicación. Es decir, devolver el sistema al estado en el que se encontraba antes de download el file tar, pero permitir que el artefacto de construcción final permanezca. (Sería genial si el process fuera algo de propósito general para permitir que un flujo de trabajo similar funcione para la compilation C / C ++, a pesar de los problemas de bibliotecas compartidas).

He investigado en chroot, lo que podría encajar en la factura, pero realmente parece excesivo. También consideré build en una VM, extrayendo el artefacto de construcción y luego simplemente borrando la máquina, pero eso también me parece ineficiente. ¿Hay algún tipo de capacidad de "instantánea" del sistema de files que se pueda adaptar a este caso de uso, o una forma de decirle a los diversos gestores de packages que trabajen exclusivamente en un directory temporal descartable dedicado?

Tienes un par de opciones.

El método tradicional es simplemente instalar manualmente todo desde la fuente en su directory personal, y luego eliminar cosas cuando haya terminado. Eso tiene la ventaja de que funciona en cualquier distribución y puede utilizar bibliotecas de sistema si ya tiene algunas de las dependencies instaladas, pero tiene la desventaja de que a menudo es difícil conseguir algunas cosas para comstackr correctamente.

La mayoría de los administradores de packages también tienen la capacidad de instalar en una ruta específica, generalmente configurada mediante una opción de línea de command o una variable de entorno. Sé con certeza que emerge, pacman y DNF respaldan esto, y estoy bastante seguro de que Zypper también lo hace. Cuando se trata de sistemas basados ​​en dpkg, también tiene la opción de utilizar el progtwig debootstrap para generar un chroot (utilícelo para inicializarlo, luego haga chroot y use el administrador de packages instalado allí para agregar los packages que necesite).

También hay un par de opciones específicas de distribución, las dos más grandes son:

  1. SUSE, cuando está instalado en BTRFS <tiene la capacidad de capturar instantáneamente el sistema antes y después de las transactions del administrador de packages. Esto puede usarse con cierto esfuerzo para lograr lo que está pidiendo, aunque no puedo ayudar mucho explicando exactamente cómo porque no uso SUSE con regularidad.
  2. El administrador de packages Nix utilizado en NixOS permite "perfiles" por usuario, que son esencialmente sets personalizables de packages instalados. Estos pueden ser creados, modificados, cambiados y destruidos a voluntad por el usuario asociado (y usted no necesita ser root para usarlos), y así proporcionar otra opción rápida para hacer esto.

Los chroots, contenedores y máquinas virtuales simples no son "exagerados". Este tipo de tarea es una de las cosas para las que son, de hecho, son esenciales si desea evitar hacer cambios irreversibles en su sistema. Y los contenedores y las máquinas virtuales son tan fáciles de usar en estos días, que realmente no hay razón para no hacerlo. En resumen, te dan un entorno de construcción que está completamente aislado del rest del sistema.

De hecho, el uso de instantáneas del sistema de files para actualizar / instalar cosas en su sistema principal, crear su software y luego volver a la instantánea anterior es excesivo. También es demasiado tosco y potencialmente peligroso para este trabajo … en su sistema suceden muchas más cosas en un momento dado que simplemente comstackr un progtwig (por ejemplo, todo tipo de tareas en segundo plano, daemons, trabajos cron, etc. o puede ha descargado el correo y lo ha eliminado del server pop / imap, o ha creado / editado files que no están relacionados con la compilation de este progtwig) – TODO eso se revertirá cuando vuelva a la instantánea anterior. Las instantáneas del sistema de files son una buena idea y una herramienta útil, pero se usan mejor como parte de una buena estrategia de respaldo y / o recuperación de dedos gordos que como una forma de cambiar dinámicamente entre diferentes entornos operativos.

La mayoría de los sistemas de gestión de contenedores y VM (por ejemplo, docker , lxc , virsh , virt-manager y muchos más) facilitan el reinicio de cada ejecución con una nueva pizarra, de modo que siempre se puede comenzar con el mismo entorno de construcción prístino. Las imágenes de disco VM a menudo se almacenan en un formatting que puede ser qcow2 y clonado (por ejemplo, qcow2 o ZFS zvol. Incluso un file de image de disco sin procesar puede copyrse y opcionalmente comprimirse). Puede hacer lo mismo con un chroot, pero debe eliminar el chroot y recrearlo usted mismo (por ejemplo, con un file .tar.gz del chroot).

Una configuration bastante básica y un process de compilation iniciarían un chroot, contenedor o VM. Este puede ser un entorno de compilation genérico que configure según sea necesario para cada trabajo de compilation o uno que esté preconfigurado para comstackr solo un progtwig específico. Luego, úsela para build su software y, finalmente, cópielo en el lugar donde se ejecutará (y / o cree un package para su distribución; si eso parece demasiado trabajo, tome un botín en la installation de verificación ).

docker en particular tiene algunas buenas herramientas para automatizar la creación de su contenedor de construcción perfecto y / o personalizar un contenedor de construcción específico basado en uno genérico.

También es posible automatizar todo el process de arranque de una máquina virtual o contenedor, enviarle un trabajo para comstackr y luego volver a arrancarlo. Existen numerosas implementaciones existentes de esta idea, genéricamente denominadas compilation de robots (hay un popular progtwig de python GPL llamado buildbot , pero el nombre, la idea y las implementaciones de trabajo existieron mucho antes de que se escribiera por primera vez en 2003). Los robots de compilation son una parte central de la continuous integration (CI) . Por cierto, hablando de CI, el código abierto GitLab es una herramienta bastante buena que le permite ejecutar su propio repository de fuente y seguimiento de problemas similar a Github combinado con varias tareas relacionadas con CI, como creación, testing e implementación automáticas.

En conclusión , y para responder a su pregunta: hay muchas, muchas maneras de create a completely discardable build environment tal como lo solicitó, y muchas de ellas están disponibles preempaquetadas para varias distribuciones de Linux (pero igual tendrá que comprender cómo trabajar y configurarlos). Lo difícil es decidir exactamente qué quiere decir con eso, qué funciones necesita y cuánto desea automatizar.

Otro factor importante, por supuesto, cuánto time / esfuerzo vale la pena gastar en esto – por ejemplo, esto es para un laboratorio de software para el hogar, una pequeña empresa o inicio, herramientas para ayudarlo a hacer su trabajo que su empleador no ve la necesidad ¿o un gran proyecto para todo su equipo de desarrollo o para toda la empresa?


PD: si se pregunta por qué todos los enlaces que he proporcionado son para wikipedia en lugar de enlaces directos a proyectos de software específicos o páginas de empresas, eso se debe a que esta respuesta es más una descripción conceptual que una recomendación de software específico. Las páginas de wikipedia tienen enlaces directos y, lo que es más importante, tienen enlaces a software similar, páginas de comparación de software y numerosos conceptos interrelacionados. Este no es un tema simple con solo una respuesta fácil de aprender. Cuanto más sepa, más fácil será tomar buenas decisiones que se adapten a sus requisitos particulares.