Testing, Shutting Down, and Further Exploration with Docker Compose

And run the same commands as before to create the database `mydb`, the user `totoro`, and to grant that user necessary permissions. Once you do that (and the example application container is automatically restarts), the `rest-service` stops failing and restarting and the console goes quiet. It would have been possible to connect the volume that you had previously used, but for the purposes of this example it's more trouble than it's worth and it also provided an opportunity to show how to introduce resilience into your deployment via the `restart_policy` Compose file feature. ### Testing the application Now, test your API endpoint. In the new terminal, run the following command: ```console $ curl http://localhost/ ``` You should receive the following response: ```json Hello, Docker! (0) ``` ### Shutting down To stop the containers started by Docker Compose, press `ctrl+c` in the terminal where you ran `docker compose up`. To remove those containers after they've been stopped, run `docker compose down`. ### Detached mode You can run containers started by the `docker compose` command in detached mode, just as you would with the `docker` command, by using the `-d` flag. To start the stack, defined by the Compose file in detached mode, run: ```console $ docker compose up --build -d ``` Then, you can use `docker compose stop` to stop the containers and `docker compose down` to remove them. ## Further exploration You can run `docker compose` to see what other commands are available. ## Wrap up There are some tangential, yet interesting points that were purposefully not covered in this chapter. For the more adventurous reader, this section offers some pointers for further study. ### Persistent storage A managed volume isn't the only way to provide your container with persistent storage. It is highly recommended to get acquainted with available storage options and their use cases, covered in [Manage data in Docker](/manuals/engine/storage/_index.md). ### CockroachDB clusters You ran a single instance of CockroachDB, which was enough for this example. But, it's possible to run a CockroachDB cluster, which is made of multiple instances of CockroachDB, each instance running in its own container. Since CockroachDB engine is distributed by design, it would have taken surprisingly little change to your procedure to run a cluster with multiple nodes. Such distributed set-up offers interesting possibilities, such as applying Chaos Engineering techniques to simulate parts of the cluster failing and evaluating your application's ability to cope with such failures. If you are interested in experimenting with CockroachDB clusters, check out: - [Start a CockroachDB Cluster in Docker](https://www.cockroachlabs.com/docs/v20.2/start-a-local-cluster-in-docker-mac.html) article; and - Documentation for Docker Compose keywords [`deploy`](/reference/compose-file/legacy-versions.md) and [`replicas`](/reference/compose-file/legacy-versions.md). ### Other databases Since you didn't run a cluster of CockroachDB instances, you might be wondering whether you could have used a non-distributed database engine. The answer is 'yes', and if you were to pick a more traditional SQL database, such as [PostgreSQL](https://www.postgresql.org/), the process described in this chapter would have been very similar. ## Next steps In this module, you set up a containerized development environment with your application and the database engine running in different containers. You also wrote a Docker Compose file which links the two containers together and provides for easy starting up and tearing down of the development environment. In the next module, you'll take a look at one possible approach to running functional tests in Docker.

This section guides the user to test the application endpoint using `curl` after fixing the database connection. It then explains how to stop and remove containers using `docker compose down` and how to run them in detached mode using the `-d` flag. Further exploration topics include persistent storage options, running CockroachDB clusters, and using other databases like PostgreSQL. Finally, it summarizes the module's achievements and introduces the next module on functional testing in Docker.