混合云和多云管理不再难：基础架构即代码来帮忙

随着运维流程变得越来越灵活，IT团队面临着越来越大的复杂度。当应用动态改变时，可以使用敏捷或者持续应用开发。但是当IT资源本身动态变化的时候怎么办呢?

多云和混合云是这一新的、动态的IT大格局的一部分——并且带来了新的风险。要解决这里的问题，一些企业使用了基础架构即代码方案。

配置管理(CM)在大规模IT基础架构里一直是必需配置。有一些CM工具，来自于云供应商，比如Amazon Web Services或者Microsoft Azure，或者来自于虚拟化或私有云软件供应商，比如OpenStack或者VMware。

基础架构即代码通过为应用程序创建虚拟托管模型来扩展了CM。这样虚拟的托管模型散布在多个云环境和数据中心平台里。

虽然基础架构即代码是CM的一种扩展，它其实是作为DevOps的扩展才开始流行起来。用户无法在还没有搭建好的服务器或者云服务上部署应用程序。因此，DevOps工具和脚本必须包含这些配置任务。这使得DevOps脚本和工具是和配置绑定的;如果从一个云平台改变到另一个平台，用户就必须更改脚本。基础架构即服务提供了一种方式，将应用程序的虚拟世界和底层资源，包括云，隔离开。有更多的托管方案存在，基础架构即代码就会更加有价值。

基础架构即代码模型为部署描述创建了中间层;用户将应用程序部署到基础架构即代码所创建的抽象的托管模型里，基础架构即代码随后将其适配到当前使用的任意云，多云或者混合配置环境里。基础架构的变动在应用程序和运维层是不可见的，并且添加新的云供应商仅需要在基础架构即代码里完成其定义即可。

但是，基础架构即代码的用户需要注意如下三大重要步骤：

1.将基础架构即代码从DevOps中隔离

IT团队能够将基础架构即代码部署到定义了配置脚本的任何环境里，并且使得应用程序能够适配几乎所有公有云服务或者数据中心平台。

IT团队需要基于哪种基础架构即代码将部署配置，来定义IT资源的抽象模型。基础架构即代码工具和实践变化很大。一些用户为每个应用程序都构建了基础架构即代码，而另外的用户为每种类型的云托管环境，比如基础架构即服务，平台即服务或者Docker，构建通用的模型。

总的来说，最好减少创建出的抽象托管模型的数量，因为当添加新的托管选择时，你必须调试每个模型。工具允许的情况下，考虑层级构建模型，这样部署应用组件——或者某个应用的一部分——的基础架构即代码模型，可以在部署整个应用程序的模型里直接引用。

2.为使用的所有云或者数据中心环境保护对基础架构即代码的支持

一旦你理解了所需模型，要确保它们能够支持计划使用的特定的云供应商和数据中心的配置。几乎所有基础架构即代码工具，比如Chef和Puppet，都让用户为任何环境定义自己的配置规则，但是流行的公有云，私有云和平台方案——比如hypervisor，容器系统和服务器操作系统——都作为基础架构即代码工具集的一部分提供。还可能有社区的支持，其他用户将他们的配置规则贡献出来。从已经能够工作的配置上开始开发，比从头开始构建自己的要更加容易。

3.将事件流从基础架构推广到部署工具

完成基础架构即代码方案中最微妙，困难和重要的事情是，处理基础架构即代码和其他工具集成的事件流;大多数情况下，这意味着使用DevOps工具。应用程序生命周期运营管理需要根据情况选择合适的软件——这些条件就是基础架构即代码里的事件。这些事件，通过托管资源生成，充当干什么事情的信号。他们通常激活一个自动化流程，比如通过在别的地方托管来替换发生故障的应用程序组件。

基础架构即代码事件和流程紧密链接，这也是为什么大多数计划使用混合或者多云部署的企业会研究其DevOps工具对基础架构即代码的支持，而并不使用单独的工具。基础架构即代码和DevOps的集成确保事件触发流程的正确设计和实现。