wait-for-it VS dockerize

python:3.10.5-slim-buster is a Debian GNU/Linux 10 (buster). Follow the Debian package link given by wait-for-it, we'll eventually find this link https://packages.debian.org/source/oldoldstable/wait-for-it, I downloaded the wait-for-it_0.0~git20160501.orig.tar.gz file and extracted wait-for-it.sh out to the project root directory where setup.py, app.py, .dockerignore, Dockerfile and docker-compose.yml are.

Using countless variations of the wait for it script (they all get ignored (yes i did chmod +x)). another candidate or using it like this

I haven’t done it, but maybe you can use something like this in an ExecStartPre on the nginx systemd service, or if that doesnt work, as a separate service that nginx’s systemd service starts after

I’ve used wait-for-it with success.

https://github.com/vishnubob/wait-for-it

When start to build docker-compose, it tried to connect db first, but it seems that db didn't become reachable yet. Even added wait-for-it doesn't work.

executes 'wait-for-it.sh' to wait on the availability of port 3306 before running 'air'--using wait-for-it.sh is just an example and this shell script has to be installed as part of the Dockerfilehttps://github.com/vishnubob/wait-for-it

Yeah dockerize seems to achieve your second suggestion, someone also suggested my wait-for-it https://github.com/vishnubob/wait-for-it which seems to be similar but a bit more popular and also used in the official documentation https://docs.docker.com/compose/startup-order/ I think I'll go this route, the first option doesn't quite match what I need as all compose aren't necessarily to be started simultaneously.

Can't you use something like this? : https://github.com/vishnubob/wait-for-it . Essentially wait until you can ping redis port and then run wsgi runserver for django. However, are you sure that you can resolve redis host on swarm? Redis starts so fast that it makes me think it might be something else.

FROM node:14 WORKDIR /app # Instale o Dockerize ENV DOCKERIZE_VERSION v0.7.0 RUN wget -O - https://github.com/jwilder/dockerize/releases/download/$DOCKERIZE_VERSION/dockerize-linux-amd64-$DOCKERIZE_VERSION.tar.gz | tar xzf - -C /usr/local/bin # Defina as condições de espera para o MongoDB CMD dockerize -wait tcp://mongodb:27017 -timeout 1m node app.js

I'll answer in points: 1- being a config file I expect the customization is about different values for the same parameters. You can use dockerize tool to fill a template with environment variables. To use at runtime, you'll have to use the dockerize command inside your entrypoint script before starting your app. https://github.com/jwilder/dockerize

# Dockerfile FROM python:3.9 WORKDIR / ENV DOCKERIZE_VERSION v0.2.0 RUN wget https://github.com/jwilder/dockerize/releases/download/$DOCKERIZE_VERSION/dockerize-linux-amd64-$DOCKERIZE_VERSION.tar.gz \ && tar -C /usr/local/bin -xzvf dockerize-linux-amd64-$DOCKERIZE_VERSION.tar.gz COPY ./requirements.txt /requirements.txt RUN pip install --upgrade pip RUN pip install --no-cache-dir --upgrade -r /requirements.txt COPY . . RUN touch env/.env RUN touch env/mysql.env RUN chmod +x docker-entrypoint.sh ENTRYPOINT ./docker-entrypoint.sh EXPOSE 8000 CMD ["python", "app/main.py"]

I was also reading about healthcheck as well as depends_on. It seems that now they want to move to using tools such as dockerize to handle these basic things, and I don't really get why something that directly has to do with the fact that Docker Compose is managing the infrastructure should be moved to near application-level logic. It adds more boilerplate in a decentralized place, without actually decoupling since there's more than enough to configure in the Compose file anyway.

The trick is to use dockerize -wait to ensure that MongoDB is listening on port 27017 before you start your Node.js container.

I came across dockerize and tried to use it without success, didn't investigate that much tho. Should I use this or is there better tools for the job?

https://github.com/jwilder/dockerize#waiting-for-other-dependencies