1。作者简介 许桂林：阿里云日志服务技术专家，硕士毕业，曾就职于AutoDesk等公司，擅长云计算、DevOps等。 2.简介 本人一直从事自动化部署，尤其是公有云的自动化部署多年，所以本文主要围绕这方面展开。 注：这里所说的云主要是指基础设施服务层，即IaaS，泛指包括公有云、私有云或混合云在内的所有IaaS层形式。 3.基本背景 因为工作原因，2008年底在上一家公司（Autodesk）的时候开始使用国外的公有云。当时参与项目的一个很重要的部分就是帮助用户在我们的平台上完成自动化部署（注：我们的平台运行在这个云上）。 因为整个部署量很大，涉及到平台本身的部署、基础软件的部署和用户传统软件的部署。每次部署都需要几个小时，极大地影响了整个团队的工作效率。因此，我们花了很多时间构建自己的云自动化部署系统。 进入现在的公司后，亲自推动了自己项目的部分自动化部署流程。虽然这个项目没有直接跑在云端，但是原项目中总结的方法还是有一定的通用性的。部分经验也进行了实施，最终效果还不错（整个系统的部署时间缩短了数量级）。 经历了以上两个完全不同的项目后，才明白系统本身的可部署性才是实现自动化部署的关键（当然，这个结论的前提是团队已经认同自动化部署是团队效率和质量的关键。基本制度保障）。 系统的可部署性是从架构设计到最终运维的整个过程中需要考虑的因素。因此，需要整个工程团队（开发、测试、运维）就系统可部署性达成一致，并制定相关指南，才能让整个自动化部署顺利进行。 所以，这里我从系统的“可部署实践指南”的角度来分析一下如何保证自动化部署的成功实施： 虽然这里提到的很多指南不仅针对云系统，但由于以个人经验在云上部署系统，个人认为未来大部分IT系统也会运行在云上，所以我会重点介绍系统在云上的自动化部署来分享我的具体实践。#p# 第四，持续交付 谈自动化部署，就必须涉及到持续交付。从逻辑的角度来看，自动化部署是持续交付的一个阶段。但是，自动化部署流程和系统仍然可以独立于整个持续交付流程运行。下图描述了一个常见的持续交付流程以及其中部署自动化的位置。 如上图所示，整个自动化部署过程会涉及到IT系统生命周期（开发、测试、预发布、生产）中的所有环境。其中，由于生产系统的敏感性和对发布流程的一些要求（如发布窗口期），需要人工审批并触发部署流程。其他环境建议持续部署，加快迭代周期，尽早发现问题。 5.可部署实践指南 系统的可部署性必须是一个产品技术团队的共同职责： 云上IT系统应该遵循的一些指南是流程相关的，可能需要运维人员做标准化; 部分内容为系统开发设计，需要开发者自行考虑； 当然在测试工作中也要考虑可部署性。 Rule0.使用版本管理系统（VCS）来管理所有要发布的东西 这个规则比较容易理解，大部分团队在实际项目中应该都很好的实现了这一点。 需要注意的是，VCS系统不仅仅用来管理你的代码，所有要发布的东西（包括代码、文档、视频等）都可以（也应该）由一个统一的VCS来管理。至于VCS系统的选择，主流的软件（SVN、Git或者Perforce等）都可以很好的支持整个持续交付和自动化部署的过程。 规则一、构建的Artifacts统一管理 这条规则很容易被很多团队忽略，但是对于自动化部署的实现非常重要。 什么是Artifacts？ Artifacts是指构建系统产生的任何需要部署的输出，例如代码包、文档、静态资源等。 参考上面的持续集成流程图，可见Artifacts是所有自动化部署流程的输入，其管理的好坏将直接影响到部署流程的流畅性和效率。关于Artifacts管理，在实际项目中经常出现的几种情况如下： 团队完全没有Artifacts管理。当需要部署时，直接从构建系统中复制，通过邮件或其他文件共享工具在团队内部传递。这种情况会导致整个部署过程完全失控，部署记录无法追踪。 团队只专注于生产环境中的Artifacts管理。在开发、测试或暂存环境中没有针对工件管理的计划或标准。在这种情况下，无法保证整个生命周期的部署一致性，极大地影响了团队的迭代效率。 Artifacts的管理完全等同于文件的管理，没有对Artifacts的元数据信息做任何有效的管理。由于缺少Artifacts的元数据信息，部署流程和系统不容易获取当前Artifacts的元数据并据此采取相关行动。会使部署过程实施困难，部署质量得不到保证。 在实际工程中，团队越早在Artifacts管理上达成统一标准，团队推进自动化部署的难度就会越小。在我看来，一个好的Artifacts管理方法需要具备以下原则： 统一管理所有需要部署的Artifacts，包括开发、测试、预发布和生产环境。只有这样，才能为以后的自动化部署流程和系统提供统一的输入。 统一的Artifacts元数据格式，包括当前Artifacts构建信息、版本信息、可部署环境等。 提供API接口连接构建系统和部署系统。只有API接口才能保证未来自动化的实现。 目前市场上已经有很多Artifacts管理工具（比如开源的Nexus），可以帮助你快速搭建整个Artifacts管理系统。如果你的系统部署在云端，云提供商提供的对象存储服务也是不错的选择。 法则2.让部署系统来管理你的云基础设施 之所以把这一点放在首位，是因为它太重要了，也和传统IT环境下的自动化部署流程有很大区别。 在云上，一个很重要的变化是：所有的基础设施都是可编程的。 今天，所有云提供商都必须提供基础设施编程接口（例如虚拟机启动和停止API、存储接口和网络配置接口）。而一些比较成熟的云供应商已经提供了CloudFormation等服务，让你的IT系统基础设施可以得到完整准确的描述。 正因为如此，云端的自动化部署系统可以完全管理自己的基础设施，并通过API或CloudFormation等服务快速准确地构建一致的IT运营基础设施。 当系统的自动化部署过程完全包含基础设施管理时，有几个明显的好处： 可以随时获得环境完全一致的IT基础设施来运行系统（包括资源申请、环境搭建和软件部署）。这样，系统可以真正快速地从头开始部署，而不需要依赖任何其他部门（例如IT部门）。 IT基础设施的任何变化，部署系统都可以自动感知，并采取相应的行动，确保IT系统的稳定性。 IT系统可根据系统当前情况，随时请求部署系统调整IT基础设施（如弹性伸缩）。 这里需要提到的是，以Docker为代表的容器技术使得运行时的标准化和可编程性变得极其容易和轻量级。 但是，整个IT系统的基础设施不仅包括系统的运行环境，还包括网络规划、存储管理、计算资源管理等。 这些基础设施的编程只能通过云端的IaaS层API或者CloudFormation来完成。所以从这个角度来说，Docker和IaaS并不冲突，而是非常好的搭档，一起大大降低了整个IT系统的运维和管理成本。 规则3.使用相同的部署流程来管理你的开发、测试、预发布和生产环境 这是传统IT和云都应该遵循的原则。现实中，很多团队喜欢把系统的部署推迟到最后一刻才上线。而且，即使有自动化部署流程，也与生产环境硬耦合，只能用于生产系统的部署。 1。这种方式虽然在短时间内来得很快，但是在IT系统的长期部署和管理中会带来很多麻烦。个人认为至少会包括以下两点： 2。这种部署方式导致不同环境下应用的不一致性成为必然的现象，而这个问题最终会导致你的生产环境出现致命故障。 这种部署方式导致开发、测试、上线过程效率极低。事实上，在不同的环境中，生产环境的部署频率是最高的，开发和测试部署几乎是工程团队每天要做的事情。通过完全自动化的部署流程管理所有环境，将大大提高日常开发和测试的效率。 所以，对于一个新项目，***可以在项目初期就成功搭建起整个IT系统的自动化部署流程，包括所有的环境。 对于已经在运行的项目，要积极推进部署流程与部署环境的解耦。具体来说，常见的解决方案有以下几点： 使用不同的代码分支来对应不同的环境，方便代码管理； 抽象并提出所有与环境相关的配置，以及 所有部署阶段都需要接受环境参数输入（可以是环境变量或参数），并根据不同的环境进行相应的部署操作； 针对不同的环境Window设置不同的部署频率和时间； 针对不同的环境设置不同的部署操作和访问权限，控制部署风险。 ***，很多团队可能不可能有完整的开发、测试、生产环境（或者这些环境差异太大），导致同一个部署流程很难适应不同的环境。但是，因为云的出现，我们在不同环境下获取IT基础设施变得容易多了。 也正因为如此，大大降低了这条规则的实施难度（事实上，开发测试已经成为很多企业用户开始尝试上云的第一站），这条规则带来的开发效率的提升会让团队受益匪浅。#p# 法则4.在全球范围内使用相同的部署流程来管理同一个IT系统 这是一条对很多团队来说似乎没有用的法则。但是，云的出现让全球部署变得非常容易，很多非常小的团队都可以进行全球部署和运营。在云上，全球部署是指将您的IT系统部署在全球云服务提供商的不同区域。 当然，即使在中国，为了提供更好的系统访问速度，云提供商也会提供多个Region。由于不同地区的云提供商提供的服务已经标准化，访问接口也统一了，因此使用相同的部署流程管理全国（甚至全球）的服务就容易多了。为此，你的部署系统需要注意几点： 抽象，提出任何与部署Region相关的配置，以配置服务的形式提供接入（配置服务可能是中心化服务）； 所有deployments所有阶段都需要接受Region相关的信息输入（可以是环境变量或参数）； 需要为不同的Region提供部署协调机制（比如不同的Region可能在不同的时区，这是一个处理和时间相关的部署，任务需要特别照顾）。 一旦能够统一不同区域的部署流程，在业务扩展时，IT部署会变得容易很多，这也是整个系统可扩展性的重要体现。 现在，IT系统的可扩展性往往局限于同一个系统能否在同一个地方快速扩展，而忽略了IT系统在不同地点的快速复制能力。这种快速复制能力不仅是业务全球化的需求，也是解决系统自身容量扩展性的重要途径。 规则5.部署过程应优先满足热升级和热切换需求 在传统IT项目中，可能难以实现热升级和热切换，系统升级和切换的频率也不高必然高。在很多情况下，这种功能需求会被视为“二等公民”。但这条准则恰恰相反，强调“优先满足”。原因如下： 1。“永远在线”成为新的刚性需求。 随着IT系统逐渐从后台支持转向前台直接服务客户。不再接受定期关机以升级系统。 特别是随着互联网和移动互联网的普及，用户对在线服务的默认期望是“随时随地都可以访问”。在这种情况下，架构设计和部署过程都需要考虑“永远在线”的目标。 2。热升级和热切换是持续交付的基础，也是最终支撑业务快速发展的关键。在实际工程中，产品团队的所有工作最终都要在生产环境中进行测试。 只有整个部署过程全面支持热升级和热插拔，才能将产品的任何改进或需求确认快速推送到生产环境进行验证。如果部署过程不能支持热升级和热插拔，持续部署必然会导致服务频繁中断，从而影响业务。 因为以上原因，需要在整个架构和部署过程的设计过程中优先考虑热升级和热切换，并坚持下去。否则，构建的整个持续交付或自动化部署流程将事倍功半，最终失败。 在云端，由于基础设施资源非常容易获得，让不同版本完全独立运行，在升级过程中逐步切换流量，已经是一种低成本的实用方式。因此，云上系统热升级和热切换的难度也得到了一定程度的降低。 规则六、自动化、自动化还是自动化 正如“自动化部署”的名称所表达的那样，自动化是其核心诉求，也是其最终成功实践的技术保障。关于自动化的好处，相信大家不用细说也明白。但在现实中，我们面临的问题往往是如何实现流畅的自动化。个人推荐以下实践经验： 1。不要在自动化技术和工具上犹豫太久。 选择什么样的自动化部署工具，对于还没有自动化流程的团队来说，并不是头等大事。重要的是团队有行动的决心和时间。 如果在技术和工具的选择上真的有什么建议，那就选择团队最熟悉的技术和工具，最有利于快速见效。让团队尽快看到自动化部署的优势，从而坚定地走这条路，比选择什么工具重要得多。 2。尽早建立“一键式”部署流程。这让团队对“一键式”有了更早的约束，而不是在推进过程中不断妥协，***完全不可能实现自动化。 3.在“一键式”部署流程的前提下，逐级推进各个组件，以满足自动化部署的要求。 一个好的策略是在一步一步的过程中区分模块中的“常量”和“变量”。 这里的“不变”指的是系统部署中不经常变化的部分（如基础操作系统、基础软件等）。对于这些部分，可以使用“预制模式”（例如系统镜像）来初始加入部署系统。在部署过程中经常发生变化的“可变”部分需要在部署系统中加以考虑。当然，“常数”和“变量”的划分并不是绝对的。一般来说，部署系统是从自动化中变化最频繁的“可变”部分开始，逐步覆盖变化较少的“常量”部分。因为这样可以尽早最大化自动化流程带来的价值。 规则7.让模块具备自启动、自发现、自部署的能力 在实现自动化部署的过程中，估计最让团队头疼的就是不同模块之间的部署依赖.很多传统的部署软件也试图通过各种方式（比如依赖可视化）来降低维护部署依赖的难度，但是很多时候最终的效果并不好。 原因在于，在业务场景频繁变化的情况下，模块之间紧耦合的依赖关系很难长期保持稳定，部署系统也很难高效维护这种多变的部署依赖关系。随着微服务概念的流行，越来越多的人开始相信每个微服务模块应该独立部署、运维、提供服务。 这一点体现在部署上，就是让每个模块都具备自启动、自发现、自部署的能力。具体包括以下几个方面： 各模块部署到系统后无需外部主动触发即可自启动； 在外接主动通知的前提下，查明自己承担的角色； 每个模块发现自己的角色后，就可以完成部署、配置、依赖检查和启动外部Serve。 基于以上需求，个人在实践中常见的做法有： 优先选择“运行时部署”而不是“预定义模式”（最常见的预定义模式是镜像投递）； 每个模块都需要描述如何完成自己的部署过程（比如某大云的CodeDeploy服务，appspec.yaml文件其实就是对应模块自己部署的描述文件）； 让每个模块独立部署，不需要模块前后部署。使用动态发现模式对模块之间的依赖关系进行优先排序。 #p#Rule8.把部署变成服务 当团队完成整个自动化部署流程后，记得向前迈出一步，把你的部署工具变成内部部署服务，让团队里的每一个人（包括非技术人员或新同事）也能快速完成部署。 为了使部署成为一个服务，你可能需要实现一个Portal，或者添加一个邮件通知服务。当然你也可以把整个部署服务做的更好，甚至服务其他团队。不管怎样，这都会给团队带来很大的好处，因为它降低了整个系统的使用门槛，让更多的人从中受益。 法则九、全面的用户监控，确保自动化部署 这是最后一条法则，但也可能是很多开始尝试自动化部署的团队最担心的问题：如果自动化部署出现问题怎么办？ 手动部署时，也可以一步步观察结果，让人检查部署过程，避免不良后果迅速扩大。其实，在回答这个问题之前，如果仔细回顾一下人肉部署导致的各种故障，你一定会发现，人为错误导致的故障所占的比例大得惊人。 而自动化部署的一个目标恰恰是为了减少人为错误导致的故障。当然，为了避免自动化部署带来的负面影响，您需要注意以下几个方面： 请对您的服务进行全方位的监控。这不仅是日常运维的需要，也是自动化部署的需要。而且，这里的监控需要包括很多应用层面的监控，而不仅仅是像CPU、Memory这样的基础监控。这样方便团队及时发现自动部署导致的系统服务问题。 在部署过程中提供快速回滚（Rollback）方案。可靠的回滚方案将使您在继续进行自动化部署时更有信心。 对每个模块、每个部署阶段多做事前检查和事后检查。想想你在部署人肉的时候，你是怎么检查每个部署阶段是否成功，怎么判断是不是问题，然后尽量把这些判断逻辑自动化。 ***，如果你是团队中想要推广自动化部署的同学，以下两个经验或许可以帮助你进步： 痛点原则。推进自动化部署的一个常见问题是时间安排。团队总会被不同的业务需求推着前行，自动化部署的非功能性需求往往无法得到资源的保障。这时候你需要不断问自己的一个问题是“如果我现在在自动化部署中只能做一件事，我需要做什么？”记得找到唯一最痛的地方作为突破口，尽快让团队感受到自动化部署带来的优势，才能得到团队更多的支持。 没有回头路的原则。在推动自动化部署的过程中，Unity经常会因为自动化部署带来的问题或者自动化部署流程不完善而放弃尝试。这个时候，作为一个积极主动的人，一定要及时跟进，发现系统问题，而不是让团队轻易回头。 当然你肯定会说拿boss是最核心的保障。如果你能有一个全力支持你的老板，那你就很幸运了。 更多的时候，老板会以半信半疑的态度对待自动化部署。这个时候，找到突破口，见效快，能够坚持不懈，或许就是你说服上司的最佳策略。 http://blog.xuguilin.me/2014/01/22/autodeploy-on-aws.html 如何一起快乐开发 《高效运维》公众号（以下二维码code)值得你关注。作为高效运维系列微信群唯一官方公众号，每周发布多篇干货满满的原创文章：来自系列群的讨论精华，运维论坛和群友的精彩在线分享原来的。《高效运维》也是互联网专栏《高效运维***实践》和官方运维2.0公众号。 温馨提示：目前两大微信群仅剩少量宝贵席位，高效运维。如果您愿意，可以加小天国的个人微信小天国为好友并申请；或者申请加入我们的技术交流群（技术讨论为主，规则没有主群多，更热闹）。 重要提示：除非事先授权，否则请在本文公众号发表后2天转载此文。尊重知识，转载请转载全文，包括我行及下方二维码。
