更新:現在gliderlabs/logspout
コンテナは最初に接続した後ロギングを停止しているように見えます。結果のための多くのグーグルの後(タイムアウト/再接続の問題の束を指しているようだ)。私は代わりにドッカーの--log-driver
オプションに移動することに決めました。これはすべてのマシンに触れ、デーモンを再起動することを意味しましたが、私のubuntuインスタンスに/etc/default/docker
ファイルを編集してドッカーを再起動するという苦労は別として、サービスの中断はありませんでした。
オリジナルの答えthis article by Sematextにおける研究の華麗な作品に
おかげで、私は魔法のbindコマンドを発見:
docker service create --name logspout \
--mode=global -e SYSLOG_TAG=swarm --publish <yourport>:<yourport> \
--mount type=bind,src=/var/run/docker.sock,dst=/var/run/docker.sock \
gliderlabs/logspout syslog+tls://<yourhost>.papertrailapp.com:<yourport>
魔法が--mount type=bind,src=/var/run/docker.sock,dst=/var/run/docker.sock
コマンドです。 SYSLOG_TAG
を使用すると、デフォルトでホスト名がコンテナID(変更可能であり、むしろ不透明)であるため、あなたの群からのものとしてsyslogを識別することも有利です。ロギングのロギングポートを公開/公開する必要があるように見えます。
私は群れにノードを追加する場合は、このサービスは自動的に新しいホストに展開され、構成されています!群れの魔法!あなたが読みやすい形式
でコンテナIDと群れの識別子を見ることができます
Sep 29 17:07:01 8d551da912a4 swarm: File "/opt/conda/envs/clientapi/lib/python3.5/site-packages/werkzeug/exceptions.py", line 646, in __call__
Sep 29 17:07:01 8d551da912a4 swarm: raise self.mapping[code](*args, **kwargs)
Sep 29 17:07:01 8d551da912a4 swarm: werkzeug.exceptions.InternalServerError: 500: Internal Server Error
Sep 29 17:11:05 cd73e5278032 swarm: ....................
Sep 29 17:11:05 cd73e5278032 swarm: complete: opportunities = added 0 updated 0 out of 2023