DockerにおけるロギングのSidecarアプローチ

Dockerを使っていて、コンテナの中で複数のログファイルを扱う場合にどうやって一箇所に集めるか？というところでググっていたら、
logglyの↓のブログを見かけて、理解するのに良さそうなので、軽く翻訳チックなことをしてみようと思います。
How to Implement Logging in Docker with a Sidecar Approach

Dockerの世界ではログの一元管理はMust-Haveである

ロギングはあなたのアプリケーション環境を可視化させるという意味で非常に重要でです。もし、数台のマシンのみ日付を超えて保持するようなユースケースの場合、ほとんどのマシンは動的になります。具体的には、あなたのアプリケーションが稼働するクラスタは、マシンがダウンした時のヒーリングを行ったり、マシンを入れ替えたりしてくれます。この場合、sshでマシンに入ってマニュアル的な作業で問題を特定することは現実的ではありません: まずは正確にアプリケーションがどこで稼働していたか特定し、多くの台数のマシンの中からログを取得し、全体像を手に入れる必要があります。つまりコンテナの世界ではログの一元管理はmustなのです。
Logglyは全てのログフローにおける中心になります。どの環境でアプリケーションが稼働していたとしても、そのアイテムを探し出すことを可能にします。ほとんどの場合、アプリケーション開発者はどこでアプリケーションが動いているか気にかけていません; 知りたいのは何が起こったか？なのです。

解決策: アプリケーションとロギングの紐づけ

私のアプローチは、CoreOSクラスタとして稼働するそれぞれのコンテナをLogglyのロギングコンテナと紐付ける、というものです。そうすることで以下のようなことが非常に簡単になります。どのコンテナがログを出力するか、そして、どのファイルがログ出力される必要があるか管理する。アプリケーション/コンテナにタグ付けする。コンテナをstartしたりstopした時にロギングと調和させる。
以下はコンテナ内の1つのアプリケーションに対するDockerプロセスのアウトプットです。

# docker ps
CONTAINER ID	IMAGE	COMMAND	NAMES
20245e614d36	app_x	“./run.sh”	app_x.service
66d3faccb0fa	garland/loggly:latest	“./run.sh”	app_x_logger.service

“app_x”というコンテナを立ち上げたら、同時に”app_x_logger”というコンテナを立ち上げて紐づけます。
CoreOSのクラスタにおけるベストプラクティスは、OSにおいてネイティブな形で何かをインストールする、ということを避けることです。ほとんどの場合アップグレード時に保持されないことになるからです。また、OSをキレイに保つという意味でも私はこれを良いアイデアであると考えます。ファイルベースのロギングをサポートする際に、Docker上で”shared volume”をサポートするコンテナを立てます。このコンテナに関しては、DockerHubのこちらに配置してあるので、是非使ってみてください。

Loggly Dockerコンテナを使うには

はじめるにあたり、アプリケーションのコンテナの名前は”app_x”にします。ログの書き込み先としてコンテナの中に1箇所もしくは2箇所を指定します。後ほどLogglyのロギングコンテナを使って、ここに表示されている全てのファイルをグラブしてLogglyに送ります。

docker run
-d
-name app_x
-v /opt/app/logs
app_x

“-v /opt/app/logs”パラメータに注目ください。これによってDockerはデータボリュームとして公開し、この箇所を他のコンテナからアクセス可能にします。
Logglyのロギングコンテナを立ち上げ、app_xの”データボリューム”を使います。

docker run -d
–volumes-from app_x
—env LOGGLY_TOKEN=
—env LOGGLY_ACCOUNT=
—env USERNAME=
—env PASSWORD=
—env DIRECTORIES_TO_MONITOR=“/opt/tomcat/logs,/var/log”
—env TAGS=“app_x”
garland/loggly

“–volumes-from app_x”に注目してください。このオプションによって、”app_x”で公開された全てのデータボリュームをこのコンテナに紐づけます。”app_x”によってジェネレートされたファイルは、このコンテナからもアクセスすることができます。(詳細に関してはこちらをご覧ください。)
起動すると、Logglyのログコンテナは、Logglyの configure-file-monitoring.sh シェルスクリプトを起動し、設定した全てのディレクトリをログコンテナに追加します。Logglyのデフォルトのセットアップスクリプトを極力使うことで、ご自身でメンテナンスする必要がなくなるのでオススメです。Logglyがバグを修正したり、機能追加をしてスクリプトをアップデートした時は、該当のコンテナは自動的にその反映を取り込むため、特に何もする必要はありません。コンテナに渡された、指定したディレクトリに配置された全てのログ(“DIRECTORIES_TO_MONITOR”)は、シンプルなbashのループによってLogglyに追加されます。

LogglyでのDockerログの解析

簡単にログを検索できるようにするために、全てのログイベントに対してLogglyのタグ付けを行うことをおすすめします。例えば:

tag:app_x*

これによって”app_x”コンテナからのログはタグを使ってpullできるようになります。それぞれアプリケーションと紐づけすることによって、タグを使って特定のアイテムを探し出すことを容易にします。

Conclusion

このセットアップの最も難しいところは、アプリケーションコンテナとロギングコンテナの紐づけのコンセプトによる、sidecarもしくはsidekicksとも呼ばれる構成の構築です。(参考例としてこちらの記事もご覧ください – 2017年2月6日現在ページが表示されませんが…)。一度構築してしまえば、簡単に何度もリユースすることができます。このポイントとしては、ロギングコンテナの存在を忘れてしまえるということです。このDockerとLogglyを使ったアプローチはDevOpsの夢: 一度構築してしまえば常にログとアプリケーションからトラブルシュートを簡単にし、メンテナンスをすることなく全てのアプリケーションに適応することができます。