Docker Images Introduction

Docker Images Introduction

What is an Ubuntu Docker Container?

Ordinary software packages can often be installed in a variety of different types of environments that satisfy the given packaging system. However, these environments can be quite varied, such as including versions of language runtimes, system libraries, and other library dependencies that the software was not well tested with.

Docker containers address the inconsistencies that can arise in such a situation by encapsulating not only the software itself, but also much of the surrounding environment. Instead of installing and maintaining a collection of software packages, the user installs and maintains a single container. The user relies on the provider of the Docker container to perform the necessary software testing and maintenance updates. There is a rich ecosystem of Docker container providers thanks to how easy Docker makes it to create containers.

The “Open Container Initiative” (OCI) establishes standards for constructing Docker images that can be reliably installed across a variety of compliant host environments. Ubuntu’s implementation of OCI containers for Kubernetes is named “ROCKS”.

Ubuntu’s LTS Docker Image Portfolio provides OCI-compliant images that receive stable security updates and predictable software updates, thus reliably simplifying the maintenance of software containers.

Container Basics

Here’s a quick exploration of Ubuntu’s OCI Docker image. Spin up a container providing the Nginx software:

$ docker run -d --name nginx-container -e TZ=UTC -p 8080:80 ubuntu/nginx:1.18-20.04_beta

Unable to find image 'ubuntu/nginx:1.18-20.04_beta' locally
1.18-20.04_beta: Pulling from ubuntu/nginx
c1bf981888da: Pull complete
131ba4c4c06e: Pull complete
59fc0d1f2904: Pull complete
de1589e6a236: Pull complete
Digest: sha256:7f67198e894158efb3714f49e1818bff005518b9a8a2e923f19821200212efd2
Status: Downloaded newer image for ubuntu/nginx:1.18-20.04_beta
d6445f7ec1a53b7167eb2f724fab6c3cc21bd4100846bcb896b4b845fd08c457

This container, named nginx-container runs in an Ubuntu 20.04 LTS environment and listens for connections on local port 8080. Load the website up in your local web browser:

$ xdg-open http://localhost:8080

Welcome to nginx!

If you see this page, the nginx web server is successfully installed and working. Further configuration is required.

For online documentation and support please refer to nginx.org.
Commercial support is available at nginx.com.

Thank you for using nginx.

The container operates much like any other Ubuntu host. You can log into it as root via:

$ docker exec -it nginx-container /bin/bash

From here, you can examine logs or install packages from the archive normally. For example, if you’re attempting to debug network connections you might run:

root@abcd12345678:/# apt-get update && apt-get install -y iputils-ping net-tools
root@abcd12345678:/# ifconfig | grep inet
    inet 192.168.192.1  netmask 255.255.240.0  broadcast 192.168.207.255
    inet 127.0.0.1  netmask 255.0.0.0
root@abcd12345678:/# ping 192.168.192.2 -c1 | tail -n2
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.032/0.032/0.032/0.000 ms

Once you’re done exploring, shut the image down and delete it:

$ docker stop nginx-container
$ docker rm nginx-container

A variety of other software containers are provided on Docker Hub, including documentation of supported customization parameters, and debugging tips.

Now, a single container like this one is marginally interesting, but the utility really shines when building a modular system of multiple containers working on concert. Let’s investigate that next.

1 Like

Thanks for the post, Bryce.

I think it looks good and is heading to the right direction. A few comments:

  • First of all: the images are being called ROCKs now, instead of OCI. So if you’re referring to a single image, it’s a ROCK. Multiple images are ROCKs. I think it’s fine to keep the initial text explaining what OCI is, but it’s also a good opportunity to introduce our nomenclature.

  • In the Container Basics section, I believe it would be better to use the latest tag when pulling the nginx image. The 1.18-20.04_beta tag will eventually be deprecated and disappear. I understand that the intention was to show the user that it’s possible to use images based on an LTS series, and using latest won’t achieve the same effect. If you think it’s important to convey this message, then I’d suggest using the 22.04 tag which has recently been uploaded.

  • I’d write the container name using the “code” formatting when referring to it (i.e., nginx-container).

  • xdg-open might not be available everywhere (xdg-utils is listed as Priority: optional), so I think it’s fine to explicitly using firefox to open the link. You can also use curl if you prefer.

  • I’m a bit reticent regarding the part about inspecting the container. It makes the document feel a bit like “how to use docker”, instead of “how to work with ROCKs published by the Ubuntu Server team”. But that may be just my impression, of course. I see docker containers as very different beasts than lxd containers, for example. While you usually want to log into the latter in order to use it, the former is almost exclusively used as a “black box” that runs a service. WDYT?

Having said all that, I’m looking forward to seeing the rest of the content :-).

Thanks for the feedback Sergio.

The note about ROCKs vs. OCI is good to know. I haven’t spotted a good ROCKS explainer/marketing page, but if there is one it’d be worth linking to. This doc should focus more on how to use it.

For the tags, I’ve figured they should be targeting 22.04, since the overall document targets the LTS release. Originally I’d targeted ‘edge’ but after some trouble switched to 20.04 just to keep things stable while 22.04 was still in flux. But I’ll re-run through with 22.04 and update that as the target.

Regarding the container inspection, I do want to include some section somewhere that provides debugging tips. If someone is as inexperienced with docker as me, figuring out how to troubleshoot things can be time consuming, and knowing how to log into it makes it possible to use all your regular unix know-how to debug. But I can shift around where this section occurs so it doesn’t seem to suggest this as a recommended usage.