本文是标题为“如何控制网络基础结构”的系列文章中的第六篇。 该系列中所有文章的内容和链接都可以在这里找到 。
在留下一些话题之后，我决定开始一个新的篇章。
我待会儿再恢复安全。 在这里，我想讨论一种简单但有效的方法，我相信，这种方法对于一种或多种形式都可能有用。 简而言之，就是自动化如何改变工程师的生活。 这将涉及temlates的使用。 最后是我的项目列表，您可以在这里看到这里描述的所有内容。
Web的DevOps
使用脚本创建配置，使用GIT来控制IT基础架构中的更改，远程“填充”-当您考虑DevOps方法的技术实现时，这些想法首先出现。 优点是显而易见的。 但是不幸的是也有缺点。
五年多以前，我们的开发人员带着这些提议来到了我们的网络公司，我们对此并不热心。
我必须说，我们继承了一个由大约10个不同供应商的设备组成的杂乱无章的网络。 通过我们最喜欢的CLI进行配置很方便，但是我们更喜欢使用GUI。 此外，还对“带电”设备的长期工作进行了实时控制。 例如，进行更改时，我直接在cli中工作会更自在。 因此，我可以快速看到出现问题并“回滚”更改。 所有这些都与他们的想法有些矛盾。
出现其他问题，例如，从版本到软件版本，界面可能会略有不同。 最后，这将导致您的脚本创建错误的“ config”。 我不想将生产用于闯入。
或者，如何理解配置命令已正确应用以及出现错误时该怎么办？
我不想说所有这些问题都是无法解决的。 只需说“ 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天：每种技术需要2天。 之后，我准备进行下一步，即创建DEV和Staging数据中心。
开发和暂存
分阶段实际上完全重复了生产。 开发是主要基于虚拟硬件的精简副本。 一种新方法的理想情况。 如果我将时间花在一般流程上，那么我认为这项工作不会超过2周。 主要时间是另一侧的等待时间，并且是联合寻找问题的时间。 第三方的实施几乎是其他人看不见的。 甚至有时间教一些东西，并在Habré上写几篇文章:)
总结一下
那我到底有什么呢？
- 我需要更改配置的全部就是更改带有配置参数的简单，结构清晰的YAML文件。 我从不更改python脚本，而且很少（仅当有错误时）我更改Jinja2
- 从文档的角度来看，获得了几乎理想的情况。 您更改文档（YAML文件起NIP的作用）并将此配置上载到设备。 因此，您的文档始终是最新的。
所有这些导致了一个事实，
- 错误的百分比降低到几乎为0
- 花了90％的常规时间
- 实施速度大大提高
PAY，F5Y，ACY
我说过一些例子足以理解其工作原理。
这是在我的工作过程中创建的内容的简要说明（当然是经过修改的）。
PAY =来自
Y aml的部署
P alo
A lto =来自Yaml的Palo Alto
F5Y =来自
Y aml的部署
F5 =来自
Y aml的
F5 （即将推出）
ACY =来自
Y aml的部署
AC i =来自
Y aml的
F5我将添加一些关于ACY的词（不要与ACI混淆）。
与ACI合作的人都知道，这个奇迹（也是一种很好的方式）不是由网络人员创造的：）。 忘记您对网络了解的所有信息-它对您而言不会派上用场！
有点夸张，但大致传达了我与ACI合作三年来不断经历的感觉。
在这种情况下，ACY不仅是建立变更控制流程的机会（对于ACI而言尤其重要，因为假设这是数据中心的核心和最关键的部分），而且还为您提供了一个友好的界面来创建配置。
该项目的工程师出于相同的目的使用Excel使用ACI而不是YAML。 当然，使用Excel有一些优点：
- 您的压区合而为一
- 客户很高兴看到的漂亮标志
- 您可以使用一些Excel工具
但是有一个缺点，在我看来，它的缺点超过了优点。 控制变更和协调团队工作变得更加困难。
ACY实际上正在应用与第三方用于配置ACI相同的方法。