私たちは興味深い議論にぶつかり、2つの陣営に陥っています。見落としている可能性のあるアイデアや落とし穴に関する特定の問題に興味があります。本当に、私たちが決定を下したり、私たちが説明していないことを指摘したりするのを助けることができるものは何でも。私はこれが「意見なし」のルールを少し厳密に回避していることを知っていますが、それでもまだ受け入れ可能な質問であることを願っています。長さについても申し訳ありませんが、かなりのニュアンスがあります。
1）一方（私-偏見がないわけではない）は、不変サーバーモデルがクラウドシステムにとって非常に興味深いものであると考えています。そのために、インフラストラクチャのすべてのコンポーネントをDockerに移動するプロトタイプを作成しました。私たちのカスタムアプリケーションは、ローカルDockerレジストリにデプロイするDockerイメージに、Jenkinsを介して直接構築されます。次に、Ansibleロールの大規模なセットと、空のサーバーに到達できるプレイブックを作成し、Dockerをインストールして、必要に応じてすべてのコンテナーをインストールするようにDockerに指示しました。数分後、アプリ全体とそれをサポートするすべてのインフラストラクチャが接続され、機能します-ロギング、モニタリング、データベースの作成/入力など。完成したマシンは、完全にコピーされた自己完結型のQAまたは開発環境です応用。これをスケールアウトするための計画は、新しいPlaybookを作成して、ベースの信頼できるAMI（おそらく非常に最小限のイメージ）から新しいAWSサーバーを構築し、本番アプリケーションのローリングデプロイを実行して構成管理とリリースを処理し、通常はサーバーを再び編集しないことです。それらを新しくするだけです。私が説明したものを実際に機能させることについては心配していません-それが妥当なモデルである場合でも。
2）他のキャンプは、Puppetを使用して構成管理を処理したい、Ansibleはビルドプロセスから生成されたtarballであるカスタムアプリケーションをデプロイし、Foremanはプロセス全体のトリガーと管理を処理し、Kateloはある程度のベースを実行したい画像管理。リリースには、必要に応じてPuppetが構成を変更し、Ansibleが更新されたコンポーネントをある程度のForemanの調整でデプロイすることが含まれます。新しいサーバーが必要になった場合、サーバーはかなり迅速に構築されますが、その意図は、標準プロセスの一部としてサーバーを使い捨てにすることではありません。これはフェニックスサーバーモデルに近いですが、長寿命です。
だから私の質問は本当にこれに帰着します：私が上でそれらを説明したように、ツールを備えた不変のサーバーモデルは実際にそれが現れるのと同じくらい現実的ですか？私のステージングプロセスは、文字どおりアプリケーションのクローン全体をライブで構築することができ、QAでそれをハンマーに任せて、データベースストレージとDNS設定を反転させてライブにすることができるというアイデアが大好きです。
または、不変サーバーモデルは実際には失敗しますか？AWSとクラウド環境の両方でかなりの経験を持っているので、それは本当に問題ではありません-合理的に洗練されたアプリを今後確実にデプロイする方法の問題です。非常に頻繁にリリースされるため、これは特に重要です。
実際にEC2サーバーを作成することを除いて、Ansibleは必要なほとんどのことを行っていますが、それは難しくありません。このモデルでパペット/フォアマン/カテロが実際に必要な理由を理解できません。Dockerは、私が知ることのできる実際のツールでは、カスタムデプロイスクリプトよりもはるかにクリーンでシンプルです。Ansibleは、その場で構成する必要がないか心配する必要がなくなり、新しい構成で再構築するだけの場合、Puppetよりもはるかに簡単に使用できます。私はKISSプリンシパルのファンです-特にマーフィーの法則が蔓延している自動化で。機械が少ないほど、IMOは向上します。
アプローチについての考え/コメントまたは提案は大歓迎です！