В чем разница Docker Compose и Dockerfile

Что проверяют

Понимаете ли вы, что это инструменты разных уровней: один собирает образ, другой запускает набор контейнеров. Следом обычно просят показать, как Spring Boot сервис в Compose находит базу и почему он падает, если Postgres ещё не готов.

Как отвечать

• Dockerfile: инструкция сборки одного образа. FROM, COPY, RUN, ENTRYPOINT, каждая инструкция даёт слой в кэше. Для Java обычно multi-stage: в первой стадии Maven или Gradle собирает jar, во второй только JRE, например eclipse-temurin:21-jre, и готовый артефакт. Официальный образ openjdk из старых примеров объявлен устаревшим;
• Compose: файл compose.yaml описывает сервисы, сети, тома, переменные окружения и порты и запускается одной командой docker compose up. Сервис ссылается либо на Dockerfile через build:, либо на готовый image:;
• связь: Compose использует Dockerfile, но не заменяет его. Dockerfile отвечает на вопрос «что внутри контейнера», Compose на вопрос «какие контейнеры и как они связаны».

Конкретика, которая выделит ответ:

• имена сервисов: контейнеры видят друг друга по имени в общей сети, поэтому в spring.datasource.url пишут jdbc:postgresql://db:5432/app, а не localhost;
• depends_on: сам по себе ждёт только запуска контейнера. Чтобы ждать готовности базы, нужен healthcheck у Postgres и condition: service_healthy;
• version:: ключ в начале файла устарел, Compose v2 его игнорирует и выводит предупреждение;
• Spring Boot: начиная с 3.1 модуль spring-boot-docker-compose сам поднимает compose.yaml при локальном запуске, а образ можно собрать и без Dockerfile через bootBuildImage или Jib.

Где спотыкаются

Говорят, что Compose это «Docker для нескольких контейнеров», который заменяет Dockerfile. Без описания образа Compose может только запускать готовые чужие образы.

Пишут localhost в адресе базы внутри контейнера и не понимают, почему соединение отклоняется.

Кладут пароли прямо в compose.yaml и берут postgres:latest. Для воспроизводимости тег фиксируют, а секреты выносят в .env или в secrets.