新年が近づいてきました。 国中の子供たちはすでにサンタクロースに手紙を送ったり、自分たちへのプレゼントを作ったりしており、その主な実行者である大手小売業者のXNUMX社は、売り上げを神格化する準備を進めていた。 XNUMX 月には、データセンターの負荷が数倍に増加します。 そこで同社は、データセンターを最新化し、耐用年数に達しつつある機器の代わりに数十台の新しいサーバーを稼働させることを決定しました。 これで、渦巻く雪片を背景に物語は終わり、スリラーが始まります。

機器は販売のピークの数か月前に現場に到着しました。 もちろん、運用サービスは、サーバーを実稼働環境に導入するために、サーバー上で何をどのように構成すればよいかを知っています。 しかし、これを自動化し、人的要因を排除する必要がありました。 さらに、会社にとって重要な一連の SAP システムの移行前にサーバーが交換されました。

新しいサーバーの稼働には期限が厳密に縛られていました。 そして、それを移動するということは、31億個のギフトの発送とシステムの移行の両方を危険にさらすことを意味しました。 フロスト神父とサンタクロースで構成されたチームでも日付を変更することはできませんでした。倉庫管理用の SAP システムを転送できるのは年に 1 回だけです。 20 月 15 日から XNUMX 月 XNUMX 日まで、サッカー場 XNUMX 個分に相当するこの小売業者の巨大な倉庫は XNUMX 時間稼働を停止します。 そして、システムを移動するのはこの期間だけです。 サーバーの導入に失敗は許されませんでした。

明確にしておきますが、私の話は私たちのチームが使用しているツールと構成管理プロセスを反映しています。

構成管理複合体は、いくつかのレベルで構成されます。 重要なコンポーネントは CMS システムです。 工業的な運用では、レベルの XNUMX つが欠けていると、必然的に不快な奇跡が発生します。

OSのインストール管理

最初のレベルは、物理サーバーおよび仮想サーバーへのオペレーティング システムのインストールを管理するシステムです。 基本的な OS 構成を作成し、人的要因を排除します。

このシステムを使用して、さらなる自動化に適した OS を備えた標準サーバー インスタンスを受け取りました。 「注入」中に、ローカル ユーザーと公開 SSH キーの最小限のセット、および一貫した OS 構成を受け取りました。 CMS を通じてサーバーを管理することが保証されており、OS レベルで「下位」に予期せぬ事態が発生することはないと確信していました。

インストール管理システムの「最大の」タスクは、BIOS/ファームウェア レベルから OS までサーバーを自動的に構成することです。 ここでの多くは、機器とセットアップ作業に依存します。 異種機器の場合は、次のことを検討できます。 レッドフィッシュ API。 すべてのハードウェアが XNUMX つのベンダーから提供されている場合、多くの場合、既製の管理ツール (HP ILO Amplifier、DELL OpenManage など) を使用する方が便利です。

物理サーバーに OS をインストールするには、運用サービスと合意された一連のインストール プロファイルを定義するよく知られた Cobbler を使用しました。 新しいサーバーをインフラストラクチャに追加するとき、エンジニアはサーバーの MAC アドレスを Cobbler の必要なプロファイルに関連付けました。 初めてネットワーク経由で起動するとき、サーバーは一時アドレスと新しい OS を受け取りました。 その後、ターゲットの VLAN/IP アドレスに転送され、そこで作業が継続されました。 はい、VLAN の変更には時間がかかり、調整が必要ですが、実稼働環境でのサーバーの誤ったインストールに対する追加の保護が提供されます。

HashiСorp Packerで用意したテンプレートを基に仮想サーバーを作成しました。 理由は同じで、OS のインストール時に起こり得る人的ミスを防ぐためです。 ただし、物理サーバーとは異なり、Packer では PXE、ネットワークの起動、VLAN の変更が必要ありません。 これにより、仮想サーバーの作成がより簡単かつシンプルになりました。

米。 1. オペレーティング システムのインストールを管理します。

シークレットの管理

どの構成管理システムにも、一般ユーザーには隠すべきデータが含まれていますが、システムを準備するためには必要です。 これらは、ローカル ユーザーとサービス アカウントのパスワード、証明書キー、さまざまな API トークンなどです。これらは通常「シークレット」と呼ばれます。

これらのシークレットをどこにどのように保存するかを最初から決定しない場合、情報セキュリティ要件の重大度に応じて、次のような保存方法が考えられます。

• 構成制御コード内またはリポジトリ内のファイル内で直接。
• 特殊な構成管理ツール (Ansible Vault など)。
• CI/CD システム (Jenkins/TeamCity/GitLab/など) または構成管理システム (Ansible Tower/Ansible AWX)。
• シークレットは「手動」で転送することもできます。 たとえば、それらは指定された場所に配置され、構成管理システムによって使用されます。
• 上記のさまざまな組み合わせ。

各方法には独自の欠点があります。 主な問題は、シークレットへのアクセスに関するポリシーが欠如していることです。特定のシークレットを誰が使用できるかを判断することが不可能または困難です。 もう XNUMX つの欠点は、アクセス監査と完全なライフサイクルがないことです。 たとえば、コードや多くの関連システムに記述されている公開キーを素早く置き換えるにはどうすればよいでしょうか?

私たちは集中型秘密ストレージ HashiCorp Vault を使用しました。 これにより、次のことが可能になりました。

• 秘密を安全に保ちます。 これらは暗号化されており、たとえ誰かが (バックアップから復元するなどして) Vault データベースにアクセスしたとしても、そこに保存されている秘密を読み取ることはできません。
• 秘密へのアクセスに関するポリシーを整理します。 ユーザーとアプリケーションは、「割り当てられた」シークレットのみを利用できます。
• シークレットへのアクセスを監査します。 シークレットを使用したアクションはすべて、Vault 監査ログに記録されます。
• 秘密を扱う本格的な「ライフサイクル」を組織します。 作成、取り消し、有効期限の設定などを行うことができます。
• 秘密へのアクセスが必要な他のシステムと簡単に統合できます。
• また、エンドツーエンドの暗号化、OS とデータベースのワンタイム パスワード、認定センターの証明書なども使用します。

次に、中央の認証および認可システムに移りましょう。 これがなくても可能ですが、多くの関連システムでユーザーを管理するのは非常に簡単ではありません。 LDAP サービスを介して認証と認可を構成しました。 それ以外の場合、Vault はユーザーの認証トークンを継続的に発行して追跡する必要があります。 そして、ユーザーの削除と追加は、「このユーザー アカウントをどこでも作成/削除したか?」という疑問に変わります。

私たちはシステムに別のレベル、つまり秘密管理と集中認証/認可を追加します。

米。 2. 機密管理。

構成管理

私たちは核心である CMS システムに到達しました。 私たちの場合、これは Ansible と Red Hat Ansible AWX の組み合わせです。

Ansible の代わりに、Chef、Puppet、SaltStack を使用できます。 いくつかの基準に基づいて Ansible を選択しました。

• まず第一に、それは多用途性です。 制御用の既製モジュールのセット 印象的です。 十分でない場合は、GitHub や Galaxy で検索できます。
• 第 XNUMX に、管理対象機器にエージェントをインストールしてサポートしたり、エージェントが負荷に干渉しないことを証明したり、「ブックマーク」がないことを確認したりする必要がありません。
• 第三に、Ansible は参入障壁が低いです。 有能なエンジニアは、文字通り製品を扱う初日に実用的なプレイブックを作成します。

しかし、本番環境での Ansible だけでは十分ではありませんでした。 そうしないと、アクセスの制限や管理者のアクションの監査に多くの問題が発生します。 アクセスを制限するにはどうすればよいですか? 結局のところ、各部門が「独自の」サーバーのセットを管理 (つまり、Ansible プレイブックを実行する) する必要がありました。 特定の従業員のみに特定の Ansible Playbook の実行を許可するにはどうすればよいですか? あるいは、Ansible を実行しているサーバーや機器に関する多くのローカル情報を設定せずに、プレイブックを起動した人を追跡するにはどうすればよいでしょうか?

このような問題の大部分は Red Hat によって解決されます Ansible タワー、または彼のオープンソースの上流プロジェクト アンシブル AWX。 だからこそ、私たちはお客様にとってそれを好んだのです。

そして、CMS システムの概要についてもう XNUMX つ触れておきます。 Ansible Playbook はコード リポジトリ管理システムに保存する必要があります。 我々はそれを持っています GitLab CE.

そのため、構成自体は Ansible/Ansible AWX/GitLab の組み合わせによって管理されます (図 3 を参照)。 もちろん、AWX/GitLab は単一の認証システムと統合されており、Ansible Playbook は HashiCorp Vault と統合されています。 構成は Ansible AWX を介してのみ実稼働環境に入ります。Ansible AWX では、誰が何を構成できるか、CMS の構成管理コードをどこで入手するかなど、すべての「ゲームのルール」が指定されます。

米。 3. 構成管理。

テスト管理

私たちの構成はコード形式で示されています。 したがって、私たちはソフトウェア開発者と同じルールに従って行動することを強いられます。 開発、継続的なテスト、構成コードの運用サーバーへの配信および適用のプロセスを整理する必要がありました。

これをすぐに行わないと、構成用に作成されたロールのサポートと変更が中止されるか、運用環境での起動が中止されます。 この痛みの治療法は知られており、それがこのプロジェクトで証明されました。

• 各役割は単体テストでカバーされます。
• テストは、構成を管理するコードに変更があるたびに自動的に実行されます。
• 構成管理コードの変更は、すべてのテストとコード レビューに合格した後にのみ実稼働環境にリリースされます。

コード開発と構成管理は、より穏やかになり、予測可能になりました。 継続的なテストを組織するために、GitLab CI/CD ツールキットを使用し、 アンシブル分子.

構成管理コードに変更があるたびに、GitLab CI/CD は Molecule を呼び出します。

• コードの構文をチェックします。
• Dockerコンテナを起動します。
• 変更したコードを作成したコンテナに適用します。
• ロールの冪等性をチェックし、このコードのテストを実行します (ここでの粒度は ansible ロール レベルです。図 4 を参照)。

Ansible AWX を使用して構成を実稼働環境に配信しました。 運用エンジニアは、事前定義されたテンプレートを通じて構成変更を適用しました。 AWX は、コードが使用されるたびに、GitLab マスター ブランチに最新バージョンのコードを独自に「リクエスト」しました。 このようにして、実稼働環境でテストされていないコードや古いコードの使用を排除しました。 当然のことながら、コードはテスト、レビュー、承認後にのみマスター ブランチに入ります。

米。 4. GitLab CI/CD でのロールの自動テスト。

実稼働システムの運用に関連する問題もあります。 実際には、CMS コードだけで構成を変更することは非常に困難です。 緊急事態は、エンジニアがコードの編集、テスト、承認などを待たずに、「今ここで」構成を変更しなければならないときに発生します。

その結果、手動による変更により、同じタイプの機器の設定に不一致が生じます (たとえば、sysctl 設定が HA クラスタ ノードで異なるように設定されているなど)。 または、機器の実際の設定が CMS コードで指定されたものと異なります。

したがって、継続的なテストに加えて、実稼働環境で構成の矛盾がないかチェックします。 私たちは最も単純なオプションを選択しました。つまり、CMS 構成コードを「ドライラン」モードで実行します。つまり、変更は適用されませんが、計画された構成と実際の構成の間のすべての不一致が通知されます。 これを実装するには、運用サーバー上で「-check」オプションを使用してすべての Ansible プレイブックを定期的に実行します。 いつものように、Ansible AWX は、プレイブックを起動して最新の状態に保つ役割を果たします (図 5 を参照)。

米。 5. Ansible AWX の設定の不一致をチェックします。

チェック後、AWX は不一致レポートを管理者に送信します。 彼らは問題のある構成を調査し、調整されたプレイブックを通じてそれを修正します。 これにより、実稼働環境で構成が維持され、CMS は常に最新の状態に保たれ、同期されます。 これにより、CMS コードが「運用」サーバーで使用されるときの不快な「奇跡」が排除されます。

これで、Ansible AWX/GitLab/Molecule で構成される重要なテスト層ができました (図 6)。

米。 6. テスト管理。

難しい？ 私は議論しません。 しかし、このような複雑な構成管理は、サーバー構成の自動化に関する多くの質問に対する包括的な答えとなっています。 現在、小売業者の標準サーバーには常に厳密に定義された構成が含まれています。 CMS はエンジニアとは異なり、必要な設定を追加したり、ユーザーを作成したり、数十、数百もの必要な設定を実行したりすることを忘れません。

現在、サーバーや環境の設定に「秘密の知識」はありません。 必要な機能はすべて Playbook に反映されます。 創造性や曖昧な指示はもう必要ありません。」通常の Oracle と同じようにインストールしますが、sysctl 設定をいくつか指定し、必要な UID を持つユーザーを追加する必要があります。 運営の人に聞けばわかるよ'。

構成の不一致を検出し、プロアクティブに修正できるため、安心感が得られます。 構成管理システムがなければ、これは通常とは異なって見えます。 問題は蓄積し、ある日それが本番環境に「発生」します。 その後、報告会が実施され、構成が確認され、修正されます。 そしてそのサイクルがまた繰り返される

そしてもちろん、サーバーの稼働開始までの時間を数日から数時間に短縮しました。

さて、大晦日、子供たちが嬉しそうにプレゼントの包装を開け、大人がチャイムが鳴るたびに願い事をしていた頃、当社のエンジニアは SAP システムを新しいサーバーに移行しました。 サンタクロースでさえ、最高の奇跡はよく準備されたものだと言うでしょう。

PS 私たちのチームは、お客様が構成管理の問題をできるだけ簡単に解決したいと考えているという事実によく遭遇します。 理想的には、まるで魔法のように、XNUMX つのツールで。 しかし、現実ではすべてがより複雑です (はい、特効薬は再び提供されませんでした)。顧客のチームにとって便利なツールを使用してプロセス全体を作成する必要があります。

著者: Sergey Artemov、部門設計者 DevOps ソリューション 「ジェットインフォシステムズ」

出所： habr.com