What is a container?
In transportation industry a shipping container is independent (to some extent), uniform, moveable construct that can hold and transport goods. They are independent since they can exist on their own (unless they need power for example). They have strong walls that keep the contents safe. Some transportation containers may need external support, for example for cooling. They are uniform since all containers have the same shape and size. There may be some different sizes and shapes, but there aren’t any arbitrary size and shape, since they need to fit together on a transport ship for example. And of course they are movable. And once you move them, the goods inside move too. If the container needs external power for example, you unplug it, move it, and then plug it in again.
In computer technology containers are a bit same as the shipping containers. They are independent (to some extent), uniform and movable. These containers can exist on their own (but of course only once we have the environment around it). You can install software and copy files in them, and the contents will follow the container. They are uniform so that when we are using a single containerization software, all the containers have the same common interfaces. These containers can also be moved from one host to another, and the contents move with them.
From now on when I mention “container”, I mean this computer technology one. Also all the following information is about Docker and Podman - two popular containerization solutions.
No really, what is a container?
One common misconception of containers is that they are just small virtual machines. Well, they kind of are, but also not really. A virtual machine virtualizes hardware and the operating environment. The operating system is real, but all the hardware drivers are for the virtual hardware.
Containers do not virtualize hardware. They only virtualize the operating environment. Containers use the host’s hardware through the host’s kernel. All containers share the host’s kernel, but they have their own file system.
Containers can be summarized like this. They have Shared kernel space, isolated user space.
I still don’t know what a container is
It’s a small machine with its own operating system inside your host machine (which can have different operating system). To broaden the scope, a container is a independent Linux machine that you can start and stop as you please. It may be a Linux box that you start only when you need to do something on bash for example. Or it may be a machine that is constantly on, receiving inputs and outputting results from/to an interface. It can also be a one shot environment for building software or implementing some other process, that just outputs the result to the host and is then shutdown and removed. Personally I have done all the above.
What’s so good about them?
One nice thing about containers is that they start up fast. Really fast. Think of a Virtual Machine running Ubuntu. How long do you think it takes to start up? Depending on the hardware of course, but I guess about a minute is not far off? A Ubuntu container starts in seconds or even under one second. You can start running bash commands immediately.
You can install what ever software you wish in them, using for example the operating system’s own package tools. You can do that once you have the container up and running, or better yet, you can make a recipe for your machine to reproduce it identically every time you want a fresh start. This recipe is called a Dockerfile. It is simply a file named Dockerfile, that you can put anywhere on your disk.
Example - run nginx in a container
A Dockerfile can look like this.
# Use Ubuntu as the base image
FROM ubuntu:latest
# Install Nginx
RUN apt-get update && apt-get install -y nginx
# Copy a custom Nginx configuration file
COPY nginx.conf /etc/nginx/nginx.conf
# Start Nginx service
CMD ["nginx", "-g", "daemon off;"]
This Dockerfile takes latest version of Ubuntu as the base operating system, retrieves updates from the package repository, installs Nginx and copies a pre-defined configuration file for it into machine we are building. Then we provide the command to run when our container starts. In this case it starts Nginx on the foreground.
Here’s a very simple nginx.conf file for this example (save it to the same directory as the Dockerfile):
worker_processes 1;
events {
worker_connections 1024;
}
http {
server {
listen 80;
server_name example.com;
location / {
root /var/www/html;
index index.html;
}
}
}
To build this Dockerfile into a useable form do the following:
docker build -t mynginx .
The result is something called an image. In the above command -t means tag. It is basically the name for the image. The single dot at the end tells docker where the Dockerfile is. Dot meaning the same folder we are in right now.
An image contains everything described in the Dockerfile, but is not yet a machine or container. You start containers from images. To start a container, run:
docker run mynginx
Nginx container starts, and it starts outputting directly to your terminal. But we don’t want that, we just want to start the container and then do something else with out terminal. This can be done like this:
docker run -d mynginx
Now the container starts in daemon mode (runs in the background). To control the container, for example to stop it, we can use more docker commands. First we need to know what the name of our container is:
docker container ls
This outputs all running containers. Docker gave our container a generated name, since we did not provide one ourselves.
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
7a6be607e6d3 mynginx "nginx…" 10 seconds ago Up 9 seconds cozy_babbage
We can also see that there are no port forwarded out of the container, so let’s stop the container, and start it again with more parameters. Note the name of the container - in this example it is cozy_babbage. So we’ll use that with the stop command. You could also use container ID.
docker stop cozy_babbage
docker run -d -p 80:80 --name nginx mynginx
Now the HTTP port is published and forwarded correctly, and our container has the name we gave it.
CONTAINER ID ... PORTS NAMES
cdded2e42a2a ... 0.0.0.0:80->80/tcp nginx
To see the container in action, open web browser and go to address localhost. You don’t need to define the port, because 80 is the default. You will see the nginx welcome page, as seen below.
What’s next
This was an introduction to containers and Docker in particular. There’s a lot more you can do with containers, and the upcoming parts of this series will go in to detail how to do advanced stuff with Docker and/or Podman. These include defining your run commands in a more convenient way, and starting multiple containers at once. There’s even a way to handle service passwords in a secure way. You will also learn about Docker vs Podman and containers in Windows.
Note that the future parts are for paid subscriptions only.
The Quest continues…