Современная сборка образов: 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

Фундамент Docker и его экосистемы

Что такое контейнеризация и чем она отличается от виртуализации

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

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

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

Контейнеризация легче: нет эмуляции ядра, overhead 1-5%, запуск — секунды, образы — сотни мегабайт. Но минус — меньшая изоляция: уязвимость в ядре может затронуть все контейнеры.
В контейнерах используйте seccomp (фильтры системных вызовов) и AppArmor/SELinux для усиления безопасности. В производительности контейнеры выигрывают для микросервисов, но VM лучше для разнородных ОС (Windows в Linux-хосте через эмуляцию).


Архитектура Docker: Engine, Daemon, CLI и Registry

Docker — это не монолит, а экосистема компонентов.

Docker Engine — это (ядро) системы, включающее все для создания и запуска контейнеров. Он состоит из даемона (демона — фонового процесса) и CLI (командной строки). Engine работает на хосте, управляя контейнерами через API.
Docker Daemon (dockerd) — серверный процесс, который слушает запросы по сокету или TCP. Он взаимодействует с ядром ОС: создает namespaces, cgroups, управляет образами и контейнерами. В памяти daemon держит состояние: список контейнеров, кэш образов.

Нюанс: daemon — single-threaded в некоторых частях, так что при большом нагрузке (сотни контейнеров) мониторьте /var/run/docker.sock на bottlenecks. Используйте --debug для логов.

CLI (docker) — клиент, который отправляет команды daemon'у. Например, docker run — это запрос к daemon на создание контейнера. CLI парсит аргументы и общается по API. Для удаленного управления настройте TLS для безопасности.

Registry — хранилище образов, как репозиторий. Docker Hub — публичный (бесплатный для open-source), но есть частные (AWS ECR, Google Artifact Registry). Registry хранит образы в формате OCI (стандарт для совместимости). При pull (загрузке) daemon проверяет аутентификацию и скачивает слои.

Нюанс: registry использует content-addressable storage (хранение по хэшу), так что слои не дублируются. Настройте garbage collection (GC) в registry, чтобы чистить dangling слои (неиспользуемые), иначе диск заполнится.

В целом архитектура клиент-серверная: CLI -> Daemon -> Ядро ОС. Для swarm (оркестрации) добавляется manager, но это позже.


#Java #middle #Docker

Образы и контейнеры: слоистая файловая система

Образ — это шаблон, как архив с файлами и инструкциями для контейнера. Контейнер — запущенный экземпляр образа, как процесс из шаблона.
Образы строятся слоями: каждый слой — изменение файловой системы (добавление файлов, установка пакетов). Слоистая файловая система (UnionFS, конкретно overlay2 в Docker) объединяет слои: нижние — read-only, верхний — writable для контейнера. В памяти при запуске слои монтируются: overlayfs использует copy-on-write (копирование при записи), так что изменения не трогают базовые слои, экономя диск. Например, если 10 контейнеров от одного образа, базовые слои shared.

UnionFS влияет на производительность — много слоев замедляют поиск файлов (до 10-20% overhead). Оптимизируйте: объединяйте RUN в Dockerfile. В памяти: слои загружаются lazily (по мере нужды), но при pull все скачивается.


Жизненный цикл контейнера

Жизненный цикл контейнера — это последовательность этапов, через которые проходит контейнер от момента его создания до полного удаления. Представьте контейнер как живой организм — он рождается, живет, работает и умирает, но все это под контролем Docker.

Жизненный цикл начинается с образа — статического шаблона.

Когда вы решаете запустить контейнер, Docker проходит следующие следующие шаги:

Загрузка образа (Pull): Если образа нет локально на вашей машине, Docker скачивает его из регистра (хранилища, как Docker Hub). Это происходит автоматически при команде docker run, если образ не найден.
Под капотом: daemon проверяет локальный кэш по тегу (метке версии, например, :latest), затем обращается к registry по HTTP/HTTPS. Слои скачиваются параллельно, если поддерживает registry.
Нюанс: pull может быть дорогим по сети — используйте локальные зеркала или caching-proxy в CI/CD. Если образ большой (гигабайты), это влияет на время старта; оптимизируйте размер слоев.
В памяти: скачанные слои хранятся в /var/lib/docker/overlay2, используя диск, но не RAM до запуска.

Создание контейнера (Create): Команда docker create аллоцирует ресурсы, но не запускает процессы. Docker создает уникальный ID для контейнера, настраивает namespaces (изолированные пространства для процессов, сети, файлов), cgroups (ограничения на CPU, память) и монтирует слоистую файловую систему. В этот момент контейнер — как "замороженный" шаблон: writable-слой (верхний слой для изменений) готов, но пуст.
Здесь происходит системный вызов clone() для namespaces, и cgroupfs монтируется. Если указаны volumes или networks, они attach'атся.
Подводный камень: если ресурсы хоста исчерпаны (например, мало дискового места), create провалится с ошибкой — мониторьте с docker system df.


#Java #middle #Docker

Запуск контейнера (Start или Run): Команда docker start (для созданного) или docker run (create + start) приводит контейнер в жизнь. Docker fork'ует (копирует) процесс и exec'ует (заменяет) его на ENTRYPOINT или CMD из образа — это становится PID 1 (первым процессом) в контейнере. Процессы стартуют в изолированном окружении: сеть подключается, порты expose'ятся, env-переменные устанавливаются.
В памяти: процессы контейнера появляются в хост-PS, но с метками cgroup. Overhead минимален — 1-2 МБ на контейнер плюс приложение.
Нюанс: запуск занимает миллисекунды, но если образ с init-скриптами (например, база данных), это может затянуться. Используйте healthchecks (docker run --health-cmd) для проверки готовности — это критично в оркестрации, чтобы не слать трафик на "холодный" контейнер.

Работа контейнера (Running): Контейнер выполняет свою задачу: ваше приложение бежит, обрабатывает запросы, пишет логи. Docker мониторит состояние: если PID 1 выходит (exit code 0 — успех, ненулевой — ошибка), контейнер останавливается. Логи доступны через docker logs.
В памяти: ресурсы потребляются динамически — cgroups enforced лимиты, так что при превышении памяти OOM-killer может убить процессы (приоритет по oom_score). Мониторьте с docker stats или Prometheus exporter; учитывайте, что restart-policy (docker run --restart=always) может перезапускать при сбоях, но это маскирует root-cause.

Пауза и возобновление (Pause/Unpause): Опционально, docker pause замораживает процессы (сигнал SIGSTOP), сохраняя состояние в памяти. Unpause (SIGCONT) продолжает. Полезно для maintenance.
Нюанс: пауза не освобождает ресурсы полностью — RAM все равно занята.

Остановка контейнера (Stop): Команда docker stop посылает SIGTERM (сигнал мягкой остановки) PID 1, дает grace-period (по умолчанию 10 секунд) на shutdown, затем SIGKILL (принудительное убийство). Это позволяет приложению gracefully закрыться: сохранить данные, завершить транзакции. Если PID 1 — Java или shell, который не ловит сигналы, используйте --init или tini для forwarding. В production настройте timeout (--time=30) для долгоживущих shutdown.

Удаление контейнера (Remove): Docker rm чистит все: удаляет writable-слой, освобождает namespaces/cgroups, detach'ит volumes/networks. Если --rm в run, удаление автоматическое.
Нюанс: stopped-контейнеры хранят состояние (файлы, логи) — используйте docker ps -a для просмотра. Dangling resources (неудаленные volumes) накапливаются — чистите с docker system prune; в скриптах автоматизируйте rm для избежания утечек диска.

Весь цикл обеспечивает воспроизводимость: контейнеры эфемерны (временны), данные persist в volumes. Подводный камень: в кластерах (Swarm/Kubernetes) lifecycle управляется оркестратором, с auto-restart и rolling updates.


#Java #middle #Docker

Базовые настройки: volumes, networks и environment variables

После запуска контейнера важно настроить его взаимодействие с внешним миром. Эти настройки — как "провода" для данных, связи и конфигурации.

Volumes — механизм для хранения данных вне контейнера, чтобы они пережили удаление.
Есть два типа:
bind-mount (привязка к директории хоста, docker run -v /host/path:/container/path) и named volume (управляемый Docker, -v myvol:/path).
Volumes монтируются в FS контейнера, позволяя читать/писать persistently. Это как внешний жесткий диск для контейнера.
В памяти: данные на диске хоста, но доступ через namespace — нет overhead, кроме I/O.
Нюанс: bind-mounts делят permissions (права доступа) с хостом, что рискованно; используйте named volumes с docker volume create для изоляции.
В production: volume drivers (plugins) для облака, как AWS EBS, но следите за latency — медленные volumes замедляют app. Чистите unused volumes с prune, иначе диск заполнится.

Networks — для связи контейнеров между собой или с внешним миром. По умолчанию — bridge (локальная виртуальная сеть, контейнеры общаются по именам).
Другие:
host (делит сеть хоста, no isolation — быстро, но небезопасно), overlay (для multi-host в Swarm).
Docker создает network namespace: каждый контейнер имеет veth-интерфейс (virtual ethernet). Bridge использует NAT (network address translation) для внешнего доступа, с overhead 5-10% на трафик. Expose порты с -p 80:80 (host:container).
В production: custom networks для изоляции (docker network create mynet), и firewall (ufw/iptables) для безопасности.

Environment variables (переменные окружения, -e KEY=VALUE) — способ передать конфиг в контейнер, как API_KEY или DB_URL. Они устанавливаются в env процесса PID 1 и доступны в коде (System.getenv в Java). Это как настройки в панели управления.
В памяти: хранятся в process-env, минимум overhead.
Нюанс: не храните секреты в env — они видны в docker inspect или ps aux; используйте --secret или Docker Secrets в Swarm. Env влияют на эргономику (например, JAVA_OPTS), но перезапись в Dockerfile с ENV фиксирует их в слое — избегайте для sensitive данных.

Эти настройки комбинируются: например, volume для DB-data, network для связи с backend, env для creds.


Разница между образами для разработки и для production

Образы адаптируются под стадию: dev — для удобства, prod — для эффективности и безопасности.

В dev: используйте полный JDK (для компиляции), добавьте debug-tools (jdb, maven), volumes для mount кода (hot-reload). Образ большой (1ГБ+), с shell для exec (docker exec -it для отладки). Multi-stage build: stage1 — build с JDK, stage2 — copy artifacts в JRE.

В production: минимальный JRE или distroless (без shell, утилит — поверхность атаки меньше). Удалите dev-зависимости, оптимизируйте слои (unite RUN). Размер 100-200МБ, immutable (неизменяемый).
Нюанс: в prod учитывайте container-aware JVM (лимиты cgroups), signals для shutdown, entropy для crypto. Тестируйте под real limits; используйте scanning (Trivy) для vuln. Dev-образы для локали/CI, prod — для deploy.


Мини-пример: запуск hello-world и openjdk образов

Установите Docker, если его нет.

Сначала hello-world — простой тест:

docker run hello-world

Pull'нет образ (~1МБ), запустит, выведет сообщение и выйдет. Проверьте docker ps -a — увидите stopped контейнер.

Для Java: openjdk:21-jre (runtime):

docker run -it --rm openjdk:21-jre java -version
-it — interactive terminal, --rm — auto-remove. Выведет версию. Добавьте --memory=512m — JVM увидит лимит и подстроит heap. Для senior: exec docker exec -it <id> bash (если shell есть) для инспекции.</id>

#Java #middle #Docker

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