Docker Community Forums

Share and learn in the Docker community.

How to control startup order in Compose?



Recently, I was leveraged spring boot and spring cloud to create those micro services including eureka server,config server and other applications in our company, and each of micro service built a docker image, In the process of container startup, It took about 10 minutes or even more for all the applications to fully launch, I think it is a much uncontrollable thing for project deployment team when deploying the project in a new environment, since I don’t know what happened in the startup process, so I hope some of them to start in a certain order, It can effectively reduce startup time (ps : via docker swarm to manage our containers) , for example, the config server can only be started if the eureka server started fully and its service is available, and the official tutorial provide an approach to resolve it, However, after my verification,it not working in docker version 3, Can you please tell me what should I do or give me some valuable advice?
Here is the docker-compose file content:

version: "3"
    image: 192.168.xx.xx/sdp/component-eureka-server:0.0.1-prod
      replicas: 1
      - 1111:1111
      - sdpapp
    image: 192.168.xx.xx/sdp/component-config-server:0.0.1-prod
      replicas: 1
      - sdpapp
      - eureka-server


The proper approach is to handle the synchronisation yourself. Even though one might think that the synonisation on a container level could be sufficient (e.g. wait for a specific tcp port to be reachable), you will need to implement retries on the application level as well, as the target service might be reachable, but does not respond yet or is temporarily unavailable.

Usaly those approaches are combined:

  • initial reachablility check during container start, e.g. try to access the target service 5 times with a delay of 1 second in between, fail the container start if uncessesful. Dockerize from jwilder might be usefull here.
  • introduce resiliency in your application, in a way that it retries to access the service until it succeeds.