这是演讲的文字记录 и .
这是一个使用自行编写的配置管理系统的项目的故事，以及为什么迁移到 Ansible 花了 18 个月的时间。
日号 -ХХХ: 开始之前
最初，基础设施由许多运行 Hyper-V 的独立主机组成。 创建虚拟机需要许多步骤：将磁盘放在正确的位置、注册 DNS、保留 DHCP、将 VM 配置放入 git 存储库。 此过程部分机械化，但例如，虚拟机是手动在主机之间分配的。 但是，例如，开发人员可以在 git 中更正 VM 配置并通过重新启动 VM 来应用它。
定制配置管理解决方案
我怀疑最初的想法被设想为 IaC：许多无状态虚拟机在重新启动时将其状态重置为零。 什么是虚拟机配置管理？ 从原理上看，它看起来很简单：
- 为虚拟机确定了静态 MAC。
- 带有 CoreOS 的 ISO 和启动磁盘已连接到虚拟机。
- CoreOS根据其IP从WEB服务器下载定制脚本来启动定制脚本。
- 该脚本根据 IP 地址通过 SCP 下载 VM 配置。
- systemd 单元文件的 footcloth 和 bash 脚本的 footcloth 已启动。
这个解决方案有很多明显的问题：
- CoreOS ISO 已被弃用。
- 迁移/创建虚拟机时有很多复杂的自动化操作和魔法。
- 更新困难以及需要特定版本的软件时。 使用内核模块会更有趣。
- 没有数据就无法获得虚拟机，即虚拟机出现时，磁盘上挂载了额外的用户数据。
- 有人不断搞砸 systemd 单元依赖关系，CoreOS 在重新启动时会冻结。 使用 CoreOS 中的可用工具很难捕捉到这一点。
- 秘密管理。
- 没有CM。 CoreOS 有 bash 和 YML 配置。
要应用虚拟机配置，您需要重新启动它，但它可能不会重新启动。 这似乎是一个明显的问题，但没有永久磁盘 - 没有地方可以保存日志。 好吧，我们尝试添加内核加载选项，以便发送日志。 但不，这一切是多么复杂。
第 0 天：认识问题
这是通常的开发基础设施：jenkins、测试环境、监控、注册表。 CoreOS 是为托管 k8s 集群而设计的，即问题在于CoreOS是如何使用的。 第一步是选择堆栈。 我们决定：
- CentOS的 作为基础分布，因为这是最接近生产环境的发行版。
- Ansible 对于配置管理，因为对此进行了广泛的审查。
- 詹金斯 作为自动化现有流程的框架，因为它已经被积极用于开发过程
- Hyper-V 作为虚拟化平台。 有很多原因超出了故事的范围，但简而言之 - 我们不能使用云，我们必须使用我们自己的硬件。
第 30 天：修复现有协议 - 协议即代码
当堆栈清理完毕后，搬家的准备工作就开始了。 以代码的形式修复现有协议（协议即代码！）。 过渡 体力劳动 -> 机械化 -> 自动化.
1. 配置虚拟机
Ansible 在这方面做得很好。 只需最少的身体动作，您就可以控制虚拟机配置：
- 创建 git 存储库。
- 我们将虚拟机列表放入清单中，将配置放入剧本和角色中。
- 我们正在设置一个特殊的詹金斯奴隶，您可以从中运行 Ansible。
- 我们创建一个作业并配置 Jenkins。
第一个过程已准备就绪。 协议是固定的。
2.创建新虚拟机
这里的一切都不是很方便。 从Linux在Hyper-V上创建虚拟机不是很方便。 使这一过程机械化的尝试之一是：
- Ansbile 通过 WinRM 连接到 Windows 主机。
- Ansible 运行 powershell 脚本。
- Powershell 脚本创建一个新的虚拟机。
- 使用 Hyper-V/ScVMM，在来宾操作系统中创建 VM 时，会配置主机名。
- 更新 DHCP 租约时，VM 会发送其主机名。
- 域控制器端的标准 ddns 和 dhcp 集成配置 DNS 记录。
- 您可以将虚拟机添加到您的清单中并使用 Ansible 配置它。
3.创建虚拟机模板
他们在这里没有发明任何东西——他们带了一个包装机。
- 将打包程序、kickstart 配置添加到 git 存储库。
- 使用 hyper-v 和 Packer 设置一个特殊的 jenkins 从属服务器。
- 我们创建一个作业并配置 Jenkins。
此链接的工作原理：
- Packer 创建一个空 VM 并获取 ISO。
- VM 启动后，Packer 将命令输入到引导加载程序中，以使用软盘或 http 中的 kickstart 文件。
- Anaconda 使用我们的配置启动，初始操作系统配置已完成。
- Packer 等待 VM 变得可用。
- 虚拟机内的 Packer 以本地模式运行 ansible。
- Ansible 使用与步骤 #1 中完全相同的角色。
- Packer导出虚拟机模板。
第 75 天：在不破坏协议的情况下重构协议 = Test ansible + Testkitchen
捕获代码中的约定可能还不够。 毕竟，如果在整个过程中你想改变一些东西，你就可以破坏一些东西。 因此，就基础设施而言，出现了对基础设施的测试。 为了在团队内同步知识，我们开始测试 Ansible 角色。 我不会深入探讨，因为…… 有一篇文章描述了当时发生的事件 （剧透，这不是最终版本，后来一切都变得更加复杂 ).
第 130 天：也许不需要 CentOS+ansible？ 也许是开档？
我们必须明白，引入基础设施的过程并不是唯一的过程，还有一些附带的子项目。 例如，我们收到一个在 openshift 中启动我们的应用程序的请求，这导致我们进行了一个多星期的研究 这减慢了移动过程。 结果证明，openshift 并不能满足所有需求；您需要真正的硬件，或者至少需要能够使用内核。
第 170 天：Openshift 不合适，我们来试试 Windows Azure Pack 吧？
Hyper-V 不是很友好，SCVMM 也没有让它变得更好。 但是有一个名为 Windows Azure Pack 的东西，它是 SCVMM 的附加组件并模仿 Azure。 但实际上，该产品看起来已被废弃：文档链接已损坏且非常稀疏。 但作为简化云生命周期选项研究的一部分，他们也对此进行了研究。
第 250 天：Windows Azure Pack 不太好。 我们仍然坚持 SCVMM
Windows Azure Pack 看起来很有前途，但出于不必要的功能考虑，决定不将 WAP 及其复杂性引入系统，并继续使用 SCVMM。
第 360 天：一块一块地吃掉大象
仅仅一年后，搬迁平台就准备好了，搬迁过程开始了。 为此，设置了 SMART 任务。 我们检查了所有虚拟机，并开始一一弄清楚配置，在 Ansible 中对其进行描述，并通过测试对其进行覆盖。
第 450 天：您获得了什么样的系统？
这个过程本身并不有趣。 这是例行公事，可以注意到，大多数配置都相对简单或同构，根据帕累托原理，80% 的虚拟机配置需要 20% 的时间。 按照同样的原则，80% 的时间花在准备动作上，只有 20% 的时间花在动作本身上。
第 540 天：决赛
18个月里发生了什么？
- 这些协议成为了代码。
- 体力劳动 -> 机械化 -> 自动化.
链接
来源： habr.com