Docker Community Forums

Share and learn in the Docker community.

Docker depends_on doesn't work

Hello every one, i need help when i used network_mode: “host” in auth container then depends_on - eureka doesn’t connect in auth container. i got the issue it’s may be problem for using host but i don’t know how to solved this problem

version: “3.8”

services:

    eureka:
            build: ./eureka/
            image: eureka-server
            container_name: eureka
            ports:
                    - "8762:8762"
            deploy:
                    resources:
                            limits:
                                    cpus: '0.10'
                                    memory: 512M
    auth:
            build: ./auth/
            image: auth-server
            container_name: auth
            network_mode: "host"
            ports:
                    - "9192:9192"
            depends_on:
                    - eureka
            volumes:
                    - /opt/docker/log:/app/log
            deploy:
                    resources:
                            limits:
                                    cpus: '0.30'
                                    memory: 512M

… APlication configuration…
spring.da tasource.driver-class-name=com.mysql.jdbc.Driver
spring.datasource.url=jdbc:mysql://192.168.0.33:3306/testdb?useSSL=false&createDatabaseIfNotExist=true
spring.datasource.username=root
spring.datasource.password=root

eureka.client.serviceUrl.defaultZone=http://eureka:8761/eureka/
eureka.instance.preferIpAddress=true

You can control the order of service startup and shutdown with the depends_on option. Compose always starts and stops containers in dependency order, where dependencies are determined by depends_on, links, volumes_from, and network_mode: “service:…”.

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.

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.

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.

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:

Use a tool such as wait-for-it, dockerize, or sh-compatible wait-for. 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.

For example, to use wait-for-it.sh or wait-for to wrap your service’s command:

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

1 Like

This is described in the docs for depends_on. Additional info in the Docker-compose documentation.