Loading...

VONDS ©

Lab 96: Running Containers with Podman

Back to Lab Index

Run containers with Podman using a rootless workflow, then inspect, restart, log, and clean up containers and images. Practice a bind mount so you can persist data between container runs.

containers podman rootless rhel

Scenario

You are preparing a host to run containerized utilities and small services using Podman. Your job is to install Podman, pull an image, run a named container, inspect state, view logs, practice a bind mount for persistence, and then clean up containers and images in a controlled way.

Operator context

Rootless Podman is a common default on modern systems. Build the habit of verifying state with ps, inspect, and logs before you destroy or replace anything.

Objective

  • Install Podman and confirm it runs as a non-root user.
  • Pull an image and run a named interactive container.
  • Verify stopped and running state and restart by name.
  • Read container logs and inspect container JSON.
  • Run a container with a bind mount for persistent data.
  • Remove containers and images cleanly.

Concepts

  • Rootless containers run under your user and use user namespaces. The goal is fewer privileged workflows by default.
  • Images are templates. Containers are instances created from images, and they can be running or stopped.
  • podman ps shows running containers. podman ps -a shows running and stopped containers.
  • Bind mounts map a host directory into a container. It is the simplest way to persist files between container runs.
  • In real environments, prefer targeted cleanup over broad wipe commands.

Walkthrough

Step 1 : Install Podman.
Commands 
# Debian/Ubuntu
sudo apt install podman -y

# RHEL/Fedora
sudo dnf install podman -y

# Arch
sudo pacman -S podman

After installation, default to a rootless workflow unless you have a specific reason to escalate. 

# Expected pattern:
Package installs successfully (or reports already installed).
Step 2 : Confirm Podman is usable as a non-root user.
Commands 
podman --version
podman info

This is a quick sanity check before you troubleshoot deeper. If rootless networking is not available on your host, it usually shows up in podman info.

Step 3 : Pull a small image.
Commands 
podman pull alpine
podman images

Keep the mental model: image equals template, container equals instance.

Step 4 : Run a named interactive container.
Commands 
podman run --name lab-alpine -it alpine /bin/sh

Exit the shell with exit or Ctrl+D. After that, verify state from the host. 

# Expected pattern:
Inside-container prompt appears, then returns to host after exit.
Step 5 : Verify the container exists and check its state.
Commands 
podman ps
podman ps -a

podman ps shows only running containers. podman ps -a gives you the full inventory. 

# Expected pattern:
lab-alpine appears in the -a list even if it is stopped.
Step 6 : Start the container by name and verify it is running.
Commands 
podman start lab-alpine
podman ps

If you need an interactive session again, attach with podman attach lab-alpine or run a new container.

Step 7 : View logs and inspect the container configuration.
Commands 
podman logs lab-alpine
podman inspect lab-alpine

Logs are your fastest signal about what happened. Inspect is your source of truth for mounts, networking, environment, and runtime configuration.

Step 8 : Practice a bind mount for persistence.
Commands 
mkdir -p ~/data

podman run --name lab-mount -v ~/data:/data -it alpine /bin/sh

Inside the container, create a file under /data and then exit. On the host, confirm the file exists in ~/data. 

# Example inside the container:
echo "hello from podman" > /data/hello.txt
exit

# Example on the host:
cat ~/data/hello.txt
Step 9 : Stop and remove containers cleanly.
Commands 
podman stop lab-alpine
podman stop lab-mount

podman rm lab-alpine
podman rm lab-mount

Stop first, then remove. In production, this pattern makes your intent obvious.

Step 10 : Remove images (targeted first).
Commands 
podman rmi alpine

# verify inventory
podman images

Prefer targeted removal. Broad wipes like podman rm -a or podman rmi -a are fine for lab hosts, but keep them deliberate.

Breakpoints

Cannot run rootless containers

If podman run fails with user namespace or storage errors, check podman info and confirm your environment supports rootless mode. On some systems, you may need subuid and subgid ranges configured.

Bind mount path confusion

Use a fully-expanded path like /home/USER/data if you suspect shell expansion issues. Also confirm the host directory exists before mounting so behavior stays predictable.

Image cannot be removed

If podman rmi alpine fails, a container may still reference the image. Re-check with podman ps -a, remove containers first, then remove the image.

Cleanup

Confirm you removed the lab containers, and keep your host data directory if you want it for the next lab cycle.

Commands 
podman ps -a
podman images

# optional: remove the host data directory created for the lab
rm -rf ~/data

Reference

  • podman : Rootless-capable container engine.
  • podman pull <image> : Download an image.
  • podman images : List local images.
  • podman run : Create and start a container from an image.
    • --name <name> : Assign a container name.
    • -it : Interactive TTY session.
    • -v HOST:CONTAINER : Bind mount a host path into the container.
  • podman ps : List running containers.
    • -a : Include stopped containers.
  • podman start <name> : Start an existing container.
  • podman stop <name> : Stop a running container.
  • podman logs <name> : Show container logs.
  • podman inspect <name> : Show container metadata as JSON.
  • podman rm <name> : Remove a container.
    • -f : Force removal (stops container if needed).
  • podman rmi <image> : Remove an image.
    • -a : Remove all images (use deliberately).