fluentd-address i/o timeout when using links instead of host

[nritholtz]

My environment:

$ docker -v
Docker version 1.8.3, build f4bf5c7

$ docker-compose -v
docker-compose version: 1.5.0dev

I've created a test repo to reproduce this issue.

When using links for connecting a sample web app to a fluentd container, and using the fluentd-address to refer to this link, I am getting the following error:

sample_fluentd_compose nritholtz$ docker-compose up
Creating samplefluentdcompose_log_1
Creating samplefluentdcompose_web_1
Cannot start container ca26fe06dd7e4d63b401b12203f5670a8b95fa0c50793fb4ab5e1ec052c4cd30: Failed to initialize logging driver: dial tcp 198.105.244.74:24224: i/o timeout

However, when exposing the fluentd container port to host and then connecting via localhost, it works just fine.

[dnephin]

I'm not sure I understand the config. Could you provide a sample docker-compose.yml ?

[nritholtz]

There's a sample docker-compose.yml inside the test repo.

[dnephin]

Ah sorry, I missed that link.

I see what you're trying to do. I think the problem is that links only expose the container IP of one container to another container. But the docker daemon is actually what's handling the logs (not the container). So the link doesn't actually do what you want.

I don't know if anyone has considered this case before, but as far as I know, it's not expected to work. You'd have to start the fluentd image as a container first. Then make it available to the docker engine somehow (either by just querying for the ip, or running some form of docker-dns service).

The host needs to be able to access the fluentd-address, not just the container.

[dnephin]

Another option would be to not using a log driver at all and have the application log to fluentd directly.

[nritholtz]

Spot on. Thanks for the clarification.

I'm really going for a "cluster" based solution for my application containers. I was super excited to see that there was support for log-drivers, since we were kind of in a discovery phase for how to log to services like AWS Cloudwatch, however, since for us there can be multiple container clusters (each potentially with different logging requirements) within a single host, I'd like to avoid any changes at the daemon/host level.

TLDR; I'm looking to configure application logs settings/driver/forwarding on a "cluster" level, and not on the host level.

[dnephin]

I think that's an interesting use case, and probably pretty common. We should keep this open and see if we can find a way to make it work.

[vaidas-lungis]

+1

[dnephin]

This issue is a duplicate of #2657. Since that issue has an minimal example right in the description I'm going to close this one and use that issue to track the problem.

Thanks for the report!