Przykładowe wdrożenia

Te przewodniki pokazują, jak uruchomić dziewięć popularnych aplikacji PHP na OxPHP, każdą jako samodzielny projekt Docker Compose. Każdy przepis został zbudowany i zweryfikowany od początku do końca: witryna sklepu, panel administracyjny, statyczne zasoby oraz wewnętrzny endpoint kontroli stanu OxPHP — wszystko odpowiada kodem 200.

Każda strona to kompletny przepis gotowy do skopiowania i wklejenia: Dockerfile, docker-compose.yml, polecenia instalacyjne oraz szczegóły specyficzne dla OxPHP, których standardowa dokumentacja aplikacji (napisana dla nginx + PHP-FPM) nie obejmuje.

Aplikacje

Aplikacja Typ Tryb routingu PHP Dodatkowe usługi Metoda instalacji
Laravel Framework Framework 8.5 MySQL composer create-project
Symfony Framework Framework 8.5 — composer create-project
Yii3 Framework Framework 8.5 — composer create-project
WordPress CMS Tradycyjny 8.5 MySQL WP-CLI
Drupal CMS Framework 8.4 MySQL drush site:install
Craft CMS CMS Framework 8.5 MySQL craft install
October CMS CMS Framework + kopia lustrzana 8.4 MySQL october:migrate + kopia lustrzana
Magento E-commerce Framework 8.4 MySQL + OpenSearch bin/magento setup:install
OpenCart E-commerce Tradycyjny 8.4 MySQL Instalator CLI

Co łączy każdy przepis

Budowanie na opublikowanym obrazie OxPHP

OxPHP dostarcza gotowe środowisko uruchomieniowe PHP jako ghcr.io/oxphp/oxphp (domyślnie PHP 8.5; wariant PHP 8.4 jest publikowany jako ghcr.io/oxphp/oxphp:<ver>-php8.4-alpine<X>). Opublikowany obraz zawiera już plik binarny oxphp, libphp.so, rozszerzenie SAPI OxPHP, PHP CLI oraz narzędzia współpracujące z Composerem. Przepisy rozszerzają go na jeden z dwóch sposobów:

  1. Skopiowanie OxPHP do bazy php:*-zts-alpine (używane przez Laravel, Symfony, Yii3, Craft, Magento, OpenCart, Drupal, October). Wieloetapowa budowa składa obraz dev z czterech etapów:

    Dockerfile
    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.10.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. Rozszerzenie środowiska uruchomieniowego OxPHP bezpośrednio (używane przez WordPress). Etap budowania kompiluje rozszerzenia względem pasującego php:*-zts-alpine i umieszcza pliki .so w obrazie OxPHP.

Note

Tak czy inaczej, ABI PHP musi się zgadzać. libphp.so oraz oxphp_sapi.so z obrazu OxPHP są skompilowane dla jednej wersji PHP (np. 8.4 → no-debug-zts-20240924); etap php-base/budowania musi używać tego samego php:<X.Y>-zts-alpine<Z>, aby kompilowane przez ciebie rozszerzenia były zgodne pod względem ABI. Mieszanie wersji sprawia, że oxphp_sapi.so odmawia załadowania lub uszkadza musl TLS podczas uruchamiania.

Zobacz Przewodnik po Dockerze, aby poznać kanoniczny szablon wieloetapowej budowy, oraz examples/dockerfile/ w repozytorium, aby uzyskać gotową do skopiowania wersję.

Świadomie wybierz wersję PHP

Domyślny obraz ghcr.io/oxphp/oxphp:<ver> to PHP 8.5. Jest to odpowiednie dla nowoczesnych frameworków (Laravel, Symfony, Yii3, Craft). Starsze lub bardziej konserwatywne bazy kodu — Magento, OpenCart, Drupal, October CMS — przypinają PHP 8.4 za pomocą taga …-php8.4-alpine…, ponieważ ich zestawy komponentów powstały przed 8.5 i emitują na nim ostrzeżenia o przestarzałych elementach. Każdy przepis podaje, której wersji używa i dlaczego.

Wybierz tryb routingu na podstawie kształtu aplikacji

Tryb routingu OxPHP odwzorowuje bezpośrednio to, jak zbudowana jest aplikacja:

  • Tryb framework (ENTRY_FILE=index.php) — jeden kontroler wejściowy w katalogu public/ (lub web/, pub/); istniejące pliki statyczne są serwowane z dysku, a wszystko inne jest kierowane do index.php. Stosuj dla Laravel, Symfony, Yii3, Craft, Magento, Drupal, October.
  • Tryb tradycyjny (bez ENTRY_FILE) — wiele fizycznych punktów wejścia PHP (np. index.php plus katalog admin/) serwowanych jako prawdziwe pliki. Stosuj dla WordPress i OpenCart.

Instaluj przez ten sam kontener

Obraz dev zawiera PHP CLI oraz Composera (a także drush, wp, bin/magento, php yii, php craft, php artisan — w zależności od potrzeb), więc każde polecenie instalacyjne i konserwacyjne uruchamia się wewnątrz działającego kontenera — bez osobnego zestawu narzędzi:

bash
docker compose exec app php artisan migrate # Laravel docker compose exec app vendor/bin/drush cr # Drupal docker compose run --rm app composer install # any

Domyślne zabezpieczenia, które obowiązują wszędzie

OxPHP daje ci za darmo kilka zabezpieczeń, które w przypadku nginx + PHP-FPM wymagają jawnej konfiguracji:

  • Blokowanie ścieżek z kropką — .env, .git/, .htaccess oraz każda inna ścieżka z segmentem zaczynającym się od kropki zwracają 404 bez konfiguracji. To dlatego uruchomienie aplikacji z katalogu, który zawiera również .env, nie ujawnia go.
  • Lista blokowania wykonywania PHP (PHP_DENY_PATHS) — używana przez przepisy w trybie tradycyjnym: OpenCart blokuje skrypty system/ i install/; WordPress blokuje wykonywanie .php w wp-content/uploads/. (W trybie framework nie ma to znaczenia, ponieważ dowolne .php nigdy nie jest wykonywane bezpośrednio.)
  • Ścieżki dozwolone dla dowiązań symbolicznych (SYMLINK_ALLOW_PATHS) — używane przez October CMS, aby OxPHP podążał za dowiązaniami symbolicznymi zasobów tworzonymi przez october:mirror public, wciąż blokując ucieczki przez dowiązania symboliczne wszędzie indziej.

Przepisy

Strony są pogrupowane według typu aplikacji, odzwierciedlając układ katalogów:

text
examples/ ├── framework/ # Laravel, Symfony, Yii3 ├── cms/ # WordPress, Drupal, Craft, October └── ecommerce/ # Magento, OpenCart

Framework — framework/

  • Laravel — kanoniczna aplikacja w trybie framework
  • Symfony — minimalny szkielet, bez bazy danych
  • Yii3 — najbardziej odchudzony ze wszystkich; wyłącznie rozszerzenia rdzenia

CMS — cms/

  • WordPress — tryb tradycyjny, budowa z rozszerzeniem środowiska uruchomieniowego, sidecar WP-CLI
  • Drupal — tryb framework, PDO + drush
  • Craft CMS — tryb framework, instalacja sterowana z konsoli
  • October CMS — tryb framework z kopią lustrzaną public/ oraz SYMLINK_ALLOW_PATHS

E-commerce — ecommerce/

  • Magento — najcięższy: OpenSearch, PHP 8.4, dowiązanie symboliczne wersji statycznych zasobów
  • OpenCart — tryb tradycyjny z dwoma kontrolerami wejściowymi i PHP_DENY_PATHS
Znalazłeś błąd? Zgłoś go →