Apr 3, 2018

An overview of Project Atomic

原文链接点击这里

像“云原生”（cloud-native）和“全网规模”（Web-scale）这样的词汇是没有意义的热门玩意儿，尽管在市场这个层面之下，如果能有一个全新的/不一样的方式去考虑系统管理的话，云系统会工作的很好。大部分的用在云操作（cloud operations）上的工具是免费的软件，很多人也会选择linux作为绝大部分的平台提供云操作。尽管几乎所有的发行版本可以正常工作，但还是有一些项目可以去新建自底而上的系统用作在云主机上，其中有一个最为人熟知的、Red Hat/Fedora项目出产的Project Atomic。

从云计算的便利性来说，其中最基本的改变常常被总结为pets VS cattle（当时两个人争论时候做的一个比喻）的道理。之前，我们关心我们自己的个人电脑，这个就是pets，因为这些个人电脑需要被保护，如果一个服务器宕机，你将会很仔细的去修复它，最坏的情况就是我们拷贝一个备份的代替原来坏了的系统。在云环境中，我们能在几秒时间内就可以创建/销毁一个主机，所以我们利用了这个优势：对待这些主机为可替代性的cattle。如果主机遇到了问题，我们可以销毁它然后创建一个新的主机代替它的功能。

处理（paradigm shift）对于容器化是一个进步，容器系统如Moby（正式说法是Docker）或者rkt（允许你部署软件通过打包成镜像的方式）和轻量级的虚拟机很像，它完成了所有包的依赖关系和所需的系统配置，容器化的/以云为基础的部署很快变为了最常见的管理策略，特别是用在web网页应用上和其他与internet相关的软件（容易水平扩展【horizontal scaling】）。

对于一次性的、跑着一些软件（所需的依赖包都打包好了）的服务器，我们没有必要去改变底层的系统，理想状况是，这些服务器只要设定一次后面就不需要再弄了，即使要更新的情况也不需要改变什么东西了。不用管理员权限就可以轻松销毁一个过期的云主机，然后再给它换上一个新的。这个模式就是“immutable infrastructure”，也可能是现代云计算下最大的技术变化了。

在典型的容器为基础的云部署上，这里有两个被linux发行版收入的级别：第一个是云主机上的操作系统，第二个是运行在容器化的主机上的linux环境，它们的内核是一样的，但是有着独立的用户空间。使用不同的发行版对应不同的软件的灵活性是虚拟化的其中一个优势，但是在产品中，安装发行版在容器里是轻量级别的，就像Alpine或者stripped down Ubuntu variant。安装在云主机的发行版需要能够运行容器，还应该能够提供针对维护和检测的各种各样的服务。

Project Atomic带来了这样一个发行版，更加通俗的说，带来的是linux云主机/容器环境下的编译工具（build tools）。Project Atomic是一个上游的项目工程，对应了OpenShift Origin的大部分组件（components），这个OpenShift Origin是Red Hat的商业化容器部署平台OpenShift。Atomic产品的主要部分是Atomic Host，它是一个在云主机（immutable状态）下运行Moby和Kubernetes下的linux发行版。

Atomic Host带来了两个优势，不过它需要用户的冒险精神（risk appetite）和也需要设定理想中的软件更新周期：第一个是由CentOS产生的，第二个是由Eedora产生的。基于底层发行版之上，Atomic Host做了很多的修改，最有意义的一个是rpm-ostree update system，rpm-tree是基于OSTree的（Git for operating systems），而且它还被集成到了熟知的Red Hat软件包管理生态系统，但是操作上有着很大的不同。理论上来说，rpm-ostree可以像容器镜像一样管理系统软件。这整个安装过程就是原子版本（atomic），然后更新在完全用新的版本去替代原来的，同时还是存留了之前的版本以便回滚。这些版本可以在Git仓库里面操作管理。 所以，有了Atomic Host的话，就不用安装一个操作系统在服务器然后安装和设置一系列的软件，因此你从Atomic Host镜像中创建一个虚拟机或者主机，这个只要一步就可以完成，最后安装Git控制系统设置。系统就可以准备开始为应用提供服务了，只要两步就可以轻松的调整云控制器（cloud orchestrator）了。当这个镜像过期了的时候，无论是更新内核还是做一些设置文件的改变，你都可以构建一个新的镜像，然后用一个新的镜像来代替跑在服务器上的文件系统。

Atomic Host的Fedora版本的变化更新速度是非常严格的每两周进行一次的，它提供了新的镜像附带了补丁和更新部分，这些改变是针对单独的软件包的。尽管CentOS Atomic SIG的一个目标是以一个特定的周期去发布，CentOS当前发布的周期是没有规律的，大约一个月一次。在传统的更新策略中，针对一个比较大的改动，用户需要使用它们作为一个系统的完全升级，为了可以收到更多关于安全方面的补丁和bug的修复代码。自从以每个包的更新方式开始后，一般是小于两个礼拜的速度进行一次。如果和Fedora和CentOS系统比较，它们可能会是Atomic Host的相对比较脆弱的地方（window）。

Composing with rpm-ostree

管理rpm-ostree的git repo包含有一系列根据包版本号和配置对云主机进行描述的文件。rpm-ostree工具用于构建整个系统，首先将这些包放入到一个文件系统中，并做好相应配置，然后整个的存储为一个镜像文件。底层的OSTree工具在构建好之后会记录文件系统的状态，而安装是通过将对应版本的整个文件系统拷贝到host上面。这样从概念上看起来比较像磁盘镜像，然而OSTree却是工作在文件系统层，这就使得它既高效，又能够利用上文件系统保留旧版本以方便对修改进行回滚的特点。

这种安装更新方式不同于我们过去所习惯的那样，总结下来有下面几个优点：1）能够保证所有host安装的软件和操作系统配置都是一样，同时也能够在还没有对生产环境产生任何修改之前做好各项测试；2）避免了大量的由于软件安装和更新带来的潜在问题，也使得自动更新更加简单；3）由于host上所有软件都是来自于带版本控制的配置，不用担心会有软件丢失，这使得替换host变得更加简单。

rpm-ostree和docker/moby一样支持image分层，当你需要在基础镜像上面安装其他软件时，对应的rpm包可以直接加在OSTree的上面，而不需要构建新镜像。这样是为了兼容管理员原有的工作方式，使得迁移到不可变更新容易些。

Atomic Host带有atomic命令，该命令是对moby的包装，使得安装和运行container镜像更加简单。atomic特别适合Moby container，带有正确元数据的container可以直接用atomic安装，而不需要之前的拉镜像、配置systemd这些步骤。

应该可以清晰看到，Atomic Host和传统的面向服务器的Linux发行版本有重大的不一样。但是对于小型环境和一次性服务器，Atomic Host看起来会很难使用，确实这些也不是Atomic Host的适用对象。Atomic Host专注于提供一个可测试的、一致的环境，而不是让单个主机拥有最大可靠性。因此对那些特别重要、不能容易替换的服务器，Atomic Host并不适合。为了真正使用到Atomic Host的优势，你所运行的应用需要能够容忍个别主机消失，并在他们可提供服务时增加新的主机。

这个修改带来的好处是能够更加简单、更加自动化的维护多台服务器。当你的应用是几乎无状态的，也能够在分钟级别重新构建，传统的系统管理工作将几乎不再需要。你的时间将能够用于全面的设计和系统配置的测试。

除了Atomic Host，Atomic Project还包含其他产品。比如Cockpit，一个用于远程管理和监控运行有Atomic Host的主机的web应用，这个应用使得能够方便的管理数十台host。

当然通过SSH或者Cockpit能够对运行中的Atomic Host进行修改，这样会使得很多不可变部署带来的优点没有，比如带来环境的不一致、几乎没有经过测试的修改。因此不可变部署也需要操作者遵守一定的纪律。快速修复的诱惑需要被克服，替换为一个经过测试的、对整个部署可控的修改。

最后Atomic Project也为开发运行Linux云环境做了不小贡献，其中一个主要例子是集成Moby和SELinux。包括Atomic Host和Cockpit，这些努力有助于Linux稳固占据云计算的前端