new repository

1 files changed, 37 insertions, 0 deletions

diff --git a/devdocs/docker/compose%2Fstartup-order%2Findex.html b/devdocs/docker/compose%2Fstartup-order%2Findex.html
new file mode 100644
index 00000000..8d747220
--- /dev/null
+++ b/devdocs/docker/compose%2Fstartup-order%2Findex.html
@@ -0,0 +1,37 @@
+<h1>Control startup and shutdown order in Compose</h1>
+
+<p>You can control the order of service startup and shutdown with the <a href="../compose-file/compose-file-v3/index#depends_on">depends_on</a> option. Compose always starts and stops containers in dependency order, where dependencies are determined by <code class="language-plaintext highlighter-rouge">depends_on</code>, <code class="language-plaintext highlighter-rouge">links</code>, <code class="language-plaintext highlighter-rouge">volumes_from</code>, and <code class="language-plaintext highlighter-rouge">network_mode: "service:..."</code>.</p> <p>However, for startup Compose does not wait until a container is “ready” (whatever that means for your particular application) - only until it’s running. There’s a good reason for this.</p> <p>The problem of waiting for a database (for example) to be ready is really just a subset of a much larger problem of distributed systems. In production, your database could become unavailable or move hosts at any time. Your application needs to be resilient to these types of failures.</p> <p>To handle this, design your application to attempt to re-establish a connection to the database after a failure. If the application retries the connection, it can eventually connect to the database.</p> <p>The best solution is to perform this check in your application code, both at startup and whenever a connection is lost for any reason. However, if you don’t need this level of resilience, you can work around the problem with a wrapper script:</p> <ul> <li> <p>Use a tool such as <a href="https://github.com/vishnubob/wait-for-it">wait-for-it</a>, <a href="https://github.com/powerman/dockerize">dockerize</a>, sh-compatible <a href="https://github.com/Eficode/wait-for">wait-for</a>, or <a href="https://github.com/jasonsychau/RelayAndContainers">RelayAndContainers</a> template. These are small wrapper scripts which you can include in your application’s image to poll a given host and port until it’s accepting TCP connections.</p> <p>For example, to use <code class="language-plaintext highlighter-rouge">wait-for-it.sh</code> or <code class="language-plaintext highlighter-rouge">wait-for</code> to wrap your service’s command:</p> <div class="highlight"><pre class="highlight" data-language="">version: "2"
+services:
+  web:
+    build: .
+    ports:
+      - "80:8000"
+    depends_on:
+      - "db"
+    command: ["./wait-for-it.sh", "db:5432", "--", "python", "app.py"]
+  db:
+    image: postgres
+</pre></div>  <blockquote> <p><strong>Tip</strong></p> <p>There are limitations to this first solution. For example, it doesn’t verify when a specific service is really ready. If you add more arguments to the command, use the <code class="language-plaintext highlighter-rouge">bash shift</code> command with a loop, as shown in the next example.</p> </blockquote> </li> <li> <p>Alternatively, write your own wrapper script to perform a more application-specific health check. For example, you might want to wait until Postgres is ready to accept commands:</p> <div class="highlight"><pre class="highlight" data-language="">#!/bin/sh
+# wait-for-postgres.sh
+
+set -e
+  
+host="$1"
+shift
+  
+until PGPASSWORD=$POSTGRES_PASSWORD psql -h "$host" -U "postgres" -c '\q'; do
+  &gt;&amp;2 echo "Postgres is unavailable - sleeping"
+  sleep 1
+done
+  
+&gt;&amp;2 echo "Postgres is up - executing command"
+exec "$@"
+</pre></div>  <p>You can use this as a wrapper script as in the previous example, by setting:</p> <div class="highlight"><pre class="highlight" data-language="">command: ["./wait-for-postgres.sh", "db", "python", "app.py"]
+</pre></div>  </li> </ul> <h2 id="compose-documentation">Compose documentation</h2> <ul> <li><a href="../index">User guide</a></li> <li><a href="../install/index">Installing Compose</a></li> <li><a href="../gettingstarted/index">Getting Started</a></li> <li><a href="../reference/index">Command line reference</a></li> <li><a href="../compose-file/index">Compose file reference</a></li> <li><a href="../samples-for-compose/index">Sample apps with Compose</a></li> </ul> 
+<p><a href="https://docs.docker.com/search/?q=documentation">documentation</a>, <a href="https://docs.docker.com/search/?q=docs">docs</a>, <a href="https://docs.docker.com/search/?q=docker">docker</a>, <a href="https://docs.docker.com/search/?q=compose">compose</a>, <a href="https://docs.docker.com/search/?q=startup">startup</a>, <a href="https://docs.docker.com/search/?q=shutdown">shutdown</a>, <a href="https://docs.docker.com/search/?q=order">order</a></p>
+<div class="_attribution">
+  <p class="_attribution-p">
+    &copy; 2019 Docker, Inc.<br>Licensed under the Apache License, Version 2.0.<br>Docker and the Docker logo are trademarks or registered trademarks of Docker, Inc. in the United States and/or other countries.<br>Docker, Inc. and other parties may also have trademark rights in other terms used herein.<br>
+    <a href="https://docs.docker.com/compose/startup-order/" class="_attribution-link">https://docs.docker.com/compose/startup-order/</a>
+  </p>
+</div>