AU294 Ch.2: Provisioning and Managing Containers

Objective: Provision containerized services from existing images and manage the life cycle of running containers.

Overview

Once an image exists, running it as a service is a matter of choosing the right run-time options — ports, environment variables, and restart behavior — and then managing the container through its life cycle: starting, stopping, inspecting, and removing it.

Key Concepts

Provisioning a containerized service

podman run pulls an image (if not already local) and starts a container from it. Common options map host ports to container ports, pass environment variables into the container, and control whether the container runs in the foreground or detached in the background.

$ podman run -d --name mysql-db \
    -e MYSQL_ROOT_PASSWORD=redhat \
    -e MYSQL_DATABASE=inventory \
    -p 3306:3306 \
    registry.redhat.io/rhel8/mysql-80

Container life-cycle states

A container moves through a predictable set of states over its life. Understanding these states is essential for troubleshooting and for scripting reliable start/stop automation.

State	Meaning
Created	Container exists but has not started running
Running	The container's main process is actively executing
Paused	Processes are frozen (cgroup freezer) but the container still exists
Exited	The main process has stopped; the container's filesystem still exists
Removed	The container and its writable layer have been deleted

Managing running containers

Day-to-day life-cycle commands cover starting and stopping containers, inspecting their configuration, and viewing logs generated by the containerized process.

Command	Purpose
`podman ps` / `podman ps -a`	List running / all containers
`podman stop <name>`	Gracefully stop a running container
`podman start <name>`	Start an existing, stopped container
`podman restart <name>`	Stop then start a container
`podman rm <name>`	Remove a stopped container
`podman logs <name>`	Show a container's stdout/stderr output
`podman inspect <name>`	Show detailed JSON configuration and state

Running containers as a systemd service

For containers that should survive a host reboot, Podman can generate a systemd unit file (podman generate systemd, or quadlet files on newer releases) so the container starts, stops, and restarts under normal systemd management rather than being run manually.

Working with It

Detached vs. Foreground

Use -d for long-running services; omit it (or use -it for an interactive shell) when you need to watch output directly or debug interactively.

Name Your Containers

Always pass --name — it makes every subsequent life-cycle command far more readable than referencing an auto-generated container ID.

Removing Loses the Writable Layer

podman rm deletes the container's writable layer permanently. Any data written inside the container but not stored in a volume is gone once the container is removed.

Basic life-cycle workflow

$ podman run -d --name web -p 8080:8080 quay.io/example/webapp:latest
$ podman ps
$ podman logs web
$ podman stop web
$ podman start web
$ podman rm -f web

Watch Out For

Common Pitfall

podman rm deletes the container's writable layer permanently. Any data written inside the container but not stored in a volume is gone once the container is removed.

Key Terms

podman run: Creates and starts a new container from an image.
Detached mode (-d): Runs a container in the background, returning control to the shell immediately.
Container state: The current life-cycle stage of a container: created, running, paused, exited, or removed.
podman inspect: Displays a container's full configuration and runtime state as JSON.
podman generate systemd: Produces a systemd unit file so a container is managed like any other service.

Review Questions

What is the difference between podman stop and podman rm?
Why does a container need a name or ID for most life-cycle commands, and what happens if you omit --name?
What data is lost when a container is removed, and what is not?
Which option runs a container in the background rather than attaching your terminal to it?
Why would you generate a systemd unit for a container instead of just running it with podman run once?