Hacker News Reader

Comment by mmerickel | Hacker News Reader

If this is an RC, will docker have a way in 1.0 to properly handle stdout/stderr logs captured on the host without just allowing a giant json file to fill up? I'm not aware of a way to do it right now without handling logs in the container and avoiding the container's stdout/stderr.

View on HN

The best solution I've seen so far is bind mounting /dev/log to a syslogd on the host and making sure everything in the container logs to syslog.

I would be pretty happy if Docker just had a simple implementation of /dev/log by default, so containers could rely on it being there. Then you could easily redirect everything to a production grade syslogd.

There was quite a bit of discussion on this topic in the Docker-dev group. The comment I found the most informative was by the creator of Docker -> https://groups.google.com/d/msg/docker-dev/3paGTWD6xyw/xj2Xa...

Yes, I've read all of that. I consider this a blocker for production use of docker and releasing a 1.0 RC without solving this is disconcerting (at least as a process wrapper, it still works fine for wrapping an init system that handles everything itself). Especially since, in that thread, shykes said it will be solved prior to 1.0.

You're right, the logging subsystem still needs work before 1.0. We're using the RC label to indicate that we don't plan on breaking APIs and file formats in any major way between now and 1.0, so toolmakers and integrators can start locking down their schedule, and trust that their tools won't be deprecated in a couple months.

If it were entirely up to me I would never call it 1.0, because part of me wants it to be flawless before anybody uses it in production. But it's not up to me - a lot of people are already using Docker in production, and there are many organizations already in process of offering commercial support and services for it. Clearly they consider Docker acceptable for their needs at some level - and at some point we'll need to acknowledge that by releasing 1.0, no matter how flawed I find it to be. The improvements won't stop at 1.0 :)

That's great to hear - I've dove pretty hard into docker and love it but the logging story has been a dealbreaker for production. Decoupling "create" and "start" has been great when using the Remote API because I can create a container, attach my IO handlers, and then start, removing the need for docker to handle the logs at all (if it supported that). Possibly something like this can be done via the CLI such that docker can just forward the streams into a custom script.

Reply on news.ycombinator.com