Як оновити PHP для одного Docker-проєкту і не зламати інший

Коли на одному комп’ютері або сервері працює лише один Docker-проєкт, оновлення PHP здається локальною задачею: змінити версію, перебудувати контейнер і перевірити застосунок.

Складність з’являється, коли поруч живе ще один проєкт, який усе ще залежить від іншої версії PHP.

Тоді головне питання вже не "як оновити PHP?", а "де саме проходить межа цього оновлення?"

Якщо межа нечітка, одна зміна в спільному Docker-оточенні може непомітно змінити середовище другого проєкту.

Одна з головних переваг Docker у тому, що застосунок може отримати власне середовище виконання.

Проєкт A може працювати на PHP 8.5, а проєкт B - на PHP 8.3, навіть якщо обидва запущені на одній машині.

Для цього команди, тести, Composer і службові процеси кожного проєкту повинні виконуватися всередині його контейнерів, а не випадково використовувати PHP з хоста.

Найнебезпечніша ситуація виникає, коли кілька проєктів неявно покладаються на один і той самий workspace-контейнер.

Тоді оновлення PHP, Composer або системних пакетів для одного проєкту автоматично змінює інструменти другого.

Надійніша модель - окремий workspace для кожного проєкту або окремий сервіс для кожної потрібної версії PHP.

Зрозумілі імена потрібні не лише для зручності.

Коли в Docker одночасно є кілька PHP-FPM, workspace, Redis або Nginx-контейнерів, нечітка назва збільшує ризик запустити команду не там.

Ім’я повинно допомагати одразу побачити, до якого проєкту та версії середовища належить контейнер.

Навіть якщо Docker Compose-файли різні, однакові назви проєктів можуть призвести до неочікуваного перетину контейнерів, мереж або томів.

Тому кожне середовище повинно мати власний Compose project name і власні назви ресурсів там, де це потрібно.

Два проєкти можуть мати окремі PHP-контейнери й усе одно конфліктувати на рівні хоста.

Наприклад, обидва Nginx-контейнери не можуть одночасно прив’язатися до одного й того самого порту хоста.

Те саме стосується Redis, MySQL, Reverb або інших сервісів, якщо їхні порти опубліковані назовні.

Тому під час зміни Docker-конфігурації варто перевіряти не лише версію PHP, а й фактичні прив’язки портів.

Composer перевіряє платформні вимоги відносно того PHP, яким він запущений.

Якщо composer install виконати на хості з PHP 8.5, а застосунок реально працює в контейнері з PHP 8.3, можна отримати залежності, які формально встановилися, але не сумісні з реальним runtime проєкту.

Тому Composer для конкретного проєкту варто запускати в його workspace-контейнері.

Якщо один проєкт уже перейшов на PHP 8.5, це краще зафіксувати не лише в Dockerfile або змінній середовища, а і в Composer-вимогах.

Так несумісність стане видимою раніше: під час встановлення залежностей або перевірки платформи, а не після запуску застосунку.

Кожен проєкт повинен мати власний vendor і власний composer.lock.

Спільний каталог залежностей між двома застосунками з різними вимогами до PHP руйнує саму ідею ізоляції.

Оновлення одного набору пакетів тоді може змінити код, який завантажує інший проєкт.

Якщо змінилася лише версія PHP, немає потреби бездумно перебудовувати всі сервіси.

Точкове оновлення зменшує площу зміни і спрощує перевірку: ми чітко знаємо, які контейнери повинні отримати новий runtime.

Якщо мета ізоляції - не вплинути на другий проєкт, це потрібно підтвердити перевіркою.

Після перебудови варто подивитися версії PHP в обох workspace-контейнерах, перевірити їхні PHP-FPM-сервіси й виконати короткий тест доступності обох застосунків.

Інакше ми перевіряємо лише половину обіцянки.

У деяких Docker-оточеннях версія PHP задається змінною у спільному .env.

Якщо два проєкти використовують один і той самий набір Docker-файлів і одну конфігурацію, зміна змінної для проєкту A може непомітно змінити майбутню перебудову проєкту B.

Тому конфігурація runtime теж повинна належати конкретному проєкту або конкретному профілю середовища.

Навіть якщо PHP runtime розділений, проєкти все ще можуть випадково ділити MySQL, Redis, мережу або том.

Це не обов’язково неправильно, але таке спільне використання має бути явним.

Особливо важливо уникати ситуації, де два проєкти використовують однакові назви баз, ключові простори Redis або томи через помилку конфігурації.

У окремій статті про безпечне оновлення PHP після критичних вразливостей я розбирала сам процес безпечного оновлення PHP.

Але в Docker-середовищі до нього додається ще одна вимога: зміна має залишитися всередині потрібного проєкту.

Тобто перевірити нову версію PHP недостатньо. Потрібно ще довести, що інші проєкти зберегли свої версії й свої залежності.

Docker дозволяє тримати кілька версій PHP на одній машині, але сама наявність контейнерів ще не гарантує ізоляцію.

Межа повинна бути явною у runtime, workspace, Compose project name, портах, залежностях і конфігурації.

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

Найкращий доказ ізоляції - не тільки "новий контейнер працює", а й "інший контейнер не змінився".