2 SLE Base Container Images #

There are four general purpose SLE BCI, and each container image comes with a minimum set of packages to keep its size low. You can use a general purpose SLE BCI either as a starting point for building custom container images, or as a platform for deploying specific software. For more information about general purpose SLE BCI, see Section 2.3, “BCI-Base, BCI-Minimal, BCI-Micro, and BCI-BusyBox”.

Language stack SLE BCI are built on top of the BCI-Base general-purpose SLE BCI. Each container image comes with the zypper stack and the free SLE_BCI repository. Additionally, each image includes most common tools for building and deploying applications in the specific language environment. This includes tools like a compiler or interpreter as well as the language specific package manager. For more information about language stack SLE BCI, see Section 2.4, “Language stack SLE Base Container Images”.

All container images, except for base, are currently classified as tech preview, and SUSE doesn't provide official support for them. This information is visible on the web on registry.suse.com. In addition to that, it is also indicated via the com.suse.supportlevel label whether a container image still has the tech preview status. You can use the skopeo and jq utilities to check the status of the desired SLE BCI as follows:

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

❯ skopeo inspect docker://registry.suse.com/bci/bci-base:15.4 | jq '.Labels["com.suse.supportlevel"]'
"l3"

In the example above, the com.suse.supportlevel label is set to techpreview in the bci-micro container image, indicating that the image still has the tech preview status. The bci-base container image on the other hand is fully l3 supported. Unlike like the general purpose SLE BCI, the language stack SLE BCI may not follow the lifecycle of the SLE distribution: they are supported as long as the respective language stack receives support. In other words, new versions of SLE BCI (indicated by the OCI tags) may be released during the lifecycle of a SLE Service Pack, while older versions may become unsupported. Refer to suse.com/lifecycle to find out whether the container in question is still under support.

Important: No updates beyond support period

A SLE Base Container Image is no longer updated after its support period ends. You will not receive any notification when that happens.

The SLE BCI are available as OCI-compatible container images directly from registry.suse.com and can be used like any other container image. For example, using one of the general purpose containers:

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

Alternatively, you can use SLE BCI in Dockerfile as follows:

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

You can then build container images using the docker build . or buildah bud . commands:

> 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!

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

This SLE BCI comes with the Zypper package manager and a free SLE-BCI repository. This allows you to install software available in the repository and customize the image during the build. The downside is the size of the image. It is the largest of the general-purpose SLE BCIs, so it is not always the best choice for a deployment image.

A variant of BCI-Base called BCI-Init comes with systemd preinstalled. The BCI-Init container image can be useful in scenarios requiring systemd for managing services in a single container.

Note: Using BCI-init with Docker or nerdctl

When using BCI-init container with Docker, you must use the following arguments for systemd to work correctly in the container:

docker run -ti --tmpfs /run -v /sys/fs/cgroup:/sys/fs/cgroup:rw --cgroupns=host registry.suse.com/bci/bci-init:latest

In case of nerdctl, the correct command is as follows:

nerdctl run -ti --env container=containerd --tmpfs /run -v /sys/fs cgroup:/sys/fs/cgroup:rw --cgroupns=host  registry.suse.com/bci bci-init:latest

To correctly shut down the container use the following command:

docker kill -s SIGRTMIN+3 CONTAINER_ID

This is a stripped-down version of the BCI-Base image. BCI-Minimal comes without Zypper, but it does have the RPM package manager installed. This significantly reduces the size of the image. However, while RPM can install and remove packages, it lacks support for repositories and automated dependency resolution. The BCI-Minimal image is therefore intended for creating deployment containers, and then installing the desired RPM packages inside the containers. Although you can install the required dependencies, you need to download and resolve them manually. However, this approach is not recommended as it is prone to errors.

This image is similar to BCI-Minimal but without the RPM package manager. The primary use case for the image is deploying static binaries produced externally or during multi-stage builds. As there is no straightforward way to install additional dependencies inside the container image, we recommend deploying a project using the BCI-Minimal image only when the final build artifact bundles all dependencies and has no external runtime requirements (like Python or Ruby).

Similar to BCI-Micro, the BCI-BusyBox image comes with the most basic tools only. However, these tools are provided by the BusyBox project. This has the benefit of further size reduction. Furthermore, the image contains no GPLv3 licensed software. When using the image, keep in mind that there are certain differences between the BusyBox tools and the GNU Coreutils. So scripts written for a system that uses GNU Coreutils may require modification to work with BusyBox.

For your reference, the list below provides an approximate size of each SLE BCI. Keep in mind that the provided numbers are rough estimations.

Language stack SLE BCI are built on top of BCI-Base. Below is an overview of the available language stack SLE BCIs.

The default package manager in SUSE Linux Enterprise is Zypper. Similar to APT in Debian and APK in Alpine Linux, Zypper offers a command-line interface for all package management tasks. Below is brief overview of commonly used container-related Zypper commands.

For more information on using Zypper, refer to https://documentation.suse.com/sles-15/html/SLES-all/cha-sw-cl.html#sec-zypper.

All the described commands use the --non-interactive flag to skip confirmations, since you cannot approve these manually during container builds. Keep in mind that you must use the flag with any command that modifies the system. Also note that --non-interactive is not a "yes to all" flag. Instead, --non-interactive confirms what is considered to be the intention of the user. For example, an installation command with the --non-interactive option fails if it needs to import new repository signing keys, as that is something that the user should verify themselves.

Here are a few examples that can give you an idea how to accomplish certain tasks in SLE BCI compared to Debian.

SUSE Linux Enterprise package naming conventions differ from Debian, Ubuntu, and Alpine, and they are closer to those of Red Hat Enterprise Linux. The main difference is that development packages of libraries (that is, packages containing headers and build description files) are named PACKAGE-devel in SUSE Linux Enterprise, as opposed to PACKAGE-dev as they are in Debian and Ubuntu. When in doubt, search for the package directly using the following command: docker run --rm registry.suse.com/bci/bci-base:OS_VERSION zypper search PACKAGE_NAME (replace OS_VERSION with the appropriate service version number, for example: 15.3 or 15.4).

Adding external repositories to a container or container image normally requires importing the GPG key used for signing the packages. This can be done with the rpm --import KEY_URL command. This adds the key to the RPM database, and all packages from the repository can be installed afterwards.