> Что такое кэширование и слои кэширования в контейнерах (Go)

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

Кэширование - это сохранение часто используемых данных в быстром хранилище для ускорения доступа. В контейнерах слои кэширования работают на уровне Docker-образов: каждый слой (layer) - результат выполнения одной инструкции в Dockerfile. Если слой не менялся, Docker переиспользует его из локального кэша, что ускоряет сборку и уменьшает потребление ресурсов.

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

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

Ключевой принцип: порядок инструкций имеет значение. Чем выше в Dockerfile расположена часто меняющаяся инструкция (например, COPY исходного кода), тем больше слоёв придётся пересобирать после неё. Поэтому стабильные операции (установка зависимостей) размещают выше, а изменяемые (копирование кода) - ниже.

Также существует кэш на уровне реестра (registry) - при pull образа уже существующие слои не скачиваются повторно, если они есть локально.

На практике

Для Go-приложений типичная оптимизация - многоступенчатая сборка (multi-stage build):

1. Первый этап: установка зависимостей (go mod download) - это стабильный слой, кэшируется хорошо.
2. Второй этап: копирование исходников и сборка бинарника.
3. Финальный этап: минимальный образ (например, scratch или alpine) с только бинарником.

Важно: если вы копируете go.mod и go.sum до COPY . ., то слой с зависимостями переиспользуется, пока не меняются модули. Если же копировать весь проект сразу, любой изменение в коде инвалидирует кэш зависимостей.

Также стоит использовать .dockerignore - это не кэш напрямую, но уменьшает контекст сборки и ускоряет передачу данных в демон Docker.

Пример кода

# Этап 1: сборка
FROM golang:1.22 AS builder
WORKDIR /app

# Сначала копируем только модули - это кэшируется
COPY go.mod go.sum ./
RUN go mod download

# Затем копируем исходники - этот слой будет пересобираться часто
COPY . .
RUN CGO_ENABLED=0 go build -o /app/server .

# Этап 2: финальный образ
FROM scratch
COPY --from=builder /app/server /server
EXPOSE 8080
CMD ["/server"]

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

Начните с определения: кэширование слоёв - механизм переиспользования неизменных частей образа. Затем объясните, как Docker определяет, что слой не изменился: сравнивает инструкцию и контекст (файлы, переменные окружения). Подчеркните важность порядка инструкций и приведите пример с Go: сначала go mod download, потом COPY . .. Упомяните multi-stage build как способ уменьшить размер и улучшить кэширование. Если спросят про инвалидацию - скажите, что изменение любой инструкции или её контекста ломает кэш для этого слоя и всех последующих.

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

• Понимание структуры Docker-образа (слои, неизменяемость).
• Умение оптимизировать Dockerfile под конкретный язык (Go).
• Знание trade-off между скоростью сборки и размером образа.
• Понимание, что кэш - это не только про скорость, но и про консистентность (нельзя использовать устаревшие слои).

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

• Копирование всего проекта до установки зависимостей - ломает кэш при каждом изменении кода.
• Использование одного большого образа без multi-stage - кэш работает, но итоговый образ огромный.
• Игнорирование .dockerignore - в контекст попадают лишние файлы (например, .git), что замедляет сборку и может ломать кэш.
• Утверждение, что кэш слоёв работает между разными Dockerfiles - это не так, кэш привязан к инструкциям и контексту.
• Забывают, что RUN с изменяемыми данными (например, apt-get update) тоже кэшируется - и это может привести к устаревшим пакетам.