CloudInitを使用するだけでなく、Amazon CloudFormationでPuppet / Chefを使用するのはなぜですか?


84

「プリベーク」されていないAMIEC2インスタンスを使用することを計画しています。つまり、スピンアップすると、AWSLinuxのベアインストールになります。ブートストラッププロセスは、Python、Tomcatなどの必要なさまざまなインストールをプルします。最小で3つのインスタンス、最大で8つのインスタンスがあります。

これらの要件を考えると、Amazon CloudFormation(CloudInit)を使用するよりもPuppet / Chefを使用する方が便利でしょうか?

私が見ることができるのは、Puppetを使用した場合、スクリプトと比較して何が起こっているかを監査するのが簡単な宣言型プログラミングがあることです。また、CloudInitには16kのスクリプトサイズ制限があり、これに遭遇する場合と遭遇しない場合があります。

私の質問に答えるためにここで提供できる特定の理由で、CloudInitからPuppetまたはChefに移動した人はいますか?


2
一部の人々(私のような)は、CloudFormationで単純なユーザーデータスクリプト(cloud-initでサポートされている)を使用しています。より長いスクリプトをS3からダウンロードして、最初のユーザーデータスクリプトで実行できます。
エリックハモンド

cloud-initは不可知論的であり、複数のクラウドプロバイダーがそれを使用します。AWS、Google Cloud Platform、およびMicrosoftAzureで実行できます。(cloud-init.io)一方、AWS :: CloudFormation :: Initは不可知論者ではありません。これはAmazon固有です。
ジョーダン・スチュワート

回答:


83

CloudInitに勝る利点はありますか?はい、絶対に、それらの多く!

確かに、CloudInitスクリプトを実行してサーバーをプロビジョニングすると、上から下への実行を記述できます。しかし、構成ファイルの変更、ユーザーの追加、パッケージの更新、または新しいパッケージのインストールが必要な場合はどうなりますか?サーバーにログインしたり、そのためのスクリプトを記述したりすることになり、必然的にサーバーの状態が不調和になります。

CloudInitは構成管理ではありません。構成管理ソフトウェアの使用を開始する場合は、クラウドinitを1つのタスクに使用します。それは、Puppet / Chef /その他のエージェントをブートストラップすることです。

Puppetは、パッケージのインストールの自動化、sshキーのセットアップ、Tomcatヒープの調整を支援するだけではありません。それは物事の状態を保証します。開発者が午前3時にJavaアプリのトラブルシューティングを行い、Tomcat構成を変更すると、Puppetはそれを元に戻します。すべてまたはノードのグループのPythonのバージョンをすばやく変更できます。誰かが別のバージョンをインストールすると、Puppetはそれを元に戻します。

アプリケーションスタックが変更され、RabbitMQ、Jetty、または新しいRDBMSなどの使用を開始すると、変更を数十または数千のサーバーに簡単にテストしてデプロイできます。

バックエンドレポート、監査、セキュリティコンプライアンスなど、構成管理ソフトウェアを使用する理由は他にもたくさんあります。


14
場合によります。長時間実行されるサービス(通常はAD、DB)の場合、構成管理が必要になる場合があります。しかし、他の交換可能な使い捨てサーバーの場合、実際にはそうではありません。ASG、hadoopまたはelasticsearchのクラスターノードで管理されるWebサーバー。構成を変更する場合は、サーバーを破棄して新しいサーバーを起動するだけです。
スリーパースミス

64

構成管理の全体的なポイントは、マシンを予測可能かつ一貫してスピンアップすることです。CloudFormationとcloudinitは、純粋にAWSに限定されている場合に最適です(CloudFormationテンプレートのデバッグは悲惨な経験ですが)が、データセンターリソースとAWSの両方を使用するアプリケーション、ローカルテスト環境、または開発マシンはどうでしょうか?

純粋にAWSに存在する場合は、cloudinitだけで解決できると思いますが、どのような規模のアプリケーションでも現実的であるとは確信していません(たとえば、Netflixは、作成したOSSテクノロジーを使用してAMIをプリベークしますそして世界にリリースされました;詳細についてはこのビデオを検討してください)。高可用性アプリケーションはトランスリージョンであり、多くの場合VPCに基づいており、VPNを介してデータセンターにバックアップする傾向があります。これは、デモ、ステージング、テスト、または開発環境にも影響しません。プロビジョニングマシンを担当している人として、私が最後にやりたいことは、作業を繰り返すか、複数のプロビジョニング方法のデバッグで行き詰まるということです。

したがって、ChefまたはPuppet。AWSでも、データセンターと同じように機能します。また、Vagrantを実行している開発マシンでも、時々必要なデモ環境と同じように機能します。cloudinitとChefまたはPuppetの両方を維持するよりも、cloudinitからChefまたはPuppetを起動したいです。


1
@ U0001:ビデオリンクを修正
Christopher

5

サーバーを破棄する場合、自動スケーリンググループの背後で実行すると、cloudinitでおそらく十分だと思います。linuxシェルスクリプトまたはwindowspowershellスクリプトでうまくいくはずです。

管理を計画しているサーバーが長時間実行されている場合は、受け入れられた回答に記載されているように、シェフ、パペット、またはDockerが有利になる可能性があります。それらを使用した後に利点が見られない場合は、おそらくツールは必要ありません。


同意します。PuppetとChefは複雑であり、新しいサーバーを削除して起動するだけでサーバーを置き換えることができる場合は、実際にはそれらを使用しないことをお勧めします。puppet / chefが優れている特定のシナリオがありますが、各シナリオでそれを使用することの余分な複雑さを強調する必要があります。
bobmarksie 2015年

0

私の経験では、AWSが提供するすぐに使えるGUIツールで簡単に実行できる簡単なことがありますが、より複雑なことに入ると、ただでできることには制限があることに気付き始めます。彼らのツール。

その時点で、停止するか、これらのより複雑な目標を達成するだけでなく、より単純なことを行うのに役立つ他のツール(ChefやPuppetなど)を見つけることができます。

あなたの選択。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.