Order of containers starting up?

[prologic]

Does fig starts containers in the order as
written in the fig.yml? If not is it meant to?

I've run into an issue where I need one or two
containers to start before others.

Related but different Issue: #74

[bfirsh]

Containers start in dependency order. E.g.

web:
    build: .
    links:
     - db
db:
    image: orchardup/postgresql

db will start before web. Is there a case where you'd want another ordering?

[prologic]

There are however situations where containers
do not depend (link) with one another.

e.g:

skydns
skydock
hipache
... etc ...

cheers
James

James Mills / prologic

E: prologic@shortcircuit.net.au
W: prologic.shortcircuit.net.au

On Thu, May 29, 2014 at 2:31 AM, Ben Firshman notifications@github.comwrote:

Containers start in dependency order. E.g.

web:
build: .
links:
- db
db:
image: orchardup/postgresql

db will start before web. Is there a case where you'd want another
ordering?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/235#issuecomment-44431687
.

[bfirsh]

Perhaps you could create a fake link between the two services? That's quite a nice way of explicitly saying that one service depends on another.

Alternatively, we could add some other option? Or perhaps boot them up in the order they are specified in the configuration file?

[prologic]

I'm thinking it would be nice to use an OrderedDict
when reading and parsing the YAML sot ath the
order you specify the services are they order they start.

(Reglardless of links, etc)

cheers
James

James Mills / prologic

E: prologic@shortcircuit.net.au
W: prologic.shortcircuit.net.au

On Thu, May 29, 2014 at 8:30 PM, Ben Firshman notifications@github.com
wrote:

Perhaps you could create a fake link between the two services? That's
quite a nice way of explicitly saying that one service depends on another.

Alternatively, we could add some other option? Or perhaps boot them up in
the order they are specified in the configuration file?

—
Reply to this email directly or view it on GitHub
#235 (comment).

[defunctzombie]

Fake links are not possible when using the "net: host" option because docker will not launch containers with net host and links. The two features are mutually exclusive.

[nicgrayson]

👍 I would lover ordering and if there was some sort of health checking before it moved on to the next container

[anentropic]

will volumes_from enforce dependency order too, like links does? I guess it needs to, just checking as maybe I can remove dummy links from my fig.yml

[aanand]

@anentropic yes, it will.

[hamiltont]

To make this issue actionable, I'd propose that this be added to fig's website. The automatic dependency handling, based on (from this discussion) links and volumes, is definitely worth mentioning in the documentation.

Also, is there any lifecycle checking for containers (like mongodb) that take some time between "the container run command returned" and "the container is ready to be used because port X is responding"?

[baptistedonaux]

+1

[nicgrayson]

@hamiltont i wrap fig in a bash script and use this function:

wait_for_endpoint() {
until $(curl --output /dev/null --silent --head --fail $1); do
printf '.'
sleep 5
done
printf "\n"
}

[arun-gupta]

There could be a dependency where a container publishes REST endpoints that may be needed for other containers. Linking may not be necessary, but defining an order would be important in that case.

[mbdas]

Any comment on the dependency ordering that does not involve link or volumes from?
Also the pattern mentioned from docker guys involving config volume containers to have config update containers to be consumed by app containers and in this case both the update container and app container will have volumes_from but the update container needs to run and finish first before app container runs. In terms of ordering there can be 2 use cases. One where one container exits before other runs and in other case the second may run on good health check of first.