让开发自动化: 部署自动化模式

让开发自动化: 部署自动化模式 用于实现简便部署的模式

文档选项 <!--START RESERVED FOR FUTURE USE INCLUDE FILES--><!-- this content will be automatically generated across all content areas --><!--END RESERVED FOR FUTURE USE INCLUDE FILES--> 级别： 初级 Paul Duvall, CTO, Stelligent Incorporated 2009 年 2 月 10 日 Java™ 部署常常很混乱，容易出现错误，需要许多手工操作，这会延误向用户交付软件的时间。本文是分两部分的 让开发自动化 系列文章的第 1 部分。在本文中，自动化专家 Paul Duvall 将介绍用于开发可靠、可重复且一致的部署流程的一些关键模式，帮助读者为 Java 应用程序生成简便的部署。 <!--START RESERVED FOR FUTURE USE INCLUDE FILES--><!-- include java script once we verify teams wants to use this and it will work on dbcs and cyrillic characters --> <!--END RESERVED FOR FUTURE USE INCLUDE FILES--> 软件部署常常被视为不可避免的麻 烦，可以在遇到它时应付一下，以后就不用理会了。但是，与开发周期的其他部分一样，可以并且应该对部署应用软件工程原理。在手工进行部署时，部署是一个重 复且容易出现错误的流程。正如可以通过自动化构建来减少错误并加快软件开发，也可以通过自动化部署流程来减少错误和加快软件交付。 在前面的一期让开发自动化 “使用自动化加速部署” 中，介绍了一种把软件远程部署到多个目标环境中的技术。本文在更高的层面上讨论自动化部署。正如存在一些用于软件开发的模式，也有一些用于部署的模式。在过去几年里，我一直在收集和整理这些模式。在第 1 部分中，我将介绍 8 个部署模式并提供相关示例： Repository，这个模式在一个集中的存储库中管理所有配置文件，这样就可以使用 Scripted Deployment 生成有效的软件 Scripted Deployment，这个模式通过脚本执行所有部署操作，这样在执行部署时就不需要人为干预 Single Command，这个模式减少部署的复杂性，确保实现部署流程的无头执行（Headless Execution） Tokenize Configuration，这个模式提供一种可重复的把可变信息注入配置文件中的方法 Externalized Configuration，这个模式可以一次性地 输入在目标环境之间有差异的信息 Template Verifier，这个模式帮助确保所有目标环境属性都是相同的 Headless Execution，这个模式提供一种在自动化流程中安全地访问多台机器的方法 Unified Deployment，这个模式帮助建立可以在许多目标环境中运行的单一部署脚本 第 2 部分将介绍更多的部署模式。 关于本系列 作为开发人员，我们致力于为用户自动化流程；但许多开发人员疏忽了自动化我们自己的开发流程的机会。为此，我们编写了 让开发自动化 系列文章，专门探讨软件开发流程自动化的实践应用，为您介绍何时 以及如何 成功应用自动化。 图 1 说明本文讨论的部署模式之间的关系： 图 1. 部署自动化模式 我将依次讨论每个模式。在这个过程中，您会逐渐理解图 1 中显示的关系。 把所有文件提交给一个版本控制存储库 名称：Repository 模式：所有文件都被提交给版本控制存储库 — 在部署上下文中，这是指所有配置文件 和工具。 反模式：一些团队把这些信息放在一个具有访问控制的共享驱动器上。其他团队可能仅仅把信息放在自己的机器上，然后把它们复制到目标环境中。 作为一般规则，我建议开发团队签入创建软件所需的所有 文件。有时候，这个规则有一些例外情况，但是不常见。在部署上下文中，一些团队错误地认为服务器和服务器配置是固定不变的资产。尽管有时候签入大的二进制 代码比较困难，但是应该把配置、数据库脚本以及所有构建和部署脚本提交给版本控制存储库。使用 Repository 模式对于实现下面讨论的 Scripted Deployment 和 Single Command 模式很有帮助。 回页首 用脚本执行所有部署流程 名称：Scripted Deployment 模式：在脚本中编写所有部署流程。 反模式：一些团队可能手工配置部署任务，比如安装和配置 Web 容器。其他团队可能使用容器提供的基于 GUI 的管理工具针对特定环境修改容器。尽管这种方式最初可以简化配置的手工修改，但是如果要在许多目标环境中频繁地执行部署，这就不合适了。另外，在首次 使用时，基于 GUI 的管理工具对于部署非常有帮助。但是，因为许多人必须重复执行这些流程，所以这种方式的可伸缩性很差且容易出现错误。 清单 1 通过实现 Scripted Deployment 模式对启动（或重新启动）Tomcat Web 容器的流程进行自动化。这个流程是用 Apache Ant 构建脚本语言编写的。 清单 1. 启动 Tomcat Web 容器的示例 <available file="@{tomcat.home}/server/@{tomcat.server.name}/bin" property="tomcat.bin.exists"/> <if> <isset property="tomcat.bin.exists"/> <then> <echo message="Starting tomcat instance at @{tomcat.home} with start_tomcat" /> <exec executable="@{tomcat.home}/server/@{tomcat.server.name}/bin/start_tomcat" osfamily="unix" /> </then> <else> <echo message="Starting tomcat instance at @{tomcat.home} with startup.sh" /> <exec osfamily="unix" executable="chmod" spawn="true"> <arg value="+x" /> <arg file="@{tomcat.home}/bin/startup.sh" /> <arg file="@{tomcat.home}/bin/shutdown.sh" /> </exec> <exec executable="sh" osfamily="unix" dir="@{tomcat.home}/bin" spawn="true"> <env key="NOPAUSE" value="true" /> <arg line="startup.sh" /> </exec> <exec osfamily="windows" executable="cmd" dir="@{tomcat.home}/bin" spawn="true" > <env key="NOPAUSE" value="true" /> <arg line="/c startup.bat" /> </exec> <sleep seconds="15" /> </else> </if> 通过脚本执行这个流程，就不再需要在 Tomcat 提供的 GUI 管理界面中执行操作。另外，因为这个流程已经脚本化了，可以在全面的自动化部署中通过无头流程运行它。 回页首 通过单一命令运行部署 名称：Single Command 模式：部署者或无头流程只需输入单一命令，即可为用户生成有效的软件。 反模式： 某些部署流程要求部署者输入多个命令并完成多个流程，比如复制文件、修改配置文件、重新启动服务器、设置密码等等，这些重复的操作很容易出现错误。如果他 们走运，手头有详细的文档，能够指导他们执行这些操作。但是无论如何，要求人员执行部署流程都会增加出错的风险，导致时间瓶颈，延误软件在多个目标环境中 的发布。 开发环境不等于生产环境 即使软件能够在开发环境或 QA 环境中正常工作，也不意味着它会在生产环境中正常工作，因为环境之间可能存在各种差异。这就是为什么通过脚本执行所有部署工作是很重要的。 在编写部署时，您的客户常常是团队、组织和公司中的其他人 — 甚至可能是计算机。运行部署的方法越复杂，别人或无头流程成功执行它的可能性就越小。清单 2 给出一个简单的单一命令部署示例： 清单 2. 使用 Ant 执行单一命令部署 ant -Dproperties.file=$USERHOME/projects/petstore/properties/dev-install.properties \ deploy:remote:install 清单 2 中的命令执行一个名为 deploy:remote:install 的 Ant 任务，并传递一个与环境相关的 .properties 文件，从而把软件远程部署到其他计算机上。这个任务执行的操作包括使用 Secure Copy protocol (SCP) 安全地复制文件；通过 Secure Shell (SSH) 在远程计算机上安全地执行命令；安装、配置和重新启动 Web 容器；以及其他流程 — 这些都不需要人为干预。显然，用户可以输入这个命令；但是因为它非常简单，所以很容易通过无头流程（比如持续集成或构建管理服务器）运行它。 回页首 把可变信息注入配置文件 名称：Tokenize Configuration 模式：把标记化的值输入配置文件，然后在 Scripted Deployment 期间根据 Repository 中的 Externalized Configuration 属性替换它们。 反模式：把与目标相关的数据输入每个环境中的配置文件。 清单 3 中的 XML 文件用来管理 Web 容器和数据库服务器之间的配置。在这个文件中，我使用 @ 符号设置了一些标记。在自动化部署期间，一个脚本将把这些标记替换为来自 Externalized Configuration 文件的实际值。 清单 3. 标记化的 Web 容器配置文件 <datasources> <local-tx-datasource> <jndi-name>@application.context.name@</jndi-name> <use-java-context>false</use-java-context> <connection-url>@database.url@</connection-url> <user-name>@database.user@</user-name> <password>@database.password@</password> <driver-class>@database.driver@</driver-class> </local-tx-datasource> </datasources> 把与环境相关的值标记化，就使 Scripted Deployment 能够通过 Unified Deployment 支持多个环境。 回页首 提取所有与环境相关的属性 名称：Externalize Configuration 模式：把所有可变值从应用程序配置转移到构建时属性中。 反模式：一些团队为每个目标环境手工硬编码这些值，或者使用 GUI 工具执行同样的工作。 清单 4 给出一些常常包含在与应用程序相关的配置文件中的属性。通过把所有可变值 集中在一个 .properties 文件，就可以把数据（可变属性）与行为（部署脚本）分隔开。换句话说，无论在哪个目标环境中，自动化部署流程都以相同的方式运行。 清单 4. 可以提取到与应用程序相关的文件中的示例属性 authentication.type=db application.url=http://${tomcat.server.hostname}:${tomcat.server.port}/brewery-webapp database.type=mysql database.server=localhost database.port=3306 database.name=mydb database.user=myuser! database.password=mypa$$! database.url=jdbc:mysql://${database.server}:${database.port}/${database.name} tomcat.server.hostname=localhost tomcat.server.name=default tomcat.web.password=pa$$123! tomcat.cobraorb.port=12748 清单 4 中的值常常分散在源代码、服务器配置、XML、.properties 和其他文件中。另外，我发现这些数据常常在系统中重复出现，这会导致难以调试的部署问题。通过把这些信息从许多地方集中到一个 .properties 文件中，可以减少发生部署问题的可能性。 回页首 通过无头执行减少麻烦 名称：Headless Execution 模式：安全地与多台计算机进行交互，而不需要输入任何命令。 反模式：由人以不同的用户身份手工登录并访问每台计算机，然后执行复制文件、配置值等操作。 尽 管 “无头执行” 这个名称有点儿夸张，但是在需要通过自动化流程远程访问其他计算机时，无头执行确实是很有效的解决方案。通过使用公共密钥基础结构 (PKI)，可以把通常由开发人员、构建工程师、软件配置管理 (SCM) 或操作员执行的命令组合为自动化的解决方案。在图 2 中，在构建计算机和 SSH 上安装一个私有密钥文件。在每个与目标相关的 .properties 文件中定义具体值。这通常包括私有密钥文件名和位置、SSH 端口号和主机名。目标计算机包含公共 SSH 密钥文件，从而完成 SSH 握手。 图 2. 使用 SSH 密钥实现 Headless Execution 模式 如果使用这种方式，Scripted Deployment 就可以从构建环境对目标环境执行部署流程，不需要人为干预。 回页首 检查在不同的环境中属性是否相同 名称：Template Verifier 模式：创建一个模板文件，所有目标环境属性都基于这个文件。 反模式：一些团队执行手工检查、尝试和纠错（在部署失败时，检查失败的原因），或者把文件 “隐藏” 在计算机上。 问 题在于，需要确保在每个环境中具有完全相同的属性。但是，在自动化环境中如何检查这一点呢？根据一个模板 .properties 文件检查所有目标环境文件，就可以确保所有属性在任何目标环境中都是相同的。在图 3 中，构建脚本运行一个 Ant 任务，此任务对 template.properties 和与目标相关的 .properties 文件（dev.properties、qa.properties 等）中的属性（而不是值）进行比较。如果发现差异，部署就会失败。 图 3. Template Verifier 模式的实现 清单 5 给出一个示例 template.properties 文件。注意，它只包含属性，因为值与这个问题无关。 清单 5. 包含属性但不包含值的模板文件 db.database= db.username= db.password= db.hostname= db.driver= db.port= db.url= 清单 6 给出 dev.properties（或 qa.properties 等）文件的片段。注意，它既包含属性，也 包含值。这些值是与目标环境相关的。 清单 6. 基于模板文件的目标环境属性文件 db.database=brewery db.username=root db.password=p@ssword db.hostname=dev1.domain.com db.driver=com.mysql.jdbc.Driver db.port=3306 db.url=jdbc:mysql://${db.hostname}:${db.port}/${db.database} 回页首 同时在多个目标环境中执行部署 名称：Unified Deployment 模式：创建能够在不同的平台和目标环境中运行的单一部署脚本。 反模式：一些团队为每个目标环境（甚至特定的计算机）使用不同的部署脚本。 尽管一些部署流程只在某些环境中运行，但是所有流程应该能够 在任何 目标环境中运行。例如，在开发、测试、准备和生产环境中应该运行相同的 Scripted Deployment，但是使用不同的 Externalized Configuration 文件。使用 Template Verifier 检查 Externalized Configuration 属性。 图 4 给出一个能够在多个目标环境中执行部署的部署脚本： 图 4. 单一部署，多个目标环境 回页首 结束语 部 署是软件开发中另一个适合自动化的方面。自动化部署可以受益于可靠且可重复的流程：提高准确性、速度和控制能力。在本文中，我讨论了 8 个适用于软件部署自动化的模式。第 2 部分将讨论更多的模式，包括 Remote Deployment、Disposable Containers、Deployment Test 和 Environment Rollback。 参考资料 学习 您可以参阅本文在 developerWorks 全球网站上的 英文原文。 Software Configuration Management Patterns（Stephen Bercuzk 和 Brad Appleton，Addison-Wesley Professional，2003 年）：作者介绍了 Repository 模式和其他许多软件配置管理模式。 Patterns of Deployment：HP Labs 的 SmartFrog wiki 包含许多部署模式的目录。 Continuous Integration: Improving Software Quality and Reducing Risk（Paul Duvall、Steve Matyas 和 Andrew Glover，Addison-Wesley Signature Series，2007 年）：第 8 章 Continuous Deployment 提供了在自动化流程中实现部署的示例。 Pragmatic Project Automation: How to Build, Deploy, and Monitor Java Apps（Mike Clark，The Pragmatic Programmers，2004 年）：尝试实现实用、自动的无人值守软件生产，确保可靠性和准确性。 Release It!: Design and Deploy Production-Ready Software（Michael T. Nygard，The Pragmatic Programmers，2007 年）：如果您是一位开发人员，而且不希望在夜里 3 点被叫去工作，这本书会有帮助。 “使用自动化加速部署”（Paul Duvall，IBM developerWorks，2008 年 1 月）：利用自动化在不同的环境之间快速转移软件。 在 技术书店 浏览关于这些主题和其他技术主题的图书。 developerWorks Java 技术专区：这里有数百篇关于 Java 编程的文章。 获得产品和技术 Ant：下载 Ant 并开始以可预见和可重复的方式构建软件。 讨论 Improve Your Code Quality 讨论论坛：developerWorks 定期投稿者 Andrew Glover 将其丰富的专家知识带入这个论坛，主要在提高代码质量方面提供咨询。 Accelerate development 空间：developerWorks 定期投稿者 Andrew Glover 在此开设了一个一站式的门户，其中包括与开发人员测试、持续集成、代码度量和重构相关的各种内容。 通过参与 developerWorks 博客 加入 developerWorks 社区。 关于作者 Paul Duvall 是 Stelligent Incorporated 的 CTO，该公司是一家咨询公司，帮助开发团队交付可立即投入生产的软件。他是 Addison-Wesley Signature 系列书籍 Continuous Integration: Improving Software Quality and Reducing Risk（Addison-Wesley Professional，2007 年；Jolt Award 2008 优胜者）的合著者。他也参与了 UML 2 Toolkit（Wiley，2003 年）和 No Fluff Just Stuff Anthology（Pragmatic Programmers，2007 年）的撰写。