「スタートアップ」から、十数のデータセンターにある数千台のサーバーまで。 Linux インフラストラクチャの成長をどのように追いかけたか

IT インフラストラクチャの成長が速すぎると、遅かれ早かれ、それをサポートするために人的リソースを直線的に増やすか、自動化を開始するかの選択を迫られることになります。 ある時点まで、私たちは最初のパラダイムに住んでいましたが、その後、Infrastructure-as-Code への長い道のりが始まりました。

もちろん、NSPK はスタートアップではありませんが、設立当初の数年間は社内にそのような雰囲気があり、非常に興味深い数年間でした。 私の名前は コルニャコフ・ドミトリー, 私は 10 年以上にわたり、高可用性要件を備えた Linux インフラストラクチャをサポートしてきました。 彼は 2016 年 XNUMX 月に NSPK チームに加わりました。残念なことに、会社の誕生の瞬間は見ていませんでしたが、大きな変化の段階に来ました。

一般に、私たちのチームは会社に 2 つの製品を供給していると言えます。 99,999つ目はインフラストラクチャです。 メールが機能し、DNS が機能し、ドメイン コントローラーがクラッシュしないサーバーにアクセスできるようにする必要があります。 同社の IT 環境は巨大です。 これらはビジネスおよびミッションクリティカルなシステムであり、一部の可用性要件は XNUMX です。 XNUMX 番目の製品は、物理サーバーと仮想サーバー自体です。 既存のものは監視する必要があり、新しいものは多くの部門から定期的に顧客に届ける必要があります。 この記事では、サーバーのライフサイクルを担うインフラストラクチャをどのように開発したかに焦点を当てたいと思います。

旅の始まり

私たちの旅の開始時点では、私たちのテクノロジー スタックは次のようになっていました。
OS CentOS 7
FreeIPA ドメイン コントローラー
自動化 - Ansible(+Tower)、Cobbler

これらすべては、複数のデータセンターにまたがる 3 つのドメインに配置されていました。 XNUMX つのデータ センターにはオフィス システムとテスト サイトがあり、残りのデータ センターには PROD があります。

ある時点でのサーバーの作成は次のようになります。

VM テンプレートでは、CentOS は最小限であり、必要な最小限は正しい /etc/resolv.conf のようなもので、残りは Ansible を通じて取得されます。

CMDB - Excel。

サーバーが物理サーバーの場合、仮想マシンをコピーする代わりに、Cobbler を使用して OS がインストールされます。ターゲット サーバーの MAC アドレスが Cobbler 構成に追加され、サーバーは DHCP 経由で IP アドレスを受け取り、次に OS を受け取ります。が追加されます。

最初は、Cobbler で何らかの構成管理を実行しようとさえしました。 しかし、時間の経過とともに、これにより、他のデータセンターと VM を準備するための Ansible コードの両方への構成の移植性に問題が発生し始めました。

当時、私たちの多くは Ansible を Bash の便利な拡張機能として認識しており、シェルと sed を使用した設計を軽視しませんでした。 全体的にバシブル。 これにより、最終的には、プレイブックが何らかの理由でサーバー上で動作しなかった場合、サーバーを削除し、プレイブックを修正して再実行する方が簡単になるという事実につながりました。 基本的にスクリプトのバージョン管理や構成の移植性はありませんでした。

たとえば、すべてのサーバーの構成を変更したいと考えました。

1. 論理セグメント/データセンター内の既存サーバーの構成を変更します。 XNUMX 日で完了しない場合もあります。アクセシビリティ要件と大数の法則により、すべての変更を一度に適用することはできません。 また、一部の変更は破壊的なものになる可能性があり、サービスから OS 自体に至るまで、何かを再起動する必要があります。
2. Ansible で修正する
3. Cobbler で修正します
4. 各論理セグメント/データセンターに対して N 回繰り返します

すべての変更をスムーズに進めるためには、多くの要因を考慮する必要があり、変更は常に発生します。

• Ansible コード、構成ファイルのリファクタリング
• 社内のベストプラクティスの変更
• 事件・事故の分析結果に基づく変更
• 社内外のセキュリティ基準の変化。 たとえば、PCI DSS は毎年新しい要件で更新されます。

インフラストラクチャの成長と旅の始まり

サーバー/論理ドメイン/データセンターの数が増加し、それに伴い構成エラーの数も増加しました。 ある時点で、構成管理を開発する必要がある XNUMX つの方向性が見えてきました。

1. オートメーション。 繰り返しの作業における人的エラーは可能な限り回避する必要があります。
2. 再現性。 インフラストラクチャが予測可能であれば、管理がはるかに簡単になります。 サーバーの構成とその準備のためのツールはどこでも同じである必要があります。 これは製品チームにとっても重要です。テスト後、アプリケーションがテスト環境と同様に構成された運用環境に移行することが保証される必要があります。
3. 構成管理への変更のシンプルさと透明性。

いくつかのツールを追加する必要があります。

私たちは、特にその組み込み CI/CD モジュールのために、コード リポジトリとして GitLab CE を選択しました。

秘密の保管庫 - Hashicorp Vault、 素晴らしい API のために。

テスト構成と Ansible ロール – Molecule+Testinfra。 ansible mitogen に接続すると、テストが大幅に高速化されます。 同時に、私たちは自動展開用に独自の CMDB とオーケストレーターを書き始めました (Cobbler 上の図) が、これはまったく別の話であり、私の同僚とこれらのシステムの主な開発者が将来語ることになります。

私たちの選択:

分子 + テストインフラ
Ansible + タワー + AWX
World of Servers + DITNET (自社開発)
コブラー
Gitlab + GitLab ランナー
ハシコープ保管庫

ところで、ansibleのロールについて。 最初は 17 つだけでしたが、数回のリファクタリングの後、XNUMX 個になりました。モノリスを冪等のロールに分割し、個別に起動できるようにすることを強くお勧めします。さらに、タグを追加できます。 ネットワーク、ロギング、パッケージ、ハードウェア、分子などの機能ごとに役割を分割しました。 一般に、私たちは以下の戦略に従いました。 これが唯一の真実だと主張するわけではありませんが、私たちにとってはうまくいきました。

• 「ゴールデン イメージ」からサーバーをコピーするのは悪です。主な欠点は、イメージが現在どのような状態にあるのか正確にわからないことと、すべての変更がすべての仮想化ファームのすべてのイメージに反映されることです。
• デフォルトの構成ファイルの使用は最小限にし、メインのシステム ファイルを担当する他の部門と合意します。たとえば、次のようになります。
  1. /etc/sysctl.conf は空のままにしておきます。設定は /etc/sysctl.d/ にのみ存在する必要があります。 あるファイルではデフォルトを、別のファイルではアプリケーション用にカスタムします。
  2. オーバーライド ファイルを使用して systemd ユニットを編集します。
• すべての構成をテンプレート化し、それらを完全に含めます。可能であれば、Playbook に sed またはその類似物を含めないでください。
• 構成管理システムのコードをリファクタリングします。
  1. タスクを論理エンティティに分割し、モノリスをロールに書き換えます。
  2. リンターを使おう！ Ansible-lint、yaml-lint など
  3. アプローチを変えましょう！ バシブルではありません。 システムの状態を説明する必要がある
• すべての Ansible ロールについて、分子内でテストを作成し、XNUMX 日に XNUMX 回レポートを生成する必要があります。
• 私たちの場合、テスト (100 以上あります) を準備した後、約 70000 個のエラーが見つかりました。 それを修正するのに数か月かかりました。

私たちの実装

これで、Ansible ロールの準備が整い、テンプレート化され、リンターによってチェックされました。 そして、gitさえどこでも発生します。 しかし、さまざまなセグメントへの信頼性の高いコード配信の問題は未解決のままでした。 スクリプトと同期することにしました。 次のようです:

変更が到着すると、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