Працює лише в мене?

1. «Працює в мене» — це ще не властивість проєкту

Фраза «в мене все працює» звучить як добра новина лише в перші кілька хвилин. Потім зʼясовується, що йдеться про одну конкретну машину, а не про проєкт. Репозиторій може бути той самий, але умови навколо нього різні: версія Java, системні змінні, локальні процеси на портах, доступність PostgreSQL, права на каталоги, робоча папка процесу, звички IDE. Із цих дрібниць і складається те саме знамените «нічого не працює».

Тому відтворюваність — це не гарне слово, а цілком прикладна властивість проєкту. Вона означає, що запуск описано так, щоб він не залежав від неочевидних домовленостей і випадкових особливостей машини. README тут допомагає, але проблему повністю не розвʼязує. Він може пояснити, що ви задумали, але не може гарантувати, що середовище справді збіглося з очікуваннями.

Якщо сказати ще точніше, локальний запуск без відтворюваності майже завжди виявляється сумішшю коду й удачі. Поки проєкт маленький і живе в однієї людини, це терпимо. Щойно в картину додаються другий розробник, другий ноутбук або просто повернення до проєкту через місяць, ціна цієї удачі різко зростає.

2. Сервіс живе в runtime-середовищі

Це, мабуть, головна думка всієї лекції. Сервіс — це не лише jar, не лише класи й не лише бізнес-логіка. У сервісу є умови життя: порт, режим запуску, профіль, змінні середовища, файлові шляхи, зовнішні залежності, мінімальний health-сигнал. Якщо ці умови ніде не зафіксовано й не стабілізовано, сам сервіс залишається крихким, навіть якщо код написано акуратно.

Ось чому один і той самий Boot-проєкт може бути «написаний» і водночас «не готовий до життя». З погляду Java все зібрано. З погляду runtime — занадто багато прихованих припущень. Десь хтось очікує, що порт 8080 вільний. Десь — що на машині вже піднято базу. Десь — що каталог ./data/exports існує і доступний для запису. Десь — що профіль застосунку увімкнено «сам собою».

І тут якраз зʼявляється той самий момент, заради якого Docker взагалі потрібен. Проблема не в тому, що ви поки не вивчили потрібну CLI-команду. Проблема в тому, що ваш сервіс ще не оформлено як відтворюваний runtime-обʼєкт. Docker приходить не замість Spring Boot, а щоб упорядкувати хаотичне середовище запуску.

3. Один сервіс, різні режими: standalone і postgres

На навчальному сервісі це видно особливо добре. У нас не два різні застосунки, а один і той самий Container-Ready Catalog Service, який може жити щонайменше в двох режимах. У standalone режимі він стартує без зовнішньої бази й зберігає дані в памʼяті. Це зручно для швидких перевірок і перших кроків курсу. У postgres режимі в нього вже зʼявляється зовнішня залежність, і картина запуску змінюється.

На рівні конфігурації ідея виглядає дуже просто:

# application-standalone.yml
# Конфігурація для режиму «без зовнішньої БД»: усе зберігається в памʼяті процесу
app:
  storage: in-memory # режим зберігання (важливо: змінює поведінку сервісу)
server:
  port: 8080 # порт сервісу в цьому профілі (частина runtime-середовища)

# application-postgres.yml
# Конфігурація для режиму із зовнішньою БД (залежність зʼявляється «ззовні» сервісу)
app:
  storage: postgres # режим зберігання: очікуємо PostgreSQL і коректні налаштування доступу
server:
  port: 8080 # порт може збігатися, але умови запуску вже інші (потрібна БД)

Тут важливі не конкретні імена властивостей, а сама ідея. Це один і той самий сервіс, але умови його життя різні. В одному випадку йому достатньо власної JVM, в іншому вже потрібна база даних. Якщо цю різницю не тримати в голові, розробник швидко починає плодити «docker-версію проєкту», «локальну спеціальну гілку» або окремий набір незрозумілих конфігів. Це і є початок runtime-хаосу.

Контейнеризація потрібна тут не для краси. Вона потрібна, щоб один і той самий сервіс запускався в різних умовах через контрольоване runtime-середовище, а не через набір випадкових практик. І це дуже доросла різниця між «сервіс написано» і «сервісом можна нормально користуватися».

4. Порти, шляхи й файли ламають запуск найлегше 🚫

Є спокуса думати, що справжні болі починаються лише з великих залежностей на кшталт бази чи брокера. На практиці все часто ламається раніше й тихіше. Порт уже зайнятий. Робочий каталог процесу не той. Відносний шлях до файлів обчислюється не звідти, звідки ви очікували. На одній машині все лежить у потрібному місці, на іншій — ні. І це особливо неприємно, тому що код при цьому може бути цілком коректним.

Навіть таке просте налаштування вже багато що показує:

server:
  # Беремо порт зі змінної середовища SERVER_PORT, а якщо її немає — використовуємо 8080
  # Це робить «порт» явною частиною runtime-середовища, а не неявною магією локальної машини
  port: ${SERVER_PORT:8080}

Воно нагадує про важливу річ: порт — це частина runtime, а не магічне число «за замовчуванням». Те саме стосується файлових сценаріїв. У проєкті Container-Ready Catalog Service є експорт каталогу у файл, а отже, шлях до цього експорту — не дрібниця, а повноцінна частина життєвого циклу сервісу.

Якщо в коді живе щось на кшталт такого, то ви вже маєте справу з реальною середовищною передумовою:

@Service
class ExportService {

    Path defaultDir() {
        // Відносний шлях: обчислюється від робочого каталогу процесу (який може відрізнятися)
        // У контейнері це буде шлях усередині файлової системи контейнера, якщо не примонтувати том
        return Path.of("./data/exports");
    }
}

На одній машині цей шлях виглядає безневинно, на іншій призводить до неочікуваного каталогу, а в контейнерному середовищі взагалі виявляється частиною внутрішньої файлової системи процесу. Саме тому файли й порти не можна списувати на «дрібниці». Це інтерфейс між застосунком і середовищем. 🔧

5. README допомагає, але не гарантує

Хороший README — це повага до людей. Але в README є чесне обмеження: він залишається текстом. Він може перелічити кроки, попередити про залежності, нагадати про змінні середовища. Але сам по собі не перетворює запуск на відтворюване середовище. Коли все тримається лише на тексті, завжди залишається зазор між «так має бути» і «так реально вийшло».

Це особливо добре видно на онбордингу. Новий розробник приходить у проєкт, клонує репозиторій, читає інструкцію і начебто робить усе правильно. Але далі спливає звична побутова реальність: інша Java, інший локальний Postgres, інший вільний порт, інші права на каталог, інший shell, інша структура вже запущених процесів. README допомагає швидше локалізувати проблему, але саму проблему не усуває.

Тому в інженерному сенсі відтворюваність — це завжди більше, ніж документація. Документація потрібна. Але якщо середовище не стабілізовано, проєкт усе одно залишається проєктом, який «якось працює» лише у свого автора. Контейнеризація якраз робить наступний крок: переносить частину знання про запуск з усних і текстових домовленостей у більш керований runtime-шар.

6. Що саме стабілізує Docker 🛠️

Тут особливо важливо не впасти в магічне мислення. Docker не лагодить поганий код. Він не виправляє неправильну бізнес-логіку. Він не перетворює незрозумілий процес старту Spring Boot на ясність. І він не замінює вам знання профілів, конфігурації та runtime-поведінки застосунку. Якщо сервіс падає через власну помилку, у контейнері він падатиме так само — інколи навіть переконливіше.

Але Docker дуже добре розвʼязує інший клас проблем. Він дає змогу стабілізувати середовище запуску, зробити його повторюваним і перестати тягнути за собою нескінченний хвіст неявних передумов. Простіше кажучи, він не лікує все підряд, зате дуже чесно бʼє саме в ту біль, яка зʼявляється після першого робочого Boot-сервісу.

І ось думка, яку корисно запамʼятати. Docker потрібен не тому, що «так роблять в індустрії». Він потрібен тому, що після першого запуску Spring Boot-сервісу головною проблемою стає вже не лише код, а відтворюваний runtime. Щойно ця думка осідає, слова image, container, registry і Compose перестають бути сухим словником і починають працювати по суті.

7. Лінза відтворюваності для будь-якого Boot-сервісу

Нижче — невелика таблиця, яку зручно тримати поруч щоразу, коли ви збираєтеся контейнеризувати вже наявний Spring Boot-сервіс. Це не «список на екзамен», а робоча лінза. Якщо ви не можете відповісти на ці питання, контейнеризація майже напевно перетвориться на вгадування.

У нашому навчальному проєкті відповіді на ці питання вже починають проступати. Є зрозумілий старт, є режими standalone і postgres, є експорт у файл, є бізнес-ендпоінт і є Actuator. Саме тому стартовий репозиторій тут не декоративний. Він не просто показує код — він показує саму область задачі.

8. Типові помилки 🤦‍♂️

Помилка № 1: вважати локальний запуск доказом відтворюваності.
Локальний успіх говорить лише про те, що ваша поточна машина збіглася з очікуваннями проєкту. Це корисно, але цього замало. Щойно змінюється машина, розробник або навіть просто набір локально запущених процесів, картина може різко змінитися.

Помилка № 2: сприймати порт, шлях або профіль як другорядні деталі.
Саме в таких «дрібницях» часто й живе велика частина болю. Сервіс може бути ідеально написаний, але якщо в нього не названо умови запуску, він залишається крихким. Runtime не починається з бази даних; він починається вже з порту й робочого каталогу.

Помилка № 3: очікувати, що Docker сам виправить хаос налаштувань.
Контейнеризація стабілізує середовище, але не замінює розуміння застосунку. Якщо ви не знаєте, які режими є у сервісу і які зовнішні передумови йому потрібні, Docker просто зробить цей хаос трохи більш упакованим.

Помилка № 4: підміняти відтворюваність гарною інструкцією.
README потрібен і важливий, але текст не дорівнює контрольованому runtime. Поки знання про запуск живе лише в документації та в головах людей, проєкт залишається вразливим до будь-якої різниці між машинами.

1

Задача

Docker for Spring, 1 рівень, 1 лекція

Недоступна

Два режими одного сервісу

Два режими одного сервісу

Відкрити

1

Задача

Docker for Spring, 1 рівень, 1 лекція

Недоступна

Експорт у відносний шлях

Експорт у відносний шлях

Відкрити