構成管理の概要

新しいサーバーを展開する必要があるときはいつでも、構成管理ツールを使用して、すべてではないにしてもほとんどのプロビジョニングプロセスを自動化できます。 自動化により、面倒なタスクを誰よりも迅速かつ正確に実行できるため、プロビジョニングがはるかに迅速かつ効率的になります。 適切で詳細なドキュメントがあっても、たとえば、Webサーバーを手動で展開すると、構成管理/自動化で数分かかるのに比べて数時間かかる場合があります。

迅速なプロビジョニングには、重要なイベントからの迅速な回復という別の利点があります。 不明な状況のためにサーバーがオフラインになった場合、システムを適切に監査し、実際に何が起こったかを調べるのに数時間かかることがあります。 このようなシナリオでは、通常、交換サーバーを展開することが、影響を受けるサーバーで詳細な検査を行いながらサービスをオンラインに戻す最も安全な方法です。 構成管理と自動化により、これを迅速かつ信頼性の高い方法で実行できます。

一見すると、手動のシステム管理は、サーバーを簡単に展開して修正する簡単な方法のように思えますが、多くの場合、代償が伴います。 プロセスが自動化されていない場合、時間が経つにつれて、サーバーにインストールされているものと行われた変更を正確に知ることは非常に難しくなる可能性があります。 手動の修正プログラム、構成の調整、およびソフトウェアの更新により、サーバーが一意の_snowflakes_になり、管理が難しくなり、複製がさらに難しくなります。 構成管理ツールを使用すると、新しいサーバーを立ち上げたり、既存のサーバーを更新したりするために必要な手順がすべてプロビジョニングスクリプトに文書化されます。

サーバーのセットアップを一連のプロビジョニングスクリプトに変換すると、ソフトウェアソースコードに通常使用する多くのツールとワークフローをサーバー環境に適用できるようになります。

Gitなどのバージョン管理ツールを使用して、プロビジョニングに加えられた変更を追跡し、スクリプトのレガシーバージョンの分岐を個別に維持できます。 バージョン管理を使用して、プロビジョニングスクリプトの_code review_ポリシーを実装することもできます。変更ポリシーは、プルリクエストとして送信し、プロジェクトリーダーによって承認される前に承認される必要があります。 これにより、インフラストラクチャのセットアップに一貫性が追加されます。

構成管理により、まったく同じソフトウェアと構成の環境を簡単に複製できます。 これにより、生産、開発、およびテストサーバーを使用して、効果的にマルチステージエコシステムを構築できます。 同じプロビジョニングスクリプトで構築されたローカル仮想マシンを開発用に使用することもできます。 この方法により、アプリケーションが運用環境に展開されたり、異なるマシンセットアップ（異なるオペレーティングシステム、ソフトウェアバージョン、および/または構成）の同僚間で共有されるときに頻繁に発生する環境の不一致によって生じる問題が最小限に抑えられます。

各CMツールは、プロビジョニングスクリプトの記述に使用できる特定の構文と機能のセットを提供します。 ほとんどのツールには、言語を従来のプログラミング言語に似たものにする機能がありますが、単純化されています。 変数、ループ、および条件は、より用途の広いプロビジョニングスクリプトの作成を容易にするために提供される一般的な機能です。

構成管理ツールは、以前に実行されたタスクの繰り返しを避けるために、リソースの状態を追跡します。 パッケージが既にインストールされている場合、ツールはそれを再度インストールしようとしません。 目的は、プロビジョニングを複数回実行しても、各プロビジョニングの実行後にシステムが目的の状態に達する（または維持する）ことです。 これが、これらのツールが_idempotent behavior_を持っていると特徴付けている理由です。 ただし、すべての場合にこの動作が強制されるわけではありません。

通常、構成管理ツールは、プロビジョニングされるシステムに関する詳細情報を提供します。 このデータは、_facts_と呼ばれるグローバル変数を介して利用できます。 ネットワークインターフェイス、IPアドレス、オペレーティングシステム、配布などが含まれます。 各ツールは、_facts_の異なるセットを提供します。 これらを使用して、プロビジョニングスクリプトとテンプレートを複数のシステムにより適応させることができます。

ほとんどのCMツールは、構成ファイルとサービスのセットアップを容易にするために使用できる組み込みのテンプレートシステムを提供します。 テンプレートは通常、汎用性を最大化するために使用できる変数、ループ、および条件をサポートします。 たとえば、テンプレートを使用して、Apache内に新しい仮想ホストを簡単にセットアップし、複数のサーバーのインストールに同じテンプレートを再利用できます。 テンプレートには、ハードコードされた静的な値だけではなく、 `+ NameServer `や ` DocumentRoot +`など、ホストごとに変更できる値のプレースホルダーを含める必要があります。

プロビジョニングスクリプトは特定のサーバーのニーズと要求に非常に特化できますが、同様のサーバー設定または複数のサーバー間で共有できる設定の一部がある場合が多くあります。 ほとんどのプロビジョニングツールは、プロビジョニング設定の小さなチャンクをモジュールまたはプラグインとして簡単に再利用および共有できる方法を提供します。

サードパーティのモジュールとプラグインは、インターネット上で簡単に見つけることができます。特に、PHP Webサーバーのインストールなどの一般的なサーバーのセットアップに適しています。 CMツールの周りには強力なコミュニティが構築される傾向があり、ユーザーはカスタム拡張機能を共有することをお勧めします。 他のユーザーが提供する拡張機能を使用すると、時間を大幅に節約できます。また、選択したツールを使用して他のユーザーが一般的な問題を解決した方法を学習する優れた方法としても役立ちます。

ほとんどの構成管理ツールには、コントローラーマシンとそれによって管理されるノードで構成される最小限の階層が必要です。 たとえば、Puppetでは、各ノードに_agent_アプリケーションをインストールし、コントローラーマシンに_master_アプリケーションをインストールする必要があります。 一方、Ansibleは、ノードに追加のソフトウェアをインストールする必要はありませんが、プロビジョニングタスクを実行するためにSSHに依存する分散型の構造を持っています。 小規模なプロジェクトの場合、単純化されたインフラストラクチャがより適しているように思えるかもしれませんが、スケーラビリティやセキュリティなどの側面を考慮することが重要です。

一部のツールには、より多くのコンポーネントと可動部分があり、インフラストラクチャの複雑さが増し、学習曲線に影響を与え、実装の全体コストが増加する可能性があります。

この記事で前述したように、CMツールは、ドメイン固有言語（DSL）を使用するカスタム構文と、自動化のフレームワークを構成する一連の機能を提供します。 従来のプログラミング言語と同様に、一部のツールでは、習得するのに高度な学習曲線が必要になります。 インフラストラクチャの要件も、ツールの複雑さと、投資の見返りをどれだけ早く得ることができるかに影響を与える可能性があります。

ほとんどのCMツールは、無料またはオープンソースバージョンを提供し、高度な機能とサービスの有料サブスクリプションを提供します。 一部のツールには他のツールよりも多くの制限があるため、特定のニーズとインフラストラクチャの成長方法に応じて、これらのサービスに料金を支払う必要が生じる場合があります。 また、トレーニングは金銭的な面だけでなく、選択したツールでチームをスピードアップさせるために必要な時間についても、潜在的な追加コストとして考慮する必要があります。

前述のように、ほとんどのツールは、サポート、拡張機能、高度なツールを含む有料サービスを提供します。 特定のニーズ、インフラストラクチャのサイズ、およびこれらのサービスを使用する必要があるかどうかを分析することが重要です。 たとえば、管理パネルはこれらのツールが提供する一般的なサービスであり、すべてのサーバーを中央から管理および監視するプロセスを大幅に促進できます。 そのようなサービスがまだ必要ない場合でも、将来必要になる可能性のあるオプションを検討してください。

ユーザーは通常、知識と拡張機能（モジュール、プラグイン、プロビジョニングスクリプト）を他のユーザーと共有できるため、強力で歓迎的なコミュニティは、サポートとドキュメントの作成に非常に役立ちます。 これは、学習曲線を高速化し、有料のサポートやトレーニングで余分なコストを回避するのに役立ちます。