1. Практична межа та базовий рівень
Коли ми чуємо слово «контейнери», мозок одразу починає хотіти всього й відразу: Dockerfile, Compose, registry, Kubernetes, моніторинг, секрети, ліміти памʼяті… і ось ви, здається, хотіли лише «трішки краще запакувати jar», а раптом уже будуєте маленький датацентр на кухні. Тому нам потрібна чесна межа: який мінімум знань і дій уже робить Boot-сервіс придатним до контейнерів, але не перетворює цей курс на інфраструктурний.
До цього моменту у нас уже є вся ланка пакування на рівні Boot: jar збирається, шари видно, образ можна отримати без ручного Dockerfile. Тепер важливо зафіксувати, що з цього справді входить до нормального базового рівня, а що вже належить до сусіднього інфраструктурного треку.
В інженерному сенсі baseline — це набір речей, яких «достатньо добре» для закриття задачі в поточному контексті. У нашому випадку задача звучить не як «вивчити Docker», а як «зрозуміти, що Spring Boot уже робить для контейнерного пакування на рівні артефакту, і вміти цим користуватися».
Проблема не в тому, що executable jar поганий. Проблема в тому, що для повторного пакування він занадто груба одиниця, якщо весь сервіс їде як один моноліт. Тому сьогоднішній базовий рівень дуже приземлений: потрібно зробити видимими різні частини артефакту — залежності, loader і сам застосунок, — щоб повторне пакування не робило зайвої роботи ще раз.
2. Ланцюжок артефактів: код → образ
Якщо досі ми думали «у мене є проєкт → у мене є jar», то тепер правильніше думати «у мене є проєкт → у мене є кілька представлень одного й того самого артефакту». Це не філософія заради філософії: це прямо впливає на швидкість перезбирання образу та на те, наскільки легко пояснити, що взагалі лежить усередині.
Зручно тримати в голові один ланцюжок:
flowchart LR A["Вихідний код catalog-service"] --> B["bootJar: виконуваний jar"] B --> C["Layered jar: layers.idx і стандартні шари"] C --> D["jarmode=tools: list-layers / extract --layers"] C --> E["bootBuildImage: OCI-образ через buildpacks"]
Сенс цього ланцюжка не в тому, що у нас раптово зʼявилося пʼять різних технологій. Це одна й та сама лінія пакування, тільки на різних рівнях деталізації. bootJar дає базовий виконуваний jar. Layered jar робить структуру артефакту явною для інструментів пакування. jarmode=tools дає змогу перевірити цю структуру вручну. bootBuildImage використовує той самий артефакт як вхід і перетворює його на образ.
Чотири стандартні групи — dependencies, spring-boot-loader, snapshot-dependencies і application — потрібні не заради краси, а щоб те, що змінюється рідко, не їхало щоразу разом із вашим свіжим фіксом.
3. Jar-first на Java 25: що не змінюється
Зараз буде думка, яка часто дивує новачків: пакування, придатне для контейнерів, майже ніколи не потребує зміни прикладного коду. Сьогодні ми не переписуємо контролер, не змінюємо CatalogProperties, не чіпаємо Actuator і не додаємо «контейнерні анотації» (їх, на щастя, не існує). Ми змінюємо форму артефакту та спосіб, яким інструменти збирання його читають.
У термінах Gradle усе виглядає навіть трохи нудно: у нас і далі є bootJar, і він і далі складає класи в BOOT-INF/classes, а залежності — в BOOT-INF/lib. Layered jar просто робить цю структуру явною для інструментів пакування.
Окремо важливо, що базовий рівень Java 25 тут не скасовує jar-first підхід. Ми залишаємося у звичайному JVM-світі: виконуваний формат — jar, застосунок запускається на JVM, а шари пакування допомагають цьому формату нормально пережити подальше контейнерне пакування. Приємні бонуси на кшталт зручного розміщення для AOT cache або CDS існують, але сьогодні нам достатньо самої дисципліни пакування.
Якщо сказати простіше: ми залишаємося на землі, просто вчимося акуратно складати валізу, а не будувати космічний корабель.
4. Мінімальна карта команд
Коли тема стає обʼємною, рятує маленьке правило: я маю вміти назвати чотири дії й пояснити, навіщо кожна. Для сьогоднішнього дня цього більш ніж достатньо.
| Що потрібно вміти | Чим це робимо | Навіщо це взагалі |
|---|---|---|
| Зібрати виконуваний jar | ./gradlew bootJar | отримати базовий виконуваний артефакт |
| Подивитися шари | java -Djarmode=tools -jar <bootJar-jar> list-layers | переконатися, що jar справді має шари |
| Розкласти jar по шарах | java -Djarmode=tools -jar <bootJar-jar> extract --layers --destination ... | побачити вміст dependencies, application та решти шарів |
| Зібрати образ засобами Spring Boot | ./gradlew bootBuildImage | перетворити той самий артефакт на OCI-образ через buildpacks |
Цього набору достатньо, щоб не плутати сьогоднішній базовий рівень з окремим Docker-курсом. Практична деталь лише одна: дивитися потрібно саме на виконуваний jar із bootJar, а не на *-plain.jar, а для bootBuildImage потрібне доступне середовище виконання контейнерів.
5. Межа дня: де зупиняємося
На рівні поточного Boot-курсу базовий рівень для контейнерів закрито, якщо виконуються три речі:
- ви розумієте, навіщо layered jar ділить артефакт за частотою змін;
- умієте вручну перевірити ці шари через tools-режим;
- розумієте, що bootBuildImage збирає образ поверх того самого jar через buildpacks.
А ось що ми свідомо не робимо зараз: не проєктуємо Dockerfile як окремий інженерний артефакт, не обговорюємо публікацію образів і registry, не чіпаємо Compose, мережу, памʼять, томи, секрети та решту експлуатаційної кухні, не розбираємо внутрішню будову buildpacks крок за кроком.
Є ще корисна інженерна заувага: buildpacks можуть нормалізувати файлові метадані заради відтворюваності та кешу. Тому застосунку краще не покладатися на timestamps файлів як на частину своєї логіки.
На цьому рівні шаблон уже достатньо дорослий: він уміє жити поза IDE, його структуру можна перевірити, а за потреби — запакувати в образ. Далі головне питання вже не про ще один спосіб пакування, а про надійність цього шаблону: чи стабільно він стартує, чи не ламається від правок конфігурації, профілів і звʼязування. Compose, registry та решта експлуатації залишаються окремому Docker-треку; усередині Boot-підходу спершу важливіше отримати захист від регресій.
6. Типові помилки під час контейнероорієнтованого пакування
Помилка №1: вважати, що «образ зібрався» = «контейнеризацію завершено».
bootBuildImage справді вміє зібрати OCI-образ, але далі починається інший світ: як запускати, як передавати конфігурацію, як налаштовувати мережу, як керувати журналами та безпекою. Сьогоднішній базовий рівень — про пакування й артефакти, а не про експлуатацію.
Помилка №2: намагатися «лікувати контейнерну придатність» правкою контролера або service.
Дуже часта реакція новачка: «Раз це про контейнери, потрібно додати якийсь код». Ні. Сенс layered jar у тому, що поділ відбувається на рівні пакування: залежності та застосунок складаються так, щоб їх було зручно кешувати й копіювати шарами. Прикладна логіка catalog-service від цього не змінюється.
Помилка №3: плутати режим застосунку та режим інструмента.
jarmode=tools потрібен, щоб подивитися й витягнути шари. Сам сервіс від цього не перестає бути звичайним Boot-застосунком, який живе як executable jar і запускається через java -jar або потрапляє в образ.
Помилка №4: вимикати шари без причини.
У поточному Boot baseline jar із шарами — штатна поведінка bootJar. Явне налаштування потрібне, коли ви хочете свідомо зафіксувати або налаштувати цю поведінку, а не тому, що «так спокійніше» або «менше файлів».
Помилка №5: занадто рано вирізати tools-support з архіву.
Якщо прибрати tools із jar, наприклад через includeTools = false, ви самі собі відріжете найзручніший спосіб вручну перевірити шари. Робити це має сенс лише свідомо і з чіткою причиною, а не «щоб було чистіше».
ПЕРЕЙДІТЬ В ПОВНУ ВЕРСІЮ