Podman: Building & Managing Container Images

Writing and Build Container Images#

Before we dive into Podman commands, let’s talk about container images. They’re like a frozen meal—you build them once and can run them anywhere. The difference is that if you mess up your container image, your app won’t just taste bad; it’ll fail spectacularly.

Writing a Containerfile (a.k.a Dockerfile for rebels)#

A Containerfile is Podman’s way of saying, “I’m totally not a Dockerfile, but I work exactly the same.” Here’s a basic one:

FROM alpine:latest
RUN apk add --no-cache curl
CMD ["curl", "https://example.com"]

Building an Image with Podman#

To create a container image from your Containerfile, use the following command:

podman build -t myimage:latest -f Containerfile

This tells Podman to build an image, tag it as myimage:latest, and use Containerfile as the source.

Running a Container from Your Image#

Once you have an image, you can run it as a container:

podman run -d --name mycontainer myimage:latest

This runs myimage:latest in detached mode (-d), assigning it the name mycontainer.

Useful Image Management Commands#

podman images   # List all images
podman inspect myimage   # Inspect image details
podman rmi myimage   # Remove an image

Tip: Be careful when using podman rmi. If you remove an image that’s still in use, well… let’s just say you’re going to have a bad time.

Multi-Stage Builds in Podman#

Writing efficient container images is an art. Multi-stage builds are like meal prepping for production—you build everything in a fat, resource-heavy environment and then only keep the essentials.

Why Should You Care?#

• Smaller image sizes → Faster deploys, less attack surface.
• Less garbage → No bloated dependencies floating around.
• Easier debugging → Okay, maybe not easier, but less painful.

Example: Optimized Go Application Build#

FROM golang:1.18 AS builder
WORKDIR /app
COPY . .
RUN go build -o myapp

FROM alpine:latest
COPY --from=builder /app/myapp /usr/local/bin/
ENTRYPOINT ["/usr/local/bin/myapp"]

Building & Running It#

podman build -t myapp:latest .
podman run --rm myapp:latest

Container Image Registries (Local & Remote)#

Managing images without a registry is like trying to share files via USB sticks—it works, but why would you?

Checking Your Configured Registries#

podman info | grep registries

Pulling & Pushing Images#

podman pull registry.fedoraproject.org/fedora:latest
podman push myimage:latest docker.io/myrepo/myimage:latest

Using a Private Registry#

podman login myregistry.com
podman tag myimage myregistry.com/myimage:latest
podman push myregistry.com/myimage:latest

Warning: If you forget to tag your image before pushing, Podman will throw a fit.

Container Image Security Best Practices#

Security isn’t optional. If you think it is, you might as well hand over your passwords to the nearest hacker.

Using Signed Images#

podman pull --tls-verify=true quay.io/example/image:latest

Scanning Images for Vulnerabilities#

podman scan myimage

Other Security Tips:#

• Use lightweight base images like alpine or scratch to minimize attack vectors.
• Don’t install unnecessary packages just because it “might be useful.” It won’t be.
• If your image has curl, wget, or nano, ask yourself why. Really, why?

Hands-On Exercise#

Enough theory—let’s get our hands dirty. Here’s your mission:

1. Build a secure multi-stage container image.
2. Push it to a private registry (if you break something, blame the registry, not me).
3. Scan it for vulnerabilities and optimize security.

If you survive this, congratulations—you’re officially better at Podman than most developers who still copy-paste Docker commands and hope for the best.

And that’s a wrap! Now go forth and containerize responsibly. If anything explodes, remember: it’s not Podman’s fault; it’s yours. Cheers!