新しいコードをライブでデプロイする

ライブ（eコマース）サイトに新しいコードを展開するためのベストプラクティスは何ですか？

今のところ、ディレクトリの名前をに変更public_html_newしpublic_html、古いものに変更するとき、apacheを+/- 10秒間停止しましたpublic_html_old。これにより、Apacheを再び起動する前に短いダウンタイムが発生します。

Gitを使用して新しいリポジトリをライブディレクトリにプルする場合、同じ質問があります。サイトがアクティブな間にレポジトリをプルできますか？また、DBもコピーする必要がある場合はどうでしょうか。

ライブサイトのtar（バックアップ目的）圧縮中に、メディアディレクトリで変更が発生したことに気付きました。それは、ファイルが定期的に変化し続けることを私に示しました。また、Apacheがデプロイメント中に停止されない場合、これらの変更が干渉する可能性がある場合。

ロードバランサーを使用することをお勧めします。サイトが数秒のダウンタイムを心配するほど重要である場合、フォールトトレランスを心配するのに十分重要です。

それはさておき、これがUNIXシステム上にある場合、名前変更（またはシンボリックリンクの更新など）の間にApacheを保留にすることができます。

killall -STOP httpd  # Pause all httpd processes
mv public_html public_html_orig
mv public_html_new public_html
killall -CONT httpd  # Resume all httpd processes

これにより、名前の変更中にApacheが新しいリクエストを受け付けなくなります。シンボリックリンクまたは他のアプローチを好む場合、同じ考えを使用できます：

killall -STOP httpd  # Pause all httpd processes
rm /var/www/html
ln -s /var/www/version/03 /var/www/html
killall -CONT httpd  # Resume all httpd processes

保留中の接続またはパケットは、OSのキューに入れられることに注意してください。非常に混雑しているサイトでは、httpdワーカータイプに適したListenBacklogの調整を検討し、TCPリスンバックログに関連するOS設定を確認してください。

httpd.confのDocumentRootを変更し、グレースフルリスタート（apachectl graceful）を実行することもできます。ここでの欠点は、Directory構成の更新も必要になるため、エラーのリスクが高くなることです。

最速かつ最も簡単な方法は、次のようなバージョンディレクトリを使用することです

/var/www/version/01
/var/www/version/02

html_rootとして現在のシンボリックリンクを使用します。

/var/www/html -> /var/www/version/02

この手法は、 、ブランチとタグをチェックアウトし、シンボリックリンクを変更し、Apacheをリロードできるリビジョン管理システム（svn、git、mercurialなど）れます。ダウンタイムは最小限で、この技術を使用して、それが可能に非常に簡単にロールバック。

また、RPMパッケージや構成変更管理（chef、puppetなど）インフラストラクチャなど、より複雑な展開システムともうまく統合されます。

Apacheをシャットダウンせずにディレクトリ名を変更しても同様に機能するはずです。これにより、ウィンドウが大幅に短くなります。mv public_html public_html_old && mv public_html_new public_htmlほんの数秒で終了するはずです。

いくつかの欠点は、このアプローチがもたらすことです 404、ウィンドウ内で発生する可能性のある要求にすべての要求です。また、public_html_newディレクトリを持たずに上記のコマンドを実行すると失敗し、サイトを提供します404すべてのリクエストに応じるます。

ディレクトリでアトミックに実行することはサポートされていません。しかし、シンボリックリンクを使用してそれを行うことができます。という名前のディレクトリを持つ代わりに、という名前のディレクトリとpublic_html、そのディレクトリを指すpublic_html.version-numberというシンボリックリンクを用意しpublic_htmlます。次のディレクトリを作成できますpublic_html.new-version-number新しいシンボリックリンクをpublic_html.new。

次に、に名前public_html.newを変更しpublic_htmlてアトミックに切り替えることができます。それmvはそのリネームを実行するには「インテリジェントすぎる」ことに注意してください。しかし、それはos.renamepythonから、またはrenameスマートにしようとせずにシステムコールを呼び出す他の何かを使用して行うことができます。

データベースで何をするかは、使用しているデータベース、および使用するデータベースによって異なります。質問のその部分に対する適切な回答を提供する前に、データベースに関する詳細を提供する必要があります。

Symlinksとmvは友達ですが、エンドユーザーが新しいバージョンのデプロイ中にエラーページを表示しないようにする必要がある場合は、少なくとも2台のバックエンドサーバーの前にリバースプロキシまたはロードバランサーが必要です（apacheあなたの場合）。

デプロイ中に、一度に1つのバックエンドを停止し、新しいコードをデプロイし、それを再起動して、残りのバックエンドで繰り返すだけです。

エンドユーザーは常にプロキシによって適切なバックエンドに誘導されます。

運用システムに定期的に変更を適用する場合は、構造化されたライフサイクルを処理します。カピストラーノhttp://capistranorb.com/をお勧めします。これは、複数のプラットフォームと構成の1つ以上のサーバーにソフトウェアを展開するためのオープンソースソリューションです。

Magentoにはプラグインもあります：https : //github.com/augustash/capistrano-ash/wiki/Magento-Example

単一サーバーおよびほぼシームレスな移行の場合、シンボリックリンクを使用することをお勧めします。

私が行う方法は、ローカルの開発環境からGithubなどのオンラインGitリポジトリに変更をコミットすることです。私の実稼働環境はリモートリポジトリから実行さgit pullれるため、サーバーにssh し、最新の変更を反映するために実行するだけです。ウェブサーバーを停止する必要はありません。

プロジェクトにファイルがあり、設定やコンテンツがローカルバージョンと異なる場合（構成ファイルやメディアアップロードなど）、環境変数を使用したり、これらのファイル/ディレクトリをファイルに追加.gitignoreして、リポジトリとの同期を防ぐことができます。

私の最初のアイデアは：

# deploy into public_html_new, and then:
rsync -vaH --delete public_html_new/ public_html/

良い解決策は、rsyncを使用することでした。実際に変更されたファイルのみが変更されました。注意してください、パスの最後のスラッシュはここで重要です。

通常、Apacheは再起動を必要としません。Javaの世界ではありません。要求に応じてすべてのphpファイルの変更をチェックし、変更時に自動的に再読み取り（および再トークン化）します。

Git pullも同様に効率的でしたが、スクリプトを作成するのは少し難しくなりました。もちろん、さまざまなマージ/変更検出の可能性の広いスペクトルを可能にしました。

このソリューションは、実際に大きな変更がない場合にのみシームレスに実行されます-展開に大きな変更がある場合、コードが部分的に変更される無視できない時間間隔があるため、少しのハザードを閉じることができませんそして、一部はそうではありません。

大きな変更がある場合、私の提案は最初の解決策でした（2つの名前変更）。

ここに少し筋金入りですが、100％アトミックソリューションがあります：

（1）magentoが行われる場所で、ファイルシステムの一部を代替マウントします。

mount /dev/sdXY /mnt/tmp

（2）--bindpublic_html_newをpublic_htmlにマウントします：

mount --bind /path/to/public_html_new /path/to/public_html

この時点から、Apacheは新しいデプロイメントを確認します。404の変更は不可能です。

（3）rsyncとのシンクロナイゼーションを行いますが、代替マウントポイントで行います）：

rsync -vaH --delete /mnt/tmp/path/to/public_html_new/ /mnt/tmp/path/to/public_html/

（4）バインドマウントを削除する

umount /path/to/public_html

http_publicフォルダの移動/置換は、シンプルmvまたはln -s HTTPサーバーが稼働し続けながらコマンドまたは同等。いくつかのスクリプトを実行してダウンタイムを大幅に削減できますが、プロセスを自動化する場合は、スクリプト内のコマンドのリターンコードを慎重に確認してください。

ただし、ダウンタイムを発生させたくない場合は、アプリケーションもそれをサポートする必要があり。ほとんどのアプリケーションは、永続性のためにデータベースを使用します。アプリケーションのバージョンNがデータモデルのバージョンN + 1（またはその逆）を台無しにすると、開発チームが予見していなければ問題が発生する可能性があります。

経験から、アップグレードを通じてこのような一貫性を維持することは、ほとんどのアプリケーションでは与えられていません。ダウンタイムにもかかわらず、適切なシャットダウンは、一貫性の問題を回避するための良い方法です。