DevOps基础-4.1-基础架构自动化：基础设施即代码

这篇开始学习第四章，第四章主要阐述基础架构自动化这个话题。

       在IT系统管理领域，自动化技术并不是新的，但DevOps提升到了完全不同的自动化水平。我们将此称为基础设施即代码。 这是一种完全编程的基础架构方法，使我们能够利用我们系统的开发实践。 分裂Dev和Ops驱动器的一个影响是，一个团队的最佳实践确实没有传递到另一个团队。是的，一个简单的例子是使用源代码控制。

       一个没有将代码保存在源代码管理中的开发商店将被广泛认为是疯狂的。大脑疯了吗，但大量的操​​作团队根本不使用源代码控制。即使是他们的脚本或其他代码。是的，那是错的，但是如果我们能像代码那样对待我们的系统呢？是的，我们在IDE中开发它们，运行它们的单元和集成测试作为持续集成管道（CI Pipeline）的一部分来部署它们。甚至让他们根据他们的状态在运行时做出决定去做对应的动作。

       这就像代码所涉及的基础设施。存在用于完全自动配置裸机服务器的工具，并且通过虚拟服务器，云服务器或容器，可以以编程方式创建，更改和销毁所有内容。是的，让我们举例说明基础设施即代码。我们来看看亚马逊网络服务。您可以使用名为CloudFormation的JSON格式完整地描述您的系统。然后你有一个控制资产的源，每个人都可以看到这是一个保证准确反映你的系统配置。Ps：用户在亚马逊填写表格，下了订单，支付了，订单内容，在后台就是一个json文件格式传递到了云服务器，有了这个订单就可以监控用户自己虚拟机或者服务的各种状态。

       它（基础设施即代码）使你测试，准生产和生产环境相同，因为它们是从相同的规范（实际就是源码）创建的。远离手动设置任何东西，UI甚至是你的敌人。在模型中定义基础架构或通过执行rest API的代码来驱动它。现在我们可以把它放在源代码管理中，通过CI管道运行和来测试它，然后部署它。 只有最无奈的环境下才能让开发人员登录并更改生产中的代码。 我们真的不再这样做了。

       这是一种反模式，为什么要用你的系统呢？基础设施面临的最大挑战是代码正在改变思维模式。这是一个新领域，因此人们不能仅仅依靠旧的习惯或在infrastructures.org等受尊敬的网站上发布最佳实践。我是一个项目经理，负责管理涉及十几个团队的企业IT商店的主要网络升级。提交给我的技术计划是，我们将删除应用程序，然后是数据库，然后是服务器，然后是SAN，然后是网络，更换网络设备，然后以相反的顺序重新启动所有内容。

       然后开发人员将测试他们的应用程序，看看是否一切都很好，所以我问他们，“在应用程序级别诊断很多可能会非常困难”。 “在你把它们传递给下一个团队之前，你们每个人都计划如何测试你们的等级？“。我看到了很多空白。这不是开发的错。测试你的基础设施的想法是如此罕见以至于他们没有甚至没想到，所以我告诉他们，“想一想，我们（指运维团队）不会继续前进，直到每个级别开发都能告诉我他们将如何进行测试。” 在他们考虑之后，他们有了很棒的想法。

       UNIX管理员说：“如果我们推出一个脚本，我们所有的服务器都会执行ping命令，然后在升级之后，并查看所有每个服务器可以连接的内容”，我们会做同样的事情，它很棒。你知道，改变你的基础设施工程师的思维方式是将基础设施视为代码的关键。工具本身就不会这样做。我们都需要应对比单一更大的挑战机架在过去的壁橱里 。分布式系统，网络规模系统，微服务架构，虚拟化，云，现在的容器，它们的复杂性都在增加。

       尝试手动跟上这种复杂性是介于低效和不可能之间。即使是传统的自动化也难以跟上。在应用于基础设施中的服务器即代码世界里，你会听到牛而不是宠物。（PS：国外很多人喜欢讲牛和宠物猫的举例，主要意思是，猫是宠物，可以有名字，每个猫都是不同，但是牛主要是用来供人吃肉的，牛是没有区别的。猫和牛就分别比作传统IT技术和DevOps（或者Docker容器）为代表的新技术。所以这句话就是，传统IT管理就是要区别对待，服务器是硬件和代码不可能产生关系。但是基础设施即代码就认为，一切皆代码，基础设施服务也可以同代码驱动和管理，没有区别。）

        那就对了。服务器不是手工制作和命名的东西，而是手动保持的状态。他们是一群需要集体处理的集群。关于将基础设施设计为代码解决方案的最后几点。运维人习惯于解决障碍问题，开发人员习惯通过编写代码来解决问题。当您将这两个学科结合在一起时，您就有机会为该表提供最佳解决方案。接下来，我们来谈谈代码实践，配置管理中最广泛的基础设施之一。