-
Notifications
You must be signed in to change notification settings - Fork 5.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Order of containers starting up? #235
Comments
Containers start in dependency order. E.g.
|
There are however situations where containers e.g: skydns cheers James Mills / prologic E: [email protected] On Thu, May 29, 2014 at 2:31 AM, Ben Firshman [email protected]:
|
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? |
I'm thinking it would be nice to use an OrderedDict (Reglardless of links, etc) cheers James Mills / prologic E: [email protected] On Thu, May 29, 2014 at 8:30 PM, Ben Firshman [email protected]
|
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. |
👍 I would lover ordering and if there was some sort of health checking before it moved on to the next container |
will |
@anentropic yes, it will. |
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"? |
+1 |
@hamiltont i wrap fig in a bash script and use this function: wait_for_endpoint() { |
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. |
Any comment on the dependency ordering that does not involve link or volumes from? |
+1 for explicit dependencies not related to any docker specifics. In addition, startup waiting time would be very much appreciated among with dependencies. |
Adding an extraneous |
This would be addressed by #686 |
@mbdas If I have it right, you're asking for a different kind of dependency ordering.
You're asking for the ability to express dependencies between long-running and ephemeral containers, where an ephemeral container needs to be created, started and finish running before a long-running container is created. Is that right? |
Both actually. So, you got it right on the ephemeral containers which is a common patter for data volume update containers for example. So, looking for generic on-exit keyword where a target container can start on successful exit of a list of containers. The second use case is a dependency between long running containers where the target container starts on successful health check condition (user supplied say with basic defaults) of the other long running containers. Link does not help in ensuring health checks and workarounds are not clean. |
My reluctance regarding the second use case boils down to: I don't think health checks should be Compose's job. In a robust distributed system, the services themselves are responsible for checking their dependencies, retrying, backing off etc. You wouldn't deploy a web app to production that refused to start if the database wasn't ready yet, and since half of the point of Compose is to close (or narrow) the gap between development and production, I don't think it's good to add complexity for the sake of enabling bad practices. I'd prefer if Compose did no ordering at all, but the way Docker is set up (container config being immutable) it's unfortunately necessary to force an ordering just so we can actually create the containers. |
There is a difference between deploying and using something in dev. One On Thursday, February 26, 2015, Aanand Prasad [email protected]
|
Fair enough, but we're planning to take Compose beyond just development environments - see the roadmap. Can you show me a use case where putting the logic in the container is significantly more hassle than getting Compose to do it? |
Most of that roadmap is dev oriented which is awesome. Helping people dev I'll think about it more, maybe will just write scripts to wait as you say. My feedback: keeping compose dev oriented seems great to me. Vagrant had On Thursday, February 26, 2015, Aanand Prasad [email protected]
|
+1 Check out this quote from the 'mysql' repo:
This is a showstopper for me for docker-compose, unf |
I regularly use docker-compose with mysql, but I don't use that image. You probably want to extend that image, and create your database and tables as part of the "build" step. That way the work is cached, and you don't have to repeat it every time you start up your container. Any other container using the mysql image just needs to retry until the container is available. It needs to do that to be resilient to network failures anyway. https://github.com/dnephin/readthedocs.org/blob/docker_compose/dockerfiles/database/Dockerfile is an approximate example of that setup using postgresql, it should be similar for mysql. |
+1 for depends_on. |
When possible I'm using some kind of 'test/retry connection test' with the service that a given container/service depends on. To workaround this limitation (service startup ordering/dependency), in my container's service startup script (eg: run.sh) I use this snippet of code to wait for: https://gist.github.com/rafaeltuelho/aff24eefe8c6e48a6b49 |
is the startorder with "links" just an order or is compose really checking if the linked container (db) is in status "running" and only then starts the other one (web)? something like
would be nice as a user of marathon i like how dependencies was solved https://mesosphere.github.io/marathon/docs/deployments.html |
There's a bunch of interesting discussion in this ticket, but it's unfortunately not terribly related to the original question. Service ordering is currently based on links and volumes_from because that's a hard requirement for docker, but I don't think "order" fully describes the concern. The concern is more about availability, which is covered by #374. I'm going to close this ticket, as I think it overlaps with #374. If you feel there are issues unrelated to those ticket, please feel free to open a new issue. |
Use the new runtime update command to process UpdateResources requests
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
The text was updated successfully, but these errors were encountered: