2

最近、Django アプリをライブにプッシュしました。サーバー上のステージング サブドメインにアプリを構築しました。ライブに移行したとき、ステージング サブドメインのファイルをメイン サイトにコピーし、ステージング データベースを作成して、古いステージング サイトを新しいステージング データベースに向けました (新しいライブ サイトは元のデータベースに向けたままにします)。これは Apache の下の mod_python にあります。

両方のサイトに固有の SESSION_COOKIE_NAME 設定を作成し、ライブ サイトでは SESSION_COOKIE_DOMAIN を ".sitename.com" に、ステージング サイトでは None に設定しました。

私たちが見ている問題は、ライブ管理者のユーザーが編集を行っており、それが (表示されているように) ステージング サイトに保存されていることです。ユーザーは、リクエスト中に管理サイトから「ランダムに」ログアウトされます。

ここで明らかに間違っていることはありますか？サブドメインが「staging.sitename.com」にあるため、SESSION_COOKIE_DOMAIN を「www.sitename.com」に制限する必要がありますか? 現在稼働中のデータベースに古いセッション情報を残しましたか (この問題が発生する前に、./manage.py clean を実行して稼働中のデータベースからすべてのセッションを削除しました)。

ありがとう

4

1 に答える 1

3

過去数週間でこの問題に遭遇しました。これが重複する可能性のある場所がいくつかありました。

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

PythonInterpreter mysite

同一サーバー展開に関連する Django ドキュメント

2) 同じポートでキャッシュ バックエンドを実行していますか? settings.py には、ステージング コンテンツとライブ コンテンツを区別するために、キャッシュされたコンテンツの前に複数の文字を追加できる構成があります。これは、settings.py の次の構成で実装されます。

CACHE_MIDDLEWARE_KEY_PREFIX = "STG_"

別のオプションとして、別のファイルシステム キャッシュでしばらく実行して、問題が解決するかどうかを確認することもできます。settings.py で、追加してみてください

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

3) .pyc ファイルをすべて削除してみましたか? 奇妙なことに、上記の 2 つの解決策で問題を解決できなかった場合、サーバーの停止中に bash コマンドを実行して、コンパイル済みのすべての Python ファイル (.pyc ファイル) を削除しました。

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

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

お役に立てれば！

于 2009-06-20T02:52:03.160 に答える