構成管理ツールは、不変のインフラストラクチャでどのような役割を果たしますか？

不変のサーバー/コンテナを使用している場合、Chef、Puppet、Ansible、Saltなどのツールが必要ですか？これらの構成管理ツールは、構成を確立してから維持するように設計されています。

不変サーバーを展開する場合、構成管理ツールは初期プロビジョニングにのみ使用する必要がありますか？

それにはいくつかの答えがあります：

1. これらの不変のイメージを構築するために何かが必要です。既知の開始状態から開始する場合、古い学校スタイルの手順スクリプトを使用して何かを構築することは確かに簡単ですが、特に異なる画像の大きなマトリックスが必要になった場合、これは時間の経過とともに非常に扱いにくくなります（例：Dockerfiles）さまざまなバージョンのソフトウェア、さまざまな環境など。Packerやその他のイメージビルドツールは、Chef、Ansible、Puppet、Saltなどとうまく統合されます。

2. 不変性はスペクトルであり、バイナリではありません。「非常に不変の」デプロイでも、ランタイム管理を必要とするいくつかの構成ファイルを持つことは珍しくありません。これは、CAPSツールを使用できる場所でもありますが、Consul Templatesやetcdなどの軽量オプションは、全体的なインフラストラクチャに応じてより意味があります。不変のアプリケーションサーバーを実行しているが、データベースサーバーが従来よりChefを使用して管理されている場合、マイナーな管理タスクのために不変の側でもChefを使用することは理にかなっています。

3. ゼロデイ管理。不変性は素晴らしいですが、次のOpenSSLの0dayが廃止されたらどうしますか？すぐに修正プログラムイメージを作成して展開できる位置にビルドパイプラインがある場合、それは素晴らしいことです。しかし、多くの人々はおそらくそのようなクイックターン能力を持たないでしょう。

4. 不変にできないもの。答えはありませんが、インフラ全体が100％不変であることはめったにありません。データベースサーバーや開発者ワークステーション（はい、それらはインフラの一部です）のようなものは、不変にするのが難しいと不可能の間のどこかにあります。

絶対に不変の環境は悪い考えだと思う。

Ansible、Chef、PuppetなどのCMツールは、あなたを含む多くの場合に役立ちます。

GCPでVMインスタンスの初期プロビジョニングにansibleを使用しています。