Fai il deploy di PHP su Nodion

Deploy di PHP passo dopo passo

1. Aggiungi composer.json e fai il commit di composer.lock Nodion riconosce PHP dal composer.json. Un repository con solo un index.php non viene riconosciuto; se non hai ancora un composer.json, ne basta uno piccolo come questo. La build esegue composer install --no-dev --optimize-autoloader, quindi tutto ciò che serve all'app in esecuzione va in require, non in require-dev. Fai il commit di composer.lock, così la build installa le versioni che hai testato. composer.json

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

2. Metti i file pubblici in public/ FrankenPHP usa public/ come document root. Se manca, Nodion prende web/, e se mancano entrambe, la root del repository. Metti index.php e i tuoi asset in public/ e tieni vendor/, configurazione e codice sorgente accanto, così vengono serviti solo i file pensati per il web.

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

3. Scegli il server web FrankenPHP è la scelta predefinita e non richiede configurazione. Per php-fpm dietro nginx o Apache httpd, aggiungi BP_PHP_SERVER con il valore nginx o apache nella scheda Environment e spunta Build. Apache legge anche i tuoi file .htaccess. Qualsiasi altro valore fa fallire la build.
4. Crea l'app e collega un database Nella dashboard, crea un'applicazione dal tuo repository GitHub, GitLab, Bitbucket o Gitea, scegli il branch e la regione EU Central e lascia la strategia di build su Buildpacks. Poi crea un database MySQL o PostgreSQL nella stessa regione e collegalo nella scheda Environment: l'app riceve DATABASE_URL al deploy successivo, solo in fase di esecuzione. Contrassegna password e chiavi API come segrete.
5. Esegui le migrazioni a ogni deploy Una riga release: in un Procfile viene eseguita una volta per ogni build, dopo la build e prima che parta la nuova versione. Se fallisce, il deploy si ferma e la versione in esecuzione resta online. Tieni lo strumento di migrazione, per esempio Doctrine Migrations o Phinx, in require. Procfile

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

Da sapere

• Fissa la versione di PHPNodion legge prima .php-version, poi require.php in composer.json; senza nessuno dei due ottieni PHP 8.3. Un intervallo sceglie la release più recente compatibile, quindi con "^8.2" ottieni PHP 8.5. Per restare su una sola versione, scrivi 8.3 in .php-version o richiedi "8.3.*".
• SymfonyNodion riconosce Symfony da bin/console più symfony.lock, esegue bin/console cache:warmup --env=prod durante la build e imposta APP_ENV=prod e APP_DEBUG=0 in fase di esecuzione. Aggiungi APP_ENV=prod anche con il flag Build, così gli script Composer eseguiti durante l'installazione non usano dev dal tuo .env. Nodion non esegue asset-map:compile; con AssetMapper, aggiungilo agli auto-scripts in composer.json. Per le build con Encore o Vite, usa un Dockerfile.
• WorkerPer un worker delle code, aggiungi al Procfile una riga come worker: php bin/worker.php insieme a una riga web: esplicita, perché senza di essa la prima voce del Procfile diversa da release: diventa il comando predefinito. Il log di build mostra il comando di avvio predefinito; per FrankenPHP funziona web: frankenphp php-server --listen :$PORT --root public/. Poi aggiungi un processo chiamato worker senza porta nella scheda Processes.
• Percorso dell'health checkIl traffico passa a una nuova release appena / risponde con 2xx o 3xx. Se / risponde con 401 o 404, imposta nelle impostazioni dell'app un percorso di health check che restituisca 200.

Cosa gestisce Nodion per te

• Deploy senza downtime Fai push sul tuo branch e Nodion crea una nuova release. Il traffico passa alle nuove istanze solo quando superano l'health check; una release fallita lascia attiva quella in esecuzione. Le app con un volume locale invece si riavviano, perché il disco appartiene a una sola istanza.
• Database accanto all'app PostgreSQL, pgvector, MySQL, Valkey e ClickHouse gestiti, nella stessa regione. I database collegati arrivano come DATABASE_URL, REDIS_URL o CLICKHOUSE_URL.
• Anteprime per ogni pull request Attiva le anteprime: ogni pull request del tuo repository riceve un'app dedicata, con un proprio URL e database nuovi e vuoti, creata automaticamente o manualmente. Le pull request dai fork e quelle dei bot vengono ignorate.
• Worker, cron job e scalabilità Esegui i worker come processi aggiuntivi della stessa app, pianifica i job nella scheda Cron e scala ogni processo fino a 16 istanze.
• Fase di release Con i buildpack, la riga release: del Procfile viene eseguita a ogni nuova build. Le app con Dockerfile, così come i redeploy e i rollback a un'immagine precedente, usano un comando di release impostato sull'app stessa, che ha anche la precedenza sulla riga del Procfile. Nei siti statici, la fase di release gira in un'immagine che contiene solo i file generati dalla build.
• Log e metriche Nella dashboard trovi log di build, release e runtime, oltre alle metriche di CPU, memoria, disco e rete per ogni istanza.
• Domini e HTTPS Un hostname predefinito con HTTPS dal primo deploy; i tuoi domini ricevono i certificati in automatico.

Per approfondire

• Dockerfile vs buildpack: quale dovresti usare? Entrambi trasformano il tuo codice in un'immagine container. Cambia chi scrive i passaggi della build, e questo determina controllo, manutenzione e aggiornamenti di sicurezza.
• Cloud Native Buildpacks: cosa sono e come funzionano I buildpack trasformano il tuo codice sorgente in un'immagine container senza Dockerfile. Cosa sono e come funzionano.

PHP su Nodion: domande e risposte