docker-compose.yml Structure: Key Concepts and Best Practices Quiz Quiz

Challenge your understanding of docker-compose.yml structure by answering questions focused on its essential components, correct usage, and configuration nuances. Enhance your knowledge of service definitions, volumes, networking, and syntax practices in the context of modern container orchestration.

1. Specifying Service Images

   In a docker-compose.yml file, which key should be included under a service to specify the container image, such as 'redis:latest'?

   1. image
   2. container
   3. service
   4. build

   Explanation: The 'image' key is used to specify which container image to use for a given service. 'container' is not a valid directive in docker-compose.yml structure. 'service' is used at a higher, more structural level, not as a service property. 'build' is used to indicate a build context or Dockerfile, not a pre-built image. Only 'image' directly points to a downloadable image.

2. Defining and Using Volumes

   Which of the following options correctly defines a named volume and attaches it to a service in docker-compose.yml?

   1. Declare the volume under 'volumes' key at top-level and refer to it under the service's 'volumes' section
   2. Only list the volume under the service's 'volumes' section without declaring it globally
   3. List the volume under a 'storage' key at the root of the file
   4. Use the 'attach-volumes' key within the service definition

   Explanation: To use named volumes, you define their names under the global 'volumes:' section and then reference them in the service's 'volumes:' block. Only referencing the volume locally without declaring it globally can cause configuration issues for named volumes. 'storage' and 'attach-volumes' are not recognized keywords in the yaml file hierarchy. Proper declaration allows for reuse and clarity.

3. Network Configuration Basics

   If you want two services to communicate privately within a docker-compose project, which structure should you use in docker-compose.yml?

   1. Define a custom network under 'networks' and list it in both services
   2. Add both services under a common 'group' key
   3. Use 'share_network: true' in the service definitions
   4. Add both services under 'links' with a value of 'private'

   Explanation: The correct way to enable private inter-service communication is by defining a network under the 'networks' key and specifying it in both service definitions. The 'group' key is not a valid part of the structure, and 'share_network' is not recognized in this context. Using 'links' is deprecated and does not facilitate secure, custom networking as 'networks' does.

4. Extending Services with Environment Variables

   How should you define environment variables for a service within the docker-compose.yml file?

   1. List key-value pairs under the 'environment' key inside the service
   2. Place environment variables under global 'env' key at the top of the file
   3. Add variables under a 'config' section with 'environment_var:' prefix
   4. Specify them using an 'environments' key within the service

   Explanation: Environment variables should be defined as key-value pairs under the 'environment' key within each service block. Using a global 'env' key or a 'config' section with an 'environment_var:' prefix are not valid in docker-compose.yml syntax. The correct key is singular 'environment,' while 'environments' is also incorrect.

5. Anchors and YAML Syntax

   Which feature allows you to reuse configuration fragments within docker-compose.yml by defining a section with '&' and referencing it elsewhere with '*'?

   1. YAML anchors and aliases
   2. Service mirroring
   3. Option duplication
   4. Keyword repeats

   Explanation: YAML anchors (using '&') and aliases (using '*') allow parts of the configuration to be defined once and reused elsewhere within the file. Service mirroring and option duplication are not standard YAML or docker-compose concepts. Keyword repeats is not a feature, but YAML anchors and aliases directly support reusability and cleaner configurations.