转载

容器VS配置管理

【编者的话】容器会取代你对配置管理的需求吗？或者说两者可以共存吗？它们应该如何共存？本文主要对比了传统的配置管理和现在比较火的容器管理之间的差别，并对两者分别进行了概括，可以让读者初步了解两者之间的区别，并感受到容器技术的力量。

每一个开发和运营团队都有着或多或少相同的目标，编写干净的、可维护的和高性能的代码、尽可能频繁的部署代码而没有宕机，以及给用户带来极速和愉悦的体验并且可以扩展来满足需求。不断的部署而没有宕机并且持续扩展来满足需求，谈何容易。如何实现这些目标的方法少说也有几百个，这需要建立一个托管平台，这个平台上要有大量系统管理员过去通常手工操纵的东西。

现在平台这个术语有些被过度使用和加载了，当你去思考平台是什么的时候，它实际上是运行你的代码的计算机以及如何去部署它们。你的平台可能是你机箱里的一台服务器、一些shell脚本、公共PaaS的供应商提供给你的一切或者众多人选择的AWS和其他托管服务提供商提供给你的东西。

配置管理回顾

直到大约一年之前，优质的标准以及理论上最好的方法是使用配置管理系统来自动化你的服务器基础设施以及部署工作流，一些比较流行的系统包括：

Chef
Puppet
Salt
Ansible
CFEngine

使用配置管理系统，你需要编写代码来描述你希望如何安装和配置系统的一些组件。当你在服务器上执行代码的时候，它应该在理想状态下结束运行。使用这种系统的好处是你可以抽象掉一些在各种不同的操作系统处理像包管理这样的功能时所带来的不同。

例如，你可以写一个bash脚本用来在Ubuntu或Debian上安装libxml2：

#!/bin/bash
 apt-get install -y libxml2

但是，当你在CentOS或者Fedora上使用这个脚本的时候会发生什么呢？它将不能够正常运行，因为这些发行版使用不同的包管理器。

取而代之，你可以用Chef写一个代码块，它可以抽象掉不同的发行版之间的差异。你可以在libxml2包存在的任何地方执行这个相同的Chef recipe，它都会正常运行。

package “libxml2” do
 action :install
 done

用以部署的配置管理

因为我对Chef非常熟悉并且在脑海中仍然记忆犹新，所以我将讨论一下它的配置资源和我在使用时碰到的一些陷阱。Chef的配置资源基于Capsitrano，Capsitrano被视为代码部署的最好选择，所以我这里所写并非是要唠叨它。

在你的Chef recipe代码中，配置资源的语法其最简单的形式看起来像这样：

deploy 'private_repo' do
 repo 'git@github.com:acctname/private-repo.git'
 user 'ubuntu'
 deploy_to '/tmp/private_code'
 ssh_wrapper '/tmp/private_code/wrap-ssh4git.sh'
 action :deploy
 end

chef-client通过某种方式的循环保持单一运行时，在同一个服务器上部署多个项目的现象并不少见。

一个这样的简单示例如下：

%w(project1 project2).each do |project|
 deploy ‘#{project}’ do
  repo 'git@github.com:acctname/#{project}-repo.git'
  user 'ubuntu'
  deploy_to '/var/www'
  ssh_wrapper '/tmp/private_code/wrap-ssh4git.sh'
  action :deploy
 end
 done

对于这种方式如何结束运行，存在一些问题：

如果项目1由于某种原因部署失败，比如git的仓库权限问题，而你没有为此构建错误处理，则会导致后续的部署接连失败。
如果你必须通过bundler、npm或者类似的工具构建部署模块，势必运行会非常缓慢，在某些情况下可能会花费几分钟甚至更长。如果模块构建失败，Chef会崩溃，除非你非常明智地提前为这种情况构建了错误处理。
通常情况下，从git拉取很慢。
如果Github崩了，你就无法部署。如果你正在新服务器的引导过程中自动扩展和部署代码，碰到这种情况是非常糟糕的。

围绕这些问题有很多解决办法，比如提前构建模块并将其存储在向s3这样的对象存储库中，将你的recipe拉到本地解压而不是在云端构建他们。还有一些人将他们的Github仓库映射到一个本地服务器，然后从本地服务器拉取。总体来说，我的观点是，使用配置管理工具来部署让人非常厌恶并且容易出错。

容器回顾

容器是时下的新宠，但它绝不是一项新技术。从2.6.24版本开始，由于加入了cgroup的支持，linux内核已经支持容器。谷歌已经使用了十几年来支持他们巨大的全球性基础设施。在过去的两年里，像Docker这种初创公司以及一些大型企业如红帽，亚马逊，谷歌和IBM在他们的主机产品中增加了对容器的支持，这已经使得容器在开发者和运维工程师中成为了最流行的话题。通过使用Linux中现有的工具如cgroups和 namespace，并且使得它们对于普通用户来说更加简单和方便，Docker产生了巨大影响。

容器使应用程序的跨平台可移植性比以往任何时候都更容易，通过允许在开发工作站上构建和测试的同一镜像运行在生产环境中，解决了开发环境与生产环境差异的老问题。作为曾经的运维工程师，我不记得已经听到过多少次这种声音，“生产环境出问题了…代码在本地运行的很好”。这就造成了开发人员编写代码和运维团队部署代码出现分歧而不是相互协作的现状。

用以部署的容器

相比配置管理系统来说，特别是谈到部署的时候，容器有着明显的优势。

所有原本在你的cookbook、playbook、manifest等文件中的逻辑现在都写在Dockerfile中，Dockfile直接依附于应用的仓库，它被设计用来构建。这就意味着，事情会更加条理并且管理git仓库的人也可以修改和测试应用程序的自动化。
对于开发者来说，容器或是Docker比他们绞尽脑汁去折腾本地部署要容易的多，它消除了整个团队要理解如何使用你所选择的、与Vagrant紧密联系的配置管理系统的需求。
所有应用程序的依赖关系都与容器捆绑，这就意味着在部署的时候没有必要在云端的每台服务器上去构建。这会使得部署和回滚更加迅速。
由于无需每次部署都从git上拉取，这就消除了Github中断的风险并且使你避免了无法部署。当然，如果你依赖 DockerHub 或其他托管镜像注册表，还是会有可能碰到这个问题。
容器促成标准化，这使得像集中式日志记录，监测和指标这样的系统，无论容器中运行的是什么，都能够轻松地卡入到位。总的来说，这将对部署时的问题监测以及轻松地推行这类监控解决方案的能力产生巨大影响。

但是，仍然有些不足，对吗？嗯…是的。

Dockerfile不会给你同配置文件一样的控制权，因为你的应用程序在各个环境如dev、staging、production之间切换。你会遇到这种情况，你的Dockerfile必须根据环境变量调用外部脚本来编辑云端中Docker镜像里的配置文件。在某些情况下，你甚至可能需要针对每个环境编写不同的Dockerfile，如果你的应用程序没有遵循“ 十二要素应用宣言 ”的最佳实践，这通常会是一个问题。
关于 Docker的安全模式，有很多负面的说法，即使在运行过程中孵化出一个竞争性的容器。虽然最近有可能在容器内确认各个层的校验和，但是从长期来看，这是不可能的。一些掌控中间层的人可能毫不费力就能污染下层容器。

配置文件和容器可以兼容吗？

当然可以。

即使不是全部的也有相当大的一部分流行的配置管理系统拥有针对Docker集成的hooks。Chef有一种集成方案，允许你使用Chef cookbook和recipe构建Docker镜像以及管理如何把你的容器部署到服务器上。Ansible也有完成类似目标的集成。

有些情况下，我会说：“是的，可以同时使用两者”：

你已经使用了其中一种配置管理系统并且你想尝试使用容器。

这将是很容易的尝试，你可以得到一些即时的反馈，看看是否要继续深入到更加复杂或全部功能的主机平台。对于你的基础设施，所有需要你真正改变的是增加Docker并将它作为应用程序的包装，你会继续以同样的方式将它们部署到同一服务器。虽然这样有些不妥，但因为使用了群集托管平台，便可以显著提高资源利用率，并能为你节省很多资金。