大数据/交付的实用DevOps
在这本书中，我们一直专注于设计工作，而大多数情况下这些工作都在我们的IDE中进行。所有分析都在开发空间中进行，而且没有运行一行代码。但是，设计和开发的目的是创建一个可以在某个数据中心或基础设施上运行的应用程序，以便我们可以使用应用程序的功能。因此，在本章中，我们将研究安装、启动和测试应用程序的方法和工具。
在典型的模型驱动方式中，部署模型提供了应用程序的精确表示。使用 部署特定建模方法 是一个良好的开端。部署模型包含构成应用程序的所有部分，因此我们需要能够读取此模型并采取步骤来设置应用程序的工具。这些工具的预期结果是模型中描述的资源的实例化，这些资源被指定为与这些资源相关联的服务所占用。
在获得能够部署应用程序的工具之前，通常还有一个步骤：将模型转换为目标工具可理解的格式。工具通常更喜欢一种更紧凑和针对性的语言，而不是UML表示，这种语言通常被称为领域特定语言 (DSL)，[1] 用于准备DIA的蓝图。我们将使用OASIS TOSCA，[2] 这是一种新兴的行业标准，用于描述可移植且可操作管理的云应用程序。其优点之一是它能够灵活地使用，并且能够扩展可用术语以适合特定领域，例如大数据。
我们将用于部署DIA的工具需要提供对管理部署的简单访问，并需要提供可重复且可靠的DIA部署操作。
DIA由许多支持服务和技术组成，我们通常在这些服务和技术之上运行一些自定义用户代码。DIA设置的复杂性是应用程序本身需求的函数。但是，无论我们有一个简单的应用程序，它只将数据存储在NoSQL存储中，还是一个多层构建块堆栈，都需要有人或某些东西来安装和启动所有组件。在DevOps环境中，我们使用云编排工具[3] 来自动化此过程。
单独的开源服务和工具附带了有关如何设置和配置服务的详细说明。手动执行此操作需要时间和技能，而这些时间和技能通常在刚开始进入数据密集型应用程序开发世界的团队中缺乏。学习部署服务的需要与学习如何充分利用服务本身的需要大多是正交的。因此，任何帮助加快或完全取代部署步骤的措施都可能成为主要的节约时间和成本的因素。
在DevOps中自动执行部署过程的需要带来了基础设施即代码的概念，[4] 它能够将整个平台的蓝图存储在版本化存储库（如GIT）中。这带来的一个巨大好处是，我们对DIA部署后的样子有一个单一的事实来源。
用TOSCA YAML编写的蓝图可以包含组成DIA的各个组件的任何数量的详细信息。但是，就像传统的应用程序源代码一样，蓝图也不应该重复可以在更低抽象级别表示的概念。这些可以打包到TOSCA库中，该库可以作为插件导入到每个蓝图中。
配置和部署的自动化并不新鲜，因为各种形式的批处理脚本已经存在了几十年。这传统上是配置自动化的命令式方法，其中脚本描述了需要按顺序运行的一系列指令。一种更新但已经广泛使用的方法是使用声明式方法，我们专注于描述系统的期望状态。
部署复杂系统的最佳方法是将流程分解，使不同的工具专注于系统的不同级别。从基础设施级别开始，即计算、网络和存储资源，我们可以从许多配置管理[5] 工具中进行选择：Chef，[6] Puppet，[7] Ansible，[8] 等等。这些工具使用cookbook、playbook等名称的定义作为安装和配置过程的源代码。然后，用户或编排器会执行这些定义的单元（例如Chef cookbook的配方）以在系统的状态之间进行转换。
为了管理云应用程序（如大数据应用程序），我们需要一种更高级的方法，它采用云编排器[3] 的形式。一些配置管理器，如Ansible或Chef，已经具有一些编排功能。这确保了相互依赖项以正确的顺序设置并配置为正确地互相发现。例如，Web应用程序需要首先配置Web服务器，然后在另一个节点上设置并运行数据库。这是由编排器工具完成的，其代表包括Ubuntu Juju，[9] Apache Brooklyn[10] 和Cloudify。 [11]
这些工具只是交付自动化的一个部分。另一个关键部分是配方、playbook、插件和蓝图类型定义。每个工具都有一个供应商自己的社区或社区对配置和编排代码的大型存储库或市场进行的贡献。以这种方式提供的材料的质量会有所不同，并且不同配方的兼容性并不总是得到保证。但这是使用技术和原型制作进行初始实验的有价值的来源，只要我们有时间研究每个cookbook或playbook。
DICE交付流程旨在使与编排的交互尽可能简单。我们从TOSCA YAML格式的应用程序蓝图开始。我们可以自己编写此文档，但遵循DICE方法并将部署特定模型使用DICER转换为等效的YAML蓝图会更好。在每种情况下，蓝图看起来都类似于以下示例
tosca_definitions_version: cloudify_dsl_1_3
imports:
- https://github.com/dice-project/DICE-Deployment-Cloudify/releases/download/0.7.2/full.yaml
node_templates:
mongo_fw:
type: dice.firewall_rules.mongo.Common
standalone_vm:
type: dice.hosts.ubuntu.Medium
relationships:
- type: dice.relationships.ProtectedBy
target: mongo_fw
standalone_mongo:
type: dice.components.mongo.Server
properties:
monitoring:
enabled: true
relationships:
- type: dice.relationships.ContainedIn
target: standalone_vm
accounts_db:
type: dice.components.mongo.DB
properties:
name: accounts
relationships:
- type: dice.relationships.ContainedIn
target: standalone_mongo
outputs:
mongo_access:
description: Mongo client connection details
value:
concat:
- "mongo --host "
- get_attribute: [ standalone_mongo, fqdn ]
- :27017
此蓝图由节点模板组成，其类型基于DICE技术库中的定义，例如
dice.hosts.ubuntu.Medium：表示中等大小的计算主机。dice.firewall_rules.mongo.Common：一个用于定义网络安全组或防火墙的节点类型，以便只有MongoDB通信所需的端口是可访问的，并且这包括对等引擎服务和任何客户端。dice.components.mongo.Server：包含所有构成独立 MongoDB 引擎实例的 MongoDB 相关模块的组件。dice.components.mongo.DB：代表 MongoDB 引擎中的数据库。dice.components.mongo.User：MongoDB 集群中的用户。
许多节点模板需要与另一个节点模板建立关系。我们使用以下关系类型来实现这一点
dice.relationships.ProtectedBy：此关系的源是计算主机，目标是定义安全组或防火墙的 dice.firewall_rules 节点模板。dice.relationships.ContainedIn：可以将与服务相关的节点模板连接到计算主机，或将数据库连接到 MongoDB 等数据库引擎。dice.relationships.mongo.HasRightsToUse：允许源用户节点模板使用目标数据库节点模板。
更多 蓝图示例 可用。
部署服务概念
[edit | edit source]部署是在目标基础设施中实例化蓝图。云编排器可以生成一个或多个并发或串行（即，由于创建了新的部署，因此销毁了前一个部署）部署。为了简化部署管理，DICE 部署服务 使用虚拟部署容器的概念。提交到特定虚拟部署容器的蓝图将导致与该虚拟部署容器关联的部署。提交到同一虚拟部署容器的新蓝图将导致一个新部署，该部署将替换上一个部署。
如上图所示，蓝图 B.1 之前已部署在虚拟部署容器 2 中。但随后用户改进了应用程序，导致蓝图 B.2 出现。将此蓝图提交到虚拟部署容器 2 后，之前的部署已被删除，并安装了新的部署。此更改使虚拟部署容器 1 中的部署保持不变。用户可以根据需要创建任意数量的容器，例如用于个人试验新技术、持续集成中的特定分支，或用于对新版本进行手动验收测试。
DICE 部署服务 和 DICE TOSCA 技术库的另一个功能是它能够部署到任何支持的云基础设施。在蓝图中，用户可以指定要部署到的平台类型（例如，OpenStack 或 Amazon EC2），并且这对于蓝图中的不同组件可以不同。对于未明确指定目标平台的节点，DICE 部署服务使用其默认目标平台。在这种情况下，相同的蓝图可以提交到不同的云提供商，而无需更改蓝图。在上图中，我们将蓝图 B2 提交到两个不同的云提供商。如所示，任何平台特定输入参数均由 DICE 部署服务提供。数据中心管理员负责将其设置为正确的值。另一方面，设计人员和开发人员不需要处理此类细节。
在幕后，实际的蓝图部署将提交到 RESTful 服务，该服务使用任何平台特定的细节来增强蓝图。然后，实际的蓝图编排由 Cloudify 执行，[11] 它负责在执行部署工作流之前拉取技术库和 Chef 食谱的相关元素。上图说明了使此工作流成为可能的服务的体系结构。
开放性挑战
[edit | edit source]所呈现的部署服务和 TOSCA 技术库的结合极大地加快了应用程序的准备和设置，这些应用程序是由支持的技术组成的。但是，许多数据密集型应用程序将结合库中支持的组件以外的其他第一方和第三方组件。
TOSCA 技术库通过为自定义（bash 或 Python）脚本提供节点类型来为某些自定义元素提供快捷方式。但这些仅适用于非常简单的自定义。由于过于简单，使用它们无法提供 TOSCA 蓝图的全部功能。结果是，此类蓝图中更大的部分成为强制性的，而不是本来必须的。解决此类问题的更简洁方法是在库级别应用扩展和更改，但这需要用户具备更高的技能和知识。
DICE 交付工具集的主要优势是它提供开源解决方案的部署，作为一个易于使用的构建块集合。但同时，这也是一个弱点，因为库中的定义仅与其提供者对其进行的更新一样最新。由于这不是服务的原始供应商，因此采用者面临落后于主流大数据服务发展的风险。
应用领域：已知用途
[edit | edit source]DICE 部署服务与 DICE TOSCA 技术库相结合，可用于各种工作流。它还可轻松满足各种大数据应用程序的需求。以下是一些建议用途。
Spark 应用程序
[edit | edit source]DICE TOSCA 技术库包含构建块，其中包括对 Apache Spark 的支持，[12] Apache Storm，[13] Hadoop[14] 文件系统，Hadoop Yarn，Kafka，[15] Apache Zookeeper，[16] Apache Cassandra[17] 和 MongoDB。 [18] 这意味着任何需要这些技术子集的应用程序都可以用 TOSCA 蓝图表示并自动部署。
例如，Storm 应用程序蓝图 显示了如何将所有必要成分一起表示
- 目标是部署和运行包含已编译的 WordCount 拓扑 Java 代码的
.jar文件。这封装在wordcount节点模板中。 - 执行此程序的平台由 Storm 节点组成：Storm Nimbus 节点（由
nimbus节点模板表示）和 Storm Worker（storm节点模板）。 - 为了使 Storm 正常工作，我们还需要在集群中使用 Zookeeper。蓝图将其定义为
zookeeper节点模板。 - 所有这些服务都需要专用的计算资源才能运行：
zookeeper_vm、nimbus_vm和storm_vm。 - 在网络资源方面，蓝图定义了哪些端口需要打开才能使服务正常工作：
zookeeper_security_group、nimbus_security_group、storm_security_group。为了方便起见，我们还在公共网络地址上发布 Zookeeper 和 Storm Nimbus：zookeeper_floating_ip和nimbus_floating_ip。
使用持续集成的部署
[edit | edit source]DICE 部署服务是一个 Web 服务，但它也附带一个 命令行工具。这使得从持续集成引擎中简单地使用成为可能。在这里，我们展示了 Jenkins[19] 管道[20] 的示例，该管道构建并部署了 Storm 应用程序。
pipeline {
agent any
stages {
stage('build-test') {
steps {
sh 'mvn clean assembly:assembly test'
}
}
stage('deploy') {
steps {
sh '''
dice-deploy-cli deploy --config $DDS_CONFIG \
$STORM_APP_CONTAINER \
blueprint.tar.gz
dice-deploy-cli wait-deploy --config $DDS_CONFIG \
$STORM_APP_CONTAINER
'''
}
}
}
}自动化部署的主要承诺是使操作人员的生活和工作更轻松。这种方法的力量在于它使大多数任务能够自动完成 - 无需系统管理员过多干预。这对应用程序交付速度有巨大的积极影响。我们几乎可以谈论 NoOps 方法，在这种方法中，系统操作员只需要设置服务并在基础设施的资源池中配置必要的配额。从这一点开始，开发人员或测试人员可以以自助方式使用交付工具。
此外，能够一致且可重复地部署相同应用程序是能够将应用程序的（重新）部署集成到更大的工作流中的重要因素。特别是，它使持续集成成为可能，在这种情况下，只要开发人员将新更新推送到存储库分支，应用程序就会重新部署到测试平台。该应用程序也可以定期测试，安装和清理都是工作流程的一部分。这为执行质量测试（如本书后面所述）和集成测试提供了许多可能性。