AWSでDocker / AnsibleとAnsible、Puppet、Foremanを使用した不変サーバーモデル？
私たちは興味深い議論にぶつかり、2つの陣営に陥っています。私は、私たちが見逃しているかもしれないアイデアや落とし穴に関する特定の問題に興味があります。本当に、私たちが決定を下したり、私たちが説明していないことを指摘したりするのに役立つものは何でも。私はこれが「意見なし」のルールを少し厳密に覆っていることを知っていますが、それでも受け入れられる質問であることを願っています。長さも申し訳ありませんが、かなりのニュアンスがあります。
1）一方の側（私の-私は偏見がないわけではありません）は、不変のサーバーモデルがクラウドシステムにとって非常に興味深いと感じています。そのために、インフラストラクチャのすべてのコンポーネントをDockerに移動するプロトタイプを作成しました。カスタムアプリケーションは、Jenkinsを介して、ローカルのDockerレジストリにデプロイされるDockerイメージに直接ビルドされます。次に、空のサーバーにアクセスし、Dockerをインストールしてから、必要に応じてすべてのコンテナーをインストールするようにDockerに指示できるAnsibleロールとプレイブックの大規模なセットを作成しました。数分後、アプリ全体とそれをサポートするすべてのインフラストラクチャ（ロギング、モニタリング、データベースの作成/作成など）が接続され、機能します。完成したマシンは、自己完結型のQAまたは開発環境であり、応用。これをスケールアウトする計画は、ベースの信頼できるAMI（おそらく非常にベアイメージ）から新しいAWSサーバーを構築するための新しいプレイブックを作成し、構成管理とリリースを処理するために本番アプリケーションのローリングデプロイを実行し、通常はサーバーを二度と編集しないことです-それらを新しくするだけです。私が説明したことを実際に機能させることについては心配していません-それが合理的なモデルであるとしても。
2）もう一方のキャンプは、Puppetを使用して構成管理を処理し、Ansibleを使用してビルドプロセスから生成されたtarballであるカスタムアプリケーションをデプロイし、Foremanを使用してプロセス全体のトリガーと管理を処理し、Katelloを使用してある程度のベースを実行したいと考えています。画像管理。リリースには、必要に応じてPuppetが構成を変更し、AnsibleがForemanの調整をある程度行って更新されたコンポーネントをデプロイすることが含まれます。新しいサーバーが必要な場合、サーバーはかなり迅速に構築されますが、その目的は、標準プロセスの一部としてサーバーを使い捨てにすることではありません。これは、寿命は長いものの、フェニックスサーバーモデルに近いものです。
だから私の質問は本当にこれに帰着します：私が上で説明したようなツールを備えた不変のサーバーモデルは実際に見た目と同じくらい現実的ですか？私たちのステージングプロセスでは、文字通りアプリケーションのクローン全体をライブで構築し、QAでハンマーで叩き、データベースストレージといくつかのDNS設定を切り替えてライブにすることができるという考えが大好きです。
または、不変のサーバーモデルは実際には失敗しますか？ AWSとクラウド環境の両方で豊富な経験があるため、それは実際には問題ではありません。合理的に洗練されたアプリを確実にデプロイする方法の問題です。非常に頻繁にリリースするため、これは特に興味深いものです。
Ansibleは、実際にEC2サーバーを作成することを除いて、必要なほとんどのことを実行していますが、それは難しくありません。このモデルで実際にパペット/フォアマン/カテッロが必要な理由を理解するのに苦労しています。 Dockerは、私が知ることができる実際のツールのカスタムデプロイスクリプトよりもはるかにクリーンでシンプルです。 Ansibleは、Puppetよりもはるかに簡単に使用できるように見えます。その場で構成する必要がなくなり、新しい構成で再構築するだけです。私はKISSプリンシパルのファンです。特に、マーフィーの法則が横行する自動化では、機械が少ないほどIMOが優れています。
アプローチに関する考え/コメントまたは提案は大歓迎です！
当社では、お客様のレガシーインフラストラクチャにPuppetを実装することに成功しました。また、Dockerコンテナーを使用して専用サービスを実行しています（実際には、コンテナーに収まるようにトリミングおよびツイストされた古いアプリケーションです）。
初めてコンテナを操作し始めたときは不満でしたが（ええと... 30kbのアプリは200MBの重い画像になります）、小さな災害の後で環境全体を再現しなければならなかったとき、気が変わりました。 Dockerはまさにこのために発明されたと思います。サーバー構成を気にせずに、高速で頻繁にデプロイします。コンテナーを正しく設計すれば、クラウドプロバイダー、開発者のラップトップ、コロケーションデータセンターを簡単に切り替えることができます。必要なのは、Dockerデーモンを備えたVanillaLinuxボックスだけだからです。
- シナリオ1）では、すべてを1か所にまとめています（Dockerを使用すると、コードと構成が同じリポジトリにあるため、1つです）、管理、読み取り、デプロイが簡単です。
- シナリオ2）では、3つの異なる（！）ツールの構成パーツを一方のリポジトリに格納し、アプリケーションコードをもう一方のリポジトリに格納する必要があるため、事態はさらに複雑になります。
以前のプロジェクトでもPuppetを使用していましたが、これまでの経験では、PuppetやChefではなくDockerを使用して不変のサーバーを実現できます。構成管理ツールは、開発チームよりもクラウドプロバイダーの方が便利だと思います。
これが私の2ユーロセントです。
提案する2つのオプションは、（ある種の）不変性を実現するための有効なオプションです。
もっと快適なものを選ぶべきだと思います。
しかし、あなたが書いたものからは、まだコンセンサスが得られていないようです。
おそらく3番目のオプションが必要ですか？ ;）
ただし、そのような不変性は目標ではなく、他のプロパティを保証する手段です（構成のドリフトがない、安定性が向上するなど）。
私は自分の目的を明確に述べ、それらを検証するためにいくつかの指標を置き、2つのオプションを使用していくつかのテストを行います。次に、あなたのビジネスに最も一致するものを選択するためのいくつかの数字があります。
幸運を！