興味深い議論に遭遇し、2 つの陣営に分かれています。どちらのアイデアにも、あるいは私たちが見逃しているかもしれない落とし穴にも、特に問題があれば興味があります。本当に、決定を下すのに役立つものや、考慮していない点を指摘できるものなら何でもいいです。これは「意見なし」のルールに少し近いことは承知していますが、それでも受け入れられる質問であることを願っています。長文で申し訳ありません。かなり微妙なところがあります。
1) 一方 (私の場合 - 偏見がないわけではありません) は、不変のサーバー モデルがクラウド システムにとって非常に興味深いと考えています。そのために、インフラストラクチャのすべてのコンポーネントを Docker に移行するプロトタイプを作成しました。カスタム アプリケーションは、Jenkins を介して直接 Docker イメージにビルドされ、ローカル Docker レジストリにデプロイされます。次に、空のサーバーにアクセスし、Docker をインストールして、必要に応じてすべてのコンテナーをインストールするように Docker に指示できる、Ansible ロールの大規模なセットとプレイブックを作成しました。数分後、アプリ全体とそれをサポートするすべてのインフラストラクチャ (ログ、監視、データベースの作成/入力など) が接続され、動作します。完成したマシンは、アプリケーションの正確なコピーを備えた自己完結型の QA または開発環境です。これをスケールアウトする計画は、新しいプレイブックを作成して、信頼できる基本 AMI (おそらく非常に基本的なイメージ) から新しい AWS サーバーを構築し、本番アプリケーションのローリング デプロイを実行して構成管理とリリースを処理し、通常はサーバーを二度と編集せず、新しく作成することです。私が説明したことが実際に機能するかどうかは気にしていません。ただ、それが合理的なモデルであるかどうかが気になります。
2) もう一方の陣営は、構成管理に Puppet、ビルド プロセスから生成された tarball であるカスタム アプリケーションのデプロイに Ansible、プロセス全体のトリガーと管理に Foreman、ベース イメージ管理の一部に Katello を使用する予定です。リリースでは、必要に応じて Puppet が構成を変更し、Ansible が Foreman の調整によって更新されたコンポーネントをデプロイします。新しいサーバーが必要な場合は、比較的迅速にサーバーを構築しますが、標準プロセスの一部としてサーバーを使い捨てにすることは意図していません。これは、寿命が長いという点ではフェニックス サーバー モデルに近いものです。
私の質問は、結局のところ、上で説明したツールを使用した不変のサーバー モデルは、見た目ほど現実的であるかどうかということになります。ステージング プロセスでは、文字通り、ライブ アプリケーションの完全なクローンを作成し、QA でテストしてから、データベース ストレージと DNS 設定の一部を変更するだけでライブにできるという考えが気に入っています。
それとも、不変サーバー モデルは実際には機能しないのでしょうか? 当社は AWS とクラウド環境の両方で豊富な経験があるため、この点はそれほど心配する必要はありません。むしろ、今後、適度に洗練されたアプリをいかにして確実に展開するかが問題です。当社は頻繁にリリースを行っているため、この点は特に興味深い点です。
実際に EC2 サーバーを作成する以外、必要な作業のほとんどを Ansible が行ってくれますが、これは難しくありません。このモデルで Puppet/Foreman/Katello がなぜ必要なのか、私には理解できません。Docker は、私が知る限り、他のどのツールよりもカスタム デプロイ スクリプトよりもはるかにクリーンでシンプルです。Ansible は、その場で構成する必要を心配する必要がなく、新しい構成で再度ビルドするだけで済むため、Puppet よりもはるかに簡単に使用できるようです。私は KISS 原則のファンです。特に、マーフィーの法則が蔓延する自動化ではそうです。機械が少ないほど良いと私は思います。
このアプローチに関するご意見、コメント、ご提案をいただければ幸いです。
答え1
当社では、顧客のレガシー インフラストラクチャに Puppet を実装することに成功しました。また、専用サービス (実際には、コンテナに収まるようにトリミングおよび調整された古いアプリケーション) を実行するために Docker コンテナも使用しています。
コンテナを使い始めた当初は、コンテナに満足していませんでした (ええ、30 KB のアプリが 200 MB の重いイメージになります)。しかし、小さな障害の後で環境全体を再作成しなければならなくなったときに、考えが変わりました。Docker はまさにこのために発明されたと思います。つまり、サーバー構成を気にせずに、迅速かつ頻繁に展開することです。コンテナを適切に設計すれば、クラウド プロバイダー、開発者のラップトップ、コロケーション データセンター間を簡単に切り替えることができます。必要なのは、Docker デーモンを搭載した通常の Linux ボックスだけです。
- シナリオ 1) では、すべてが 1 か所 (Docker ではコードと構成が同じリポジトリにあるため 1 か所) にまとめられ、管理、読み取り、展開が容易になります。
- シナリオ2)では、3つの異なるツールの設定部分を1つのリポジトリに保存し、アプリケーションコードを別のリポジトリに保存する必要があるため、状況が複雑になります。
以前のプロジェクトでも Puppet を使用していましたが、これまでの経験では、不変サーバーは Puppet や Chef よりも Docker で実現できます。構成管理ツールは、開発チームよりもクラウド プロバイダーにとってより便利だと思います。
答え2
ここに2ユーロセントがあります。
あなたが提案する 2 つのオプションは、(ある種の) 不変性を実現するための有効なオプションです。
より快適な方を選択すべきだと思います。
ただし、あなたが書いた内容からすると、まだコンセンサスが得られていないようです。
おそらく、3 番目のオプションが必要でしょうか ? ;)
ただし、不変性は目標ではなく、他の特性（構成のドリフトがない、安定性が向上するなど）を保証するための手段です。
私は目標を明確に述べ、それを検証するための指標をいくつか設定し、2 つのオプションを使用してテストをいくつか実行します。そうすれば、ビジネスに最も適したものを選択するための数値が得られます。
幸運を！