La virtualisation est de loin la plus simple.
Cependant, vous avez ici 2 cas d'utilisation distincts, qui auront différentes solutions
1. Essayez de nouvelles distributions
Les distributions sont essentiellement déterminées par les applications packagées et l'environnement de l'espace utilisateur (par exemple, SystemD
vs init
pour le démarrage)
Si vous voulez "évaluer" l'UIX d'une distribution différente, qualitativement, alors je recommanderais la virtualisation complète où vous installez le système d'exploitation dans son intégralité et évaluer sa convivialité. Ceci est couvert de manière adéquate dans d'autres réponses.
Si vous avez simplement besoin de l'environnement de l'espace utilisateur pour les tests, lisez la suite.
2. Test et "instances à jeter" dans différents environnements
Il est plus facile, moins cher et plus rapide d'utiliser la conteneurisation, une forme de virtualisation légère qui utilise le noyau pour créer des environnements en bac à sable.
Un conteneur partage les ressources du noyau avec l'hôte, mais a par ailleurs son propre système de fichiers racine, espace utilisateur, pile réseau, etc. Il peut être considéré, conceptuellement, comme un chroot
on stéroïdes. Cependant, comme le noyau est partagé, la virtualisation est "mince", ce qui signifie qu'à des fins pratiques, il s'exécute à la même vitesse que le système d'exploitation hôte.
Il existe un système de conteneurs couramment utilisé appelé docker
. Docker a des images standardisées pour pratiquement toutes les distributions Linux que vous souhaitez, et il fonctionne sur Windows (cependant, les images Windows ne fonctionnent que sur Windows, les images Linux fonctionnent sur les deux). Il a des fonctionnalités supplémentaires utiles pour économiser de l'espace et des performances.
Il existe également des alternatives natives open source pour Linux comme LXC
(qui est intégré au noyau!), Qui peuvent être utilisées à peu près la même chose (mais avec plus de configuration requise).
Exemple simplifié d'un environnement de test ou de construction dans docker
# Dockerfile
FROM ubuntu:17.10
RUN apt-get update && apt-get install -y build-essential
WORKDIR /workdir
docker build --tag my-builder .
Ensuite, à partir de la ligne de commande, compilez votre projet ou vos tests dans cet environnement de différentes manières
"connectez-vous" et compilez dans l'environnement, exécutez des tests, etc. En supposant que vous êtes dans le répertoire source de votre projet
$ docker run -v "$PWD:/workdir" --rm -it my-builder /bin/bash
# echo "Now in docker container"
# make
...
# build/test/my-test
...
# exit
$ echo "Build artifacts are now on your host OS Directory :) "
Utiliser en une seule fois
$ docker run -v "$PWD:/workdir" --rm my-builder make
Vous pouvez même transmettre des variables d'environnement
$ docker run -e "CROSS_COMPILE=arm-linux-gnueabi" -v "$PWD:/workdir" --rm my-builder make
Ou démarrez une instance persistante et copiez-y explicitement les fichiers
$ Start our instance in background
$ docker run --name my-builder-inst -d my-builder
$ echo "Copy files to instance"
$ docker cp /my/source/dir my-builder-inst:/workdir
$ echo "run project build"
$ docker exec my-builder-inst make
$ echo "copy build artifacts"
$ docker cp my-builder-inst:/workdir/build /my/output/dir
$ echo "destroy and delete container"
$ docker rm -f my-builder-inst
Il existe littéralement des centaines d'autres modèles d'utilisation, cependant, la définition d'image de type script, les images extensibles et l'utilisation en ligne de commande le rendent extrêmement attrayant pour les environnements de développement, de test et même de déploiement.