Docker Best Practices

This article describes what we've found to be best practices for using Docker and Docker Compose in development.

Cheatsheet

These commands might be helpful to know. See docker-compose docs for more detail.

Start the containers.

$ docker-compose up

Run a command in the existing app container. The container must already be running.

$ docker-compose exec app bash

Run a command in a new app container, and remove the container after completion.

$ docker-compose run --rm app bash

See what containers are running.

$ docker-compose ps

Clean up the containers, and any volumes.

$ docker-compose down --volumes --remove-orphans

Occasionally, you might need to pull the latest version of your images.

$ docker-compose pull

This describes the features we're after when we add Docker and Docker Compose to our development environments.

Editing of source code can be done on the host. The application should reload automatically when it detects the source files changed.
The same docker setup can be used in CI for testing.
Majority of the setup is done in the docker build, so that you get a working system with docker-compose up.
You should be able to get a shell easily within the docker container e.g. docker-compose run --rm app bash.

If the application generates files, they should probably be stored in a named volume. This allows the containers to more easily share files.

If you're adding a directory to the .gitignore, you might also want to create a named volume for it.

Some examples: