If you work in DevOps, platform, or SRE, your day is a loop: pipeline broke, someone needs a container image checked, a developer swears it works locally, and you are the person who has to prove what is true before tonight’s deploy. You do not need another slide about “containers.” You need a tool that behaves on your laptop the way your Linux runners behave—and that does not fight your security team on every audit.
That is where Podman usually shows up. It is still “run an image, build a Dockerfile, wire up a compose file,” but it is built around a daemonless model on Linux, rootless workflows that feel grown-up, and commands close enough to docker that you are not relearning muscle memory from scratch. Below, I will tell you what Podman is in plain terms, then how people in our line of work actually use it in a normal day, then the commands you can run today on Linux or macOS (with Podman Machine).
π What is Podman? (the short honest version)
Podman (“Pod Manager”) is an open-source container engine that runs the same kind of OCI images you already push to registries and run on Kubernetes—images, containers, networks, volumes, the usual suspects. Think of it as the toolbox you use when you say “let me run this thing in isolation and see what happens,” except the toolbox was designed for people who will later have to explain their choices to security and to a broken CI log.
Why “daemonless” actually matters to you
With a classic Docker-style setup, a lot of your day is talking to one big background daemon (dockerd). Podman takes a different path: more fork-exec, less “there is always a root-owned daemon sitting there.” In day-to-day terms, that means fewer stories that start with “why is the daemon acting weird,” and a smaller conversation when someone asks what runs as root on this box. You still have real security work to do—but the model is easier to defend in a review.
Rootless on Linux (not just a buzzword)
On Linux, Podman is built to run rootless under your own user, using user namespaces and UID/GID maps. Practically: your test container is not silently “root on the host” unless you meant it to be. That lines up with how we want developers and CI to behave anyway—especially before the same image ends up in a cluster.
It speaks your habits—and a bit of Kubernetes
For most daily commands you can swap docker for podman in your head: pull, run, build, ps, images, exec. It is not a pixel-perfect clone of every Docker edge case, but it is close enough that you are not learning a new religion. When you live in YAML, tools like podman play kube (and playing with pods locally) help you rehearse how things will look in-cluster without burning cloud cost for every experiment.
Where you run it
On Linux, the engine is native—that is the happy path for matching servers and automation. On macOS, Apple is not Linux; Podman runs the engine inside Podman Machine, a small Linux VM your CLI talks to. Once you accept that layer, your day looks the same: build, run, debug—just mind bind mounts and paths when you share folders from your Mac.
☕ How DevOps engineers use Podman in real days
Nobody gets paid to “use Podman.” You get paid to ship safely, unblock people, and keep production boring. Podman is just a convenient way to do the boring parts without a fight. Here is how it usually shows up in a normal week—not theory, just the recurring tasks.
When the pipeline is red and you need a clean repro
The build passed on a branch last night; this morning it fails on main and Slack is noisy. Your job is to find out whether the problem is the code, the base image, or the runner. With Podman you pull the same Dockerfile or image tag, run podman build and podman run on your machine, and you get an answer without spinning a whole cluster story. On Linux, that repro is close to what many CI workers do; on a Mac, you are doing the same thing through Podman Machine—just remember bind mounts behave differently than on a bare-metal Linux laptop.
Before you tell someone “LGTM” on an image change
A developer bumps a parent image or adds a stage to the Dockerfile. You are not going to eyeball twenty layers in a web UI. You build it locally, run the entrypoint, maybe hit one health endpoint, and you sanity-check size and user permissions. That five-minute habit prevents the Friday deploy where the container runs as root when it should not, or where the image never actually started the process you thought it did.
When you are glue between devs and Kubernetes
Platform work is half psychology: people think in either Docker commands or Kubernetes YAML, rarely both at once. Podman lets you group things in pods locally, sketch dependencies, and sometimes translate toward manifests (generate kube / play kube style workflows) so a ticket becomes “here is what we tried on the laptop” instead of hand-wavy architecture. You are not replacing the cluster—you are making the handoff legible.
When you need a tool for twenty minutes, not a new install story
You need curl, jq, a specific Terraform build, or a one-off scanner against a file. Pull a small tool image, run it with podman run --rm, pipe files in, done. No “install this globally on my Mac,” no leftover service. DevOps folks live in that pattern; Podman just keeps it repeatable and scriptable.
When security asks uncomfortable questions
Sooner or later someone will ask what runs as root, what listens on the network, and what your developers use on their laptops. Podman gives you a cleaner story on Linux—rootless by default, no central daemon holding the keys—than older “always-on daemon as root” setups. That does not make you audit-proof; it makes the conversation shorter so you can spend time on real risks, like secrets in images and bad registry permissions.
π Plenty of teams still run Docker happily. I am not here to start a war. Use whatever your org supports. Podman tends to win hearts when Linux parity, security posture, and OSS policy show up in the same meeting—and that is a pretty common Tuesday for DevOps engineers.
π Podman vs Docker (quick comparison)
| Topic | Podman | Typical Docker Engine |
|---|---|---|
| Daemon | Daemonless (no dockerd-style requirement for core flows) | Central daemon |
| Rootless (Linux) | First-class | Available (rootless mode); historically optional |
| CLI familiarity | Very similar for common commands | Docker CLI + Engine |
| Compose | podman compose (Compose v2 with Podman backend) or podman-compose | docker compose |
You can mix tools; life is messy. Many of us pick Podman when local behavior and production behavior should rhyme, and when the same OCI artifact has to pass security without drama.
π How Podman fits in your workflow
Think of it this way: whether you sit on a Linux workstation or a MacBook, you are still trying to get to one portable artifact—the image—and run it somewhere predictable. On Linux, your shell talks straight to the engine. On macOS, Podman Machine sits in the middle, but the artifact and the mental model stay the same.
π³ CloudChef Recipe: Podman step by step (Linux and macOS)
Enough context—here is the part you can type along with. You will need install rights (sudo on Linux, Homebrew on macOS), and a shell like bash or zsh. Follow either the Linux path or the macOS path for Step 1; you are not meant to run both install flows on the same machine for this tutorial.
π₯ Step 1: Install Podman
On Linux
Fedora / RHEL family (dnf):
sudo dnf install -y podman
Debian / Ubuntu (apt): Package names and versions follow your distribution; adjust if your release ships an older Podman.
sudo apt-get update && sudo apt-get install -y podman
After install, optional sanity check for rootless (recommended): podman info should show rootless configuration when you run it as a normal user.
On macOS
Install the CLI (Homebrew is the usual path), then create and start a Linux VM that hosts the engine:
brew install podman
podman machine init
podman machine start
If you change CPU or memory needs later, see podman machine set --help. First-time init downloads an image; keep network allowance in mind.
Verify (Linux and macOS):
podman version
podman info
⚡ Step 2: Run your first container
Pull a small image and run it (prints a message and exits):
podman run --rm quay.io/podman/hello
Run an interactive shell in a throwaway Alpine container:
podman run --rm -it docker.io/library/alpine:latest sh
Inside the shell, try cat /etc/os-release, then type exit.
π§ Step 3: List containers and images
podman ps -a
podman images
π podman ps shows running containers; -a includes stopped ones—same mental model as docker ps.
π ️ Step 4: Build a tiny image
Create a directory and a Dockerfile:
mkdir -p ~/podman-demo && cd ~/podman-demo
cat > Dockerfile <<'EOF'
FROM docker.io/library/alpine:latest
RUN echo 'Built with Podman' > /message.txt
CMD ["cat", "/message.txt"]
EOF
Build and run:
podman build -t my-alpine-demo .
podman run --rm my-alpine-demo
π¦ Step 5: Create a pod (optional but “Podman-native”)
Create a pod with a name and published port, then attach a container:
podman pod create --name demo-pod -p 8080:80
podman run -d --pod demo-pod --name web docker.io/library/nginx:alpine
podman ps
podman pod ps
Stop and clean up when done:
podman pod stop demo-pod
podman pod rm demo-pod
π Step 6: Compose workflows (optional)
If you use Compose files, Podman can drive them (plugin availability varies by install). On Linux, your distro may ship podman-compose or the Compose v2 plugin; on macOS, Homebrew often pulls compatible pieces alongside Podman. Try:
podman compose version
podman compose up -d
If your environment uses a standalone podman-compose binary instead, use that executable—the goal is the same: multi-container apps from one YAML file.
⚠️ Practical gotchas (Linux vs macOS)
- macOS and Podman Machine: Containers run in a Linux VM, not natively on Darwin. Bind mounts map host paths into the VM—syntax and performance differ from Linux laptops; check current docs when sharing folders from
/Users/.... - Linux rootless networking: Published ports, DNS, and slirp/pasta-style networking can differ from rootful mode; test with
curlfrom the same host when something “should” be reachable. - Linux vs macOS parity: Treat Linux as the source of truth for production-like behavior; use macOS for day-to-day dev, but validate in CI or a Linux VM before you blame the image.
- Image names: Fully qualified registry paths (e.g.
docker.io/library/...) avoid ambiguity when multiple registries are configured.
π₯ CloudChef Pro Tip
If you only adopt one habit: reproduce pipeline failures with Podman before you escalate. On Linux, stay rootless for routine work so your laptop matches the posture you preach for CI. On macOS, spend ten real minutes on Podman Machine CPU/RAM and how bind mounts map into the VM—future you will not waste an afternoon on “the file is there but the container cannot see it.” Pin serious images by digest; keep bases small so reviews stay human-sized.
π Continue Your CloudChef Journey
π References
- Loading references...
π Final Thoughts
You will not get a medal for installing Podman. You will get fewer nights where you cannot tell whether a failure is the app, the image, or the environment—and that is the whole job. Use it to repro CI, to vet images before merge, to pull one-off tools without polluting your laptop, and to speak the same OCI language your cluster does.
On Linux, lean into rootless and let your habits match your runners. On macOS, make peace with Podman Machine early so volume quirks do not become mythology. Start with podman run and podman build; reach for pods and Compose when the work actually gets multi-container. Small habits, repeated daily, beat a perfect checklist you never run.
No comments:
Post a Comment