3 SLE Base Container Images #

This SLE BCI comes with the Zypper package manager and the 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 SLE BCI-Base called SLE BCI-Init comes with systemd preinstalled. The SLE BCI-Init container image can be useful in scenarios requiring systemd for managing services in a single container.

Important: Using SLE BCI-init with Docker or nerdctl

When using SLE 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 SLE BCI-Base image. SLE 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 SLE 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 SLE 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 SLE BCI-Minimal image only when the final build artifact bundles all dependencies and has no external runtime requirements (like Python or Ruby).

Similar to SLE BCI-Micro, the SLE 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.

The default package manager in SLES 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/SUSE Linux Enterprise Server-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 must verify themselves.

container-suseconnect is a plugin available in all SLE BCIs that ship with Zypper. When the plugin detects the host’s SUSE Linux Enterprise Server registration credentials, it uses them to give the container access the SUSE Linux Enterprise repositories. This includes additional modules and previous package versions that are not part of the free SLE_BCI repository.

You need a registered SLES system to use container-suseconnect on non-SLE hosts or with Podman, Buildah, or with nerdctl. This can be a physical machine, a virtual machine, or the BCI-Base container with SUSEConnect installed and registered.

If you do not use RMT, copy /etc/zypp/credentials.d/SCCcredentials to the development machine. Otherwise, copy both the /etc/zypp/credentials.d/SCCcredentials and /etc/SUSEConnect files.

You can use the following command to obtain SCCcredentials (replace REGISTRATION_CODE with your SUSE Customer Center registration code).

Docker:

docker run --rm registry.suse.com/suse/sle15:latest bash -c \
    "zypper -n in SUSEConnect; SUSEConnect --regcode REGISTRATION_CODE; \
     cat /etc/zypp/credentials.d/SCCcredentials"

Podman:

podman run --rm registry.suse.com/suse/sle15:latest bash -c \
    "zypper -n in SUSEConnect; SUSEConnect --regcode REGISTRATION_CODE; \
     cat /etc/zypp/credentials.d/SCCcredentials"

nerdctl:

nerdctl run --rm registry.suse.com/suse/sle15:latest bash -c \
    "zypper -n in SUSEConnect; SUSEConnect --regcode REGISTRATION_CODE; \
     cat /etc/zypp/credentials.d/SCCcredentials"

If you are running a container based on a SLE BCI, mount SCCcredentials (and optionally /etc/SUSEConnect) in the correct destination. The following example shows how to mount SCCcredentials in the current working directory.

Docker:

docker run -v /path/to/SCCcredentials:/etc/zypp/credentials.d/SCCcredentials \
    --rm -it --pull=always registry.suse.com/bci/bci-base:latest

Podman:

podman run -v /path/to/SCCcredentials:/etc/zypp/credentials.d/SCCcredentials \
    --rm -it --pull=always registry.suse.com/bci/bci-base:latest

nerdctl:

nerdctl run -v /path/to/SCCcredentials:/etc/zypp/credentials.d/SCCcredentials \
    --rm -it --pull=always registry.suse.com/bci/bci-base:latest

Do not copy the SCCcredentials and SUSEConnect files into the container image to avoid inadvertently adding them to the final image. Use secrets instead, as they are only available to a single layer and are not part of the built image. To do this, put a copy of SCCcredentials (and optionally SUSEConnect) somewhere on the file system and modify the RUN instructions that invoke Zypper as follows:

FROM registry.suse.com/bci/bci-base:latest

RUN --mount=type=secret,id=SUSEConnect \
    --mount=type=secret,id=SCCcredentials \
    zypper -n in fluxbox

Docker and Buildah support mounting secrets via the --secret flag as shown below.

Docker:

docker build --secret=id=SCCcredentials,src=/path/to/SCCcredentials \
    --secret=id=SUSEConnect,src=/path/to/SUSEConnect .

Podman:

buildah bud --layers --secret=id=SCCcredentials,src=/path/to/SCCcredentials \
    --secret=id=SUSEConnect,src=/path/to/SUSEConnect .

Note

container-suseconnect runs automatically every time you invoke Zypper. If you are not using a registered SLES host, you may see the following error message:

> zypper ref
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.

Ignore the message, as it simply indicates that container-suseconnect was not able to retrieve your SUSE Customer Center credentials, and thus could not add the full SLE repositories. You still have full access to the SLE_BCI repository, and can continue using the container as intended.

container-suseconnect allows you to automatically add SLE Modules to a container or container image. What modules are added is determined by the environment variable ADDITIONAL_MODULES that includes a comma-separated list of the module names. In a Dockerfile, this is done using the ENV directive as follows:

FROM registry.suse.com/bci/bci-base:latest
ENV ADDITIONAL_MODULES sle-module-desktop-applications,sle-module-development-tools

RUN --mount=type=secret,id=SCCcredentials zypper -n in fluxbox && zypper -n clean

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

SLE package naming conventions differ from Debian, Ubuntu, and Alpine, and they are closer to those of RHEL. The main difference is that development packages of libraries (that is, packages containing headers and build description files) are named PACKAGE-devel in SLE, 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.