是DevOps还是彼此割裂?Docker、OpenStack，还有配置即服务
【原文编者的话】：
这是Mirantis.com网站系列技术连载文章的第一篇，主要介绍了针对DevOps模式，OpenStack可以做哪些事情?相比Kubernetes、Mesos这些容器管理工具，通过OpenStack Heat项目所能够实现的功能与场景。
风头正劲的Docker和围绕其展开的宣传活动揭示了开发者向云转型的一个关键性动机，即人们不愿意在繁琐的配置上花费过多的精力。为应用设置网络许可权限、操作系统的兼容性、库对服务的依赖性、数据持久性的要求、注册表项，以及让Docker正常运行的各项重要参数都让用户感到非常头疼。听起来似乎OpenStack和DevOps更胜一筹。
是的，OpenStack可以提供必需的自动化，详细易懂的ReST API能够让配置安全地暴露在几乎所有的管理工具或是开发环境中。DevOps目前相处得非常融洽。找一本关于亚马逊的DevOps书籍，让开发人员阅读它们。开发人员负责创建，运营人员负责管理。
让我们仔细看一下DevOps神话将我们引入歧途的方式。这些方式包括：
- 让开发人员从事所有软件定义的东西;
- Docker vs DevOps;
- 编排的问题;
- OpenStack Heat项目和Murano项目是如何帮助开发者解决这一问题的;
我们是如何陷入烂摊子的?
对于开发者来说，针对底层云服务的所有优秀ReST API，似乎是一件可将OpenStack变成杀手级应用的秘密武器。选择你的虚拟机、网络配置、存储(可以随意调整它们)，选择动态迁移，然后迅速执行。整个数据中心都是你手中的玩具。开发者可以通过软件定义数据中心，挑选适合他们应用的资源，确保企业在软件经济时代能够从IT中获得价值。
然而不幸的是，依靠应用来决定构成主机环境的硬件和操作系统，使得“以应用为中心”的解决方案成为了导致现代企业IT陷入混乱的主要原因。通过让开发者编写数据中心API的方式，让开发者去承担软件经济中的竞争责任，似乎注定要以失败收场。
为什么会如此艰难呢?每次配置一个Linux服务器来运行一个应用看起来是非常容易的。但是在第二次、第三次和第四次之后，任何称职的开发者都希望让管理员来接手这一工作。那么配置一个由相互关联的虚拟机(每一台虚拟机都运行自己的服务)组成的大型云架构，或是配置一个频繁变化的云架构，情况又是什么样子呢?
问题会接踵而至。正如我们所看到的一样，让开发者通过填写IT表单和申请基础设施，来解决这个问题是不会有什么效果的。(不幸的是，目前这种做法非常普遍。)这种情况需要的是一个更程序化的解决方案。这给了OpenStack一个用武之地。
DOCKER VS. DevOps
软件定义数据中心需要多少编程工作呢?如果问一下开发者，他们的回答是宁愿没有。编写docker pull oraclelinux胜过详细规定30多个启动参数。然而，运行甲骨文的人可能未必会重新部署一个纯粹基于docker的云。OpenStack不能让这一切变得简单起来吗?
容器中的应用Docker化会涉及许多方面。它们的特色功能之一就是，可以通过dockerfile简化配置。在这种比较详细的结构中，设置运行时配置可以缓解这个问题，至少对于容器化环境是这样的。
但是关于DevOps的讨论在很大程度上被引向了一个错误的方向。DevOps的本意是协调开发者和运营者的利益，其中所蕴含的文化就是彼此互相尊重。但是我所听到的这类讨论似乎都是在说“运营者来自火星，而开发者来自金星”。
双方的差异是难以调和或者是克服的。开发者是以代码为导向，而运营者则是以脚本为导向。实现方面，OpenStack在其出现的4年半时间里，能够克服许多差异，主要是因为开发者认为，他们能够通过程序解决所有的运营问题。即便是Cloud Foundry这样的PaaS环境，也必须采取一些非中立的举措以解决简化配置，防止开发者陷入配置混乱的困境当中。由于云原生应用12个因素(创建 SaaS应用的重要方法论)的限制，我们根本无法对其彻底重新编写。因此IT仍然存在难以逾越的丛林地带。
运营者从开发者那里学到的经验是对待配置的方式。Docker通过一种很好的方式为人们带来了希望。
不要考虑编排，要使用Heat
对于许多公司来说，寻找和部署能够在OpenStack上运行的工作负载，存在的挑战是——该技术存在部署的障碍。存在于现有系统中的许多企业价值(以及它们所支持的人和程序)，使得它们无法很容易地向云或是向软件定义数据中心转型。
在OpenStack开发者那里泊来的术语中，“编排”(Orchestration)这个词在这里会产生很大的误解。它们是指序列化依赖关系所产生的复杂活动顺序。而Heat围绕的不是顺序，而是状态。
我们同样需要明确“配置”(Configuration)这一术语的含义。它们不是指一个活动，而是指一种状态。在云基础设施中，它们是处理配置的唯一方式。因为配置的初始状态是所有应用启动的关键点。这代表着一个重要变化，即在部署、配置和运营领域中有许多必需的东西。例如，Chef、 Puppet、Ansible、SaltStack等部署工具是编辑复杂操作顺序的前提，目的是让它们具有可重复性。
但是确保可重复性的最可靠办法是——消除活动组件。OpenStack编排项目Heat被设计用于专门解决该问题。在计算术语中，Heat 编排模板(HOT，Heat Orchestration Template)为陈述性的，而非是强制性的。
Heat编排模板(HOT)不包括顺序信息，相反其可被解读为固定时间点上的一种固定状态。在这里，“编排”更像是在音乐会中所起的作用，一方面它们有点像乐谱。它们为每个服务分配角色、价值，以及在OpenStack云中的参数。另一方面，它们又不完全像乐谱，除非整个乐队只演奏一个音符。
Heat模板和dockerfile的角色有点相似，但是它们之间有一个关键性区别。那就是dockerfile的范围为一个单个的机器镜像，而 Heat的范围则是一个完备的IaaS环境，其中包括丰富的网络选项、存储、分布式处理流程等。还有一点就是，Heat模板适用于CRUD操作，所以我们可通过版本管理对简单配置进行前滚和后滚。
换句话说，这是“配置代码化”(configuration as code)的一个锚点，套用时髦的话说就是“配置即服务”(configuration-as-a-service)。与dockerfile相似的地方是，Heat为运行服务所需的配置提供了一个明确的定义。Docker传递给DevOps世界最有价值的经验是：每一个Docker容器都有一个确定且透明的dockerfile。对于每一个OpenStack工作负载，要有一个确定且透明的Heat模板。换而言之，应用部署要与其配置捆绑在一起。
与Docker不同的地方是，Heat从事的是多个底层服务，而不是陈述单个虚拟机的需求及其关联性。多个Docker容器需要一个配置集吗?正如我们之前在其他地方所说的那样，这是PaaS要做的事情。Kubernetes能够做这样的工作。Mesos也能够做这样的工作。但总的来说，OpenStack为这些服务的运行提供了一个更加通用的平台。