🐳 Вопросы интервью по Docker

Ответ: Docker — платформа для упаковки приложения вместе со всеми зависимостями (JDK, библиотеки, конфигурация) в образ и запуска его в изолированном контейнере. Приложение ведёт себя одинаково на ноутбуке разработчика, в CI и на сервере.

• Воспроизводимость — «у меня работает» превращается в «работает везде»
• Изоляция — приложения не конфликтуют по версиям зависимостей и портам
• Быстрый запуск — контейнер стартует за секунды, так как не загружает целую ОС
• Простое окружение — БД, Redis, Kafka поднимаются одной командой
• Удобная доставка — образ собирается один раз и разворачивается где угодно

• Образ — неизменяемый шаблон, набор слоёв файловой системы и метаданных (команда запуска, переменные). Из него создаются контейнеры
• Контейнер — запущенный (или остановленный) экземпляр образа с добавленным сверху слоем для записи. Как «объект» относится к «классу»
• Реестр — хранилище образов: Docker Hub, GitHub Container Registry, приватные (Harbor, Nexus, ECR)

docker pull postgres:16           # скачать образ из реестра
docker run -d --name db postgres:16   # создать и запустить контейнер из образа
docker run -d --name db2 postgres:16  # второй независимый контейнер из того же образа
                

Ответ: Контейнер — это обычный процесс Linux, к которому применены средства ядра:

• docker (CLI) → dockerd (демон) → containerd → runc (создаёт контейнер)
• Слои общие: если десять образов основаны на одном базовом, он хранится на диске один раз

FROM eclipse-temurin:21-jre
WORKDIR /app
COPY target/app.jar app.jar
EXPOSE 8080
ENTRYPOINT ["java", "-jar", "app.jar"]
                

• ENTRYPOINT — основная исполняемая команда контейнера; аргументы из docker run добавляются к ней
• CMD — команда или аргументы по умолчанию; целиком заменяется, если передать свою команду в docker run
• Часто используют вместе: ENTRYPOINT задаёт программу, CMD — аргументы по умолчанию

ENTRYPOINT ["java", "-jar", "app.jar"]
CMD ["--spring.profiles.active=prod"]
# docker run my-app --spring.profiles.active=dev   -> заменит только CMD
                

• COPY просто копирует файлы
• ADD умеет ещё скачивать по URL и распаковывать tar-архивы; из-за неявного поведения рекомендуется COPY

• ARG существует только во время сборки (--build-arg)
• ENV сохраняется в образе и доступен приложению при запуске

Ответ: Каждая инструкция RUN, COPY, ADD создаёт новый слой. Docker кэширует слои: если инструкция и её входные данные не менялись, слой берётся из кэша. Как только слой изменился, все слои после него пересобираются.

• Сначала копировать редко меняющееся (pom.xml, скачивание зависимостей), потом часто меняющееся (исходники)
• Объединять связанные команды в один RUN и убирать за собой временные файлы в той же команде

COPY pom.xml .
RUN mvn -q dependency:go-offline     # слой с зависимостями: меняется редко
COPY src ./src                       # исходники: меняются часто
RUN mvn -q package -DskipTests
                

Файл исключает ненужное из контекста сборки: ускоряет сборку, не попадают лишние и секретные файлы.

target/
.git/
.idea/
*.log
.env
                

Ответ: В multi-stage Dockerfile несколько FROM. На первом этапе собирают приложение (нужны JDK и Maven), на втором — копируют только результат в лёгкий образ. Инструменты сборки в итоговый образ не попадают.

# этап 1: сборка
FROM maven:3.9-eclipse-temurin-21 AS build
WORKDIR /app
COPY pom.xml .
RUN mvn -q dependency:go-offline
COPY src ./src
RUN mvn -q package -DskipTests

# этап 2: запуск
FROM eclipse-temurin:21-jre
WORKDIR /app
COPY --from=build /app/target/*.jar app.jar
ENTRYPOINT ["java", "-jar", "app.jar"]
                

• Брать JRE вместо JDK и компактные базовые образы (-alpine, distroless)
• jlink — собрать урезанный runtime только с нужными модулями JDK
• Layered jar в Spring Boot: слои с зависимостями кэшируются отдельно от кода
• Jib и Cloud Native Buildpacks — сборка образа без Dockerfile
• .dockerignore и очистка временных файлов в том же RUN

Ответ: JVM, начиная с JDK 10 (и 8u191), учитывает ограничения контейнера по памяти и CPU. Но без настройки доля памяти для кучи невелика: по умолчанию максимальная куча — около 25% от лимита контейнера.

FROM eclipse-temurin:21-jre
WORKDIR /app
COPY app.jar app.jar
USER 1000
ENTRYPOINT ["java", "-XX:MaxRAMPercentage=75.0", "-jar", "app.jar"]
                

docker run -d --name app -p 8080:8080 --memory=512m --cpus=1.5 my-app
                

• -XX:MaxRAMPercentage задаёт долю памяти контейнера под кучу; можно использовать и обычный -Xmx
• Кроме кучи JVM использует память под метаспейс, стеки потоков, native-память, поэтому Xmx не стоит делать равным лимиту
• Если процесс превысил лимит, ядро убивает контейнер — статус OOMKilled, код выхода 137
• Лимит CPU влияет на Runtime.availableProcessors(), а значит на размеры пулов потоков
• Передавайте конфигурацию через переменные окружения (например SPRING_PROFILES_ACTIVE), а не пересобирайте образ

Ответ: Файлы внутри контейнера исчезают вместе с ним, поэтому для постоянных данных используют монтирование.

docker volume create pgdata
docker run -d --name db -v pgdata:/var/lib/postgresql/data postgres:16   # volume
docker run -d -v $(pwd)/config:/app/config:ro my-app                      # bind mount, только чтение
                

docker network create backend
docker run -d --name db --network backend postgres:16
docker run -d --name app --network backend -p 8080:8080 my-app
# внутри app база доступна по адресу db:5432
                

-p 8080:80 публикует порт: порт_хоста:порт_контейнера. EXPOSE порт не публикует, он только документирует.

Ответ: Docker Compose описывает несколько контейнеров приложения в одном YAML-файле (compose.yaml / docker-compose.yml) и запускает их одной командой: docker compose up -d. Compose сам создаёт общую сеть, где сервисы видят друг друга по имени.

services:
  app:
    build: .
    ports:
      - "8080:8080"
    environment:
      SPRING_DATASOURCE_URL: jdbc:postgresql://db:5432/mydb
      SPRING_DATASOURCE_USERNAME: app
      SPRING_DATASOURCE_PASSWORD: secret
    depends_on:
      db:
        condition: service_healthy
    restart: unless-stopped

  db:
    image: postgres:16
    environment:
      POSTGRES_DB: mydb
      POSTGRES_USER: app
      POSTGRES_PASSWORD: secret
    volumes:
      - pgdata:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U app -d mydb"]
      interval: 5s
      retries: 10

volumes:
  pgdata:
                

• depends_on без condition ждёт только старта контейнера, а не готовности БД; для ожидания готовности нужен healthcheck и service_healthy
• restart: no, on-failure, always, unless-stopped
• Основные команды: up, down (-v удаляет и тома), logs -f, ps, build
• Compose обычно используют для разработки и тестов, а не как production-оркестратор

• Не кладите секреты в образ: ни в ENV, ни в COPY, ни в ARG. Они остаются в слоях и видны через docker history
• Передавайте при запуске: -e, --env-file, Docker/Compose secrets, секреты оркестратора, Vault
• Не коммитьте .env в репозиторий, добавьте его в .gitignore и .dockerignore

• Запускайте не от root: USER в Dockerfile
• Используйте минимальные базовые образы и фиксируйте версии (а не latest)
• Сканируйте образы на уязвимости (Trivy, Docker Scout)
• Ограничивайте ресурсы (--memory, --cpus) и привилегии (--cap-drop, --read-only)
• Не используйте --privileged и не монтируйте docker.sock без необходимости
• Обновляйте образы, подписывайте и берите только из доверенных реестров

RUN useradd -r -u 1001 appuser
USER appuser
                

Ответ: Это инструменты разных уровней.

• Pod — минимальная единица запуска, один или несколько контейнеров
• Deployment — поддерживает нужное число копий Pod и обновления
• Service — постоянный адрес и балансировка для набора Pod
• ConfigMap и Secret — конфигурация и секреты