前段时间在DockerOne回复了一个关于 CoreOS 升级的提问。仔细琢磨来，这个问题还有不少可深入之处，因此有了此文，供已经在国内使用 CoreOS 的玩家们参考。
具有CoreOS特色的系统升级CoreOS的设计初衷之一就是“解决互联网上普遍存在的服务器系统及软件由于没有及时升级和应用补丁，造成已知漏洞被恶意利用导致的安全性问题”。因此，它的升级方式在各种Linux发型版中可以说是独树一帜的，特别是与主流的服务器端系统相比。
平滑升级一方面来说，常用的服务器系统如RedHat、CentOS、Debian、Ubuntu甚至FreeBSD和Windows Server都存在明确的版本界限，要么不能支持直接在线升级至新的发行版本，要么（如Debian/Ubuntu和Windows 7以后的版本）虽能够跨版本升级却容易出现兼容性风险，一旦升级后出现故障往往面临进退两难的局面。
这个问题在一些新兴的Linux发行版，如Arch Linux已经有了较先进的解决方法：将过去累计许多补丁再发行一次大版本的做法变为以月或更短周期的快速迭代更新，并由系统本身提供平滑升级和回滚的支持。这样，用户可以在任何时候、从任何版本直接更新至修了最新安全补丁的系统。然而，这些以 Arch 为代表的平滑升级系统还是带来了一些更新系统后无法使用的事故，不妨在百度以“Arch 升级问题”关键字搜索会发现许多类似的抱怨。事实上，Arch的目标用户主要是喜爱尝鲜的Linux爱好者而不是服务器管理员或者服务端应用架构师。
那么平滑升级的思路是不是在服务器系统就走不通了呢。其实仔细分析平滑升级出现问题的原因，当中最关键的一个因素在于，系统设计时最多只能确保从一个干净的系统顺利升级的途径，如果用户对系统中的某些核心组件做了修改（比如将系统中的Python2升级成了Python3），它就不属于操作系统设计者控制范围内的工作了。这样相当于设定了一个售后服务霸王条款（只是个比喻，这些Linux系统其实都是免费的）：自行改装，不予保修。
在过去，用户要使用服务器系统，他就必然需要在上面安装其他的提供对外服务软件和程序，因此对系统本身有意无意的修改几乎是无法避免的。这个问题直到近些年来应用容器（特别是Docker）的概念被大规模的推广以后才出现了新的解决思路。而CoreOS就是通过容器巧妙的避开了用户篡改系统的问题，提出了另一种解决思路：让系统分区只读，用户通过容器运行服务。不得不说，这简直就是以一个霸王条款替代了另一个霸王条款，然而这个新的“条款”带来的附加好处，使得它被对稳定性和安全性都要求很高的服务器领域而言接受起来要心安理得的多。
“反正许多东西都要自动化的，套个容器又何妨。” 恩，就这么愉快的决定了。
自动更新另一方面来说，除了系统的大版本升级，平时的系统和关键软件的小幅补丁更新也时常由于系统管理员的疏忽而没有得到及时运用，这同样是导致系统安全问题的一个重要因素（比如2014年BrowserStack中招的这个例子）。
这个解决思路就比较简单了：自动更新。这么简单的办法当然早就被人用过了。即便在操作系统层面还见得不多，在应用软件上早都是烂熟的套路。那么，为了不落俗套，怎样把自动更新做得创意一些呢。先来看看系统升级都会有哪些坑。
乍一看来，操作系统这个东东和普通应用在升级时候会遇到的问题还是有几分相似。比如软件正在使用的时候一般是不可以直接热修补的，系统也一样（Linux 4.0 内核已经在着手解决这个痛点了，因此它在未来可能会成为伪命题）。又比如软件运行会有依赖，而系统的核心组件之间也是有依赖的，因此一旦涉及升级就又涉及了版本匹配问题。除此之外，它们之间还是有些不一样的地方。比如许多应用软件其实可以直接免安装的，升级时候直接把新文件替换一下旧的就算完成了。操作系统要想免安装，则需要些特别的技巧。
下面依次来说说CoreOS是怎样应对这几个坑的。