共通のデータベースを指す複数の負荷分散サーバーがある状況があります。
通常の実行では、これは正常に機能し、冗長性、スケーラビリティなどを提供します。
ただし、展開は少し面倒な作業です。
私たちはさまざまな機能を使用しており、展開の自動化を試みています。現時点での展開はあまり信頼できません。
簡略化された形式では、各サーバーのデプロイスクリプトには2つの段階があります。
ファイルを更新する
機能を元に戻す（依存関係、設定変更などを管理します）
複数のサーバーを一貫性のない状態にせずに展開するためのベストプラクティスはありますか？
手順1と2をサーバーAに展開するかどうかを確認すると、サーバーBが壊れます。両方のサーバーで手順1を試してから手順2に進むと、しばらくの間両方が壊れます。
回答:
おそらくAegirを検討する必要があります。これは、これまでで最も柔軟で強力なDrupalサイト管理/デプロイメントシステムです。アクロの複数のWebヘッドにまたがる「プラットフォーム」、または「クラスター」、およびその他のさまざまな構成を管理できます。
私は彼らの一読を持つことをお勧めしたいコミュニティのドキュメント、一般的にかなり良いです、などを読んmig5の優れた概要と紹介記事などで彼の他の記事のいくつかのこの1。
また、＃aegir IRCチャンネルでも優れたサポートを得ることができます。
これはワークフローの変更になるので、気が付くまでに少し時間がかかる可能性がありますが、一度そこに戻ると、振り返ることはできません。
私たちの会社では、Drupalサイトをたくさん維持していますが、現在の設定は次のようになります。
上記のことは、ほとんどのDrupalサイトでかなり一般的です。
私たちが私たちの特別なことは、カスタムのdrushコマンド-'Drush Debian Packaging ' を使用して、デプロイメント用のサイトをdebianパッケージ化することです。
Drush Debianパッケージは、DrupalサイトをDebianまたはUbuntuサーバーにデプロイする手段として、DrupalサイトのDebianパッケージを構築するためのDrushコマンドを提供します。
Drush Debianパッケージングは、Drupalフックシステムを利用して、サイトのニーズに最適なDebianパッケージを構築します。機能は次のとおりです。
これは何を意味するのでしょうか？
リリースをビルドするには：
cd /path/to/drupal-root
drush dh-makeリリースをデプロイするには、最初に.debをクラスター内のすべてのWebサーバーにSCPします。次に、すべてのWebサーバーで実行します（Linuxパッケージcsshを使用して、ファーム内のすべてのサーバーに同時にコマンドを入力できます）。
sudo dpkg -i drupal-site-yoursitehere.2011.05.25-1.all.deb1つのWebサーバーで次を実行します。
cd /path/to/drupal-root
sudo -u drupal-site-yoursitehere drush updb && drush fra -y && drush cronできた
もちろん、これをコードベースの観点からロールバックするのは簡単です。以前のバージョンの.debをすべてのWebサーバーにインストールし、データベースをロールバックするだけです。
これについての質問に答えて幸せ
展開プロセスのどの部分が面倒/信頼できないのですか？
それが「サーバーAを更新してからB /不整合を更新する」問題である場合、プッシュの期間中メンテナンスページを表示するのはどうですか？メンテナンスページをアップ、両方のWebヘッドでコードを更新、そのうちの1つで update.phpを実行、メンテナンスページをダウン これはかなり簡単にスクリプト化できます。
別のオプション：実行するサイトの種類に応じて、すべてのユーザーをオフラインで起動し、ログイン/登録を無効にする「読み取り専用モード」を作成できます。DBを同じdbボックスの2番目のDBに複製し、フロントエンドを新しいdocrootに複製し、そこで更新を行ってから、Apacheのdocrootを新しいフロントエンドdocrootにシンボリックリンクします。ワークフローは次のようなものです。
Entenduが示唆するように、それはあなたが行っている変更に依存します。データベースがまだ更新されていない場合、エラーを発生させずに実行できるコード更新の割合はどれくらいですか？データベースの更新に依存しないものについては（そして開発プロセスを少し変更してこれをより一般的にすることができます）、実際に特別なことはありません。最小限のダウンタイムでデプロイメントを実行することを想定しています。それ以外の場合は、基本的な同期操作が必要になります。この場合、（読み取り専用モードでサイトを使用している場合でも）望ましくない影響のある時間枠が常に存在しますが、ほとんどの場合はかなり短いと思います。
各サーバーに「新しい」ディレクトリを事前に設定し、それらすべてを同時に切り替えて新しいディレクトリを指すようにするなどの基本的な最適化を行うことができます（おそらくEntenduの回答のようなシンボリックリンクを使用）。サーバーは5〜10秒以内に新しいファイルに切り替えました。
データベースの更新の問題が残ります。それらが1つのサーバーからのみ実行する必要がある種類である場合は、他のサーバーをメンテナンスモードにするか、ロードバランサーを調整して、この間それらを使用しないようにすることができます。もちろん、ユーザーがサイトでアクティブなときにそれらを実行できない場合は、すべてをメンテナンスモードにする必要がありますが、単純な更新の場合、これは約30秒以下で実行できるものになる可能性があります。
変更の種類ごとに異なる展開スクリプトを用意することは価値があるため、ファイルのコピー、小さなデータベースの更新の実行、データベースの大きな変更など、必要な最小限のプロセスを実行できます。
ファイルとデータベースの更新を最適化して、開発方法に簡単な変更を加えることができるかどうかを確認できれば、近づく可能性がありますが、これが新しいものかどうかはわかりません。
Aegirは、サイトのネットワークの管理に役立ちます。私はそれを使用して、単一のクライアントに対して2000を超えるサイトを展開および管理しました。
あなたの質問は、複数のウェブヘッドを持つ単一のサイトを管理したいことを示唆しています。その場合、Aegirはあまり役に立ちません。代わりに、ネットワークをサポートするファイルシステムの使用を検討することをお勧めします。これにより、コードの同期が保たれるだけでなく、すべてのノードでアップロードを利用できるようになります。
歴史的に人々はNFSを使用して、1つのサーバーのファイルシステムを他のノードと共有することができました。残念ながら、これにより単一障害点が発生します。NFSサーバーがロックしたり、停止したりすると、サイトにサービスを提供できないためです。
より信頼性の高いサーバーを優先してioパフォーマンスを少し妥協しても構わない場合は、GlusterFSをお勧めします。いくつかの実稼働環境で使用しました。完璧ではありませんが、NFSよりも優れています。Glusterを使用すると、ウェブヘッドは常にローカルで読み取り、書き込みは他のノードに複製されます。
展開戦略に関しては、リストの最初のツールとしてdrushを使用する必要があります。Drushを使用すると、デプロイメントのステップを自動化できるはずです。展開ジョブを追跡し、問題が発生した場合のパターンを特定できるように、Jenkinsをミックスに追加することを検討する必要があります。Capistranoは、デプロイメントに関連するステップを自動化するのに役立ちます。物事を適切に実行すれば、ユーザーが展開を行ったことをユーザーに知られないようにすることができます。