Deploy PHP op Nodion

PHP stap voor stap deployen

1. Voeg composer.json toe en commit composer.lock Nodion herkent PHP aan composer.json. Een repository met alleen een index.php wordt niet herkend; heb je nog geen composer.json, dan volstaat een klein bestand zoals dit. De build voert composer install --no-dev --optimize-autoloader uit, dus alles wat de app tijdens runtime nodig heeft, hoort in require, niet in require-dev. Commit composer.lock, zodat de build de versies installeert die je hebt getest. composer.json

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

2. Zet publieke bestanden in public/ FrankenPHP gebruikt public/ als documentroot. Ontbreekt die map, dan neemt Nodion web/, en ontbreken beide, de root van de repository. Zet index.php en je assets in public/ en houd vendor/, configuratie en broncode ernaast, zodat alleen bestanden worden geserveerd die voor het web bedoeld zijn.

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

3. Kies de webserver FrankenPHP is de standaard en heeft geen configuratie nodig. Voor php-fpm achter nginx of Apache httpd voeg je op het tabblad Environment BP_PHP_SERVER toe met de waarde nginx of apache en vink je Build aan. Apache leest ook je .htaccess-bestanden. Met elke andere waarde mislukt de build.
4. Maak de app aan en koppel een database Maak in het dashboard een applicatie aan vanuit je GitHub-, GitLab-, Bitbucket- of Gitea-repository, kies de branch en de regio EU Central, en laat de buildstrategie op Buildpacks staan. Maak daarna een MySQL- of PostgreSQL-database aan in dezelfde regio en koppel die op het tabblad Environment: de app krijgt DATABASE_URL bij de volgende deployment, alleen tijdens runtime. Markeer wachtwoorden en API-sleutels als secret.
5. Voer migraties uit bij elke deployment Een release:-regel in een Procfile draait één keer per build, na de build en voordat de nieuwe versie start. Mislukt die, dan stopt de deployment en blijft de draaiende versie live. Zet de migratietool, bijvoorbeeld Doctrine Migrations of Phinx, in require. Procfile

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

Goed om te weten

• Zet de PHP-versie vastNodion leest eerst .php-version, daarna require.php in composer.json; zonder een van beide krijg je PHP 8.3. Een bereik kiest de nieuwste passende release, dus "^8.2" levert PHP 8.5 op. Wil je op één versielijn blijven, zet dan 8.3 in .php-version of vereis "8.3.*".
• SymfonyNodion herkent Symfony aan bin/console plus symfony.lock, voert tijdens de build bin/console cache:warmup --env=prod uit en zet tijdens runtime APP_ENV=prod en APP_DEBUG=0. Voeg APP_ENV=prod ook toe met de vlag Build, zodat de Composer-scripts die tijdens de installatie draaien niet dev uit je .env gebruiken. Nodion voert asset-map:compile niet uit; gebruik je AssetMapper, voeg het dan toe aan de auto-scripts in composer.json. Gebruik voor builds met Encore of Vite een Dockerfile.
• WorkersVoeg voor een queue-worker een regel zoals worker: php bin/worker.php toe aan het Procfile, samen met een expliciete web:-regel, want zonder die regel wordt de eerste Procfile-regel die geen release: is het standaardcommando. Het buildlog laat zien met welk commando de app standaard start; voor FrankenPHP werkt web: frankenphp php-server --listen :$PORT --root public/. Voeg daarna op het tabblad Processes een proces met de naam worker zonder poort toe.
• Pad voor de health checkHet verkeer gaat over naar een nieuwe release zodra / antwoordt met 2xx of 3xx. Antwoordt / met 401 of 404, stel dan in de app-instellingen een pad voor de health check in dat 200 teruggeeft.

Wat Nodion voor je regelt

• Deploys zonder downtime Push naar je branch en Nodion bouwt een nieuwe release. Het verkeer schakelt over zodra de nieuwe instanties hun health check doorstaan; een mislukte release laat de draaiende versie staan. Apps met een lokaal volume herstarten in plaats daarvan, omdat de schijf bij één instantie hoort.
• Databases naast de app Managed PostgreSQL, pgvector, MySQL, Valkey en ClickHouse in dezelfde regio. Gekoppelde databases komen binnen als DATABASE_URL, REDIS_URL of CLICKHOUSE_URL.
• Previews per pull request Zet previews aan en pull requests uit je repository krijgen een eigen app met een eigen URL en nieuwe, lege databases, automatisch of handmatig aangemaakt. Forks en pull requests van bots worden overgeslagen.
• Workers, cronjobs en schalen Draai workers als extra processen van dezelfde app, plan jobs op het tabblad Cron en schaal elk proces naar maximaal 16 instanties.
• Releasestap Met buildpacks draait een release:-regel in het Procfile bij elke nieuwe build. Dockerfile-apps, en redeploys of rollbacks naar een eerdere image, gebruiken een releasecommando dat op de app zelf is ingesteld en dat ook voorrang heeft op de Procfile-regel. Bij statische sites draait een releasestap in een image die alleen de gebouwde bestanden bevat.
• Logs en metrics Build-, release- en runtimelogs plus metrics voor CPU, geheugen, schijf en netwerk van elke instantie in het dashboard.
• Domeinen en HTTPS Een standaardhostnaam met HTTPS vanaf de eerste deploy; je eigen domeinen krijgen automatisch certificaten.

Verder lezen

• Dockerfile vs buildpacks: welke moet je gebruiken? Allebei maken ze van je code een containerimage. Het verschil is wie de buildstappen schrijft, en dat bepaalt controle, onderhoud en beveiligingsupdates.
• Cloud Native Buildpacks uitgelegd Buildpacks maken van je broncode een containerimage zonder Dockerfile. Wat ze zijn en hoe ze werken.

PHP op Nodion: vragen en antwoorden