Evaluate your understanding of Docker Compose configuration, service management, networking, and troubleshooting for efficient local development workflows. This quiz covers key concepts, syntax, and best practices for leveraging docker-compose in modern development environments.
Which section in a docker-compose.yml file is used to define multiple containers, for example, a web app and its database, as separate services?
Explanation: In a docker-compose.yml file, the 'services' section is used to define multiple containers as individual services. 'Containers' and 'instances' are common terms but not valid keys in the Compose file format. 'Tasks' is associated with orchestration but not with Compose configuration for local development.
If you want changes made to your local source code directory to be immediately reflected in a running container, which docker-compose.yml directive is most appropriate?
Explanation: The 'volumes' key enables real-time file synchronization between the host and the container, which is ideal for local development. 'Mounts', while a related concept, is not the correct key in the Compose file. 'Binds' is often used in manual Docker commands, and 'shares' is not a recognized directive in Compose.
In docker-compose, which option should you use if your application service must wait for the database service to be ready before starting?
Explanation: 'depends_on' is the correct option to define service dependencies within Compose, ensuring one service starts after another. 'wait_for' is not a recognized Compose option, though it sounds plausible. 'Links' is an outdated feature no longer recommended. 'Before' is not a valid key in Compose configuration.
When using Docker Compose, how can a service named 'web' communicate with a service named 'db' on the default network, assuming ports are properly exposed?
Explanation: On the default Docker Compose network, services automatically get hostnames matching their service names, so 'db' can be used by the 'web' service to access the database. 127.0.0.1 refers to the container’s own loopback interface, not the other service. The container ID can change and is not a stable hostname. 'host.docker.internal' is useful for accessing the host machine, not other containers.
During local development, what is the most appropriate docker-compose command to check the logs of a specific failing service, for example 'api', for troubleshooting?
Explanation: 'docker-compose logs api' displays the log output of the 'api' service, which helps in identifying startup or runtime errors. 'docker-compose inspect api' provides detailed metadata but not logs. 'docker-compose ps api' lists information about running containers. 'docker-compose events api' shows real-time events but does not provide service logs directly.