本文是“如何控制网络基础设施”系列的第六篇文章。 该系列所有文章内容及链接均可找到 .
抛开几个话题后，我决定开始新的篇章。
稍后我会回到安全区。 在这里，我想讨论一种简单但有效的方法，我相信它以某种形式对许多人有用。 这更像是一个关于自动化如何改变工程师生活的小故事。 我们将讨论使用模板。 最后有一个我的项目列表，您可以在其中看到这里描述的所有内容是如何工作的。
网络 DevOps
使用脚本创建配置、使用 GIT 控制 IT 基础设施的更改、远程“上传”——当您考虑 DevOps 方法的技术实现时，这些想法首先出现。 优点是显而易见的。 但不幸的是，也有缺点。
五年多前，当我们的开发人员向我们（网络人员）提出这些建议时，我们并不高兴。
我必须说，我们继承了一个相当杂乱的网络，由大约 10 个不同供应商的设备组成。 通过我们最喜欢的 cli 来配置一些东西很方便，但在其他方面我们更喜欢使用 GUI。 此外，长期在“现场”设备上的工作教会了我们实时控制。 例如，在进行更改时，我感觉直接通过 cli 工作更舒服。 这样我就可以快速发现出现问题并回滚更改。 这一切都与他们的想法有些矛盾。
还会出现其他问题，例如，不同版本的软件界面可能会略有不同。 这最终会导致您的脚本创建错误的“配置”。 我不想用生产来“磨合”。
或者，如何了解配置命令是否正确应用以及出现错误时该怎么办？
我并不是想说所有这些问题都是无法解决的。 只说“A”可能也可以说“B”，如果您想使用与开发中相同的流程进行变更控制，那么除了生产之外，您还需要拥有开发和登台环境。 那么这个方法看起来就完成了。 但要花多少钱呢？
但有一种情况是，缺点几乎被消除，只剩下优点了。 我说的是设计工作。
项目
在过去的两年里，我一直在参与一个为大型提供商构建数据中心的项目。 我在这个项目中负责F5和Palo Alto。 从思科的角度来看，这是“第三方设备”。
就我个人而言，这个项目有两个不同的阶段。
第一阶段
第一年我无休止地忙碌，我晚上和周末都工作。 我无法抬起头。 来自管理层和客户的压力是强大且持续的。 在日常工作中，我什至无法尝试优化流程。 与其说是设备配置，不如说是设计文档的准备。
第一次测试已经开始，我会惊讶于其中出现了多少小错误和不准确之处。 当然，一切正常，但是名称中缺少一个字母，命令中缺少一行...测试一直在进行，我已经每天都在与错误、测试和文档作斗争。
这种情况持续了一年。 据我了解，这个项目对每个人来说并不容易，但渐渐地，客户变得越来越满意，这使得雇佣更多能够自己承担部分日常工作的工程师成为可能。
现在我们可以四处看看。
这就是第二阶段的开始。
第二阶段
我决定使该过程自动化。
我从当时与开发人员的交流中了解到（我们必须赞扬，我们有一个强大的团队），文本格式虽然乍一看像是来自 DOS 操作系统世界的东西，但它有很多优点。的宝贵财产。
因此，例如，如果您想充分利用 GIT 及其所有衍生产品，则文本格式将很有用。 我也想这么做。
嗯，看起来您可以简单地存储配置或命令列表，但进行更改非常不方便。 除此之外，设计过程中还有一个重要的任务。 您应该有描述您的整体设计（低级设计）和具体实施（网络实施计划）的文档。 在这种情况下，使用模板看起来是一个非常合适的选择。
所以，当使用 YAML 和 Jinja2 时，一个包含 IP 地址、BGP AS 号等配置参数的 YAML 文件完美地履行了 NIP 的作用，而 Jinja2 模板则包含了与设计相对应的语法，也就是说，它本质上是一个LLD 的反映。
花了两天时间学习了YAML和Jinja2。 几个很好的例子就足以理解它是如何工作的。 然后大约花了两周时间来创建与我们的设计相匹配的所有模板：Palo Alto 一周，F5 又一周。 所有这些都发布在公司 githab 上。
现在更改过程如下所示：
- 更改了 YAML 文件
- 使用模板创建配置文件（Jinja2）
- 保存在远程存储库中
- 将创建的配置上传到设备
- 我看到一个错误
- 更改了 YAML 文件或 Jinja2 模板
- 使用模板创建配置文件（Jinja2）
- ...
显然，一开始花了很多时间进行编辑，但一两周后，这种情况就变得很少见了。
客户希望更改命名约定，这是一个很好的测试和调试一切的机会。 那些曾与 F5 合作过的人都了解情况的严峻性。 但对我来说，这一切都很简单。 我更改了 YAML 文件中的名称，从设备中删除了整个配置，生成了一个新配置并上传了它。 一切，包括错误修复，花了 4 天时间：每种技术需要两天。 之后，我为下一阶段做好了准备，即创建 DEV 和 Staging 数据中心。
开发和分期
舞台实际上完全复制了生产。 Dev 是一个主要基于虚拟硬件构建的高度精简的副本。 这是采用新方法的理想情况。 如果把我所花费的时间从整个过程中分离出来，那么我认为这项工作只花了不超过2周的时间。 主要的时间就是等待对方，一起寻找问题。 第三方的实施几乎没有被其他人注意到。 甚至还有时间学习一些东西并写几篇关于哈布雷的文章:)
总结
那么，我到底有什么底线呢？
- 要更改配置，我所需要做的就是更改带有配置参数的简单、结构清晰的 YAML 文件。 我从不更改 python 脚本，并且很少（仅当出现错误时）更改 Jinja2 heatlate
- 从文档的角度来看，这几乎是理想的情况。 您更改文档（YAML 文件充当 NIP）并将此配置上传到设备。 这样您的文档始终是最新的
这一切导致了这样一个事实：
- 错误率几乎下降到0
- 90%的例行公事都消失了
- 实施速度显着提高
支付、F5Y、ACY
我说几个例子就足以理解它是如何工作的。
这是我在工作期间创建的内容的简短（当然是修改过的）版本。
= 部署 PALO A从 Yaml = 来自 Yaml 的帕洛阿尔托
= 部署 F5 止 Y氨氮= F5 止 Yaml（即将推出）
= 部署 AC我来自 Y氨氮= F5 止 YAML
我将添加一些有关 ACY 的内容（不要与 ACI 混淆）。
那些与 ACI 合作过的人都知道，这个奇迹（而且是以一种好的方式）绝对不是由网络工作者创造的:)。 忘记你所知道的关于网络的一切——它对你没有用！
虽然有点夸张，但大致传达了我在过去三年与 ACI 合作中不断感受到的感受。
在这种情况下，ACY 不仅是构建变更控制流程的机会（这在 ACI 的情况下尤其重要，因为它应该是数据中心的核心和最关键的部分），而且还为您提供了用于创建配置的用户友好界面。
该项目的工程师使用 Excel 来配置 ACI，而不是 YAML，以达到完全相同的目的。 当然，使用 Excel 有以下优点：
- 您的 NIP 在一个文件中
- 美丽的标志让客户赏心悦目
- 你可以使用一些excel工具
但有一个缺点，在我看来，它超过了优点。 控制变更和协调团队工作变得更加困难。
ACY 实际上是我用于第 3 方配置 ACI 的相同方法的应用程序。
来源： habr.com