Docker in the Terminal Widget
Learn how Docker can be used in the Terminal widget.
The third major use-case of Docker is the functionality it provides in the Terminal widget. This is perhaps the most straightforward use-case and requires minimal setup.
The environment of your Docker image is automatically linked to any Terminal you use. There is no need to set up a new job, all you need is a working Dockerfile.
Objective
Using Docker, we want to provide a custom environment with which users can interact through a terminal. This is useful when you are teaching terminal commands/instructions.
The examples below will fully highlight the use of Docker in the Terminal widget.
Example 1 - Nano
Nano is a long-running text editor that can be opened inside the terminal. Suppose we want to give users the ability to access Nano in a Linux environment. To achieve this, we will create a Ubuntu container with Nano installed in it.
Dockerfile
The Dockerfile can be seen below:
FROM ubuntu:20.04RUN apt-get update &&\apt install nano
Upload the tarball so that the image can be built.
Now, if you create a Terminal, it will run in the Ubuntu environment we have specified above.
Start Script
In the Terminal widget’s Start Script, you can provide commands that should be executed before the user connects to the Terminal. For example, you may want to move into a specific directory or provide instructions.
In our case, we will display the version of Nano in our environment.
The Terminal below runs in our Docker container. Use nano
to open the Nano editor.
Conversely, we can put the nano
command in the Start Script so that users can go straight to the editor without having to manually open it:
Example 2 - MongoDB
Like the SPA widget, you can connect to a live server through the Terminal. Think of it as the terminal that appears in SPA when we have a live VM running.
In this example, we will connect to a MongoDB database using a Terminal. Keep in mind that we do not need any code or project files. We only have to install MongoDB in our Docker image and run the server.
Dockerfile
As always, the first step is to create the Dockerfile. For MongoDB we can follow the installation steps specified in its official documentation.
Here’s the Dockerfile:
FROM ubuntu:16.04# Installing gnupg2 and its required filesRUN apt-get update && apt-get install -y gnupg2# Adding the MongoDB public keyRUN apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv 9DA31620334BD75D9DCB49F368818C72E52529D4# Creating a list file for MongoDBRUN bash -c 'echo "deb http://repo.mongodb.org/apt/ubuntu xenial/mongodb-org/4.0 multiverse" > /etc/apt/sources.list.d/mongodb-org-4.0.list'# Reloading packagesRUN apt-get update# Installing all the MongoDB packagesRUN apt-get install -y mongodb-org=4.0.10 mongodb-org-server=4.0.10 mongodb-org-shell=4.0.10 mongodb-org-mongos=4.0.10 mongodb-org-tools=4.0.10 --allow-unauthenticated
- We use Ubuntu 16.04 as our base image. This is not the option we have, but it is stable with MongoDB.
- All the installation steps are put into
RUN
commands. Imagine that you are working on a Ubuntu machine and installing MongoDB. These are the exact same steps. - It’s a good practice to use a single
RUN
with all the commands chained together with&&
. We’ve used multipleRUN
s for the purpose of readability.
Start Script
If you want the user to run MongoDB manually, there’s no need for a Start Script. We have it installed in our environment, which is linked to the Terminal widget.
The terminal below exhibits this behaviour. First, create the /data/db
directory using the following command:
mkdir -p /data/db
Run mongod
to start MongoDB:
Alternatively, we can use the Start Script to run mongod
automatically.
Click Update to see the changes of the Start Script.
Here’s what our Terminal looks like now:
Things to remember
-
The Terminal widget is NOT persistent like a SPA live VM. Changes in one Terminal are not reflected throughout the course.
-
No Docker job is required in a Terminal. It only uses a Start Script.
-
Using a Terminal ends any server session that was running in a SPA live VM. The next time you run the SPA, the server will be restarted.