In my previous blog post, I gave a brief introduction to containerisation, and the differences between Docker and Docker Compose. Here I’m going to share the Docker Compose commands that I use on a daily basis and have found the most essential.
In my opinion, if you only learn 5 Docker Compose commands, they should be:
docker-compose up
Run this command to launch your project.
The up command builds or creates all the services in the docker-compose file and starts a container for each of them.
If you add the -d flag (i.e., docker-compose up -d), it runs in ‘detached’ mode, which means the containers are set up and run in the background, and you don’t see Docker’s rather lengthy logs in your terminal.
(To undo this and tear your services down, the command is, unsurprisingly, docker-compose down).
docker-compose run <service name> [<command>]
The run command starts a new container for the service and runs a command in that container. If you don’t specify a command, it will use the default command as defined in your docker-compose file. You can overwrite this default command by adding a different one, e.g. docker-compose run web bash.
If you add the --rm flag, i.e. docker-compose run --rm web bash, this creates a temporary or “ephemeral” container, which means the container will automatically delete as soon as the command is complete.
docker-compose exec <service name> <command>
Similar to the run command, but importantly different, the exec command runs a command in an already-running container.
docker-compose ps
This command lists all of your project’s services, and their current status: i.e., “Up”, “Restarting”, or “Exit” if they’ve been stopped.
docker-compose logs
This command prints the logs for the services in your app. You can also specify a service by name. Adding the -f flag, i.e. docker-compose logs -f, prints the logs in ‘follow’ mode, with live updates.
With all docker-compose commands, you can specify a particular service. Or if you don’t, the command will apply to all services listed in your docker-compose file. For example, you can either call docker-compose logs to view the logs on all the services for your project. Or if you only want to see the logs for your service called “web”, you can call docker-compose logs web.
Docker commands can be long and repetitive, especially once you’re adding options flags, service names and commands. In our project, we created the following bin files for the commands we used frequently:
bin/build => docker-compose build $@
bin/bundle => bin/exec web bundle $@
bin/destroy => bin/down --rmi ‘all’ --volumes
bin/down => docker-compose down --remove-orphans $@
bin/exec => docker-compose exec $@
bin/logs => docker-compose logs $@
bin/run => docker-compose run --rm $@
bin/start => docker-compose start $@
bin/status => docker-compose ps
bin/stop => docker-compose stop $@
bin/up => docker-compose up $@Make sure to preface every file with the shebang #!/bin/sh. The shebang is a special character sequence in a script file that specifies which program should be called to run the script. Here, the shebang specifies /sh, meaning the system should use its default shell program to interpret the script in these files.
Also, I learnt that by adding $@, the command can take any additional argument(s) you provide, but equally will run without them if you don’t.
You can then run the docker-compose command you need just by calling the appropriate bin file. For example, instead of typing docker-compose ps, you can now just type bin/status. And instead of typing docker-compose logs -f web, you can now just type bin/logs -f web.
Obviously, there’s a lot more to the world of Docker Compose than these 5 commands. In my next blog post, I will talk through some other commands that I have found useful during the project. But hopefully, these 5 will help get you started!
