私は(Debian 8.2に)OpenVPNサーバーをドッキングしようとしました(そうです、確かに、そのようなコンテナーは既にあります)コンテナー内で何か問題が発生し、サーバーを起動できませんでした。
ログを調べることにしましたが、/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
質問は次のとおりです。
OpenVPNがHost Debian 8.2へのデフォルトのインストール後にsyslog
にログを記録し、コンテナー内でログを記録しないのはなぜですか? OpenVPNログをsyslog
に強制するようにホストマシンで何も設定していません。これはデフォルトの動作でした。
Dockerコンテナー内で実行されているOpenVPNサーバーのログを構成するにはどうすればよいですか?
OpenVPNは、起動するものが何もないため、そのDockerfileで起動しません:-)。エントリポイントはsh
です。実行するのはそれだけです。
Docker内で2つのデーモンを開始する場合、エントリーポイントは両方のデーモンを開始するプログラムである必要があります。多くの人がこれにsupervisord
を使用しています。 Dockerは比較的独断的なソフトウェアであり、1つのコンテナで複数のデーモンを実行することは慣用的とは見なされないことに注意してください。
これがデバッグに関するものであれば、問題はありません。 openvpn
を--daemon
または--log
とともに実行しないでください。 stdoutに書き込みます(申し立てによると、stderrが表示されても驚くことはありません)。これは、手動で開始した場合のデバッグに最適です。ターミナルにすべてのログメッセージがすぐに表示されます。
エントリポイントを設定し、手動でコンテナをインタラクティブモードで起動した場合-同じことです。これをバックグラウンドコンテナーとして起動すると(あいまいさを許します)、docker logs
の出力がキャプチャされます。これは、systemd(およびsystemdの「ジャーナル」ロギングシステム)などの最新のinitシステムが好む手法と同じです。
デーモンを希望どおりに設定したら、他の回答のように、ログをキャプチャするためのよりカスタマイズされたシステムに興味を持つかもしれません。
docker logs
のマンページによると、Dockerにはプラグ可能なロギングドライバーがあります。ホストSyslogに書き込むと表示する「syslog」ドライバーがあります。docker logs
が機能しないと表示されますが、それが問題になることはないと思います。
[〜#〜]警告[〜#〜]:docker logs
は、journaldロギングドライバーを使用する場合に機能します。ただし、Debianのデフォルトでは、これは再起動時にログが失われる原因になると想定しています。 Debianは永続的なジャーナルを設定しないからです。それがあなたが望むものであるならば、しかし、それを変えることは難しくありません。
docker logs
コマンドをサポートする他のロギングドライバーは「json-file」と呼ばれます。私はそれが持続することを期待しますが、他の解決策の1つを好むかもしれません。
要点は、Dockerコンテナーは、基盤となるOSと必ずしも同じように機能するとは限らないということです。 Dockerは、LXC
、systemd-nspawn
などのOS仮想化や仮想マシンではありません。 DockerはLXC
から派生したものですが、単一のプログラムを実行する「アプリケーションコンテナー」用に特別に設計されました。
(現在の)サーバー配布は、いくつかの実行中のプログラムの組み合わせとして設計されています。したがって、それらからパッケージを取得して、これらのアプリケーションコンテナーの1つ内でまったく同じように動作することを期待することはできません。
ロギングデーモンとの通信が良い例です。アプリケーションコンテナーの概念をよりよく理解できるようになることを除いて、変更点はありません。そして、それが彼らが実際に使用したいものかどうか:)。多くのシステム管理者はLXC(OSコンテナー)のマッシュアップにもっと興味があると思います。コンテナー間でパッケージを共有するNixOSのようなものがあります。まだ書かれていないだけです。または、単に better LXC です。
Logglyを見てください- https://www.loggly.com/docs/docker-syslog/ またはfluentd- http://www.fluentd.org/guides/recipes/ docker-logging 。