Wdróż PHP na Nodion

Wdróż PHP krok po kroku

1. Dodaj composer.json i composer.lock do repozytorium Nodion wykrywa PHP po pliku composer.json. Repozytorium z samym index.php nie zostanie wykryte; jeśli nie masz jeszcze composer.json, wystarczy mały plik taki jak ten. Build uruchamia composer install --no-dev --optimize-autoloader, więc wszystko, czego aplikacja potrzebuje podczas działania, musi trafić do require, a nie do require-dev. Dodaj do repozytorium composer.lock, aby build zainstalował przetestowane przez Ciebie wersje. composer.json

   {
     "require": {
       "php": "8.4.*"
     }
   }

2. Trzymaj pliki publiczne w public/ FrankenPHP używa public/ jako document root. Jeśli tego katalogu nie ma, Nodion bierze web/, a gdy brakuje obu, katalog główny repozytorium. Umieść index.php i swoje zasoby w public/, a vendor/, konfigurację i kod źródłowy przechowuj poza tym katalogiem, aby serwowane były tylko pliki przeznaczone dla WWW.

   composer.json
   composer.lock
   src/
   public/
     index.php

3. Wybierz serwer WWW FrankenPHP jest domyślny i nie wymaga konfiguracji. Aby używać php-fpm za serwerem nginx lub Apache httpd, dodaj w zakładce Environment zmienną BP_PHP_SERVER z wartością nginx lub apache i zaznacz Build. Apache odczytuje też Twoje pliki .htaccess. Każda inna wartość kończy build błędem.
4. Utwórz aplikację i podłącz bazę danych W dashboardzie utwórz aplikację ze swojego repozytorium GitHub, GitLab, Bitbucket lub Gitea, wybierz branch i region EU Central, a strategię buildu zostaw na Buildpacks. Następnie utwórz bazę danych MySQL lub PostgreSQL w tym samym regionie i podłącz ją w zakładce Environment: aplikacja otrzyma DATABASE_URL przy następnym wdrożeniu, tylko podczas działania. Hasła i klucze API oznacz jako sekrety.
5. Uruchamiaj migracje przy każdym wdrożeniu Linia release: w Procfile jest wykonywana raz na build, po buildzie i przed startem nowej wersji. Jeśli się nie powiedzie, wdrożenie zostaje zatrzymane, a działająca wersja nadal obsługuje ruch. Narzędzie do migracji, na przykład Doctrine Migrations lub Phinx, trzymaj w require. Procfile

   release: vendor/bin/doctrine-migrations migrate --no-interaction

Warto wiedzieć

• Przypnij wersję PHPNodion najpierw odczytuje .php-version, potem require.php w composer.json; bez żadnego z nich dostajesz PHP 8.3. Zakres wybiera najnowsze pasujące wydanie, więc "^8.2" daje PHP 8.5. Aby zostać przy jednej linii wersji, wpisz 8.3 do .php-version albo ustaw wymaganie "8.3.*".
• SymfonyNodion rozpoznaje Symfony po bin/console razem z symfony.lock, podczas buildu uruchamia bin/console cache:warmup --env=prod, a podczas działania ustawia APP_ENV=prod i APP_DEBUG=0. Dodaj też APP_ENV=prod z zaznaczoną opcją Build, aby skrypty Composera uruchamiane podczas instalacji nie używały dev z Twojego .env. Nodion nie uruchamia asset-map:compile; jeśli korzystasz z AssetMappera, dodaj to polecenie do auto-scripts w composer.json. Do buildów z Encore lub Vite użyj Dockerfile.
• WorkeryDla workera kolejki dodaj do Procfile linię taką jak worker: php bin/worker.php razem z jawną linią web:, bo bez niej pierwszy wpis w Procfile inny niż release: staje się domyślnym poleceniem. Log buildu pokazuje domyślne polecenie startowe; dla FrankenPHP działa web: frankenphp php-server --listen :$PORT --root public/. Następnie dodaj w zakładce Processes proces o nazwie worker bez portu.
• Ścieżka health checkuRuch przechodzi na nowy release, gdy / odpowie kodem 2xx lub 3xx. Jeśli / zwraca 401 lub 404, ustaw w ustawieniach aplikacji ścieżkę health checku, która zwraca 200.

Czym Nodion zajmuje się za Ciebie

• Wdrożenia bez przestojów Wypchnij zmiany do swojej gałęzi, a Nodion zbuduje nowy release. Ruch przełącza się, gdy nowe instancje przejdą health check; nieudany release nie wpływa na działającą wersję. Aplikacje z lokalnym wolumenem są natomiast uruchamiane ponownie, bo dysk należy do jednej instancji.
• Bazy danych obok aplikacji Zarządzane PostgreSQL, pgvector, MySQL, Valkey i ClickHouse w tym samym regionie. Podłączone bazy danych trafiają do aplikacji jako DATABASE_URL, REDIS_URL lub CLICKHOUSE_URL.
• Środowiska podglądu dla pull requestów Włącz środowiska podglądu, a każdy pull request z Twojego repozytorium dostanie własną aplikację z własnym adresem URL i nowymi, pustymi bazami danych, tworzoną automatycznie lub ręcznie. Forki i pull requesty od botów są pomijane.
• Workery, zadania cron i skalowanie Uruchamiaj workery jako dodatkowe procesy tej samej aplikacji, planuj zadania w zakładce Cron i skaluj każdy proces do 16 instancji.
• Etap release W przypadku buildpacków linia release: w Procfile uruchamia się przy każdym nowym buildzie. Aplikacje z Dockerfile, a także ponowne wdrożenia i rollbacki do wcześniejszego obrazu, korzystają z polecenia release ustawionego w samej aplikacji, które ma też pierwszeństwo przed linią z Procfile. W przypadku stron statycznych krok release działa w obrazie zawierającym tylko zbudowane pliki.
• Logi i metryki W dashboardzie znajdziesz logi z builda, release'u i działania aplikacji oraz metryki CPU, pamięci, dysku i sieci dla każdej instancji.
• Domeny i HTTPS Domyślna nazwa hosta z HTTPS od pierwszego wdrożenia; Twoje własne domeny automatycznie dostają certyfikaty.

Warto przeczytać

• Dockerfile vs buildpacki: co wybrać dla aplikacji? Oba podejścia zamieniają Twój kod w obraz kontenera. Różni je to, kto pisze kroki builda, a od tego zależą kontrola, utrzymanie i aktualizacje bezpieczeństwa.
• Cloud Native Buildpacks: czym są i jak działają Buildpacki zamieniają Twój kod źródłowy w obraz kontenera bez Dockerfile. Czym są i jak działają.

PHP na Nodion: pytania i odpowiedzi