Requisiti di hosting

Questa pagina definisce il contratto di hosting per un'installazione di produzione WebBlocks CMS. È destinato ad agenzie, operatori di server e provider di hosting che valutano un server prima della distribuzione.

WebBlocks CMS è un pacchetto Composer installato in un'applicazione host Laravel. L'applicazione host possiede il proprio ambiente, server Web, database, posta, code, attività pianificate, backup e distribuzione. Il solo soddisfacimento dei requisiti del pacchetto non rende distribuibile un'applicazione Laravel altrimenti incompleta.

area

Requisito minimo

PHP

PHP 8.3 o più recente all'interno della gamma ^8.3 supportata da Composer, con CLI e runtime web che utilizzano la stessa versione compatibile

Quadro

Laravel Quadro 12.55+ oppure 13.x

Gestore dipendenze

Composer 2, disponibile durante l'installazione e gli aggiornamenti di sistema nativi del pacchetto

PHP estensioni dichiarate dal pacchetto

mbstring, sodium e zip

Baseline database di produzione

MySQL 8.0 con InnoDB, un database e credenziali che l'applicazione può utilizzare per tabelle, indici, chiavi esterne e transazioni

Server web

Nginx, Apache o un server equivalente in grado di instradare le richieste Laravel tramite public/index.php

Radice del documento

La directory public/ dell'applicazione host, mai la root dell'applicazione

TLS

HTTPS per amministrazione produzione e traffico pubblico

Composer risolve anche i requisiti della piattaforma Laravel. Il provider deve consentire a composer check-platform-reqs di passare per l'applicazione host completa; la tabella sopra non sostituisce il check.

Non è ancora stato stabilito un minimo universale di memoria PHP o un timeout delle richieste certificato per la produzione. La qualificazione locale parziale attuale ha prodotto questi valori provvisori di pianificazione:

Carico di lavoro verificato

Valore provvisorio di pianificazione

Core CMS, senza trasformazioni di immagini GD

PHP memory_limit di almeno 128 MiB

Un lavoratore PHP che può trasformare le immagini con GD

Almeno 512 MiB di capacità di processo effettiva per lavoratore simultaneo, qualificato per immagini sorgente fino a 6.000 × 4.000 pixel (24 MP)

Il valore di 128 MiB è un candidato provvisorio per il nucleo: l’intera suite di test delle funzionalità è passata in tutte e cinque le esecuzioni con questo limite e ha fallito a 96 MiB. Da solo non basta per elaborare immagini con GD. Nel test WebP da 24 MP, PHP ha riportato solo 32.5 MiB, mentre il picco reale di memoria residente del processo ha raggiunto 312.26 MiB; GD alloca molta memoria al di fuori del limite monitorato da PHP memory_limit. Applicando il margine di sicurezza del protocollo di qualificazione, si ottiene un profilo provvisorio di pianificazione di 512 MiB di memoria reale per ogni processo PHP che trasformi immagini contemporaneamente.

La cifra di 512 MiB è la capacità del lavoratore, non la RAM totale del server. Il server deve inoltre ospitare il sistema operativo, il server Web, il database, le cache e altri lavoratori PHP simultanei. Poiché il CMS attualmente limita le dimensioni dei file caricati ma non le dimensioni dei pixel raster, 512 MiB non possono garantire immagini arbitrarie più grandi del carico di lavoro testato di 24 MP. Vedi Risultati della capacità di hosting per le misurazioni e il confine di qualificazione.

SQLite viene utilizzato dalla suite di test del pacchetto ed è supportato da percorsi di codice di backup/ripristino specifici, ma non è la base di hosting dell'hosting di produzione. Esistono percorsi di backup e ripristino compatibili con MariaDB, ma una versione di MariaDB non fa attualmente parte della matrice di accettazione della produzione. PostgreSQL non deve essere offerto come destinazione di produzione completamente supportata fino a quando i flussi completi di installazione, migrazione, funzionamento, backup e ripristino non saranno coperti e documentati.

Le estensioni richieste devono essere abilitate sia nella CLI PHP-FPM/Apache PHP che nella CLI PHP. Un pannello di hosting che espone diverse configurazioni per web e CLI PHP deve mantenerle allineate.

Le seguenti funzionalità sono condizionali:

• gd, inclusi i codec per i formati multimediali in uso, consente la generazione di miniature e immagini reattive. Senza di esso, le trasformazioni idonee ricadono negli URL multimediali originali.
• Il driver PDO del database deve corrispondere al database selezionato; il profilo MySQL di produzione necessita quindi di pdo_mysql.
• I requisiti della piattaforma standard Laravel e Composer, comunemente inclusi OpenSSL e il supporto delle informazioni sui file, devono rimanere abilitati come richiesto dall'applicazione host risolta.
• proc_open e l'autorizzazione per eseguire i processi PHP e Composer sono necessari per il flusso di lavoro di aggiornamento del sistema nativo del pacchetto. Se il provider disabilita l'esecuzione del processo, le distribuzioni e gli aggiornamenti devono essere gestiti dall'operatore all'esterno del CMS.

Non dedurre un requisito di estensione da un comando medico di solo sviluppo. Il controllo di installazione autorevole è la risoluzione della piattaforma Composer per l'applicazione host completa, seguita dai controlli di idoneità del CMS.

Il codice distribuito deve essere leggibile dal runtime PHP. L'utente runtime PHP o un gruppo di distribuzione condiviso necessita dell'accesso in lettura/scrittura a:

• storage/, inclusi storage/framework, storage/logs, supporti pubblici, aree di lavoro temporanee e disco di backup configurato;
• bootstrap/cache;
• public/site, dove è possibile creare risorse di sostituzione del sito e della pagina;
• la radice dell'applicazione e l'area di lavoro di aggiornamento configurata solo quando gli aggiornamenti di sistema nativi del pacchetto modificheranno il pacchetto installato; e
• qualsiasi altro disco Laravel configurato dall'host per supporti o backup CMS.

Utilizzare la proprietà o un gruppo di distribuzione con ambito ristretto; non utilizzare le autorizzazioni 777 scrivibili da tutti. Il server dovrebbe consentire il collegamento simbolico public/storage di Laravel quando i media pubblici utilizzano il disco storage/app/public standard. Se i collegamenti simbolici non sono disponibili, l'host deve fornire un accordo di servizio del disco pubblico equivalente.

La radice dell'applicazione, .env, vendor/, storage/, .git/ e i file di origine non devono essere direttamente accessibili dal Web. Richieste come /.env e /.git/config devono restituire 404.

Il server deve:

• serve direttamente i file esistenti sotto public/ e invia altre richieste a public/index.php di Laravel;
• preserva HTTPS e informazioni sull'host tramite qualsiasi proxy inverso in modo che Laravel generi URL sicuri corretti;
• consente all'amministratore CMS in /webadmin e alle risorse del pacchetto statico in /cms di coesistere;
• Evitare di aggiungere un controller frontale public/cms/index.php o di trattare /cms come percorso amministrativo; e
• supporta le dimensioni del corpo del caricamento e i timeout di richiesta selezionati dall'operatore per la politica sui media del sito.

WebBlocks CMS non pubblica ancora un minimo certificato dalla produzione per la memoria PHP o il timeout della richiesta. Gli attuali risultati di capacità stabiliscono un candidato core provvisorio PHP memory_limit di 128 MiB e un profilo testato di capacità di processo di 512 MiB per un lavoratore di trasformazione GD da 24 MP. Quest'ultimo non è universale perché le dimensioni dei pixel raster sono attualmente illimitate. L'attuale limite massimo di convalida multimediale CMS è di 50 MiB per caricamento e l'aggiornamento del sistema nativo del pacchetto ha un limite di preflight di spazio libero assoluto di 500 MiB; nessuno dei due valori da solo costituisce una garanzia generale di memoria, richiesta o capacità di archiviazione. Una proposta del fornitore deve indicare i suoi limiti effettivi. Utilizza Convalida della capacità di hosting per qualificare e pubblicare i minimi supportati dal carico di lavoro.

Capacità

Dipendenza dall'hosting

Varianti di immagini

PHP GD con il codec JPEG, PNG o WebP richiesto

Notifiche di contatto ed e-mail di reimpostazione della password

Un trasporto di posta Laravel funzionante e credenziali del fornitore

Notifiche pianificate

Laravel schedule:run ogni minuto; richiesto per le notifiche di contatti batch/giornalieri o live chat e i riepiloghi giornalieri dei messaggi in sospeso. Richiede inoltre il funzionamento della posta in uscita e una cache condivisa con blocchi atomici quando vengono eseguiti più nodi di lavoro.

Pulizie programmate

Lo stesso pianificatore Laravel; facoltativo solo quando nessuna funzionalità abilitata richiede un'elaborazione pianificata ed è sufficiente la pulizia manuale

Code

Di proprietà dell'applicazione host; non richiesto per la generazione sincrona di immagini CMS o l'indicizzazione della ricerca pubblica

Aggiornamenti di sistema nativi del pacchetto

HTTPS in uscita, ZIP e sodio, Composer 2, proc_open, eseguibile PHP/Composer, percorsi di aggiornamento/applicazione scrivibili e spazio libero sufficiente per download, estrazione, backup e rollback

Backup/ripristino MySQL nativo

mysqldump o mariadb-dump per l'esportazione e mysql o mariadb per l'importazione, disponibili per il processo PHP

Importazione multimediale remota

HTTP/HTTPS in uscita soggetto ai controlli di sicurezza della rete CMS e a eventuali criteri del firewall di hosting

Un server può eseguire il CMS senza funzionalità opzionali solo quando la funzionalità corrispondente è disabilitata o gestita operativamente altrove. La limitazione deve essere registrata durante l'handoff.

L'applicazione host deve avere un APP_KEY, APP_DEBUG=false potente, un APP_URL pubblico corretto, cookie di sessione protetti su HTTPS, credenziali del database funzionanti e impostazioni di sessione/cache/e-mail adeguate alla produzione. I segreti appartengono all'ambiente e non devono essere sottoposti a commit o esposti tramite la root del documento.

L'accordo di hosting deve inoltre definire:

• come viene eseguito il backup del database e dei file caricati all'esterno dell'applicazione;
• come vengono distribuite le versioni quando gli aggiornamenti in-app non sono disponibili;
• come PHP-FPM o il servizio pertinente viene ricaricato quando OPcache non convalida i timestamp;
• dove vengono conservati i registri e come viene monitorato l'esaurimento del disco; e
• chi possiede il rinnovo TLS, la manutenzione del database, i test di ripristino e la risposta agli incidenti.

I backup a livello di applicazione non sostituiscono i backup del provider o dell'infrastruttura.

Prima di approvare un host, rivedere gli attuali Risultati della capacità di hosting, selezionare o qualificare un profilo testato utilizzando Convalida della capacità di hosting, quindi completare Preparazione dell'hosting Lista di controllo. Dopo la distribuzione, eseguire:

Quindi verificare il sito pubblico, /webadmin/login, le risorse statiche /cms, il caricamento multimediale e qualsiasi servizio dipendente dalle funzionalità abilitato. System Update dispone di un proprio preflight superato/fallito e deve rimanere non disponibile quando uno dei suoi requisiti fallisce.

Vedi anche Installazione, Sicurezza, Operazioni e Immagine multimediale Varianti.