Docker-Compose: how to wait for other service to be ready?

Update to version 3+.

Please follow the documents from version 3:

There are several things to be aware of when using depends_on:

depends_on does not wait for db and redis to be “ready” before starting web - only until they have been started.
If you need to wait for a service to be ready, see Controlling startup order for more on this problem and strategies for solving it.
Version 3 no longer supports the condition form of depends_on.
The depends_on option is ignored when deploying a stack in swarm mode with a version 3 Compose file.

I would consider using the restart_policy option for configuring your myprogram-app to restart until the jhipster-registry is up and accepting connections:

 restart_policy:
        condition: on-failure
        delay: 3s
        max_attempts: 5
        window: 60s

The documentation suggests that, in Docker Compose version 2 files specifically, depends_on: can be a list of strings, or a mapping where the keys are service names and the values are conditions. For the services where you don't have (or need) health checks, there is a service_started condition.

depends_on:
  # notice: these lines don't start with "-"
  jhipster-registry:
    condition: service_healthy
  myprogram-postgresql:
    condition: service_started
  myprogram-elasticsearch:
    condition: service_started

Depending on how much control you have over your program and its libraries, it's better still if you can arrange for the service to be able to start without its dependencies necessarily being available (equivalently, to function if its dependencies die while the service is running), and not use the depends_on: option. You might return an HTTP 503 Service Unavailable error if the database is down, for instance. Another strategy that often is helpful is to immediately exit if your dependencies aren't available but use a setting like restart: on-error to ask the orchestrator to restart the service.

Best Approach - Resilient App Starts

While docker does support startup dependencies, they officially recommend updating your app start logic to test for the availability of external dependencies and retry. This has lots of benefits for robust applications that may restart in the wild on the fly in addition to circumventing the race condition in docker compose up

depends_on & service_healthy - Compose 1.27.0⁺

depends_on is back in docker compose v1.27.0+ (was deprecated in v3) in the Compose Specification

Each service should also implement a service_healthy check to be able to report if it's fully setup and ready for downstream dependencies.

version: '3.0'
services:
  php:
    build:
      context: .
      dockerfile: tests/Docker/Dockerfile-PHP
    depends_on:
      redis:
        condition: service_healthy
  redis:
    image: redis
    healthcheck:
      test: ["CMD", "redis-cli", "ping"]
      interval: 1s
      timeout: 3s
      retries: 30

wait-for-it.sh

The recommended approach from docker according to their docs on Control startup and shutdown order in Compose is to download wait-for-it.sh which takes in the domain:port to poll and then executes the next set of commands if successful.

version: "2"
services:
  web:
    build: .
    ports:
      - "80:8000"
    depends_on:
      - "db"
    command: ["./wait-for-it.sh", "db:5432", "--", "python", "app.py"]
  db:
    image: postgres

Note: This requires overriding the startup command of the image, so make sure you know what wanted to pass to maintain parity of the default startup.

Further Reading

• Docker Compose wait for container X before starting Y
• Difference between links and depends_on in docker_compose.yml
• How can I wait for a docker container to be up and running?
• Docker Compose Wait til dependency container is fully up before launching
• depends_on doesn't wait for another service in docker-compose 1.22.0

Although you already got an answer, it should be mentioned that what you are trying to achieve have some nasty risks.

Ideally a service should be self sufficient and smart enough to retry and await for dependencies to be available (before a going down). Otherwise you will be more exposed to one failure propagating to other services. Also consider that a system reboot, unlike a manual start might ignore the dependencies order.

If one service crash causes all your system to go down, you might have a tool to restart everything again, but it would be better having services that resist that case.