TDM 40200: Project 12 — 2023

In this project, we will begin learning about the various docker commands. In addition, we will learn about some of the Dockerfile commands, and even build and use some simple containers!

Like the last project, we will be working in a virtual machine (VM). By using a VM on Anvil, we are able to ensure that everyone has the proper permissions in order to run each and every one of the necessary commands to build and run Docker images. There are 3 main steps needed in order to both get a VM up and running on Anvil resources, and connect and get a shell on the VM from Anvil.

For this question, just include a screenshot of your terminal after you have successfully connect to the VM.

Whoa, you may have noticed things look a little bit different from the previous project — that’s okay! We made a few modifications that will be useful to you during this project. Let’s test out the most useful new feature.

In your terminal in the VM, list all of the files as follows:

Okay, nothing special yet. That is to be expected. Now, in the same terminal session, type the letter "l" and immediately pause for a second. You will quickly notice that the terminal shows "s -la" in light grey text after your initially typed "l". We’ve installed a program that remembers your shell history and does its best to predict what you will type based on your previous commands. If you press the right arrow on your keyboard, the rest of the "ls -la" command will be typed out fully. This is an extrememly useful feature, especially as we are juggling various docker commands that can be long and confusing. For example, you can type "docker" and start typing the up arrow on your keyboard and this tool will cycle through all of your previous commands that started with "docker".

Okay, try running the command docker and docker ps and docker images. Follow these command up with "docker" followed by you pressing the up arrow on your keyboard to cycle through your previous commands. Once you are comfortable with this functionality, go ahead and take a screenshot of some of your outputs from these docker commands and include it in your submission.

Next, let’s build a barebones Docker image using the docker command and a Dockerfile.

A Dockerfile is a text file that contains a set of instructions for building a Docker image.

The docker command is a command line interface (CLI) that allows you to interact with Docker.

A Docker image is a essentially a zipped up tarball of a file system that contains all of the files and dependencies needed to run a program. You can think of it as the ubuntu filesystem that you extracted and used with chroot in the previous project.

For a very barebones image, your Dockerfile will only need to contain two lines. The first line will be a FROM command. This command will tell Docker what base image to build on top of. It is very common to choose a barebones operating system image like alpine or ubuntu as the base image.

The second line will be a CMD command. This command will tell Docker what command to run when a container is started from the image.

Use your favorite command line text editor (the image has nano, vim, and emacs installed already) to create a new file called Dockerfile in your home directory. Replace "OS" with the base image you want to use. For this project, we will use an ubuntu image from here — specifically the newest stable version of ubuntu, which is currently 22.04 — ubuntu:22.04. Here, ubuntu is the repository namespace and 22.04 is the tag specifying a version of the image. While _technically ubuntu could put all sorts of different containers in the ubuntu namespace under different tags, it is customary to use the tag to specify the version of the image.

Next, replace "command" with the command you want to run when a container is started from the image. For now, let’s use the most basic shell that is available on many linux operating systems, /bin/sh. If we had multiple arguments to pass to the command, we would add them to the list of arguments after the first argument. For example, if we wanted to run the command echo "hello world", we would use the following CMD ["echo", "'hello world'"] command.

Once complete, save the file and close the text editor. Now, its time to build our image! Run the following command to build the image:

Once the image is built, you can check to see that it is there by running the following command:

You will notice that there are 2 images available: ubuntu:22.04 and myfirstimage. The ubuntu:22.04 image is the base image we used to build our image on top of. The myfirstimage image is the image we just built. Very cool!

Now, let’s run our image! Run the following command to run our image:

Congratulations! You now have a shell (/bin/sh) running in a container!

Okay, now that you have a shell running in the container, let’s take a minute to clarify the last line of our Dockerfile.

There are two important commands that we need to delineate: CMD and ENTRYPOINT. It is kind of a mess, but it is important to take the time to understand the differences — otherwise it will be more difficult to debug your containers in the future.

The following Dockerfile has a single CMD line. In a Dockerfile, there can only be a single CMD line — if there is more, only the last CMD line will be respected.

This CMD is in exec form. This means that:

Build the image and run it. What was your output?

Now, run it and pass in a different command. What was your output?

Modify the Dockerfile and rebuild your image.

What happens? Instead of "cwd: /" you get "cwd: $PWD". This is because variable substitution doesn’t occur since a shell isn’t processing the commands. We can, however, use the shell form. This means that:

You once again get "cwd: /" since the sh shell is performing the variable substitution! Behind the scenes it is really running /bin/sh -c "echo cwd: $PWD".

Finally, there is another series of scenarios that we can explore that have to do with our ENTRYPOINT. The first being — what happens if we are not using the shell form of CMD and our first argument is not and executable like echo or /bin/sh? Let’s find out!

What happens? It fails! Docker doesn’t understand what to do with that, since it isn’t anything executable. In these scenarios, you need to specify an ENTRYPOINT.

It works just like when we did the following!

Or does it? In this case, once again there is no variable substitution because a shell is not processing the commands. However, you will find things are different than before. Before, you could run the following:

The result would be that the contents of the CMD, CMD ["echo", "cwd: $PWD"], would be effectively replaced and a shell would be spawned. However, try running it with the following Dockerfile.

What happens? It does not do what one might expect! It simply prints out "/bin/sh". Why? Well, the arguments after docker run do not replace our ENTRYPOINT, just our CMD. So, in this case, we essentially ran echo /bin/sh! In fact, if you gave multiple parameters to ENTRYPOINT — none of them would be replaced.

In this example, ENTRYPOINT is in exec form — it has the square brackets. ENTRYPOINT also has a shell form.

Here, what is actually being run is /bin/sh -c "echo $PWD". When ENTRYPOINT is run using shell form, CMD is completely ignored, and, because CMD is completely ignored, the /bin/sh argument passed as a part of the docker run command is also ignored. A side effect is that that signals are not passed properly using this method, this will effect stopping the container and the first process running in the container.

Hopefully this gives you a taste of the myriad of capabilities that CMD and ENTRYPOINT provide. It is a mess, however, Docker does provide some "best practices". In a nutshell:

For this question, submit the text for a Dockerfile that would result in the following output when run.

Okay, we are making some progress, but the complexity of ENTRYPOINT and CMD are certainly enough to slow us down a bit. Rebuild myfirstimage with the following Dockerfile.

Once you are in a shell in your container, go ahead and run the following to create a file called "imhere" in the /root/ directory.

Verify that the file exists:

Great! Now go ahead and exit the container. Now, rerun the container, and verify that the file is still there.

It is no longer there! The container executes our shell, we run some commands, and as soon as we exit the container our changes are all gone! Containers are ephemeral — any changes you make will only survive for the duration that the process running the container exists. When we exit the container the process is no longer running and our changes disappear.

There are a couple of ways around this. One is to use a VOLUME to bind a location outside of our container somewhere inside our container. We will play with this later on. Another way that is super straightforward is to not let our process exit! We can do this by using the -d flag to run the container in the background. Give it a try!

Whoa, this is way different — there is a long string of characters that are printed, and then we have our regular shell prompt. What is going on?

The long string of characters is the container ID. This is a unique identifier for the container. We can use this to interact with the container.

Okay, great, but do we have to remember that? No! We don’t! You can see all running containers using the following command.

Here, we have an abbreviated container id as well as the name of the image that was used to create the container. Okay, now how do we interact with the container? We can use the docker exec command. This command allows us to execute a command inside of a running container. In this case, we want a shell, so let’s give it a try.

Great! Let’s repeat the previous steps to create the file in /root/ called "imhere".

Now, let’s exit the container. Is the container still running? Use docker ps to find out. Okay, great! It is still running — that should mean that if we get another shell inside the container and look for the file, it should still be there. Let’s give it a try.

Indeed, it is! Excellent! While this is great, if, for some reason, the container restarted this file would once again disappear. If we really need some data to persist, we need to use a VOLUME, but we will mess around with this in a future project. What else can we do? What other commands are useful? Well, let’s make our running container stop.

After that, check on your container with docker ps — you’ll find it has stopped! Very cool.

Remember how earlier in the project we mentioned that Docker images are just layers of a read-only filesystem compressed into a zipped up tarball? Well, up until this point I haven’t seen any actual transferrable files, have you? With docker we have the ability to export them using the docker save command. Let’s do this.

The result is a tarball that you can transfer to any other system (at least, any with the same architecture) with Docker and use docker load to load it up.

For this question, just include a screenshot of the terminal contents that demonstrates that you were able to persist the "imhere" file after exiting the container.