Chapter 2. Working with container images
Red Hat Enterprise Linux (RHEL) base images can be used as the foundation for the container images. For RHEL 8, all Red Hat base images are available as new Universal Base Images (UBI), which means that you can freely obtain and redistribute them. These include versions of RHEL standard, minimal, init, and Red Hat Software Collections that are all now freely available and redistributable. The RHEL base images are:
- Supported: Supported by Red Hat for use with containerized applications. They contain the same secured, tested, and certified software packages found in Red Hat Enterprise Linux.
- Cataloged: Listed in the Red Hat Container Catalog, with descriptions, technical details, and a health index for each image.
- Updated: Offered with a well-defined update schedule, so you know you are getting the latest software (see Red Hat Container Image Updates).
- Tracked: Tracked by errata to help understand the changes that go into each update.
- Reusable: The base images need to be downloaded and cached in your production environment once. Each base image can be reused by all containers that include it as their foundation.
UBIs for RHEL 8 provide the same quality RHEL software for building container images as their non-UBI predecessors (rhel6
, rhel7
, rhel-init
, and rhel-minimal
base images), but offer more freedom in how they are used and distributed.
For RHEL 8, standard, minimal and init base images are available. Red Hat also provides a set of language runtime images, based on Application Streams, that you can build on when you are creating containers for applications that require specific runtimes. Runtime images include python, php, ruby, nodejs, and others.
There is a set of RHEL 7 images as well that you can run on RHEL 8 systems. For RHEL 7, there are both UBI (redistributable) and non-UBI (require subscription access and are non-redistributable) base images. Those images include three regular base images (rhel7
, rhel-init
, and rhel-minimal
) and three UBI images (ubi7
, ubi7-init
, and ubi7-minimal
).
Although Red Hat does not offer tools for running containers on RHEL 6 systems, it does offer RHEL 6 container images you can use. There are standard (rhel6
) and init (rhel6-init
) base image available for RHEL 6, but no minimal RHEL 6 image. Likewise, there are no RHEL 6 UBI images.
Although the legacy RHEL 7 base images will continue to be supported, UBI images are recommended going forward. For that reason, examples in the rest of this chapter are done with RHEL 8 UBI images. For a list of available Red Hat UBI images, and associated information about UBI repositories and source code, see article Universal Base Images (UBI): Images, repositories, and packages.
2.1. Differences between RHEL images and UBI images
UBI images were created so you can build your container images on a foundation of official Red Hat software that can be freely shared and deployed. From a technical perspective, they are nearly identical to legacy Red Hat Enterprise Linux images, which means they have great security, performance, and life cycles, but they are released under a different End User License Agreement. Here are some attributes of Red Hat UBI images:
- Built from a subset of RHEL content: Red Hat Universal Base images are built from a subset of normal Red Hat Enterprise Linux content. All of the content used to build selected UBI images is released in a publicly available set of yum repositories. This lets you install extra packages, as well as update any package in UBI base images.
- Redistributable: The intent of UBI images is to allow Red Hat customers, partners, ISVs, and others to standardize UBI images so you can build your container images on a foundation of official Red Hat software that can be freely shared and deployed. From a technical perspective, they are nearly identical to legacy Red Hat Enterprise Linux images, which means they have great security, performance, and life cycles, but they are released under a different End User License Agreement.
- Base and runtime images: Besides the three types of base images, UBI versions of various runtime images are available as well. These runtime images provide a foundation for applications that can benefit from standard, supported runtimes such as python, php, nodejs, and ruby.
Enabled yum repositories: The following yum repositories are enabled within each RHEL 8 UBI image:
-
The
ubi-8-baseos
repository holds the redistributable subset of RHEL packages you can include in your container. -
The
ubi-8-appstream
repository holds Application streams packages that you can add to a UBI image to help you standardize the environments you use with applications that require particular runtimes.
-
The
- Licensing: You are free to use and redistribute UBI images, provided you adhere to the Red Hat Universal Base Image End User Licensing Agreement.
- Adding UBI RPMs: You can add RPM packages to UBI images from preconfigured UBI repositories. If you happen to be in a disconnected environment, you must allowlist the UBI Content Delivery Network (https://cdn-ubi.redhat.com) to use that feature. See the Connect to https://cdn-ubi.redhat.com solution for details.
2.2. Understanding standard Red Hat base images
Standard RHEL 8 base images (ubi8
) have a robust set of software features that include the following:
-
init system: All the features of the systemd initialization system you need to manage systemd services are available in the standard base images. These init systems let you install RPM packages that are pre-configured to start up services automatically, such as a Web server (
httpd
) or FTP server (vsftpd
). -
yum: Software needed to install software packages is included via the standard set of
yum
commands (yum
,yum-config-manager
,yumdownloader
, and so on). For the UBI base images, you have access to free yum repositories for adding and updating software. -
utilities: The standard base image includes some useful utilities for working inside the container. Utilities that are in this base image that are not in the minimal images include
tar
,dmidecode
,gzip
,getfacl
(and other acl commands),dmsetup
(and other device mapper commands), and others.
2.3. Understanding minimal Red Hat base images
The ubi8-minimal
images are stripped-down RHEL images to use when a bare-bones base image in desired. If you are looking for the smallest possible base image to use as part of the larger Red Hat ecosystem, you can start with these minimal images.
RHEL minimal images provide a base for your own container images that is less than half the size of the standard image, while still being able to draw on RHEL software repositories and maintain any compliance requirements your software has.
Here are some features of the minimal base images:
- Small size: Minimal images are about 92M on disk and 32M compressed. This makes it less than half the size of the standard images.
-
Software installation (
microdnf
): Instead of including the full-blownyum
facility for working with software repositories and RPM software packages, the minimal images includes themicrodnf
utility. themicrodnf
is a scaled-down version ofdnf
. It includes only what is needed to enable and disable repositories, as well as install, remove, and update packages. It also has a clean option, to clean out cache after packages have been installed. - Based on RHEL packaging: Because minimal images incorporate regular RHEL software RPM packages, with a few features removed such as extra language files or documentation, you can continue to rely on RHEL repositories for building your images. This allows you to still maintain compliance requirements you have that are based on RHEL software. Features of minimal images make them perfect for trying out applications you want to run with RHEL, while carrying the smallest possible amount of overhead. What you do not get with minimal images is an initialization and service management system (systemd or System V init), a Python run-time environment, and a bunch of common shell utilities.
-
Modules for
microdnf
are not supported: Modules used with thednf
command let you install multiple versions of the same software, when available. Themicrodnf
utility included with minimal images does not support modules. So if modules are required, you should use a non-minimal base images, which includeyum
.
If your goal, however, is just to try to run some simple binaries or pre-packaged software that does not have a lot of requirements from the operating system, the minimal images might suit your needs. If your application does have dependencies on other software from RHEL, you can use microdnf
to install the needed packages at build time.
Red Hat intends for you to always use the latest version of the minimal images, which is implied by requesting ubi8/ubi-minimal
or ubi8-minimal
. Red Hat does not expect to support older versions of minimal images going forward.
2.4. Understanding init Red Hat base images
The UBI ubi8-init
images contain the systemd initialization system, making them useful for building images in which you want to run systemd services, such as a web server or file server. The init image contents are less than what you get with the standard images, but more than what is in the minimal images.
Because the ubi8-init
image builds on top of the ubi8
image, their contents are mostly the same. There are a few critical differences, however. In ubi8-init
, the Cmd is set to /sbin/init
, instead of bash
, to start the systemd Init service by default. It includes ps
and process related commands (procps-ng
package), which ubi8 does not. Also, ubi8-init
sets SIGRTMIN+3
as the StopSignal
, as systemd in ubi8-init
ignores normal signals to exit (SIGTERM
and SIGKILL
), but will terminate if it receives SIGRTMIN+3
.
Historically, Red Hat Enterprise Linux base container images were designed for Red Hat customers to run enterprise applications, but were not free to redistribute. This can create challenges for some organizations that need to redistribute their applications. That is where the Red Hat Universal Base Images come in.
2.5. Using the UBI init images
This procedure shows how to build a container using a Dockerfile that installs and configures a Web server (httpd
) to start automatically by the systemd service (/sbin/init
) when the container is run on a host system.
Procedure
Create a Dockerfile with the following contents to a new directory:
FROM registry.access.redhat.com/ubi8/ubi-init RUN yum -y install httpd; yum clean all; systemctl enable httpd; RUN echo "Successful Web Server Test" > /var/www/html/index.html RUN mkdir /etc/systemd/system/httpd.service.d/; echo -e '[Service]\nRestart=always' > /etc/systemd/system/httpd.service.d/httpd.conf EXPOSE 80 CMD [ "/sbin/init" ]
The Dockerfile installs the
httpd
package, enables thehttpd
service to start at boot time, creates a test file (index.html
), exposes the Web server to the host (port 80), and starts the systemd init service (/sbin/init
) when the container starts.Build the container:
# podman build --format=docker -t mysysd .
Optionally, if you want to run containers with systemd and SELinux is enabled on your system, you must set the
container_manage_cgroup
boolean variable:# setsebool -P container_manage_cgroup 1
Run the container named
mysysd_run
:# podman run -d --name=mysysd_run -p 80:80 mysysd
The
mysysd
image runs as themysysd_run
container as a daemon process, with port 80 from the container exposed to port 80 on the host system.Check that the container is running:
# podman ps a282b0c2ad3d localhost/mysysd:latest /sbin/init 15 seconds ago Up 14 seconds ago 0.0.0.0:80->80/tcp mysysd_run
Test the web server:
# curl localhost/index.html Successful Web Server Test
2.6. Redistributing UBI images
This procedure describes how to redistribute UBI images. After you pull a UBI image, you are free to push a UBI image to your own or another third-party registry and share it with others. You can upgrade or add to that image from UBI yum repositories as you like.
Procedure
To pull the
ubi
image from the registry.redhat.io registry, enter:# podman pull registry.redhat.io/ubi8/ubi
To add an additional name to the
ubi
image, enter:# podman tag registry.redhat.io/ubi8/ubi registry.example.com:5000/ubi8/ubi
To push the
ubi
image from your local storage to a registry, enter:# podman push registry.example.com:5000/ubi8/ubi
While there are few restrictions on how you use these images, there are some restrictions about how you can refer to them. For example, you cannot call those images Red Hat certified or Red Hat supported unless you certify it through the Red Hat Partner Connect Program, either with Red Hat Container Certification or Red Hat OpenShift Operator Certification.
2.7. Searching for container images
The podman search
command lets you search selected container registries for images.
You can also search for images in the Red Hat Container Registry. The Red Hat Container Registry includes the image description, contents, health index, and other information.
You can find the list of registries in the configuration file registries.conf
:
[registries.search] registries = ['registry.access.redhat.com', 'registry.redhat.io', 'docker.io'] [registries.insecure] registries = [] [registries.block] registries = []
-
By default, the
podman search
command searches for container images from registries listed in section[registries.search]
in the given order. In this case,podman search
command looks for the requested image in registry.access.redhat.com, registry.redhat.io and docker.io in this order. -
The
[registries.insecure]
section adds the registries that do not use TLS (an insecure registry). -
The
[registries.block]
section disallows the access to the registry from your local system.
As a root user, you can edit the /etc/containers/registries.conf
file to change the default, system-wide search settings.
As a regular (rootless) user of podman
, you can create your own registries.conf
file in your home directory ($HOME/.config/containers/registries.conf
) to override the system-wide settings.
Make sure that you follow the conditions when configuring container registries:
- Each registry must be surrounded by single quotes.
-
If there are multiple registries set for the
registries = value
, you must separate those registries by commas. - You can identify registries by either IP address or hostname.
- If the registry uses a non-standard port - other than TCP ports 443 for secure and 80 for insecure, enter that port number with the registry name. For example: host.example.com:9999.
-
The system searches for registries in the order in which they appear in the
registries.search
list of theregistries.conf
file.
Some podman search
command examples follow. The first example illustrates the unsuccessful search of all images from quay.io. The forwardslash at the end means to search the whole registry for all images accessible to you:
# podman search quay.io/ ERRO[0000] error searching registry "quay.io": couldn't search registry "quay.io": unable to retrieve auth token: invalid username/password
To search quay.io registry, log in first:
# podman login quay.io Username: johndoe Password: *********** Login Succeeded! # podman search quay.io/ INDEX NAME DESCRIPTION STARS OFFICIAL AUTOMATED quay.io quay.io/test/myquay 0 quay.io quay.io/test/redistest 0 quay.io quay.io/johndoe/websrv21 0 quay.io quay.io/johndoe/mydbtest 0 quay.io quay.io/johndoe/newbuild-10 0
Search all available registries for postgresql
images (resulting in more than 40 images found):
# podman search postgresql-10 INDEX NAME DESCRIPTION STARS OFFICIAL AUTOMATED redhat.io registry.redhat.io/rhel8/postgresql-10 This container image ... 0 redhat.io registry.redhat.io/rhscl/postgresql-10-rhel7 PostgreSQL is an advanced ... 0 quay.io quay.io/mettle/postgresql-database-provisioning docker.io docker.io/centos/postgresql-10-centos7 PostgreSQL is an advanced ... 13 ...
To limit your search for postgresql
to images from registry.redhat.io, type the following command. Notice that by entering the registry and the image name, any repository in the registry can be matched:
# podman search registry.redhat.io/postgresql-10 INDEX NAME DESCRIPTION STARS OFFICIAL AUTOMATED redhat.io registry.redhat.io/rhel8/postgresql-10 This container image ... 0 redhat.io registry.redhat.io/rhscl/postgresql-10-rhel7 PostgreSQL is an ... 0
To get longer descriptions for each container image, add --no-trunc
to the command:
# podman search --no-trunc registry.redhat.io/rhel8/postgresql-10 INDEX NAME DESCRIPTION STARS OFFICIAL AUTOMATED redhat.io registry.redhat.io/rhel8/postgresql-10 This container image provides a containerized packaging of the PostgreSQL postgres daemon and client application. The postgres server daemon accepts connections from clients and provides access to content from PostgreSQL databases on behalf of the clients. 0
To access insecure registries, add the fully-qualified name of the registry to the [registries.insecure]
section of the /etc/containers/registries.conf
file. For example:
[registries.search] registries = ['myregistry.example.com'] [registries.insecure] registries = ['myregistry.example.com']
Then, search for myimage
images:
# podman search myregistry.example.com/myimage INDEX NAME DESCRIPTION STARS OFFICIAL AUTOMATED example.com myregistry.example.com/myimage The myimage container executes the ... 0
Now you can pull myimage
image:
# podman pull myimage.example.com/myimage
2.8. Defining the image signature verification policy
Red Hat delivers signatures for the images in the Red Hat Container Registry. When running as root, /etc/containers/policy.json
, and the YAML files in the /etc/containers/registries.d/
directory define the signature verification policy. The trust policy in /etc/containers/policy.json
describes a registry scope (registry and or or repository) for the trust.
By default, the container tool reads the policy from $HOME/.config/containers/policy.json
, if it exists, otherwise from /etc/containers/policy.json
.
Trust is defined using three parameters:
- The registry or registry/repository name
- One or more public GPG keys
- A signature server
Red Hat serves signatures from these URIs:
https://access.redhat.com/webassets/docker/content/sigstore https://registry.redhat.io/containers/sigstore
Procedure
Display the
/etc/containers/policy.json
file:# cat /etc/containers/policy.json { "default": [ { "type": "insecureAcceptAnything" } ], "transports": { "docker-daemon": { "": [{"type":"insecureAcceptAnything"}] } } }
To update an existing trust scope for the registries registry.access.redhat.com and registry.redhat.io, enter:
# podman image trust set -f /etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release registry.access.redhat.com # podman image trust set -f /etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release registry.redhat.io
To verify trust policy configuration, display the
/etc/containers/policy.json
file:"docker": { "registry.access.redhat.com": [ { "type": "signedBy", "keyType": "GPGKeys", "keyPath": "/etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release" } ], "registry.redhat.io": [ { "type": "signedBy", "keyType": "GPGKeys", "keyPath": "/etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release" } ] },
You can see that sections
"registry.access.redhat.com"
and"registry.redhat.io"
are added.Create the
/etc/containers/registries.d/registry.access.redhat.com.yaml
file to identify the signature store for container images from registry.access.redhat.com registry:docker: registry.access.redhat.com: sigstore: https://access.redhat.com/webassets/docker/content/sigstore
Create the
etc/containers/registries.d/registry.redhat.io.yaml
file with the following content:docker: registry.redhat.io: sigstore: https://registry.redhat.io/containers/sigstore
To display the trust configuration, enter:
# podman image trust show default accept registry.access.redhat.com signedBy security@redhat.com, security@redhat.com https://access.redhat.com/webassets/docker/content/sigstore registry.redhat.io signedBy security@redhat.com, security@redhat.com https://registry.redhat.io/containers/sigstore insecureAcceptAnything
To reject the default trust policy, type:
# podman image trust set -t reject default
To verify the trust policy configuration, display the
/etc/containers/policy.json
:# cat /etc/containers/policy.json { "default": [ { "type": "reject" } ... }
You can see that the
"default"
section has changed from"insecureAcceptAnything"
to"reject"
.Try to pull the minimal Red Hat Universal Base Image 8 (
ubi8-minimal
) image from the registry.access.redhat.com registry:# podman --log-level=debug pull registry.access.redhat.com/ubi8-minimal .... DEBU[0000] Using registries.d directory /etc/containers/registries.d for sigstore configuration DEBU[0000] Using "docker" namespace registry.access.redhat.com DEBU[0000] Using https://access.redhat.com/webassets/docker/content/sigstore ...
You see that the signature storage address
access.redhat.com/webassets/docker/content/sigstore
matches the address you specified in the/etc/containers/registries.d/registry.access.redhat.com.yaml
.Log in to the registry.redhat.io registry:
# podman login registry.redhat.io Username: username Password: *********** Login Succeeded!
Try to pull the
support-tools
image from the registry.redhat.io registry:# podman --log-level=debug pull registry.redhat.io/rhel8/support-tools ... DEBU[0000] Using registries.d directory /etc/containers/registries.d for sigstore configuration DEBU[0000] Using "docker" namespace registry.redhat.io DEBU[0000] Using https://registry.redhat.io/containers/sigstore ...
You can see that the signature storage address
registry.redhat.io/containers/sigstore
matches the address you specified in the/etc/containers/registries.d/registry.redhat.io.yaml
.To list all images pulled to your local system, enter:
# podman images REPOSITORY TAG IMAGE ID CREATED SIZE registry.redhat.io/rhel8/support-tools latest 5ef2aab09451 13 days ago 254 MB registry.access.redhat.com/ubi8-minimal latest 86c870596572 13 days ago 146 MB
Additional resources
-
For more information on the
podman image trust
, typeman podman-image-trust
. - For more information about verifying container images, see article Verifying image signing for Red Hat Container Registry.
2.9. Pulling images from registries
To get container images from a remote registry (such as Red Hat’s own container registry) and add them to your local system, use the podman pull
command:
# podman pull <registry>[:<port>]/[<namespace>/]<name>:<tag>
The <registry> is a host that provides a container registry service on TCP <port>. Together, <namespace> and <name> identify a particular image controlled by <namespace> at that registry. The <tag> is an additional name to locally-stored image, the default tag is latest
. Always use fully qualified image names including: registry, namespace, image name and tag. When using short names, there is always an inherent risk of spoofing. Add registries that are trusted, that is registries which do not allow unknown or anonymous users to create accounts with arbitrary names.
Some registries also support raw <name>; for those, <namespace> is optional. When it is included, however, the additional level of hierarchy that <namespace> provides is useful to distinguish between images with the same <name>. For example:
Namespace | Examples (<namespace>/<name>) |
---|---|
organization |
|
login (user name) |
|
role |
|
The registries that Red Hat provides are registry.redhat.io (requiring authentication), registry.access.redhat.com (requires no authentication), and registry.connect.redhat.com (holds Red Hat Partner Connect program images). For details on the transition to registry.redhat.io, see Red Hat Container Registry Authentication . Before you can pull containers from registry.redhat.io, you need to authenticate. For example:
# podman login registry.redhat.io Username: myusername Password: ************ Login Succeeded!
Use the pull option to pull an image from a remote registry. To pull the RHEL base image ubi
and rsyslog
logging image from the Red Hat registry, type:
# podman pull registry.redhat.io/ubi8/ubi # podman pull registry.redhat.io/rhel8/rsyslog
An image is identified by a registry name (registry.redhat.io), a namespace name (ubi8) and the image name (ubi). You could also add a tag (which defaults to :latest if not entered). The repository name ubi, when passed to the podman pull command without the name of a registry preceding it, is ambiguous and could result in the retrieval of an image that originates from an untrusted registry. If there are multiple versions of the same image, adding a tag, such as latest to form a name such as ubi8/ubi:latest, lets you choose the image more explicitly.
To see the images that resulted from the above podman pull command, along with any other images on your system, type podman images:
REPOSITORY TAG IMAGE ID CREATED SIZE registry.redhat.io/ubi8/ubi latest eb205f07ce7d 2 weeks ago 214MB registry.redhat.io/rhel8/rsyslog latest 85cfba5cd49c 2 weeks ago 234MB
The ubi
and rsyslog
images are now available on your local system for you to work with.
2.10. Listing images
You can use podman images
command to see which images have been pulled to your local system and are available to use.
Procedure
- To list images in local storage, enter:
# podman images REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE registry.redhat.io/rhel8/support-tools latest b3d6ce4e0043 2 days ago 234MB registry.redhat.io/ubi8/ubi-init latest 779a05997856 2 days ago 225MB registry.redhat.io/ubi8/ubi latest a80dad1c1953 3 days ago 210MB
2.11. Inspecting local images
After you pull an image to your local system and before you run it, it is a good idea to investigate that image. Reasons for investigating an image before you run it include:
- Understanding what the image does
- Checking what software is inside the image
Procedure
The podman inspect
command displays basic information about what an image does. You also have the option of mounting the image to your host system and using tools from the host to investigate what is in the image. Here is an example of investigating what a container image does before you run it.
Inspect an image: Run
podman inspect
to see what command is executed when you run the container image, as well as other information. Here are examples of examining the ubi8/ubi and rhel8/rsyslog container images (with only snippets of information shown here):# podman pull registry.redhat.io/ubi8/ubi # podman inspect registry.redhat.io/ubi8/ubi | less ... "Cmd": [ "/bin/bash" ], "Labels": { "License": "GPLv3", "architecture": "x86_64", "authoritative-source-url": "registry.redhat.io", "build-date": "2018-10-24T16:46:08.916139", "com.redhat.build-host": "cpt-0009.osbs.prod.upshift.rdu2.redhat.com", "com.redhat.component": "rhel-server-container", "description": "The Red Hat Enterprise Linux Base image is designed to be a fully supported... ...
# podman pull registry.redhat.io/rhel8/rsyslog # podman inspect registry.redhat.io/rhel8/rsyslog "Cmd": [ "/bin/rsyslog.sh" ], "Labels": { "License": "GPLv3", "architecture": "x86_64", ... "install": "podman run --rm --privileged -v /:/host -e HOST=/host -e IMAGE=IMAGE -e NAME=NAME IMAGE /bin/install.sh", ... "run": "podman run -d --privileged --name NAME --net=host --pid=host -v /etc/pki/rsyslog:/etc/pki/rsyslog -v /etc/rsyslog.conf:/etc/rsyslog.conf -v /etc/sysconfig/rsyslog:/etc/sysconfig/rsyslog -v /etc/rsyslog.d:/etc/rsyslog.d -v /var/log:/var/log -v /var/lib/rsyslog:/var/lib/rsyslog -v /run:/run -v /etc/machine-id:/etc/machine-id -v /etc/localtime:/etc/localtime -e IMAGE=IMAGE -e NAME=NAME --restart=always IMAGE /bin/rsyslog.sh", "summary": "A containerized version of the rsyslog utility ...
The ubi8/ubi container will execute the bash shell, if no other argument is given when you start it with
podman run
. If an Entrypoint were set, its value would be used instead of the Cmd value (and the value of Cmd would be used as an argument to the Entrypoint command).In the second example, the rhel8/rsyslog container image has built-in
install
andrun
labels. Those labels give an indication of how the container is meant to be set up on the system (install) and executed (run).Mount a container: Using the
podman
command, mount an active container to further investigate its contents. This example runs and lists a runningrsyslog
container, then displays the mount point from which you can examine the contents of its file system:# podman run -d registry.redhat.io/rhel8/rsyslog # podman ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 1cc92aea398d ...rsyslog:latest /bin/rsyslog.sh 37 minutes ago Up 1 day ago myrsyslog # podman mount 1cc92aea398d /var/lib/containers/storage/overlay/65881e78.../merged # ls /var/lib/containers/storage/overlay/65881e78*/merged bin boot dev etc home lib lib64 media mnt opt proc root run sbin srv sys tmp usr var
After the podman mount, the contents of the container are accessible from the listed directory on the host. Use
ls
to explore the contents of the image.Check the image’s package list: To check the packages installed in the container, tell the
rpm
command to examine the packages installed on the container’s mount point:# rpm -qa --root=/var/lib/containers/storage/overlay/65881e78.../merged redhat-release-server-7.6-4.el7.x86_64 filesystem-3.2-25.el7.x86_64 basesystem-10.0-7.el7.noarch ncurses-base-5.9-14.20130511.el7_4.noarch glibc-common-2.17-260.el7.x86_64 nspr-4.19.0-1.el7_5.x86_64 libstdc++-4.8.5-36.el7.x86_64
2.12. Inspecting remote images
To inspect a container image before you pull it to your system, you can use the skopeo inspect
command. With skopeo inspect
, you can display information about an image that resides in a remote container registry.
Procedure
The following command inspects the ubi8-init
image from the Red Hat registry.
-
To inspect the
ubi8-init
from the registry.redhat.io registry, enter:
# skopeo inspect docker://registry.redhat.io/ubi8/ubi-init { "Name": "registry.redhat.io/ubi8/ubi8-init", "Digest": "sha256:53dfe24...", "RepoTags": [ "8.0.0-9", "8.0.0", "latest" ], "Created": "2019-05-13T20:50:11.437931Z", "DockerVersion": "1.13.1", "Labels": { "architecture": "x86_64", "authoritative-source-url": "registry.access.redhat.com", "build-date": "2019-05-13T20:49:44.207967", "com.redhat.build-host": "cpt-0013.osbs.prod.upshift.rdu2.redhat.com", "com.redhat.component": "ubi8-init-container", "description": "The Red Hat Enterprise Linux Init image is designed to be...
2.13. Tagging images
You can add names to images to make it more intuitive to understand what they contain. Tagging images can also be used to identify the target registry for which the image is intended. Using the podman tag
command, you essentially add an alias to the image that can consist of several parts. Those parts can include:
registryhost/username/NAME:tag
You can add just NAME if you like. For example:
# podman tag 474ff279782b myrhel8
In the previous example, the rhel8
image had an image ID of 474ff279782b. Using podman tag
, the name myrhel8
now also is attached to the image ID. So you could run this container by name (rhel8 or myrhel8) or by image ID. Notice that without adding a :tag to the name, it was assigned :latest as the tag. You could have set the tag to 8.0 as follows:
# podman tag 474ff279782b myrhel8:8.0
To the beginning of the name, you can optionally add a user name and/or a registry name. The user name is actually the repository on Docker.io that relates to the user account that owns the repository. Tagging an image with a registry name was shown in the "Tagging Images" section earlier in this document. Here’s an example of adding a user name:
# podman tag 474ff279782b jsmith/myrhel8 # podman images | grep 474ff279782b rhel8 latest 474ff279782b 7 days ago 139.6 MB myrhel8 latest 474ff279782b 7 months ago 139.6 MB myrhel8 7.1 474ff279782b 7 months ago 139.6 MB jsmith/myrhel8 latest 474ff279782b 7 months ago 139.6 MB
Above, you can see all the image names assigned to the single image ID.
2.14. Saving and loading images
If you want to save a container image you have stored locally, you can use podman save
to save the image to an archive file or directory and restore it later to another container environment. The archive you save can be in any of several different container image formats: docker-archive, oci-archive, oci-dir (directory with oci manifext type), or docker-dir (directory with v2s2 manifest type). After you save an image, you can store it or send it to someone else, then load
the image later to reuse it. Here is an example of saving an image as a tarball in the default docker-archive format:
# podman save -o myrsyslog.tar registry.redhat.io/rhel8/rsyslog:latest # file myrsyslog.tar myrsyslog.tar: POSIX tar archive
The myrsyslog.tar
file is now stored in your current directory. Later, when you are ready to reuse the tarball as a container image, you can import it to another podman environment as follows:
# podman load -i myrsyslog.tar # podman images REPOSITORY TAG IMAGE ID CREATED SIZE registry.redhat.io/rhel8/rsyslog latest 1f5313131bf0 7 weeks ago 235 MB
Instead of using save
and load
to store and reload an image, you can make a copy of a container instead, using podman export
and podman import
.
2.15. Removing images
To see a list of images that are on your system, run the podman images
command. To remove images you no longer need, use the podman rmi
command, with the image ID or name as an option. (You must stop any containers run from an image before you can remove the image.) Here is an example:
# podman rmi ubi8-init 7e85c34f126351ccb9d24e492488ba7e49820be08fe53bee02301226f2773293
You can remove multiple images on the same command line:
# podman rmi registry.redhat.io/rhel8/rsyslog support-tools 46da8e23fa1461b658f9276191b4f473f366759a6c840805ed0c9ff694aa7c2f 85cfba5cd49c84786c773a9f66b8d6fca04582d5d7b921a308f04bb8ec071205
If you want to clear out all your images, you could use a command like the following to remove all images from your local registry (make sure you mean it before you do this!):
# podman rmi -a 1ca061b47bd70141d11dcb2272dee0f9ea3f76e9afd71cd121a000f3f5423731 ed904b8f2d5c1b5502dea190977e066b4f76776b98f6d5aa1e389256d5212993 83508706ef1b603e511b1b19afcb5faab565053559942db5d00415fb1ee21e96
To remove images that have multiple names (tags) associated with them, you need to add the force option to remove them. For example:
# podman rmi -a A container associated with containers/storage, i.e. via Buildah, CRI-O, etc., may be associated with this image: 1de7d7b3f531 # podman rmi -f 1de7d7b3f531 1de7d7b3f531...