Déployez PHP sur Nodion

Déployez PHP étape par étape

1. Ajoutez composer.json et commitez composer.lock Nodion détecte PHP grâce au composer.json. Un dépôt qui ne contient qu'un index.php n'est pas détecté ; si vous n'avez pas encore de composer.json, un petit fichier comme celui-ci suffit. Le build exécute composer install --no-dev --optimize-autoloader : tout ce dont l'app a besoin à l'exécution va donc dans require, pas dans require-dev. Commitez composer.lock pour que le build installe les versions que vous avez testées. composer.json

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

2. Placez les fichiers publics dans public/ FrankenPHP utilise public/ comme racine du site. S'il n'existe pas, Nodion prend web/, et sans aucun des deux, la racine du dépôt. Placez index.php et vos assets dans public/ et gardez vendor/, la configuration et le code source à côté : seuls les fichiers destinés au web sont alors servis.

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

3. Choisissez le serveur web FrankenPHP est le choix par défaut et ne demande aucune configuration. Pour php-fpm derrière nginx ou Apache httpd, ajoutez BP_PHP_SERVER avec la valeur nginx ou apache dans l'onglet Environment et cochez Build. Apache lit aussi vos fichiers .htaccess. Toute autre valeur fait échouer le build.
4. Créez l'app et rattachez une base de données Dans le dashboard, créez une application depuis votre dépôt GitHub, GitLab, Bitbucket ou Gitea, choisissez la branche et la région EU Central, et laissez la stratégie de build sur Buildpacks. Créez ensuite une base de données MySQL ou PostgreSQL dans la même région et rattachez-la dans l'onglet Environment : l'app reçoit DATABASE_URL au déploiement suivant, uniquement à l'exécution. Marquez les mots de passe et les clés d'API comme secrets.
5. Exécutez les migrations à chaque déploiement Une ligne release: dans un Procfile s'exécute une fois par build, après le build et avant le démarrage de la nouvelle version. Si elle échoue, le déploiement s'arrête et la version en cours reste en ligne. Gardez l'outil de migration, par exemple Doctrine Migrations ou Phinx, dans require. Procfile

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

Bon à savoir

• Fixez la version de PHPNodion lit d'abord .php-version, puis require.php dans composer.json ; sans l'un ni l'autre, vous obtenez PHP 8.3. Une plage prend la version compatible la plus récente : "^8.2" donne donc PHP 8.5. Pour rester sur une seule version mineure, écrivez 8.3 dans .php-version ou exigez "8.3.*".
• SymfonyNodion reconnaît Symfony à bin/console associé à symfony.lock, exécute bin/console cache:warmup --env=prod pendant le build et définit APP_ENV=prod et APP_DEBUG=0 à l'exécution. Ajoutez aussi APP_ENV=prod avec l'option Build, pour que les scripts Composer lancés pendant l'installation n'utilisent pas dev depuis votre .env. Nodion n'exécute pas asset-map:compile ; avec AssetMapper, ajoutez-le aux auto-scripts de composer.json. Pour des builds avec Encore ou Vite, utilisez un Dockerfile.
• WorkersPour un worker de file d'attente, ajoutez au Procfile une ligne comme worker: php bin/worker.php ainsi qu'une ligne web: explicite : sans elle, la première entrée du Procfile autre que release: devient la commande par défaut. Le log de build affiche la commande de démarrage par défaut ; pour FrankenPHP, web: frankenphp php-server --listen :$PORT --root public/ fonctionne. Ajoutez ensuite dans l'onglet Processes un processus nommé worker sans port.
• Chemin du health checkLe trafic bascule vers une nouvelle release dès que / renvoie un code 2xx ou 3xx. Si / répond 401 ou 404, définissez dans les paramètres de l'app un chemin de health check qui renvoie 200.

Ce que Nodion gère pour vous

• Déploiements sans interruption Faites un push sur votre branche : Nodion construit une nouvelle release. Le trafic bascule lorsque les nouvelles instances réussissent leur health check ; si la release échoue, celle en cours reste active. Les apps avec un volume local redémarrent, car le disque appartient à une seule instance.
• Bases de données à côté de l'app PostgreSQL, pgvector, MySQL, Valkey et ClickHouse managés, dans la même région. Les bases de données rattachées arrivent sous forme de DATABASE_URL, REDIS_URL ou CLICKHOUSE_URL.
• Previews par pull request Activez les previews, et les pull requests de votre dépôt obtiennent leur propre app, avec sa propre URL et des bases de données neuves et vides, créées automatiquement ou à la main. Les pull requests issues de forks ou de bots sont ignorées.
• Workers, cron jobs et mise à l'échelle Exécutez les workers comme processus supplémentaires de la même app, planifiez des tâches dans l'onglet Cron et mettez chaque processus à l'échelle jusqu'à 16 instances.
• Étape de release Avec les buildpacks, une ligne release: du Procfile s'exécute à chaque nouveau build. Les apps Dockerfile, ainsi que les redéploiements ou les rollbacks vers une image antérieure, utilisent une commande de release définie sur l'app elle-même, qui prime aussi sur la ligne du Procfile. Sur les sites statiques, l'étape de release s'exécute dans une image qui ne contient que les fichiers générés par le build.
• Logs et métriques Logs de build, de release et d'exécution, ainsi que les métriques CPU, mémoire, disque et réseau de chaque instance, dans le dashboard.
• Domaines et HTTPS Un nom d'hôte par défaut avec HTTPS dès le premier déploiement, et des certificats automatiques pour vos propres domaines.

Pour aller plus loin

• Dockerfile vs buildpacks : lequel choisir ? Les deux transforment votre code en image de conteneur. La différence, c'est qui écrit les étapes du build, et cela détermine le contrôle, la maintenance et les mises à jour de sécurité.
• Les Cloud Native Buildpacks expliqués Les buildpacks transforment votre code source en image de conteneur sans Dockerfile. Ce qu'ils sont et comment ils fonctionnent.

PHP sur Nodion : questions et réponses