27

そこで、uWSGI 経由で Docker + Supervisord + Django アプリを試してみます。スタック全体が正常に動作していますが、ログを整理する必要があります。

非デーモン モードでスーパーバイザーを起動すると、

/usr/bin/supervisord -n

次に、スーパーバイザーのログ出力を docker logs stdout に再生します。ただし、supervisord がデーモン モードの場合は、それ自体のログがコンテナー ファイルシステムに隠され、そのアプリケーションのログも (独自の app__stderr/stdout ファイルに) 隠されます。

私が望むのは、スーパーバイザーとアプリケーションの標準出力の両方を docker ログに記録することです。

スーパーバイザーを非デーモン モードで起動することは賢明な考えですか、それとも意図しない結果を引き起こしますか? また、アプリケーション ログも docker ログに記録するにはどうすればよいですか?

4

7 に答える 7

24

Docker コンテナーは kleenex のようなもので、使用してからドロップします。「生きている」ためには、Docker はフォアグラウンドで何かを実行する必要があります (デーモンはバックグラウンドで実行されます)。そのため、Supervisord を使用しています。

そのため、プロセスの出力 (アクセスとエラー) を、コンテナーの実行時に表示される Supervisord の出力に「リダイレクト/追加/マージ」する必要があります。

ドリューが言ったように、誰もがそれを達成するためにhttps://github.com/coderanger/supervisor-stdoutを使用しています (私にとって、これは Supervisord プロジェクトに追加する必要があります!)。ドリューが言い忘れたこと、追加する必要があるかもしれません

stdout_logfile=/dev/stdout
stdout_logfile_maxbytes=0

Supervisord プログラム構成ブロックへ。

また、プロセスが標準出力ではなくログファイルに記録されていると想像してみてください。supervisord に監視を依頼することもできます。

[program:php-fpm-log]
command=tail -f /var/log/php5-fpm.log
stdout_events_enabled=true
stderr_events_enabled=true

これにより、php5-fpm.log の内容が stdout にリダイレクトされ、さらに Supervisord-stdout 経由で Supervisord stdout にリダイレクトされます。

于 2015-02-21T10:25:29.050 に答える
7

デーモン モードを使用しないことが最善の解決策のように思えますが、実際の物理サーバーまたは何らかの VM セットアップがある場合に使用するのと同じ戦略を採用する可能性があります。つまり、ログを集中化します。

コンテナー内でlogstashのような自己ホスト型のものを使用して、ログを収集し、中央サーバーに送信できます。または、loggly や papertrail などの商用サービスを使用して同じことを行います。

于 2013-09-20T23:02:31.287 に答える
1

現在のベスト プラクティスは、Docker イメージを最小限にすることです。私にとって、Python アプリケーションの理想的なコンテナーには、必要に応じて、コード、サポート ライブラリなどを含めるuwsgiことができます。

https://github.com/msgre/uwsgi_loggingで 1 つのソリューションを公開しました。背後にある単純な Django アプリケーションであり、Django アプリuwsgiからのログを表示するように構成されており、 .uwsgisupervisor

于 2016-02-24T19:30:20.633 に答える
0

実際、supervisord を非デーモン モードで起動するのが最善の解決策です。

また、ボリュームを使用して、supervisord のログを中央の場所にマウントすることもできます。

于 2013-09-14T00:30:31.237 に答える