新年が近づいていました。全国の子供たちがすでにサンタクロースに手紙を送ったり、自分たちに贈り物をしたりしており、主要な小売業者の1つである彼らの主な出演者は販売の黙示録の準備をしていました。12月には、データセンターの負荷が数倍になります。そのため、同社はデータセンターを最新化し、耐用年数の終わりに近づいていた機器の代わりに数十の新しいサーバーを稼働させることを決定しました。これで、渦巻く雪片を背景にした格言が終わり、スリラーが始まります。





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



新しいサーバーの試運転は、締め切りと密接に結びついていました。そしてそれを動かすことは、10億の贈り物の輸送とシステムの移行の両方を危険にさらすでしょう。サンタクロースとサンタクロースで構成されるチームでさえ、日付を変更することはできませんでした。倉庫管理用のSAPシステムは、年に1回しか転送できません。 12月31日から1月1日まで、小売業者の巨大な倉庫、合計20のサッカー場が、15時間作業を停止します。そして、これはシステムが移動する唯一の時間です。サーバーへの入力を間違える権利はありませんでした。



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



構成管理コンプレックスは、いくつかのレベルで構成されています。重要なコンポーネントはCMSシステムです。産業開発では、レベルの1つがないと、必然的に不快な奇跡が発生します。

OSインストール管理

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



このシステムの助けを借りて、OSを備えたサーバーのさらなる自動化インスタンスに適した標準を受け取りました。キャストされたとき、彼らは最小限のローカルユーザーと公開SSHキーのセット、および一貫したOS構成を受け取りました。 CMSを介してサーバーを管理することが保証され、OSレベルで「下」に驚きがないことを確信できました。



インストール管理システムの最大の目標は、BIOS /ファームウェアレベルからOSまでサーバーを自動的に構成することです。ハードウェアと構成タスクに大きく依存します。異なる機器については、REDFISHAPIを検討してください..。すべてのハードウェアが1つのベンダーのものである場合は、多くの場合、既製の管理ツール（HP ILOアンプ、DELL OpenManageなど）を使用する方が便利です。



OSを物理サーバーにインストールするために、メンテナンスサービスと調整されたインストールプロファイルのセットを定義する有名なCobblerを使用しました。インフラストラクチャに新しいサーバーを追加する場合、エンジニアはサーバーのMACアドレスをCobblerの必要なプロファイルにバインドします。ネットワークを介した最初の起動時に、サーバーは一時アドレスと新しいOSを受け取りました。次に、ターゲットVLAN / IPアドレッシングに転送され、そこで動作し続けました。はい、VLANの変更には時間がかかり、調整が必要ですが、実稼働環境でのサーバーの偶発的なインストールに対する追加の保護を提供します。



HashiCorpPackerを使用して作成したテンプレートに基づいて仮想サーバーを作成しました。理由は同じです。OSのインストール時に発生する可能性のある人的エラーを防ぐためです。ただし、物理サーバーとは異なり、PackerではPXE、ネットワークブート、およびVLAN変更を使用できません。これにより、仮想サーバーの作成がより簡単かつ簡単になりました。





図：1.オペレーティングシステムのインストールの管理。

秘密の管理

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



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

• 構成管理コードまたはリポジトリ内のファイル内。
• 専用の構成管理ツール（Ansible Vaultなど）。
• CI / CDシステム（Jenkins / TeamCity / GitLab /など）または構成管理システム（Ansible Tower / Ansible AWX）;
• また、秘密は「手動制御」に移すことができます。たとえば、合意された場所に配置され、構成管理システムによって使用されます。
• 上記のさまざまな組み合わせ。

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



一元化されたHashiCorpVaultを使用しました。これにより、次のことが可能になりました。

• 秘密を安全に保管してください。それらは暗号化されており、誰かがVaultデータベースにアクセスしたとしても（たとえば、バックアップから復元することによって）、そこに保存されているシークレットを読み取ることはできません。
• . «» ;
• . Vault;
• « » . , , . .
• , ;
• , , ..

それでは、中央の認証および承認システムに移りましょう。それがなくても実行できますが、関連する多くのシステムでユーザーを管理するのは簡単すぎます。LDAPサービスを介して認証と承認を構成しました。そうしないと、同じVaultがユーザーの認証トークンの記録を継続的に発行して保持する必要があります。また、ユーザーを削除および追加すると、「このUZをどこでも作成/削除しましたか？」というクエストになります。



システムにもう1つのレベルを追加します。シークレットの管理と中央認証/承認：





図：2.秘密の管理。

構成管理

コア、つまりCMSシステムに到達しました。私たちの場合、これはAnsibleとRed Hat AnsibleAWXの束です。



シェフ、パペット、ソルトスタックはアンシブルの代わりに行動することができます。いくつかの基準でAnsibleを選択しました。

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

しかし、産業環境では、Ansibleだけでは十分ではありませんでした。そうしないと、アクセスの制限と管理者のアクションの監査に多くの問題が発生します。アクセスを区別する方法は？結局のところ、各部門はサーバーの「その」セットを管理（読む-Ansibleプレイブックを実行する）する必要がありました。特定の従業員のみが特定のAnsibleプレイブックを実行できるようにするにはどうすればよいですか？または、Ansibleサーバーとハードウェアで多くのローカルKMを実行せずに、誰がプレイブックを起動したかを追跡する方法はありますか？



Red Hat Ansible Tower、またはそのオープンソースのアップストリームAnsible AWXプロジェクトは、そのような問題の大部分を解決します。したがって、私たちは顧客のためにそれを好みました。



そして、CMSシステムのポートレートにもう1つ触れます。Ansible Playbookは、コードリポジトリ管理システムに保存する必要があります。このGitLabCEがあります。



したがって、構成自体は、Ansible / Ansible AWX / GitLabのバンドルによって管理されます（図3を参照）。もちろん、AWX / GitLabは統合認証システムと統合されており、AnsibleプレイブックはHashiCorpVaultと統合されています。構成は、Ansible AWXを介してのみ実稼働環境に入ります。この環境では、構成できるユーザーと対象、CMSの構成管理コードの取得先など、すべての「ゲームのルール」が設定されています。





図：3.構成管理。

テスト管理

構成はコードとして表示されます。したがって、私たちはソフトウェア開発者と同じルールでプレイすることを余儀なくされています。開発プロセス、継続的なテスト、配信、および実稼働サーバーへの構成コードの適用を整理する必要がありました。



これがすぐに行われなかった場合、構成用に記述された役割は、維持および変更されなくなるか、本番環境での実行を停止します。この痛みの治療法は知られており、このプロジェクトで成果を上げました。

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

コード開発と構成管理はより穏やかで、より予測可能です。継続的なテストを整理するために、我々はGitLab CI / CDツールキットを使用して、我々は取っAnsible分子をテストを整理するためのフレームワークとして。



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

• コードの構文をチェックし、
• Dockerコンテナを持ち上げ、
• 変更されたコードを生成されたコンテナに適用し、
• 役割の同一性をチェックし、このコードのテストを実行します（ここでの粒度は、実行可能な役割レベルです。図4を参照してください）。

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





図： 4. GitLab CI / CDでの役割の自動テスト。



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



その結果、手動での変更により、構成の不一致が同じタイプの機器（HAクラスターのノードなど）に表示されます。 sysctl設定の異なる構成）。または、ハードウェアの実際の構成がCMSコードで設定されているものと異なります。



したがって、継続的なテストに加えて、構成の不一致がないか実稼働環境をチェックします。最も単純なオプションを選択しました。CMS構成コードを「ドライラン」モードで実行します。つまり、変更を適用せずに、計画された構成と実際の構成の間のすべての不一致を通知します。これは、本番サーバーで「--check」オプションを指定してすべてのAnsibleプレイブックを定期的に実行することで実装されています。 Ansible AWXは、いつものように、プレイブックの立ち上げと関連性に責任があります（図5を参照）。





図： 5. AnsibleAWXの構成の不一致をチェックします。



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



これで、Ansible AWX / GitLab / Moleculeで構成される重要なテストレイヤーができました（図6）。





図： 6.テスト管理。



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



今日のサーバーと環境の設定には「秘密の知識」はありません。必要な機能はすべてプレイブックに反映されています。これ以上の創造性と漠然とした指示はありません。「通常のOracleのように配置しますが、そこでいくつかのsysctl設定を登録し、必要なUIDを持つユーザーを追加する必要があります。手術の人に聞いてください、彼らは知っています。」



構成の不一致を検出して事前に修正する機能により、安心感が得られます。 CMSがないと、これは通常異なって見えます。問題は、ある日、本番環境で「撃たれる」まで蓄積されます。次に、報告が実行され、構成がチェックおよび修正されます。そして、このサイクルが再び繰り返されます。



もちろん、本番環境でのサーバーの立ち上げを数日から数時間に加速しました。



さて、大晦日には、子供たちが喜んで包装を解き、大人がチャイムに願い事をしたとき、私たちのエンジニアはSAPシステムを新しいサーバーに移行しました。サンタクロースでさえ、最高の奇跡はよく準備されたものであると言うでしょう。



PS私たちのチームは、顧客が構成管理の問題をできるだけ簡単に解決したいという事実に直面することがよくあります。理想的には、まるで魔法のように、1つのツールで。しかし、人生では、すべてがより複雑です（はい、銀の弾丸は配信されませんでした）。顧客のチームに便利なツールを使用してプロセス全体を作成する必要があります。



著者：Sergey Artemov、DevOpsのアーキテクト-JetInfosystemsのソリューション部門