☰

Docker コンテナ内でログ記録を構成するにはどうすればよいでしょうか?

tag-icon • tag-icon debian syslog docker rsyslog container
Docker コンテナ内でログ記録を構成するにはどうすればよいでしょうか?

OpenVPN サーバーを Docker 化 (Debian 8.2 に) しようとしていました (はい、そのようなコンテナーがすでに存在していることは知っています) が、コンテナー内で問題が発生し、サーバーの起動に失敗しました。

ログを検査することにしましたが、/var/log/syslog(ホスト マシン上の OpenVPN ログ) がコンテナー内にありませんでした。

インストールされていないと思いrsyslog、OpenVPN のインストールの前に Dockerfile にそのインストールを追加しました。しかし、これは効果がなく、syslogまだ欠落していました。

私の Dockerfile は次のとおりです:

FROM debian:8.2
USER root
EXPOSE 53/udp
EXPOSE 1194/udp
EXPOSE 443/tcp
RUN apt-get update
RUN apt-get install -y rsyslog
RUN apt-get install -y openvpn
# ...
# Some configuration stuff
# ...
ENTRYPOINT service openvpn start && sh

質問は次のとおりです:

  • 私のホスト Debian 8.2 にデフォルトでインストールした後、 OpenVPN が にログ記録するsyslogのに、コンテナー内ではログ記録しないのはなぜですか? ホスト マシンで OpenVPN が にログ記録するように強制する設定は何もしていませんsyslog。これはデフォルトの動作でした。

  • Docker コンテナ内で実行されている OpenVPN サーバーのログ記録を構成するにはどうすればよいですか?

答え1

OpenVPN は、起動するものが何もないので、その Dockerfile では起​​動しません :-)。エントリポイントは ですsh。これが実行されるすべてです。

Docker 内で 2 つのデーモンを起動したい場合、エントリポイントは両方のデーモンを起動するプログラムである必要があります。多くの人がsupervisordこれを使用します。Docker は比較的偏ったソフトウェアであり、1 つのコンテナーで複数のデーモンを実行することは慣用的ではないことに注意してください。

デバッグ目的であれば、問題はありません。またはopenvpnで実行しないでください。stdout に書き込まれます (そう言われていますが、stderr が表示されても驚きません)。手動で起動すると、デバッグに最適です。すべてのログ メッセージがすぐにターミナルに表示されます。--daemon--log

エントリポイントを設定し、コンテナをインタラクティブ モードで手動で起動した場合も、同じ処理が行われます。バックグラウンド コンテナとして起動した場合 (あいまいな表現で申し訳ありませんが)、出力は にキャプチャされますdocker logs。これは、systemd (および systemd の「ジャーナル」ログ システム) などの最新の init システムで好まれる手法と同じです。

デーモンを希望どおりに設定したら、他の回答のように、ログをキャプチャするためのよりカスタマイズされたシステムに興味があるかもしれません。

のマニュアルページによると、Docker にはプラグ可能なログ ドライバーがありますdocker logs。ホストの syslog に書き込む「syslog」ドライバーがあります。 動作しないと書かれていますdocker logsが、それは問題にならないと思います。

警告: docker logsjournald ログ ドライバーを使用する場合は機能します。ただし、Debian のデフォルトでは、再起動時にログが失われると思われます。Debian は永続的なジャーナルを設定しないためです。ただし、それが必要な場合は変更するのは難しくありません。

このコマンドをサポートする他のログ ドライバーは、docker logs「json-file」と呼ばれます。これは永続的なものだと思いますが、他のソリューションのいずれかを好むかもしれません。

「なぜ」という質問

重要なのは、Docker コンテナは必ずしもそのベースとなる OS と同じように動作するわけではないということです。Docker は、 、 、または仮想マシンのような OS 仮想化ではありませんLXC。Dockersystemd-nspawnは から派生したものですがLXC、単一のプログラムを実行する「アプリケーション コンテナ」用に特別に設計されました。

(現在の) サーバー ディストリビューションは、複数の実行プログラムの組み合わせとして設計されています。そのため、そこからパッケージを取得しても、それがアプリケーション コンテナーの 1 つ内でまったく同じように動作するとは期待できません。

ログデーモンとの通信は良い例です。アプリケーションコンテナの概念に人々が慣れるようになる以外、何も変わることはありません。そして、それが実際に使いたいものかどうかは別ですが:)。多くのシステム管理者は、コンテナ間でパッケージを共有するためのNixOSのようなものとLXC（OSコンテナ）のマッシュアップに興味があるのではないかと思います。私の知る限り、まだ書かれていないだけです。あるいは、より良いLXC。

関連情報