「単一サーバー複数管理者」の構成管理

小さな協会のインフラストラクチャを実行するサーバーをセットアップしました。これまでのところ、Ansibleを使用して構成を管理しようとしましたが、それは大きな成功ではありませんでした。おそらく私たちはそれを間違っています。

原則として、このサーバーはほとんどの場合このサーバーはそのままにして、ブルームーンで一度追加または変更を行うという考え方です。システムを管理していない人は頻繁に概要を失うことになるため（詳細は覚えておいてください）、サーバー上で構成され実行されているものはすべて文書化され、明確であることが重要です。さらに、時間の経過とともに、このサーバーを管理する人々のグループの構成は変化します（人々が「委員会」を離れて参加するにつれて）。

クリーンインストールから始めて、何かを設定したいときはいつでも（nginx、phpfpm、postfix、firewall、sftp、muninなどの）ansibleにロールを追加しました。おそらく、私たちの経験の不足が原因で、設定が試行錯誤のプロセスであるため、一連のansibleタスクを必要な方法で正確に入力することはできません。つまり、実際には、通常、まずサーバーで実行する必要のあるサービスを構成し、次に、不可能なタスクに変換します。これがどこに向かっているかがわかります。人々はそれからタスクをテストすることを忘れるか、または物事を壊すリスクでそうすることを恐れるか、またはさらに悪いことです：私たちは物事をansibleに追加することを忘れるか、または無視します。

今日、ansible構成が実際にサーバーで構成されているものを反映しているという確信はほとんどありません。

現在、3つの主な問題が見られます。

• 物事を壊す危険を冒さずにansibleタスクをテストする（読む：良い方法がない）のは難しい。
• それは最初に望ましい構成を理解するために余分な作業を追加し、次にこれをansibleタスクに変換する方法を理解します。
• （理想的には）親しみやすさと日常を築くほど頻繁には使用しません。

ここでの重要な考慮事項は、私たちが最終的に何をしても、多くの練習をしなくても初心者が簡単にロープを学ぶことができるということです。

master「物事を構成し、あなたがしたことを書き留める」が提供できないいくつかの保証とチェック（Ansibleファイルをいくつかにマージするのと同等）を提供する実行可能な代替策はありますか？

編集：/etcgitへのコミットを検討しました。その方法でシークレット（秘密鍵など）を保護するための合理的な方法はありますが、それでもサーバーの外で構成リポジトリを使用できるようにしていますか？

変更の検証に使用できるテスト/ステージングVMを起動するだけです。最初に手動で変更を行う現在の方法は、どうしようもなく壊れて失敗する運命にあります。あなたとあなたのチームはCMを適切に使用することを約束する必要があり、その一部はテストシステムを利用できるようにすることです。ローカルのvagrant VMだけで十分です。

これは、新しい変更のテストに役立つだけでなく、新しい従業員（またはしばらくシステムを使用していない高齢の従業員）がテスト環境として慣れるためのテストベッドとしても機能します。

/ etc /をgitに保持することについて：いいえ、これを行わないでください。そのディレクトリは、ansibleが変更しているもののほんの一部にすぎません。そこにgitを配置することで、人々がローカルで変更するように促すだけです。

ansibleプレイブックをgitに保存します。自分だけがライブサーバーに変更を適用できるように、アクセス許可を制限することを検討してください。他の人はプルリクエストをその変更とともに送信できます。必要に応じて、変更を確認してマスターにマージできます。

おそらく私たちの経験の不足が原因で、当然のことながら、一連のansibleタスクを一度に実行するために必要な方法で正確に入力することはできません。また、構成が試行錯誤のプロセスであるためです。つまり、実際には、通常、最初にサーバーで実行する必要のあるサービスを構成し、次に、適切なタスクに変換します。

その他の問題（テスト環境がないなど）がありますが、これを行わないことで大きな改善が見込めます。

一つAnsibleのコア設計目標は、することであるべき等、これ（あなたがプレーを変更していない限り）あなたの脚本を複数回実行すると何も変更してはならないことを意味します。したがって、新しいソフトウェアを構成するときの手順は次のとおりです。

1. Ansibleタスクに変更を加えます。
2. ハンドブックを実行します。
3. システムを調べ、正しくない場合は、手順1に戻ります。
4. 変更をコミットします。

Ansibleで初めて正しいものを書くと思わない場合は、他のコードと同じように、とにかくそれを書いて、正しくなるまで繰り返します。これにより、開発プロセスのある時点で行ったすべての変更がすでにAnsibleにあったため、行った変更のAnsiblizeを忘れる可能性が大幅に減少します。

Ansibleは、以前のレベルの生産性を超える前に立ち上がる時間がありますが、それができれば、システムの状態は簡単に確認できます。あなたの実践はあなたの最終目標と同期していないようです。堅固なエンジニアリング手法を維持しながら、CMツールセットを使用して生産性を高めることができますが、正しく構成するには時間がかかります。基本的に、安定性と企業のスケーラビリティのために、効率と実装の容易さのトレードオフになります。経験豊富なプロのプログラマーが醜いハックを書かないのとまったく同じように、結果は常にメリットを上回ります。

初心者にとって、明確な所有権がないコックが多すぎて、コモンズの悲劇を予期しているかもしれません。ビジネスの優先度は、システムエンジニアリングの懸念を常に上回ります。ただし、それが広く否定されず、残っているものが責任あるエンジニアに直接反映されている場合を除きます。

CMツールセットは、管理者が設計することはできません。これが私が実現したところです。彼らは既存の仕事を再利用することができます。エンジニアができることは、管理者ができることではありません。Ansibleの多くの概念はコードベースとほとんど同じですが、管理Pythonを教えて、有能な結果を​​期待できますか？いいえ、確かにそうではありません。ハックジョブを期待しているので、ハックジョブが耐えられるようにタスクを十分に構造化する必要があります。

したがって、成功のために物事をセットアップする必要があり、不必要な管理のポイントのためのソリューションを設計します。低レベルのシステムの複雑さを、管理者が実際に成功させることができるものと交換してください。CMツールセットは、アーキテクチャまたは設計の不一致からユーザーを救うことはありません。

したがって、実装は現在の状態に最も影響を与えない経路に依存するため、順序は変更される可能性があります。

1. ビジネス関連のワークフロー関連のシステム作業を専用のランデッキに移動します。

2. ボックス上のタスクを分割します。現在1つに2つ以上のボックスがある場合があります。

3. より構造化された方法でCMを再実装し、機能や役割ではなくオブジェクトを表すプレイブックなど、より適切な実践方法に従ってください。各システムは1回のプレイで説明する必要があります。