<p>This question is discussed many times but I'd like to hear some best practices and real-world examples of using each of the approaches below:</p>

<ol>
<li><p>Designing containers which are able to check the health of dependent services. Simple script <a href="https://github.com/vishnubob/wait-for-it" rel="nofollow noreferrer">whait-for-it</a> can be usefull for this kind of developing containers, but aren't suitable for more complex deployments. For instance, database could accept connections but migrations aren't applyied yet.</p></li>
<li><p>Make container able to post own status in Consul/etcd. All dependent services will poll certain endpoint which contains status of needed service. Looks nice but seems redundant, don't it?</p></li>
<li><p>Manage startup order of containers by external scheduler. </p></li>
</ol>

<p>Which of the approaches above are preferable in context of absence/presence orchestrators like Swarm/Kubernetes/etc in delivery process ?</p>

<p>I can take a stab at the kubernetes perspective on those.</p>

<blockquote>
  <p>Designing containers which are able to check the health of dependent services. Simple script whait-for-it can be useful for this kind of developing containers, but aren't suitable for more complex deployments. For instance, database could accept connections but migrations aren't applied yet.</p>
</blockquote>

<p>This sounds like you want to differentiate between liveness and readiness. Kubernetes allows for <a href="http://kubernetes.io/docs/user-guide/production-pods/#liveness-and-readiness-probes-aka-health-checks" rel="nofollow noreferrer">both types of probes</a> for these, that you can use to check health and wait before serving any traffic. </p>

<blockquote>
  <p>Make container able to post own status in Consul/etcd. All dependent services will poll certain endpoint which contains status of needed service. Looks nice but seems redundant, don't it?</p>
</blockquote>

<p>I agree. Having to maintain state separately is not preferred. However, in cases where it is absolutely necessary, if you really want to store the state of a resource, it is possible to use a <a href="http://kubernetes.io/docs/user-guide/thirdpartyresources/" rel="nofollow noreferrer">third party resource</a>.</p>

<blockquote>
  <p>Manage startup order of containers by external scheduler.</p>
</blockquote>

<p>This seems tangential to the discussion mostly. However, <a href="http://kubernetes.io/docs/user-guide/petset/" rel="nofollow noreferrer">Pet Sets</a>, soon to be replaced by Stateful Sets in Kubernetes v1.5, give you deterministic order of initialization of pods. For containers on a single pod, there are <a href="http://kubernetes.io/docs/user-guide/production-pods/#handling-initialization" rel="nofollow noreferrer">init-containers</a> which run serially and in order prior to running the main container.</p>
