<p><a href="https://forums.rancher.com/t/start-order-of-stack-containers/3106/9" rel="nofollow noreferrer">https://forums.rancher.com/t/start-order-of-stack-containers/3106/9</a></p>

<blockquote>
  <p>We do not support depends_on, and neither does Docker in Swarm mode.
  It is not a real solution to the problem anyway and leaves you with
  unhandled pointy-edge cases when failures occur and containers are
  being replaced. Your services should know how to either wait for their
  dependencies or exit and be rescheduled to retry.</p>
</blockquote>

<p>I agree with this comment. Services should always be able to start. Imagine that one service goes down then another service will not work anymore.</p>

CC BY-SA 3.0
2017-09-15T09:23:38.213Z
and what if "my services" are 3rd party well-known apps... like Solr for example?
Ta Mu
CC BY-SA 3.0
2017-09-15T09:25:22.220Z
Could you elaborate the current situation? So what is the current order of apps that need to be restarted and why do some services needed to be started first. Could you include this information in the question?
030
CC BY-SA 3.0
2017-09-15T09:34:46.290Z
I must admit we have to change our setup. Within solr container, we had sometimes configuration loaded after it is required, I did not know that. Thx - still I will give a note on other generic problem because of load peak as all services run sumulateneously.
Ta Mu
CC BY-SA 3.0
2017-09-15T09:21:19.250Z
2017-09-15T09:21:19.250Z
030
<p>AFAIK you cannot influence the order how Docker Swarm starts containers for services.</p>

<p>Is that possible with:</p>

<ul>
<li>Mesos?</li>
<li>K8s (Kubernetes)?</li>
<li>Rancher?</li>
<li>Other?</li>
</ul>

<p>This question is not about specific orchestration of dependent services but the problem that if you run 10 services each with one JVM this creates a load peak. The system slows down and you need complex loops to wait for other services.
Are there any mechanisms known in other orchestration concepts to manage the startup somehow? </p>

<p>For example, in completely other domain, in JMeter you can tell a timeframe in which a thread group will start. So could I say "try to start this service with some offset"?</p>

<containers><cloud><orchestration>
Defined start sequence of containers
Ta Mu
# Defined start sequence of containers

(Asked by: username_0 on 2017-09-15)

AFAIK you cannot influence the order how Docker Swarm starts containers for services.

Is that possible with:

* Mesos?
* K8s (Kubernetes)?
* Rancher?
* Other?

This question is not about specific orchestration of dependent services but the problem that if you run 10 services each with one JVM this creates a load peak. The system slows down and you need complex loops to wait for other services.
Are there any mechanisms known in other orchestration concepts to manage the startup somehow?

For example, in completely other domain, in JMeter you can tell a timeframe in which a thread group will start. So could I say "try to start this service with some offset"?

**Tags:** containers, cloud, orchestration


---

## 1 answers

### Answer by username_1 on 2017-09-15. Score: 4 | Accepted answer

<https://forums.rancher.com/t/start-order-of-stack-containers/3106/9>

> We do not support depends\_on, and neither does Docker in Swarm mode.
> It is not a real solution to the problem anyway and leaves you with
> unhandled pointy-edge cases when failures occur and containers are
> being replaced. Your services should know how to either wait for their
> dependencies or exit and be rescheduled to retry.

I agree with this comment. Services should always be able to start. Imagine that one service goes down then another service will not work anymore.

> **Comments:**
> **username_0**: and what if "my services" are 3rd party well-known apps... like Solr for example?  
> **username_1**: Could you elaborate the current situation? So what is the current order of apps that need to be restarted and why do some services needed to be started first. Could you include this information in the question?  
> **username_0**: I must admit we have to change our setup. Within solr container, we had sometimes configuration loaded after it is required, I did not know that. Thx - still I will give a note on other generic problem because of load peak as all services run sumulateneously.  

---

