A browser-based, cloud-hosted Open edX development environment
For the last three Open edX conferences, it’s been a goal of mine to deliver Open edX training using Docker-based training environments, also called cloud-based labs, virtual IT labs or practice labs. Imagine doing Open edX development — without having to install anything on your laptop, other than a web browser!?
Wondering why providing labs to your learners, especially for technical subjects, is so important? Read our blog post on introducing personalized learning labs which discusses the importance of learning-by-doing, project-based learning, and the challenges of delivering labs at scale.
Each year, I would get excited about offering a workshop at the Open edX conference that provided every student with an Open edX development environment in the cloud, but there were always too many hurdles to overcome, such as getting Open edX, code editor and terminal all working in the same Docker image. So this goal was not met.
But this year, I submitted a workshop proposal, “Getting Started with Open edX Development,” to the Open edX conference as a forcing function, and told myself that if it got accepted, I would finally get the Docker-based training environments working!
I’m happy to say that workshop was accepted, and the goal was finally achieved! Thanks to some incredible work by one of our engineers, Filip Jukic (who based his work off Regis Behmo’s openedx-docker project), we were able to put together a single Docker image containing not only Open edX itself, but a web-based code editor and terminal, so the entire development environment is self-contained.
This is a two part blog post series: this first post describes how the lab environment is put together, and the second post describes how the workshop presentation slides were put together using Markdown, RevealJS and Github Pages.
How to Create the Lab Environment in 4 Steps
Preparing for this “Getting Started with Open edX Development” workshop has been a fulfilling learning experience for me, and has sparked some new ideas about improving the way we do technical training. It has demonstrated the power of augmenting the traditional instructor-led classroom way of teaching with online assessments and guided lab exercises. And it gave me a chance to eat my own dogfood!
Here is the complete workflow from start to finish from the student’s perspective.
The lab environment depends on 4 distinct components:
- Open edX course
- Launch Container XBlock
- Appsembler Virtual Labs
- The Docker image
1. The Open edX Course
There is an Open edX course from which the labs are launched. Although Open edX is not a requirement, embedding the labs inside a course provides a framework in which we can deliver contextual material around the labs. We can use Open edX to build out a self-paced course, or simply to provide complementary materials for an instructor-led course.
When the student clicks on this button, they get a lab environment provisioned for them in about 10 seconds. I repeat – a complete Open edX development environment in ten seconds! (try doing that using DevStack on your laptop which takes an hour or more, depending on the speed of your computer) ?
When the student clicks that button, they will see the following message:
Clicking on the first URL will open in a new tab, the web-based development environment, which looks like this:
2. The Launch Container XBlock
So where did that launch button come from? The Launch Container XBlock is what we use to seamlessly embed the labs in the course without requiring the student to register and login to yet another service. By virtue of logging into Open edX, these credentials are used to launch the labs.
To add the lab to the course, all the course author needs to know are these 3 bits of information: name of the project (lab), friendly name, and the unique project token string. No Docker knowledge necessary!
3. Virtual Labs
So what happens behind the scenes when we click that button? Appsembler’s Virtual Labs is the magic that makes all of this work seamlessly. Our virtual labs solution provisions a container on-demand from the pre-built Docker image.
By on-demand, I mean that when the student clicks on the “Launch Lab” button in the Open edX course, it talks to our virtual labs service API, and immediately spins up a container from the snapshotted image. Again, this entire process takes only 10 seconds from when the student clicks on the button until when they get their lab environment ready for use.
What kind of software can run inside a virtual lab? Really anything that runs on Linux: Jupyter Notebooks, RStudio, OpenRefine, NodeJS apps, Ruby apps, Django apps, etc. If a software application as complex as Open edX can run, then anything is possible, right?
4. The Docker Image
How did this Docker image get created? The Docker image is built locally using the Dockerfile in this Github repository. Once it’s been built, then it’s pushed to Docker Hub.
The image can then be pulled down from Docker Hub into our virtual labs service after which it can be made available for student use, and embedded in edX courses using the Launch Container XBlock.
There are a few more steps with the virtual labs service to make the image usable, mostly around setting up exposed ports and setting the duration that the container should run, and actually embedding them.
Coding in the cloud!
So what makes this Docker image so special? Well, in addition to running Open edX and all of its dependencies, there are two other services running in the container.
- Orion (web-based code editor)
- GoTTY (web-based terminal)
You can think of Orion as a code editor that runs in the browser. It might not be as full-featured as a full-blown desktop IDE (integrated development environment), but it provides the basic features you’d expect from a code editor and it gets the job done.
Similarly, GoTTY is a web-based terminal that provides a Linux shell in which you can interact with the OS and run commands. Instead of having to SSH into a VM (requiring the student to install something like PuTTY if they’re on Windows), we just embed the terminal right in the browser and avoid all the complexity of public/private keys, opening SSH ports, etc.
Here’s what the Orion (top half of screen) and GoTTY (bottom half of screen) development environment looks like.
Supervisor handles the starting of all these services running in the container, and makes it easy to start/stop/restart the Open edX services.
(For my future self: Supervisor provides a web-based process controller that can be exposed on port 9001. Provide this as an additional service to easily start/stop services from a web browser)
If you’re interested in learning more about using Docker to spin up Open edX environments for development or production purposes, and you’re attending the Open edX conference this week, we are organizing a Birds of a Feather session at 3:40pm tomorrow (5/31), and it’s also a topic during the Development Summit on Friday at 12:50-2:15pm (6/1).
If you’re interested in learning more about Appsembler’s Virtual Labs software, stop by our booth at the Open edX conference, where we can give you a hands-on demonstration. Or, if you can’t make it to the conference, we are hosting a webinar the week after the conference called “How to Deliver Hands-On Labs for Virtual Software Training.” Save your seat by registering here!