AmazonEC2を使用したローリングデプロイメントの管理
最近、RightScale、Scalr、さまざまなサーバーを管理するためのカスタムスクリプトなど、それぞれが複数の役割（アプリ、データベース、ロードバランサー、ジョブキューなど）をホストするさまざまなクラウド管理ツールを試しています。
ほとんどのソリューションに欠けていると思うことの1つは、ローリングデプロイメントを実行する方法です。つまり、同じ役割を持つ複数のサーバーにわたってデプロイメントを順番に実行します。たとえば、すべてのWebサーバーを同時に構築したくないのは、ほぼ間違いなく、顧客にダウンタイムまたは500秒をもたらすからです。一度に1つまたは2つのサーバーを構築し、他のサーバーは引き続き要求を処理できるようにしたいです。
もう1つの方法は、起動時に自動的に更新される新しいサーバーを起動することですが、これは費用効果が低く、ビルドが完了するまでに時間がかかる可能性があります（新しいサーバーを起動するよりも既存のサーバーでビルドする方が高速です）。サーバーと古いものを殺します）。
有名な「Pushtobuild」ボタンを持っている大企業（Twilio、Etsyなどの企業）を聞いたことはありますが、すべてカスタム実装されているようです。私は単純なssh-loop、clusterssh、またはmcollectiveについて話しているのではありません-RightScriptやScalrスクリプトのようなものを指定してサーバーのセットで実行できる素敵な単純なインターフェイスを備えたものが望ましい特定の役割、そしてそれはそれらを順番に構築します。
これを行う簡単な方法を知っている人はいますか、それともこれは新しいオープンソースプロジェクトの候補ですか？
PuppetとMCollectiveを一緒に使用します。 Puppetはビルド作業のほとんどを実行できます。 MCollectiveを使用すると、ノードを選択してスケジュールできます。
http://www.devco.net/archives/2010/03/17/scheduling_puppet_with_mcollective.php
webistrano をデプロイしましたが、開発者にそれを使用させることはできませんでした。彼らは常に、デプロイを台無しにする何らかの方法を見つけました。
このタイプの更新を支援するサービスを私は知りません。問題は、これを念頭に置いてアプリケーションを設計する必要があることです。多くの場合、サーバーxをデータベースサーバーとして使用するか、サーバーyをキャッシュサーバーとして使用するように構成されているサーバーがあります。これは、レガシーソフトウェアを調べて、更新プロセスなどを自動化する方法を考え始めたときに目にする最大の問題です。
私たちはあなたと同じ問題を抱えていました。私たちの最新の製品はすべて、最初はこの種の更新用に設計されていたため、解決策はそれほど難しくありませんでした。開発では、密結合サービスを回避しようとしました。これにより、ステージング領域でまったく新しいサーバーグループを起動できます。ステージング領域のテストが完了したら、DNSサーバーのCNAMEを変更して、ステージング領域を本番環境にプロモートします。このプロセスは、ダウンタイムが発生せず、サーバーを間違った構成などで更新するリスクが低くなります。これは、メインの通信プロトコルとしてhttpを使用し、ローカルDNSサーバーを使用して実現しました。
ローリングアップデートでうまく機能する特定のアーキテクチャに合うようにアプリケーション全体を再設計するのはおそらく簡単な作業ではないことを理解していますが、それが最も簡単な解決策であることがわかりました。有名な「プッシュして構築」ボタンは、小さなマグロがそのアクションの一部を取得できる場合でも、大きな魚だけのものである必要はありません。アプリケーションの複雑さや単純さに応じて、独自の[プッシュしてビルド]ボタンを作成するのがどれほど難しいか簡単かが決まります。