Scaling Service Deployment with Docker Compose Quiz

Deepen your understanding of scaling services with Docker Compose, including configuration, orchestration options, dependencies, and challenges. This quiz covers essential scaling commands, configuration fields, and practical best practices for managing scalable, resilient containerized applications.

1. Scaling a Service Using Command-Line

   Which command correctly scales a service named 'api' to 4 replicas using docker-compose?

   1. docker-compose up --scale api=4
   2. docker-compose scale api=4
   3. docker-compose run --count=4 api
   4. docker-compose deploy api=4

   Explanation: The correct syntax to scale a service in Docker Compose is 'docker-compose up --scale [service]=[number]'. The 'scale' sub-command is deprecated in newer versions. Using 'run --count=4' or 'deploy' for this purpose is incorrect, as they do not handle scaling services in Compose. Only the first option is fully supported for scaling services in a Compose setup.

2. Scaling and Stateful Containers

   What is a potential issue when scaling services that use local volumes in a docker-compose setup?

   1. Each replica might have an isolated and inconsistent data store
   2. Service environment variables are lost
   3. Network communication between replicas is disabled
   4. All replicas share the exact same filesystem changes automatically

   Explanation: When you scale services that use local volumes, each replica may have its own data, leading to inconsistencies or isolated state. Environment variables are not typically lost during scaling. Network communication remains active among replicas by default. Replicas do not share local volume file changes automatically unless a shared volume or external storage is configured, making the last option incorrect.

3. Service Dependencies When Scaling

   If you scale a frontend service to 3 replicas but its database service remains at 1, what is a likely outcome in Docker Compose?

   1. All frontend replicas connect to the same single database instance
   2. Each frontend replica automatically creates its own separate database
   3. Frontend replicas fail to start due to missing database dependencies
   4. Frontend and database services are always scaled equally by default

   Explanation: When scaling only the frontend service, all its replicas will typically connect to the single running database instance unless configured otherwise. Docker Compose does not automatically provide individual databases per replica. Frontend replicas will attempt to start as long as the database dependency is defined, and there is no forced equal scaling between services. Only the first option accurately describes the default setup.

4. Configuration Fields for Scaling

   Which field in a Compose file allows you to set the default number of replicas for a service when using orchestration tools?

   1. replicas
   2. instances
   3. count
   4. scale

   Explanation: The 'replicas' field is used under the 'deploy' section in a Compose file for service orchestration, specifying the number of containers to run. The other terms ('instances', 'count', and 'scale') are not valid Compose file fields for this purpose, making 'replicas' the only valid option for declarative scaling with orchestration.

5. Scaling and Port Allocation Behavior

   When scaling a Docker Compose service with a published port on the host, what commonly happens with port allocation for each replica?

   1. Only one replica can bind to the published host port, causing conflicts for others
   2. Each replica receives a unique published port on the host automatically
   3. All replicas share the published port with seamless load balancing by default
   4. Published ports are ignored and networking is only internal

   Explanation: With the default Compose networking, only one container can bind to a specific host port; scaling replicas with host port publishing leads to binding conflicts. Compose does not automatically allocate unique ports to each replica. Sharing a host port among several containers without explicit load-balancing setup causes errors, and ignoring published ports is not standard behavior. Thus, the correct answer is the first one.