Docker Compose Service Linking Essentials Quiz

Explore essential concepts of linking services in Docker Compose, focusing on how containers communicate, service dependency management, and best practices for configuration. Enhance your understanding of container orchestration with scenarios involving docker-compose and service connectivity.

1. Service Communication Across Networks

   In a docker-compose file, what is the recommended way for one service to communicate with another service called 'database' within the default network?

   1. Use the service name 'database' as the hostname in the connecting service
   2. Connect using the IP address assigned at runtime
   3. Define a custom entry in /etc/hosts before running docker-compose
   4. Manually expose ports to the host and connect via localhost

   Explanation: Within the default network created by docker-compose, services can communicate using each other's service names as hostnames, which is the intended and reliable method. Using direct IP addresses is less reliable since they can change between runs. Manually editing /etc/hosts is unnecessary because docker networking resolves service names automatically. Exposing and connecting through localhost works for host-to-container connections, not container-to-container in the same network.

2. Legacy 'links' Key Usage

   Why is using the 'links' key in a modern docker-compose.yml file generally discouraged for connecting services?

   1. Because modern docker-compose networking resolves service names automatically
   2. Because 'links' is required for all service communication
   3. Because it exposes services to the public internet by default
   4. Because 'links' only works with volumes, not networks

   Explanation: Modern versions of docker-compose automatically provide service name resolution through user-defined networks, making 'links' unnecessary and outdated. 'Links' is not required for service communication, as this is handled by networks. The 'links' key does not affect internet exposure, which is managed by explicit port mappings. While 'links' is not related to volumes, it historically provided hostname mappings, now obsolete due to networks.

3. Dependencies and Service Startup

   Given two services, 'web' and 'db', how can you ensure that 'db' starts before 'web' in docker-compose, without enforcing full readiness of 'db'?

   1. Add 'depends_on' for 'db' in the 'web' service section
   2. Set 'restart: always' on the 'db' service
   3. Use the 'links' key with 'db' in 'web'
   4. Specify a healthcheck for 'db' in the compose file

   Explanation: 'depends_on' ensures that 'db' is started before 'web', but it does not wait for 'db' to be fully ready—it only manages startup order. 'restart: always' controls service restart policies, not dependencies. The 'links' key only adds legacy hostname dependencies and is not meant for startup order. Adding a healthcheck can help with readiness, but compose by itself doesn't delay 'web' until healthchecks pass unless advanced options are used.

4. External Network Linking

   How can services from different docker-compose projects communicate securely without using host networking or exposing ports to the external network?

   1. Attach both projects' services to a shared external network defined in each compose file
   2. Rely on the default bridge network for cross-project communication
   3. Expose ports in both projects and use public IP addresses
   4. Use the 'links' key across compose project boundaries

   Explanation: Defining and attaching services to a shared external network allows isolated inter-project communication while keeping services private. The default bridge network is unique per project and doesn't permit cross-project access by default. Exposing ports for inter-service communication unnecessarily opens services to the external network, reducing security. 'Links' do not work across project boundaries and are deprecated in favor of networks.

5. Automatic Service Discovery

   When a service in docker-compose fails to resolve another linked service's hostname, which misconfiguration is a likely cause?

   1. The two services are not on the same network
   2. Both services have 'restart: unless-stopped' configured
   3. The failed service lacks a 'build' context
   4. The environment variables section is missing

   Explanation: For service discovery via hostname to work, containers must be attached to the same network within docker-compose. Restart policies such as 'unless-stopped' do not impact network connectivity. The presence or absence of a 'build' context only affects image building, not networking. Omitted environment variables may affect service configuration but not hostname resolution between services.