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.
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.
Features | SLE BCI-Base | SLE BCI-Minimal | SLE BCI-Micro | SLE 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.
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 MBSLE BCI-Minimal
~42 MBSLE BCI-Micro
~26 MBSLE 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
Ships with the python3 version from the tag and pip3, curl, git tools.
- node
Comes with nodejs version from the tag, npm and git. The yarn package manager can be installed with the
npm install -g yarn
command.
- openjdk
Ships with the OpenJDK runtime. Designed for deploying Java applications.
- openjdk-devel
Includes the development part of OpenJDK in addition to the OpenJDK runtime. Instead of Bash, the default entry point is the jshell shell.
- ruby
A standard development environment based on Ruby 2.5, featuring ruby, gem and bundler as well as git and curl.
- golang
Ships with the go compiler version specified in the tag.
- dotnet-runtime
URL: https://registry.suse.com/bci/dotnet-runtime/index.html
Includes the .NET runtime from Microsoft and the Microsoft .NET repository.
- dotnet-aspnet
Ships with the ASP.NET runtime from Microsoft and the Microsoft .NET repository.
- dotnet-sdk
Comes with the .NET and ASP.NET SDK from Microsoft as well as the Microsoft .NET repository.
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.
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 .
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!