Lesson: Two Engines, One Standard

What you'll learn

Describe the daemon architecture of Docker and the daemonless architecture of Podman.
Explain rootful vs rootless containers and why rootless is safer.
Understand the OCI standard that lets images run on any compliant engine.
Decide when you might reach for Docker vs Podman.
Use the (almost identical) CLI of both engines.

By the end you will understand that "Docker" and "Podman" are two implementations of the same idea, so a skill in one transfers directly to the other.

The lesson

1. Same job, two designs

Docker and Podman both build and run containers. They differ mainly in architecture — how the pieces are arranged.

Docker uses a long-running background service called the daemon (dockerd). When you type docker run, the docker command-line tool just sends your request to that daemon, which does the real work.

   DOCKER (client / daemon)            PODMAN (daemonless)
   docker CLI                           podman CLI
       |  (talks to)                        |  (runs the work itself)
       v                                     v
   dockerd  (root daemon, always on)    container processes
       |                                  (children of YOUR shell)
       v
   container processes

Podman has no central daemon. The podman command starts containers directly as child processes of your own session. When the command exits, nothing extra is left running in the background.

Why care? A daemon is a single always-on service. If dockerd dies, everything it manages is affected, and historically it ran as root, making it a juicy target. Podman's daemonless model removes that single point of failure.

2. Rootful vs rootless

A rootful container engine runs as the root superuser. That is powerful but risky: a flaw that lets an attacker escape the container could hand them root on the host.

A rootless engine runs entirely as your normal, unprivileged user. It uses the user namespace (a Linux kernel feature — recall namespaces from Module 2) to map "root inside the container" to your ordinary user outside it. So a process can be root within its own little world while having no special powers on the host.

Podman runs rootless by default — a major reason people choose it.
Docker runs rootful by default (the daemon is root), though it offers a rootless mode you can opt into.

Rule of thumb: prefer rootless wherever you can. Less privilege means a smaller blast radius if something goes wrong.

3. The OCI standard — why images are portable

You can build an image with Docker and run it with Podman, or the reverse. That works because both follow the OCI (Open Container Initiative) standards. OCI defines:

the image-spec — how an image (its layers and metadata) is laid out, and
the runtime-spec — how a container is launched from it.

Think of OCI like the standard that lets any brand of charger fit a USB-C port. Because the format is agreed, the tool becomes a choice, not a lock-in. The same image you push to the lab registry at 10.100.100.6 runs identically whether the host has Docker or Podman installed.

4. The CLI is (almost) the same

Podman was deliberately built to mirror Docker's commands. Nearly everything you learned in Chapter 1 works by swapping one word:

# Docker
docker run -d --name web -p 8080:80 nginx:1.27
docker ps
docker logs web
docker exec -it web sh

# Podman — identical, just the binary name
podman run -d --name web -p 8080:80 nginx:1.27
podman ps
podman logs web
podman exec -it web sh

Many teams even add alias docker=podman so existing scripts keep working. The mental model and muscle memory transfer cleanly.

5. A few real differences to know

docker-compose: Docker ships first-class Compose support (Chapter 4). Podman supports Compose too (via podman compose / podman-compose), and additionally has pods — a way to group containers that share a network, the same concept Kubernetes uses.
Systemd integration: because Podman containers are just child processes, it is clean to run them as systemd services (podman generate systemd / Quadlet) so they start on boot without a daemon.
Building images: Docker uses docker build (BuildKit under the hood). Podman typically uses its sibling tool Buildah (podman build wraps it). Both read the same Dockerfile you will write in Chapter 5.

6. When to reach for which

There is no universally "correct" choice — it depends on context:

Docker is the most widely documented, has the largest ecosystem, and is what most tutorials assume. Great default for learning and for environments already standardised on it.
Podman is preferred where security and no-daemon simplicity matter: rootless by default, easy systemd services, and it is the default on Red Hat / Fedora systems. (Note: your lab box itself runs Fedora 44.)

For this internship you will mostly use Docker because the lab is set up for it, but everything you learn applies to Podman with a one-word change. Knowing both exist — and that they share the OCI standard — is what makes you flexible on a real team.

7. Quick verification

Confirm what is installed and how it is running:

docker version          # client + server (daemon) versions
docker info             # shows storage driver, root status, etc.

# If Podman is present:
podman version
podman info | grep -i rootless   # tells you the rootless status

Dig deeper

Search terms

docker daemon vs podman daemonless
rootless containers user namespace explained
what is the OCI open container initiative
podman vs docker when to use
alias docker podman compatibility
buildah podman build dockerfile

Check yourself

What is the dockerd daemon, and how does Podman's architecture differ?
What does "rootless" mean, and which kernel feature makes "root inside the container" map to a normal user outside?
What is the OCI, and why does it let a Docker-built image run under Podman?
Give two practical differences between Docker and Podman beyond the daemon.
Why can most Docker tutorials be followed with Podman by changing only one word?