A true hybrid image/package system
一个真正的混合镜像/软件包系统
- Projects using rpm-ostree
使用 rpm-ostree 的项目 - Getting started 入门指南
- Why? 为什么?
- Why would I want to use it?
为什么我要使用它? - Why not implement these changes in an existing package manager?
为什么不在现有的软件包管理器中实施这些更改? - But still evolutionary 但仍然是进化的
- Talks and media 谈话和媒体
- License 许可证
rpm-ostree is a hybrid image/package system. It combines libostree as a base image format, and accepts RPM on both the client and server side, sharing code with the dnf project; specifically libdnf. and thus bringing many of the benefits of both together.
rpm-ostree 是一种混合的镜像/软件包系统。它将 libostree 作为基本镜像格式,并在客户端和服务器端都接受 RPM,与 dnf 项目共享代码;具体来说是 libdnf。因此将两者的许多优点结合在一起。
+-----------------------------------------+
| |
| rpm-ostree (daemon + CLI) |
+------> <---------+
| | status, upgrade, rollback, | |
| | pkg layering, initramfs --enable | |
| | | |
| +-----------------------------------------+ |
| |
| |
| |
+-----------------|-------------------------+ +-----------------------|-----------------+
| | | |
| libostree (image system) | | libdnf (pkg system) |
| | | |
| C API, hardlink fs trees, system repo, | | ties together libsolv (SAT solver) |
| commits, atomic bootloader swap | | with librepo (RPM repo downloads) |
| | | |
+-------------------------------------------+ +-----------------------------------------+
Features: 特点:
- Transactional, background image-based (versioned/checksummed) upgrades
事务性、基于后台镜像的(版本化/校验和)升级 - OS rollback without affecting user data (
/usr
,/etc
but not/var
) via libostree
在不影响用户数据的情况下回滚操作系统 (/usr
,/etc
但不包括/var
) 通过 libostree - Client-side package layering (and overrides)
客户端包层叠 (和覆盖) - Easily make your own derivatives
轻松制作您自己的衍生版本
Projects using rpm-ostree
使用 rpm-ostree 的项目
The OSTree project is independent of distributions and agnostic to how content is delivered and managed; it’s used today by e.g. Debian, Fedora, and OpenEmbedded derived systems among others. There are some examples in the OSTree github.
OSTree 项目独立于发行版,对内容的传递和管理方式保持中立;例如,Debian、Fedora 和 OpenEmbedded 衍生系统今天都在使用它。在 OSTree 的 GitHub 上有一些示例。
In contrast, rpm-ostree is intended to be tightly integrated with the Fedora ecosystem. Today it is the underlying update mechanism of Fedora CoreOS as well as its derivative RHEL CoreOS. It is also used by Fedora IoT and Fedora Silverblue.
相比之下,rpm-ostree 旨在与 Fedora 生态系统紧密集成。今天它是 Fedora CoreOS 及其衍生产品 RHEL CoreOS 的基础更新机制。它还被 Fedora IoT 和 Fedora Silverblue 使用。
Originally, it was productized as part of Project Atomic.
最初,它作为 Atomic 项目的一部分进行产品化。
Getting started 入门指南
If you want to try the system as a user, see the main Fedora website which has several versions that use rpm-ostree, including Silverblue, IoT and CoreOS. If you are interested in assembling your own systems, see compose server.
如果您想以用户身份尝试该系统,请查看主要的 Fedora 网站,该网站有几个使用 rpm-ostree 的版本,包括 Silverblue、IoT 和 CoreOS。如果您对组装自己的系统感兴趣,请查看组合服务器。
Why? 为什么?
Package systems such as apt and yum are highly prevalent in Linux-based operating systems. They offer a lot of flexiblity, but have many failure modes.
apt 和 yum 等软件包系统在基于 Linux 的操作系统中非常普遍。它们提供了很多灵活性,但也有许多故障模式。
The core premise of rpm-ostree is that offline transactional image-based updates should be the default. This provides a high degree of predictability and resiliency. The operating system vendor can focus a lot of effort on testing the “base images” as a unit.
rpm-ostree 的核心前提是离线事务性基于镜像的更新应该是默认设置。这提供了高度的可预测性和弹性。操作系统供应商可以将大量精力集中在测试“基础镜像”作为一个单元上。
Further, image based updates simply work better at scale. For “IoT” style devices it’s very inefficient to have each machine perform dependency resolution, run package scripts etc. And the same is true for many server datacenter use cases.
此外,基于图像的更新在规模上表现更好。对于“物联网”风格的设备,让每台机器执行依赖关系解析、运行软件包脚本等是非常低效的。对于许多服务器数据中心使用案例也是如此。
Where rpm-ostree is fairly unique in the ecosystem is supporting client-side package layering and overrides; deeply integrating RPM as an (optional) layer on top of OSTree.
在生态系统中,rpm-ostree 相对独特的地方在于支持客户端软件包分层和覆盖;深度集成 RPM 作为 OSTree 顶部的(可选)层。
A good way to think of package layering is recasting RPMs as “operating system extensions”, similar to how browser extensions work (although before those were sandboxed). One can use package layering for components not easily containerized, such as PAM modules, custom shells, etc.
将软件包分层视为将 RPM 重新构建为“操作系统扩展”的好方法,类似于浏览器扩展的工作方式(尽管在这些扩展被沙箱化之前)。可以使用软件包分层来处理不容易容器化的组件,例如 PAM 模块、自定义 shell 等。
Further, one can easily use rpm-ostree override replace
to override the kernel or userspace components with the very same RPMs shipped to traditional systems. The Fedora project for example continues to only have one kernel build.
此外,人们可以轻松使用 rpm-ostree override replace
来覆盖内核或用户空间组件,使用与传统系统中提供的相同的 RPM 软件包。例如,Fedora 项目仍然只有一个内核构建。
Layering and overrides are still built on top of the default OSTree engine - installing and updating client-side packages constructs a new filesystem root, it does not by default affect your booted root. This preserves the “image” nature of the system.
分层和覆盖仍然建立在默认的 OSTree 引擎之上 - 安装和更新客户端软件包会构建一个新的文件系统根目录,它默认不会影响您的引导根目录。这保留了系统的“镜像”特性。
By its nature as a hybrid image/package system, rpm-ostree is intended to span nearly all use cases of current package systems and image systems.
由于其作为混合镜像/软件包系统的特性,rpm-ostree 旨在涵盖当前软件包系统和镜像系统的几乎所有用例。
Why would I want to use it?
为什么我要使用它?
One major feature rpm-ostree has over traditional package management is atomic upgrade/rollback. It supports a model where an OS vendor (such as CentOS or Fedora) can provide pre-assembled “base OS images”, and client systems can replicate those, and possibly layer on additional packages.
rpm-ostree 相对于传统软件包管理具有一个重要特性,即原子升级/回滚。它支持一种模型,其中操作系统供应商(如 CentOS 或 Fedora)可以提供预先组装的“基础操作系统镜像”,客户端系统可以复制这些镜像,并可能在其上添加额外的软件包。
Why not implement these changes in an existing package manager?
为什么不在现有软件包管理器中实现这些更改?
The OSTree related projects section covers this to a degree. As soon as one starts taking “snapshots” or keeping track of multiple roots, it uncovers many issues. For example, which content specifically is rolled forward or backwards? If the package manager isn’t deeply aware of a snapshot tool, it’s easy to lose coherency.
与 OSTree 相关的项目部分在一定程度上涵盖了这一点。一旦开始“快照”或跟踪多个根目录,就会揭示许多问题。例如,具体哪些内容是向前滚动或向后滚动的?如果软件包管理器对快照工具不够了解,很容易失去一致性。
Filesystem layout 文件系统布局
A concrete example is that rpm-ostree moves the RPM database to /usr/share/rpm
, since we want one per root /usr
. In contrast, the snapper tool goes to some effort to include /var/lib/rpm
in snapshots, but avoid rolling forward/back log files in /var/log
.
一个具体的例子是 rpm-ostree 将 RPM 数据库移动到 /usr/share/rpm
,因为我们希望每个根目录 /usr
有一个。相比之下,snapper 工具会努力在快照中包含 /var/lib/rpm
,但避免在 /var/log
中向前/向后滚动日志文件。
OSTree requires clear rules around the semantics of directories like /usr
and /var
across upgrades, and while this requires changing some software, we believe the result is significantly more reliable than having two separate systems like yum and snapper glued together, or apt-get and BTRFS, etc.
OSTree 需要在升级过程中对目录的语义(如 /usr
和 /var
)进行明确规定,虽然这需要改变一些软件,但我们相信结果比将两个独立系统(如 yum 和 snapper 粘合在一起,或者 apt-get 和 BTRFS 等)更可靠。
User experience 用户体验
Furthermore, beyond just the mechanics of things like the filesystem layout, the implemented upgrade model affects the entire user experience.
此外,除了像文件系统布局这样的机制之外,实施的升级模型也会影响整个用户体验。
For example, the base system OSTree commits that one replicates from a remote server can be assigned version numbers. They are released as coherent wholes, tested together. If one is simply performing snapshots on the client side, every client machine can have different versions of components.
例如,基本系统 OSTree 提交的副本可以从远程服务器分配版本号。它们作为一体发布,一起测试。如果只是在客户端执行快照,每台客户机可以有不同版本的组件。
Related to this is that rpm-ostree clearly distinguishes which packages you have layered, and it’s easy to remove them, going back to a pristine, known state. Many package managers just implement a “bag of packages” model with no clear bases or layering. As the OS evolves over time, “package drift” occurs where you might have old, unused packages lying around.
与此相关的是,rpm-ostree 清楚地区分了您添加的哪些软件包,并且很容易将它们删除,回到一个原始的、已知的状态。许多软件包管理器只是实现了一个“软件包的集合”模型,没有明确的基础或分层。随着操作系统随时间的演变,“软件包漂移”会发生,您可能会有一些旧的、未使用的软件包留在那里。
But still evolutionary 但仍然是渐进的
On the other hand, rpm-ostree in other ways is very evolutionary. There have been many, many different package managers invented - why not adopt or build on one of those?
另一方面,rpm-ostree 在其他方面非常具有进化性。已经发明了许多不同的软件包管理器 - 为什么不采用或建立其中的一个?
The answer here is that it takes a long time for tooling to be built on top of a package format - things like mirroring servers. Another example is source format representations - there are many, many tools that know how to build source RPMs.
这里的答案是,构建在软件包格式之上的工具需要很长时间 - 例如镜像服务器。另一个例子是源格式表示 - 有许多工具知道如何构建源 RPM。
From the perspective of distribution which has all of that ecosystem built up, rpm-ostree does introduce a new binary format (ostree), but otherwise includes an RPM database, and also operates on packages. It is not a new source format either.
从拥有所有这些生态系统的分发角度来看,rpm-ostree 确实引入了一种新的二进制格式(ostree),但除此之外还包括一个 RPM 数据库,并且也操作软件包。它也不是一种新的源格式。
Talks and media 对话和媒体
A number of Project Atomic talks are available; see for example this post which has a bigger collection that also includes talks on containers.
一些 Project Atomic 的讨论可供参考;例如,可以查看这篇帖子,其中包含更多内容,还包括有关容器的讨论。
rpm-ostree specific talks:
rpm-ostree 特定的讨论:
- devconf.cz 2018: Colin Walters: Hybrid image/package OS updates with rpm-ostree (slides)
devconf.cz 2018: Colin Walters: 使用 rpm-ostree 进行混合镜像/软件包 OS 更新(幻灯片) - devconf.cz 2018: Peter Robinson: Using Fedora and OSTree for IoT
devconf.cz 2018: Peter Robinson: 使用 Fedora 和 OSTree 用于物联网
License 许可证
rpm-ostree includes code licensed under GPLv2+, LGPLv2+, (Apache 2.0 OR MIT). For more information, see LICENSE.
rpm-ostree 包含根据 GPLv2+、LGPLv2+、(Apache 2.0 或 MIT) 许可的代码。有关更多信息,请参阅 LICENSE。