Objective: Access container image registries and manipulate container images locally.
Overview
Every container starts from an image, so working effectively with containers requires knowing how to find, retrieve, inspect, tag, and clean up images — and how registries organize and authenticate access to them.
Key Concepts
Registries and image names
A fully-qualified image name has the form registry/namespace/repository:tag, for example registry.redhat.io/rhel8/httpd-24:latest. If the registry is omitted, the container engine falls back to a configured default (or prompts to choose one, in Podman's case, when multiple unqualified-search registries are configured).
Common registries
Different registries serve different purposes: Red Hat's registry.redhat.io hosts certified, supported images (authentication required); registry.access.redhat.com hosts a subset without authentication; quay.io is Red Hat's general-purpose public/private registry service; and an OpenShift cluster runs its own internal registry for images built inside the cluster.
Authenticating to a registry
podman login <registry> stores credentials (in ~/.docker/config.json or the equivalent Podman auth file) so subsequent pulls and pushes to that registry don't require re-entering credentials.
Working with images locally
A core set of commands covers the full local image workflow: retrieving, listing, inspecting, tagging, and removing images.
| Command | Purpose |
|---|---|
podman search <term> |
Search configured registries for an image |
podman pull <image> |
Download an image to local storage |
podman images |
List locally stored images |
podman tag <image> <newname> |
Add an additional name/tag to a local image |
podman push <image> |
Upload a local image to a registry |
podman rmi <image> |
Remove a local image |
podman inspect <image> |
Show an image's layers, config, and metadata |
Image layers and caching
Each instruction that adds content to an image creates a new, immutable layer, stacked on top of the ones before it. Layers are content-addressed and shared across images where possible, which is why pulling a new image that shares a base with one you already have downloads only the new layers.
Working with It
A tag like :latest is only a label pointing at a specific image digest — it can be reassigned to a different image later, which is why production deployments should generally pin to an immutable digest, not a mutable tag.
podman search against your configured registries is faster than guessing an image's exact name and namespace.
podman rmi refuses to remove an image that a container (even a stopped one) still references — remove or update the container first, or use --force deliberately.
Pull, tag, and push an image
$ podman login registry.redhat.io
$ podman pull registry.redhat.io/rhel8/httpd-24
$ podman images
$ podman tag registry.redhat.io/rhel8/httpd-24 quay.io/myorg/httpd-24:v1
$ podman push quay.io/myorg/httpd-24:v1Watch Out For
podman rmi refuses to remove an image that a container (even a stopped one) still references — remove or update the container first, or use --force deliberately.
Key Terms
- Registry
- A networked service that stores and serves container images.
- Tag
- A human-readable label pointing at a specific image; mutable, unlike a digest.
- Layer
- An immutable, content-addressed filesystem diff that makes up part of an image.
- podman pull / push
- Commands to download an image from, or upload an image to, a registry.
- podman tag
- Adds an additional name to a locally stored image without duplicating its layers.
Review Questions
- Write out the four parts of a fully-qualified image name and give an example.
- What is the practical difference between registry.redhat.io and registry.access.redhat.com?
- Why can pulling a new image sometimes be much faster than its total size would suggest?
- Why is pinning a production deployment to an image digest safer than pinning to a tag like :latest?
- What would you need to do before
podman rmiwould succeed on an image still referenced by a stopped container?