Mixing NRELab’s Antidote and Eclipse Che on the same k8s cluster

You may have heard of my search for Cloud solutions to run labs in an academic context, with a focus on free an open source solutions . You may read previous installments of this blog, or for a shorter, check the presentation I’ve recorded last week.

I’ve become quite interested, in the latest month, in 2 projects: NRELab’s Antidote and  Eclipse Che.

Antidote is the software that powers NRELabs, a labs platform for learning network automation, which runs on top of Kubernetes (k8s). The interesting thing is that for each learner, there can be a dedicated k8s namespace with multiple virtual nodes running on a separate network. This can be used in the context of virtual classes/labs where our students will perform network labs in parallel on the same cluster.

Eclipse Che powers Eclipse “on the Cloud”, making available software development environments, for developers, on a Kubernetes Cloud. Developers typically work from a Web page instead of installing local development tools.

Both projects seem quite complementary. For one, we both teach networks and software developments. So that would naturally appeal for many professors.

Furthermore, Eclipse Che provides a few features that Antidote is lacking : authenticating users (with keycloak), and persisting their work in workspaces, between work sessions. Typically what we need in our academic context where students will work on the same labs during scheduled classes, week after week, during or off-hours.

Thus it would be great to have more integration between the 2 environments.

I intend to work on that front, but that takes time, as running stuff on Kubernetes isn’t exactly trivial, at least when you’re like me and want to use a “vanilla” kubernetes.

I’ve mainly relied on running k8s inside VMs using Vagrant and/or minikube so far.

A first milestone I’ve achieved is making sure that Antidote and Eclipse Che aren’t incompatible. Antidote’s “selfmedicate” script was actually running inside a Vagrant VM, where I had difficulties installing Eclipse Che (probably because of old software, or particular networking setup details). I’ve overcome this hurdle, as I’m now able to install both environments on a single Kubernetes VM (using my own Vagrant setup).

Running Eclipse Che (alongsite Antidote) on a k8s Vagrant VM.

This proves only that there’s no show stopper there, but a lot of work remains.

Stay tuned.

Update: I’ve finally managed to get it to work on the antidote-selfmedicate base too. See my branch at: https://github.com/olberger/antidote-selfmedicate/tree/che

Testing KubeVirt + Kata-Containers for running VMs inside Kubernetes in a Vagrant + qemu VM (updated)

I wanted to be able to test deployment of VMs inside a Kubernetes cluster with KubeVirt (and maybe Kata-Containers too), using a VM-based testbed. An additional requirement was trying to get a similar setup script that could be applied to a regular physical host, should the tests be conclusive.

I’ve adapted an existing installation procedure for installation on Vagrant Ubuntu VMs, and the result is there:
https://github.com/olberger/vagrant-k8s-kubevirt-katacontainers

I runs a Vagrant VM with libvirt+qemu/kvm, installed with Ubuntu 18.04, and provisions a Kubernetes cluster using kubeadm (no longer minikube, unlike what was done in the original repo I’ve forked from).

Inside the cluster, containers are run with CRI-O, which seems to be compatible with KubeVirt. Packages are “official” k8s packages (except for CRI-O and KubeVirt).

I hope it’ll work for you too, provided that you can run nested virtualization.

Next steps will be trying I’ve also added Kata-Containers to the cluster. It seems that kata-containers and KubeVirt are compatible (all running with libvirt below).

Here’s a screencast :

 

Updated: I’ve now added Kata-Containers deployment to the provisioning scripts. Also, it runs 18.04 now (LTS too, but more recent than 16.04). Oh, and the scripts seem to be useable outside Vagrant, on a regular Ubuntu server too.

Next steps, testing various workloads on the cluster for virtual labs deployments.

New short paper : “Designing a virtual laboratory for a relational database MOOC” with Vagrant, Debian, etc.

Here’s a short preview of our latest accepted paper (to appear at CSEDU 2015), about the construction of VMs for the Relational Database MOOC using Vagrant, Debian, PostgreSQL (previous post), etc. :

Designing a virtual laboratory for a relational database MOOC

Olivier Berger, J Paul Gibson, Claire Lecocq and Christian Bac

Keywords: Remote Learning, Virtualization, Open Education Resources, MOOC, Vagrant

Abstract: Technical advances in machine and system virtualization are creating opportunities for remote learning to provide significantly better support for active education approaches. Students now, in general, have personal computers that are powerful enough to support virtualization of operating systems and networks. As a conse- quence, it is now possible to provide remote learners with a common, standard, virtual laboratory and learning environment, independent of the different types of physical machines on which they work. This greatly enhances the opportunity for producing re-usable teaching materials that are actually re-used. However, configuring and installing such virtual laboratories is technically challenging for teachers and students. We report on our experience of building a virtual machine (VM) laboratory for a MOOC on relational databases. The architecture of our virtual machine is described in detail, and we evaluate the benefits of using the Vagrant tool for building and delivering the VM.

TOC :

  • Introduction
    • A brief history of distance learning
    • Virtualization : the challenges
    • The design problem
  • The virtualization requirements
    • Scenario-based requirements
    • Related work on requirements
    • Scalability of existing approaches
  • The MOOC laboratory
    • Exercises and lab tools
    • From requirements to design
  • Making the VM as a Vagrant box
    • Portability issues
    • Delivery through Internet
    • Security
    • Availability of the box sources
  • Validation
    • Reliability Issues with VirtualBox
    • Student feedback and evaluation
  • Future work
    • Laboratory monitoring
    • More modular VMs
  • Conclusions

Bibliography

  • Alario-Hoyos et al., 2014
    Alario-Hoyos, C., Pérez-Sanagustın, M., Kloos, C. D., and Muñoz Merino, P. J. (2014).
    Recommendations for the design and deployment of MOOCs: Insights about the MOOC digital education of the future deployed in MiríadaX.
    In Proceedings of the Second International Conference on Technological Ecosystems for Enhancing Multiculturality, TEEM ’14, pages 403-408, New York, NY, USA. ACM.
  • Armbrust et al., 2010
    Armbrust, M., Fox, A., Griffith, R., Joseph, A. D., Katz, R., Konwinski, A., Lee, G., Patterson, D., Rabkin, A., Stoica, I., and Zaharia, M. (2010).
    A view of cloud computing.
    Commun. ACM, 53:50-58.
  • Billingsley and Steel, 2014
    Billingsley, W. and Steel, J. R. (2014).
    Towards a supercollaborative software engineering MOOC.
    In Companion Proceedings of the 36th International Conference on Software Engineering, pages 283-286. ACM.
  • Brown and Duguid, 1996
    Brown, J. S. and Duguid, P. (1996).
    Universities in the digital age.
    Change: The Magazine of Higher Learning, 28(4):11-19.
  • Bullers et al., 2006
    Bullers, Jr., W. I., Burd, S., and Seazzu, A. F. (2006).
    Virtual machines – an idea whose time has returned: Application to network, security, and database courses.
    SIGCSE Bull., 38(1):102-106.
  • Chen and Noble, 2001
    Chen, P. M. and Noble, B. D. (2001).
    When virtual is better than real [operating system relocation to virtual machines].
    In Hot Topics in Operating Systems, 2001. Proceedings of the Eighth Workshop on, pages 133-138. IEEE.
  • Cooper, 2005
    Cooper, M. (2005).
    Remote laboratories in teaching and learning-issues impinging on widespread adoption in science and engineering education.
    International Journal of Online Engineering (iJOE), 1(1).
  • Cormier, 2014
    Cormier, D. (2014).
    Rhizo14-the MOOC that community built.
    INNOQUAL-International Journal for Innovation and Quality in Learning, 2(3).
  • Dougiamas and Taylor, 2003
    Dougiamas, M. and Taylor, P. (2003).
    Moodle: Using learning communities to create an open source course management system.
    In World conference on educational multimedia, hypermedia and telecommunications, pages 171-178.
  • Gomes and Bogosyan, 2009
    Gomes, L. and Bogosyan, S. (2009).
    Current trends in remote laboratories.
    Industrial Electronics, IEEE Transactions on, 56(12):4744-4756.
  • Hashimoto, 2013
    Hashimoto, M. (2013).
    Vagrant: Up and Running.
    O’Reilly Media, Inc.
  • Jones and Winne, 2012
    Jones, M. and Winne, P. H. (2012).
    Adaptive Learning Environments: Foundations and Frontiers.
    Springer Publishing Company, Incorporated, 1st edition.
  • Lowe, 2014
    Lowe, D. (2014).
    MOOLs: Massive open online laboratories: An analysis of scale and feasibility.
    In Remote Engineering and Virtual Instrumentation (REV), 2014 11th International Conference on, pages 1-6. IEEE.
  • Ma and Nickerson, 2006
    Ma, J. and Nickerson, J. V. (2006).
    Hands-on, simulated, and remote laboratories: A comparative literature review.
    ACM Computing Surveys (CSUR), 38(3):7.
  • Pearson, 2013
    Pearson, S. (2013).
    Privacy, security and trust in cloud computing.
    In Privacy and Security for Cloud Computing, pages 3-42. Springer.
  • Prince, 2004
    Prince, M. (2004).
    Does active learning work? A review of the research.
    Journal of engineering education, 93(3):223-231.
  • Romero-Zaldivar et al., 2012
    Romero-Zaldivar, V.-A., Pardo, A., Burgos, D., and Delgado Kloos, C. (2012).
    Monitoring student progress using virtual appliances: A case study.
    Computers & Education, 58(4):1058-1067.
  • Sumner, 2000
    Sumner, J. (2000).
    Serving the system: A critical history of distance education.
    Open learning, 15(3):267-285.
  • Watson, 2008
    Watson, J. (2008).
    Virtualbox: Bits and bytes masquerading as machines.
    Linux J., 2008(166).
  • Winckles et al., 2011
    Winckles, A., Spasova, K., and Rowsell, T. (2011).
    Remote laboratories and reusable learning objects in a distance learning context.
    Networks, 14:43-55.
  • Yeung et al., 2010
    Yeung, H., Lowe, D. B., and Murray, S. (2010).
    Interoperability of remote laboratories systems.
    iJOE, 6(S1):71-80.

Configuring the start of multiple docker container with Vagrant in a portable manner

I’ve mentioned earlier the work that our students did on migrating part of the elements of the Database MOOC lab VM to docker.

While docker seems quite cool, let’s face it, participants to the MOOCs aren’t all using Linux where docker can be available directly. Hence the need to use boot2docker, for instance on Windows.

Then we’re back quite close to the architecture of the Vagrang VM, which relies too on a VirtualBox VM to run a Linux machine (boot2docker does exactly that with a minimal Linux which runs docker).

If VirtualBox is to be kept around, then why not stick to Vagrant also, as it offers a docker provider. This docker provider for Vagrant helps configure basic parameters of docker containers in a Vagrantfile, and basically uses the vagrant up command instead of using docker build + docker run. If on Linux, it only triggers docker, and if not, then it’ll start boot2docker (or any other Linux box) in between.

This somehow offers a unified invocation command, which renders a bit more portable the documentation.

Now, there are some tricks when using this docker provider, in particular for debugging what’s happening inside the VM.

One nice feature is that you can debug on Linux what is to be executed on Windows, by explicitely requiring the start of the intermediary boot2docker VM even if it’s not really needed.

By using a custom secondary Vagrantfile for that VM, it is possible to tune some parameters of that VM (like its graphic memory to allow to start it with a GUI allowing to connect — another alternative is to “ssh -p 2222 docker@localhost” once you know that its password is ‘tcuser’).

I’ve committed an example of such a setup in the moocbdvm project’s Git, which duplicates the docker provisioning files that our students had already published in the dedicated GitHub repo.

Here’s an interesting reference post about Vagrant + docker and multiple containers, btw.

Student project contributions on using docker to build headless virtualised labs for MOOC participants

After having used Vagrant to create Virtual Machines (VMs) ready made for MOOC participants, I’ve been investigating the use of docker for a similar need.

In order to move on, I’ve applied a clever trick by proposing a project to students of ours (3rd year engineering school end-of-classes project of the ASR major).

The project was addressing several needs :

  • a functional need: being able to monitor what happens inside the VMs run on the participant’s side, so that MOOC labs aren’t performed in a black box;
  • a non functional need: investigate the potential benefits of docker, compared to Vagrant.

The students (François Monniot and Alexis Mousset) have worked very well, and we have a few apps in the result, that allow us to assemble a POC in order to complete our evaluation.

In following posts, I will describe some of these components and will present some ideas and maybe results on the technology’s potential. The impatient reader may directly browse their code on GitHub, starting from the dedicated site.