I only played with docker briefly on my laptop, and never in a production system. Do you think there will be any performance hits in a system like this?
RancherOS: An OS for Docker Containers
61–66 of 66 posts
Re: RancherOS: An OS for Docker Containers
#62This is a CoreOS alternative?
Re: RancherOS: An OS for Docker Containers
#63Earlier quoted context omitted.
In my experience it works, but is a mess. You end up with really crazy unit files that aren't actually managing the docker daemon, they're managing the docker client. CoreOS created Rocket in part because the match between docker and systemd is so bad. Rancher seems to be going in the other direction by making Docker support fully native. I do wonder how much this really buys you over a higher level framework like Me…
I wouldn't say the unit files end up "really crazy", but I do agree it is a bit of a mismatch and we lose out on a bit of the advantages of systemd. Re: the post you refer to, I really don't like his proposed solution of "docker attach | docker start | docker run". I usually do this: ExecStartPre=-docker kill %P ExecStartPre=-docker rm %P ExecStart=docker run --rm --name %p ... ExecStop=docker stop %p Of course that…
Simple examples looks fine, but try a setup where you have dozens of environmental variables being set, data volume-containers that need to match the lifecycle of the main container, pulling images that don't exist, ambassadors containers for cross-host linking, and other sidekicks for things like load-balancer registration and health checking. If you look at how Deis does it, they've actually created tons of little binaries to help with different tasks (https://github.com/deis/deis/issues/2254) because the unit files get too crazy by themselves. You end up trying to build a system like Kubernetes using shell scripts and unit files.
The key thing to remember with CoreOS is it puts systemd at the center not docker and only interacts with docker through the client. In fact, there's really zero docker integration besides shipping the binary.
There's also the underlying technical issue around what is PID 1. In your example, you aren't actually monitoring the container, you're monitoring the status of the docker client, which may be different than the docker daemon. For containers, the docker daemon owns the fork rather than systemd. In a system like Kubernetes you have a reconciliation loop that monitors the daemon. You could probably build a similar idea into your unit files to make them more robust, but that's even more complicated.
Having gone down the systemd route it seems like a dead end to me for distributed docker applications. If you believe in a containerized future, then choose an orchestration framework that treats docker as first order primitive. You can still bootstrap this framework using CoreOS/systemd but after that I'd much prefer to just interact with a higher-level system.
Re: RancherOS: An OS for Docker Containers
#64Curious if anyone has come up with a way to run X11 itself in a container? (there are numerous articles on running GUI apps in containers that simply need a way to talk to Xauthority or X socket, or using VNC or xpra). I'd imagine it would need to run privileged with access to device files, or something like that. I've kicked around the idea of a "workstation" set of containers to run on top of CoreOS, but this is th…
I'm starting to wrap some of my pyweek games in Docker because getting all of the pyglet/opengl/avbin dependencies to work correctly is a royal pain in the rear end.
Check out: https://github.com/pdevine/yoyobrawlah
You can use the run_docker.sh script to get things going. The image is also available on Docker Hub, but you need to pass in things like the dri device to get it working correctly.
Re: RancherOS: An OS for Docker Containers
#65I've used coreos and configuring it into clusters was over complicated. So much so that I switched back to ubuntu. Does anyone know how RancherOS compares?
For clustering and management, you might try running RancerOS with Rancher the company's orchestration tool.
Re: RancherOS: An OS for Docker Containers
#66Earlier quoted context omitted.
I wouldn't say the unit files end up "really crazy", but I do agree it is a bit of a mismatch and we lose out on a bit of the advantages of systemd. Re: the post you refer to, I really don't like his proposed solution of "docker attach | docker start | docker run". I usually do this: ExecStartPre=-docker kill %P ExecStartPre=-docker rm %P ExecStart=docker run --rm --name %p ... ExecStop=docker stop %p Of course that…
Simple examples looks fine, but try a setup where you have dozens of environmental variables being set, data volume-containers that need to match the lifecycle of the main container, pulling images that don't exist, ambassadors containers for cross-host linking, and other sidekicks for things like load-balancer registration and health checking. If you look at how Deis does it, they've actually created tons of little…
I don't build any of that into the unit files because I need additional health checking anyway. That the processes are running does not really tell me much useful - a huge proportion of the system failures I deal with are failures where the processes are still running but something else has gone wrong.
For the same reason it doesn't really matter to me if Docker is treated as a first order primitive.