Build vs Image Options in Docker Compose Explained Quiz

Explore the critical differences between the 'build' and 'image' options in docker-compose files, enhancing understanding of container workflows and best practices for defining services. This quiz covers configuration behavior, use cases, and common pitfalls related to container orchestration and Docker Compose ecosystems.

1. Selecting Service Source in Compose

   When defining a service in a docker-compose configuration, which scenario requires the use of the 'build' option instead of the 'image' option?

   1. You want to create an image from a local Dockerfile.
   2. You want to pull an existing image from a remote registry.
   3. You want to use a prebuilt image with custom runtime variables.
   4. You want to start a container from a downloaded archive.

   Explanation: You should use the 'build' option when you need to create an image from a Dockerfile, typically located in your local project directory. The 'image' option is for referencing an already built image in a registry and does not build a new image from source files. Adjusting runtime variables does not require the 'build' option if an image already exists. Starting a container from a downloaded archive is not a supported use case for either 'build' or 'image' in Compose.

2. Combination of Build and Image

   What happens if you specify both 'build' and 'image' fields under the same service in a docker-compose file?

   1. Compose builds the image and tags it with the name in the 'image' field.
   2. Compose ignores the 'build' field and only uses the 'image' field.
   3. Compose throws a syntax error and refuses to start.
   4. Compose downloads a base image and skips the build step.

   Explanation: When both 'build' and 'image' are present, Compose uses the Dockerfile to build the image, then assigns the specified 'image' name as the tag. It does not ignore either field or cause a syntax error. Downloading a base image and skipping the build step is incorrect, as the 'build' process is executed first. Ignoring or rejecting the configuration are common misconceptions.

3. Efficiency in Deployment Scenarios

   Which option is more efficient when deploying a service that does not need to be rebuilt and uses a stable release image maintained elsewhere?

   1. Specifying only the 'image' field with the image tag.
   2. Using the 'build' field to reference a Dockerfile every time.
   3. Defining both 'build' and 'image' for the same service.
   4. Using the 'builds' field to load an existing image.

   Explanation: Referencing an existing image with the 'image' field is more efficient when you don't need to rebuild or customize the image. The 'build' option causes Compose to build the image each time, which adds unnecessary overhead in this scenario. Using both 'build' and 'image' is only useful when you want to tag a custom build. There is no supported 'builds' field in docker-compose.

4. Handling Docker Context with Build

   If you use the 'build' option in a compose file with a relative path to a subdirectory, what does Docker Compose expect to find at that path?

   1. A directory containing a Dockerfile and relevant context files.
   2. A compressed image file for direct loading.
   3. A YAML file describing the image manifest.
   4. A binary for initializing the container.

   Explanation: The 'build' option with a path points to the build context directory, which should include a Dockerfile and all files needed for building the image. A compressed image file is not used by the build process. YAML manifests and binaries are not part of standard build contexts for Compose. Choosing the wrong option would result in build failures or errors.

5. Impact on Version Control and Teams

   Why might using the 'build' option in a docker-compose configuration be preferable for team collaboration compared to distributing only the 'image' option?

   1. Teammates can update the Dockerfile and build images consistently from source.
   2. The service will automatically download performance updates from the registry.
   3. Only the image field ensures consistent runtime configuration for all services.
   4. Build option disables runtime overrides for environment variables.

   Explanation: With the 'build' option, all team members can use the same Dockerfile and context to produce consistent images, reducing discrepancies. The 'image' option alone assumes everyone uses the same prebuilt image, which does not reflect local code or configuration changes. Automatic updates and disabled environment overrides are not related to the build versus image distinction. Maintaining builds in version control promotes better collaboration.