I want to do something like this where I can run multiple commands in order.
db:
image: postgres
web:
build: .
command: python manage.py migrate
command: python manage.py runserver 0.0.0.0:8000
volumes:
- .:/code
ports:
- "8000:8000"
links:
- db
If you need to run more than one daemon process, there's a suggestion in the Docker documentation to use Supervisord in an un-detached mode so all the sub-daemons will output to the stdout.
From another SO question, I discovered you can redirect the child processes output to the stdout. That way you can see all the output!
Use a tool such as wait-for-it or dockerize. These are small wrapper scripts which you can include in your application’s image. Or write your own wrapper script to perform a more application-specific commands. according to: https://docs.docker.com/compose/startup-order/
I ran into this while trying to get my jenkins container set up to build docker containers as the jenkins user.
I needed to touch the docker.sock file in the Dockerfile as i link it later on in the docker-compose file. Unless i touch'ed it first, it didn't yet exist. This worked for me.
Dockerfile:
docker-compose.yml:
try using ";" to separate the commands if you are in verions two e.g.
command: "sleep 20; echo 'a'"
You can use entrypoint here. entrypoint in docker is executed before the command while command is the default command that should be run when container starts. So most of the applications generally carry setup procedure in entrypoint file and in the last they allow command to run.
make a shell script file may be as
docker-entrypoint.sh
(name does not matter) with following contents in it.in docker-compose.yml file use it with
entrypoint: /docker-entrypoint.sh
and register command ascommand: python manage.py runserver 0.0.0.0:8000
P.S : do not forget to copydocker-entrypoint.sh
along with your code.Though this is not entirely relevant to the question, posting it here incase it helps someone. If you want to run a command before starting of the container, you can run the container normally. Then login to the container and make the changes. You can then commit the container as a new image. This new image can be used to ensure that all necessary changes exist before starting the container.