Leap 15 & Tumbleweed 中的事务性更新

事务性更新是 Kubic 项目中的令人兴奋的新功能之一，它将在即将发布的 openSUSE Leap 15 中可用，并且已经可以在 Tumbleweed 中使用。
但是它们是什么，为什么你应该感兴趣？

补丁并不容易

软件更新有两个常见的，但常常相互冲突的要求。每个人都应该尽快、尽可能频繁地更新，以确保他们运行的是软件的最新、最安全的版本。如果没有这样做，系统发生故障或遭受成功的网络攻击的风险就会增加。

但与此同时，没有人愿意冒风险影响当前正在运行的系统。“不要碰正在运行的系统”是一句许多系统管理员和用户在世界各地坚持的格言，这是有充分理由的。软件更新确实存在一定的风险，并且这种风险在拥有更多用户和更多软件包的系统上往往会增加。迟早，总会出问题。

这是我们在 openSUSE & SUSE 发行版中长期以来一直在努力解决的问题。在 Tumbleweed 中，我们以惊人的速度发布更新，每周数百个新软件包。用户想要并需要这些更新，只要他们能够处理，就希望更新的速度尽可能快，但又希望风险最小。

在 SUSE 的企业发行版中，需求同样不容小觑。关键任务系统通常具有广泛的高可用性解决方案，因此会中断服务的更新比定期重新启动系统更昂贵。在这些环境中，确保更新应用得完美也很重要。更改应该完全应用，系统永远不会处于未定义或可疑的状态。

快照 - 答案的开端

在所有当前的 openSUSE & SUSE Linux Enterprise 发行版中，我们默认使用 btrfs 和 snapper 为我们的用户提供内置的带有回滚的快照。

这些与 zypper 和 YaST 集成，以在这些工具进行任何软件或配置更改之前和之后自动记录系统状态。

这在一定程度上解决了其中的一些问题。快照确实提供了一种非常可靠的方式来将系统恢复到工作状态，但最终这种方法并不能减轻可能导致系统故障的许多问题。

这些“传统”更新是在正在运行的系统上运行的，因此它们会受到当前正在运行的服务的影响，并可能被其影响。这些动态变量更有可能导致更新失败或仅部分成功，这意味着回滚系统的需求实际上可能比应该发生的频率更高。

介绍事务性更新

简单来说，事务性更新是一种

原子性。它要么完全应用，要么根本不应用。此外，更新作为单个事务完成，不会影响正在运行的系统。

易于回滚。如果更新失败，或者成功更新被认为不兼容或以其他方式不正确，则可以快速丢弃它，立即将系统恢复到其先前的工作状态。

关于……？

像在开源世界中引入任何新事物一样，公平地说，应该承认已经存在替代这种新的事务性更新方法的方法。

很长一段时间以来，一些用户一直采用相当昂贵的方法，即在磁盘上的多个分区中维护多个版本的系统，以便能够轻松地在它们之间切换并解决这些问题中的许多问题。当然，它有效，但在磁盘存储和维护工作量方面都相当昂贵。

寻找更现代化的方法，ostree & snap 等解决方案试图解决这些问题，并为他们的用户带来原子/事务性更新。

这些解决方案并非没有好处，但存在一些关键缺陷，而事务性更新可以避免这些缺陷。特别是，它们要求用户、开发人员和合作的软件供应商都学习管理系统的新方法。现有的软件包无法重用，需要重新打包或转换。并且现有的存储库和其他常见的软件包交付机制不再可用。

所有这些都发展成一种情况，即采用者需要重新设计他们的思维模式、系统、工具和公司策略，以配合这些工具。而这正是事务性更新努力避免的。

保持简单

在底层，我们努力保持事务性更新的简单性。我们正在利用我们在 openSUSE 和 SLE 中默认了解和信任的相同的 btrfs、snapper 和 zypper 技术。

从本质上讲，事务性更新做的事情与我们的传统快照回滚非常相似。但有了事务性更新，它永远不会触碰正在运行的系统。
与其修补当前系统，transactional-update 工具会创建一个新的、空的、快照。更新所需的所有操作都将执行到该快照中，确保当前系统未受影响，没有更改影响正在运行的系统。
在更新结束时，假设更新成功，此完成的快照将被标记为新的默认值。然后，这些更新将在系统重新启动时生效。

如果更新不成功，则会丢弃快照，并且不会对系统进行任何更改。

这种方法的另一个额外好处是，由于所有更新处理都在正在运行的系统中完成，因此事务性更新系统的启动时间与非事务性 openSUSE 系统的常规启动时间相同。

锦上添花：只读根文件系统

事务性更新永远不会触碰正在运行的系统，但你可能会，或者其他正在运行的软件也可能触碰。在具有典型的读写根文件系统的系统上，这意味着仍然存在变量可能会中断、干扰或以其他方式与系统更新交互。
然而，在许多情况下，用户不需要能够写入他们的根文件系统。这就是为什么在 Leap 15 和 Tumbleweed 中，我们很高兴现在提供带有事务性更新和只读根文件系统的服务器系统角色。

介绍事务性服务器角色

用户配置在 /etc 中是可写的，因为自动配置了 overlayfs，而 /var 是可写的，因为现在它是一个单独的子卷。

此角色与 SUSE CaaS Platform 和 Tumbleweed Kubic 共享许多相似之处，在这些地方默认使用此功能来提供容器主机或Kubernetes 集群节点。

但是现在该功能也适用于 openSUSE Leap 15 和 Tumbleweed，因此有了更多的可能性。你是否希望比平时更确定你的Web 或邮件服务器定期补丁，而不会出现故障？你的虚拟化主机呢？关于 IoT 呢？甚至可能是 事务性桌面？。

使用事务性更新

使用事务性更新的最简单方法是在 Leap 15 或 Tumbleweed 安装期间选择适当的角色。

openSUSE Leap 15 中的系统角色选择屏幕

安装完成后，只需将 transactional-update 作为 zypper 或 yast 的替代品来升级、更新或删除系统上的软件即可。
语法应该相当熟悉

• 使用 transactional-update up 在 Leap 上更新你的系统，或在 Tumbleweed 上使用 transactional-update dup
• 使用 transactional-update pkg in $foo 安装软件，其中 $foo 是你要安装的软件包的名称
• 使用 transactional-update pkg rm $foo 删除软件

在上述任何操作之后，你需要reboot 你的系统，然后更改才会生效。

• 要丢弃待处理的快照，只需在重新启动之前运行 transactional-update rollback
• 如果 reboot 未成功启动，只需从系统的 grub 菜单中选择最后一个工作快照，然后运行 transactional-update rollback

启用自动事务性更新和重新启动

事务性更新可以设置为每天自动运行，只需运行 systemctl enable --now transactional-update.timer

但是，如果没有自动重新启动系统的方法，这实际上是无用的。而不是愚蠢的 cron 作业，我们建议使用 rebootmgr。可以通过运行 systemctl enable --now rebootmgr.service 来启用它。
默认情况下，rebootmgr 会在有更新待处理时在 0330 到 0500 之间重新启动系统。编辑 /etc/rebootmgr.conf 以配置 rebootmgr 服务，以根据你的需要更改此维护窗口。man rebootmgr.conf 提供了有关可用参数的详细信息。

就这样了，你现在拥有了用于运行任何你想要的事务性系统。

谢谢，祝你事务性更新愉快，玩得开心！