現在、Amazon EC2でのwordpressインストールを自動スケーリングすることを検討しています。すべてが機能しています。EBSインスタンスをバンドルし、ポリシーを設定すると、必要に応じてAmazonがロードバランサーの背後でインスタンスを自動的に実行できます。
しかし、WordPressにプラグインがある場合、すべてのインスタンスにインストールされるわけではありません。プラグインをインストールすると、他のサーバーにも自動的にインストールされるようにしたいと思います。
私はこれのために何ができますか?何か考えがありますか?
あなたの質問には2つの側面があります:
同期:
Wordpressプラグインをインストールすると、ファイルとデータベースが変更されます。したがって、すべてのサーバーで変更を模倣するには、各インスタンスのファイルとデータベースの両方を変更する必要があります。特定の実装では、すべてのインスタンスが同一であるか(つまり、すべてがWebサーバーとデータベースサーバーの両方を実行するか)、またはWebサーバーとデータベースサーバーを異なるインスタンスで実行するかどうかに依存します。
Webサーバーで1つのインスタンスを実行し(次にそのインスタンスを自動スケーリングし)、データベースサーバーで別のインスタンスを実行する(例: http://www.mysqlperformanceblog.com/2006/10))には、適切な議論がなされる可能性があります。/16/should-mysql-and-web-server-share-the-same-box / )。もちろん、データベースを自動スケーリングするとすぐに、すべてのインスタンスでデータの一貫性を維持するという問題が発生します。
ファイルの同期:データを同期する最も簡単な解決策はrsyncを使用することです。定期的に(cron経由で)実行することも、incronを使用してトリガーすることもできます。これにより、ディレクトリの内容が変更されたときに実行できるようになります。 inotifyを使用してディレクトリへの変更を監視し、rsyncをトリガーする別のオプションlsyncd。
ファイル同期への別のアプローチは、ネットワーク/分散/クラスターファイルシステムを使用することです。たとえば、Glusterを使用して、複製(複数のコピー)および/または分散(拡散)を維持できます。
また、ノード間でPHPセッションを共有することもできます。
データベースの同期:間違いなく、ファイルの同期を維持するのは簡単な部分です。データベースの同期を維持することは、より困難です。さまざまな数のノードで使用すると、難易度が高くなります。
別のMySQLインスタンスと、rsyncベースのスクリプトの1つ(おそらくlsyncd)を使用して、ファイルの同期を維持することをお勧めします。 Webサーバーを自動スケーリングします。データベースサーバーについて心配する必要が生じるまでには、おそらくしばらく時間がかかります。データベースを自動スケーリングする場合は、マスターノードをグループから除外し、スレーブをスケーリングします。
展開:
この面では、各ノードにわずかな違いが必要な場合があります(たとえば、1つはマスター、もう1つはスレーブなど)。フレームワーク(voretaq7の回答で述べたように)がここに行く方法です。多くの点で、実装が優れているほど、自動スケーリングの必要性は少なくなります。 1つのセットアップには、各ノードとそのノードで実行されているサービスの状態を監視するCorosyncとPacemakerが含まれる場合があります。マスターノードを選択し、必要に応じてスクリプトを実行してクラスターをスケーリングします。