关于开源:让开源项目从易用到好用-亚马逊的开源文化

亚马逊的领导力准则是亚马逊文化的外围，它如同亚马逊的 DNA 融入贯通每一个重要决策，深深影响着每一位亚麻人、影响着每一位亚马逊的客户、合作伙伴以及每一位亚马逊云科技的构建者。同时，亚马逊的领导力准则对亚马逊与开源的互动形式也产生着深远的影响。

前两篇文章里，咱们别离为大家介绍了亚马逊在开源社区如何践行“客户至尚”和“最高规范”这两个领导力准则。

作为本系列的完结篇，咱们想与大家分享在开源社区里咱们是如何做到“翻新简化”这一领导力准则的。

翻新简化

因为开源的自在，开发者可能拜访成千上万的开放源码我的项目。然而，仅仅因为能够拜访源代码，就意味着能够驾驭它吗？

事实并非如此——对于许多开放源码我的项目，须要“运行起来”能力使其达到可用的状态。在亚马逊云科技，“翻新简化”的领导力准则赋予了一个使命——让人们更容易应用开源代码。

开发者通知咱们，让他们轻松实现开源，是云供应商可能帮忙他们的最重要的事件。

Bottlerocket

我的项目地址：https://github.com/bottlerocket-os/bottlerocket?trk=cndc-detail

Bottlerocket 是专为运行容器构建的基于 Linux 的操作系统，咱们以 Bottlerocket 我的项目为例，为你介绍亚马逊云科技在帮忙开发者更容易地应用凋谢源代码方面所做的致力。

Bottlerocket 的开发初衷

2014 年，亚马逊云科技推出了 Amazon ECS，并且同步推出了用于托管容器的预配置、即用型操作系统 AMI。2017 年，咱们又推出了 Amazon EKS 以及配套优化的 AMI。在这两个容器服务被开发者宽泛的应用的同时，咱们听取了他们对于 ECS 优化型 AMI、EKS 优化型 AMI 以及其余以容器为核心型操作系统的倡议，如：加强安全性、保障集群内各实例的统一性，容易运维等。同时，开发者还通知咱们，他们经常会遇到只在 Linux 零碎上运行容器的生产场景，这种场景并不总是须要一个残缺的 Linux 发行版。他们更须要一个特定于容器、仅提供必要软件包的 Linux 零碎。同时轻量级的操作系统也能够缩小了部署工夫。

于是，2020 年 3 月 10 日，亚马逊正式推出 Bottlerocket。它不是 Ubuntu、Fedora 这样的惯例 Linux 发行版，而是一套用于托管 Linux 容器的新型专用操作系统。它不仅仅优化了零碎部署的工夫和对底层资源的占用，最要害的是：

• 极简的零碎将会带来弱小的内置平安：Bottleroket 仅蕴含托管容器必须组件，最大限度地缩小攻击面；
• 它应用只读的文件系统，在启动时通过 dm-verity 查看其完整性，来帮忙避免基于 rootkit 的攻打；
• 没有 SSH、解释器 (例如 Python)、Shell，使得攻击者将更难在零碎当中寻找驻留点；
• 通过应用 Bottleroket，开发者能够在降级或替换节点时统一地利用配置设置，从而缩小保护开销，实现工作流的自动化。

Bottlerocket 的设计

安全性

安全性的次要概念在于缩小攻击面，验证软件品质并强制划分权限边界。

Bottlerocket 的设计初衷是在大多数状况下都能轻装上阵，因而 Bottlerocket 中蕴含的组件很少，没有 SSH、没有解释器 (例如 Python)、也没有 Shell。剔除此类组件带来的另外一个益处是，攻击者将更难在零碎当中寻找驻留点。

除了缩小组件之外，Bottlerocket 还通过一些设计来管制操作系统的攻击面，包含：构建不受地位限度的可执行文件 (PIE)，应用重定位只读文件 (RELRO) 链接，应用 Rust 及 Go 等内存平安语言等等。

为了加强安全性，Bottlerocket 还通过明码技术进行自我验证。零碎由磁盘镜像组成，零碎在启动镜像时应用 dm-verity 进行自我验证，磁盘镜像的任何意外变更，都将导致操作系统无奈启动。

Bottlerocket 还领有本人的软件更新程序，而非间接应用更常见的 Linux 包管理器。Bottlerocket 的所有更新都来自一套遵循 The Update Framework (TUF) 标准的代码库。TUF 可能无效缓解针对传统程序包管理器零碎中各类软件代码库的常见攻打办法。Bottlerocket 还会在强制模式下应用 SELinux 限度本身受到的批改，甚至可能回绝高权限容器下达的操作申请。SELinux 属于一套对 Linux 内核施行强制访问控制 (MAC) 的实现版本，其限度了过程所能采取的具体操作类别。现在，Bottlerocket 的 SELinux 限度策略曾经十分明确，可能限度各类容器对操作系统做出意外更改。展望未来，咱们心愿进一步扩大这些策略，从而对应更多不同类型的继续威逼流动。

一致性

保障集群内各实例的统一性是咱们听取的开发者对于容器运行零碎的重要诉求之一，也是 Bottlerocket 设计的另外一个初衷。

Bottlerocket 次要通过三种形式加强一致性：基于镜像的更新、只读 root 文件系统，外加 API 驱动型配置。

基于镜像的更新——目前各类常见的通用型 Linux 发行版总会内置用于软件装置及更新操作的集成软件包管理系统。在治理大量主机时，每一台主机可能装置有不同的软件包的不同版本，同时软件包管理器中的可用软件包品种繁多，且咱们装置的软件包组合可能从未进行过匹配测试。这些给各实例一致性的治理带来严厉的挑战。与之相同，Bottlerocket 的状况齐全不同——它不提供软件包管理器。Bottlerocket 间接应用事后构建的镜像，其中蕴含操作系统必要软件，以及诊断及可察看性工具等其他软件计划。当存在可用更新时，Bottlerocket 会下载新的残缺磁盘镜像，并通过简略重启实现利用更新。这种基于镜像的部署办法可能严格保障一致性程度：fleet 中的所有 Bottlerocket 主机都可能运行完全相同的软件，并保障 Bottlerocket 镜像中的每一种组件及其特定版本都通过严格的组合测试。Bottlerocket 专门用于运行容器，而且凭借基于镜像的部署机制保障一致性。但运行中容器内的每一个用例都是不同的，并不存在可能宽泛实用的普适性软件与配置。同时，要让 Bottlerocket 可能在不同的地位 (包含 Raspberry Pi 设施上) 配合不同的编排工具 (例如 Amazon ECS) 失常运行。为了解决这个看起来“互相对抗”的问题，Bottlerocket 设计了“变体 (variant)”零碎满需要差别，并针对不同的用例提供不同的镜像。比方亚马逊云科技面向 Kubernetes 1.15 公布的变体名为 aws-k8s-1.15。Bottlerocket 中也蕴含对应工具，容许大家联合本身需要构建属于本人的变体版本。

只读 root 文件系统——与传统 Linux 发行版不同，Bottlerocket 操作系统配置有只读的 root 文件系统。这样的设计将进一步晋升一致性程度并缩小变量漂移。应用程序无奈批改磁盘镜像，同时也无奈将以后变更引入另一台主机。在 Bottlerocket 下载完更新并筹备装置时，该更新将被写入至辅助分区。在重新启动之后，Bottlerocket 的疏导加载程序将依据该分区进行疏导，更改主分区并在辅助分区内持续保留旧版本镜像。一旦产生更新问题，咱们能够利用这套机制实现疾速回滚。Bottlerocket 还在文件系统当中装备一个独立的可写入局部，专门用于寄存持久性用户数据，例如容器镜像与存储卷等。

外加 API 驱动型配置——目前比拟常见的作法，是在 Linux 上的 /etc 目录当中存储软件配置。Bottlerocket 同样兼容 /etc 目录，但会将其以基于内存的临时文件零碎的模式进行公开，此文件系统在每次疏导时都会经验重建。除了这部分配置外加可能容许应用程序更改 Bottlerocket 本体的大量配置之外，其余所有配置都将通过 Bottlerocket 凋谢的 API 实现。该 API 领有丰盛的语义反对范畴，涵盖结构化设置、事务设置与主动迁徙等等。用户能够通过 Amazon Systems Manager 经由 Bottlerocket 中的“control”容器拜访该 API，借此实现交互式变更；此外，大家也能够间接以编程模式实现变更。如果大家将 Bottlerocket 运行在 EC2 实例之上，亦可通过 TOML 格局的用户数据进行配置设定。

Bottlerocket 还具备自行设定一部分配置选项的能力。在疏导过程初期，Bottlerocket 会主动生成主机名称与网络配置等以实现自我设置。在应用 Bottlerocket 的 asws-k8s-1.15 变体时，零碎将运行帮忙程序以配置 Kubernetes 中的特定设置，例如集群 DNS 设置与暂停容器镜像的名称等。大家能够应用 API 笼罩掉这些初始设置，也能够在配合 EC2 实例应用时通过 TOML 格局的用户数据实现设置。

可操作性

尽管 Bottlerocket 是为容器设计的精简操作系统，但依然具备多种惯例操作性能。比方内置了主动软件更新机制，并与 Kubernetes 相集成，通过监控警报及工作负载转移等机制缩小服务中断造成的影响。再比方 Bottlerocket 提供了用于执行惯例治理工作 (例如变更设置以及手动装置软件更新) 的工具，供开发者用于紧急情况。

Bottlerocket 的更新性能由多种不同组件独特实现。首先是一套基于 TUF 的代码库，其中蕴含更新的镜像与签名，用于证实镜像完整性以及代码库本身的完整性。其次，Bottlerocket 中的托管工具 updog 用于同代码库进行交互并检索更新。Updog 可能查问更新，并将更新内容立刻利用于 Bottlerocket。但须要留神的是，updog 默认应用基于“wave”准则的更新策略——wave 机制容许更新内容在不同时段内有秩序地交付至集群内的不同主机，而非同一时间向全副主机公开更新。这一机制可能防止所有主机同时尝试进行更新，进而导致容器内工作负载呈现服务中断；而一旦发现主机呈现问题，也能够立刻进行更新。每个主机都会在疏导过程中被调配予一个随机 wave，当然用户也能够依据需要对为各主机指定特定的 wave。

Bottlerocket 的更新性能可能与容器编排工具相集成。Bottlerocket 提供了 Kubernetes operator，能够将其部署到集群中以应用 updog 执行更新。该 operator 将确保每次仅更新集群中的一台主机，并在利用更新之前妥善处理监控警报与负载转移等工作。

因为 Bottlerocket 中没有装置 SSH，因而咱们须要一种不同的机制实现操作系统管制、与 API 进行交互，并在紧急状态下切换为管理模式。Bottlerocket 提供两款工具：其一是用于典型打算内保护工作 (例如变更设置) 的“control”容器，其二为用于紧急用处的“admin”容器。其中 control 容器将在容器启动时开始运行，其中蕴含 Amazon SSM 代理；大家能够利用 AmazonSystems Manager API 与之交互。此 control 容器中还蕴含名为 apiclient 及 enable-admin-container 的程序，前者用于实现与 Bottlerocket API 之间的交互，后者是一款小型帮忙程序，可能主动收回 API 调用以启动应急 admin 容器。

Admin 容器专门负责解决各类紧急状况。它以全权限模式启动，而且除了已利用的 SELinux 配置文件之外，不再受任何其余限度的束缚。Admin 容器以 Amazon Linux 2 容器镜像为根底，其中提供咱们在通用 Linux 发行版中须要的所有工具。Admin 容器中装置并运行有 SSH，用户能够在实例启动时应用指定的 SSH 密钥通过 Bottlerocket 主网络接口实现接入。此外，Admin 容器还提供名为 sheltie 的工具，可能将当前工作负载的上下文 (Linux 命名空间) 转换为主机上下文，帮忙开发者在 admin 容器之内对主机进行操作。Admin 容器在默认状况下不会启用，并倡议在 Bottlerocket 的生产部署中将其禁用。

Bottlerocket 所运行的容器，一部分由编排工具负责管理，也有一部分以本地形式经营——咱们将后一类称为“主机容器”。这些主机容器中也包含之前提到的 control 与 admin 容器。

Bottlerocket 应用两种互相独立的容器运行时相当于两种不同的容器正本运行这些容器。这样的解决形式起因有三：

1. 依据 SELinux 配置要求，编排容器与主机容器可能领有彼此不同的独立平安要求；
2. 咱们能够通过不同于主机容器的运行时 (例如 Docker 或者 CRI-O) 启动编排容器；
3. 编排容器与主机容器能够借此领有互不烦扰的故障域，保障在对某一容器运行时进行配置变更或产生故障时，另一过来时不会受到影响。

Bottlerocket 默认蕴含 control 容器，但 admin 容器只能在必要时手动增加。当然，大家也能够应用主机容器零碎在 Bottlerocket 上运行本人的诊断、操作与管理工具。

Bottlerocket 的倒退和将来

Bottlerocket 是一套齐全开源的操作系统，由现有开源组件 (例如 Linux 内核)、软件包以及专为 Bottlerocket 编写的新组件 (次要以 Rust 及 Go 语言编写而成) 独特组成。Bottlerocket 中应用的所有开源组件皆合乎其原始许可，而专为 Bottlerocket 开发的组件也遵循相似的许可协定，开发者能够依据需要抉择 Apache 2.0 许可或 MIT 许可。

欢送你退出 Bottlerocket 小家庭！能够查看咱们的 GitHub 仓库，通过问题参加探讨，并通过提交合并申请为我的项目做出奉献。

Bottlerocket 我的项目地址：https://github.com/bottlerocket-os/bottlerocket?trk=cndc-detail

咱们也整顿了一系列 Bottlerocket 相干的文章，欢送浏览：

• Bottlerocket 当初由 Amazon Inspector 提供反对

https://aws.amazon.com/cn/about-aws/whats-new/2022/09/bottler…

• 实用于 Bottlerocket 的互联网安全核心 (CIS) 基准现已推出

https://aws.amazon.com/cn/about-aws/whats-new/2022/08/center-…

• Bottlerocket 现已在 Amazon Web Services 中国区域推出

https://aws.amazon.com/cn/about-aws/whats-new/2022/08/center-…

• Bottlerocket 减少了 ECS 版本来反对由 NVIDIA 提供反对的基于 GPU 的 Amazon EC2 实例类型

https://aws.amazon.com/cn/about-aws/whats-new/2022/06/bottler…

• Bottlerocket 现已在 AWS GovCloud (美国) 区域推出

https://aws.amazon.com/cn/about-aws/whats-new/2021/11/bottler…

• Bottlerocket AMI for Amazon ECS 现已全面凋谢

https://aws.amazon.com/cn/about-aws/whats-new/2021/06/the-bot…

• 发表全面推出 Bottlerocket – 专为运行容器而打造的基于 Linux 的全新开源操作系统

https://aws.amazon.com/cn/about-aws/whats-new/2020/08/announc…

Firecracker

我的项目地址：https://github.com/firecracker-microvm/firecracker?trk=cndc-detail

开发者通知咱们，当所有的容器都必须应用某个共享的操作系统内核时，现有的容器不能在应用程序之间实现充沛的隔离，平安问题很难解决。

咱们聆听了开发者的想法，并在此基础上推出了 Firecracker 的开源我的项目。

Firecracker 是一种采纳基于 Linux 内核的虚拟机 (KVM) 技术的开源虚拟机监控程序 (VMM)。能够在不到一秒的工夫外在非虚拟化环境中启动轻量级微型虚拟机 (microVM)，充分利用传统虚拟机提供的安全性实现工作负载间的隔离。以及容器带来的资源效率。

Firecracker 的开发初衷

平安，对于亚马逊来说始终是头等要务！Firecracker 保持精简主义的设计准则，它仅蕴含运行平安、轻量的虚拟机所需的组件。在设计过程的各个环节，根据安全性、速度和效率要求来优化 Firecracker。例如：

• 仅需启动绝对较新的 Linux 内核，并且仅启动应用特定配置选项集编译的内核（内核编译配置选项超过 1000 种）；
• 此外，不反对任何类型的图形卡或加速器，不反对硬件透传，不反对（大多数）老旧设施。Firecracker 启动的内核配置极少，不依赖仿真 BIOS，不应用残缺设施模式。惟一的设施是半虚拟化网卡和半虚拟化硬盘，以及单按钮键盘（复位引脚在无电源治理设施时应用）。这种极简的设施模式不仅有利于缩短开机工夫，同时也缩小了攻击面，从而进步了安全性。无关 Firecracker 承诺反对以极低的开销执行容器和无服务器工作负载的更多信息，请查阅文档:
• Firecracker 应用 Rust 语言来实现，来保障线程和内存平安，避免缓存溢出以及可能导致安全性破绽的许多其余类型的内存平安问题。

Firecracker 又被视为无服务器计算的轻量级虚拟化。2014 年亚马逊云科技推出 Amazon Lambda，专一于为开发者提供平安的无服务器体验，让他们能够不用治理基础设施。为了达到现实的隔离情况，为每位客户应用了专用的 EC2 实例。这种办法可能实现平安指标，但也不得不在后盾治理 Lambda 时做出一些取舍。

随着无服务器技术的疾速倒退和宽泛采纳，其劣势延长到了容器，如 Amazon Fargate。如何进一步提高无服务器以及容器运行的效率是摆在开发者背后的新的问题。对于亚马逊来说，秉承“翻新”和“简化”的准则，咱们问本人：为当今的容器和函数世界设计的虚拟机到底该是什么样子？

2018 年咱们推出了开源产品 Firecracker。不同于 Docker 容器或 JVM 等语言 VM，Firecracker 是专门致力于无服务器利用的轻量虚构。Firecracker 容许创立微型虚拟机，即 microVM。它仅蕴含运行平安、轻量的虚拟机所需的组件。Firecracker microVM 进步了效率和利用率，内存开销极低，每 microVM 的内存开销 < 5MB。这意味着能够将数千个 microVM 封装到一个虚拟机中。开发者能够应用过程中速率限制器来实现对网络和存储资源的共享形式的精密管制，即便跨数千个 microVM 也同样可行。所有硬件计算资源能够平安地超订，从而最大化能够在主机上运行的工作负载数量。

综上，Firecracker 的开发源于如下的领导信条：

• 内置安全性：提供了反对多租户工作负载并且不会被客户谬误禁用的计算安全性屏障。用户工作负载被认为既神圣（不可进犯）又邪恶（该当拒之门外）；
• 轻量虚拟化：器重瞬时性或无状态的工作负载，而非长时间运行或持续性的工作负载。Firecracker 的硬件资源开销是明确且有保障的；
• 性能极简主义：不会构建非具体任务所明确要求的性能。每个性能仅施行一项；
• 开源：Firecracker 是一项沉闷的开源我的项目，向所有人凋谢，所有硬件计算资源都能够平安地超订，并期待与来自世界各地的贡献者单干。

Firecracker 的设计

Firecracker 运行在 Linux 主机和 Linux guest OS 上（目前反对的内核版本的残缺列表，请查看 Kernel Support Policy）。在生产环境中，Firecracker 以 jailer binary 形式启动（更多细节请参见沙盒化）。在过程启动并执行 InstanceStart 前，用户通过与 Firecracker API 交互来配置 microVM。Firecracker 通过主机上的 TAP 模块模仿了虚拟机的网络设备，通过主机的文件系统模仿了虚拟机的块状存储设备。

运行 Firecracker microVM 的主机实例

作为一款轻量级虚拟机，每个 Firecracker 过程封装一个且仅有一个 microVM。这意味着每个 microVM 外部仅运行一个利用容器，或者仅运行一个利用 Pod。因而不同租户的不同利用之间就实现了虚拟化级别的隔离，每个利用不再共享 HostOS 内核，而是领有独立的 GuestOS Linux 内核。与此同时 Firecracker 运行在一般 Linux 上，每个 microVM 都是以 KVM 过程的形式运行，由操作系统负责过程调度。对于不同 microVM 在宿主机上运行的 Firecracker 过程，Firecracker 通过动态链接以 jailer 形式启动，并通过 CGroups 和 Seccomp BPF 进行过程间平安隔离，全方位提供隔离性保障。

作为一款轻量级虚拟机，Firecracker 仅蕴含以下性能：

• 基于 VirtIO 的网络，磁盘和套接字驱动 (virtio-net, virtio-blk, virtio-vsock)，别离用于 microVM 的网络与磁盘 IO 拜访，以及 microVM 上的 AF_VSOCK 套接字与宿主机的 AF_UNIX 套接字通信，从而实现 microVM 内运行的利用传递 vhost 内核代码到宿主机的通信；
• 可编程的距离计时器；
• KVM 时钟；
• 串口终端控制台（例如 /dev/ttyS0）；
• 仅蕴含关机键的键盘。其中 VirtIO 驱动是一种支流的半虚拟化 IO 驱动形式，它缩小了用户态和内核态之间的切换次数从而晋升效率，也是 QEMU-KVM 中最罕用的一种 IO 驱动形式。

Firecracker 的倒退和将来

作为一个开源我的项目，Firecracker 不仅引起了社区的宽泛关注，同时也孵化出了多个基于 Firecracker 运行时的容器我的项目。开源也大大拓宽了 Firecracker 这款通用轻量级虚拟机的应用场景，除了亚马逊云科技的无服务计算产品，还能在亚马逊云科技以外的本地环境中运行容器。

以社区的 firecracker-containerd 我的项目为例，通过该我的项目使得规范的 RunC 容器可能运行在 microVM 外部，而且通过 HostOS 上的 containerd 就可能治理 GeustOS 的容器。从而无缝兼容 OCI (Open Container Initiative) 标准规范，镜像格局以及管理工具，这使得以 Docker 和 Kubernetes 的支流容器运行调度框架只须要大量批改，就可能适配基于 Firecracker 虚拟化技术隔离的平安容器计划。这样提现了容器畛域以开源文化主导的社区生态魅力。

除此之外与 firecracker-containerd 性能相似的另一个我的项目，则是由 OpenStack 社区主导的 Kata Containers，该我的项目在 1.5 版本后，新减少了对 Firecracker VMM 的反对（之前仅反对 QEMU 和 NEMU 作为 VMM），Kata 本人的运行时和 RunC 一样也合乎 OCI 及 CRI 标准规范，可能同时被 Docker、Kubernetes 及 OpenStack 间接反对。

在亚马逊翻新简化的领导力准则指引下，咱们还会一直为升高开源应用老本和晋升开源产品质量而不懈努力。

欢送继续关注 Build On Cloud 微信公众号，并分享你喜爱的文章，与更多开发者一起交换技术新趋势和云开发动静！

往期举荐

单干、参加、让开源更易用 | 亚马逊的开源文化
牢靠、平安、稳固，开源高质量我的项目 | 亚马逊的开源文化

作者
郑予彬
亚马逊云科技资深开发者布道师，20 年 ICT 行业和数字化转型实际积攒，专一于亚马逊云科技云原生、云平安技术畛域。18 年架构师教训，致力于为金融、教育、制作以及世界 500 强企业用户提供数据中心建设以及软件定义数据核心等解决方案的征询及技术落地。

文章起源：https://dev.amazoncloud.cn/column/article/63e5a7a62dfc3e07190…