8

Elastic Beanstalk で実行されている Wordpress でサイトを作成するとします。次に、実行中のアプリで投稿/ページを作成し、画像をアップロードします。つまり、データベース内の一部のデータ、ビデオ、ファイル、レコードが実行中のアプリケーションに追加されます。

3 つの質問:

  1. 複数の Amazon EC2 インスタンスが実際に WordPress インストールを実行している Elastic Beanstalk で WordPress が実行されている場合、それらのファイルは実行中のすべてのインスタンスに自動的に伝播しますか? また、新しい EC2 インスタンスが起動された場合 (たとえば、増加した負荷を処理するために)、これも発生しますか?

  2. AWS コンソールに表示される内容から、アプリのさまざまなバージョンをデプロイできますが、上記のシナリオに従って、新しいバージョンをデプロイすると、実行中のアプリに直接アップロードされたすべてのファイル (つまり、ファイルとデータベース レコード) が失われることはありませんか? それらを保持しながら、同時に新しいバージョンのアプリをデプロイするにはどうすればよいですか?

  3. WordPress チームは、アップグレードを発行し続けます。Web インターフェイスを介して、実行中の WordPress インストールを直接アップグレードできますか? それとも、最初に WordPress のローカル バージョンをアップグレードしてから、アプリの新しいバージョンを Beanstalk にアップロードする必要がありますか? ローカル バージョンをアップグレードしてからアップロードする必要がある場合は、ポイント 1 に戻ります。つまり、実行中のアプリの古いバージョンに対してユーザーが直接行った変更です。これらの変更を保存するにはどうすればよいですか?

4

7 に答える 7

8

私もこれに取り組んでおり、ここに関連するいくつかのことを学びました-特にアップロードに関するあなたの質問は私の心にありました:

（1）アップロードを処理する最良の方法は、あなたが提案するようにNFS / NASルートを使用することですが、それよりも優れているのは、WordPress用のAmazon S3プラグインを使用して、アップロードが自動的にコピーされるようにすることですWordPress メディア ライブラリの URL は、特定のサイトではなく、バケットの FQDN を反映します。そうすれば、Beanstalk に 1 つまたは 10 の WP ノードを持つことができ、メディア/画像はそれらのサーバーのいずれにも依存しません。

(2) ここでは絶対に RDS を使用する必要があります。マルチ AZ のリザーブド MySQL RDS インスタンスほど、操作が簡単でストレスのないものはほとんどありません。それか、Beanstalk から独立した MySQL を実行している独自の EC2 のいずれかですが、RDS の方がはるかに簡単なのに、なぜそれを実行するのでしょうか?

(3) はい、最初に Git リポジトリまたはローカル ファイルへの変更 (新しいプラグイン、テーマへの変更、WP のアップグレード) をコミットしてから、 Beanstalkコードのリビジョンとしてアップロード/インストールする必要があります。そうしないと、Web インターフェースを介して 1 つのノードに加えたすべての変更が、新しいノードの新しいロードに反映されることはありません。実際、データベースはアップグレードされますが、Beanstalk アプリケーションには古いコード セットが含まれます。何らかのエラーを作成します。

私は AWS アーキテクチャのコースを受講しましたが、EC2 と Beanstalk に対する彼らのアドバイスは、サーバー インスタンスは非常に使い捨てであると考え始めることです。たった 1 つのボックスで貴重なリソースを使用せずに、互いに働きすぎます。したがって、インスタンスを失うことは決して大したことではありません。(これは、物理サーバーの世界で私たちが考えていた方法とはまったく異なります.

幸運を！

于 2013-02-27T13:58:49.643 に答える
4

私は専門家ではありませんが、誰も答えていないので、最善を尽くします。

  1. あなたは絶対に正しいです。各 EC2 インスタンスにはいくつかのローカル ストレージがありますが、新しいインスタンスごとに破棄され、リセットされます。このため、Amazon には永続ファイル用の Elastic Block Storage や S3 などがあります。これを利用するように WP を構成する方法はわかりませんが、それが解決策になる可能性があります。

  2. この問題は、#1 に対する私の回答によって解決されると思います。データベースに関しては、すべての EC2 インスタンスが同じ RDS の場所からプルされている必要があります。繰り返しになりますが、各 EC2 インスタンスで MySQL を実行することもできますが、永続性のために、別個のデータベースを使用する方が理にかなっています。

  3. 繰り返しになりますが、ほとんどすべてが正しいです。ローカルでの開発は、常にライブ展開よりも前に行う必要があります。ローカルでアップグレードしてからライブ サーバーにプッシュすると、すべてのインスタンスが同じままになります。

正直なところ、私は専門家ではありません。うまくいけば、他の誰かがやって来て、より多くの情報に基づいた答えを出すでしょう. ただし、ここでの重要な概念上のハードルは、弾力的なスケーラビリティのアイデアです。このアイデアの顕著な点は、弾力的/スケーラブル/使い捨て可能なものと永続的なものとの間の要素の分離です。

うまくいけば、それは役に立ちます。

于 2012-10-30T15:16:48.883 に答える
0

OK、私はこの特定の問題について多くの調査を行い、これが私が学んだことです--

(1) wordpress ユーザーがいくつかのファイルをアップロードする場合、そのファイルは、その時点で実際に要求を処理している仮想マシンにのみアップロードされます。たとえば、現在 wordpress サイトがクラウド展開されており、5 つの仮想マシンを使用している場合、ユーザーが要求を行うと、その時点で負荷が最も低い 1 つの仮想マシンに転送されます...彼のアップロードはその仮想マシンにのみ保存されますサーバ。現在のサービスとしてのプラットフォーム ソリューション (Amazon Elastic Beanstalk や App Fog など) には、実行中のすべてのインスタンスに変更を伝達する機能がありません。それ（変更をすべてのサーバーに伝播する）か、実行中のすべてのインスタンスで共通のストレージを使用するかのいずれかです。これらは、この問題に対する唯一の2つの解決策です。(たとえば、共通ストレージの例は、Network-Attached-Storage (NAS) を使用する 5 つの実行中の仮想マシンすべてです...)

(2) たとえば、Amazon Elastic Beanstalk や App Fog などの現在利用可能なプラットフォームへの参照を使用すると、ユーザーが実行中のアプリに直接変更を加えた場合でも、これらのプラットフォームはコードのローカル バージョン (管理者が最初にクラウドにデプロイしたもの) に依存します。ユーザーが実行中のアプリに加えた変更で (管理者の PC 上の) コードのローカル バージョンを更新する方法はありません。したがって、これらの変更、つまりファイルは失われます。同様に、実行中のアプリに対するユーザーによるデータベースの変更も同様です。紛失 -- 管理者がローカル アプリ (クラウドにデプロイしたもの) とまったく同じデータベースを使用していない場合

(3) 実行中のアプリに対する変更は、最初に管理者の PC 上のローカル アプリに加えてから、クラウドにプッシュする必要があります。

私は、これらすべての問題に対処するクラウド PaaS に取り組んでいます。つまり、実行中のアプリを更新できます。実行中のアプリに加えられたコードの変更は、ユーザーがアクセスできるコード リポジトリでも更新されます。概念実証の準備ができていることを願っています。私が望んでいるほど良いものになるでしょう:) -- 現在、実際にあるのはウェブサイト（anyacloudpanel.com）だけです -- 設計作業が進行中です:)

私のウェブサイト (アーニャ クラウド パネル) について触れてはいけないルールがある場合は、申し訳ありませんが、回答から私のウェブサイトの URL を自由に編集して削除してください :)

ありがとう、アービンド。

于 2012-10-30T16:41:15.820 に答える