When to Choose Linux-Based Containers for Your Lab and How to Get Started

Containers are a remarkably simple way to deploy and scale applications. Container management services, such as Docker and Kubernetes, have revolutionized the way applications are built, deployed and managed.

That makes containers a natural next step to extend Learn on Demand’s expansive ecosystem of lab platform choices in Lab on Demand.

A New Fabric Choice in Lab on Demand

Adding Linux-based containers to Lab on Demand means we now offer eight fabrics on which you can build your hands-on lab:

  1. VMware for virtual machines.
  2. Hyper-V for virtual machines.
  3. AWS EC2 for virtual machines.
  4. AWS Cloud Slice with CloudFormation templates.
  5. Azure IaaS for virtual machines.
  6. Azure Cloud Slice with ARM templates.
  7. Credential Pools with LCA for open web based labs.
  8. NEW – Docker Linux Containers

Docker containers allow lab authors to create environments that leverage any of the thousands of pre-built containers located on Docker Hub. Containers can be deployed as stand-alone lab environments or paired with virtual machines* and/or Cloud Slice to create dynamic, diverse, real-world environments.

The Docker fabric is fully supported by our authoring tool IDLx including replacement tokens that enable you to provide direct deployment scripts, interact with containers, expose and use container properties etc. plus activity-based assessments now interact with containers.

Advantages of Containers

Containers offer several distinct advantages when compared to virtual machines in hands-on labs.

  1. Startup time is near instantaneous.
  2. Since containers share the underlying operating system, containers consume far fewer resources.
  3. Containers can be stored and shared using a container repository, such as Docker Hub. Presently, public repositories are supported, and private repositories with access control are planned for a future update.
  4. You do not need to download and install software to create a lab. You can simply reference the container on a supported repository.
  5. Containers leverage our HTML-based console, and therefore do not have the same bandwidth or latency requirements as virtual machine-based labs, enabling them to be used in low bandwidth locations.

For a deeper understanding of how containers differ from virtual machines, check out Docker’s e-book, “Docker for the Virtualization Admin.”

Limitations of Containers

Containers are not a replacement for virtual machines. They address a distinct set of circumstances. If your lab meets the following characteristics, then a container-based lab might be a good choice:

  1. Your lab is based on Linux and uses a Linux console (not desktop).

    Examples of this include Kali Linux security labs or Ubuntu Linux administration training.
  2. Your lab contains a web app, which exposes endpoints as services.

    Examples of this include AI containers, such as the Azure Cognitive Services containers.

Windows containers are not supported at this time.

Container Scenarios

There are a few learning scenarios where containers are of particular use. These scenarios revolve around a few key characteristics:

  1. Linux environments in which the console is the only way you interact with Linux.This applies to many Linux administration topics, as well as many security topics. Scenarios include security tools training, Linux configuration and administration training, or installing and configuring services on Linux. A great example would be ethical hacking using Kali Linux containers.
  2. Applications and services as containers.Many applications now ship as containers and expose the configuration of the application over HTTPS using a web app of some sort. They may also expose API endpoints that let you use the services of the container. In this scenario, you would configure the container to expose the required ports, and then pair it with a virtual machine running development software, such as Visual Studio, or access the configuration tools directly.A great example of this scenario is the Microsoft Cognitive Services containers available on Docker Hub. These containers expose API and configuration endpoints over port 80.Another example of this is a lab on database development. Instead of deploying a full database server in a VM, your database server could be a container version of a database, such as microsoft.com/mssql/server, which contains SQL Server for Linux.

As we expand the Docker fabric with additional capabilities, many more deployment scenarios will surface.

Getting Started with Containers

To create a lab based on a container, you begin by leveraging the new Containers tile in Lab on Demand. You can search for existing container images or create a new container image.

When creating a new container image, browse Docker Hub and identify the container you wish to base your lab on. For example, Kali Linux as shown here.

To create the new container image, simply specify:

  • the container name
  • any additional scripts or commands you want to run
  • any service ports you want to expose, such as HTTP or HTTPS

Lab on Demand will do the rest.  See here.

When you create your lab profile, select Docker as the Virtualization, add your container, and you are done. See here.

Note the customizable replacement token alias value, as you can use this later to access properties of your container in lab instructions using IDLx replacement tokens.

Launch your lab and you will be instantly presented with your container terminal console, as seen below. This lab environment supports the same basic functions of connection management, geolocation, and save/resume, as virtual machine-based labs.

Open the IDLx Editor, and you can access replacement tokens that grant you access to your container’s properties, such as the public URL and port for any published ports. Note the token @lab.Container(kali-linux-docker).ExposedPortAddress(80), which in this example will resolve to tpadocker01.learnondemandsystems.com:49152. Lab on Demand will assign a publicly accessible, dynamic port to allow each student to have direct access to any published services on the containers they are using. See here.

These tokens allow powerful instructions that are fully integrated with the container deployment and enable you to provide direct deployment scripts, URLs and many other useful constructs.

Finally, activity-based assessments have been extended to interact with containers. In this example, I am scoring a container to determine if the currently logged-on user is Root. See here.

Authoring Container Images

Release 1 of the Docker fabric does not support directly authoring container images. To author a container image, use a platform such as Docker for Windows or Docker for Linux to create and save your container image. Then, simply upload that image to Docker Hub, and you can now add that image to Lab on Demand and create new lab instances from that image. Docker provides documentation on how to complete this process.

Just Released

Private networking between containers in a lab without needing web access.

Release 2

We are actively working on Release 2 for Docker fabric for Lab on Demand. Release 2 is planned to include:

  • Support for labs containing containers and virtual machines.
  • Support for saving and publishing container images.
  • Support for private container image repositories.

*Release 1 does not allow labs containing containers and virtual machines. This will be introduced in Release 2.