コンテナ内のプロセスのログ出力先を標準出力/標準エラー出力に設定する方法


はじめに

Docker を利用している場合、コンテナ内で動作しているプロセスのログは標準出力/標準エラー出力に出力させるのがベストプラクティスだと言われています。
(Docker が、コンテナの標準出力/標準エラー出力をログとして記録するため)

すでに Docker 環境を利用している方からすれば基本中の基本だとは思いますが、自分の備忘録という意味も込めてコンテナの各種プロセスのログ出力先を標準出力/標準エラー出力に設定する方法を今回は 2パターン(他にも設定の仕方はあるかもしれませんが下記2パターンで選択肢としては個人的には十分かと思います)のアプローチを紹介します。

設定のアプローチ

Docker のバージョンやホスト OS のバージョンによって設定方法が変わるわけではないので環境の記載は割愛します。

  • 今回は、例として Nginx に対してログ設定を行います

アプローチ ①(スペシャルファイルを指定)

まず、1 つ目のアプローチはシンプルに各種サービスの config ファイル内で設定できるログ出力先を標準出力/標準エラー出力のスペシャルファイルに指定する方法です。

nginx.conf
access_log  /dev/stdout  main;
error_log   /dev/stderr  warn;

特に工夫もなく本当に直接指定しているだけです。

アプローチ ②(シンボリックリンクを貼る)

2 つ目のアプローチは、標準出力/標準エラー出力のスペシャルファイルに対して各種サービスで指定したログファイルのシンボリックリンクを貼る方法です。

公式の Nginx の Docker イメージはこちらの方法で設定されているので公式の Docker イメージを利用して確認および紹介したいと思います。

まずは、公式の Nginx の Docker イメージを利用してコンテナを作成します。

$ docker run -d --rm nginx
4a285282d8a198b64e4d655c9e522a2a44fbb7198fe7c8f07affc26e365eb9b5

作成したコンテナの nginx.conf の内容を確認してみます。

$ docker exec -it 4a285282d8a1 cat /etc/nginx/nginx.conf

user  nginx;
worker_processes  1;

error_log  /var/log/nginx/error.log warn;
pid        /var/run/nginx.pid;


events {
    worker_connections  1024;
}


http {
    include       /etc/nginx/mime.types;
    default_type  application/octet-stream;

    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';

    access_log  /var/log/nginx/access.log  main;

    sendfile        on;
    #tcp_nopush     on;

    keepalive_timeout  65;

    #gzip  on;

    include /etc/nginx/conf.d/*.conf;
}

アクセスログとエラーログの出力先は下記の通りに設定されています。

  • アクセスログ
    • /var/log/nginx/access.log
  • エラーログ
    • /var/log/nginx/error.log

次に、/var/log/nginx/のディレクトリ内容を確認します。

$ docker exec -it 4a285282d8a1 ls -l /var/log/nginx
total 0
lrwxrwxrwx 1 root root 11 Dec 29 03:31 access.log -> /dev/stdout
lrwxrwxrwx 1 root root 11 Dec 29 03:31 error.log -> /dev/stderr

すると、スペシャルファイルに対してシンボリックリンクが貼られていることが確認できます。

おわりに

既存システムの移行等を考慮すると、サービス自体には手を加えないパターン ② の方が好ましいと思います。
環境等に合わせて選択をしてみてください。