Tag: labs

Experimenting on distant labs and labs on the Cloud

I have delivered a speech last week about some ideas and experiments I have about the use of remote access and Cloud technologies for labs. I have collected the speech recording and stuff, in french, in another post.

The presentation was in french originaly, so I’ve quickly translated my slides and recorded an english version.

I mention tools like Guacamole, MeshCentral, NRELab’s Antidote, Eclipse Che and Labtainers, as well as k8s and Docker, as interesting tools that may allow us to continue teaching in labs while allowing more flexibility, distant learning, and hopefully improved quality.

You can find the slides here: https://speakerdeck.com/oberger/experimenting-on-distant-labs-and-labs-on-the-cloud, and the recording is here:

Experimenting on distant labs and labs on the Cloud.

Running networking labs over Kubernetes with Antidote

I’ve just come across Antidote a recent project that intends at running networking-oriented labs over Kubernetes. It is developped by members of the Network Reliability Engineering community (Juniper-related, AFAIU), to power the NRE Labs platform.

It looks very similar to other platforms that allow you to run labs remotely in consoles opened on cloud machines, alongside lab instructions.

I find it interesting as the code is published under FLOSS license (Apache), and seems to be runable over any Kubernetes installation: you can test it with Minikube through the selfmedicate repo.

Antidote demo running virtual labs in Kubernetes with selfmedicate/minikube, running locally from Olivier Berger on Vimeo.

Internally, it uses Guacamole to provide the Web consoles connected via SSH to the hosts (or emulated devices) running on the k8s cluster. Each learner will get her own k8s namespace running the corresponding PODs.

In principle, it’s rather easy to package any app that can be used from the CLI to run it over Antidote.

The main drawback I’ve found so far, wrt our experiments with virtual labs, is the limitation to SSH access for a CLI: the Guacamole setup doesn’t provide access to VNC, AFAICS (yet).

Quite interesting and promising project anyway.

Recrutement ingénieur·e DevOps pour conteneurs de Travaux Pratiques en informatique/réseaux

MAJ : nous avons trouvé le candidat. Le poste n’est plus disponible.

Nous recrutons un·e ingénieur·e en informatique pour travailler à l’application des concepts et technologies DevOps (conteneurs Docker, Git, Linux, libre, …) pour la mise au point et l’hébergement de dispositifs de Travaux Pratiques virtualisés, qui seront utilisés pour des enseignements d’informatique et de réseaux, sur un CDD de 1 an, à Télécom SudParis, à Évry (91).

Pour en savoir plus, voir le descriptif du poste que j’ai mis en ligne.

A review of Virtual Labs virtualization solutions for MOOCs

I’ve just uploaded a new memo A review of Virtual Labs virtualization solutions for MOOCs in the form of a page on my blog, before I eventually publish something more elaborated (and valuated by peer review).

The subtitle is “From Virtual Machines running locally or on IaaS, to containers on a PaaS, up to hypothetical ports of tools to WebAssembly for serverless execution in the Web browser”

Excerpt from the intro :

In this memo, we try to draw an overview of some benefits and concerns with existing approaches at using virtualization techniques for running Virtual Labs, as distributions of tools made available for distant learners.

We describe 3 main technical architectures: (1) running Virtual Machine images locally on a virtual machine manager, or (2) displaying the remote execution of similar virtual machines on a IaaS cloud, and (3) the potential of connecting to the remote execution of minimized containers on a remote PaaS cloud.

We then elaborate on some perspectives for locally running ports of applications to the WebAssembly virtual machine of the modern Web browsers.

I hope this will be of some interest for some.

Continue reading “A review of Virtual Labs virtualization solutions for MOOCs”

Deploying parallel Eclipse installations for teaching labs

I’ve worked on documenting and automating the deployment of Eclipse installations for several teaching labs of Telecom SudParis.

The recently introduced Eclipse Installer (Oomph) allows to install several parallel Eclipse installations containing diverse versions of Eclipse and bundles, so that each specific installation only contains a limited set of features, and that common plugins are pooled in a shared space.

This allows to deploy different Eclipse installations for different course labs, containing only the needed features, and minimizing the disk space needed for the whole.
Previously, we installed pretty much everything in a single place (yum install eclipse*), which lead to providing students with all possible languages support and features, on every machines, by default.
One of the main expected benefits of the new approach is to minimize Eclipse startup times, but this should also help avoid conflicting plugins.
If the experiment proves useful, we’ll then have one Eclipse installation for each needing computer science lab, all under different subdirs of /opt/eclipse/. For instance students registered in CSC4101 will start Eclipse by executing /opt/eclipse/CSC4101/eclipse/eclipse, giving them features for PHP and Symfony development (resp /opt/eclipse/CSC4102/eclipse/eclipse for CSC4102, for Java + Maven, etc.).

I’ve made available a document which explains the process, which was originally documented using org-mode’s babel feature which allows to write “litterate devops” documents containing executable instructions. I’ve used a Vagrant + Virtualbox setup to create the installation inside a Fedora VM, which mimics the target system for our lab machines.

The git repo of the corresponding project should be accessible for anyone interested.