Jump to contentJump to page navigation: previous page [access key p]/next page [access key n]
documentation.suse.com / Container Guide / SLE Base Container Images
Applies to Container Guide

3 SLE Base Container Images

3.1 Introduction to SLE Base Container Images

SLE Base Container Images (SLE BCI) are minimal SLES 15-based images that you can use to develop, deploy, and share applications. There are two types of SLE BCIs:

  • General-purpose SLE BCIs can be used for building custom container images and for deploying applications.

  • Language stack SLE BCIs provide minimal environments for developing and deploying applications in specific programming languages.

3.2 Why SLE Base Container Images

SLE BCIs offer a platform for creating SLES-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 4000 packages available for the AMD64/Intel 64, AArch64, PowerPC, and IBM Z 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.

Security

Each package in the SLE_BCI repository undergoes security audits, and SLE BCIs benefit from the same mechanism of dealing with CVEs as SUSE Linux Enterprise Server. All discovered and fixed vulnerabilities are announced via e-mail, the dedicated CVE pages, and as OVAL and CVRF data. To ensure a secure supply chain, all container images are signed with Notary v1, Podman’s GPG signatures, and Sigstore Cosign.

Stability

Since SLE BCIs are based on SLES, they feature the same level of stability and quality assurance. Similar to SLES, SLE BCIs receive maintenance updates that provide bug fixes, improvements, and security patches.

Tooling and integration

SLE BCIs are designed to provide drop-in replacements for popular container images available on hub.docker.com. You can use the general-purpose SLE BCIs and the tools they put at your disposal to create custom container images, while the language stack SLE BCIs provide a foundation and the required tooling for building containerized applications.

Redistribution

SLE Base Container Images are covered by a permissive EULA that allows you to redistribute custom container images based on a SLE Base Container Image.

3.2.1 Highlights

  • SLE BCIs are fully compatible with SLES, but they do not require a subscription to run and distribute them.

  • SLE BCIs automatically run in FIPS-compatible mode when the host operating system is running in FIPS mode.

  • Each SLE BCI includes the RPM database, which makes it possible to audit the contents of the container image. You can use the RPM database to determine the specific version of the RPM package any given file belongs to. This allows you to ensure that a container image is not susceptible to known and already fixed vulnerabilities.

  • All SLE BCIs (except for those without Zypper) come with the container-suseconnect service. This gives containers that run on a registered SLES host access to the full SLES repositories. container-suseconnect is invoked automatically when you run Zypper for the first time, and the service adds the correct SLES repositories into the running container. On an unregistered SLES host or on a non-SLES host, the service does nothing.

Note
Note: SLE_BCI repository

There is a SLE_BCI repository for each SLE service pack. This means that SLE BCIs based on SP4 have access to the SLE_BCI repository for SP4, all SLE BCIs based on SP5 use the SLE_BCI repository for SP5, and so on. Each SLE_BCI repository contains all SLE packages except kernels, bootloaders, installers (including YaST), desktop environments, and hypervisors (such as KVM and Xen).

3.3 General-purpose SLE BCIs

There are four general purpose SLE BCIs, 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.

SUSE offers several general-purpose SLE BCIs that are intended as deployment targets or as foundations for creating customized images: SLE BCI-Base, SLE BCI-Minimal, SLE BCI-Micro, and SLE 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.

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

Table 3.1: Support matrix
FeaturesSLE BCI-BaseSLE BCI-MinimalSLE BCI-MicroSLE BCI-BusyBox

glibc

CA certificates

rpm database

coreutils

busybox

bash

rpm (binary)

zypper

3.3.1 SLE BCI-Base and SLE BCI-Init: When you need flexibility

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

3.3.2 SLE BCI-Minimal: When you do not need Zypper

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.

3.3.3 SLE BCI-Micro: When you need to deploy static binaries

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).

3.3.4 SLE BCI-BusyBox: When you need the smallest and GPLv3-free image

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.

3.3.5 Approximate sizes

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

  • SLE BCI-Base ~94 MB

  • SLE BCI-Minimal ~42 MB

  • SLE BCI-Micro ~26 MB

  • SLE BCI-BusyBox ~14 MB

3.4 Language stack SLE BCIs

Language stack SLE BCIs are built on top of the SLE 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.

Below is an overview of the available language stack SLE BCIs.

python
node
openjdk
openjdk-devel
ruby
golang
dotnet-runtime
dotnet-aspnet
dotnet-sdk

3.5 Important note on status and lifecycle

All container images, except for base, are currently classified as tech preview, and SUSE does not provide official support for them. This information is visible on the web on registry.suse.com. 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, has full L3 support. Unlike like the general purpose SLE BCIs, the language stack SLE BCIs may not follow the lifecycle of the SLES distribution: they are supported as long as the respective language stack receives support. In other words, new versions of SLE BCIs (indicated by the OCI tags) may be released during the lifecycle of a SLES 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
Important

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

3.6 Verifying SLE BCIs with Cosign

To verify a SLE BCI, run Cosign in the container. The command below fetches the signing key from the SUSE server and uses it to verify the latest BCI-Base container image.

> podman run --rm -it gcr.io/projectsigstore/cosign verify \
    --key https://ftp.suse.com/pub/projects/security/keys/container–key.pem \
    registry.suse.com/bci/bci-base:latest | tail -1 | jq

[
  {
    "critical": {
      "identity": {
        "docker-reference": "registry.suse.com/bci/bci-base"
      },
      "image": {
        "docker-manifest-digest": "sha256:52a828600279746ef669cf02a599660cd53faf4b2430a6b211d593c3add047f5"
      },
      "type": "cosign container image signature"
    },
    "optional": {
      "creator": "OBS"
    }
  }
]

The signing key can be used to verify all SLE BCIs, and it also ships with SLE 15 (the /usr/share/container-keys/suse-container-key.pem file).

You can also check BCI container images against rekor, the immutable tamper resistant ledger. For example:

> podman run --rm -it -e COSIGN_EXPERIMENTAL=1 gcr.io/projectsigstore/cosign \
    verify --key https://ftp.suse.com/pub/projects/security/keys/container–key.pem \
    registry.suse.com/bci/bci-base:latest | tail -1 | jq
[
  {
    "critical": {
      "identity": {
        "docker-reference": "registry.suse.com/bci/bci-base"
      },
      "image": {
        "docker-manifest-digest": "sha256:52a828600279746ef669cf02a599660cd53faf4b2430a6b211d593c3add047f5"
      },
      "type": "cosign container image signature"
    },
    "optional": {
      "creator": "OBS"
    }
  }
]

If verification fails, the output of the cosign verify command is similar to the one below.

Error: no matching signatures:
crypto/rsa: verification error
main.go:62: error during command execution: no matching signatures:
crypto/rsa: verification error

3.7 Understanding SLE BCIs

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.

3.7.1 Package manager

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.

Install packages

zypper --non-interactive install PACKAGE_NAME

Add a repository

zypper --non-interactive addrepo REPOSITORY_URL; zypper --non-interactive refresh

Update all packages

zypper --non-interactive update

Remove a package

zypper --non-interactive remove --clean-deps PACKAGE_NAME (the --clean-deps flag ensures that no longer required dependencies are removed as well)

Clean up temporary files

zypper clean

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.

3.7.2 Using container-suseconnect with SLE BCIs

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.

3.8 Using container-suseconnect

If you are running a registered SLES system with Docker, container-suseconnect automatically discovers your credentials and uses the subscription, without requiring any action on your part.

On openSUSE systems with Docker, you must copy the files /etc/SUSEConnect and /etc/zypp/credentials.d/SCCcredentials from a registered SLES machine to your local machine. The /etc/SUSEConnect file is required only if you are using RMT for managing your registration credentials.

3.8.1 Using container-suseconnect on non-SLE hosts or with Podman, Buildah, and nerdctl

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

3.8.2 Adding modules to a container or container image

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

3.8.3 Common patterns

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

Remove orphaned packages
  • Debian: apt-get autoremove -y

  • SLE BCI: Not required if you remove installed packages using the zypper --non-interactive remove --clean-deps PACKAGE_NAME

Obtain container’s architecture
  • Debian: dpkgArch="$(dpkg --print-architecture | awk -F- '{ print $NF }')"

  • SLE BCI: arch="$(uname -p|sed 's/x86_64/amd64/')"

Install packages required for compilation
  • Debian: apt-get install -y build-essential

  • SLE BCI: zypper -n in gcc gcc-c++ make

Verify GnuPG signatures
  • Debian: gpg --batch --verify SIGNATURE_URL FILE_TO_VERIFY

  • SLE BCI: zypper -n in dirmngr; gpg --batch --verify SIGNATURE_URL FILE_TO_VERIFY; zypper -n remove --clean-deps dirmngr; zypper -n clean

3.8.4 Package naming conventions

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).

3.8.5 Adding GPG signing keys

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.

3.9 Getting started with SLE Base Container Images

The SLE BCIs 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 a 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!