Although Docker Open Source Engine is a popular choice for working with images and containers, Podman provides a drop-in replacement for Docker that offers several advantages. While Chapter 11, Podman overview provides more information on Podman, this chapter offers a quick introduction to key concepts and a basic procedure for creating a container image and using it to run a container.

The basic Podman workflow is as follows:

Running a container, either on a local machine or cloud service, usually involves the following steps:

To run a container, you need an image. An image includes all dependencies needed to run the application. For example, the SLE base image contains the SLE distribution with a minimal package selection.

While it is possible to create an image from scratch, few applications would work in such an empty environment. Thus, using an existing base image is more practical in most situations. A base image has no parent, meaning it is not based on another image.

Although you can use a base image for running containers, the main purpose of base images is to serve as foundations for creating custom images that can run containers with specific applications, servers, services, and so on.

Both base and custom images are usually available through a repository of images called a registry. Unless a registry is explicitly specified, Podman pulls images from the Docker Hub registry. While you can fetch a base image manually, Podman can do that automatically when building a custom image.

To build a custom image, you need to create a special file called a Containerfile or Dockerfile, containing building instructions. For example, a Dockerfile can contain instructions to update the system software, install the desired application, open specific network ports, run commands, etc.

You can build images not only from base images, but also on top of custom images. So you can have an image consisting of multiple layers:

SLE Base Container Image (SLE BCI) are minimal SUSE Linux Enterprise Server 15-based images that you can use to develop, deploy, and share applications. There are two types of SLE BCI:

In addition to that, we will provide Application Container Images based on SLE BCI featuring popular containerized applications like Nginx, PostgreSQL, MariaDB and RMT.

skopeo inspect docker://registry.suse.com/bci/bci-micro:15.4 | jq '.Labels["com.suse.techpreview"]'
skopeo inspect docker://registry.suse.com/bci/bci-base:15.4 | jq '.Labels["com.suse.techpreview"]'
null

> podman run --rm -it registry.suse.com/bci/bci-base:15.4 grep '^NAME' /etc/os-release
NAME="SLES"

FROM registry.suse.com/bci/bci-base:15.4
RUN zypper -n in python3 && \
    echo "Hello Green World!" > index.html
ENTRYPOINT ["/usr/bin/python3", "-m", "http.server"]
EXPOSE 8000

> docker build .
Sending build context to Docker daemon  2.048kB
Step 1/4 : FROM registry.suse.com/bci/bci-base:15.4
 ---> e34487b4c4e1
Step 2/4 : RUN zypper -n in python3 &&     echo "Hello Green World!" > index.html
 ---> Using cache
 ---> 9b527dfa45e8
Step 3/4 : ENTRYPOINT ["/usr/bin/python3", "-m", "http.server"]
 ---> Using cache
 ---> 953080e91e1e
Step 4/4 : EXPOSE 8000
 ---> Using cache
 ---> 48b33ec590a6
Successfully built 48b33ec590a6
 
> docker run -p 8000:8000 --rm -d 48b33ec590a6
575ad7edf43e11c2c9474055f7f6b7a221078739fc8ce5765b0e34a0c899b46a
 
> curl localhost:8000
Hello Green World!

SLE BCIs offer a platform for creating SLE-based custom container images and containerized applications that can be distributed freely. SLE BCIs feature the same predictable enterprise lifecycle as SLES. The SLE_BCI 15 SP3 and SP4 repository (which is a subset of the SLE repository) gives SLE BCIs access to 4,000 packages available for the AMD64/Intel 64, AArch64, ppc64le, and s390x architectures. The packages in the repository have undergone quality assurance and security audits by SUSE. The container images are FIPS-compliant when running on a host in FIPS mode. In addition to that, SUSE can provide official support for SLE BCIs through SUSE subscription plans.

SUSE offers several general-purpose SLE Base Container Images that are intended as deployment targets or as foundations for creating customized images: BCI-Base, BCI-Minimal, BCI-Micro, and BCI-BusyBox. These images share the common SLES base, and none of them ship with a specific language or an application stack. All images feature the RPM database (even if the specific image does not include the RPM package manager) that can be used to verify the provenance of every file in the image. Each image includes the SLES certificate bundle, which allows the deployed applications to use the system's certificates to verify TLS connections.

2.3.1 Quick overview #

The table below provides a quick overview of the differences between BCI-Base, BCI-Minimal, BCI-Micro, and BCI-BusyBox.

If you have a working knowledge of containers, you will not have any difficulties using SLE BCIs. However, there are certain features that set SLE BCIs apart from similar offerings, like images based on Debian or Alpine Linux. And understanding the specifics can help you to get the most out of SLE BCIs in the shortest time possible.

Images are considered official only if they are built using the Internal Build Service.

There are no official SLE container images at https://build.opensuse.org, and the RPMs exported there are not identical to the internal ones. This means that it is not possible to build officially supported images at https://build.opensuse.org.

Docker Open Source Engine uses a client/server architecture. You can use the CLI client to communicate with the daemon. The daemon performs operations with containers and manages images locally or in registry. The CLI client can run on the same server as the host daemon or on a different machine. The CLI client communicates with the daemon by using network sockets. The architecture is shown in Figure 4.1, “Docker Open Source Engine architecture”.

Figure 4.1: Docker Open Source Engine architecture #

Prepare the host as described below. Before installing any Docker-related packages, you need to enable the Containers Module:

Note: Built-in Docker orchestration support

Starting with Docker Open Source Engine 1.12, container orchestration is now an integral part of Docker Open Source Engine. Even though this feature is available in SUSE Linux Enterprise Server, it is not supported by SUSE and is only provided as a technology preview. Use Kubernetes for container orchestration. For details, refer to the Kubernetes documentation.

The Docker daemon listens on a local socket accessible only by the root user and by the members of the docker group. The docker group is automatically created during package installation.

To allow a certain user to connect to the local Docker daemon, use the following command:

> sudo /usr/sbin/usermod -aG docker USERNAME

This allows the user to communicate with the local Docker daemon.

To give the containers access to the external network, enable the ipv4 ip_forward rule.

Docker Open Source Engine supports different storage drivers:

Since SUSE Linux Enterprise Server 12 onward, the Btrfs file system is used by default, which forces Docker Open Source Engine to use the btrfs driver.

It is possible to specify what driver to use by changing the value of the DOCKER_OPTS variable defined in the /etc/sysconfig/docker file. This can be done either manually or using YaST by browsing to the System / /etc/sysconfig Editor / System / Management / DOCKER_OPTS menu and entering the -s storage_driver string.

For example, to force the usage of the devicemapper driver, enter the following text:

DOCKER_OPTS="-s devicemapper"

Important: Mounting /var/lib/docker

It is recommended to mount /var/lib/docker on a separate partition or volume. In case of file system corruption, this would leave the operating system running Docker Open Source Engine unaffected.

If you choose the Btrfs file system for /var/lib/docker, it is strongly recommended to create a subvolume for it. This ensures that the directory is excluded from file system snapshots. If you do not exclude /var/lib/docker from snapshots, the file system will likely run out of disk space soon after you start deploying containers. In addition, a rollback to a previous snapshot will also reset the Docker database and images. For more information, see https://documentation.suse.com/sles-15/html/SLES-all/cha-snapper.html#sec-snapper-setup-customizing-new-subvolume.

All updates to the docker package are marked as interactive (that is, no automatic updates) to avoid accidental updates breaking running container workloads. In general, we recommend stopping all running containers before applying an update to Docker Open Source Engine.

To avoid data loss, we do not recommend having workloads rely on containers being start-able after an update to Docker Open Source Engine. Although it is technically possible to keep containers running during an update via the --live-restore option, experience has shown that such updates can introduce regressions. SUSE does not support this feature.

Docker Registry is an open source platform for storing and retrieving container images. You can avoid using Docker Hub by running a local instance of Docker Registry.

Docker Registry is also used by Docker Hub. However, from a user's point of view, Docker Hub consists of the following components:

The SUSE Registry provides a container image that makes it possible to run a local Docker Registry as a container. Before you start a container, create a config.yml file with the following example configuration:

version: 0.1
log:
  level: info
storage:
  filesystem:
    rootdirectory: /var/lib/docker-registry
http:
  addr: 0.0.0.0:5000

Also create an empty directory to map the /var/lib/docker-registry directory outside the container. This directory is used for storing container images.

Run the following command to pull the registry container image from the SUSE Registry and start a container that can be accessed on port 5000:

podman run -d --restart=always --name registry -p 5000:5000 \
-v /PATH/config.yml:/etc/docker/registry/config.yml \
-v /PATH/DIR:/var/lib/ \ docker-registry registry.suse.com/sles12/registry:2.6.2

To make it easier to manage the registry, create a corresponding system unit:

#  podman generate systemd registry >  \
 /etc/systemd/system/suse_registry.service

Enable and start the registry service, then verify its status:

# systemctl enable suse_registry.service
# systemctl start suse_registry.service
# systemctl status suse_registry.service

For more details about Docker Registry and its configuration, see the official documentation at https://docs.docker.com/registry/.

Docker Registry has two major limitations:

SUSE offers several official base container images that can be used as a starting point for building custom containers. Each SLE base image provides a minimal environment with a shell and package management.

Base images are available from https://registry.suse.com. For information about the SUSE Registry, see Section 7.3, “SUSE Registry”. The base images in the SUSE Registry all have the status General Availability (that is, they are suitable for production use) and LTSS releases of SLES 12 and SLES 15. SUSE Linux Enterprise base images in the SUSE Registry receive security updates and are covered by the SUSE support plans. For more information about these support plans, see Chapter 15, Compatibility and support plans.

SUSE container images have identifiers that provide information about their version, origin, and creation time. The individual identifiers listed below can be accessed after you pull a container image from the repository and run podman inspect on it.

The official SUSE Registry is available at https://registry.suse.com. It contains tested and updated SUSE Linux Enterprise base container images. All images in the SUSE Registry undergo a maintenance process. The images are built to contain the latest available updates and fixes. The SUSE Registry's Web user interface lists a subset of the available images.

Signatures for images available through SUSE Registry are stored in the Notary. You can verify the signature of a specific image using the following command:

docker trust inspect --pretty registry.suse.com/suseIMAGE:TAG

For example, the command docker trust inspect --pretty registry.suse.com/suse/sle15:latest verifies the signature of the latest SLE15 base image.

To automatically validate an image when you pull it, set the environment DOCKER_CONTENT_TRUST to 1. For example:

env DOCKER_CONTENT_TRUST=1 docker pull registry.suse.com/suse/sle15:latest

The container-diff tool can be used for analyzing and comparing container images. container-diff can examine images along several criteria, including the following:

You can inspect a single image or perform a diff operation on two images. container-diff supports Docker images located in both a local Docker daemon and a remote registry. It is also possible to use the tool with .tar, .tar.gz, and .tgz archives.

The container-diff package is part of the SUSE Linux Enterprise Server 15 SP4 Containers Module. Alternatively, it can be installed separately. For instructions on installing it, see the container-diff documentation.

To obtain a pre-built base image for SUSE Linux Enterprise 12 SP3 and later, use the following command:

      > docker pull registry.suse.com/suse/
      IMAGENAME

For example, for SUSE Linux Enterprise Server 15, the command is as follows:

> docker pull registry.suse.com/suse/sle15

sle2docker is not required, because the image is being pulled from the Docker Registry.

For information on obtaining specific base images, refer to Section 7.1, “SUSE Linux Enterprise base images”.

When the container image is ready, you can customize it as described in Section 8.2, “Customizing SLES container images”.

The pre-built images do not have any repositories configured and do not include any modules or extensions. They contain a zypper service that contacts either the SUSE® Customer Center or a Repository Mirroring Tool (RMT) server, according to the configuration of the SUSE Linux Enterprise Server host that runs the container. The service obtains the list of repositories available for the product used by the container image. You can also directly declare extensions in your Dockerfile. For more information, see Section 8.2.3, “Adding SLE extensions and modules to images”.

Note: SLE_BCI repository

Starting with SUSE Linux Enterprise 15 SP3, the default base image includes the SLE_BCI repository. This repository is only used when a container is built or runs on a non-registered SLES host, or when registration credentials are not made available to containers. The repository provides a subset of SUSE Linux Enterprise 15 SP3 packages useful for customizing SLES container images. The repository is available without any registration, and it is not supported.

You do not need to add any credentials to the container image, because the machine credentials are automatically injected into the /run/secrets directory in the container by the docker daemon. The same applies to the /etc/SUSEConnect file of the host system, which is automatically injected into the /run/secrets directory.

Note: Credentials and security

The contents of the /run/secrets directory are never included in a container image, hence there is no risk of your credentials leaking.

Note: Building images on systems registered with RMT

When the host system used for building container images is registered with RMT, the default behavior allows only building containers of the same code base as the host. For example, if your container host is an SLE 15 system, you can only build SLE 15-based images on that host by default. To build images for a different SLE version, for example, SLE 12 on an SLE 15 host, the host machine credentials for the target release can be injected into the container as outlined below. Please note that if the RMT server is using a self-signed certificate, the matching CA certificate needs to be added into the container at CA_TRUSTSTORE/rmt-server.pem for the certificate to be accepted.

When the host system is registered with SUSE Customer Center, this restriction does not apply.

Note: Building container images in on-demand SLE instances in the public cloud

Building container images on SLE instances that were launched as on-demand or pay-as-you-go instances on a public cloud (AWS, GCE, or Azure) requires additional steps. To install packages and updates, the “on-demand” public cloud instances are connected to the update infrastructure. This infrastructure is based on RMT servers operated by SUSE on the various public cloud providers.

Therefore, your machines need to locate the required services and authenticate with them. This can be done using the containerbuild-regionsrv service. This service is available in the public cloud images provided through the marketplaces of the various public cloud providers. Before building an image, this service must be started on the public cloud instance by running the following command:

> sudo systemctl start containerbuild-regionsrv

To start it automatically on system start-up, enable it:

> sudo systemctl enable containerbuild-regionsrv

The Zypper plug-ins provided by the SLE base images connect to this service and retrieve authentication details and information about which update server to talk to. For this to work, the container has to be built with host networking enabled, for example:

        > docker build --network host
        build-directory/

Since update infrastructure in the public clouds is based upon RMT, the restrictions on building SLE images for SLE versions different from the SLE version of the host apply as well (see Note: Building images on systems registered with RMT).

To obtain the list of repositories, use the following command:

> sudo zypper ref -s

This automatically adds all the repositories to the container. For each repository added to the system, a new file will be created under /etc/zypp/repos.d . The URLs of these repositories include an access token that automatically expires after 12 hours. To renew the token, run the command zypper ref -s . Including these files in a container image does not pose any security risk.

To use a different set of credentials, put a custom /etc/zypp/credentials.d/SCCcredentials file inside the container image. It contains the machine credentials that have the subscription you want to use. The same applies to the SUSEConnect file: To override the existing file on the host system running the container, add a custom /etc/SUSEConnect file inside the container image.

Now you can create a custom container image by using a Dockerfile as described in Section 8.2.1, “Creating a custom image for SLE 12 SP3 and later”.

If you want to move your application to a container, see Chapter 9, Creating application images.

After you have edited the Dockerfile , build the image by running the following command in the same directory in which the Dockerfile resides:

> docker build .

For more information about docker build options, see the official Docker documentation .

Note: Creating application images

For information about creating a Dockerfile for the application you want to run inside a container, see Chapter 9, Creating application images.

        FROM registry.suse.com/suse/sle15

        RUN zypper ref -s
        RUN zypper -n in vim

        FROM registry.suse.com/suse/sle15

        # Import the crt file of our private SMT server
        ADD http://smt.example.com/smt.crt /etc/pki/trust/anchors/smt.crt
        RUN update-ca-certificates

        RUN zypper ref -s
        RUN zypper -n in vim

        > docker inspect registry.suse.com/suse/sle15
        [...]
        "Labels": {
            "com.suse.sle.base.created": "2020-11-23T11:51:32.695975200Z",
            "com.suse.sle.base.description": "Image containing a minimal environment for containers based on SUSE Linux Enterprise Server 15 SP2.",
            "com.suse.sle.base.disturl": "obs://build.suse.de/SUSE:SLE-15-SP2:Update:CR/images/4a8871be8078bcef2e2417e2a98fc3a0-sles15-image",
            "com.suse.sle.base.reference": "registry.suse.com/suse/sle15:15.2.8.2.794",
            "com.suse.sle.base.title": "SUSE Linux Enterprise Server 15 SP2 Base Container",
            "com.suse.sle.base.url": "https://www.suse.com/products/server/",
            "com.suse.sle.base.vendor": "SUSE LLC",
            "com.suse.sle.base.version": "15.2.8.2.794",
            "org.openbuildservice.disturl": "obs://build.suse.de/SUSE:SLE-15-SP2:Update:CR/images/4a8871be8078bcef2e2417e2a98fc3a0-sles15-image",
            "org.opencontainers.image.created": "2020-11-23T11:51:32.695975200Z",
            "org.opencontainers.image.description": "Image containing a minimal environment for containers based on SUSE Linux Enterprise Server 15 SP2.",
            "org.opencontainers.image.title": "SUSE Linux Enterprise Server 15 SP2 Base Container",
            "org.opencontainers.image.url": "https://www.suse.com/products/server/",
            "org.opencontainers.image.vendor": "SUSE LLC",
            "org.opencontainers.image.version": "15.2.8.2.794",
            "org.opensuse.reference": "registry.suse.com/suse/sle15:15.2.8.2.794"
        },
        [...]

ENV ADDITIONAL_MODULES sle-module-desktop-applications,sle-module-development-tools

If your application needs a version of a package different from the package installed on the system, you can create a container image that includes the package version the application requires. The following example Dockerfile allows building an image based on an up-to-date version of SUSE Linux Enterprise Server with an older version of the example package:

FROM registry.suse.com/suse/sle15
LABEL maintainer=tux
RUN zypper ref && zypper in -f example-1.0.0-0
COPY application.rpm /tmp/
RUN zypper --non-interactive in /tmp/application.rpm
ENTRYPOINT ["/etc/bin/application"]
CMD ["-i"]

Build the image by running the following command in the directory that the Dockerfile resides in:

> docker build --tag tux_application:latest .

The Dockerfile example shown above performs the following operations during the docker build:

After a successful build of the tux_application image, you can start a container based on the new image using the following command:

> docker run -it --name application_instance tux_application:latest

Keep in mind that after closing the application, the container exits as well.

To run an instance using a different configuration, create a derived image and include the additional configuration with it. For example, if your application is called example and can be configured using the file /etc/example/configuration_example, you could use:

FROM registry.suse.com/suse/sle15 1
RUN zypper ref && zypper --non-interactive in example 2
ENV BACKUP=/backup 3
RUN mkdir -p $BACKUP 4
COPY configuration_example /etc/example/ 5
ENTRYPOINT ["/etc/bin/example"] 6

The above example Dockerfile performs the following operations:

You can now build the image. After a successful build, you can run a container based on the image you just created.

Docker Open Source Engine allows sharing data between host and a container by using volumes. You can specify a mount point directly in the Dockerfile. However, you cannot specify a directory on the host system in the Dockerfile, as the directory may not be accessible at build time. Find the mounted directory under /var/lib/docker/volumes/ on the host system.

Note: Discarding changes to the directory to be shared

After you specify a mount point by using the VOLUME instruction, all changes made to the directory with the RUN instruction are discarded. After the mount point is specified, the volume becomes a part of a temporary container, which is removed after a successful build. This means that for certain actions to take effect, they must be performed before specifying a mount point. For example, if you need to change permissions, do this before you specify the directory as a mount point in the Dockerfile.

Specify a particular mount point on the host system when running a container by using the -v option:

> docker run -it --name testing -v /home/tux/data:/data sles12sp4:latest /bin/bash

Note

The -v option overwrites the VOLUME instruction if you specify the same mount point in the container.

The following example image contains a Web server that reads Web content from the host's file system. The Dockerfile could look as follows:

FROM registry.suse.com/suse/sles12sp4
RUN zypper ref && zypper --non-interactive in apache2
COPY apache2 /etc/sysconfig/
RUN chown -R admin /data
EXPOSE 80
VOLUME /data
ENTRYPOINT ["apache2ctl"]

The example above installs the Apache Web server to the image and copies the entire configuration to the image. The data directory is owned by the admin user and is used as a mount point to store Web pages.

If your application needs to run in the background as a daemon, or as an application exposing ports for communication, you can run the container in the background.

An example Dockerfile for an application exposing a port looks as follows:

FROM registry.suse.com/suse/sle15 1
LABEL maintainer=tux 2
ADD etc/ /etc/zypp/ 3
RUN zypper refs && zypper refresh 4
RUN zypper --non-interactive in apache2 5
RUN echo "The Web server is running" > /srv/www/htdocs/test.html 6
# COPY data/* /srv/www/htdocs/ 7
EXPOSE 80 8
ENTRYPOINT ["/usr/sbin/httpd"]
CMD ["-D", "FOREGROUND"]

Note: Make sure the ports used by the container image are unused

To use port 80, make sure there is no other server software running on this port on the host.

To use the container, proceed as follows:

You can use the resulting container to serve your data with the Apache2 Web server by following these steps:

To view the published data, point a browser at http://localhost:80/test.html .

To avoid copying Web site data into the container, share a directory of the host with the container. For more information, see https://docs.docker.com/storage/volumes/ .

Containers normally exit when their main process finishes. For example, if a container starts a particular application, the container exits when the application quits. You can start the container again by running:

> docker start -ai <container name>

To remove unused containers:

> docker rm <container name>

To install Podman, run the command sudo zypper in podman. Then run podman --version to check whether Podman has been installed successfully.

To run Podman without root privileges, subuids and subgids must be assigned to the user running Podman. If there is no entry in the /etc/subuid file, add an entry using the following command:

>  sudo usermod --add-subuids 200000-201000 --add-subgids 200000-201000 $USER

To enable the change, reboot the machine or stop the session of the current user. To do the latter, run loginctl list-sessions | grep $USER and note the session ID. Then run loginctl kill-session SESSION_ID to terminate the session.

The command above defines a range of local UIDs to which the UIDs allocated to users inside the container are mapped on the host. Note that the ranges defined for different users must not overlap. It is also important that the ranges do not reuse the UID of an existing local user or group. By default, adding a user with the useradd command on SLES 15 automatically allocates subUID and subGID ranges.

Running a container with Podman in rootless mode on SUSE Linux Enterprise Server may fail, because the container needs read access to the SUSE Customer Center credentials. For example, running a container with the command podman run -it --rm registry.suse.com/suse/sle15 bash and then executing zypper ref results in the following error message:

Refreshing service 'container-suseconnect-zypp'.
Problem retrieving the repository index file for service 'container-suseconnect-zypp':
[container-suseconnect-zypp|file:/usr/lib/zypp/plugins/services/container-suseconnect-zypp] 
Warning: Skipping service 'container-suseconnect-zypp' because of the above error.
Warning: There are no enabled repositories defined.
Use 'zypper addrepo' or 'zypper modifyrepo' commands to add or enable repositories

To solve the problem, grant the current user the required access rights by running the following command on the host:

> sudo setfacl -m u:$USER:r /etc/zypp/credentials.d/*

Log out and log in again to apply the changes.

To give multiple users the required access, create a dedicated group using the groupadd GROUPNAME command. Then use the following command to change the group ownership and rights of files in the /etc/zypp/credentials.d/ directory.

> sudo chgrp GROUPNAME /etc/zypp/credentials.d/*
> sudo chmod g+r /etc/zypp/credentials.d/*

You can then grant a specific user write access by adding them to the created group.

Since Podman is compatible with Docker Open Source Engine, it features the same commands and options. For example, the podman pull command fetches a container image from a registry, while the podman build command is used to build images.

One of the advantages of Podman over Docker Open Source Engine is that Podman can be configured to search multiple registries. To make Podman search the SUSE Registry first and use Docker Hub as a fallback, add the following configuration to the /etc/containers/registries.conf file:

[registries.search]
registries = ["registry.suse.com", "docker.io"]

Similar to Docker Open Source Engine, Podman can run containers in an interactive mode, allowing you to inspect and work with an image. To run suse/sle15 in interactive mode, use the following command:

> podman run --rm -ti suse/sle15

Both Podman and Buildah can be used to build container images. While Podman makes it possible to build images using Dockerfiles, Buildah offers an expanded range of image building options and capabilities.

To install Buildah, run the command sudo zypper in buildah. Run the command buildah --version to check whether Buildah has been installed successfully.

If you already have Podman installed and set up for use in rootless mode, Buildah can be used in an unprivileged environment without any further configuration. If you need to enable rootless mode for Buildah, run the following command:

> sudo usermod --add-subuids 200000-201000 --add-subgids 200000-201000 $USER

This command enables rootless mode for the current user. After running the command, log out and log in again to enable the changes.

The command above defines a range of local UIDs on the host, onto which the UIDs allocated to users inside the container are mapped. Note that the ranges defined for different users must not overlap. It is also important that the ranges do not reuse the UID of any existing local users or groups. By default, adding a user with the useradd command on SLES 15 automatically allocates subUID and subGID ranges.

Note: Buildah in rootless mode

In rootless mode, Buildah commands must be executed in a modified user namespace of the user. To enter this user namespace, run the command buildah unshare. Otherwise, the buildah mount command will fail.

Instead of a special file with instructions, Buildah uses individual commands to build an image. Building an image with Buildah involves several steps: Run a container based on the specified image, edit the container (install packages, configure settings, etc.), configure the container options, and commit all changes into a new image. While this process may include additional steps, such as mounting the container's file system and working with it, the basic workflow logic remains the same.

The following example can give you a general idea of how to build an image with Buildah.

container=$(buildah from suse/sle15) 1
buildah run $container zypper up 2
buildah copy $container . /usr/src/example/ 3
buildah config --workingdir /usr/src/example $container
buildah config --port 8000 $container
buildah config --cmd "php -S 0.0.0.0:8000" $container 4
buildah config --label maintainer="Tux" $container
buildah config --label version="0.1" $container 5
buildah commit $container example 6
buildah rm $container 7

In addition to building and managing images, Podman makes it possible to work with pods. A pod is a group of one or more containers with shared resources, such as the network interface. A pod usually encapsulates an application composed of multiple containers into a single unit.

The podman pod can be used to create, delete, query, and inspect pods. To create a new pod, run the podman pod create command. This creates a pod with a random name. To list the existing pods, use the podman pod list command. To view a list of running pods, run podman ps -a --pod. The output of the command looks as follows (the STATUS and CREATED columns are omitted for brevity):

POD ID        NAME                # OF CONTAINERS   INFRA ID
399a120a09ff  suspicious_curie    1                 e57820093817

Notice that the command assigned a random name to the pod (suspicious_curie in this case). You can use the --name parameter to assign the desired name to a pod.

To examine the pod and its contents, run the podman ps -a --pod command and take a look at the output (the COMMAND, CREATED, STATUS, PORTS, and POD ID columns are omitted for brevity):

CONTAINER ID  IMAGE                 NAMES              PODNAME
e57820093817  k8s.gcr.io/pause:3.2  399a120a09ff-infra suspicious_curie

The created pod has an infra container identified by the k8s.gcr.io name. The purpose of this container is to reserve the namespaces associated with the pod and allow Podman to add other containers to the pod.

Using the podman run --pod command, you can run a container and add it to the desired pod. For example, the command below runs a container based on the suse/sle15 image and adds the container to the suspicious_curie pod:

podman run -d --pod suspicious_curie registry.suse.com/suse/sle15 sleep 1h

The command above adds a container that sleeps for 60 minutes and then exits. Run the podman ps -a --pod command again and you should see that the pod now has two containers.

Containers in a pod can be restarted, stopped, and started without affecting the overall status of the pod. For example, you can stop a container using the sudo podman stop CONTAINER_NAME command.

To stop the pod, use the podman pod stop command:

podman pod stop suspicious_curie

In case a custom Docker Open Source Engine container image built on top of the SLE base container image is not working as expected, the container-diff tool can help you analyze the image and collect information relevant for troubleshooting.

container-diff makes it possible to analyze image changes by computing differences between images and presenting the diff in a human-readable and actionable format. The tool can find differences in system packages, language-level packages, and files in a container image.

container-diff can handle local container images (using the prefix daemon://), images in a remote registry (using the prefix remote://), and images saved as .tar archives. You can use container-diff to compute the diff between a local version of an image and a remote version.

To install container-diff, run the sudo zypper in container-diff command.

> sudo container-diff analyze --type=history daemon://IMAGE
> sudo container-diff analyze --type=file daemon://IMAGE

> sudo container-diff diff daemon://IMAGE_1 daemon://IMAGE_2 --type=history

There are three guiding principles of SUSE container support.

For further information, refer to the Product Support Lifecycle page and the documentation available for specific container images on SUSE Registry.

Container images can have different support status, and they can have limited support. Refer to the appropriate SUSE Registry page for the further information about a specific container image.

The following support options (tiers) apply to SUSE Linux Enterprise Server containers on SUSE host environments.

The support options (tiers) covered below apply to the following container options:

Container images labeled as Tech Preview are provided by SUSE to give you an opportunity to test new technologies within your environment and share your feedback. If you test a technology preview, contact your SUSE representative to share your experiences and use cases. Your input is helpful for future development.

Technology previews come with the following limitations:

Container images are labeled as Tech Preview are marked as such at registry.suse.com. Additionally, container images that are technology previews include the com.suse.supportlevel="techpreview" label in the container image metadata. You can check whether the metadata includes the label using the docker inspect command, or an appropriate command in other container runtimes.