Django：同じサーバー上のライブサイトとステージングサイトの競合

Question

最近私はDjangoアプリをライブ配信しました。私たちはサーバーのステージングサブドメインにアプリケーションを構築しました。私がライブに出たとき、私はステージングサブドメインのファイルをメインサイトにコピーし、ステージングデータベースを作成し、新しいステージングデータベースで元のステージングサイトを指し示しました（新しいライブサイトは元のデータベースを指していました）。これはApacheのmod_pythonにあります。

両方のサイトでSESSION_COOKIE_NAMEの設定が一意になりました。ライブサイトではSESSION_COOKIE_DOMAINを、サイトでは「.sitename.com」に設定しました。

ライブ管理者のユーザーがステージングサイトに保存されている編集を行っていることがわかりました。ユーザーは、リクエスト中に管理サイトから「ランダムに」ログアウトしています。

私は明らかにここで間違っていることがありますか？サブドメインが "staging.sitename.com"にあるため、SESSION_COOKIE_DOMAINを "www.sitename.com"に制限して制限する必要がありますか？今のライブデータベースに古いセッション情報を残しましたか（この問題が発生する前に./manage.pyを駆除し、ライブデータベースからすべてのセッションを削除しました）？

ありがとうございました

Answer 1

ここ数週間、この問題が発生しました。これは重複する可能性のある場所がいくつかありました。

1）別のPythonインタプリタを実行していますか？ スレッドがお互いに踏み込まないようにmod_pythonを設定する方法はいくつかあります。ここでのポイントは、個別のServerName（この場合ドメインstaging.sitename.comとwww.sitename.com）を提供し、Apache vhosts構成ファイルに別個のPythonInterpreter構成設定を提供することです。

PythonInterpreter mysite 

Relevant Django docs on same-server deployments

2）あなたは、同じポート上のキャッシュバックエンドを実行していますか？ キャッシュされたコンテンツの先頭に複数の文字を付けて、ライブコンテンツとステージングコンテンツを分離するための設定がsettings.pyにあります。これは、settings.pyに次のような構成で実装されています。

CACHE_MIDDLEWARE_KEY_PREFIX = "STG_" 

別のオプションは、問題が解決されるかどうかを確認するためにしばらくの間、別のファイルシステムのキャッシュ上で実行することができます。 settings.pyでは、）

CACHE_BACKEND = 'file:///var/tmp/django_cache' 

3を追加してみてください、あなたの.pycファイルのすべてのファイルを削除しようとしたことがありますか？ 奇妙なことに、上記の2つの解決策が問題を解決できなかった場合、サーバーの停止中にコンパイル済みのすべてのPythonファイル（.pycファイル）を削除するbashコマンドを実行しました。

find ./ -type f -name "*.pyc" -exec rm -f {} \; 

これは、デプロイメントの変更が何らかの理由で再コンパイルされなかったことを示します。

希望すると便利です。