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

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

Сети, Volume, ENV и логи в Docker

Основы: архитектурные компоненты Docker

Что такое Docker-сеть? Концепция изоляции и коммуникации
Docker-сеть — это виртуальная изолированная среда, построенная на механизмах ядра Linux (network namespaces, iptables, виртуальные Ethernet-пары), обеспечивающая коммуникацию между контейнерами и внешним миром.

Каждая сеть предоставляет контейнерам собственное сетевое пространство, включающее:
- Интерфейсы (loopback, Ethernet),
- Таблицы маршрутизации,
- Правила firewall (iptables/nftables).

Без сетей контейнеры не смогли бы взаимодействовать друг с другом или с хостом. Изоляция предотвращает конфликты портов (например, два контейнера с веб-сервером на порту 80) и обеспечивает безопасность через segmentation.


Docker Networking: bridge, host, overlay

1. Bridge (по умолчанию)
Bridge-сеть — изолированная сеть на уровне хоста, где контейнеры общаются через виртуальный коммутатор (bridge). Это аналог домашнего роутера: контейнеры получают внутренние IP-адреса, а трафик к внешнему миру проходит через NAT.

Как это работает:
- Docker Daemon создает bridge-интерфейс (обычно docker0) на хосте. Это виртуальный коммутатор уровня L2.

- Для каждого контейнера генерируется virtual Ethernet pair (veth):
- Один конец подключается к docker0 (на хосте),
- Второй — к network namespace контейнера (изолированное сетевое пространство).

- Network namespace — механизм ядра Linux, изолирующий сетевые ресурсы (интерфейсы, таблицы маршрутизации). Контейнер «видит» только свои интерфейсы, не мешая другим процессам.

- Трафик между контейнерами фильтруется через iptables:
- Правила NAT (POSTROUTING) маскируют исходящие пакеты (SNAT),
- Правила FORWARD разрешают коммуникацию внутри сети.

Пример:

docker run -d --name web nginx

- Контейнер web получает IP вида 172.17.0.2 в сети docker0.
- При запросе curl http://web с другого контейнера в той же сети:
1. DNS-резолвер Docker преобразует web в 172.17.0.2,
2. Пакет передается через veth-пару в docker0,
3. Доставляется в контейнер web без участия хоста.

Нюансы:
- Проброс портов (-p 8080:80) добавляет правило в цепочку DOCKER iptables, перенаправляющее трафик с хоста в контейнер.
- Для связи между контейнерами в разных bridge-сетях требуется user-defined bridge (создается через docker network create).


2. Host-сеть
Контейнер использует сетевой стек хоста напрямую, без изоляции. Это как запуск процесса на хосте, но с изоляцией процессов и файловой системы.

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

Пример:

docker run --network host -d nginx

- Nginx слушает порт 80 на хосте напрямую.
- Нет накладных расходов на NAT, но конфликты портов неизбежны при запуске нескольких сервисов.

Когда использовать:
- Для высокопроизводительных сетевых утилит (tcpdump, haproxy),
- В embedded-системах, где изоляция не требуется.


3. Overlay-сеть
Сеть для multi-host оркестрации (требует Docker Swarm или Kubernetes). Позволяет контейнерам на разных серверах общаться как в одной локальной сети.

Как это работает:
- Использует VXLAN (Virtual Extensible LAN) для туннелирования трафика между узлами.
- VXLAN — технология инкапсуляции L2-кадров в UDP-пакеты. Каждый пакет получает заголовок с VXLAN Network Identifier (VNI), идентифицирующим сеть.
- Распределенное хранилище (Consul/Etcd) синхронизирует состояние сети между нодами.

- Encap/Decap:
- При отправке пакета с узла A на узел B:
1. Данные инкапсулируются в UDP-дейтаграмму с VNI,
2. Передаются по физической сети,
3. На узле B извлекаются из туннеля.

Пример:

docker network create -d overlay my_overlay

- Требует открытия портов:
- 7946 (TCP/UDP) — для обнаружения узлов,
- 4789 (UDP) — для VXLAN-трафика.

Нюансы:
- Задержки выше, чем в bridge, из-за инкапсуляции.
- В Kubernetes вместо overlay используется CNI (Container Network Interface) с плагинами (Calico, Flannel).

#Java #middle #Docker #Bridge #Host #Overlay

Volumes и bind-mounts: управление данными

Volume — это механизм хранения данных, независимый от жизненного цикла контейнера. В отличие от данных внутри контейнера (которые удаляются при его остановке), volume сохраняет информацию даже после удаления контейнера. Это достигается через выделение отдельного места на диске хоста с управлением через Docker Engine.

Зачем это нужно?
- Персистентность данных (БД, конфиги),
- Обмен данными между контейнерами,
- Изоляция от изменений на хосте.


1. Named Volumes
Именованные тома, управляемые Docker. Хранятся в /var/lib/docker/volumes/.

Как это работает:
- Docker создает том в /var/lib/docker/volumes/db_data/_data.
- При монтировании в контейнер используется bind mount с флагом rprivate (изоляция от изменений на хосте).
- OverlayFS: Для образов с несколькими слоями volume монтируется как верхний writable-слой.

Пример:

volumes:
  db_data:
services:
  db:
    volumes:
      - db_data:/var/lib/postgresql/data

- При старте контейнера:
1. Docker проверяет наличие тома db_data,
2. Если том новый — инициализирует его пустой директорией,
3. Монтирует в контейнер через mount-системный вызов.

Нюансы:
- Владелец тома — пользователь внутри контейнера (например, postgres в образе PostgreSQL).
- При удалении контейнера том не удаляется — требуется docker volume prune.


2. Bind Mounts
Прямое сопоставление директории хоста и контейнера.

Как это работает:
- Ядро Linux связывает inode хоста (./logs) и контейнера (/app/logs) через mount namespace.
- Все операции записи в /app/logs отражаются на хосте в ./logs.

Пример:

services:
  app:
    volumes:
      - ./logs:/app/logs

- inode — уникальный идентификатор файла в файловой системе. При bind mount inode хоста и контейнера совпадают.

Критические ограничения:
- Производительность ниже, чем у named volumes (отсутствие кэширования overlayfs),
- Риск повреждения данных при одновременной записи из хоста и контейнера.

#Java #middle #Docker #Volumes

Переменные окружения (ENV, .env)

Это динамические пары ключ=значение, доступные процессу во время выполнения. В Linux они хранятся в памяти процесса как null-terminated строки (например, PATH=/usr/bin).

Как это работает в Docker:
- При старте контейнера Docker Daemon добавляет переменные в process namespace через execve-системный вызов.
- Значения копируются в память процесса (PID 1 контейнера) при его создании.

Пример:

environment:
  DB_URL: jdbc:postgresql://db:5432/mydb

- Внутри контейнера переменная доступна через:

  cat /proc/1/environ | tr '\0' '\n'  # PID 1 — процесс Java
  

Нюансы безопасности:
- Переменные видны в docker inspect и через /proc/<pid>/environ,
- Никогда не передавайте секреты через environment — используйте Docker Secrets или Vault.


Продвинутые сценарии

Секреты: от Docker Secrets до Vault

Что такое секреты в контексте Docker?
Это конфиденциальные данные (пароли, токены), требующие защищенного хранения и передачи. В отличие от переменных окружения, секреты шифруются и изолируются от неавторизованного доступа.

Docker Secrets (Swarm mode)

Как это работает:
- Секреты монтируются как файлы в /run/secrets/ через tmpfs (RAM-диск).
- При монтировании устанавливаются права 000 — доступ только через docker exec.
- Шифрование: секреты передаются по TLS между менеджерами Swarm и хранятся в Raft-логе шифрованными.

Пример:

echo "my_password" | docker secret create db_password -

- Raft-лог: Алгоритм консенсуса для распределенных систем. В Swarm используется для синхронизации состояния секретов.

Недостатки:
- Не подходит для Compose (требует Swarm),
- Нет ротации — при обновлении секрета нужно пересоздавать сервис.


Конфигурация логирования: драйверы и их особенности

Что такое драйвер логирования?
Это модуль, определяющий, как Docker перехватывает и обрабатывает stdout/stderr контейнера. По умолчанию используется json-file, но можно подключить сторонние системы (Fluentd, Syslog).

Как это работает:
- Docker Daemon перехватывает потоки stdout/stderr через pipe (канал межпроцессного взаимодействия).
- Данные передаются в драйвер, который форматирует и отправляет их в указанное место.

Пример для gelf:

logging:
  driver: gelf
  options:
    gelf-address: "udp://graylog:12201"

- GELF (Graylog Extended Log Format) — бинарный формат для структурированных логов.

Поддерживает поля:

  {"version": "1.1", "host": "app", "short_message": "Error", "level": 3}
  

Нюансы:
- UDP не гарантирует доставку — возможна потеря логов при перегрузке,
- Для надежности используйте tcp вместо udp, но снизится производительность.

#Java #middle #Docker #env

Тонкая настройка JVM через переменные окружения

Control Groups (cgroups) — механизм ядра Linux для ограничения, учета и изоляции использования ресурсов (CPU, память, дисковый I/O) группой процессов. Docker использует cgroups для ограничения ресурсов контейнера.

Как это влияет на JVM?
- Если в контейнере установлен лимит памяти (--memory=512m), JVM не видит его по умолчанию и пытается выделить память, превышающую лимит.

Решение:

  environment:
    JAVA_TOOL_OPTIONS: "-XX:MaxRAMPercentage=75.0"
  
  - -XX:MaxRAMPercentage указывает JVM использовать 75% от лимита cgroups, а не от общей памяти хоста.  

Как это работает:
- JVM читает лимиты из /sys/fs/cgroup/memory/memory.limit_in_bytes (путь внутри cgroup контейнера).
- При старте выделяет heap через mmap с учетом лимита.

Критические ошибки:
- Если -Xmx превышает лимит cgroups, JVM упадет с Native memory allocation (mmap) failed.
- Для контейнеров никогда не используйте `-Xmx` без учета cgroups.


Пример: Java-сервис с ENV и логами в volume

docker-compose.yml

version: '3.8'
services:
  app:
    build: ./app
    environment:
      DB_URL: jdbc:postgresql://db:5432/mydb
      DB_PASSWORD: ${DB_PASSWORD}
    volumes:
      - app_logs:/app/logs
    logging:
      driver: json-file
      options:
        max-size: "50m"
    networks:
      - app_net

  db:
    image: postgres:15
    environment:
      POSTGRES_DB: mydb
      POSTGRES_PASSWORD: ${DB_PASSWORD}
    volumes:
      - pg_data:/var/lib/postgresql/data
    networks:
      - app_net

volumes:
  app_logs:
    driver: local
  pg_data:

networks:
  app_net:
    driver: bridge

Концептуальное объяснение:
1. Сеть app_net:
- Создает bridge-сеть через docker network create.
- Контейнеры app и db получают IP в подсети 172.18.0.0/16 и могут общаться по именам (db:5432).

2. Том pg_data:
- Хранится в /var/lib/docker/volumes/pg_data/_data.
- При старте PostgreSQL инициализирует данные в этом каталоге.

3. Логирование:
- Драйвер json-file пишет логи в /var/lib/docker/containers/<id>/<id>-json.log.
- При достижении 50m файл ротируется, сохраняя 3 архива.

Код Java-приложения:

public class Main {
  public static void main(String[] args) {
    String dbUrl = System.getenv("DB_URL"); // Чтение из process namespace
    try (Connection conn = DriverManager.getConnection(
        dbUrl, "user", System.getenv("DB_PASSWORD"))) {
      // Запись в файловый лог
      try (FileWriter fw = new FileWriter("/app/logs/application.log", true)) {
        fw.write("DB connection established\n");
      }
    }
  }
}

Почему это работает:
- Переменные DB_URL и DB_PASSWORD передаются через process namespace, что безопаснее hardcode.
- Том app_logs изолирует логи от жизненного цикла контейнера — данные сохраняются после docker-compose down.
- JVM учитывает лимиты cgroups благодаря -XX:MaxRAMPercentage.


Best practices

1. Сети:
- Bridge — для локальной разработки,
- Overlay/CNI — для продакшена,
- Host — только для специфических задач.

2. Volumes:
- Named volumes — для БД и персистентных данных,
- Bind mounts — только для разработки (hot-reload).

3. Секреты:
- Всегда используйте Vault или Kubernetes Secrets в продакшене,
- Избегайте .env для секретов — он не шифруется.

4. Логирование:
- Настройте централизованное логирование (Fluentd + Elasticsearch),
- Используйте gelf или fluentd вместо json-file в продакшене.

5. JVM:
- Всегда ограничивайте память через -XX:MaxRAMPercentage,
- Проверяйте лимиты cgroups через cat /sys/fs/cgroup/memory/memory.limit_in_bytes.


#Java #middle #Docker #best

Production практики для Java в Docker


Управление сборкой и архитектурой

Build args (ARG vs ENV): передача параметров при сборке

- ARG — переменная, доступная только на этапе сборки образа. Не сохраняется в финальном образе.
- ENV — переменная, доступная во время выполнения контейнера. Сохраняется в образе.

Как это работает:
- При выполнении docker build --build-arg JAVA_VERSION=17 . значение JAVA_VERSION передается в Dockerfile через ARG.
- Если ARG используется в ENV, его значение копируется в образ:

  ARG JAVA_VERSION=17
  ENV JAVA_VERSION=${JAVA_VERSION}
  Здесь JAVA_VERSION станет частью образа и будет доступна в runtime.

Нюансы безопасности:
- Никогда не передавайте секреты через ARG без флага --secret (например, токены для приватных репозиториев):

  docker build --secret id=github,src=./github.token .
  

В Dockerfile:

  RUN --mount=type=secret,id=github \
      git clone https://$(cat /run/secrets/github)@github.com/private/repo.git
  

- Почему это важно: Секреты, переданные через ARG, попадают в историю образа (видны в docker history).

Пример для Maven:

ARG MAVEN_VERSION=3.8.6
ARG USER_HOME_DIR="/root"
RUN mkdir -p /usr/share/maven && \
    curl -fsSL "https://archive.apache.org/dist/maven/maven-3/${MAVEN_VERSION}/binaries/apache-maven-${MAVEN_VERSION}-bin.tar.gz" \
    | tar -xzC /usr/share/maven --strip-components=1

- MAVEN_VERSION используется только при загрузке Maven и не сохраняется в образе.


Multi-arch образы (ARM64 vs x86) и кросс-сборка

Образы, собранные для разных архитектур процессоров (x86_64, ARM64), чтобы запускаться на любом устройстве — от серверов до Raspberry Pi.

Как это работает:
- Docker использует QEMU для эмуляции архитектур через binfmt_misc (механизм ядра Linux).
- Buildx — расширение Docker CLI для кросс-платформенной сборки:

  docker buildx create --use
  docker buildx build --platform linux/amd64,linux/arm64 -t myapp:latest .
  

- При пушинге в реестр создается manifest list — файл, описывающий образы для разных архитектур.

Нюансы:
- Эмуляция через QEMU:
- Требует установки qemu-user-static:

docker run --rm --privileged multiarch/qemu-user-static --reset -p yes
    

- Замедляет сборку на 20-30% из-за эмуляции.

- Сборка нативно:
- Для ARM64 используйте серверы с ARM-процессорами (AWS Graviton, Raspberry Pi).
- В CI/CD настройте параллельную сборку для каждой архитектуры.

Пример для Java:

# Сборка под ARM64 и x86_64
FROM --platform=$BUILDPLATFORM openjdk:17 AS builder
ARG TARGETARCH
RUN echo "Собираем под архитектуру: ${TARGETARCH}"
COPY . .
RUN ./mvnw package -DskipTests

- Переменная TARGETARCH автоматически устанавливается Buildx (значения: amd64, arm64).


Использование .dockerignore для ускорения сборки

Файл, исключающий ненужные директории/файлы из build context — набора данных, передаваемых Docker Daemon при сборке.

Почему это критично:
- Build context отправляется в память Docker Daemon через сокет.
- Если в контексте есть target/ (500 МБ), сборка замедлится из-за передачи данных.

Типичное содержимое .dockerignore:

.git
.gitignore
**/target/
**/*.log
**/.idea/
**/.vscode/
docker-compose.yml

Как это работает:
1. При docker build . CLI сканирует текущую директорию.
2. Файлы из .dockerignore исключаются из контекста.
3. Оставшиеся данные архивируются и отправляются в память Docker Daemon (через /var/run/docker.sock).

Нюанс:
- .dockerignore не влияет на COPY в Dockerfile. Если файл исключен из контекста, COPY завершится ошибкой.


#Java #middle #Docker #Production

Оптимизация образов: безопасность и размер

jlink: минимальная JVM под конкретное приложение

Инструмент JDK для создания настраиваемой JVM, включающей только необходимые модули (например, java.base, java.logging).

Как это работает:

1. Анализ зависимостей через jdeps:

jdeps --print-module-deps target/myapp.jar
Вывод: java.base,java.logging,java.xml.  
   

2. Сборка минимальной JVM:

   RUN jlink \
       --add-modules java.base,java.logging,java.xml \
       --output /jlinked \
       --strip-debug \ — удаление отладочной информации.  
       --compress 2 \ — максимальное сжатие (уменьшает размер на 30%).  
       --no-header-files \
       --no-man-pages
   

Результат:
- Стандартный образ OpenJDK 17 — 450 МБ.
- Образ с jlink — 120 МБ.

Нюансы:
- Некоторые библиотеки (например, Hibernate) требуют модуля jdk.unsupported.
- Проверяйте совместимость через --dry-run.


Distroless runtime образы (Google)

Образы без операционной системы, содержащие только JVM и ваше приложение. Созданы Google для минимизации attack surface.

Пример:

FROM gcr.io/distroless/java17-debian11
COPY --from=builder /app/target/myapp.jar /app.jar
ENTRYPOINT ["/app.jar"]

Как это работает:
- Distroless использует scratch (пустой образ) и добавляет только:
- Мусоросборщик (glibc или musl)
- Базовые сертификаты SSL,
- Минимальный набор библиотек для JVM
- Нет shell (/bin/sh), поэтому docker exec -it bash невозможен.

Преимущества:
- Размер образа — 80 МБ против 450 МБ у OpenJDK.
- Нулевой attack surface: нет curl, bash, apt для эксплуатации.

Отладка:
- Для диагностики используйте sidecar-контейнеры с curl или netcat.
- Логи читайте через docker logs, метрики — через /actuator/prometheus.


Non-root user: запуск Java-приложений безопасно

Запуск процесса Java не от root, чтобы ограничить ущерб при компрометации контейнера.

Как это работает:

# Создаем пользователя с UID 1001
RUN adduser --uid 1001 --disabled-password --gecos "" appuser
USER 1001
COPY --chown=1001:1001 target/myapp.jar /app.jar
ENTRYPOINT ["java", "-jar", "/app.jar"]

Нюансы безопасности:
- UID/GID:
- Используйте фиксированный UID (1001), чтобы избежать конфликтов с томами.
- Если том смонтирован с правами root, пользователь 1001 не сможет писать в него.
- Capabilities:
- По умолчанию контейнер получает capabilities NET_BIND_SERVICE (привязка к портам < 1024).
- Для запуска на порту 80:

    # docker-compose.yml
    app:
      cap_add:
        - NET_BIND_SERVICE
    

Критическая ошибка:
- Если приложение требует записи в /tmp, убедитесь, что директория доступна для записи:

  RUN mkdir /app/tmp && chown 1001:1001 /app/tmp
  ENV JAVA_OPTS="-Djava.io.tmpdir=/app/tmp"

#Java #middle #Docker #Debug