Podman 对容器管理的⽀持¶
Launchpad蓝图
https://blueprints.launchpad.net/tripleo/+spec/podman-support
一直以来都有希望使用⼀套专⽬解决应⽤程序部署时复杂问题的⼯具来管理 TripleO 容器。TripleO 的容器化从 Docker CLI 实现开始，但我们正在研究如何利用 Kubernetes 友好的解决方案来实现容器编排。
问题描述¶
本⽂档将涵盖三个问题
正在进⾏讨论，未来版本的 Red Hat 平台是否会维护 Docker。普遍趋势是转向符合 OCI（开放容器倡议）标准的运行时，例如 CRI-O（容器运行时接⼝，专为 OCI 设计）。
TripleO 社区正在研究如何通过 Kubernetes 编排容器的生命周期，以便与 OpenShift 等其他项⽬保持⼀致性。
TripleO 项⽬旨在在 Red Hat 平台的下⼀个版本上⼯作，因此我们在 Stein 周期中正在寻找 Docker 的替代方案。
提议的变更¶
引言¶
TripleO 的容器化已经进⾏了⼀段时间，我们始终都在寻求逐步进⾏的⽅法，试图为部署者和开发⼈员维护向后兼容性；并且以⼀种可以从以前的版本升级，⽆需过多痛苦的⽅式。话虽如此，我们正在研究⼀项不会造成太多破坏，但仍然符合容器故事总体路线图，并有望引导我们使用 Kubernetes 管理容器的提议变更。我们使⽤ Paunch 项⽬来提供容器集成中的抽象。Paunch 将处理具有后端⽀持的容器配置格式。
集成 Podman CLI¶
Podman 的⽬标是允许⽤户运⾏独立的（未编排的）容器，这是我们直到现在都⽤ Docker 做的事情。Podman 还允许⽤户运⾏称为 Pods 的容器组，其中 Pod 是 Kubernetes 项⽬开发的概念，描述的是⼀个对象，它具有⼀个或多个容器化进程，共享多个命名空间（⽹络、IPC 和可选的 PID）。Podman 没有任何守护进程，这使得它比 Docker 更轻量级，并使⽤更传统的 Unix 和 Linux fork/exec 模型。Podman 使⽤的容器运行时是 runc。CLI 与 Docker 具有部分向后兼容性，因此将其集成到 TripleO 应该不会太痛苦。
提议在 TripleO 中添加对 Podman CLI 的⽀持（除了 Docker CLI），以管理容器的创建、删除、检查。我们将拥有⼀个新的参数，称为 TripleO 中的 ContainerCli，如果设置为“podman”，将使容器配置⽤ Podman CLI 进⾏，而不是 Docker CLI。
由于没有守护进程，因此存在我们需要解决的⼀些问题
⾃动重启失败的容器。
在主机（重新）启动时⾃动启动容器。
在主机启动期间按特定顺序启动容器。
提供与容器通信的渠道。
运⾏容器健康检查。
为了解决前 3 个问题，提议使⽤ Systemd
使⽤ Restart，以便我们可以为我们的容器配置重启策略。我们⼤多数容器将以 Restart=always 策略运⾏，但我们需要⽀持⼀些例外情况。
systemd 服务将默认启用，以便容器在启动时启动。
顺序将由 Wants 管理，Wants 在 Systemd 中提供隐式依赖项。Wants 是 Requires 的弱化版本。它将允许我们确保在同⼀主机上先启动 HAproxy，然后再启动 Keepalived。由于它是一个弱依赖项，它们仅在容器在同⼀主机上运⾏时才会被遵守。
容器的管理⽅式（启动/停止/重启/状态）对于习惯于控制 Systemd 服务的操作员来说将是熟悉的。但是，我们可能希望明确这⾮是我们长期管理容器的⽬标。
Systemd 集成将是
充分到足以涵盖我们的⽤例并与 Docker 实现实现功能同等性。
轻量级到足以能够在未来将我们的容器生命周期与 Kubernetes（例如 CRI-O）集成。
对于第四个问题，我们仍在调查选项
varlink：接⼝描述格式和协议，旨在以最简单的⽅式使服务可供⼈和机器访问。
CRI-O：基于 CI 的 Kubernetes 容器运行时接⼝实现，没有 Kubelet。例如，我们可以使⽤ CRI-O Python 绑定来与容器通信。
⼀个专⽤的镜像，它运⾏ rootwrap 守护进程，并带有 rootwrap 过滤器，仅运⾏允许的命令。控制容器将在其中安装 rootwrap socket，以便可以触发 rootwrap 容器中的允许的调⽤。对于 pacemaker，rootwrap 容器将允许镜像标记。对于 neutron，rootwrap 容器将在容器内生成进程，因此它需要是 Paunch 外部管理的⽣命周期较长的容器。
+———+ +———-+ | | | | | L3Agent +—–+ Rootwrap | | | | | +———+ +———-+
在此例⼦中，L3Agent 容器安装了 rootwrap 守护进程 socket，以便可以在 rootwrap 容器内运⾏允许的命令。
最后，第五个问题仍然是⼀个持续的问题。Podman 计划⽀持健康检查，但截至今天还没有完成。我们可能需要使⽤ Systemd 在我们这边实现⼀些东西。
替代方案¶
提出了两种替代方案。
CRI-O 集成¶
CRI-O 旨在提供符合 OCI 运行时和 kubelet 之间的集成路径。具体来说，它使⽤符合 OCI 标准的运行时实现了 Kubelet 容器运行时接⼝ (CRI)。请注意，与 CRI-O 交互的 CLI ⼯具不打算在生产环境中使用，因此仅通过 Docker 或 Podman CLI 才能管理容器的生命周期。
因此，与其从 Docker CLI ⾄ Podman CLI 的平滑迁移，我们可以直接进⾏ Kubernetes 集成，并将我们的 TripleO 服务转换为与由 CRI-O 管理的独立 Kubelet 协同⼯作。我们需要为 CRI-O 能够管理它们的 Pod 格式的 YAML ⽂件生成每个容器。这不需要 Systemd 集成，因为容器将由 Kubelet 管理。操作员将通过使⽤ kubectl 命令和 Paunch 中的 Kubelet 后端来控制容器的生命周期来控制容器的生命周期。
虽然这种实现将帮助我们迁移到多节点 Kubernetes 友好的环境，但就需要在 Stein 周期结束前设计、实现、测试和运送新⼯具所需⼯量与时间而言，它仍然是最有风险的选项。
我们还需要记住，CRI-O 和 Podman 共享容器/存储和容器/镜像库，因此我们遇到的 Podman 问题也会影响 CRI-O。
保留 Docker¶
我们可以保留 Docker，并且不更改我们管理容器的⽅式。我们也可以保留 Docker 并使其与 CRI-O 协同⼯作。⽽唯一风险是，Docker ⼯具可能不再受 Red Hat 平台的⽀持，如果 Docker 出现任何问题，我们将不得不⾃⾏解决。TripleO 社区始终寻求与我们交互的项⽬社区之间健康和⻓期的协作。
提议的路线图¶
在 Stein 中
使 Paunch ⽀持 Podman 作为 Docker 的替代方案。
使我们的现有服务完全可部署在 Podman 上，与我们之前在 Docker 上所拥有的功能同等。
如果有时间，将 Podman pod ⽀持添加到 Paunch
在“T”周期中
将我们所有的容器 yaml 重写为 pod 格式。
将 Kubelet 后端添加到 Paunch（或更改我们的 agent ⼯具，以便直接从 Ansible 调⽤ Kubelet）。
使我们的现有服务完全可以通过 Kublet 部署，与我们之前在 Podman / Docker 上所拥有的功能同等。
评估切换到 Kubernetes 本身。
安全影响¶
TripleO 容器将依赖于 Podman 安全性。如果我们不使⽤ CRI-O 或 varlink 与容器通信，我们将不得不考虑以特权模式运⾏某些容器，并将 /var/lib/containers 挂载到容器中。这是一个安全问题，我们需要评估它。此外，我们需要使提议的解决方案在 Enforcing 模式下与 SELinux 协同⼯作。
Docker 解决方案不会强制 SELinux 在容器之间隔离。Podman 确实如此，并且当前没有简单的方法可以全局停⽤它。因此，从一开始就必须⽀持隔离，我们可以获得更安全的容器。
升级影响¶
由 Docker Engine 管理的容器将被删除并配置到新的运行时。此过程将在 Paunch 生成和执⾏新的容器配置时发⽣。操作员不应需要采取任何手动操作，并且迁移将是⾃动化的，主要是由 Paunch 进⾏。容器化 Undercloud 升级作业将测试在 Rocky 上运⾏ Docker 容器的 Undercloud 的升级，并在 Stein 上升级到 Podman 容器。Overcloud 升级作业也将测试。
注意：由于 docker 运行时没有 selinux 分离，所以在迁移到 podman 运行时之前可能需要⼀些 chcon/重新标记。
最终⽤户影响¶
操作员将不再能够像以前那样运⾏ Docker CLI，而是必须使⽤ Podman CLI，其中保证了⼀定的向后兼容性。
性能影响¶
我们需要调查的不同性能方面
容器性能（依赖于 Podman）。
Systemd + Podman 如何协同⼯作，以及重启如何与 Docker engine 进⾏比较。
部署者影响¶
对于部署者来说，不应有太⼤的影响，因为我们的⽬标是使此更改尽可能透明。到目前为止，将暴露给部署者的唯⼀选项是“ContainerCli”，其中仅将⽀持“docker”和“podman”。如果选择“podman”，则过渡将是⾃动化的。
开发人员影响¶
对于 TripleO 服务的开发⼈员来说，不应有太⼤的影响，除了 Podman 中与 Docker 相比略有变化的事情。例如，Podman 在将绑定挂载到容器中时不会创建缺少的⽬录，⽽ Docker 会创建它们。
实现¶
贡献者¶
Bogdan Dobrelya
Cédric Jeanneret
Emilien Macchi
Steve Baker
工作项¶
更新 TripleO 服务以与 Podman 协同⼯作（例如，修复绑定挂载问题）。
SELinux 分离（与绑定挂载权限 + 我们从容器中调⽤ iptables/其他主机命令时出现的一些问题相关）。
Systemd 集成。
健康检查⽀持。
Socket / 运行时：varlink？CRI-O？
升级流程。
测试。
操作员的⽂档。
依赖项¶
Podman 集成在多⼤程度上取决于该⼯具的稳定性以及它被发布和运送到 CI 中以便我们测试的频率。
健康检查接⼝取决于 Podman 的路线图。
测试¶
⾸先，我们将切换 Undercloud 作业以使⽤ Podman，并且此⼯作应在 milestone-1 之前完成。部署和升级作业都应切换并实际⼯作。overcloud 作业应在 milestone-2 之前切换。
我们将继续⽀持 Docker 测试，直到我们继续在 CentOS7 平台上测试为止。
文档影响¶
我们需要记录新的命令（主要是与 Docker 相同），以及容器管理⽅式（例如，Systemd 替代 Docker CLI）的差异。
