Приклади розгортання

Ці посібники показують, як запустити дев’ять популярних PHP-застосунків на OxPHP, кожен як самодостатній проєкт Docker Compose. Кожен рецепт зібрано й перевірено від початку до кінця. У його розділі «Перевірка» перелічено запити, які перевірялися, і статус, що повертає кожен із них.

Кожна сторінка — це повний рецепт, який можна просто скопіювати: Dockerfile, docker-compose.yml, команди встановлення та специфічні для OxPHP деталі, яких не охоплює стандартна документація застосунку (написана для nginx + PHP-FPM).

Застосунки

Що спільного в усіх рецептах

Збірка на основі опублікованого образу OxPHP

OxPHP постачає готове середовище виконання PHP як ghcr.io/oxphp/oxphp (типово PHP 8.5; варіант із PHP 8.4 публікується як ghcr.io/oxphp/oxphp:<ver>-php8.4-alpine<X>). Опублікований образ уже містить бінарний файл oxphp, libphp.so, SAPI-розширення OxPHP, PHP CLI та інструменти, зручні для Composer. Рецепти розширюють його одним із двох способів:

1. Копіювання OxPHP в базовий образ php:*-zts-alpine (так зроблено для Laravel, Symfony, Yii3, Craft, Magento, OpenCart, Drupal, October). Багатоетапна збірка складає образ dev із чотирьох етапів:

   Dockerfilecopy

   FROM php:8.4-zts-alpine3.23 AS php-base # your app's PHP extensions FROM composer:2 AS composer # the Composer binary FROM ghcr.io/oxphp/oxphp:0.13.0-php8.4-alpine3.23 AS oxphp # OxPHP artifacts FROM php-base AS dev # final image # ... copy the oxphp binary, bridge library, and SAPI extension across: COPY --from=oxphp /usr/local/bin/oxphp /usr/local/bin/oxphp COPY --from=oxphp /usr/local/lib/liboxphp_bridge.so /usr/local/lib/ COPY --from=oxphp /usr/local/lib/php/extensions/ /tmp/oxphp-ext/ RUN cp /tmp/oxphp-ext/*/oxphp_sapi.so "$(php -r 'echo ini_get("extension_dir");')/" \ && echo "extension=oxphp_sapi.so" > /usr/local/etc/php/conf.d/oxphp-ext.ini

2. Безпосереднє розширення середовища виконання OxPHP (так зроблено для WordPress). Етап збирання компілює розширення з відповідним php:*-zts-alpine і кладе файли .so в образ OxPHP.

Канонічний багатоетапний шаблон див. у посібнику з Docker, а готову до копіювання версію — у examples/dockerfile/ в репозиторії.

Обирайте версію PHP свідомо

Типовий образ ghcr.io/oxphp/oxphp:<ver> — це PHP 8.5. Для сучасних фреймворків (Laravel, Symfony, Yii3, Craft) це підходить. Старіші або консервативніші кодові бази — Magento, OpenCart, Drupal, October CMS — фіксують PHP 8.4 через тег …-php8.4-alpine…, бо їхні стеки компонентів старші за 8.5 і видають на ньому попередження про застарілість. У кожному рецепті зазначено, яку версію він використовує і чому.

Обирайте режим маршрутизації за структурою застосунку

Режим маршрутизації OxPHP безпосередньо відповідає тому, як організовано застосунок:

• Фреймворковий режим (ENTRY_FILE=index.php) — один фронт-контролер у каталозі public/ (або web/, pub/); наявні статичні файли віддаються з диска, усе інше передається в index.php. Використовуйте для Laravel, Symfony, Yii3, Craft, Magento, Drupal, October.
• Традиційний режим (без ENTRY_FILE) — кілька фізичних точок входу PHP (наприклад, index.php плюс каталог admin/), які віддаються як справжні файли. Використовуйте для WordPress і OpenCart.

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

Образ dev містить PHP CLI і Composer (а також, залежно від застосунку, drush, bin/magento, php yii, php craft, php artisan), тож команди встановлення й обслуговування виконуються всередині запущеного контейнера — без окремого набору інструментів. Виняток — WordPress: його образ розширює середовище виконання OxPHP, у якому немає бінарника wp, тому WP-CLI працює в окремому sidecar-контейнері wpcli. Для решти рецептів:

Типові захисти, що діють усюди

OxPHP безкоштовно надає кілька захистів, які в nginx + PHP-FPM потребують явного налаштування:

• Блокування dot-шляхів — .env, .git/, .htaccess та будь-який інший шлях із сегментом, що починається з крапки, повертають 404 без жодного налаштування. Саме тому запуск застосунку з каталогу, де також лежить .env, не призводить до його витоку.
• Список заборони виконання PHP (PHP_DENY_PATHS) — використовується в рецептах із традиційним режимом: OpenCart блокує скрипти в system/ та install/; WordPress блокує виконання .php у wp-content/uploads/. (У фреймворковому режимі це нічого не змінює, бо довільні .php там ніколи не виконуються напряму.)
• Дозволені шляхи для символьних посилань (SYMLINK_ALLOW_PATHS) — використовується в October CMS, щоб OxPHP переходив за символьними посиланнями на ресурси, створеними october:mirror public, і водночас блокував виходи через символьні посилання в усіх інших місцях.

Рецепти

Сторінки згруповано за типом застосунку відповідно до структури каталогів:

Фреймворки — framework/

• Laravel — канонічний застосунок у фреймворковому режимі
• Symfony — мінімальний каркас, без бази даних
• Yii3 — найлегший з усіх; лише базові розширення

CMS — cms/

• WordPress — традиційний режим, збірка з розширенням середовища виконання, допоміжний контейнер WP-CLI
• Drupal — фреймворковий режим, PDO + drush
• Craft CMS — фреймворковий режим, встановлення через консоль
• October CMS — фреймворковий режим із дзеркалом public/ та SYMLINK_ALLOW_PATHS

Електронна комерція — ecommerce/

• Magento — найважчий: OpenSearch, PHP 8.4, символьне посилання для версії статичних ресурсів
• OpenCart — традиційний режим із двома фронт-контролерами та PHP_DENY_PATHS