Understanding the basics of Virtual Labs

Virtual Labs (sometimes referred to as AVL) is a powerful tool which allows you to create sophisticated software environments with the click of a button. But what does it all mean? In this article we'll look at the very basics of terminology we use in order to better understand just what's going on, and how we get from an image to a working software lab environment.

Basic elements of Virtual Labs

Virtual Labs uses a few main pieces to form a functional lab setup, including "images", "containers", "projects", and "events", as well as the Container Launcher XBlock.

Images

The image is a snapshot of a piece of software in a specific state, using a piece of technology called Docker. It's like a frozen moment in time, like a save file that you'd find in any piece of software except so much more, because it doesn't just save the state, it saves the software itself. They are the blueprint that defines what the software will look like once it's running. You can also have what's known as a paired image, which will allow you to connect two images together, such as a piece of software that displays information that you put into another, like a chat client or a web-based development environment with a preview. Images can be imported from two places, the Google Container Registry or DockerHub.

The Container Registry is a private instance of the software that can store Docker images before importing them into the Virtual Labs dashboard; you can think of this as a remote storage location. Read our guide on Importing a Virtual Labs image from the Container Registry in order to make use of it.

Docker Hub is a registry that hosts thousands of user-created images which can be used for Virtual Labs. This includes free images found on the Docker Store, their new marketplace, so long as they are for Linux-based software packages. For information on how to use on of these images, see our article on Importing a Virtual Labs image from Docker Hub.

If the piece of software you need does not currently have a Docker image, you'll need to create your own Docker image containing the software. Some Appsembler customers have developers on staff who create images, and we can offer consulting services to create those images or coach your team through the process (please note, however, that the availability of this service will vary depending on workload). You can take a look at Docker's "Getting Started" guide, or just send us a note indicating your interest in Virtual Labs, and we'll help you understand how to move forward.

Containers

A container is how we restore the image to life, it's the machine that runs the software from its frozen state, it's the building created from the blueprints of the image. We've got two types of containers - Admin containers and Student containers, but they're essentially just the same thing given different names and purposes. In some cases, you'll combine two images together to create paired images. You'll need a shared volume container to work with a paired image. Fortunately we've got an article on doing just that - Creating shared volume containers in Virtual Labs - but it's a good idea to understand the basics first!

Admin containers

Admin containers are used to manipulate an image into the state you want it in for your students to use it. This means for example if you're running a software lab on using a piece of database software, you might take the image of that database software and manipulate it slightly to have some pre-filled data by using an admin container before you give it to your students.

Admin containers are typically the first thing you create once your image is ready for use and pulled into Virtual Labs. Learners never see them, or at least that's the theory! They're purely for your own use so that you don't have to go through the full process of embedding a lab into Open edX in order to check your image is actually working.

The names of Admin containers appear on a green background in the Virtual Labs dashboard.

Student (or User) containers

This is where the learning happens. These are the containers that you give to your students to do whatever they want with your software image. It's like having them use their own personal machines, except without all the headaches of "I've forgotten my password","I was supposed to register?", "This computer doesn't have ___ installed", "I can't get it to run" or any of those other hassles that anyone who has done software training is all too familiar with, which get in the way of the actual training.

Student containers are given a time limit in order to stop them from running forever and overloading the servers. This doesn't mean that everything is lost once that time limit expires, but it does mean that if they're required past their expiry time, we'll need to manually wake them up again.

You may see student containers referred to in some places as User containers. It's fine, they're the same thing really. Their names appear on a purple background on the Virtual Labs dashboard.

Projects

A project is simply a way to coordinate and manage your student containers; you'll choose an image, set a limit on the number of students, and the container duration. The project is where you say "I'm going to have 100 student containers that will run for a week". It puts bounds on the session in order to stop things getting out of hand. This can scale well, but if you're ever planning a project with large numbers of students please let us know about it in advance so we can make sure it runs smoothly! Please also never just set this arbitrarily high to avoid having to think about limits. A good rule of thumb is allow as many containers as you think you'll have students, and then add ~25% on top.

Projects are the primary way that most will use Virtual Labs, in that we use a project to connect to the container launcher XBlock. For a guide on how to create your first project, check out our article on Creating a Virtual Labs project.

The names of Projects appear on an Orange background in the Virtual Labs dashboard.

Events

Events are the other way of coordinating student containers. As the name would suggest, these are good for events, where people turn up on the day and activate containers to work on for a limited period of time. This is good for something like an in-person training event or a conference demo area, over projects which are typically used asynchronously in a distributed context.

If you would like to arrange one of these events, just talk to your Customer Success Manager or contact support. Note that Live Events is included in Virtual Labs Pro, and can be purchased for other tiers as an add-on.

The Container Launcher XBlock

The Container Launcher XBlock is how we connect a project to Open edX, allowing students in Open edX to launch their student container. To do this:

Follow the steps in our article Enabling XBlocks in Open edX to enable XBlocks on your course, as well as add this specific one.

Hint: The line of text to add for the Container Launcher XBlock is:
```
"launchcontainer"
```
Then follow our guide to Adding a Virtual Labs project to your Open edX course to get your lab inserted into your course.

Example

To better explain the process of using Virtual Labs and how all the different moving parts intersect, the following example is of a typical use-case for Virtual Labs.

Ana of Delta Rook Limited is a subject-matter expert seeking to train her clients in the use of their new enterprise customer success management software, Customer Farm, using Virtual Labs and an Open edX course. Customer Farm has already got a usable docker image, which is convenient, so Ana just has to follow the steps as outlined in the help article Creating a Virtual Labs project, which you should check out if you're interested in the detail of exactly how to accomplish each step.

Ana first creates an Admin container using her blank Customer Farm image, and opens it up. She uses this virtual copy of Customer Farm to set up a range of dummy customer accounts for training purposes.
Once she's done, she converts the Admin Container back into an image. This new image has all the changes Ana made to the original in her admin container, so any fresh containers that use it will essentially pick up where she left off.
She then gives it a try as a student by creating a new admin container to ensure that everything is exactly as she wants it to be. If there are any further changes to be made, she'd need to change the image again. Fortunately, everything's fine, and now whenever she starts a container it launched Customer Farm with all her dummy customers ready for use.
She then creates a Project using this new, amended image. Ana stipulates that because she has a class of 30 using the image, they'll need a maximum of 40 containers, just to be sure. Each image will only be needed once, but she sets an expiry of 14 days, just in case anyone wants to revisit their work shortly after the session.
She embeds the Container Launcher XBlock in her Open edX course where she wants the project to occur.
When her course is live, Ana's students are able to start up their own copies of Customer Farm and do whatever they like with the dummy customer accounts without affecting each other. If they make a huge mistake, they can be reset back to their initial state.