Labtainers
Labtainers copied to clipboard
mfthomps
Controlling labtainers from inside a container
Running labtainers currently relies on running a set of Python scripts (mainly) which control the Docker containers through the docker command-line.
Should one want to avoid installing these Python scripts (and dependencies) on the host, an alternative is to use a VM containing a labtainers installation (such as the ones provided).
As an alternative, may it be possible to provide a "master" labtainers container containing these scripts, that would control the start/stop of these other containers.
In principle this should be faisable since docker can be controlled from within docker. An option is described at https://jpetazzo.github.io/2016/04/03/one-container-to-rule-them-all/ but there may be more recent/alternative options.
These would help running Labtainers from a non-Linux host without installing a big VM, but only something like boot2docker or other lightweight options.
Also I think this may help running Labtainers over a PaaS cloud like OpenShift.
What's you feeling on that feasibility ?
In general, putting the Labtainer control scripts into a container is attractive. And using that container to potentially launch remote containers could help toward a more seamless implementation of the architectures suggested by the "Multi-user Labtainers" section of the Designer Guide. The referenced "one container to rule them all" article suggests the subject method would not work with boot2docker (I've no experience with that yet, so I don't know the implications). Our primary audience remains students running labs on their computers. So, they'd still have to install Docker, and have at least one local script to control the container that controls them all.
I've managed to achieve a PoC running on Linux host with docker. See https://github.com/olberger/Labtainers/commit/0f220dc70129260cb93dcd3f85074ce8b6a5a842 :-)
That might work also with boot2docker, who knows ;-)
I'm moving the changes from the PoC into the baseline. I'm wondering if "docker0" as the name of a container might be potentially confusing since that is the default virtual network. Or maybe that association is desired.
Naming the "master" container docker0 was just a quick way to adjust the script to make the shortest patch... but I guess it should be better to check if we're running on the host, of inside a container, to depend as less as possible on the container's name in the latter case. I was just too lazy to code some more elaborate Python code ;)
For reference, I published a container image on dockerhub which allows testing this with a script like https://github.com/olberger/Labtainers/commit/0f220dc70129260cb93dcd3f85074ce8b6a5a842#diff-e9fffd9185ec493040fe9fc4b9965b19
I just updated the "master" container's entrypoint, pushed at https://github.com/olberger/Labtainers/commit/d2e7d9a229caf012731b5b7faea0cd8176468693 so that the docker group id is set at runtime, according to the host's, and not to the group id at image build time. This should fix permission issues. I know it's lagging behind, but haven't had the time to catch up with latest changes in labtainers
Maybe x11docker could be interesting to allow running the Labtainers' display : https://github.com/mviereck/x11docker
That looks to have a lot of potential, giving the Labtainer environment independence of the host X11 setup.
On Tue, Mar 12, 2019 at 6:22 AM Olivier Berger [email protected] wrote:
Maybe x11docker could be interesting to allow running the Labtainers' display : https://github.com/mviereck/x11docker
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/mfthomps/Labtainers/issues/1#issuecomment-471998046, or mute the thread https://github.com/notifications/unsubscribe-auth/AUSE27sMmlbI18c5OA94yRcPRcmfZkA4ks5vV6orgaJpZM4TS7v_ .
FYI, I've improved our build process for the master container image, in order to use a 2 stage build that will rebuild labtainer from Git instead of downloading the archive.
See https://gitlab.com/olberger/virtual-labs/blob/master/labtainer-docker/Dockerfile and associate Makefile and docs
At this time, it is not practical to run a new dockerd within a Docker container. The Docker-recommended method of sharing the dockerd with containers via a socket works fine -- however it means that all "master" instances share the same dockerd. This is OK for single-user cases, but creates naming conflicts if you attempt to support multiple students on one server.
For multi-user cases, consider assigning each student a stripped down VM, e.g., a simple Linux server that runs Docker. That Docker would then host the "master" and its x11 server. The master would then start Labtainers, using the underlying dockerd. Students would be isolated via the VMs.
Yup.
I've neglected Labtainers for a while, but am still interested (as you may see in https://speakerdeck.com/oberger/experimentations-autour-de-tps-en-distanciel-tps-sur-le-cloud, in french), but I'm still thinking about its integration with kubernetes.
Since our former experiments with Labtainers, I have investigated Kubernetes and Antidote https://nrelabs.io/ , the platform that runs NRELabs over a kubernetes cluster.
I think it would be great to be able to run Labtainers labs over Antidote. Maybe through the use of tiny VMs sandboxing of the k8s pods, for increased security.
The nice thing in Antidote is that every learner has her own "environment" (inside a separate k8s namespace) to run multiple PODs, for playing with a particular virtualized network topology, including virtualized appliances (like Juniper router clones, etc.). It's thus quite similar to Labtainers.
The main difference is that Labtainer may involve GUI tools, whereas Antidote is currently limited to terminals for interacting with the lab endpoints.
I think that Kubernetes should probably be he most generic way forward for multi-user deployment of such lab environments, even though I haven't yet deployed it in an academic context.
Hope this makes sense