🥇从“初创公司”到十几个数据中心的数千台服务器。我们如何追逐 Linux 基础设施的增长

如果您的 IT 基础设施增长太快，您迟早会面临一个选择：线性增加人力资源来支持它或开始自动化。直到某个时候，我们都生活在第一个范式中，然后通往基础设施即代码的漫长道路开始了。

当然，NSPK 并不是一家初创公司，但公司成立的头几年就弥漫着这样的氛围，那是非常有趣的几年。我的名字是德米特里·科尔尼亚科夫，我十多年来一直支持具有高可用性要求的 Linux 基础设施。他于10年2016月加入NSPK团队，不幸的是，他并没有看到公司成立的最初阶段，而是处于一个巨大变化的阶段。

一般来说，我们可以说我们的团队为公司提供了 2 种产品。首先是基础设施。邮件应该正常工作，DNS 应该正常工作，域控制器应该让您进入不应该崩溃的服务器。公司的IT格局巨大！这些是业务和任务关键型系统，某些系统的可用性要求为 99,999。第二个产品是服务器本身，包括物理服务器和虚拟服务器。现有的产品需要进行监控，并且新的产品必须定期从多个部门交付给客户。在本文中，我想重点讨论我们如何开发负责服务器生命周期的基础设施。

开始的旅程

在我们的旅程开始时，我们的技术堆栈如下所示：
操作系统 CentOS 7
FreeIPA 域控制器
自动化 - Ansible（+Tower）、Cobbler

所有这些都位于 3 个域中，分布在多个数据中心。一个数据中心有办公系统和测试站点，其余的有PROD。

在某一时刻创建服务器看起来像这样：

在VM模板中，CentOS是最小的，所需的最低限度就像正确的/etc/resolv.conf，其余的来自Ansible。

CMDB-Excel。

如果服务器是物理服务器，则不是复制虚拟机，而是使用 Cobbler 在其上安装操作系统 - 目标服务器的 MAC 地址添加到 Cobbler 配置中，服务器通过 DHCP 接收 IP 地址，然后操作系统被添加。

起初我们甚至尝试在 Cobbler 中进行某种配置管理。但随着时间的推移，这开始带来配置向其他数据中心和用于准备虚拟机的 Ansible 代码的可移植性问题。

当时，我们许多人都认为 Ansible 是 Bash 的便捷扩展，并没有吝惜使用 shell 和 sed 进行设计。整体 Bashible。这最终导致了这样一个事实：如果 playbook 由于某种原因无法在服务器上运行，则删除服务器、修复 playbook 并再次运行会更容易。基本上没有脚本的版本控制，也没有配置的可移植性。

例如，我们想更改所有服务器上的一些配置：

我们更改逻辑段/数据中心中现有服务器的配置。有时不是一天之内 - 可访问性要求和大数定律不允许立即应用所有更改。有些更改可能具有破坏性，需要重新启动某些内容 - 从服务到操作系统本身。
在 Ansible 中修复它
我们在 Cobbler 中修复它
对每个逻辑段/数据中心重复 N 次

为了让所有的改变能够顺利进行，需要考虑到很多因素，而改变也在不断地发生。

重构ansible代码、配置文件
改变内部最佳实践
根据事件/事故分析结果进行更改
不断变化的内部和外部安全标准。例如，PCI DSS 每年都会更新新的要求

基础设施的增长和旅程的开始

服务器/逻辑域/数据中心的数量增加，配置错误的数量也随之增加。在某些时候，我们得出了配置管理需要发展的三个方向：

自动化。应尽可能避免重复操作中的人为错误。
重复性。当基础设施可预测时，管理起来就会容易得多。服务器的配置和准备工具在任何地方都应该相同。这对于产品团队也很重要 - 测试后，必须保证应用程序最终位于与测试环境配置类似的生产环境中。
对配置管理进行更改的简单性和透明度。

仍然需要添加一些工具。

我们选择 GitLab CE 作为我们的代码存储库，尤其是因为它内置的 CI/CD 模块。

秘密金库 - Hashicorp Vault，包括。为了伟大的 API。

测试配置和 ansible 角色 – Molecule+Testinfra。如果您连接到 ansible mitogen，测试会更快。与此同时，我们开始编写自己的CMDB和编排器用于自动部署（上图中的Cobbler），但这是一个完全不同的故事，我的同事和这些系统的主要开发人员将在未来讲述。

我们的选择：

分子+测试基础设施
Ansible + 塔 + AWX
服务器世界 + DITNET（自行开发）
皮匠
Gitlab + GitLab 运行器
Hashicorp金库

顺便说一下ansible角色。一开始只有一个，经过几次重构，已经有17个了，我强烈建议把单体分解成幂等角色，然后可以单独启动；另外，还可以添加标签。我们按功能划分角色——网络、日志、包、硬件、分子等。总的来说，我们遵循以下策略。我并不坚持认为这是唯一的事实，但它对我们有用。

从“黄金镜像”复制服务器是邪恶的！主要缺点是您不知道映像现在处于什么状态，并且所有更改都将应用于所有虚拟化场中的所有映像。
尽量少用默认配置文件，并与其他部门同意你负责的主要系统文件例如：
1. 将 /etc/sysctl.conf 留空，设置只能在 /etc/sysctl.d/ 中。您在一个文件中使用默认值，在另一个文件中为应用程序自定义。
2. 使用覆盖文件来编辑 systemd 单元。
将所有配置模板化并完全包含它们；如果可能，剧本中不要使用 sed 或其类似物
重构配置管理系统代码：
1. 将任务分解为逻辑实体并将整体重写为角色
2. 使用短绒棉！ Ansible-lint、yaml-lint 等
3. 改变你的方法！没有bashsible。需要描述系统的状态
对于所有 Ansible 角色，您需要在 molecular 中编写测试并每天生成一次报告。
在我们的例子中，准备测试（其中有 100 多个）后，发现了大约 70000 个错误。花了几个月的时间才修复它。

我们的实施

因此，ansible 角色已准备就绪，并由 linter 进行模板化和检查。甚至到处都养着小鸡。但向不同细分市场可靠地交付代码的问题仍然悬而未决。我们决定与脚本同步。看起来像这样：

更改到达后，启动 CI，创建测试服务器，推出角色，并由分子进行测试。如果一切正常，代码将转到 prod 分支。但我们不会将新代码应用到机器中现有的服务器上。这是我们系统的高可用性所必需的一种停止器。当基础设施变得庞大时，大数定律就会发挥作用——即使你确信这种变化是无害的，它也可能导致可怕的后果。

创建服务器的选项也有很多。我们最终选择了自定义 Python 脚本。对于 CI ansible：

- name: create1.yml - Create a VM from a template
  vmware_guest:
    hostname: "{{datacenter}}".domain.ru
    username: "{{ username_vc }}"
    password: "{{ password_vc }}"
    validate_certs: no
    cluster: "{{cluster}}"
    datacenter: "{{datacenter}}"
    name: "{{ name }}"
    state: poweredon
    folder: "/{{folder}}"
    template: "{{template}}"
    customization:
      hostname: "{{ name }}"
      domain: domain.ru
      dns_servers:
        - "{{ ipa1_dns }}"
        - "{{ ipa2_dns }}"
    networks:
      - name: "{{ network }}"
        type: static
        ip: "{{ip}}"
        netmask: "{{netmask}}"
        gateway: "{{gateway}}"
        wake_on_lan: True
        start_connected: True
        allow_guest_control: True
    wait_for_ip_address: yes
    disk:
      - size_gb: 1
        type: thin
        datastore: "{{datastore}}"
      - size_gb: 20
        type: thin
        datastore: "{{datastore}}"

这就是我们所面临的情况，该系统将继续存在和发展。

17 个用于设置服务器的 Ansible 角色。每个角色都旨在解决单独的逻辑任务（日志记录、审计、用户授权、监控等）。
角色测试。分子+测试基础设施。
自己开发：CMDB + Orchestrator。
服务器创建时间约为 30 分钟，是自动化的，并且几乎独立于任务队列。
所有部分中基础设施的状态/命名相同 - 剧本、存储库、虚拟化元素。
每日检查服务器状态，并生成与标准不一致的报告。

我希望我的故事对那些刚开始旅程的人有用。您使用什么自动化堆栈？

来源： habr.com

从“初创公司”到十几个数据中心的数千台服务器。 我们如何追逐 Linux 基础设施的增长

从“初创公司”到十几个数据中心的数千台服务器。我们如何追逐 Linux 基础设施的增长