1

セロリ コンポーネントを含む wsgi アプリがあります。基本的に、特定のリクエストが来ると、比較的時間のかかるタスクをセロリに引き渡すことができます。自分でセットアップしたサーバーにこの製品の動作バージョンがありますが、最近クライアントから Cloud Foundry にデプロイするように依頼されました。Celery は Cloud Foundry のサービスとして利用できないため、私たち (私とクライアントのデプロイ チーム) はアプリを 2 回デプロイすることにしました。1 回は wsgi アプリとして、もう 1 回はスタンドアロンのセロリ アプリとして、rabbitmq サービスを共有します。

アプリ間のコードは同じです。wsgi アプリは正しく応答し、期待される Web ページを返します。vmc logs celeryappセロリが稼働していることを示していますが、セロリタスクになるはずのリクエストをwsgiに送信すると、.delay()ステートメントに到達するとすぐに消えます。それらはセロリのログにも表示されず、エラーとしても表示されません。

デバッグを試みます:

  • 各アプリはサンドボックス化され、ポートが制限されているため、Cloud Foundryでは使用できませんcelery.contrib.rdb(pdb に telnet インターフェイスを提供するため)。
  • これらのアプリが共有することになっている特定の rabbitmq インスタンスを見つける方法がわからないので、渡されているメッセージを確認できます。

更新: rabbitmq の検索に関する上記のステートメントを裏付けるために、セロリ タスクを共有する必要があるノードにアクセスしようとすると、次のようになります。

root@cf:~# export RABBITMQ_NODENAME=eecef185-e1ae-4e08-91af-47f590304ecc
root@cf:~# export RABBITMQ_NODE_PORT=57390
root@cf:~# ~/cloudfoundry/.deployments/devbox/deploy/rabbitmq/sbin/rabbitmqctl list_queues
Listing queues ...

=ERROR REPORT==== 18-Jun-2012::11:31:35 ===
Error in process <0.36.0> on node 'rabbitmqctl17951@cf' with exit value: {badarg,[{erlang,list_to_existing_atom,["eecef185-e1ae-4e08-91af-47f590304ecc@localhost"]},{dist_util,recv_challenge,1},{dist_util,handshake_we_started,1}]}

Error: unable to connect to node 'eecef185-e1ae-4e08-91af-47f590304ecc@cf': nodedown
diagnostics:
- nodes and their ports on cf: [{'eecef185-e1ae-4e08-91af-47f590304ecc',57390},
                                {rabbitmqctl17951,36032}]
- current node: rabbitmqctl17951@cf
- current node home dir: /home/cf
- current node cookie hash: 1igde7WRgkhAea8fCwKncQ==

これをデバッグするにはどうすればよいですか?また、タスクが消えてしまうのはなぜですか?

4

1 に答える 1

1

どうやら問題は、ブローカーとセロリ ワーカーの間のデッドロックによって引き起こされたようで、ワーカーはタスクの完了を決して認識せず、新しいタスクを受け入れることもありませんが、クラッシュしたり失敗したりすることはありませんでした。タスクは消えていませんでした。彼らは単に永遠に列に並んでいました。

更新: デッドロックは、依存関係をインストールするラッパー スクリプト内で celeryd を実行していたことが原因でした。(文字通りpip install -r requirements.txt && ./celeryd -lINFO)。Cloud Foundry がプロセス ツリーを管理する方法が原因で、Cloud Foundry は親プロセス (bash) を強制終了しようとし、これにより celeryd が HUP されますが、最終的には多くの子プロセスが終了することはありません。

于 2012-06-24T13:45:00.603 に答える