RED HAT ENTERPRISE LINUX

Container Management

Managing Containers with Podman

College-Level Course Module | RHEL System Administration

Welcome to this essential module on container management in Red Hat Enterprise Linux. Containers have revolutionized how we deploy and manage applications. They package applications with their dependencies into isolated, portable units that run consistently across environments. RHEL uses Podman as its container engine - a daemonless, rootless-capable tool that provides Docker-compatible commands without requiring a background service or root privileges. You will learn to pull and manage container images, run containers with various configurations, persist data with volumes, configure networking, and run containers as systemd services for production use. These skills are essential for modern system administration and are tested on the RHCSA exam. Let us dive into the world of containers.

Learning Objectives

Understand container concepts

Images, containers, registries, and Podman architecture

Manage container images

Search, pull, list, inspect, and remove images

Run and manage containers

Create, start, stop, execute commands, and configure containers

Configure persistent storage and services

Use volumes for data persistence, run containers as systemd services

What Are Containers?

Containers are lightweight, isolated environments that package applications with their dependencies. They share the host kernel but have isolated filesystems, processes, and network stacks.

Virtual Machines

Full OS per VM
Hypervisor required
GB of memory each
Minutes to start
Strong isolation

Containers

Shared host kernel
No hypervisor needed
MB of memory each
Seconds to start
Process isolation

Container A | Container B | Container C

Container Runtime (Podman)

Host Operating System (RHEL)

Hardware

Containers are a lightweight virtualization technology. Unlike virtual machines that run complete operating systems with their own kernels, containers share the host system's kernel. Each container has its own isolated filesystem, process space, and network stack, but they all use the same kernel. This makes containers much more efficient than VMs. A VM might need gigabytes of memory and minutes to boot. A container typically needs megabytes and starts in seconds. You can run many more containers than VMs on the same hardware. The trade-off is isolation level. VMs have stronger isolation through the hypervisor. Containers rely on kernel features like namespaces and cgroups for isolation. For most applications, container isolation is sufficient and the efficiency gains are worth it. The diagram shows the architecture: multiple containers run on top of the container runtime (Podman), which runs on the host OS. All containers share that single kernel but are isolated from each other.

Images vs Containers

Container Image

Read-only template containing application and dependencies. Like a class definition or a recipe.

Built from layers
Stored in registries
Immutable once created
Shared across containers

Container

Running instance of an image with a writable layer. Like an object or a meal from a recipe.

Created from an image
Has isolated runtime
Writable layer on top
Can be started/stopped

Registry

→

Image

→

Container

→

Container

→

Container

Understanding the distinction between images and containers is fundamental. A container image is a read-only template. It contains the application code, runtime, libraries, and configuration needed to run an application. Images are built in layers - each layer adds files or configuration. This layering allows efficient storage and transfer since shared layers are stored once. A container is a running instance of an image. When you start a container, Podman takes the image and adds a thin writable layer on top. Any changes the container makes - new files, modified files - go in this writable layer. The underlying image remains unchanged. You can create many containers from the same image. Each gets its own writable layer but shares the read-only image layers. This is efficient - ten containers from the same image do not duplicate the image ten times. Images are pulled from registries - servers that store and distribute images. You pull an image, then create containers from it. When the container stops, its writable layer can be preserved or discarded.

Introduction to Podman

Podman (Pod Manager) is RHEL's container engine. It provides Docker-compatible commands without requiring a daemon or root privileges. It is the default container tool in RHEL 8 and 9.

Feature	Podman	Docker
Daemon	No daemon required	Requires dockerd daemon
Root access	Rootless by default	Requires root (or docker group)
Command syntax	docker-compatible	docker commands
Systemd integration	Native support	Limited
Pod support	Native pods	No native pods

# Install Podman
[root@server ~]# dnf install container-tools

# Verify installation
[user@server ~]$ podman --version
podman version 4.6.1

# Podman commands are Docker-compatible
[user@server ~]$ alias docker=podman   # Works for most commands

Podman is Red Hat's container engine and the standard tool for containers in RHEL. It has several advantages over Docker. First, Podman is daemonless. Docker requires a background daemon (dockerd) that must be running. Podman runs containers directly without any daemon. This simplifies management and eliminates a potential single point of failure. Second, Podman is rootless by default. Regular users can run containers without root privileges. This is more secure - a container escape does not give root access to the host. Docker traditionally required root or membership in the docker group, which is effectively root access. Third, Podman commands are Docker-compatible. If you know Docker, you know Podman. Most commands work identically - podman run, podman ps, podman images all work just like their Docker equivalents. Fourth, Podman has native systemd integration, making it easy to run containers as system services. Install Podman with dnf install container-tools, which includes Podman and related utilities.

Container Registries

Registries are servers that store and distribute container images. You pull images from registries and can push your own images to them.

Registry	URL	Description
Red Hat Registry	registry.redhat.io	Official Red Hat images (requires login)
Red Hat Catalog	registry.access.redhat.com	Certified partner images
Quay.io	quay.io	Red Hat's public registry
Docker Hub	docker.io	Public Docker registry

# Registry configuration
[user@server ~]$ cat /etc/containers/registries.conf
unqualified-search-registries = ["registry.access.redhat.com", "registry.redhat.io", "docker.io"]

# Login to registry (required for registry.redhat.io)
[user@server ~]$ podman login registry.redhat.io
Username: your-redhat-username
Password: 
Login Succeeded!

# Full image name format:
registry.redhat.io/rhel9/httpd-24:latest
registry/namespace/image:tag

Container registries are servers that store and distribute images. Think of them like package repositories for containers. Red Hat provides several registries. registry.redhat.io is the official Red Hat container registry. It contains supported Red Hat images but requires authentication with your Red Hat account. registry.access.redhat.com provides certified partner and community images. quay.io is Red Hat's public registry service. docker.io is Docker Hub, the largest public registry. The registry configuration file /etc/containers/registries.conf lists registries to search when you pull an image without specifying a full path. When you request just "httpd", Podman searches these registries in order. Full image names follow the format registry/namespace/image:tag. The tag specifies a version - latest is the default if not specified, but using explicit version tags is better for reproducibility. To use registry.redhat.io, log in first with podman login. Use your Red Hat customer portal credentials or a service account token.

Searching for Images

# Search registries for images
[user@server ~]$ podman search httpd
INDEX       NAME                                      DESCRIPTION                 STARS   OFFICIAL
redhat.io   registry.redhat.io/rhel8/httpd-24         Apache HTTP Server 2.4      0
redhat.io   registry.redhat.io/rhel9/httpd-24         Apache HTTP Server 2.4      0       
docker.io   docker.io/library/httpd                   The Apache HTTP Server      4523    [OK]
docker.io   docker.io/centos/httpd-24-centos7         Platform for running...     44

# Search specific registry
[user@server ~]$ podman search registry.redhat.io/httpd

# Limit results
[user@server ~]$ podman search --limit 5 nginx

# Show only official images
[user@server ~]$ podman search --filter=is-official=true httpd

# List available tags (requires skopeo)
[user@server ~]$ skopeo list-tags docker://registry.redhat.io/rhel9/httpd-24
{
    "Repository": "registry.redhat.io/rhel9/httpd-24",
    "Tags": ["1-290", "1-299", "latest"]
}

Before pulling images, you often need to find them. podman search queries configured registries for images matching your search term. Results show the registry, full image name, description, star rating (popularity indicator), and whether it is an official image. You can search specific registries by including the registry in your search term. The --limit option reduces the number of results. The --filter option narrows results - is-official=true shows only official images from that registry. To see what tags (versions) are available for an image, use skopeo. This tool inspects remote images without downloading them. skopeo list-tags shows all available versions. Using specific version tags rather than "latest" is recommended for production - you know exactly what version you are running and updates are explicit rather than automatic.

Pulling Images

# Pull an image from registry
[user@server ~]$ podman pull registry.redhat.io/rhel9/httpd-24
Trying to pull registry.redhat.io/rhel9/httpd-24:latest...
Getting image source signatures
Copying blob 8e5fca777171 done
Copying blob 3c72a8ed6814 done
Copying config 8f1de90813 done
Writing manifest to image destination
8f1de908137c2c3b9f2c7e8e4c9d9de1f4a6b5c3d2e1f0...

# Pull with specific tag
[user@server ~]$ podman pull registry.redhat.io/ubi9/ubi:9.3

# Pull from Docker Hub
[user@server ~]$ podman pull docker.io/library/nginx:1.25

# Pull without specifying registry (searches configured registries)
[user@server ~]$ podman pull ubi9
? Please select an image:
    registry.access.redhat.com/ubi9:latest
  ▸ registry.redhat.io/ubi9:latest

UBI (Universal Base Image): Red Hat provides freely distributable base images (UBI) that can be used without a subscription. Perfect for building custom containers.

Pulling downloads an image from a registry to your local storage. Use podman pull with the image name. The output shows Podman downloading image layers. Images are built in layers, and Podman only downloads layers it does not already have - pulling similar images is faster because they share base layers. Specify a version tag after a colon. Without a tag, Podman pulls "latest" which may not be what you want for reproducibility. Always use explicit tags in production. For images without a registry prefix, Podman prompts you to choose from configured registries. This prevents accidentally pulling the wrong image when names exist in multiple registries. Red Hat's Universal Base Images (UBI) are freely available base images you can use to build containers. They provide a supported, secure foundation without requiring a Red Hat subscription for the container itself - only the host system needs a subscription.

Managing Images

# List local images
[user@server ~]$ podman images
REPOSITORY                           TAG      IMAGE ID       CREATED        SIZE
registry.redhat.io/rhel9/httpd-24    latest   8f1de90813c2   2 weeks ago    462 MB
registry.redhat.io/ubi9/ubi          9.3      a1b2c3d4e5f6   3 weeks ago    211 MB
docker.io/library/nginx              1.25     b2c3d4e5f6a7   1 month ago    142 MB

# Inspect image details
[user@server ~]$ podman inspect registry.redhat.io/ubi9/ubi:9.3
[{
    "Id": "a1b2c3d4e5f6...",
    "Config": {
        "Cmd": ["/bin/bash"],
        "Env": ["PATH=/usr/local/sbin:..."],
        ...
    }
}]

# Show image history (layers)
[user@server ~]$ podman history registry.redhat.io/ubi9/ubi:9.3

# Remove an image
[user@server ~]$ podman rmi registry.redhat.io/ubi9/ubi:9.3

# Remove all unused images
[user@server ~]$ podman image prune -a

After pulling images, you need to manage them. podman images lists all images stored locally. Output shows repository, tag, image ID, creation date, and size. The image ID is a unique identifier - you can use it instead of the full name in commands. podman inspect shows detailed metadata about an image - its configuration, default command, environment variables, exposed ports, and more. This is invaluable for understanding how to run an image correctly. podman history shows the layers that make up an image and what commands created each layer. Useful for understanding image structure. podman rmi removes an image. You cannot remove an image that has containers (running or stopped) based on it - remove the containers first or use -f to force. podman image prune removes unused images. The -a flag removes all images not used by any container. Be careful with this in production - you might remove images you intended to keep.

Running Containers

# Run a container (pulls image if needed)
[user@server ~]$ podman run registry.redhat.io/ubi9/ubi echo "Hello Container"
Hello Container

# Run interactively with terminal
[user@server ~]$ podman run -it registry.redhat.io/ubi9/ubi /bin/bash
[root@a1b2c3d4 /]# cat /etc/redhat-release
Red Hat Enterprise Linux release 9.3 (Plow)
[root@a1b2c3d4 /]# exit

# Run in detached mode (background)
[user@server ~]$ podman run -d --name myweb registry.redhat.io/rhel9/httpd-24
a1b2c3d4e5f6g7h8i9j0...

# Run with automatic removal when stopped
[user@server ~]$ podman run --rm registry.redhat.io/ubi9/ubi cat /etc/os-release

Key options: -i interactive (keep STDIN open), -t allocate TTY, -d detached (background), --name assign name, --rm auto-remove on exit.

podman run creates and starts a container from an image. The basic syntax is podman run [options] image [command]. If the image is not local, Podman pulls it first. Without options, the container runs in the foreground, executes the command, and exits. The -i flag keeps standard input open for interactive use. The -t flag allocates a pseudo-terminal. Together, -it gives you an interactive shell session inside the container. The -d flag runs the container in detached mode - it starts in the background and returns the container ID. Use this for services that should keep running. The --name flag assigns a friendly name to the container. Without it, Podman generates a random name. Named containers are easier to manage. The --rm flag automatically removes the container when it exits. This is useful for one-off commands where you do not need to keep the container afterward. Without --rm, stopped containers remain and must be explicitly removed.

Container Lifecycle

# List running containers
[user@server ~]$ podman ps
CONTAINER ID  IMAGE                                   COMMAND               STATUS        PORTS   NAMES
a1b2c3d4e5f6  registry.redhat.io/rhel9/httpd-24      /usr/bin/run-http...  Up 5 minutes          myweb

# List all containers (including stopped)
[user@server ~]$ podman ps -a

# Stop a container
[user@server ~]$ podman stop myweb

# Start a stopped container
[user@server ~]$ podman start myweb

# Restart a container
[user@server ~]$ podman restart myweb

# Remove a stopped container
[user@server ~]$ podman rm myweb

# Force remove a running container
[user@server ~]$ podman rm -f myweb

# Remove all stopped containers
[user@server ~]$ podman container prune

Image

→

Created

→

Running

→

Stopped

→

Removed

Containers have a lifecycle you manage with various commands. podman ps shows running containers - their IDs, image, command, status, ports, and names. Add -a to see all containers including stopped ones. podman stop sends a termination signal to a container, allowing graceful shutdown. podman start resumes a stopped container. podman restart stops and starts in one command. podman rm removes a stopped container. Use -f to force-remove a running container. podman container prune removes all stopped containers - useful for cleanup. The lifecycle flow is: an image becomes a container when you run it. The container can be running or stopped. You can start and stop containers multiple times. When you remove a container, its writable layer is deleted. The underlying image remains. Containers can be referenced by ID (or partial ID) or by name. Names are easier to remember for frequently-used containers.

Executing Commands

# Execute command in running container
[user@server ~]$ podman exec myweb cat /etc/httpd/conf/httpd.conf

# Get interactive shell in running container
[user@server ~]$ podman exec -it myweb /bin/bash
[root@a1b2c3d4 /]# ps aux
USER  PID  %CPU %MEM    VSZ   RSS TTY  STAT START   TIME COMMAND
root    1   0.0  0.1  12345  1234 ?    Ss   10:00   0:00 httpd -D FOREGROUND
...
[root@a1b2c3d4 /]# exit

# View container logs
[user@server ~]$ podman logs myweb
[Mon Jan 20 10:00:00.000000 2024] [core:notice] Starting Apache...

# Follow logs in real-time
[user@server ~]$ podman logs -f myweb

# Show container resource usage
[user@server ~]$ podman stats myweb
ID            NAME    CPU %   MEM USAGE / LIMIT     MEM %   NET IO      BLOCK IO
a1b2c3d4e5f6  myweb   0.50%   45.2MiB / 7.768GiB    0.57%   1.2kB/0B    0B/0B

Often you need to run commands inside an already running container. podman exec runs a command in a running container. Unlike run which creates a new container, exec uses an existing one. For one-off commands, specify the command directly. For interactive access, use -it flags just like with run. This gives you a shell inside the container for troubleshooting or configuration. podman logs shows output from the container's main process - what would go to stdout and stderr. The -f flag follows logs in real-time, like tail -f. Logs are essential for troubleshooting container applications. podman stats shows real-time resource usage - CPU, memory, network, and block I/O. Useful for monitoring container performance and identifying resource issues. These commands work by container name or ID. Tab completion works for container names, making them convenient.

Port Mapping

Containers have isolated network stacks. To access container services from outside, map container ports to host ports using -p.

# Map host port 8080 to container port 80
[user@server ~]$ podman run -d --name web -p 8080:80 registry.redhat.io/rhel9/httpd-24

# Access from host
[user@server ~]$ curl http://localhost:8080
<html>...</html>

# Map multiple ports
[user@server ~]$ podman run -d -p 8080:80 -p 8443:443 --name secureweb nginx

# Map to specific host interface
[user@server ~]$ podman run -d -p 192.168.1.100:8080:80 --name web nginx

# Let Podman choose host port
[user@server ~]$ podman run -d -p 80 --name web nginx
[user@server ~]$ podman port web
80/tcp -> 0.0.0.0:43210

# View port mappings
[user@server ~]$ podman ps
...  PORTS                   NAMES
...  0.0.0.0:8080->80/tcp    web

Container networking is isolated by default - services inside containers are not accessible from outside. Port mapping connects host ports to container ports. The -p flag syntax is host-port:container-port. When you map port 8080:80, traffic arriving at the host on port 8080 is forwarded to port 80 inside the container. You can map multiple ports with multiple -p flags. You can bind to specific host interfaces by including the IP address - useful for multi-homed hosts or security. If you specify only the container port (-p 80), Podman automatically assigns an available host port. Use podman port to see what was assigned. Remember for rootless Podman: non-root users cannot bind to ports below 1024. Use higher ports like 8080 instead of 80. Also, open firewall ports on the host if external access is needed. Port mappings show in podman ps output, making it easy to see what is exposed.

Environment Variables

# Set environment variable
[user@server ~]$ podman run -d --name mydb \
    -e MYSQL_ROOT_PASSWORD=secret123 \
    -e MYSQL_DATABASE=appdb \
    docker.io/library/mysql:8.0

# Verify environment inside container
[user@server ~]$ podman exec mydb env | grep MYSQL
MYSQL_ROOT_PASSWORD=secret123
MYSQL_DATABASE=appdb

# Pass environment from file
[user@server ~]$ cat myenv.txt
DB_HOST=database.example.com
DB_USER=appuser
DB_PASS=secretpass

[user@server ~]$ podman run -d --name myapp --env-file myenv.txt myapp:latest

# Pass host environment variable
[user@server ~]$ export API_KEY="abc123"
[user@server ~]$ podman run -e API_KEY myapp:latest

Configuration pattern: Many container images use environment variables for configuration. Check image documentation for available variables.

Environment variables are the standard way to configure containerized applications. They pass configuration into the container at runtime without modifying the image. The -e flag sets environment variables. You can use multiple -e flags for multiple variables. This is how you configure things like database passwords, connection strings, feature flags, and application settings. For many variables, use --env-file to read from a file. Each line is NAME=value format. This is cleaner for complex configurations and keeps secrets out of command history. If you specify just a variable name with -e, Podman passes the current host value - useful for inheriting configuration from the host environment. Container images document what environment variables they expect. Database images typically need password variables. Web applications might need database connection details. Always check the image documentation to understand required and optional variables. Never hard-code sensitive values in images - always pass them at runtime.

Persistent Storage

By default, container data is ephemeral. When a container is removed, its writable layer is deleted. Use volumes for data that must persist.

# Bind mount host directory into container
[user@server ~]$ podman run -d --name web \
    -v /home/user/website:/var/www/html:Z \
    -p 8080:80 \
    registry.redhat.io/rhel9/httpd-24

# Create and use a named volume
[user@server ~]$ podman volume create dbdata
[user@server ~]$ podman run -d --name mysql \
    -v dbdata:/var/lib/mysql \
    -e MYSQL_ROOT_PASSWORD=secret \
    docker.io/library/mysql:8.0

# List volumes
[user@server ~]$ podman volume ls
DRIVER   VOLUME NAME
local    dbdata

# Inspect volume
[user@server ~]$ podman volume inspect dbdata

# Remove volume
[user@server ~]$ podman volume rm dbdata

Container storage is ephemeral by default. The writable layer exists only while the container exists. Remove the container, lose the data. For persistent data, use volumes. There are two main approaches. Bind mounts connect a host directory to a container path. The -v syntax is host-path:container-path. Any files in the host directory appear in the container, and changes in either location are reflected in both. The :Z suffix is important on SELinux systems - it applies the correct SELinux context so the container can access the files. Named volumes are managed by Podman. Create them with podman volume create, then reference by name instead of path. Podman stores volume data in a managed location. Named volumes are more portable and easier to backup than bind mounts. Use bind mounts when you need to share specific host files with containers. Use named volumes for application data like databases where you just need persistence, not specific host access.

SELinux and Volumes

SELinux blocks container access to host files by default. Use volume options to set correct context, or container cannot read/write mounted directories.

# Without SELinux option - fails with permission denied
[user@server ~]$ podman run -v /home/user/data:/data ubi9 ls /data
ls: cannot open directory '/data': Permission denied

# With :Z - relabels for this container only (private)
[user@server ~]$ podman run -v /home/user/data:/data:Z ubi9 ls /data
file1.txt  file2.txt

# With :z - relabels for shared access (multiple containers)
[user@server ~]$ podman run -v /shared/data:/data:z ubi9 ls /data

# Check SELinux context
[user@server ~]$ ls -lZ /home/user/data
-rw-r--r--. user user system_u:object_r:container_file_t:s0 file1.txt

:Z vs :z - Use uppercase :Z for private volumes (one container). Use lowercase :z for shared volumes (multiple containers). Both relabel for container access.

SELinux on RHEL protects the system by restricting what processes can access. By default, container processes cannot access arbitrary host files - SELinux blocks it even if Unix permissions allow it. When you bind mount a host directory, you must tell Podman to set the correct SELinux context. The :Z suffix (uppercase) relabels the directory for private container use. Only one container should use that directory. The :z suffix (lowercase) relabels for shared use. Multiple containers can access the directory. Without either option, you get Permission denied errors. This is a common stumbling point - the error looks like a permissions problem but it is actually SELinux. Use ls -Z to check SELinux contexts. Files accessible to containers should have container_file_t or similar container-related types. Named volumes handled by Podman automatically get correct contexts. This SELinux integration is primarily an issue with bind mounts to host directories.

Containers as Services

For production, run containers as systemd services. This provides automatic startup, restart on failure, and standard service management.

# Create container first (do not start yet for user service)
[user@server ~]$ podman create --name myweb -p 8080:80 registry.redhat.io/rhel9/httpd-24

# Generate systemd unit file
[user@server ~]$ mkdir -p ~/.config/systemd/user
[user@server ~]$ podman generate systemd --name myweb --files --new
~/.config/systemd/user/container-myweb.service

# Reload systemd and enable service
[user@server ~]$ systemctl --user daemon-reload
[user@server ~]$ systemctl --user enable --now container-myweb

# Check status
[user@server ~]$ systemctl --user status container-myweb

# Enable lingering (service runs without user login)
[user@server ~]$ loginctl enable-linger $USER

Enable lingering! Without loginctl enable-linger, user services stop when the user logs out.

For production deployments, manage containers with systemd. This gives you automatic startup at boot, restart on failure, dependency management, and standard service commands. podman generate systemd creates a systemd unit file from a container. The --name flag uses the container name in the unit file. The --files flag writes to a file instead of stdout. The --new flag creates a service that creates a fresh container each time rather than starting an existing one. For rootless containers, put the unit file in ~/.config/systemd/user/ and use systemctl --user commands. For root containers, use /etc/systemd/system/ and regular systemctl. Critical: enable lingering with loginctl enable-linger. Without this, user services stop when the user logs out. With lingering, services continue running even without an active session. After creating the unit file, reload systemd and enable the service. It starts automatically at boot and restarts if the container fails.

Rootless vs Root

Rootless (Default)

Run by regular users
No root privileges needed
Container escape = user access only
Cannot bind ports below 1024
Limited network features
User systemd services

Root Containers

Run by root user
Full system access
Container escape = root access!
Can bind any port
Full network features
System systemd services

# Rootless - run as regular user
[user@server ~]$ podman run -d -p 8080:80 --name web nginx

# Root - run as root (when necessary)
[root@server ~]# podman run -d -p 80:80 --name web nginx

# Storage locations differ:
# Rootless: ~/.local/share/containers/
# Root: /var/lib/containers/

Best practice: Use rootless containers whenever possible. Only run as root when you need privileged ports or specific system access.

Podman supports both rootless and root containers. This is a key security feature. Rootless containers run without root privileges. Any user can run them. If an attacker escapes the container, they only have that user's access - not root. This is the default and recommended mode. Limitations include: cannot bind ports below 1024 (use 8080 not 80), some network features are restricted, and storage is in the user's home directory. Root containers run with full privileges. Use them only when necessary - binding privileged ports, certain network configurations, or when images require root-specific features. A container escape from a root container gives root on the host - this is a significant security risk. Storage locations differ: rootless uses ~/.local/share/containers/, root uses /var/lib/containers/. Root and rootless containers are completely separate - they do not see each other's images or containers. For RHCSA and best practice, default to rootless. Understand both modes but prefer security.

Inspecting Containers

# Detailed container information
[user@server ~]$ podman inspect myweb
[{
    "Id": "a1b2c3d4e5f6...",
    "State": { "Status": "running", "Pid": 12345 },
    "NetworkSettings": { "IPAddress": "10.88.0.2" },
    "Mounts": [...],
    ...
}]

# Get specific value with format
[user@server ~]$ podman inspect --format '{{.State.Status}}' myweb
running

[user@server ~]$ podman inspect --format '{{.NetworkSettings.IPAddress}}' myweb
10.88.0.2

# View container processes
[user@server ~]$ podman top myweb
USER    PID   PPID   %CPU   ELAPSED   TTY   COMMAND
root    1     0      0.0    10m30s    ?     httpd -D FOREGROUND
apache  10    1      0.0    10m29s    ?     httpd -D FOREGROUND

# Show container filesystem changes
[user@server ~]$ podman diff myweb
C /var/log/httpd
A /var/log/httpd/access_log
A /var/log/httpd/error_log

Podman provides several ways to inspect running containers. podman inspect shows comprehensive container metadata in JSON format - state, network configuration, mounts, environment variables, and more. The output is verbose but complete. Use --format with Go template syntax to extract specific values. Common queries include status, IP address, port mappings, and environment variables. This is useful in scripts that need to work with container properties. podman top shows processes running inside the container, similar to the top or ps commands but scoped to one container. Useful for seeing what is actually running. podman diff shows filesystem changes - what files were added, changed, or deleted compared to the original image. C means changed, A means added, D means deleted. This helps understand what a container has modified during its runtime.

Best Practices

Do

Use rootless containers when possible
Use specific image tags, not :latest
Use volumes for persistent data
Set resource limits (--memory, --cpus)
Use named containers for easy management
Run containers as systemd services
Keep images updated for security
Use :Z or :z for bind mounts (SELinux)

Do Not

Run as root unless necessary
Store important data only in containers
Use untrusted images in production
Expose unnecessary ports
Hard-code secrets in images
Forget to clean up unused resources
Ignore container logs
Skip SELinux labels on bind mounts

# Good: Specific tag, named, resource limits, volume for data
[user@server ~]$ podman run -d --name mydb \
    --memory 512m --cpus 1 \
    -v dbdata:/var/lib/mysql:Z \
    -e MYSQL_ROOT_PASSWORD_FILE=/run/secrets/db-password \
    mysql:8.0.35

Following best practices ensures secure, maintainable container deployments. Use rootless containers - they provide better security with minimal trade-offs. Use specific version tags - "mysql:8.0.35" not "mysql:latest". Latest changes unpredictably and makes deployments non-reproducible. Always use volumes for data that must survive container restarts. Set resource limits to prevent containers from consuming all host resources. Name your containers - "mydb" is much easier to manage than "quirky_mendel". For production, run containers as systemd services with auto-restart. Keep images updated - container images need security updates like any software. On RHEL, always use :Z or :z for bind mounts or SELinux blocks access. Avoid running as root, storing data only in the container layer, using untrusted images, exposing unnecessary ports, embedding secrets in images, and neglecting cleanup. Regular maintenance with podman system prune keeps disk usage reasonable.

Key Takeaways

Podman: RHEL's daemonless, rootless container engine. Docker-compatible commands. Install with dnf install container-tools.

Images: podman search/pull/images/rmi. Use specific tags. Pull from trusted registries.

Containers: podman run/ps/stop/start/rm/exec/logs. Use -d for background, -p for ports, -e for environment, -v for volumes.

Services: podman generate systemd creates unit files. Enable lingering for user services. Use :Z for SELinux.

LAB EXERCISES

Pull images from registry.redhat.io and run a web server container
Map ports and access container service from host
Use volumes to persist data across container restarts
Configure container with environment variables
Create systemd service for container with auto-restart
Practice rootless container management as regular user

Next: Building Custom Container Images with Containerfiles

Let me summarize the essential container management skills. Podman is RHEL's container engine - daemonless and rootless by default. Commands are Docker-compatible, so existing knowledge transfers. Install the container-tools package to get started. Image management uses podman search to find images, pull to download, images to list, and rmi to remove. Always use specific version tags for reproducibility. Pull from trusted registries like registry.redhat.io. Container management uses podman run to create and start, ps to list, stop/start for lifecycle, rm to remove, exec to run commands inside, and logs to view output. Key run options are -d (background), -p (port mapping), -e (environment), and -v (volumes). For production, generate systemd service files with podman generate systemd. Enable lingering for user services to persist without login. Remember :Z for SELinux on bind mounts. Your lab exercises provide hands-on practice with all these concepts. Focus on the workflow: find image, pull, run with appropriate options, persist data, manage as service. These skills are essential for modern RHCSA and real-world Linux administration.