设备在销售高峰之前几个月就到达了现场。维护服务当然知道如何以及在服务器上进行什么配置，以将其引入生产环境。但是我们需要实现这一点的自动化并消除人为因素。此外，在迁移对公司至关重要的一组SAP系统之前，已更换了服务器。
新服务器的调试与最后期限紧密相关。而移动它会危害十亿礼物的运输和系统的迁移。甚至由圣诞老人和圣诞老人组成的团队也无法更改日期-仓库管理的SAP系统每年只能转让一次。从12月31日至1月1日，零售商的大型仓库（总共20个足球场）停工15个小时。这是系统运行的唯一时间段。我们无权在输入服务器时犯错。
让我立即解释一下：我的故事反映了我们团队使用的工具和配置管理流程。
配置管理中心由几个级别组成。关键组件是CMS系统。在工业开发中，缺少其中一个级别将不可避免地导致令人不快的奇迹。
操作系统安装管理
第一层是用于管理物理服务器和虚拟服务器上操作系统安装的系统。它创建了基本的OS配置，消除了人为因素。
在该系统的帮助下，我们获得了标准，适用于具有OS的服务器的进一步自动化实例。投放时，他们收到的本地用户和公共SSH密钥最少，并且操作系统配置一致。我们可以保证通过CMS管理服务器，并确保在操作系统级别“没有任何意外”。
安装管理系统的最大目标是从BIOS /固件级别到OS自动配置服务器。在很大程度上取决于硬件和配置任务。对于不同的设备，请考虑使用REDFISH API...如果所有硬件都来自一个供应商，则使用现成的管理工具（例如HP ILO Amplifier，DELL OpenManage等）通常会更方便。
为了在物理服务器上安装操作系统，我们使用了著名的Cobbler，它定义了一组与维护服务配合的安装配置文件。在基础架构中添加新服务器时，工程师会将服务器的MAC地址绑定到Cobbler中所需的配置文件。通过网络首次启动时，服务器收到一个临时地址和一个新的OS。然后将其传输到目标VLAN / IP地址，并继续在那里工作。是的，更改VLAN需要花费时间并且需要协调，但是它提供了额外的保护，以防止在生产环境中意外安装服务器。
我们基于使用HashiCorp Packer准备的模板创建了虚拟服务器。原因是相同的：防止在安装操作系统时可能出现的人为错误。但是，与物理服务器不同，Packer允许您不使用PXE，网络启动和VLAN更改。这使得创建虚拟服务器变得越来越容易。
数字：1.管理操作系统的安装。
秘密管理
任何配置管理系统都包含应向普通用户隐藏的数据，但这些数据是准备系统所必需的。这些是本地用户和服务帐户的密码，证书密钥，各种API令牌等。通常将它们称为“秘密”。
如果从一开始就没有确定这些秘密的存储位置和方式，那么根据IS要求的严重性，可能使用以下存储方法：
- 直接在配置管理代码或存储库中的文件中；
- 在专用的配置管理工具（例如Ansible Vault）中；
- 在CI / CD系统（Jenkins / TeamCity / GitLab等）中或在配置管理系统中（Ansible Tower / Ansible AWX）；
- 机密也可以转移到“手动控制”中。例如，将它们放置在约定的位置，然后由配置管理系统使用；
- 以上各种组合。
每种方法都有其自身的缺点。主要的问题是缺乏用于访问机密的策略：不可能或很难确定谁可以使用某些机密。另一个缺点是缺少访问审核和完整的生命周期。例如，如何快速替换用代码和许多相关系统编写的公共密钥？
我们使用了集中式HashiCorp保管库。这使我们能够：
- 保守秘密。它们是经过加密的，即使有人访问了Vault数据库（例如，通过从备份还原数据库），他们也将无法读取存储在其中的机密信息。
- . «» ;
- . Vault;
- « » . , , . .
- , ;
- , , ..
现在，让我们继续进行中央认证和授权系统。您可以没有它，但是在许多相关系统中管理用户太简单了。我们已经通过LDAP服务配置了身份验证和授权。否则，同一保管库将不得不连续地为用户颁发并保留身份验证令牌的记录。删除和添加用户将变成一个任务“我是否到处都创建/删除了这个UZ？”
我们在系统中增加了一个级别：秘密管理和中央认证/授权：
数字：2.机密管理。
配置管理
我们到达了核心-CMS系统。在我们的案例中，这是一堆Ansible和Red Hat Ansible AWX。
厨师，木偶，SaltStack可以代替Ansible采取行动。我们为几个标准选择了Ansible。
- 首先，它是多功能性。现成的控制模块集令人印象深刻。而且如果您没有足够的资源，可以在GitHub和Galaxy上搜索。
- 其次，无需在受控设备上安装和维护代理程序，以证明它们不会干扰负载，也无需确认没有“书签”。
- 第三，Ansible的进入门槛很低。称职的工程师将在使用产品的第一天按字面意义写一本工作手册。
但是仅Ansible在工业环境中对我们来说还不够。否则，在限制访问和审核管理员的操作方面会存在很多问题。如何区分访问权限？毕竟，每个部门都需要管理（阅读-运行Ansible剧本）“其”服务器集。如何只允许某些员工运行特定的Ansible剧本？还是如何跟踪谁启动了剧本而不在Ansible服务器和硬件上运行许多本地KM的情况下？
红帽Ansible Tower或其开源上游Ansible AWX项目解决了此类问题中的绝大部分。因此，我们为客户选择它。
再加上我们CMS系统肖像的一触即发。Ansible剧本必须存储在代码存储库管理系统中。我们有这个GitLab CE。
因此，配置本身由Ansible / Ansible AWX / GitLab的捆绑包管理（参见图3）。当然，AWX / GitLab已与统一的身份验证系统集成，而Ansible剧本已与HashiCorp Vault集成。配置仅通过Ansible AWX进入生产环境，在该环境中设置了所有“游戏规则”：可以配置的人员和对象，在何处获取CMS的配置管理代码等。
数字：3.配置管理。
测试管理
我们的配置以代码形式显示。因此，我们被迫遵循与软件开发人员相同的规则。我们需要组织开发过程，持续测试，交付配置代码并将其应用到生产服务器。
如果没有立即执行此操作，则将停止维护和修改配置的书面角色，或者将停止在生产环境中运行。这种疼痛的治疗方法是已知的，并且在该项目中得到了回报：
- 每个角色都包含在单元测试中；
- 只要配置管理代码有任何更改，测试就会自动运行；
- 只有成功通过所有测试和代码审查后，配置管理代码中的更改才会进入生产环境。
代码开发和配置管理更加镇定和可预测。为了组织连续的测试，我们使用了GitLab CI / CD工具包，并采用了Ansible Molecule作为组织测试的框架。
对于配置管理代码中的任何更改，GitLab CI / CD会调用Molecule：
- 它检查代码的语法，
- 提起Docker容器，
- 将修改后的代码应用于生成的容器，
- 检查角色是否具有幂等性，并为此代码运行测试（此处的粒度位于ansible角色级别，请参见图4）。
我们使用Ansible AWX将配置交付到生产环境。运营工程师通过预定义的模板应用了配置更改。每次使用AWX时，它都会从GitLab主分支独立地“请求”最新版本的代码。这样，我们就排除了在生产环境中使用未经测试或过时的代码。自然，代码仅在经过测试，审查和批准后才进入master分支。
数字： 4.自动测试GitLab CI / CD中的角色。
还存在与生产系统的操作有关的问题。在现实生活中，仅通过CMS代码进行配置更改非常困难。当工程师必须在“这里和现在”更改配置而不等待代码编辑，测试，批准等情况时，会出现异常情况。
结果，由于手动更改，同一类型设备上的配置出现差异（例如，在HA群集的节点上） sysctl设置的不同配置）。或者硬件上的实际配置与CMS代码中的设置不同。
因此，除了连续测试之外，我们还要检查生产环境中的配置差异。我们选择了最简单的选项：在“空运行”模式下运行CMS配置代码，也就是说，无需应用更改，但会通知计划的配置与实际配置之间的所有差异。我们通过在生产服务器上定期使用“ --check”选项运行所有Ansible剧本来实现此目的。与往常一样，Ansible AWX负责该剧本的发布和相关性（见图5）：
数字： 5.检查Ansible AWX中的配置差异。
检查后，AWX将差异报告发送给管理员。他们研究问题的配置，然后通过调整后的剧本进行修复。这样，我们就可以在生产环境中维护配置，并且CMS始终是最新的并已同步。当CMS代码应用于“生产”服务器时，这消除了不愉快的“奇迹”。
现在，我们有一个重要的测试层，由Ansible AWX / GitLab / Molecule组成（图6）。
数字： 6.测试管理。
硬？我不争辩。但是，这样的配置管理复合体已成为对与服务器配置自动化有关的许多问题的全面解答。现在，零售商始终对标准服务器具有严格定义的配置。 CMS与工程师不同，它不会忘记添加必要的设置，创建用户并执行数十或数百个必需的设置。
如今，服务器和环境的设置中没有“秘密知识”。所有必要的功能都反映在剧本中。没有更多的创造力和模糊的说明：“像普通的Oracle一样放置它，但是您需要在其中注册一些sysctl设置，并使用所需的UID添加用户。从手术中问这些家伙，他们知道。”
能够检测到配置差异并事先进行纠正，这使您放心。如果没有CMS，通常情况会有所不同。问题会累积到一天，然后在生产中“解决”。然后执行汇报，检查并更正配置。而且周期又重复了
。当然，我们已经将服务器的生产发布从几天加速到了几个小时。
好吧，在除夕之夜，当孩子们高兴地打开包装的礼物，而当大人们鸣叫的时候，大人们发出了祝福，我们的工程师将SAP系统迁移到了新服务器上。甚至圣诞老人也会说，最好的奇迹是精心准备的。
PS我们的团队经常面临这样一个事实，即客户希望尽可能轻松地解决配置管理问题。理想情况下，好像是魔术一样-用一种工具。但是生活中，一切都变得更加复杂（是的，再次没有交付银弹）：您必须使用对客户团队方便的工具来创建整个流程。
作者：Sergey Artemov，Jet Infosystems的DevOps-solutions部门的架构师