0

Debianサーバーでホストされているdjangoプロジェクトがセロリとセロリビートを使用できるように、最適な「アーキテクチャ」を見つけようとしています。彼は私の要件です:

  • セロリ ワーカーとセロリ ビートは、サーバーの再起動後に自動的に実行できるようになります。
  • 標準の Debian パッケージを使用することをお勧めします。
  • グローバルにインストールする必要がないものは、プロジェクトの virtualenv にインストールする必要があります。
  • django プロジェクトの所有者である Linux ユーザーは、プロジェクトを展開するために sudo 権限を必要としません。

これらの要件に基づいて、次の結論に達しました。

  • ワーカーとビートのデーモン化には、supervisord を使用するとよいでしょう。Supervisord は標準の debian パッケージに含まれており、この方法でインストールすると、サーバーの再起動後に Supervisord が実行されます (これが、すべてのプロジェクトで virtualenv にローカルにインストールしたくない主な理由です)
  • Celeryは、 virtualenvのすべてのプロジェクトに対してローカルにインストールできます。

このような状況下で、新しいプロジェクトを展開するときに、新しい Linux ユーザーを作成し、ルートとして実行している apache virtualhost などをセットアップするときに、supervisord の新しい構成ファイルも追加します。次に、ファブリックを使用してプロジェクトの新しいバージョンをデプロイするとき、プロジェクトユーザーの下でのみ作業します。

このソリューションの唯一の未解決の問題 (私が今まで見つけた) は、セロリ ビートのスケジュール構成が django の設定に記述されているが、リロードされるまでビート デーモンが構成の変更を認識できないことです。ただし、プロジェクト ユーザーはリロードできません。

私の質問は、この問題をどのように解決すべきか、または他のどのアーキテクチャをお勧めしますか? ありがとうございました。

4

2 に答える 2

0

Chris の回答に基づいて、sudo 権限なしで Supervisord プログラムを再起動する方法の解決策: ソケットの権限を変更するには、supervisord.conf を編集する必要があります (私の場合は /etc/supervisor/supervisord.conf にあります]

[unix_http_server]
file=/var/run//supervisor.sock   ; (the path to the socket file)
chmod=0766                       ; sockef file mode (default 0700)

次に、構成ファイルに書き込まれているユーザーがプログラムを再起動するユーザーであることを確認する必要があります。

[program:projectx_celerybeat]
; Set full path to celery program if using virtualenv
command=/path_to_project_root/env/bin/celery beat -A main -s /path_to_project_root/celerybeat-schedule --loglevel=INFO

; remove the -A myapp argument if you are not using an app instance

directory=/home/xxx/project_root/celery_root/
user=YOUR_USER
numprocs=1
stdout_logfile=/path_to_log/beat.log
stderr_logfile=/path_to_log/beat.log
autostart=true
autorestart=true
startsecs=10

次に、YOUR_USER によって実行されるこのコマンドが機能する必要があります。

supervisorctl [stop/start/restart] [program_name]
于 2015-02-17T15:42:52.943 に答える