尽管 Docker 开源引擎是用于处理映像和容器的流行解决方案，但具备诸多优势的 Podman 可以直接取代 Docker。有关 Podman 的详细信息，请参见第 6 章 “Podman 概述”。本章将会简要介绍重要概念，以及创建容器映像并使用 Podman 来运行容器的基本过程。

基本的 Podman 工作流程如下：

在本地计算机或云服务中运行容器通常涉及以下步骤：

要运行容器，需要有一个映像。映像包含运行应用程序所需的全部依赖项。例如，SLE SLE BCI 基本映像包含选择了极少量软件包的 SLE 发行套件。

尽管可以从头开始创建映像，但很少有应用程序能够在这种空环境中正常运行。因此，在大多数情况下，使用现有的基本映像更为可行。基本映像没有父项，也就是说，它不以其他映像为基础。

尽管您可以使用基本映像来运行容器，但基本映像的主要用途是充当创建自定义映像的基础，自定义映像可以运行包含特定应用程序、服务器、服务等的容器。

基本映像和自定义映像通常都可以通过称作“注册表”的映像储存库获得。除非显式指定了注册表，否则 Podman 将从 openSUSE 和 Docker Hub 注册表中提取映像。尽管您可以手动提取基本映像，但 Podman 可以在构建自定义映像时自动提取基本映像。

要构建自定义映像，必须创建一个名为 Containerfile 或 Dockerfile 的特殊文件，其中包含构建指令。例如，Dockerfile 可以包含用于更新系统软件、安装所需应用程序、打开特定网络端口、运行命令等的指令

您不仅可以基于基本映像构建映像，而且可以基于自定义映像构建映像。因此您可以构建由多个层组成的映像。有关详细信息，请参考第 11 章 “创建自定义容器映像”。

SUSE 注册表 是 SLE 基本容器映像的官方来源。其中包含已经过测试、更新和认证的 SLE 基本容器映像。SUSE 注册表中的所有映像会定期重构建，以包含更新和修复。SUSE 注册表的 Web 用户界面列出了一部分可用映像：基本容器映像、语言容器映像、应用程序容器映像、SUSE SUSE Linux Enterprise Server 映像，以及不再享受一般支持的版本。Web UI 还提供了每个映像的附加信息，包括发布日期、支持级别、大小、映像摘要以及映像中的软件包。

Docker 是一个用于创建和管理容器的系统。其核心是 Docker Open Source Engine—，这是一种轻量级虚拟化解决方案，可在单台主机上同时运行多个容器。Docker 容器是使用 Dockerfile 构建的。

Podman 表示 Pod Manager 工具。它是一个无守护程序的容器引擎，用于在 Linux 系统上开发、管理和运行 Open Container Initiative (OCI) 容器，可以直接取代 Docker。Podman 是推荐用于 SLES 的容器运行时。有关 Podman 的一般介绍，请参见第 6 章 “Podman 概述”。

Buildah 是用于构建 OCI 容器映像的实用程序。它是 Podman 的补充工具。事实上，podman build 命令使用 Buildah 来执行容器映像构建。Buildah 可让您从头开始构建映像，也可使用 Dockerfile 从现有映像构建映像。使用 Buildah 命令行工具和基于 OCI 的底层技术（例如 containers/image 和 containers/storage）构建的 OCI 映像具有可移植性，因此可以在 Docker 开源引擎环境中运行。有关安装和使用 Buildah 的信息，请参见第 14 章 “Buildah 概述”。

skopeo 是一个命令行实用程序，用于管理、检查容器映像和映像储存库并为其签名。skopeo 可用于检查远程与本地容器注册表中的容器和储存库。skopeo 可以在不同的存储后端之间复制容器映像。skopeo 包含在 SLES 的 Basesystem Module 中。

Helm 是 Kubernetes 软件包管理器，它是使用图表在 Kubernetes 群集上部署容器化应用程序的事实标准。Helm 可用于在一个或多个容器中安装、更新和去除应用程序。它还可以处理关联的资源，如配置、存储卷等。例如，可以使用它来部署 RMT 服务器（有关详细信息，请参见 RMT 文档）。

Distribution 是一个开源的注册表实现，用于通过 OCI 分发规范存储和分发容器映像。它为构建大规模注册表解决方案或运行简单专用注册表提供简单、安全且可缩放的基础。Distribution 还可以镜像 Docker Hub，但不会镜像任何其他私有注册表。

Open Build Service (OBS) 提供用于构建和存储 RPM 软件包（包括不同的容器格式）的免费基础架构。OBS Container Registry 提供由 OBS 构建的所有容器映像的详细列表，使用命令完成将映像提取到本地环境的操作。您可以根据特定需求修改 OBS openSUSEcontainer image templates，这是创建您自己的容器分支的最简单方法。您可以使用 Dockerfile 通过 Docker 工具从现有映像构建容器映像。也可以使用 KIWI 映像构建解决方案从头开始构建映像。

此处提供了有关如何在 OBS 上构建映像的说明。

SUSE 容器映像称为 SUSE Linux Enterprise 基本容器映像 (SLE BCI)，它们是仅有的官方 SUSE 容器映像，具体请参见第 4 章 “SLE 基本容器映像”。它们未在 https://build.opensuse.org 上提供，导出到该网站的 RPM 与内部 RPM 不同。这意味着无法在 https://build.opensuse.org 上构建官方支持的映像。

有关 SLE BCI 的详细信息，请参见第 4 章 “SLE 基本容器映像”。

KIWI Next Generation 是用于构建映像的多功能工具。除容器映像、常规安装 ISO 映像以及适用于虚拟机的映像之外，KIWI 还可构建通过 PXE 或 Vagrant 盒子引导的映像。KIWI 中的主要构建基块是映像 XML 说明，一个包含 config.xml 或 .kiwi 文件以及脚本或配置数据的目录。使用 KIWI 创建映像的过程是完全自动化的，不需要任何用户交互。映像创建过程所需的任何信息由主要配置文件 config.xml 提供。可以使用 config.sh 和 images.sh 脚本自定义映像。KIWI 是 Open Build Service (OBS) 的核心引擎。

注意

请务必区分 KIWI NG（当前版本 9.20.9）及其不再维护的旧版本（7.x.x 或更早版本，现在称为 KIWI Legacy）。

有关如何安装 KIWI 以及使用它来构建映像的具体信息，请参见 KIWI 文档。KIWI GitHub 储存库上提供了一系列示例映像说明。

KIWI 手册页提供了使用该工具的相关信息。要访问手册页，请安装 kiwi-man-pages 软件包。

SLE 基本容器映像 (SLE BCI) 是基于 SLES 15 的精简映像，可用于开发、部署和共享应用程序。SLE BCI 有两种类型：

https://registry.suse.com 上提供了 SLE 基本容器映像。其中包含已经过测试和更新的 SLE 基本容器映像。SUSE 注册表中的所有映像都要经历一个维护过程。构建的映像包含最新可用的更新和修复。SUSE 注册表的 Web 用户界面列出了一部分可用映像。有关 SUSE 注册表的信息，请参见第 3.1 节 “SUSE 注册表”。

SUSE 注册表中的 SLE 基本映像会收到安全更新，并涵盖在 SUSE 支持计划中。有关这些支持计划的详细信息，请参见第 15 章 “兼容性和支持条件”。

SLE BCI 提供一个平台用于创建基于 SLES 的自定义容器映像和可任意分发的容器化应用程序。SLE BCI 具有与 SLES 相同的可预测企业生命周期。SLE_BCI 15 SP3 和 SP4 储存库（SLE 储存库的子集）使 SLE BCI 能够访问 4000 个适用于 AMD64/Intel 64、AArch64、PowerPC 和 IBM Z 体系结构的软件包。储存库中的软件包享有 SUSE 的质量保证并接受其安全审计。以 FIPS 模式在主机上运行时，容器映像符合 FIPS 规范。除此之外，SUSE 还可以通过 SUSE 订阅计划为 SLE BCI 提供官方支持。

4.2.1 高亮显示数 #

 

• SLE BCI 与 SLES 完全兼容，但无需订阅即可运行和分发。

• 当主机操作系统以 FIPS 模式运行时，SLE BCI 会自动以 FIPS 兼容模式运行。

• 每个 SLE BCI 都包含 RPM 数据库，因此可以审计容器映像的内容。您可以使用 RPM 数据库来确定任意给定文件所属的 RPM 软件包的特定版本。这可以确保容器映像不容易受到已知漏洞和已修复漏洞的影响。

• 所有 SLE BCI（不包含 Zypper 的 SLE BCI 除外）都附带 container-suseconnect 服务。因此，在已注册的 SLES 主机上运行的容器可以访问完整的 SLES 储存库。当您首次运行 Zypper 时会自动调用 container-suseconnect，该服务会将正确的 SLES 储存库添加到正在运行的容器中。在未注册的 SLES 主机或非 SLES 主机上，该服务不执行任何操作。有关更多信息，请参见第 5.2 节 “container-suseconnect”。

注意：SLE_BCI 储存库

每个 SLE 服务包都有一个 SLE_BCI 储存库。这意味着，基于 SP4 的 SLE BCI 可以访问 SP4 的 SLE_BCI 储存库，所有基于 SP5 的 SLE BCI 可以使用 SP5 的 SLE_BCI 储存库，依此类推。每个 SLE_BCI 储存库包含除内核、引导加载程序、安装程序（包括 YaST）、桌面环境和超级管理程序（例如 KVM 和 Xen）之外的其他所有 SLE 软件包。

注意：请求缺失的软件包

如果 SLE_BCI 储存库不包含您所需的软件包，您可以采取两种做法。现有的 SUSE 客户可以提交功能请求。普通用户可以通过在 Bugzilla 中创建问题来请求创建软件包。

有四个通用 SLE BCI，其中每个容器映像附带最少量的一组软件包，以保持较小的大小。可将通用 SLE BCI 用作构建自定义容器映像的起点，或用作部署特定软件的平台。

SUSE 提供多个通用 SLE BCI，这些 BCI 可用作部署目标或用作创建自定义映像的基础：BCI-Base、BCI-Minimal、BCI-Micro 和 BCI-BusyBox。这些映像采用通用的 SLES 基础，并且它们都不随附特定的语言或应用程序堆栈。所有映像具有 RPM 数据库（即使特定的映像不包含 RPM 软件包管理器），该数据库可用于校验映像中每个文件的来源。每个映像包含 SLES 证书分发包，已部署的应用程序可以通过该分发包使用系统的证书来校验 TLS 连接。

下表简要概述了 SLE BCI-Base、SLE BCI-Minimal、SLE BCI-Micro 和 SLE BCI-BusyBox 之间的差异。

4.3.1 SLE BCI-Base 和 SLE BCI-Init：需要灵活性时 #

 

此 SLE BCI 附带 Zypper 软件包管理器和免费的 SLE_BCI 储存库。这样，您便可以安装储存库中提供的软件并在构建期间自定义映像。该映像的缺点在于其大小。它是最大的通用 SLE BCI，因此它不一定是最佳的部署映像选项。

名为 SLE BCI-Init 的 SLE BCI-Base 变体中预安装了 systemd。在需要通过 systemd 在单个容器中管理服务的方案中，SLE BCI-Init 容器映像可能很有用。

重要：将 SLE BCI-init 与 Docker 配合使用

将 SLE BCI-init 容器与 Docker 配合使用时，必须使用以下参数才能使 SYSTEMD 在容器中正常工作：

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

要正确关闭容器，请使用以下命令：

> docker kill -s SIGRTMIN+3 CONTAINER_ID

语言堆栈 SLE BCI 构建在 BCI-Base 通用 SLE BCI 的基础之上。每个容器映像附带 SLE_BCI 堆栈和免费的 SLE_BCI 储存库。此外，每个映像包含用于在特定语言环境中构建和部署应用程序的最常用工具。这包括编译器或解释器等工具，以及特定于语言的软件包管理器。

下面是可用语言堆栈 SLE BCI 的概览。

应用程序 SLE BCI 是基于 SLE BCI 的容器映像，其中包含特定的应用程序，例如 PostgreSQL 数据库和 Performance Co-Pilot（系统级性能分析工具包）。应用程序 SLE BCI 在 SUSE 注册表的专门部分中提供。

除基本映像以外的其他所有容器映像目前都分类为技术预览，SUSE 不为它们提供官方支持。此信息会在 registry.suse.com 网站上显示。此外，还会通过 com.suse.supportlevel 标签来指示某个容器映像是否仍处于技术预览状态。可以使用 skopeo 和 jq 实用程序检查所需 SLE BCI 的状态，如下所示：

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

在上面的示例中，bci-micro 容器映像中的 com.suse.supportlevel 标签设置为 techpreview，表示该映像仍处于技术预览状态。相比之下，bci-base 容器映像则享受完全的 L3 支持。与通用 SLE BCI 不同，语言堆栈 SLE BCI 可能不遵循 SLES 分发包的生命周期：只要相应的语言堆栈能够获得支持，语言堆栈 SLE BCI 就受支持。换言之，新版本的 SLE BCI（由 OCI 标记表示）可能会在 SLES Service Pack 的生命周期内发布，而旧版本可能不受支持。请访问 suse.com/lifecycle 确定相关容器是否仍受支持。

重要

SLE 基本容器映像在其支持周期结束后将不再更新。如果发生这种情况，您不会收到任何通知。

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"
        },
[...]

podman inspect registry.suse.com/bci/bci-base:15.4 | \
jq '.[0].Labels'

podman inspect registry.suse.com/bci/bci-base:15.4 | \
jq '.[0].Labels["com.suse.sle.base.supportlevel"]'

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"]'

要校验 SLE BCI，请在容器中运行 Cosign。以下命令从 SUSE 服务器提取签名密钥，并使用它来校验最新的 BCI 基本容器映像。

> 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"
    }
  }
]

签名密钥可用于校验所有 SLE BCI，SLE 15 也附带了签名密钥（/usr/share/container-keys/suse-container-key.pem 文件）。

您还可以对照不可变防篡改帐本 rekor 检查 BCI 容器映像。例如：

> 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"
    }
  }
]

如果校验失败，则 cosign verify 命令的输出如下所示。

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

如果您在容器方面有一定的实践知识，那么使用 SLE BCI 就不会有任何难度。但是，SLE BCI 有一些与类似产品（例如基于 Debian 或 Alpine Linux 的映像）不同的特性。了解细节有助于在尽可能短的时间内发挥 SLE BCI 的最大作用。

可以直接从 registry.suse.com 以 OCI 兼容容器映像的形式获取 SLE BCI，并可以像使用任何其他容器映像一样使用它们。例如，使用某个通用容器：

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

或者，可以如下所示在 Dockerfile 中使用 SLE BCI：

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

然后可以使用 docker build . 或 buildah bud . 命令构建容器映像：

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

要在 SUSE Linux Enterprise Server 上使用容器，首先必须启用 SLE Containers 模块。此模块包含围绕容器的软件包，其中包括容器引擎以及与容器相关的核心工具，例如本地注册表。有关 SLE 模块的详细信息，请参见 https://documentation.suse.com/sles/html/SLES-all/article-modules.html。

常规 SLES 订阅包含免费的 SLE Containers 模块。

> sudo SUSEConnect -p sle-module-containers/15.4/x86_64

要安装 Podman，请确保启用 SLE Containers 模块（参见第 5.1 节 “SLE Containers 模块”），并运行命令 sudo zypper in podman。然后运行 podman info 来检查 Podman 是否已成功安装。

默认情况下，Podman 会尝试以当前用户的身份启动容器。对于非特权用户，这意味着以无 root 权限模式启动容器。默认已为 SLE 中所有新建的用户启用了对无 root 权限容器的支持，无需执行额外的步骤。

如果 Podman 无法以无 root 权限模式启动容器，请检查 /etc/subuid 中是否存在当前用户的对应项：

 ❯ grep $(id -nu) /etc/subuid
user:10000:65536

如果未找到该项，请通过以下命令添加所需的子 UID 和子 GID 项：

> sudo usermod --add-subuids 100000-165535 --add-subgids 100000-165535 $(id -nu)

要启用更改，请重引导计算机或停止当前用户的会话。要执行后一项操作，请运行 loginctl list-sessions | grep USER 并记下会话 ID。然后运行 loginctl kill-session SESSION_ID 以停止会话。

以上 usermod 命令会在主机上定义一系列本地 UID，分配给容器中的用户的 UID 将映射到这些 UID。请注意，为不同用户定义的范围不得重叠。同样重要的是，这些范围不能重复使用现有本地用户或组的 UID。默认情况下，在 SLES 15 中使用 useradd 命令添加用户会自动分配子 UID 和子 GID 范围。

使用包含 Podman 的无 root 权限容器时，建议使用 cgroups v2。与 cgroups v2 相比，cgroups v1 在功能方面存在限制。例如，cgroups v1 允许每个用户修改所有现有的控制组，而不仅仅是他们自己的控制组。此外，Podman 无法使用 cgroups v1 和 systemd 日志驱动程序正确读取容器日志。要启用 cgroups v2，请将以下内容添加到内核命令行：systemd.unified_cgroup_hierarchy=1

在 SLES 上以无 root 权限模式运行包含 Podman 的容器可能会失败，因为容器需要对 SCC 身份凭证拥有读取访问权限。例如，使用命令 podman run -it --rm registry.suse.com/suse/sle15 bash 运行容器，然后执行 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.
Warning: There are no enabled repositories defined.
Use 'zypper addrepo' or 'zypper modifyrepo' commands to add or enable repositories

要解决该问题，请在主机上运行以下命令为当前用户授予所需的访问权限：

> sudo setfacl -m u:$(id -nu):r /etc/zypp/credentials.d/*

注销然后重新登录以应用更改。

要为多个用户授予所需的访问权限，请使用 groupadd GROUPNAME 命令创建一个专用组。然后使用以下命令更改 /etc/zypp/credentials.d/ 目录中的文件的组所有权和权限。

> sudo chgrp GROUPNAME /etc/zypp/credentials.d/*
> sudo chmod g+r /etc/zypp/credentials.d/*

之后，您便可以通过将特定用户添加到这个创建的组来为其授予写入访问权限。

❯ podman run --rm -it registry.suse.com/bci/bci-base id
uid=0(root) gid=0(root) groups=0(root)

❯ podman run --userns=keep-id --rm -it registry.suse.com/bci/bci-base id
uid=1000(user) gid=1000(users) groups=1000(users)

 ❯ podman run --rm -it -v $(pwd):/share/ registry.suse.com/bci/bci-base stat /share/
  File: /share/
  Size: 318             Blocks: 0          IO Block: 4096   directory
Device: 2ch/44d Inode: 3506170     Links: 1
Access: (0755/drwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2023-05-03 12:52:18.636392618 +0000
Modify: 2023-05-03 12:52:17.178380923 +0000
Change: 2023-05-03 12:52:17.178380923 +0000
 Birth: 2023-05-03 12:52:15.852370288 +0000

 ❯ podman run --userns=keep-id --rm -it -v $(pwd):/share/ registry.suse.com/bci/bci-base stat /share/
  File: /share/
  Size: 318             Blocks: 0          IO Block: 4096   directory
Device: 2ch/44d Inode: 3506170     Links: 1
Access: (0755/drwxr-xr-x)  Uid: ( 1000/     user)   Gid: ( 1000/     users)
Access: 2023-05-03 12:52:18.636392618 +0000
Modify: 2023-05-03 12:52:17.178380923 +0000
Change: 2023-05-03 12:52:17.178380923 +0000
 Birth: 2023-05-03 12:52:15.852370288 +0000

 ❯ podman unshare bash

 ❯ id
uid=0(root) gid=0(root) groups=0(root),65534(nobody)

sysctl net.ipv4.ip_unprivileged_port_start=0

sysctl -w net.ipv4.ip_unprivileged_port_start=0

 ❯ sudo systemctl start podman.socket

可以任意标记映像（即设置自定义名称），目的主要是设置一个更直观的名称或者标识特定的映像。

从 registry.suse.com 提取 bci-base 映像：

localhost:~ # podman pull registry.suse.com/bci/bci-base
Trying to pull registry.suse.com/bci/bci-base:latest...
Getting image source signatures
Copying blob bf6ca87723f2 done
Copying config 34578a383c done
Writing manifest to image destination
Storing signatures
34578a383c7b6fdcb85f90fbad59b7e7a16071cf47843688e90fe20ff64a684

列出提取的映像：

localhost:~ # podman images
REPOSITORY                      TAG         IMAGE ID      CREATED        SIZE
registry.suse.com/bci/bci-base  latest      34578a383c7b  22 hours ago   122 MB

将 bci-base 映像重命名为 my-base：

podman tag 34578a383c7b my-base

podman images
REPOSITORY                      TAG         IMAGE ID      CREATED        SIZE
registry.suse.com/bci/bci-base  latest      34578a383c7b  22 hours ago   122 MB
localhost/my-base               latest      34578a383c7b  22 hours ago   122 MB

将自定义标记添加到 my-base（假设这是映像版本 1）

podman tag 34578a383c7b my-base:1

podman images
REPOSITORY                      TAG         IMAGE ID      CREATED        SIZE
registry.suse.com/bci/bci-base  latest      34578a383c7b  22 hours ago   122 MB
localhost/my-base               latest      34578a383c7b  22 hours ago   122 MB
localhost/my-base               1           34578a383c7b  22 hours ago   122 MB

请注意，默认标记 latest 仍然存在。

与 Docker 开源引擎类似，Podman 能够以交互模式运行容器，使您可以检查和处理映像。要以交互模式运行 suse/sle15，请使用以下命令：

> podman run --rm -ti suse/sle15

Podman 可以从 Dockerfile 构建映像。podman build 命令的行为与 docker build 相同，并且接受相同的选项。

Podman 的配套工具 Buildah 提供了另一种构建映像的方式。有关 Buildah 的更多信息，请参见第 14 章 “Buildah 概述”。

请按如下所述准备主机。在安装任何与 Docker 相关的软件包之前，需要启用 Containers Module：

注意：内置 Docker 编制支持

从 Docker Open Source Engine 1.12 开始，容器编制现在是 Docker 开源引擎不可或缺的组成部分。尽管此功能已在 SUSE Linux Enterprise Server 中提供，但 SUSE 并不提供对它的支持，此功能仅作为技术预览提供。使用 K8S 进行容器编制。有关细节，请参见 Kubernetes documentation。

> sudo /usr/sbin/usermod -aG docker USERNAME

要使容器能够访问外部网络，请启用 ipv4 ip_forward 规则。

Docker 开源引擎支持不同的存储驱动程序：

从 SUSE Linux Enterprise Server 12 开始，默认会使用 Btrfs 文件系统，这会强制 Docker 开源引擎使用 btrfs 驱动程序。

可以通过更改 /etc/sysconfig/docker 文件中定义的 DOCKER_OPTS 变量值来指定要使用的驱动程序。可以手动进行这种更改，也可以在 YaST 中浏览到系统 > /etc/sysconfig 编辑器 > 系统 > 管理 > DOCKER_OPTS 菜单，然后输入 -s storage_driver 字符串进行更改。

例如，要强制使用 devicemapper 驱动程序，请输入以下文本：

DOCKER_OPTS="-s devicemapper"

重要：挂载 /var/lib/docker

建议在单独的分区或卷上挂载 /var/lib/docker。这样，当文件系统损坏时，运行 Docker 开源引擎的操作系统将不受影响。

如果您为 /var/lib/docker 选择了 Btrfs 文件系统，强烈建议为其创建一个子卷。这可以确保从文件系统快照中排除该目录。如果不从快照中排除 /var/lib/docker，当您开始部署容器后，文件系统可能很快就会耗尽磁盘空间。此外，回滚到以前的快照也会重置 Docker 数据库和映像。有关详细信息，请参见 https://documentation.suse.com/sles/html/SLES-all/cha-snapper.html#sec-snapper-setup-customizing-new-subvolume。

对docker 软件包进行的所有更新都会标记为“交互式”（即，不是自动更新），以避免意外的更新破坏正在运行的容器工作负载。我们建议在对 Docker 开源引擎应用更新之前停止所有正在运行的容器。

为避免数据丢失，我们不建议让工作负载依赖于容器在 Docker 开源引擎更新后保持可启动状态。尽管从技术上讲可以通过 --live-restore 选项使容器能够在更新期间保持运行，但经验表明，这种更新可能会导致性能下降。SUSE 不支持此功能。

Docker 注册表是用于存储和检索容器映像的开源平台。可以通过运行 Docker 注册表的本地实例来避免使用 Docker Hub。

Docker Hub 也会使用 Docker 注册表。但从用户的角度而言，Docker Hub 由以下组件构成：

SUSE 注册表提供了一个容器映像，可用于将本地 Docker 注册表作为容器运行。在启动容器之前，请创建包含以下示例配置的 config.yml 文件：

version: 0.1
log:
  level: info
storage:
  filesystem:
    rootdirectory: /var/lib/docker-registry
http:
  addr: 0.0.0.0:5000

另外，创建一个空目录以映射容器外部的 /var/lib/docker-registry 目录。此目录用于存储容器映像。

运行以下命令以从 SUSE 注册表提取注册表容器映像，并启动一个可以通过端口 5000 访问的容器：

podman run -d --restart=always --name registry -p 5000:5000 \
-v /PATH/config.yml:/etc/docker/registry/config.yml \
-v /PATH/DIR:/var/lib/ \ docker-registry registry.suse.com/sles12/registry:2.6.2

为了更方便地管理注册表，请创建相应的系统单元：

> sudo podman generate systemd registry >  \
 /etc/systemd/system/suse_registry.service

启用并启动注册表服务，然后校验其状态：

> sudo systemctl enable suse_registry.service
> sudo systemctl start suse_registry.service
> sudo systemctl status suse_registry.service

有关 Docker 注册表及其配置的更多细节，请参见 https://docs.docker.com/registry/ 上的官方文档。

Docker 注册表存在两项主要限制：

通过 SUSE 注册表提供的映像签名存储在 Notary 中。您可以使用以下命令校验特定映像的签名：

docker trust inspect --pretty registry.suse.com/suse/IMAGE:TAG

例如，命令 docker trust inspect --pretty registry.suse.com/suse/sle15:latest 校验最新 SLE15 基本映像的签名。

要在提取映像时自动验证该映像，请将环境变量 DOCKER_CONTENT_TRUST 设置为 1。例如：

env DOCKER_CONTENT_TRUST=1 docker pull registry.suse.com/suse/sle15:latest

要校验 SLE BCI 映像，请在容器中运行 Cosign。以下命令从 SUSE 服务器提取签名密钥，并使用它来校验最新的 BCI 基本容器映像。

> 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"
    }
  }
]

签名密钥可用于校验所有 SLE BCI 容器映像。SUSE Linux Enterprise 15 随附了签名密钥（/usr/share/container-keys/suse-container-key.pem 文件）。

您还可以对照不可变防篡改帐本 rekor 检查 SLE BCI 容器映像。例如：

> 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"
    }
  }
]

如果校验失败，则 cosign verify 命令的输出如下所示。

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

要获取 SLE 12 SP5 和更高版本的预构建基本映像，请使用以下命令：

> podman pull registry.suse.com/suse/IMAGENAME

例如，对于 SUSE Linux Enterprise Server 15，命令如下：

> podman pull registry.suse.com/suse/sle15

有关获取特定基本映像的信息，请参见第 4.1 节 “SLE 基本容器映像简介”。

容器映像准备就绪后，您可以按照第 11.2 节 “自定义 SLES 容器映像”中所述对其进行自定义。

如果您的应用程序所需的软件包版本不同于系统上安装的软件包版本，您可以创建一个包含应用程序所需软件包版本的容器映像。下面的示例 Dockerfile 允许使用较旧的 example 软件包版本构建基于最新 SUSE Linux Enterprise Server 版本的映像：

FROM registry.suse.com/suse/sle15
LABEL maintainer=EXAMPLEUSER_PLAIN
RUN zypper ref && zypper in -f example-1.0.0-0
COPY application.rpm /tmp/
RUN zypper --non-interactive in /tmp/application.rpm
ENTRYPOINT ["/etc/bin/application"]
CMD ["-i"]

通过在 Dockerfile 所在的目录中运行以下命令来构建映像：

> podman build --tag tux_application:latest .

上面显示的 Dockerfile 示例会在 podman build 运行期间执行以下操作：

成功构建 tux_application 映像后，可使用以下命令启动基于新映像的容器：

> podman run -it --name application_instance tux_application:latest

请记住，关闭应用程序后，容器也会退出。

要运行使用不同配置的实例，请创建派生映像并在其中包含附加配置。以下示例使用文件 /etc/example/configuration_example 配置名为 example 的应用程序：

FROM registry.suse.com/suse/sle15 1
RUN zypper ref && zypper --non-interactive in example 2
ENV BACKUP=/backup 3
RUN mkdir -p $BACKUP 4
COPY configuration_example /etc/example/ 5
ENTRYPOINT ["/etc/bin/example"] 6

以上示例 Dockerfile 执行以下操作：

Podman 允许使用卷在主机和容器之间共享数据。您可以直接在 Dockerfile 中指定挂载点。但是，不能在 Dockerfile 中指定主机系统上的目录，因为该目录在构建时可能无法访问。在主机系统上的 /var/lib/docker/volumes/ 下找到挂载的目录。

注意：丢弃对要共享的目录所做的更改

使用 VOLUME 指令指定挂载点后，将会丢弃使用 RUN 指令对目录所做的所有更改。指定挂载点后，该卷将成为临时容器的一部分，而成功构建后会去除该临时容器。这表示要使某些操作生效，必须在指定挂载点之前执行这些操作。例如，如果您需要更改权限，请先进行更改，然后再在 Dockerfile 中将目录指定为挂载点。

运行容器时，使用 -v 选项指定主机系统上的特定挂载点：

> podman run -it --name testing -v /home/tux/data:/data sles12sp4:latest /bin/bash

注意

如果您在容器中指定相同的挂载点，-v 选项会重写 VOLUME 指令。

以下 Dockerfile 示例将构建一个映像，其中包含一个从主机文件系统读取 Web 内容的 Web 服务器。

FROM registry.suse.com/suse/sles12sp4
RUN zypper ref && zypper --non-interactive in apache2
COPY apache2 /etc/sysconfig/
RUN chown -R admin /data
EXPOSE 80
VOLUME /data
ENTRYPOINT ["apache2ctl"]

上面的示例将 Apache Web 服务器安装到映像，并将整个配置复制到该映像。data 目录由 admin 用户拥有，用作存储网页的挂载点。

如果您的应用程序需要作为守护程序在后台运行，或者作为公开通讯端口的应用程序运行，您可以在后台运行容器。

公开端口的应用程序的示例 Dockerfile 如下所示：

FROM registry.suse.com/suse/sle15 1
LABEL maintainer=EXAMPLEUSER_PLAIN 2
ADD etc/ /etc/zypp/ 3
RUN zypper refs && zypper refresh 4
RUN zypper --non-interactive in apache2 5
RUN echo "The Web server is running" > /srv/www/htdocs/test.html 6
# COPY data/* /srv/www/htdocs/ 7
EXPOSE 80 8
ENTRYPOINT ["/usr/sbin/httpd"]
CMD ["-D", "FOREGROUND"]

注意

要使用端口 80，请确保主机中没有任何其他服务器软件在此端口上运行。

要使用容器，请执行以下操作：

您可以执行以下步骤来使用生成的容器通过 Apache2 Web 服务器提供数据：

要查看已发布的数据，请在浏览器中指向 http://localhost:80/test.html。

为了避免将网站数据复制到容器中，请与容器共享主机的某个目录。有关详细信息，请参见 https://docs.docker.com/storage/volumes/。

现在您已充分了解如何在桌面或服务器上处理容器，接下来可以进一步了解如何在生产环境中使用容器。在生产环境中，您可能需要管理多个容器，包括单个容器主机或多个容器主机上的容器。要管理多个容器，必须将一个或多个容器分组到一个 Pod 中，使它们能够共享存储和网络资源；同时，必须制定有关如何部署和运行容器的规范。简而言之，Pod 会将包含多个容器的应用程序封装成一个单元。 Pod 概念是由 Kubernetes 引入的。不过，Podman（代表 Pod Manager）使用与 Kubernetes 相同的定义。

使用所述的方法意味着容器映像永远不会更新。可以通过将 --pull=always 标志添加到单元文件中的 ExecStart= 项来解决该问题。但请注意，这会增加容器的启动时间，并在每次重启动时更新映像。后一种行为还意味着，容器映像更新可能会因新造成的 bug 而导致容器在安排的维护时段之外不可用。

Podman 中的 auto-update 子命令提供了一种可行的解决方法。将标签 io.containers.autoupdate=registry 添加到容器，使 Podman 在运行 podman auto-update 时从注册表中提取容器映像的新版本。这样，就可以在所需的时间使用一条命令更新所有容器映像，而且不会增加 systemd 单元的启动时间。

可以通过将行 --label "io.containers.autoupdate=registry" \ 添加到容器 systemd 单元文件的 ExecStart= 项来启用自动更新功能。对于 NGINX 示例，请如下所示修改 ~/.config/systemd/user/container-web.service：

ExecStart=/usr/bin/podman run \
        --cidfile=%t/%n.ctr-id \
        --cgroups=no-conmon \
        --rm \
        --sdnotify=conmon \
        --replace \
        -d \
        --name web \
        --label "io.containers.autoupdate=registry" \
        -p 8080:80 docker.io/nginx

重新装载守护程序并重启动容器后，执行更新试运行（此操作很可能不会报告任何更新）：

❯ podman auto-update --dry-run
UNIT                   CONTAINER           IMAGE            POLICY      UPDATED
container-web.service  87d263489307 (web)  docker.io/nginx  registry    false

最好进行外部测试，以确保映像更新在一般情况下可以安全部署。如果您对我们的容器映像的质量有信心，可以通过启用 podman-auto-update.timer 来让 Podman 自动定期应用映像更新：

# just for the current user
❯ systemctl --user enable podman-auto-update.timer
Created symlink /home/user/.config/systemd/user/timers.target.wants/podman-auto-update.timer → /usr/lib/systemd/user/podman-auto-update.timer.
# or as root
❯ sudo systemctl enable podman-auto-update.timer
Created symlink /etc/systemd/system/timers.target.wants/podman-auto-update.timer → /usr/lib/systemd/system/podman-auto-update.timer.

某些应用程序需要依赖于多个容器才能正常运行，例如 Web 前端、后端服务器和数据库。Docker compose 是在一台计算机上部署多容器应用程序的流行工具。虽然 Podman 并不原生支持 compose 命令，但在大多数情况下，可以将 compose 文件移植到某个 Podman Pod 和多个容器。

以下示例在单个 Pod 中部署 Drupal 和 PostgreSQL 容器，并通过 systemd 单元管理这些容器。首先，创建一个公开 Drupal Web 界面的新 Pod：

❯ podman pod create -p 8080:80 --name drupal
736cab072c49e68ad368ba819e9117be13ef8fa048a2eb88736b5968b3a19a64

创建该 Pod 后，启动 Drupal 前端及其包含的 PostgreSQL 数据库：

❯ podman run -d --name drupal-frontend --pod drupal docker.io/drupal
ffd2fbd6d445e63fb0c28abb8d25ced78f819211d3bce9d6174fe4912d89f0ca

❯ podman run -d --name drupal-pg --pod drupal \
      -e POSTGRES_DB=drupal \
      -e POSTGRES_USER=user \
      -e POSTGRES_PASSWORD=pass \
      docker.io/postgres:11
a4dc31b24000780d9ffd81a486d0d144c47c3adfbecf0f7effee24a00273fcde

这会生成三个正在运行的容器：Drupal Web 界面、PostgreSQL 数据库和 Pod 的基础架构容器。

❯ podman ps
CONTAINER ID  IMAGE                                    COMMAND               CREATED             STATUS                 PORTS                 NAMES
2948fa1476c6  localhost/podman-pause:4.2.0-1660228937                        2 minutes ago       Up About a minute ago  0.0.0.0:8080->80/tcp  736cab072c49-infra
ffd2fbd6d445  docker.io/library/drupal:latest          apache2-foregroun...  About a minute ago  Up About a minute ago  0.0.0.0:8080->80/tcp  drupal-frontend
a4dc31b24000  docker.io/library/postgres:11            postgres              40 seconds ago      Up 41 seconds ago      0.0.0.0:8080->80/tcp  drupal-pg

为 Pod 创建 systemd 单元的方式类似于为单个容器创建此单元：

❯ podman generate systemd --name --new --files drupal
/home/user/pod-drupal.service
/home/user/container-drupal-frontend.service
/home/user/container-drupal-pg.service
❯ mv *service ~/.config/systemd/user/
❯ systemctl daemon-reload --user

由于 Podman 知道哪些容器属于 drupal Pod 以及如何调用这些容器的 systemd 单元，因此它可以正确地将依赖项添加到 Pod 的单元文件中。这意味着，当您启动或停止 Pod 时，systemd 会确保该 Pod 中的所有容器自动启动或停止。

要检查 systemd 的依赖项处理，请先停止 drupal Pod，然后校验主机上当前是否未运行任何容器：

❯ podman pod stop drupal
736cab072c49e68ad368ba819e9117be13ef8fa048a2eb88736b5968b3a19a64
❯ podman pod rm drupal
736cab072c49e68ad368ba819e9117be13ef8fa048a2eb88736b5968b3a19a64
❯ podman ps -a
CONTAINER ID  IMAGE       COMMAND     CREATED     STATUS      PORTS       NAMES

通过 systemctl start --user pod-drupal.service 启动 drupal Pod，systemd 会启动该 Pod 中的容器：

❯ systemctl start --user pod-drupal.service
❯ podman ps
CONTAINER ID  IMAGE                                    COMMAND               CREATED        STATUS            PORTS                 NAMES
d1589d3ac68b  localhost/podman-pause:4.2.0-1660228937                        5 seconds ago  Up 5 seconds ago  0.0.0.0:8080->80/tcp  ca41b505bd13-infra
a49bea53c20c  docker.io/library/postgres:11            postgres              4 seconds ago  Up 5 seconds ago  0.0.0.0:8080->80/tcp  drupal-pg
dc9dca018dad  docker.io/library/drupal:latest          apache2-foregroun...  4 seconds ago  Up 5 seconds ago  0.0.0.0:8080->80/tcp  drupal-frontend

Kubernetes 是一个开源容器编制引擎，用于自动化容器化应用程序的部署、缩放和管理。该开源项目由云原生计算基金会 (CNCF) 主办。

凭借其多样化的特性和功能并受到大型开发者社区的支持，Kubernetes 已成为大多数容器即服务平台的首选标准。它提供广泛的且至关重要的功能来部署生产级的容器，其中包括高可用性、生命周期管理、存储、安全性和网络。

Podman 和 Buildah 都可用于构建容器映像。虽然 Podman 可让用户使用 Dockerfile 构建映像，但 Buildah 提供的映像构建选项和功能更广泛。

要安装 Buildah，请运行命令 sudo zypper in buildah。运行命令 buildah --version 检查是否已成功安装 Buildah。

如果您已安装 Podman 并将其设置为在无 root 权限模式下使用，则无需进行进一步配置，就能在非特权环境中使用 Buildah。如果需要为 Buildah 启用无 root 权限模式，请运行以下命令：

> sudo usermod --add-subuids 100000-165535 --add-subgids 100000-165535 USER

此命令将为当前用户启用无 root 权限模式。运行该命令后，注销然后重新登录即可启用更改。

以上命令会在主机上定义一系列本地 UID，分配给容器中的用户的 UID 将映射到这些 UID。请注意，为不同用户定义的范围不得重叠。同样重要的是，这些范围不能重复使用任何现有本地用户或组的 UID。默认情况下，在 SLES 15 SP4 中使用 useradd 命令添加用户会自动分配 subUID 和 subGID 范围。

注意：无 root 权限模式下的 Buildah

在无 root 权限模式下，Buildah 命令必须在用户的已修改用户名称空间中执行。要进入此用户名称空间，请运行命令 buildah unshare。否则，buildah mount 命令将会失败。

Buildah 使用单独的命令来构建映像，而不使用包含指令的特殊文件。使用 Buildah 构建映像涉及以下步骤：

虽然此过程可能包括其他步骤（例如，挂载并使用容器的文件系统），但基本的工作流程逻辑是相同的。

下面的示例可让您大致了解如何使用 Buildah 构建映像。

container=$(buildah from suse/sle15) 1
buildah run $container zypper up 2
buildah copy $container . /usr/src/example/ 3
buildah config --workingdir /usr/src/example $container 4
buildah config --port 8000 $container
buildah config --cmd "php -S 0.0.0.0:8000" $container
buildah config --label maintainer="Tux" $container 5
buildah config --label version="0.1" $container
buildah commit $container example 6
buildah rm $container 7

术语“支持”指两个不同的概念：a) 功能或组合（例如主机和容器）的技术支持，以及 b) SUSE 向 SUSE 客户提供的企业支持。根据 https://www.suse.com/products/terms_and_conditions.pdf，企业支持要求订阅 SUSE 产品。技术支持如下所述。

15.1.1 对 SLES 主机的支持 #

 

请查阅以下支持和兼容性矩阵，确保所需的主机系统和容器组合与系统兼容且受支持。

表 15.1︰ 支持矩阵 #

 

主机 ↓ 容器映像 →	SLES 12	SLES 15
SLES 12 SP5	✓	❋
SLES 15	✓	✓
SLE Micro	✓	✓

✓ 完全支持

❋ 有限支持（请参见“有限支持说明”）

重要：有限支持说明

由于容器化应用程序可能导致系统调用在主机内核中不可用这一事实，SUSE 为 SLES 12 SP5 主机上运行的基于 SLES PRODUCT-GA 的容器提供有限支持。为了避免潜在的风险和兼容性问题，SUSE 建议为容器和主机使用相同的服务包版本。

BCI 支持以下体系结构：X86-64、AARCH64、POWER 和 ZSERIES。容器体系结构必须与主机的体系结构相匹配。不匹配的容器和主机方案不受支持。

在大多数情况下，如果应用程序或其依赖项不直接与特定于内核版本的数据结构（ioctl、/proc、/sys、routing、iptables、nftables、eBPF 等）或模块（KVM、OVS、SystemTap 等）交互，则所有 SLE 容器预期都可互操作。仅在非特权用户所需的最常见方案中提供对 ioctl 的支持和对 /proc 的访问。

有三项 SUSE 容器支持的指导原则。

有关更多信息，请参见 Product Support Lifecycle 页面，以及适用于 SUSE 注册表中特定容器映像的文档。

容器映像可以处于不同的支持状态，因此对它们的支持可能有限制。有关特定容器映像的更多信息，请参见相应的 SUSE 注册表页面。

以下支持选项对 SUSE 主机环境中的 SLES 容器有效。

SUSE 提供的容器和主机环境完全受支持。这也适用于所有受支持的产品，包括一般支持和 Long Term Service Pack Support (LTSS)。

签署了联合工程协作协议的合作伙伴容器和主机环境受到完全支持。此层级适用于协议涵盖的容器、主机环境以及支持（包括标准支持和 LTSS）下的所有产品。

虽然基于 SUSE 的容器受到完全支持，主机环境中的问题仍必须由主机环境供应商负责处理。SUSE 支持来自 SUSE 基本容器的组件，还支持来自 SUSE 储存库的软件包。容器中的其他组件和应用程序不在 SUSE 支持的范围内。基于 SLE BCI 或 SLE BCI 储存库的内容构建派生容器不需要订阅。要构建包含完整 SLE 系列中的软件包的容器，您需要购买订阅，使自己能够访问包含这些软件包的储存库。

上面未提到的任何容器和主机环境享受有限支持。相关细节请与 SUSE 支持团队讨论，该团队负责就问题和建议的备用解决方案进行会审。在任何其他情况下，主机环境中的问题都必须由主机环境供应商负责处理。

标记为技术预览的容器映像由 SUSE 提供，让您有机会在环境中测试新技术并分享反馈。如果您测试了技术预览，请联系 SUSE 代表，以分享您的经验和用例。您的反馈对于我们的未来开发非常有帮助。

技术预览存在以下限制：

容器映像标记为技术预览，并且在 registry.suse.com 上也采用这种标记。此外，作为技术预览提供的容器映像在容器映像元数据中包含 com.suse.supportlevel="techpreview" 标签。可以使用 docker inspect 命令或其他容器运行时中的相应命令检查元数据是否包含该标签。

如果基于 SLE 基本容器映像构建的自定义 Docker 开源引擎容器映像无法按预期方式工作，您可以借助container-diff 工具来分析该映像并收集用于查错的相关信息。

container-diff 可以分析映像的变化，具体方式是计算映像之间的差异并以直观易懂且可处理的格式呈现差异。该工具可以找出系统软件包、语言级软件包和容器映像中文件的差异。

container-diff 可以处理本地容器映像（使用前缀 daemon://）、远程注册表中的映像（使用前缀 remote://），以及另存为 .tar 存档的映像。可以使用 container-diff 来计算映像的本地版本与远程版本之间的差异。

要安装 container-diff，请运行 sudo zypper in container-diff 命令。

> sudo container-diff analyze --type=history daemon://IMAGE
> sudo container-diff analyze --type=file daemon://IMAGE

> sudo container-diff diff daemon://IMAGE_1 daemon://IMAGE_2 --type=history