I am working on controlling the startup order of container as my docker-compose.yml
has total 5 containers and they need to be started in an order.
I have gone through many of the suggestions on the internet regarding controlling the startup orders.
The issue is the
command: ["./wait-for-it.sh","rabbitmq:15672"]
is not getting executed inside Docker container when container starts.
Here is a detailed description:
I have a Spring Boot project which has Dockerfile given below.
FROM openjdk:8-jre-alpine
COPY ./target/spring-cloud-config-server-0.0.1-SNAPSHOT.jar /usr/source/
COPY wait-for-it.sh /usr/source/
RUN chmod 777 /usr/source/wait-for-it.sh
RUN apk add --no-cache bash
WORKDIR /usr/source/
EXPOSE 8080
ENTRYPOINT ["java", "-jar", "spring-cloud-config-server-0.0.1-SNAPSHOT.jar"]
2.I am using wait-for-it.sh bash script which is placed in the same root directly where my Dockerfile is present. 3. In the same root directory, I have docker-compose.yml as given below
version: "3.3"
services:
rabbitmq:
image: rabbitmq:management
ports:
- "15672:15672"
- "5672:5672"
volumes:
- /root/rabbitmq_data:/var/lib/rabbitmq
spring-cloud-config-server:
image: rajeevshukla/spring-cloud-config-server
container_name: spring_cloud_config_server
depends_on:
- rabbitmq
links:
- rabbitmq
command: ["./wait-for-it.sh","rabbitmq:15672"]
ports:
- "8888:8080"
environment:
- "SPRING_PROFILES_ACTIVE=prod"
Now when I build Docker image and start it. I see wait-for-it.sh is present inside Docker container in /usr/source/ directory where my jar file is present.
When I run
docker-compose up
I am expecting that once Rabbitmq server is up then spring-cloud-config-server should start. But it is not actually happening. Even I run any command in command: it does not get executed. I have tried all the possible cases but no luck.
As per my knowledge command: ["./wait-for-it.sh","rabbitmq:15672"]
gets executed when the container starts. So does it execute before ENTRYPOINT ["java", "-jar", "spring-cloud-config-server-0.0.1-SNAPSHOT.jar"]
?
Containers are started by executing a single binary, and when that executable exits, the container itself exits. Because of this, when you define both an entrypoint and a command on a container, the result is to pass the command as arguments to the entrypoint. In that situation, your entrypoint needs to know how to process the automatically arguments from the command. What you won't get is a container that runs two commands.
The typical usage is to make the entrypoint a script that performs any initialization steps, like the wait-for-it
command. And then the last line is often an exec "$@"
which replaces the entrypoint script in pid 1 with a new executable defined by the "$@"
, which is the command line arguments.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With