Docker

Контейнеры, образы и сборка


Что такое контейнер и как он работает

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

На уровне системы контейнер строится на двух ключевых технологиях ядра Linux (поскольку Docker изначально ориентирован на Linux, хотя теперь работает и на других платформах через эмуляцию): пространства имен и группы контроля ресурсов.

Пространства имен — это способ разделить системные ресурсы так, чтобы процессы внутри контейнера видели только свою часть системы. Например, пространство имен для процессов (PID namespace) делает так, что процессы в контейнере имеют свои собственные идентификаторы, начиная с 1, как будто они в отдельной системе. Пространство имен для сети изолирует сетевые интерфейсы, так что контейнер может иметь свой IP-адрес. Есть также пространства для пользователей, файловой системы и других. В памяти это значит, что процессы контейнера не видят процессы хоста напрямую — они работают в своем "пузыре", но делят одно ядро операционной системы. Это экономит ресурсы: нет overhead от полной виртуализации.

Группы контроля ресурсов (cgroups) — это механизм ограничения ресурсов, таких как процессор, память и диск. Например, вы можете сказать: "Этот контейнер может использовать не больше 512 МБ памяти". В памяти это работает через ядро, которое отслеживает использование и при превышении может убить процессы (OOM killer). Cgroups также помогают в изоляции ввода-вывода, чтобы один контейнер не "загружал" диск для всех.

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


Отличие контейнера от виртуальной машины

Виртуальная машина (VM) — это полная эмуляция отдельного компьютера с собственным ядром операционной системы, процессором и памятью. Она использует гипервизор (программу вроде VirtualBox или VMware), который эмулирует аппаратное обеспечение. В памяти хоста VM занимает отдельный блок: ее процессы работают в изолированном пространстве с overhead от эмуляции (до 10-20% потерь производительности).

Контейнер, напротив, делит ядро хоста. Нет эмуляции аппаратного уровня — все процессы используют одно ядро. Это делает контейнеры легче: образ (шаблон для контейнера) может быть в разы меньше (сотни МБ vs гигабайты для VM), запуск быстрее, и overhead минимален (1-5%). Но есть минус: контейнеры менее безопасны, если есть уязвимость в ядре, она может затронуть все. Для Java это значит, что ваше приложение в контейнере запускается на той же JVM (виртуальной машине Java), что и на хосте, но с изоляцией зависимостей, что упрощает развертывание.


#Java #middle #Docker #DockerFile #Docker_compose #Buildx

OCI-спецификации: образы, манифесты и слои

Open Container Initiative (OCI) — это стандарт, который определяет, как должны выглядеть контейнерные образы и runtime (среда выполнения). Docker следует этим спецификациям, чтобы образы были совместимы с другими инструментами, вроде Podman или containerd.

Образ — это шаблон для контейнера, как архив с файлами, конфигурацией и инструкциями. Он состоит из слоев (layers) — последовательных изменений файловой системы. Каждый слой — это blob (бинарный объект), хранящий дельту (изменения) от предыдущего.

Манифест — это JSON-файл, описывающий образ: платформу (архитектуру процессора), слои, конфигурацию (команда запуска, порты). Для multi-platform образов (для разных CPU, как AMD64 и ARM) есть index-манифест, указывающий на подманифесты.

Content-addressable storage — хранение по хэшу содержимого. Каждый слой имеет уникальный хэш (SHA256), так что если слой не изменился, он не перезагружается. Это влияет на кэш: при сборке Docker проверяет хэш и использует кэш, если ничего не поменялось. "Тонкие" образы (thin images) — это когда слои минимальны, без лишних файлов, что экономит место в памяти и на диске. В памяти при запуске слои монтируются как union-файловая система (overlayfs): верхние слои перекрывают нижние, но в RAM загружается только то, что нужно.

Это позволяет эффективно хранить образы: общие слои (например, базовый Ubuntu) делятся между образами, снижая использование диска.


Регистры образов: Docker Hub, теги и управление

Регистр — это хранилище для образов, как репозиторий для кода. Docker Hub — публичный регистр, где хранятся официальные образы (например, openjdk). Можно использовать частные, вроде в AWS ECR или self-hosted.

Теги — это метки для версий образа, как "latest" или "21-jre". Образы иммутабельны (неизменяемы): после загрузки в регистр их нельзя изменить, только перезаписать тег. Это обеспечивает воспроизводимость: тег "1.0" всегда тот же.

Удаление и сборка мусора (GC): Когда вы удаляете тег, слой не удаляется сразу, если он используется другими тегами. GC (garbage collection) — процесс, который чистит неиспользуемые слои. В Docker Hub это автоматически, но в частных регистрах нужно настраивать. Нюанс: dangling images (висячие, без тегов) накапливаются и жрут место; используйте "docker image prune" для очистки.

Для Java полезно: официальные образы вроде eclipse-temurin:21-jre хранятся в Docker Hub, и теги помогают управлять версиями JVM.


Dockerfile: декларативный подход и подводные камни

Dockerfile — это текстовый файл с инструкциями для сборки образа. Он декларативный: вы описываете, что нужно, а Docker строит слои последовательно.

Ключевые инструкции:
FROM: базовый образ, например, FROM eclipse-temurin:21-jre.
RUN: выполняет команду, создает слой (например, RUN apt-get install ...).
COPY/ADD: копирует файлы в образ.
CMD/ENTRYPOINT: команда запуска.

Подводные камни:
Порядок инструкций: Docker кэширует слои по порядку. Если часто меняющийся RUN в начале, весь кэш сломается. Ставьте стабильные инструкции первыми.
Кэш: Каждый слой кэшируется по хэшу. Если файл в COPY изменился, слои ниже инвалидируются.
Слои: Много RUN создают много слоев — объединяйте в один RUN с && для минимизации. В памяти это значит меньше overhead при монтировании.

Для Java: избегайте установки лишнего в RUN, чтобы образ был маленьким.


#Java #middle #Docker #DockerFile #Docker_compose #Buildx

Современная сборка образов: BuildKit и Buildx как стандарт

BuildKit — это новый движок сборки, который с 2023 года используется по умолчанию в Docker. В отличие от старого билдера, который обрабатывал инструкции последовательно, BuildKit анализирует весь Dockerfile как граф зависимостей. Это значит, что он может выполнять независимые инструкции параллельно. Например, если у вас несколько RUN, которые не зависят друг от друга, BuildKit запустит их одновременно на разных ядрах процессора. На уровне системы это снижает время сборки: вместо линейного ожидания, вы получаете параллельное использование ресурсов, что в памяти хоста проявляется как более эффективное распределение CPU и RAM во время билда.

Одна из ключевых фишек BuildKit — улучшенный кэш. В классическом подходе кэш хранится локально и может сломаться при изменении инструкций. BuildKit вводит inline-кэш: вы можете экспортировать кэш прямо в образ или в регистр. При следующей сборке Docker pulls (загружает) этот кэш, что ускоряет процесс в CI/CD-пайплайнах (системах непрерывной интеграции и доставки). Например, если вы собираете образ в GitHub Actions, inline-кэш позволяет избежать полной перестройки каждый раз.

Еще нюанс — обработка секретов. В старом билдере пароли или API-ключи могли попасть в слои образа, что небезопасно. BuildKit позволяет передавать секреты через --secret флаг: они монтируются временно в память во время RUN, но не сохраняются в финальном образе. В памяти это работает как tmpfs (временная файловая система в RAM), так что секреты не пишутся на диск и не остаются в истории.

Buildx — это расширение BuildKit для сборки мультиплатформенных образов. Оно позволяет создавать один образ, который работает на разных архитектурах процессоров, таких как x86 (AMD64) и ARM (для Raspberry Pi или облачных инстансов). Под капотом Buildx использует эмуляцию через QEMU: для каждой платформы он запускает виртуальный билдер, собирает слой, и объединяет в манифест. Это влияет на память: эмуляция может потреблять больше RAM, но результат — универсальный образ, который Docker сам выбирает под хост.

Для Java это критично: JVM (виртуальная машина Java) имеет версии для разных платформ, и Buildx обеспечивает, что ваш образ с Java 21 будет работать везде без перестройки. Подводный камень: эмуляция медленнее нативной сборки, так что для больших проектов используйте удаленные билдеры в облаке.


Docker Compose версии 2: оркестрация для локальной разработки и CI

Оркестрация — способ запуска нескольких контейнеров как единой системы. Docker Compose v2 — это инструмент, который стал дефолтным для этого. Он позволяет описать весь стек приложений в одном YAML-файле, включая сервисы, сети и volumes (тома для хранения данных).

Compose работает как надстройка над Docker: он парсит файл docker-compose.yml и вызывает docker run для каждого сервиса. В памяти хоста это значит создание сети по умолчанию (bridge), где контейнеры общаются по именам, и volumes, которые монтируются как bind-mounts (привязки к хост-файлам) или named volumes (управляемые Docker).
Для локальной разработки Compose идеален: команда docker compose up запускает все сервисы, и вы можете отлаживать Java-приложение с базой данных, например, PostgreSQL. В CI, таком как Jenkins или GitLab CI, Compose используется для тестов: он поднимает окружение, запускает тесты и сносит все после.

Нюансы: Compose v2 быстрее v1 благодаря Go-реализации (вместо Python), и лучше интегрируется с Docker Desktop. Подводный камень — зависимости: если сервис A зависит от B, укажите depends_on, но это не гарантирует готовность (например, база данных может стартовать медленно). Для Java используйте healthchecks: в compose-файле добавьте проверку, чтобы приложение ждало базу.
Еще фишка — профили: вы можете группировать сервисы для разных сред (dev, test), чтобы не запускать все сразу.


#Java #middle #Docker #DockerFile #Docker_compose #Buildx

Примеры кода

Минимальный Dockerfile для Java 21 с использованием BuildKit

text# syntax=docker/dockerfile:1  # Включает расширения BuildKit
FROM eclipse-temurin:21-jre
WORKDIR /app  # Рабочая директория внутри контейнера
COPY target/myapp.jar /app/myapp.jar  # Копируем скомпилированный JAR
ENTRYPOINT ["java", "-jar", "/app/myapp.jar"]  # Команда запуска

Чтобы собрать с BuildKit-фичами:

docker buildx build -t myapp:latest --cache-to=type=inline . 

Inline-кэш сохранит промежуточные результаты в образе.

Если добавить

--secret id=mysecret,source=/path/to/secret

то в RUN можно использовать $mysecret без записи в слой.


Мультиархитектурная сборка с Buildx

Buildx — стандарт для создания образов под несколько платформ.

Сначала создайте билдер:

docker buildx create --name mybuilder --use. 

Затем соберите:

docker buildx build --platform linux/amd64,linux/arm64 -t repo/myapp:latest --push .

Это создаст манифест, где Docker выберет нужный вариант. В памяти во время сборки эмуляция ARM на x86 может занять до 2x больше RAM, но результат — универсальность.


#Java #middle #Docker #DockerFile #Docker_compose #Buildx

Dockerfile и образы для Java

Основы: ключевые инструкции в Dockerfile

Dockerfile — декларативный файл: вы пишете, что нужно, а Docker строит образ слой за слоем. Каждый слой — это изменение файловой системы, как кирпичик в стене.

FROM: Это основа — базовый образ, от которого вы строите.
Например, FROM openjdk:21-jre — берет официальный образ с Java Runtime Environment (JRE, среда выполнения без компилятора).
Термин "образ" — это архив с файлами, конфигурацией и инструкциями.
FROM определяет родительский слой; используйте official-образы из Docker Hub для безопасности (они сканируются на уязвимости).
Нюанс: тег (как :21-jre) фиксирует версию — избегайте :latest для воспроизводимости, иначе обновления сломают билд.

RUN: Выполняет команду внутри образа, создавая новый слой.
Например, RUN apt-get update && apt-get install -y curl — обновляет пакеты и ставит curl.
Это как запуск терминала в контейнере.
RUN запускает временный контейнер, выполняет команду и фиксирует изменения (copy-on-write в overlayfs).
Объединяйте команды в один RUN с &&, чтобы минимизировать слои — много слоев замедляют поиск файлов (overhead до 10% на I/O). Избегайте RUN для часто меняющихся частей, иначе кэш сломается (об этом позже).

COPY: Копирует файлы с хоста (вашей машины) в образ.
Например, COPY target/myapp.jar /app/myapp.jar — переносит JAR-файл (скомпилированное Java-приложение) в директорию /app. Альтернатива ADD — то же, но с распаковкой архивов.
COPY предпочитается для простоты; оно сохраняет ownership и permissions. Нюанс: если файлы меняются, слои ниже инвалидируются — ставьте COPY после стабильных RUN.

ENTRYPOINT: Фиксированная команда запуска контейнера, как "java -jar /app/myapp.jar". Она не переопределяется аргументами в docker run. Это "главный вход" — контейнер всегда стартует с этого.

CMD: Дефолтные аргументы для ENTRYPOINT или самостоятельная команда.
Например, CMD ["-Dserver.port=8080"]. Переопределяется в run.
ENTRYPOINT + CMD — для гибкости; используйте ENTRYPOINT для скрипта-обертки (проверки env, graceful shutdown). В JSON-формате (["java", "-jar"]) избегайте shell-обработки; shell-форм (java -jar) — для переменных.

Эти инструкции строят слои последовательно: FROM — база, RUN/COPY — изменения, ENTRYPOINT/CMD — запуск.


Как собрать свой первый образ с Java-приложением

Представьте, что вы готовите блюдо по рецепту — Dockerfile это рецепт, docker build — процесс приготовления, а образ — готовый продукт, который можно "запускать" сколько угодно раз.
Возьмем за основу готовый JAR-файл (это скомпилированное Java-приложение, как архив с кодом и зависимостями, созданный с помощью инструментов вроде Maven или Gradle). Если у вас нет JAR, вы можете создать простое Hello World-приложение в Java и скомпилировать его.

Предположим, ваша директория проекта выглядит так:
есть папка target с myapp.jar (результат компиляции).
Создайте в корне файл Dockerfile (без расширения, с большой D).

Вот содержимое Dockerfile для минимального примера:

textFROM eclipse-temurin:21-jre
COPY target/myapp.jar /app/myapp.jar
WORKDIR /app
ENTRYPOINT ["java", "-jar", "myapp.jar"]

Разберем, что здесь происходит:
FROM eclipse-temurin:21-jre: Базовый образ от Eclipse Temurin — это официальная дистрибуция OpenJDK, оптимизированная для контейнеров.
:21-jre значит версия Java 21 с только runtime-окружением (JRE), без компилятора (JDK). Это делает образ легче — около 200-300 МБ.
Temurin предпочтительнее openjdk, потому что он включает патчи для контейнеров (container-aware) и лучше поддерживается Adoptium. Если вы на ARM (как Mac M1), тег :21-jre-arm64, но с Buildx это автоматически.

COPY target/myapp.jar /app/myapp.jar: Копируем JAR с хоста в образ. /app — директория внутри контейнера. Нюанс: Путь target/ относительный к контексту build (текущей папке). Если JAR в другом месте, скорректируйте.

WORKDIR /app: Устанавливает рабочую директорию, как команда cd в терминале. Все последующие команды (RUN, CMD) будут оттуда. Это упрощает пути и делает образ чище.

#Java #middle #Docker #Dockerfile

ENTRYPOINT ["java", "-jar", "myapp.jar"]: Фиксированная команда запуска. Формат в скобках — exec-форма, без shell — быстрее и безопаснее (нет интерпретации переменных). При запуске контейнера Docker выполнит java -jar myapp.jar из /app.

Чтобы собрать образ, откройте терминал в директории с Dockerfile и выполните:

docker build -t myjavaapp:1.0 .

docker build: Команда для сборки.
-t myjavaapp:1.0: Тег (метка) для образа — имя:версия. Без тега — random ID.
.: Контекст — текущая директория, откуда берутся файлы для COPY.


Что происходит под капотом во время сборки?

Docker daemon читает Dockerfile строку за строкой, создавая промежуточные контейнеры для каждого слоя.
Для FROM — pull базового образа (если нет локально).
Затем RUN/COPY — запускает temp-контейнер, применяет изменения и commit'ит слой (как git commit). Каждый слой — delta (изменения) в overlayfs; кэш проверяется по хэшу (инструкция + файлы). Если все гладко, сборка занимает секунды. Вывод в терминале покажет шаги: "Step 1/4 : FROM...", с хэшами слоев.

После сборки проверьте: docker images — увидите myjavaapp:1.0 с размером. Используйте docker history myjavaapp:1.0 — покажет слои в обратном порядке, с размерами и командами. Это поможет оптимизировать: если слой большой (из-за RUN install), объедините.

Теперь запустите:

docker run myjavaapp:1.0

Контейнер стартует, выполнит JAR и выйдет (если app не daemon). Добавьте -d для фона, -p 8080:8080 для портов (если app сервер).

Логи:

docker logs <container-id>.</container-id>

Распространенные ошибки и как фиксить:
"No such file": JAR не найден — проверьте путь в COPY; добавьте .dockerignore для игнора лишнего (как .gitignore).
Pull failed: Нет интернета или registry down — используйте локальные образы.
Build краш в RUN: Добавьте --no-cache в build для полной перестройки (игнор кэша).
Если secrets нужны (пароли в build), используйте --secret id=mysecret,source=.env; в RUN echo $mysecret. В CI (GitHub Actions) интегрируйте с caching для ускорения.

Это базовый образ — для dev. В production добавьте healthcheck: HEALTHCHECK CMD curl -f http://localhost:8080/health.


Усложняем: многоэтапная сборка

Multi-stage build — это продвинутый подход, где вы разделяете процесс на этапы: один для компиляции кода (с полным JDK и build-tools вроде Maven), а другой — только для запуска (минимальный JRE). Это делает финальный образ компактным, без лишних инструментов, что снижает размер, ускоряет deploy и повышает безопасность (меньше vuln в production).

Пример с Maven (предполагаем, у вас есть src/ и pom.xml — файл конфигурации Maven):

text# Этап 1: Сборка приложения
FROM maven:3.9.6-eclipse-temurin-21 AS build
COPY src /app/src
COPY pom.xml /app
WORKDIR /app
RUN mvn clean package -DskipTests

# Этап 2: Runtime-окружение
FROM eclipse-temurin:21-jre
COPY --from=build /app/target/myapp.jar /app/myapp.jar
WORKDIR /app
ENTRYPOINT ["java", "-jar", "myapp.jar"]

AS build: Имя первого этапа — можно ссылаться в COPY --from.
RUN mvn clean package: Компилирует JAR, пропуская тесты для скорости (-DskipTests). В памяти: Maven кэширует deps в /root/.m2, но в multi-stage это не сохраняется в финале.
COPY --from=build: Берет только JAR из первого этапа — остальное (JDK, Maven) отбрасывается.

Сборка:

docker build -t myjavaapp:prod . 

Финальный образ ~150-300 МБ vs 1ГБ+ с JDK. В BuildKit (дефолт) этапы могут параллелизоваться, если нет зависимостей; используйте --target=build для остановки на первом этапе (тесты).
Нюанс: Если deps меняются редко, копируйте pom.xml первым, затем RUN mvn dependency:go-offline — кэш deps сохранится. В CI добавьте cache-from для reuse.
Подводные камни: Если тесты нужны, уберите -DskipTests; для Gradle замените на FROM gradle:8.10-jdk21 и RUN gradle build.


#Java #middle #Docker #Dockerfile

Alpine vs Slim vs Distroless: плюсы и минусы

Выбор базового образа влияет на размер, производительность и совместимость. Давайте сравним варианты для Java.

Alpine (eclipse-temurin:21-jre-alpine):
Основан на легком Linux-дистрибутиве с musl libc (библиотека C). Плюсы: Очень маленький (~70-100 МБ), быстро загружается, экономит диск/сеть.
Минусы: Musl не полностью совместим с glibc (стандарт в Java) — проблемы с нативными библиотеками (JNI), шрифтами, локалями или DNS. Чревато крашами в enterprise-apps.
Когда использовать: Простые сервисы без native-кода; тестируйте entropy (-Djava.security.egd=file:/dev/./urandom для random). Musl легче в памяти (меньше overhead), но glibc стабильнее для legacy.

Slim (eclipse-temurin:21-jre-slim):
На базе Debian slim (урезанный).
Плюсы: Glibc-совместимость, размер ~150-250 МБ, включает базовые утилиты.
Минусы: Больше Alpine, но все равно минимален по сравнению с full. Когда: Баланс — для apps с зависимостями (шрифты, crypto). Senior: Добавьте RUN apt-get install -y fontconfig для fonts; лучше для multi-platform.

Distroless (gcr.io/distroless/java21:nonroot):
Сверхминимальный, без ОС-утилит. Плюсы: ~50-100 МБ, высокая безопасность (нет shell — хакеры не запустят команды), immutable.
Минусы: Нет инструментов для debug (bash, jcmd); вручную добавляйте CA-certs (COPY /etc/ssl/certs).
Чревато: Нет tzdata — env TZ=UTC; signals ok, но shutdown-hooks в коде. Когда: Production, где security > удобство. В Kubernetes — идеал для scaling; используйте debug-sidecar для отладки.

Выбор: Начните с Slim для dev, перейдите на Distroless для prod. Всегда тестируйте под load — проверьте java -version в run.


Как работает кэширование слоёв и почему важен порядок инструкций

Кэширование слоёв — это один из самых мощных механизмов Docker, который делает повторные сборки образов быстрыми и эффективными. Без него каждая сборка начиналась бы с нуля, что занимало бы много времени, особенно для сложных приложений с установкой зависимостей. Представьте кэш как "память" Docker — если ничего не изменилось в части рецепта (Dockerfile), он использует готовый результат из предыдущей сборки, вместо того чтобы готовить заново.

Каждый слой в образе — это результат выполнения одной инструкции в Dockerfile (FROM, RUN, COPY и т.д.). Docker присваивает каждому слою уникальный идентификатор на основе хэша (обычно SHA256). Хэш рассчитывается не только от самой инструкции, но и от её контекста: для RUN — это текст команды, для COPY — checksum (контрольная сумма) копируемых файлов, для FROM — тег базового образа. Если при следующей сборке хэш совпадает с кэшированным, Docker пропускает выполнение и берет готовый слой из локального хранилища.

Процесс кэширования шаг за шагом:
Проверка кэша при старте сборки: Когда вы запускаете docker build, Docker daemon (фоновый процесс, управляющий сборками) сканирует Dockerfile сверху вниз. Для первой инструкции (обычно FROM) он проверяет, есть ли в локальном кэше слой с таким же хэшем. Если базовый образ изменился (например, обновился в registry), кэш инвалидируется, и Docker pull'нет свежую версию.


#Java #middle #Docker #Dockerfile

Расчет хэша для каждой инструкции: Для RUN хэш включает точный текст команды (даже пробелы важны).
Для COPY/ADD — хэш файлов: Docker tar'ит (архивирует) контекст сборки (директорию с Dockerfile) и вычисляет checksum. Если файл изменился хоть на байт, хэш новый. В памяти хоста это происходит быстро: daemon использует минимум RAM, но для больших контекстов (много файлов) tar может занять время.

Использование кэша: Если хэш match, Docker копирует слой из /var/lib/docker/overlay2 (хранилище слоёв на диске). Нет выполнения команды — экономия времени и ресурсов. Если нет — создает временный контейнер, выполняет инструкцию и commit'ит новый слой.

Инвалидация цепочки: Вот ключевой момент — кэш цепной. Если слой N изменился, все слои ниже (N+1, N+2...) инвалидируются, даже если их инструкции не поменялись. Это потому, что каждый слой строится на предыдущем (union-файловая система).

В памяти и на диске: Кэш хранится локально, занимая диск (сотни МБ для образов). Нет загрузки в RAM до запуска контейнера. Но в CI/CD (системах непрерывной интеграции, как GitHub Actions) кэш может быть shared через registry — с BuildKit используйте --cache-to=type=inline или type=registry для экспорта.

Почему порядок инструкций так важен? Потому что он напрямую влияет на частоту инвалидации кэша.
Идея: ставьте стабильные, редко меняющиеся инструкции в начало, а изменяемые — в конец. Это минимизирует перестройки.

Пример плохого порядка (кэш часто ломается):

textFROM eclipse-temurin:21-jre
COPY src /app/src  # Код меняется часто — хэш новый каждый раз
RUN mvn clean package  # Зависимости перестраиваются заново
COPY target/myapp.jar /app/myapp.jar
Здесь COPY src в начале — если код изменился (что бывает часто), RUN mvn ниже инвалидируется, и вся компиляция повторяется (минуты времени).

Хороший порядок (кэш работает эффективно):

textFROM eclipse-temurin:21-jre
COPY pom.xml /app  # Только файл зависимостей — меняется редко
RUN mvn dependency:go-offline  # Скачивает deps, кэшируется
COPY src /app/src  # Код в конце — меняется, но deps уже в кэше
RUN mvn clean package
COPY target/myapp.jar /app/myapp.jar
Теперь, если код изменился, только последние RUN/COPY перестроятся — deps из кэша. Экономия: 80-90% времени на повторных билдах.

Нюансы

В классическом билдере (до BuildKit) кэш линейный и последовательный. BuildKit (дефолт с Docker 18.09+, обязательно с 23.0) строит граф зависимостей: анализирует весь Dockerfile и выполняет независимые инструкции параллельно (на multi-core CPU). Например, несколько RUN без зависимостей — одновременно. Это ускоряет в 2-5 раз.
Флаги: --cache-from=remote для pull кэша из registry в CI; --cache-to=type=gha для GitHub Actions.

.dockerignore: Файл в корне, как .gitignore — исключает файлы из контекста (не tar'ятся). Например, игнор target/, node_modules — ускоряет build, снижает размер контекста (max 100-200 МБ, иначе ошибки).
"Застрявший" кэш: Если хэш неверный (баги, изменения env), используйте --no-cache в build — полная перестройка. Или docker builder prune — чистка кэша (освобождает диск).
Multi-platform и кэш: С Buildx (--platform linux/amd64,linux/arm64) кэш per-архитектура: отдельно для x86 и ARM. Эмуляция (QEMU) жрёт RAM (до 2x), но манифест объединяет.
Секреты и кэш: Пароли в RUN попадут в слой — используйте --secret для временного mount в память (tmpfs, не на диск).
Влияние на Java: Для Maven/Gradle deps кэшируются в слое, но в multi-stage — не в финале. Если deps большие (сотни МБ), оптимизируйте порядок для CI — сэкономите bandwidth.

В Docker Desktop (Mac/Windows) кэш медленнее из-за VM-layer; используйте mutagen или volume-sync для ускорения. Тестируйте: Соберите дважды — второй раз должен быть мгновенным, если ничего не изменилось.


#Java #middle #Docker #Dockerfile

JVM в контейнере: настройки памяти и сборка мусора

JVM (виртуальная машина Java) в Docker требует специальной настройки, потому что контейнеры ограничивают ресурсы, и без адаптации приложение может крашнуться.

-Xmx и -XX:+UseContainerSupport: Флаг -Xmx задаёт максимальный размер кучи (heap — области для объектов Java), например, -Xmx512m.
Но в контейнере это опасно: если docker run --memory=1g, а -Xmx не задан или больше лимита, JVM возьмёт больше памяти, и система убьёт процесс (OOM-killer).
Флаг -XX:+UseContainerSupport (включен по умолчанию в Java 10 и выше) делает JVM "container-aware": она читает лимиты из cgroups (/sys/fs/cgroup/memory/memory.limit_in_bytes) и автоматически подстраивает heap под доступную память. В коде это видно через Runtime.getRuntime().maxMemory() — возвращает скорректированное значение (обычно 75% от лимита минус резервы JVM).
Не дублируйте -Xmx — используйте -XX:MaxRAMPercentage=80 для максимального процента от cgroup-лимита и -XX:InitialRAMPercentage=50 для стартового. Это позволяет динамически scaling в Kubernetes. Следите за native memory (память вне heap: нити, буферы, Metaspace для классов) — лимитируйте -XX:MaxMetaspaceSize=256m, иначе утечки съедят весь RAM. Включайте -XX:NativeMemoryTracking=detail для трекинга (overhead ~5%, но покажет breakdown).
В старых Java (8u131-) флаг не работает — обновляйтесь.


Сборка мусора в контейнерах: GC — процесс очистки кучи от "мусора" (ненужных объектов). В контейнере лимиты CPU и памяти влияют: низкая память — частые GC, низкий CPU — длинные паузы (app замирает). Выбор GC зависит от приложения.

G1GC (-XX:+UseG1GC, дефолт с Java 9): "Garbage-First" делит heap на регионы (по 1-32 МБ) и чистит "мусорные" первыми.
Плюсы: баланс между производительностью (throughput) и паузами (low-latency), подходит для heap 1-32 ГБ.
В контейнере: Учитывает cgroups — запускает GC раньше, минимизируя OOM. Паузы: 50-200 мс.
Настройте -XX:G1HeapRegionSize=2m для маленьких heap; -XX:ConcGCThreads=4 для CPU-квот. Если паузы высокие — мониторьте с -XX:+PrintGCDetails и JFR (Java Flight Recorder).

ZGC (-XX:+UseZGC, стабильный в Java 15+): Concurrent GC — чистит параллельно с app, паузы <10 мс даже на терабайтных heap.
Плюсы: Для high-throughput/low-pause apps (trading, streaming).
Минусы: Требует много CPU — при docker --cpus=2 throttling (замедление) растянет паузы.
В контейнере: Хорошо масштабируется, но тестируйте под load. В Java 21 — production-ready; -XX:ZCollectionInterval=5s для частоты; используйте для pause-sensitive микросервисов.

Shenandoah (-XX:+UseShenandoahGC): Похож на ZGC, но с evacuation (перемещением объектов) concurrently.
Плюсы: Лучше адаптируется к variable loads, низкие паузы.
Минусы: Меньше сообщества (Red Hat-driven).
В контейнере: Отлично для dynamic environments.
-XX:ShenandoahGCHeuristics=adaptive для auto-tune; комбинируйте с virtual threads (Java 21) для IO-bound apps.

Влияние cgroups: Runtime.maxMemory() = cgroup memory limit - JVM reserves (10-20%). При --cpus=0.5 GC использует меньше нитей (-XX:ParallelGCThreads auto-подстраивается).
Тестируйте: Запустите с -verbose:gc для логов; используйте JFR (-XX:StartFlightRecording) для профилей.
Нюанс: Virtual threads (Java 19+, stable 21) снижают overhead нитей (миллионы без OOM), но GC не меняется — они в heap. Для CPU-bound — ForkJoinPool лучше.
В production: Мониторьте с Prometheus JMX exporter.


#Java #middle #Docker #Dockerfile