Dockerとログ

ログをどう運用するか?

ログは大事だ。Dockerで構築した環境の場合、どのように保存して管理していくか考えてみたい。

方式をリストアップ

選択できるログの運用方法をリストアップしてそれぞれについての利点等を考えてみる。自分が全く知らない方法があるかもしれないがそれはご了承いただきたい。

1. まずアンチパターン

最近久しぶりに目にしたがこちらの記事にも記載があるのだが、ログをそのままコンテナ内に保存するのは当然良くない。

コンテナにデータを保存しない

よほどの自信がある時以外は、Dockerコンテナ内にデータを保存するのはやめましょう。動作中のコンテナを誤って止めてしまうと、そのデータは永遠に失われてしまいます。データを管理するのであれば、共有ディレクトリのあるホストに直接、保存した方が安全ですし簡単です。

ログに関しては、ホストの共有ディレクトリか[logstash](http://logstash.net/)やpapertrailのようなリモートのログ収集サービスを使うといいでしょう。

引用:Dockerにまつわる誤解とベストプラクティスについて

自分はコンテナをストップするとデータは全て消えるものだと勘違いしていたので、そもそもこの選択肢は無いと思っていたというのは余談として、ちゃんとコンテナやDockerホストが壊れてしまったときのことを考えておきましょう。

2. Volumeマウントする方式

この方式は、必要なコンテナ側のログ出力ディレクトリとDockerホスト側のディレクトリをVolumeマウントしておく方法です。 実現には比較的簡単な方法といえるでしょう。ただ、保存しておくログのディレクトリがいっぱいあったりすると面倒な為、Dockerベースとした構築を前提としている場合、アプリケーションを設計するときからこの辺りは少し考慮しておく必要がありそうです。

オンプレミスでサーバーを管理していた頃は、syslog周りもちゃんと把握しておくようなイメージがありましたが、クラウド+Dockerで考えたときにsyslogが全く無いのは困るかもしれませんが、あまり見る機会がなさそうな感じがします。ハードが壊れているとかであれば捨てればいいわけです。ただ、「スケーラブルな設計となっていれば」というのが前提ではありますが。

また大事なのはログをコンテナの外に出すことは簡単ですが、さきほど言ったようにスケーラブルな構成ですとそのホストもいつ死んでも大丈夫なようにもっと安全な場所へ退避しておくことが必要となるでしょう。

AWSならS3に退避したり、Fluentdでログをどこかへ集約したり、この辺りの選択肢は環境によっていろいろありそうです。

3. ログドライバを使う方式

まだちゃんと把握できていない領域。

Docker 公式 Configure logging driver

logオプションをjson-fileを指定すると、docker logs [ContainerID]でログを確認することができるのだが、fluentdオプションが使えるようになったのは確か1.8系から。(というか早すぎて追いつくのが大変)

ログをコンテナ内に保存せず、Fluentdに処理させるといった考え方としては簡単なのだが、どのログにどのタグをつけたりといったことが想像がつかない。 もうちょっとこの辺はまだ深掘りする必要がありそうだし、journaldというキーワードも気になるところ。

4. その他

ここに記載する内容は面白そうだったのでメモしておく程度。実際にやったことがないので利点やら短所などはよくわかりません。

まとめ

  • ちゃんとログ運用を考えないなら、最低限、ログの出力ディレクトリは1つにまとめておく
  • まとめておけばホスト側にマウントして外部へ吸い出す。自作するなら、Fluentdとか使いたくなる。

ログは保守程度であればいうほど見る機会は少ないですが、解析系に使うようになると非常に重要で後々面倒なことにならないように先を見据えた設計にしておきたいですね。