9

私の質問は基本的に2つの質問ですが、それらは密接に関連しているため、まとめて質問するのが理にかなっていると思いました。

ケース:
AWS Elastic Load Balancer の背後にある複数の AWS EC2 インスタンスに分散された Web アプリケーションを実行しています。

意図する目標:
a) 新しいアプリ コード (php) をデプロイする場合、すべての EC2 インスタンスに自動的に配布する必要があります。
b) 新しい EC2 インスタンスが追加されると、最新のアプリコードで自動的に「ブートストラップ」する必要があります

これまでの私の考え:
ad a)
phing (http://phing.info) がおそらくこの部分の答えです。おそらく、各 EC2 インスタンスに複数のターゲットを追加し、デプロイを実行すると、すべてのマシンにデプロイされます。おそらく残念ながら並行していません。しかし、EC2 インスタンスがロードバランサーで「一時停止」され、アップグレードされ、再び「一時停止」されて次のインスタンスに移行するようにスクリプトを作成する場合にも、これは有益な場合があります。

ad b)
どうすればそれを達成できるかわかりません。従来の「ハードウェア ベースのセットアップ」では、おそらくネットワーク ストレージ デバイスに「アプリ コード」ボリュームがあり、新しいサーバーを追加するときにそのボリュームを接続するだけでした。新しいアプリコードをデプロイするとき、このボリュームへのデプロイ操作は 1 回だけでした。そのため、新しくブートストラップされたマシン/インスタンスがアプリコードをダウンロードする場所から「中央ストレージ」が必要です。git も考えましたが、やはり git はデプロイ ツールではなく、1 つとして強制的に使用するべきではないでしょう。

そのようなタスクのセットアップを見て、そのような状況に対するヒントやアイデアを聞いていただければ幸いです.

ありがとう、

ジョシュア

4

4 に答える 4

3

これは、phingを使用して作成できます。ただし、新しいインスタンスでアプリコードを自動的に取得する必要がある理由がわかりません。余分なインスタンスを頻繁に取得しますか？そして、コードをいくつかのインスタンスにデプロイするためにa)、それでもそれらを知る必要がありますか？

このセットアップにはマスターデプロイサーバーが必要であり、プッシュ戦略を使用します。マスターサーバーには、phing、必要なphingパッケージ、およびオプションでEC2インスタンスのsshキーが必要です。

a）の提案

（これは、必要なphingタスクの一般的な概要です）

  • インスタンスリストを取得します（構成ファイルまたは提供されたパラメーターのいずれか）
  • リポジトリからマスターサーバーへのアプリコードのエクスポート（例：SubVersion）
  • タールアプリコード
  • scpすべてのEC2インスタンスへのtarball（デプロイフォルダーへ）
  • rshEC2インスタンスでtarballを解凍します
  • EC2インスタンスのシンボリックリンクをrsh更新すると、ウェブサーバーフォルダーが新しいデプロイフォルダーを指すようになります
  • Webサーバーのキャッシュをすべてクリアする

上記は、新しいリリースを作成した後に呼び出すことができます。

b）の提案 これは、phingスクリプトを数時間ごとに実行し、EC2インスタンスにログインして、アプリコードを確認することで実現できます。見つからない場合は、最新の最終リリースをデプロイします。もちろん、これには、ウェブサーバーや設定ファイルなどに関してEC2インスタンスが正しくセットアップされている必要があります（ただし、これはphingを介したリモートシェルでも実現できます）。

以前に同様のセットアップを使用しましたが、EC2などのサービスでは試していません。

于 2011-02-16T12:58:03.400 に答える
0

ping はこれに適したツールだと思います。カピストラーノも役立つかもしれません。

非常によく似た環境にアプリケーションをデプロイします。これまでのところ、単純な bash スクリプトを使用してきましたが、主にシェル スクリプトの開発に伴う困難のため、おそらく phing ベースのソリューションに移行することになるでしょう (あまり柔軟ではない新しい構文を知っておく必要があります。クロスプラットフォームについて言及) と、phing に存在する並列処理の可用性。

于 2012-06-23T22:13:44.850 に答える
0

Phing は、デプロイメント タスクを管理するための優れたツールであり、(a) のほとんどをカバーします。

インフラストラクチャ管理にはOpsCode Chefを使用します。アプリケーション コードのデプロイ用に SVN と Git リポジトリの両方をサポートする deploy_revision ターゲットがあり、knife (メインの Chef コマンドライン ツール) には、1 つのコマンドで新しい EC2 をスピンアップできる EC2 プラグインがあります。 Chef で定義したロールと環境を使用してインスタンス化し、アプリケーション コードをデプロイします。

ELB の背後にある複数の EC2 インスタンスでこれを管理するために、Python botoライブラリを使用して、ELB に接続し、その ELB にアタッチされているすべてのインスタンスのリストを取得し、インスタンスを 1 つずつ削除する非常に単純なスクリプトを作成しました。 ELB は、そのインスタンスで Chef の更新を実行し (新しいアプリケーション コードとマシン構成の変更をデプロイします)、インスタンスを ELB に再アタッチし、次のインスタンスに進みます。

于 2012-10-12T06:29:27.593 に答える
0

a) Capistranoを見てください。Ruby (および RoR) を使用していないため、railsless-deployプラグインを使用してください。Capistrano は複数のサーバーにデプロイできます。

b）これについては経験がありませんが、これをほとんど行うことができる Capistrano 用のプラグイン/gem がなくても驚かないでしょう。

于 2011-02-15T15:07:47.357 に答える