4 SLE Base Container Images #
4.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.
SLE Base Container Images are available from https://registry.suse.com. It contains tested and updated SLE 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. For information about the SUSE Registry, see Section 3.1, “SUSE Registry”.
SLE 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 conditions.
4.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.
4.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. See Section 5.2, “container-suseconnect” for more information.
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).
4.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 | ✓ | ╳ | ╳ | ╳ |
4.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
To correctly shut down the container use the following command:
> docker kill -s SIGRTMIN+3 CONTAINER_ID
4.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.
4.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).
4.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.
4.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
4.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.
- rust
Ships with the Rust compiler and the Cargo package manager.
- 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.
4.5 Application SLE BCIs #
Application SLE BCIs are SLE BCI-Base container images that include specific applications, such as the PostgreSQL database and the Performance Co-Pilot a system-level performance analysis toolkit. Application SLE BCIs are available in the dedicated section of SUSE Registry.
4.6 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.
4.6.1 SLE BCI labels #
SLE BCIs feature the following labels.
- com.suse.image-type
Shows whether this is a pure SLE BCI or an application container based on another SLE BCI.
- com.suse.eula
Marks which section of the SUSE EULA applies to the container image.
- com.suse.release-stage
Indicates the current release stage of the image.
prototype
Indicates that the container image is in the ALP prototype phase.alpha
Prevents the container image from appearing in the registry.suse.com Web interface even if it is available there. The value also indicates the alpha quality of the container image.beta
Lists the container image in the Beta Container Images section of the registry.suse.com Web interface and adds the Beta label to the image. The value also indicates the beta quality of the container image.released
Indicates that the container image is released and suitable for production use.
- com.suse.supportlevel
Shows the support level for the container.
l2
Problem isolation, which means technical support designed to analyze data, reproduce customer problems, isolate problem areas, and provide a resolution for problems not resolved by Level 1, or prepare for Level 3.l3
Problem resolution, which means technical support designed to resolve problems by engaging engineering to resolve product defects which have been identified by Level 2 Support.techpreview
The image is unsupported and intended for use in proof-of-concept scenarios.unsupported
No support is provided for the image.
- com.suse.lifecycle-url
Points to the https://www.suse.com/lifecycle/ page that offers information about the lifecycle of the image.
4.6.1.1 Working with SLE BCI labels #
Starting with SLE 15 SP3, all base container images include information such as a build time stamp and description. This information is provided in the form of labels attached to the base images, and is therefore available for derived images and containers.
Here is an example of the Labels information shown by podman inspect
:
podman inspect registry.suse.com/suse/sle15 [...] "Labels": { "com.suse.bci.base.created": "2023-01-26T22:15:08.381030307Z", "com.suse.bci.base.description": "Image for containers based on SUSE Linux Enterprise Server 15 SP4.", "com.suse.bci.base.disturl": "obs://build.suse.de/SUSE:SLE-15-SP4:Update:CR/images/1477b070ae019f95b0f2c3c0dce13daf-sles15-image", "com.suse.bci.base.eula": "sle-bci", "com.suse.bci.base.image-type": "sle-bci", "com.suse.bci.base.lifecycle-url": "https://www.suse.com/lifecycle", "com.suse.bci.base.reference": "registry.suse.com/suse/sle15:15.4.27.14.31", "com.suse.bci.base.release-stage": "released", "com.suse.bci.base.source": "https://sources.suse.com/SUSE:SLE-15-SP4:Update:CR/sles15-image/1477b070ae019f95b0f2c3c0dce13daf/", "com.suse.bci.base.supportlevel": "l3", "com.suse.bci.base.title": "SLE BCI 15 SP4 Base Container Image", "com.suse.bci.base.url": "https://www.suse.com/products/server/", "com.suse.bci.base.vendor": "SUSE LLC", "com.suse.bci.base.version": "15.4.27.14.31", "com.suse.eula": "sle-bci", "com.suse.image-type": "sle-bci", "com.suse.lifecycle-url": "https://www.suse.com/lifecycle", "com.suse.release-stage": "released", "com.suse.sle.base.created": "2023-01-26T22:15:08.381030307Z", "com.suse.sle.base.description": "Image for containers based on SUSE Linux Enterprise Server 15 SP4.", "com.suse.sle.base.disturl": "obs://build.suse.de/SUSE:SLE-15-SP4:Update:CR/images/1477b070ae019f95b0f2c3c0dce13daf-sles15-image", "com.suse.sle.base.eula": "sle-bci", "com.suse.sle.base.image-type": "sle-bci", "com.suse.sle.base.lifecycle-url": "https://www.suse.com/lifecycle", "com.suse.sle.base.reference": "registry.suse.com/suse/sle15:15.4.27.14.31", "com.suse.sle.base.release-stage": "released", "com.suse.sle.base.source": "https://sources.suse.com/SUSE:SLE-15-SP4:Update:CR/sles15-image/1477b070ae019f95b0f2c3c0dce13daf/", "com.suse.sle.base.supportlevel": "l3", "com.suse.sle.base.title": "SLE BCI 15 SP4 Base Container Image", "com.suse.sle.base.url": "https://www.suse.com/products/server/", "com.suse.sle.base.vendor": "SUSE LLC", "com.suse.sle.base.version": "15.4.27.14.31", "com.suse.supportlevel": "l3", "org.openbuildservice.disturl": "obs://build.suse.de/SUSE:SLE-15-SP4:Update:CR/images/1477b070ae019f95b0f2c3c0dce13daf-sles15-image", "org.opencontainers.image.created": "2023-01-26T22:15:08.381030307Z", "org.opencontainers.image.description": "Image for containers based on SUSE Linux Enterprise Server 15 SP4.", "org.opencontainers.image.source": "https://sources.suse.com/SUSE:SLE-15-SP4:Update:CR/sles15-image/1477b070ae019f95b0f2c3c0dce13daf/", "org.opencontainers.image.title": "SLE BCI 15 SP4 Base Container Image", "org.opencontainers.image.url": "https://www.suse.com/products/server/", "org.opencontainers.image.vendor": "SUSE LLC", "org.opencontainers.image.version": "15.4.27.14.31", "org.opensuse.reference": "registry.suse.com/suse/sle15:15.4.27.14.31" }, [...]
All labels are shown twice to ensure that the information in derived images about the original base image is still visible and not overwritten.
Use Podman and the jq tool (sudo zypper in jq
) to retrieve labels of a local image. The following
command lists all labels and only the labels information of the bci-base:15.4
image:
podman inspect registry.suse.com/bci/bci-base:15.4 | \ jq '.[0].Labels'
It is also possible to retrieve the value of a specific label:
podman inspect registry.suse.com/bci/bci-base:15.4 | \ jq '.[0].Labels["com.suse.sle.base.supportlevel"]'
The preceding command retrieves the value of the com.suse.sle.base.supportlevel
label.
The skopeo tool makes it possible to examine labels of an image without pulling it first. For example:
skopeo inspect docker://registry.suse.com/bci/bci-base:15.4 | \ jq '.Labels' skopeo inspect docker://registry.suse.com/bci/bci-base:15.4 | \ jq '.Labels["com.suse.sle.base.supportlevel"]'
4.6.2 Tags #
Tags are used to refer to images. A tag forms a part of the image’s name. Unlike labels, tags can be freely defined, and they are usually used to indicate a version number.
If a tag exists in multiple images, the newest image is used. The image maintainer decides which tags to assign to the container image.
The conventional tag format is repository name
: image version specification
(usually version number). For example, the tag for the latest published image of PRODUCTNAME 15 SP2 would be suse/sle15:15.2
.
4.7 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
4.8 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.
4.8.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.
4.8.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.
Refer to Section 5.2, “container-suseconnect” for more information on how to use the repository for SLES, openSUSE, and non-SLES hosts.
4.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
4.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
).
4.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.
4.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!