Proposal: Boot order because of swarm /w overlay

[emilebosch]

Overlay networking /w swarm uses and modifies /etc/hosts in order to do container discovery and update the containers , when boot order isn't honored ts means that the web container can be booted before the db, and then can never reach the DB. (Because swarm didn't update the /etc/hosts because it aint booted yet).

In other words. docker swarm just made boot order important, links are of no use in a swarm so lets fix this for once. I've seen many duplicates on this. But not regarding swarm.

[mavenugo]

@emilebosch

• In docker 1.9.x, the /etc/hosts updates doesn't depend on container bootup order. Regardless of the order in which the containers are brought up, the /etc/hosts were updated in the dependent containers.
• with the upcoming docker 1.10, overlay networking in docker engine will use embedded DNS instead of /etc/hosts updates for service discovery. So no more /etc/hosts updates.

In other words, by design docker swarm and multi-host networking has no boot order dependencies that we are aware of. Please let us know if there is a specific issue that you are hitting.

[emilebosch]

Good to hear. I am using 1.9. And it seems that my app (rails) starts, can't read in the hosts and then decide to quite after some time (with no route to host) Even if 1.9 would update the hosts afterwards it wouldn't matter because the app already gave up with no route to host (many legacy apps will do this anyway). Specifying boot order wouldn't be a bad idea in general though. Is there any reason why this isn't just in the order specified in the YAML file?

I am happy however that 1.10 is going to solve it with built in DNS any way i can try this out now?

[mavenugo]

@emilebosch you can try the embedded DNS solution in the newly released Release-Candidates (you can download them from https://releases.dockerproject.org/).

But, regardless of DNS or /etc/hosts, the bootup order dependency of the application is a different issue.
Are you trying compose as your front-end and expecting the bootup order to be specified in the compose YAML file ? In that case, we have to take up the discussion in https://github.com/docker/compose/.

[dnephin]

Ordering would not fix this issue. Your application needs to retry until the host is available. It would be even better if it retried on every request, instead of assuming the connection is available when the application starts.

We already have a few issues open for ordering (#2682, #2619, #2614, #686) and delayed startup (#374), so I'm going to close this one