Re:How We Use Docker For Continuous Delivery – Part 2
by AdamMeghji on Monday June 09, 2014 @02:29PM
(#7869719)
Install the tools you need via the Dockerfile (iostat, top, atop, etc.), and an sshd. Then, instead of running the single web process, run supervisord via CMD, which will subsequently launch both your web app process, AND sshd. From there, EXPOSE 80 22, and you can SSH into the container to run any perf analysis tools as usual.
EXPOSE 80 22; CMD ["/usr/bin/supervisord"]
Re:How We Use Docker For Continuous Delivery – Part 2
by fsaintjacques on Monday June 09, 2014 @01:17PM
(#7869340)
Couldn't you just connect to the master host? I'm not sure how namespacing is done inside the kernel, but I would assume that the host would have access to containers info.
Re:How We Use Docker For Continuous Delivery – Part 2
by ah- on Monday June 09, 2014 @02:01PM
(#7869588)
Yes, at least with raw lxc containers that's the case. You can simply see the processes in the container in the host top.
Re:How We Use Docker For Continuous Delivery – Part 2
by dorfsmay on Tuesday June 10, 2014 @12:30AM
(#7871841)
Yes, you can, but then it means you need to keep track of which master your dockers are running on.
Re:How We Use Docker For Continuous Delivery – Part 2
by fsaintjacques on Tuesday June 10, 2014 @02:13PM
(#7874324)
It's either tracking the slave you're on, or repackaging the whole linux userland in your container. I'd go for the first one.
In a classic "apps run on a known instance" model, when the instance starts having performance issues, I can ssh to it and use the usual tools (iosat, top, atop, netstat, etc...). With docker, how do you correlate instance/docker, and do perf analysis?