There are several commands for managing the container life cycle in Docker Compose. It's important to understand the differences between the options, so you don't remove resources unexpectedly.

The up and down commands are blunt tools to start and stop the whole application. The up command creates any resources specified in the Compose file that don't exist, and it creates and starts containers for all the services. The down command does the reverse—it stops any running containers and removes the application resources. Containers and networks are removed if they were created by Docker Compose, but volumes are not removed—so any application data you have is retained.

The stop command just stops all the running containers without removing them or other resources. Stopping the container ends the running process with a graceful shutdown. The kill command stops all the containers by forcibly ending the running process. Stopped application containers can be started again with start, which runs the entry point program in the existing container.

Stopped containers retain all their configuration and data, but they don't use any compute resources. Starting and stopping containers is a very efficient way to switch context if you work on multiple projects. If I'm developing on NerdDinner when another piece of work comes in as a priority, I can stop the whole NerdDinner application to free up my development environment:

> docker-compose stop
Stopping ch06-docker-compose_nerd-dinner-web_2           ... done
Stopping ch06-docker-compose_nerd-dinner-web_1           ... done
Stopping ch06-docker-compose_nerd-dinner-web_3           ... done
Stopping ch06-docker-compose_nerd-dinner-save-handler_3  ... done
Stopping ch06-docker-compose_nerd-dinner-save-handler_2  ... done
Stopping ch06-docker-compose_nerd-dinner-save-handler_1  ... done
Stopping ch06-docker-compose_nerd-dinner-index-handler_1 ... done
Stopping ch06-docker-compose_kibana_1                    ... done
Stopping ch06-docker-compose_reverse-proxy_1             ... done
Stopping ch06-docker-compose_nerd-dinner-homepage_1      ... done
Stopping ch06-docker-compose_nerd-dinner-db_1            ... done
Stopping ch06-docker-compose_nerd-dinner-api_1           ... done
Stopping ch06-docker-compose_elasticsearch_1             ... done
Stopping ch06-docker-compose_message-queue_1             ... done

Now I have no containers running, and I can switch to the other project. When that work is done, I can fire up NerdDinner again by running docker-compose start.

You can also stop individual services by specifying a name, which is very useful if you want to test how your application manages failures. I can check how the index-dinner handlers behave if they can't access Elasticsearch by stopping the Elasticsearch service:

> docker-compose stop elasticsearch
Stopping ch06-docker-compose_elasticsearch_1 ... done

All of these commands are processed by comparing the Compose file to the services running in Docker. You need to have access to the Docker Compose file to run any Docker Compose commands. This is one of the biggest drawbacks of using Docker Compose on a single host to run your applications. The alternative is to use the same Compose file but to deploy it as a stack to a Docker Swarm, which I'll cover in the next chapter.