事実上の高可用性サービス用に複雑なサーバー設定を実行しています。これまでのところ、すべてをセットアップするのに約 2 日かかるため、プロビジョニングを自動化したいと考えています。
ただし、（実行中の）サーバーに対してかなりの数の手動変更を行っています。典型的な例は、さまざまなハッキングの試み、パケットフラッドなどに対処するためにファイアウォール構成を変更することです。アクティブなノードで迅速に作業できることは重要です。また、サーバーは多くのアクティブな TCP 接続を維持しており、単純な構成変更のためにそれらを失うことは論外です。
Chef または Puppet がこれに対処するように設計されているかどうかはわかりません。システム構成を変更したら、それをどこかに保存して、次のインスタンスのプロビジョニング中に使用したいと考えています。これらのツールのいずれかを使い続けるか、別のツールを選択する必要がありますか?
手作業による変更とプロビジョニングは手間がかかりません。彼らは一緒にお茶を飲むことさえしません。
仕事では、すべてのアーキテクチャを管理するためにpuppetを使用します。パフォーマンスのボトルネックや攻撃などのために、急いで手作業で変更を加える必要があります。
私たちが行うことは、最初に、パペットが特定の調整なしで配信できるように、アーキテクチャのすべての部分をセットアップできることを確認することです。
次に、手作業で変更を加える必要がある場合、パペットが管理するファイルを急いでいじらない限り、リスクはありません。パペットが管理するファイルの場合、変更する必要があるのは、パペットエージェントを停止して何でもするだけです。必要です。
急いで終了した後、次のように進めます。
これらの変更は、同じ症状のすべてのサーバーに適用する必要がありますか？
その場合、実行ごとにエージェントで実行されるコードである「facts」と呼ばれるpuppetを開発し、すべてのpuppetモジュールで使用可能な変数に結果を保存できます。たとえば、ファイアウォールのためにipconntrackmax値を変更した場合すべての接続を処理できなかったため、現在のconntrackカウント値を使用して変数を実行するたびに（10行のコードで）簡単にpuppetを実行できるため、現在の使用状況に関連する最大値を設定するようにpuppetに指示します。そうすれば、他のすべてのサーバーがこの調整の恩恵を受け、おそらくconntrackの問題に対処する必要がなくなるでしょう（デフォルトである短い頻度でpuppetを実行し続ける限り）
これらの変更は、特定の緊急事態に常に手作業で適用する必要がありますか？
構成がpuppetによって管理されている場合は、構成に他のファイルを含める方法を見つけて、puppetにそれを無視するように指示します。これが最も簡単な方法ですが、常に可能であるとは限りません（たとえば、/ etc / network / interfacesはincludesをサポートしていません）。それが不可能な場合は、緊急時にパペットエージェントを停止して、次のパペット実行時に削除されるリスクなしにパペットファイルを変更できるようにする必要があります。
これはこのホストに対してのみ変更され、他のホストはこれを必要としませんか？
とにかく人形に追加してください！$ fqdn == my.very.specific.hostの場合は甘いものを配置し、必要なものは何でも中に入れます。単一のケースであっても、サーバーに行ったすべての変更をサーバーに移行することは常に有益です（そして時間がかかります）。何らかの理由でサーバーがクラッシュして回復不可能な状態（ハードウェアなど）になった場合にサーバーセットアップを完全に復元できるようになります。問題）
要約すれば：
私にとって、手作りの変更に対処する秘訣は、変更をどのように行うかを推論することに多大な労力を費やし、緊急事態が終わった後、そのロジックを人形に移します。特定のソフトウェアスロットですべてが使用されたが、サーバー上で空きメモリがまだ利用可能であるために何かがおかしいと感じた場合は、トラフィックのピークに対処するために、より多くのスロットを実行できるようにするのが合理的でした。その後、そのロジックをpuppetに移動するのに時間を費やします。 。もちろん、非常に慎重に、そしてそれをテストしたいアーキテクチャ上のさまざまなシナリオの量と同じくらい時間がかかりますが、最終的には非常にやりがいがあります。
Valorの優れた回答を完成させたいと思います。
puppet は、構成を強制するためのツールです。したがって、次のように考える必要があります。
質問の 1 つに答えると、puppet はマシンやサービスの再起動を必要としません。しかし、puppet で設定した構成ファイルの変更により、対応するサービス/デーモン/アプリの再起動が必要な場合、それを回避する方法はありません。構成が変更された場合にサービスを再起動する必要があることを伝えるパペットのメソッドがあります。もちろん、puppet は、何も変更されていないことを確認した場合、サービスを再起動しません。
バロールは、クライアント/サーバーの方法でパペットを使用することを想定しています。たとえば、パペットクライアントは、設定のためにパペットサーバーを数時間ごとにポーリングします。ただし、たとえば git を使用してパペット ファイルをマシンからマシンに移動し、パペットを手動で起動することもできます。この方法は次のとおりです。
多くのマシンを管理している場合、これは puppet を使用するための最良の方法ではないことは明らかですが、良いスタートまたは良い移行になる可能性があります。
また、パペットは興味深いレベルで習得するのが非常に困難です。AWS サーバーをゼロから自動的にインストールできるようになるまでに 2 週間かかりました。後悔はしていませんが、上司に時間を割くよう説得しなければならない場合は、その事実を知りたいと思うかもしれません.