Docker Compose Vocabulary
Learn to read and write Docker Compose configuration in English: services, volumes, networks, and environment variable language.
0 / 23 completed
1 / 23
In Docker Compose, a 'service' definition describes:
A service in docker-compose.yml defines everything needed to run one container: image, build context, ports, volumes, environment, and depends_on.
2 / 23
The 'depends_on' key in a service definition means:
'depends_on' controls startup order — a web service with 'depends_on: [db]' will wait for the db service to start before it launches.
3 / 23
A Docker Compose 'named volume' is used to:
Named volumes (e.g., db_data:/var/lib/postgresql/data) persist container data on the host — without volumes, data is lost when the container is removed.
4 / 23
What does 'ports: - 5432:5432' in a service definition mean?
Port mapping format is HOST_PORT:CONTAINER_PORT. 5432:5432 exposes the container's port 5432 on the host's port 5432 — standard for PostgreSQL.
5 / 23
The command 'docker compose up -d' means:
'docker compose up' starts all services. The '-d' (detached) flag runs them in the background, returning control to the terminal.
6 / 23
Sarah: "Hey team, I've added a new service, 'message_queue', to our Compose file. It needs to connect to the 'database' service, but it shouldn't start until the database is running. I'm using depends_on."This is a common use case. The
depends_on keyword in Docker Compose defines dependencies between services. It ensures that the `message_queue` service will only start *after* the `database` service has successfully started and is considered healthy. Importantly, it doesn't force immediate connection attempts; instead, it manages the startup order based on these defined relationships. Misconceptions often arise from thinking it's a restart mechanism – it's about sequential dependency resolution.7 / 23
John: 'I'm reviewing this PR. The `web_app` service is defined with `environment:` variables like `DATABASE_URL`. It seems a bit odd to hardcode the URL directly in the Compose file – shouldn't we use an external configuration source, maybe a secrets manager or environment variable passed during deployment?', Maria: 'We're using Docker Compose for development and it simplifies things. We can just put the database connection string in the `environment` block.'This scenario highlights a common debate about security versus developer convenience. While hardcoding configuration in Docker Compose is often acceptable for development to simplify local testing, it's generally considered a poor practice for production environments due to potential exposure of sensitive data like database credentials. Using external sources like secrets managers or environment variables passed during deployment provides better control, auditing capabilities, and reduces the risk of accidental leakage.
8 / 23
David: 'Okay team, I've updated the `docker-compose.yml` file for our new microservice, 'payment_processor'. I've added a `restart: always` directive to the service definition. This should ensure it automatically restarts if it crashes, right? I'm not sure what that does exactly.The `restart: always` directive in Docker Compose tells Docker to automatically restart the service container if it exits for any reason. This is crucial for ensuring high availability and resilience; it addresses a common pitfall where services might stop unexpectedly due to crashes or unexpected terminations. It's important to differentiate this from other restart policies like `on-failure` which only restarts on failure, and `no` which prevents restarting entirely.
9 / 23
Context: The team is discussing a recent change to the `api_gateway` service's configuration within their Docker Compose setup. They've updated the `docker-compose.yml` file to include `depends_on` for the `database` service.
PR Description:
Subject: Update `api_gateway` service to use a new database connection.
Body:
> I've updated the `docker-compose.yml` file for the `api_gateway` service. The previous configuration used a hardcoded environment variable for the database URL, but I've now added a `depends_on` directive to ensure it starts after the `database` service is ready.
The correct answer (3) accurately describes the function of `depends_on`. It forces the `api_gateway` service to wait for the `database` service to reach a running state before attempting to start itself. The other options misinterpret the purpose: defaults are not automatically configured by `depends_on`, immediate connection attempts can cause errors, and `depends_on` does *not* create volumes – it controls startup order.
10 / 23
Sarah: "Hey team, I've added a new service, 'message_queue', to our Compose file. It needs to connect to the 'database' service, but it shouldn't start until the database is running. I'm using depends_on."This is a common use case. The
depends_on keyword in Docker Compose defines dependencies between services. It ensures that the `message_queue` service will only start *after* the `database` service has successfully started and is considered healthy. Importantly, it doesn't force immediate connection attempts; instead, it manages the startup order based on these defined relationships. Misconceptions often arise from thinking it's a restart mechanism – it's about sequential dependency resolution.11 / 23
John: 'I'm reviewing this PR. The `web_app` service is defined with `environment:` variables like `DATABASE_URL`. It seems a bit odd to hardcode the URL directly in the Compose file – shouldn't we use an external configuration source, maybe a secrets manager or environment variable passed during deployment?', Maria: 'We're using Docker Compose for development and it simplifies things. We can just put the database connection string in the `environment` block.'This scenario highlights a common debate about security versus developer convenience. While hardcoding configuration in Docker Compose is often acceptable for development to simplify local testing, it's generally considered a poor practice for production environments due to potential exposure of sensitive data like database credentials. Using external sources like secrets managers or environment variables passed during deployment provides better control, auditing capabilities, and reduces the risk of accidental leakage.
12 / 23
David: 'Okay team, I've updated the `docker-compose.yml` file for our new microservice, 'payment_processor'. I've added a `restart: always` directive to the service definition. This should ensure it automatically restarts if it crashes, right? I'm not sure what that does exactly.The `restart: always` directive in Docker Compose tells Docker to automatically restart the service container if it exits for any reason. This is crucial for ensuring high availability and resilience; it addresses a common pitfall where services might stop unexpectedly due to crashes or unexpected terminations. It's important to differentiate this from other restart policies like `on-failure` which only restarts on failure, and `no` which prevents restarting entirely.
13 / 23
Context: The team is discussing a recent change to the `api_gateway` service's configuration within their Docker Compose setup. They've updated the `docker-compose.yml` file to include `depends_on` for the `database` service.
PR Description:
Subject: Update `api_gateway` service to use a new database connection.
Body:
> I've updated the `docker-compose.yml` file for the `api_gateway` service. The previous configuration used a hardcoded environment variable for the database URL, but I've now added a `depends_on` directive to ensure it starts after the `database` service is ready.
The correct answer (3) accurately describes the function of `depends_on`. It forces the `api_gateway` service to wait for the `database` service to reach a running state before attempting to start itself. The other options misinterpret the purpose: defaults are not automatically configured by `depends_on`, immediate connection attempts can cause errors, and `depends_on` does *not* create volumes – it controls startup order.
14 / 23
Sarah: "Hey team, I've added a new service, 'message_queue', to our Compose file. It needs to connect to the 'database' service, but it shouldn't start until the database is running. I'm using depends_on."This is a common use case. The
depends_on keyword in Docker Compose defines dependencies between services. It ensures that the `message_queue` service will only start *after* the `database` service has successfully started and is considered healthy. Importantly, it doesn't force immediate connection attempts; instead, it manages the startup order based on these defined relationships. Misconceptions often arise from thinking it's a restart mechanism – it's about sequential dependency resolution.15 / 23
John: 'I'm reviewing this PR. The `web_app` service is defined with `environment:` variables like `DATABASE_URL`. It seems a bit odd to hardcode the URL directly in the Compose file – shouldn't we use an external configuration source, maybe a secrets manager or environment variable passed during deployment?', Maria: 'We're using Docker Compose for development and it simplifies things. We can just put the database connection string in the `environment` block.'This scenario highlights a common debate about security versus developer convenience. While hardcoding configuration in Docker Compose is often acceptable for development to simplify local testing, it's generally considered a poor practice for production environments due to potential exposure of sensitive data like database credentials. Using external sources like secrets managers or environment variables passed during deployment provides better control, auditing capabilities, and reduces the risk of accidental leakage.
16 / 23
David: 'Okay team, I've updated the `docker-compose.yml` file for our new microservice, 'payment_processor'. I've added a `restart: always` directive to the service definition. This should ensure it automatically restarts if it crashes, right? I'm not sure what that does exactly.The `restart: always` directive in Docker Compose tells Docker to automatically restart the service container if it exits for any reason. This is crucial for ensuring high availability and resilience; it addresses a common pitfall where services might stop unexpectedly due to crashes or unexpected terminations. It's important to differentiate this from other restart policies like `on-failure` which only restarts on failure, and `no` which prevents restarting entirely.
17 / 23
Context: The team is discussing a recent change to the `api_gateway` service's configuration within their Docker Compose setup. They've updated the `docker-compose.yml` file to include `depends_on` for the `database` service.
PR Description:
Subject: Update `api_gateway` service to use a new database connection.
Body:
> I've updated the `docker-compose.yml` file for the `api_gateway` service. The previous configuration used a hardcoded environment variable for the database URL, but I've now added a `depends_on` directive to ensure it starts after the `database` service is ready.
The correct answer (3) accurately describes the function of `depends_on`. It forces the `api_gateway` service to wait for the `database` service to reach a running state before attempting to start itself. The other options misinterpret the purpose: defaults are not automatically configured by `depends_on`, immediate connection attempts can cause errors, and `depends_on` does *not* create volumes – it controls startup order.
18 / 23
Sarah: "Hey team, I've added a new service, 'message_queue', to our Compose file. It needs to connect to the 'database' service, but it shouldn't start until the database is running. I'm using depends_on."This is a common use case. The
depends_on keyword in Docker Compose defines dependencies between services. It ensures that the `message_queue` service will only start *after* the `database` service has successfully started and is considered healthy. Importantly, it doesn't force immediate connection attempts; instead, it manages the startup order based on these defined relationships. Misconceptions often arise from thinking it's a restart mechanism – it's about sequential dependency resolution.19 / 23
John: 'I'm reviewing this PR. The `web_app` service is defined with `environment:` variables like `DATABASE_URL`. It seems a bit odd to hardcode the URL directly in the Compose file – shouldn't we use an external configuration source, maybe a secrets manager or environment variable passed during deployment?', Maria: 'We're using Docker Compose for development and it simplifies things. We can just put the database connection string in the `environment` block.'This scenario highlights a common debate about security versus developer convenience. While hardcoding configuration in Docker Compose is often acceptable for development to simplify local testing, it's generally considered a poor practice for production environments due to potential exposure of sensitive data like database credentials. Using external sources like secrets managers or environment variables passed during deployment provides better control, auditing capabilities, and reduces the risk of accidental leakage.
20 / 23
David: 'Okay team, I've updated the `docker-compose.yml` file for our new microservice, 'payment_processor'. I've added a `restart: always` directive to the service definition. This should ensure it automatically restarts if it crashes, right? I'm not sure what that does exactly.The `restart: always` directive in Docker Compose tells Docker to automatically restart the service container if it exits for any reason. This is crucial for ensuring high availability and resilience; it addresses a common pitfall where services might stop unexpectedly due to crashes or unexpected terminations. It's important to differentiate this from other restart policies like `on-failure` which only restarts on failure, and `no` which prevents restarting entirely.
21 / 23
Context: The team is discussing a recent change to the `api_gateway` service's configuration within their Docker Compose setup. They've updated the `docker-compose.yml` file to include `depends_on` for the `database` service.
PR Description:
Subject: Update `api_gateway` service to use a new database connection.
Body:
> I've updated the `docker-compose.yml` file for the `api_gateway` service. The previous configuration used a hardcoded environment variable for the database URL, but I've now added a `depends_on` directive to ensure it starts after the `database` service is ready.
The correct answer (3) accurately describes the function of `depends_on`. It forces the `api_gateway` service to wait for the `database` service to reach a running state before attempting to start itself. The other options misinterpret the purpose: defaults are not automatically configured by `depends_on`, immediate connection attempts can cause errors, and `depends_on` does *not* create volumes – it controls startup order.
22 / 23
During a code review of a PR updating the `order_service`'s Docker Compose file, Alice comments: 'I noticed you've used `ports:` to expose port 8080. While this works, it might introduce security vulnerabilities if the service is accessible from outside our internal network. Shouldn't we consider using
internal: true instead?' What does Alice suggest?Alice is highlighting a common security concern when exposing ports in Docker Compose. Using
internal: true prevents the service from being accessible directly from outside the Docker network, reducing potential vulnerabilities. The incorrect options either exacerbate the risk or misinterpret the purpose of the `ports:` directive.23 / 23
In a Slack channel discussing deployment issues, Ben writes: 'The `shipping_service` isn't starting after deploying. I checked the logs and it seems to be failing because it can't connect to the database. I've added
depends_on to the service definition in the Docker Compose file.' What is Ben primarily addressing?The core problem Ben describes is a dependency issue – the `shipping_service` relies on the database being available before it can function.
depends_on in Docker Compose explicitly defines this dependency order, ensuring that services start in the correct sequence and preventing startup failures related to missing dependencies.Frequently Asked Questions
What does the "Docker Compose Vocabulary" exercise cover?
Learn to read and write Docker Compose configuration in English: services, volumes, networks, and environment variable language.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to use with no account, sign-up, or paywall.
How many questions are in "Docker Compose Vocabulary"?
This exercise has 23 questions. Each one gives instant feedback with an explanation, so you can see exactly why an answer is right or wrong.
Do I need to create an account to save my progress?
No account is required. The progress bar and score are tracked in your browser for the current session -- the exercise is designed to be a quick, repeatable drill rather than something you resume later.
What happens if I get an answer wrong?
You'll see the correct answer highlighted immediately, along with a short explanation of why it's correct. Wrong answers aren't penalized beyond your score, and you can keep going through every question.
How is this exercise different from reading an article?
Articles explain vocabulary and concepts through prose, while exercises like this one are interactive drills -- multiple-choice questions -- that test and reinforce your recall of specific terms and phrasing.
Can I retry this exercise?
Yes -- use the "Try again" button on the results screen to reset your score and go through all the questions again from the start.
Where can I find more Developer Toolchain exercises?
Browse the full Developer Toolchain hub for related drills, or check the site-wide exercises index for other IT English topics.
Is this exercise suitable for beginners?
This exercise assumes basic familiarity with IT terminology. If a term feels unfamiliar, check the site Glossary for a plain-English definition before attempting the questions.
How often is new content like this published?
New exercises are added regularly across all categories, alongside new vocabulary sets and articles. Check back on the exercises hub to see what's new.