> Какой у тебя опыт работы с Docker (Go)

Короткий ответ

С Docker работаю плотно последние 4 года: от локальной разработки до продакшн-оркестрации в Kubernetes. Основной стек - Go-сервисы, которые собираю в multi-stage Dockerfile, оптимизирую под минимальный размер и безопасность. Регулярно пишу docker-compose для локальных окружений и CI-пайплайнов, настраиваю healthcheck'и, работаю с сетями и volume'ами. Есть опыт дебага проблем с layer caching, resource limits и graceful shutdown контейнеров.

Подробное объяснение

Мой опыт с Docker можно разбить на несколько уровней:

Базовый уровень - ежедневная работа: создание Dockerfile для Go-приложений, использование официальных образов golang:alpine как базовых, multi-stage сборка для уменьшения размера артефакта. Настройка docker-compose для локальной разработки с несколькими сервисами (БД, redis, сам сервис).

Продвинутый уровень - оптимизация: понимание layer caching, правильный порядок инструкций в Dockerfile, использование --mount=type=cache для ускорения сборки Go-модулей. Работа с multi-arch образами через buildx, подпись образов, сканирование уязвимостей через trivy.

Инфраструктурный уровень - интеграция с оркестрацией: деплой Go-сервисов в Kubernetes, где Docker - это только часть пайплайна. Настройка resource requests/limits, liveness и readiness probes, graceful shutdown через обработку SIGTERM в Go-приложении.

Операционный уровень - дебаг и мониторинг: работа с docker logs, docker exec для диагностики, анализ проблем с сетью между контейнерами, управление volume'ами и их бэкапами.

На практике

В реальных проектах Docker используется не изолированно, а как часть CI/CD. Типичный пайплайн для Go-сервиса:

1. Линтер и тесты в CI (обычно GitHub Actions или GitLab CI)
2. Сборка образа с тегом коммита
3. Пуш в registry (Docker Hub, ECR, GCR)
4. Деплой в staging через helm upgrade
5. Прогон интеграционных тестов
6. Промоушн в production

Для локальной разработки - docker-compose с сервисами: postgres, redis, сам Go-сервис с hot-reload через air или reflex. Важно, чтобы контейнер с Go-приложением не был единственным способом запуска - иногда быстрее запустить бинарь локально, а Docker использовать только для зависимостей.

Пример кода

Типичный multi-stage Dockerfile для Go-сервиса:

# Stage 1: build
FROM golang:1.22-alpine AS builder
WORKDIR /app

# Копируем только go.mod и go.sum для кэширования зависимостей
COPY go.mod go.sum ./
RUN go mod download

# Копируем исходники и собираем статический бинарь
COPY . .
RUN CGO_ENABLED=0 GOOS=linux go build -ldflags="-s -w" -o /app/server ./cmd/server

# Stage 2: runtime
FROM alpine:3.20
RUN apk --no-cache add ca-certificates tzdata
WORKDIR /app

# Запускаем от непривилегированного пользователя
RUN addgroup -S app && adduser -S app -G app
USER app

COPY --from=builder /app/server .
COPY --from=builder /app/configs ./configs

EXPOSE 8080
HEALTHCHECK --interval=30s --timeout=3s --start-period=5s --retries=3 \
  CMD wget -qO- http://localhost:8080/health || exit 1

ENTRYPOINT ["./server"]

Важные моменты: CGO_ENABLED=0 для статической линковки, -ldflags="-s -w" для уменьшения размера, отдельный пользователь для безопасности, healthcheck для оркестратора.

Как отвечать на собеседовании

Структурируй ответ по уровням: от простого к сложному. Начни с того, что Docker - это инструмент, а не цель. Покажи, что понимаешь не только синтаксис, но и принципы: изоляция процессов, overlay filesystem, сетевые драйверы.

Обязательно упомяни trade-off'ы: например, что Docker не дает полной изоляции как VM, и что для production чаще используется Kubernetes, а Docker - только как runtime. Расскажи про конкретные проблемы, которые решал: утечка памяти в контейнере, проблемы с DNS между сервисами, race condition при параллельной сборке.

Приведи пример из реального проекта: как оптимизировал время сборки с 5 минут до 30 секунд за счет правильного кэширования слоев. Или как настроил graceful shutdown, чтобы при деплое не терялись запросы.

Что проверяет интервьюер

Интервьюер оценивает:

• Глубину понимания - не просто знание команд, а понимание того, как работает Docker: слои, copy-on-write, namespace, cgroups
• Практический опыт - умение решать реальные проблемы: дебаг, оптимизация, безопасность
• Интеграцию с экосистемой - понимание места Docker в CI/CD, оркестрации, мониторинге
• Умение принимать решения - когда Docker подходит, а когда нет, какие альтернативы существуют
• Внимание к деталям - знание нюансов: разница между CMD и ENTRYPOINT, почему не стоит запускать процессы от root, как работает DNS resolution между контейнерами

Для senior-позиции важно показать, что ты не просто пользователь, а можешь проектировать инфраструктуру и обучать других.

Типичные ошибки

• Отвечать только на уровне команд - docker run, docker build без объяснения принципов работы
• Не упоминать безопасность - запуск от root, отсутствие healthcheck, использование устаревших базовых образов
• Путать Docker и Kubernetes - это разные уровни абстракции, Docker - runtime, Kubernetes - оркестратор
• Игнорировать оптимизацию - не говорить про multi-stage build, layer caching, размер образа
• Не знать про graceful shutdown - для Go-сервисов это критично, контейнер должен корректно обрабатывать SIGTERM
• Говорить только про успешные сценарии - хороший кандидат расскажет и про проблемы, которые возникали, и как их решал
• Не упоминать про ресурсы - memory limits, CPU limits, OOM killer - это важно для стабильности продакшена