Featured image for "Red Hat CodeReady Containers 1.31.2 makes the leap."

Containers, Kubernetes, and microservices have been a hot topic for the past few years, yet many developers may still be wondering how they all work. To take a somewhat different angle on the subject, this article will describe how a container image is constructed and executed using a non-traditional, conversational approach.

First, let's take a quick look at the layers of a container image and how they relate to one another.

What is a container image?

Briefly, an image is an operating system that runs libraries and runtimes and an application, all enclosed in an Open Container Initiative (OCI) compliant file.

Figure 1 illustrates an example: a Node.js application that uses the Express library, running on the Red Hat Universal Base Image (UBI) operating system. If you're not familiar with Express, it's (as their website says) a "fast, unopinionated, minimalist web framework for Node.js" that makes it easy to create a Web API (RESTful) service.

Figure 1: Layers of a Linux image running a Node.js application
Image illustrating layers of a Linux image running a Node.js application

How containers work

If running a container were a conversation between all the interested parties, it would go something like this:

Actor Dialog

Command line:

docker run...


podman run...

"Hey Docker/Podman machine, run this image with these parameters. Thanks."


(Checks the registries in the configured list of registries to find the image to run. If the image isn't located in a local registry, it will pull from a remote registry.)

"Got the image. I'll now inspect the OCI-compliant interface; I need some information to run this image. I need..."

  • A user under which to run, e.g., root
  • The command needed to start the image.
  • The ports that should be exposed.
  • Environment variables and values
  • ...and more.

"OK, I have everything I need. Now the host operating system kernel needs to start running this image in a container."

Container (after being started by machine)

"Hello Linux (or Windows) kernel! Hope you're well today. Say ... I need access to a TCP port so I can process traffic in and out."

Host OS kernel "No problem. Here's a list of open ports."
Machine "I'm gonna choose this one and use it for this container. But since a port was specified on the command line to start this container, I'll redirect to that port for the container."
Container "Awesome; I'm processing traffic on the port of my choosing. Life is good."

Learn more about containers

I hope this unique take on how a container works is helpful. If you want more information, check out the links I've listed below. If you want to actually build and use containers, take advantage of the Developer Sandbox for Red Hat OpenShift, available at no cost.

Last updated: October 31, 2023