Clever Geek Handbook

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

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







もちろん、NSPKはスタートアップではありませんが、そのような雰囲気が会社の最初の数年間に広まったので、これらは非常に興味深い年でした。私の名前はDmitry Kornyakovです。10年以上、高可用性要件のあるLinuxインフラストラクチャをサポートしています。彼は2016年1月にNSPKチームに参加しましたが、残念ながら会社の存在の始まりは見えませんでしたが、大きな変化の段階にありました。



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



パス



の始まりパスの始まりでは、テクノロジースタックは次のようになりました 。OSCentOS

7

ドメインコントローラーFreeIPA

Automation-Ansible（+ Tower）、Cobbler



これらはすべて3つのドメインにあり、複数のデータセンターに分散しています。 1つのデータセンター-オフィスシステムとテストサイト、残りのPROD。



ある時点で、サーバーの作成は次のように







なりました。VMCentOSの最小限のテンプレートと必要な最小限のテンプレート（正しい/etc/resolv.confなど）では、残りはAnsibleを介して行われます。



CMDB-Excel。



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



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



当時、私たちの多くは、AnsibleをBashの便利な拡張機能と認識しており、sedを使用してシェルを使用した構造を損なうことはありませんでした。一般的にはBashsibleです。これは最終的に、何らかの理由でサーバー上でPlaybookが機能しない場合、サーバーを削除し、Playbookを修正して再実行する方が簡単であるという事実につながりました。実際、スクリプトのバージョン管理や構成の移植性もありませんでした。



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



  1. 論理セグメント/データセンター内の既存のサーバーの構成を変更します。時には一晩ではない-可用性の要件と多数の法則により、すべての変更を一度に適用することはできません。また、一部の変更は潜在的に破壊的であり、サービスからOS自体まで、何でも再起動する必要があります。
  2. Ansibleでの修正
  3. コブラーの修正
  4. 各論理セグメント/データセンターに対してN回繰り返す


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



  • Ansibleコード、構成ファイルのリファクタリング
  • 内部のベストプラクティスの変更
  • インシデント/アクシデントの分析後の変化
  • 内部および外部の両方のセキュリティ標準の変更。たとえば、PCI DSSは毎年新しい要件で更新されます


インフラストラクチャの増加とパスの始まり



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



  1. オートメーション。可能な限り、反復操作の人的要因は回避する必要があります。
  2. . , . . – , .
  3. configuration management.


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



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



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



テスト構成とansibleロール-Molecule + Testinfra。 ansible mitogenに接続すると、テストははるかに速く実行されます。並行して、自動展開用の独自のCMDBとオーケストレーター（Cobblerの上の図を参照）を書き始めましたが、これはまったく別の話であり、私の同僚とこれらのシステムの主な開発者が将来話します。



私たちの選択：



Molecule + Testinfra

Ansible + Tower + AWX Server

World + DITNET（社内）

Cobbler

Gitlab + GitLabランナー

Hashicorp Vault









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



  • 「ゴールデンイメージ」からサーバーをコピーするのは悪いことです。



    主な欠点は、イメージの現在の状態が正確にわからないことと、すべての変更がすべての仮想化ファームのすべてのイメージに反映されることです。
  • デフォルトの構成ファイルを最小限にして、担当するコアシステムファイルについて他の部門に同意します。次に例を示します。



    1. /etc/sysctl.conf , /etc/sysctl.d/. , .
    2. override systemd .
  • , sed
  • :



    2. ! Ansible-lint, yaml-lint, etc
    3. ! bashsible.
  • Ansible molecule .
  • , ( 100) 70000 . .





私たちの実装



これで、ansibleロールは準備が整い、テンプレート化され、リンターによってチェックされました。そしてGitさえ至る所で発生します。しかし、さまざまなセグメントにコードを確実に配信するという問題は未解決のままでした。スクリプトと同期することにしました。それは次のようになります。







変更が到着した後、CIは、ロールがロールバックされ、テストサーバーが作成され、打ち上げ分子でテストされています。すべて問題なければ、コードは本番ブランチに送られます。ただし、マシン内の既存のサーバーに新しいコードを適用するわけではありません。これは、システムの高可用性に必要な一種のストッパーです。そして、インフラストラクチャが巨大になると、多数の法則が作用します-変更が無害であると確信している場合でも、それは悲しい結果につながる可能性があります。



サーバーを作成するための多くのオプションもあります。最終的にはカスタム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ロール。それぞれの役割は、個別の論理タスク（ロギング、監査、ユーザー認証、監視など）を解決するように設計されています。
  • 役割テスト。Molecule + TestInfra。
  • 独自開発：CMDB + Orchestrator。
  • サーバー作成時間〜30分、自動化され、タスクキューから実質的に独立しています。
  • プレイブック、リポジトリ、仮想化要素など、すべてのセグメントでインフラストラクチャの同じ状態/命名。
  • 標準との不一致に関するレポートを生成して、サーバーのステータスを毎日チェックします。


私の話が旅の始めにいる人たちに役立つことを願っています。どの自動化スタックを使用していますか？


More articles:


All Articles