Home Explore Blog Models CI



docker

4th chunk of `content/get-started/workshop/08_using_compose.md`
9edefaf0bc3510560b740129392d9af40f3e4f4909c09d400000000100000c30
   Creating app_app_1   ... done
   Creating app_mysql_1 ... done
   ```

    You'll notice that Docker Compose created the volume as well as a network. By default, Docker Compose automatically creates a network specifically for the application stack (which is why you didn't define one in the Compose file).

3. Look at the logs using the `docker compose logs -f` command. You'll see the logs from each of the services interleaved
    into a single stream. This is incredibly useful when you want to watch for timing-related issues. The `-f` flag follows the
    log, so will give you live output as it's generated.

    If you have run the command already, you'll see output that looks like this:

    ```plaintext
    mysql_1  | 2019-10-03T03:07:16.083639Z 0 [Note] mysqld: ready for connections.
    mysql_1  | Version: '8.0.31'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  MySQL Community Server (GPL)
    app_1    | Connected to mysql db at host mysql
    app_1    | Listening on port 3000
    ```

    The service name is displayed at the beginning of the line (often colored) to help distinguish messages. If you want to
    view the logs for a specific service, you can add the service name to the end of the logs command (for example,
    `docker compose logs -f app`).

4. At this point, you should be able to open your app in your browser on [http://localhost:3000](http://localhost:3000) and see it running.

## See the app stack in Docker Desktop Dashboard

If you look at the Docker Desktop Dashboard, you'll see that there is a group named **getting-started-app**. This is the project name from Docker
Compose and used to group the containers together. By default, the project name is simply the name of the directory that the
`compose.yaml` was located in.

If you expand the stack, you'll see the two containers you defined in the Compose file. The names are also a little
more descriptive, as they follow the pattern of `<service-name>-<replica-number>`. So, it's very easy to
quickly see what container is your app and which container is the mysql database.

## Tear it all down

When you're ready to tear it all down, simply run `docker compose down` or hit the trash can on the Docker Desktop Dashboard
for the entire app. The containers will stop and the network will be removed.

> [!WARNING]
>
> By default, named volumes in your compose file are not removed when you run `docker compose down`. If you want to
>remove the volumes, you need to add the `--volumes` flag.
>
> The Docker Desktop Dashboard does not remove volumes when you delete the app stack.

## Summary

In this section, you learned about Docker Compose and how it helps you simplify
the way you define and share multi-service applications.

Related information:
 - [Compose overview](/manuals/compose/_index.md)
 - [Compose file reference](/reference/compose-file/_index.md)
 - [Compose CLI reference](/reference/cli/docker/compose/_index.md)

## Next steps

Next, you'll learn about a few best practices you can use to improve your Dockerfile.

{{< button text="Image-building best practices" url="09_image_best.md" >}}

Title: Observing, Accessing, and Tearing Down the Application Stack
Summary
This section explains how to view service logs, access the application in a browser, and observe the application stack in the Docker Desktop Dashboard. It also details how to tear down the application stack using `docker compose down` and warns about the default behavior of named volumes. Finally, it summarizes the section's content, providing links to related information and suggesting next steps regarding image-building best practices.