1

django webapp のスーパーユーザーに公開する特定の sysadmin 設定があります。ドメイン名 (contrib.sites を使用) やシングル サインオン構成など。これらの設定の一部は、システムによってキャッシュされます。これは、リクエストごとにミドルウェアで余分な DB ヒットを回避したい場合や、独自のキャッシュを持つ contrib.sites が原因である場合があります。そのため、設定が変更されても、アプリがリロードされるまで変更は有効になりません。

これらの変更が行われたときにアプリを自動的に再起動して、クライアントが再起動を行うようにせがむ必要がないようにします。

私たちの webapp は mod_wsgi を介して apache で実行されているため、これらの設定のいずれかが変更されるたびに、アプリの wsgi ファイルに触れるだけでこれを実行できるはずですが、それを行うのは少し奇妙に感じられます。私たちが従うべき、より優雅な慣習です。

キャッシュされ、アプリのリロードが必要な更新を適用する正しい方法はありますか? これらのキャッシュを無効にするのは非常に面倒なので、アプリの再起動に重大な欠点がない限り、それは避けたいと思います。

4

4 に答える 4

2

mod_wsgi の場合:

他のいくつかの WSGI サーバーには同様のオプションがありますが、他の WSGI サーバーのオプションは通常より制限されています。

于 2012-12-17T22:23:37.337 に答える
1

WSGI を使用していて、supervisord、gunicorn、uwsgi などのコントローラーによってプロセスが監視されている場合は、自分自身に SIGINT または SIGQUIT を送信できます (コントローラーによって異なります)。現在のプロセスを正常にシャットダウンし、コントローラーがプロセスを再起動します。

import signal, os
os.kill(os.getpid(), signal.SIGQUIT)
于 2012-12-17T23:49:38.207 に答える
0

mod_wsgi を使用して Apache で実行している場合は、モデルを変更するたびに wsgi 構成ファイルのタイムスタンプを更新するだけです。wsgi ファイルが更新されると、Apache はアプリケーションを自動的に再起動します。

于 2012-12-17T21:32:51.037 に答える
0

それはあなたのセットアップに依存します：

  • 単一のサーバーで wsgi を使用している場合は、wsgi ファイルに触れて、Apache がアプリのすべてのインスタンスを再起動できるようにすることができます。
  • gunicorn を使用している場合は、おそらく Supervisord を使用して制御します。次に、supervisorctl restart APPNAME が解決策になります
  • アプリを複数のサーバーにスケーリングする場合は、すべてのサーバーがインスタンスを再起動することを確認する必要があります。これを実現するには、いくつかの方法があります。
    • mod_wsgi を使用している場合は同じファイルシステムを使用し、タッチはすべてのサーバーでカウントされます
    • sshを使用して他のサーバーにログインし、アプリを再起動させます

アプリを再起動する方法は他にもあると思いますが、設定と、すべてのインスタンスを再起動する必要があるか、1 つだけを再起動する必要があるかによって大きく異なります。

于 2012-12-18T08:32:26.510 に答える