3 ms·

Maybe that is how the init you linked works, but the docker instructions take you through the basics of setting up an Ubuntu image, where upstart is used (not s

by yebyen 13y ago

Maybe that is how the init you linked works, but the docker instructions take you through the basics of setting up an Ubuntu image, where upstart is used (not sysvinit) and if you stray off the path, or try to upgrade the base image to a newer release, you find very quickly that upstart does not tolerate running in a container very well, and that a lot of things expected it to be running, you'd have to work around it. The OP is targeting Ubuntu users (or users of the 'base' image distributed in the docker registry.) Not to mention, Docker places its own hooks in /sbin/init (still true?) so if you had an init that you wanted to run, you had better put it somewhere else inside of your image, because the file will be overriden when your app container starts. This is a good discussion that starts in about the same place: https://github.com/dotcloud/docker/issues/223 https://github.com/dotcloud/docker/issues/223

peterwwillis 13y ago
Oh jesus that's a huge mess. So I guess it turns out Docker was designed to do a bunch of wacky things under the hood because they never expected users to use their tool in different ways. It looks like as a fix some people are running full-blown copies of Ubuntu under Docker (because somehow that's better than OpenVZ??)
- yebyen 13y ago
  I'm not sure how you infer this from what I said? Even Ubuntu have plans to ditch upstart long-term, following Debian's lead to adopt systemd. Nobody is running "full-blown copies of Ubuntu" under docker, because full-blown would imply "with upstart" and using your distributions' built-in /sbin/init is precluded by the fact that docker overrides it, and also that Upstart doesn't work well in a container. So people are running parts of Ubuntu without understanding that sometimes those parts had expectations of being child processes of upstart, and that upstart would always be running, when in docker-land that's not a reasonable expectation (and OP addresses this by adding in a more reasonable init, which probably handles most of these concerns.) I just built the baseimage-docker, trying to get into it with ssh now, I can't imagine giving anyone a container and not letting them ssh into it, and I've added ssh to containers before in a way that I knew was non-supported or broken, so it's good to have this example. It looks like they are indeed doing it right.
- yebyen 13y ago
  I think that some time since the issue I linked you from ~11 months ago, they stopped overriding /sbin/init and started putting their hooks in /.dockerinit instead, since many folks tend to put something they care about in /sbin/init. Here's the reference: https://github.com/dotcloud/docker/pull/898 https://github.com/dotcloud/docker/pull/898 So yes, there is some mess associated with changing your way of business over to doing containers, but a lot of these problems have been solved in one way over six months ago. We're left arguing about the people who didn't catch the solution, don't know the expected way of doing things, haven't RTFM'ed or just aren't interested in making permanent solutions out of their docker containers. That is one of the strengths; docker lowers the cost of deployment (in test) when you can take an image that solves only the problem you care about and deploy it into a disposable container. You will always get the occasional "I want to put this in docker" from someone who maybe isn't understanding, and of course some times that person is your boss. Then sometimes what they're asking for is perfectly reasonable like "let's use it for an SSH forwarding endpoint". Docker (and CoreOS) certainly put some hurdles in front of generally easy and perfectly normal ideas, for better or for worse. Your first challenge in this case will be to get your container listening on a port 22 of some public interface somewhere, since containers are designed not to be exposed like that until you RTFM; you know whose fault it will be when something is badly configured after you just went and skipped ahead to the section on forwarding ports without spending time on the rest of the instructions at all. They are definitely curating the GitHub Issues database, you have to give them that.
  - yebyen 13y ago
    And as long as we're linking to the source code of init apps: https://github.com/dotcloud/docker/blob/master/dockerinit/dockerinit.go https://github.com/dotcloud/docker/blob/master/dockerinit/do...

by yebyen 13y ago

peterwwillis 13y ago

Oh jesus that's a huge mess. So I guess it turns out Docker was designed to do a bunch of wacky things under the hood because they never expected users to use their tool in different ways. It looks like as a fix some people are running full-blown copies of Ubuntu under Docker (because somehow that's better than OpenVZ??)

yebyen 13y ago
I'm not sure how you infer this from what I said? Even Ubuntu have plans to ditch upstart long-term, following Debian's lead to adopt systemd. Nobody is running "full-blown copies of Ubuntu" under docker, because full-blown would imply "with upstart" and using your distributions' built-in /sbin/init is precluded by the fact that docker overrides it, and also that Upstart doesn't work well in a container. So people are running parts of Ubuntu without understanding that sometimes those parts had expectations of being child processes of upstart, and that upstart would always be running, when in docker-land that's not a reasonable expectation (and OP addresses this by adding in a more reasonable init, which probably handles most of these concerns.) I just built the baseimage-docker, trying to get into it with ssh now, I can't imagine giving anyone a container and not letting them ssh into it, and I've added ssh to containers before in a way that I knew was non-supported or broken, so it's good to have this example. It looks like they are indeed doing it right.
yebyen 13y ago
I think that some time since the issue I linked you from ~11 months ago, they stopped overriding /sbin/init and started putting their hooks in /.dockerinit instead, since many folks tend to put something they care about in /sbin/init. Here's the reference: https://github.com/dotcloud/docker/pull/898 https://github.com/dotcloud/docker/pull/898 So yes, there is some mess associated with changing your way of business over to doing containers, but a lot of these problems have been solved in one way over six months ago. We're left arguing about the people who didn't catch the solution, don't know the expected way of doing things, haven't RTFM'ed or just aren't interested in making permanent solutions out of their docker containers. That is one of the strengths; docker lowers the cost of deployment (in test) when you can take an image that solves only the problem you care about and deploy it into a disposable container. You will always get the occasional "I want to put this in docker" from someone who maybe isn't understanding, and of course some times that person is your boss. Then sometimes what they're asking for is perfectly reasonable like "let's use it for an SSH forwarding endpoint". Docker (and CoreOS) certainly put some hurdles in front of generally easy and perfectly normal ideas, for better or for worse. Your first challenge in this case will be to get your container listening on a port 22 of some public interface somewhere, since containers are designed not to be exposed like that until you RTFM; you know whose fault it will be when something is badly configured after you just went and skipped ahead to the section on forwarding ports without spending time on the rest of the instructions at all. They are definitely curating the GitHub Issues database, you have to give them that.
- yebyen 13y ago
  And as long as we're linking to the source code of init apps: https://github.com/dotcloud/docker/blob/master/dockerinit/dockerinit.go https://github.com/dotcloud/docker/blob/master/dockerinit/do...