Exigences d'hébergement

Cette page définit le contrat d'hébergement pour une installation de production WebBlocks CMS. Il est destiné aux agences, aux opérateurs de serveurs et aux fournisseurs d'hébergement qui évaluent un serveur avant son déploiement.

WebBlocks CMS est un package Composer installé dans une application hôte Laravel. L'application hôte est propriétaire de son environnement, de son serveur Web, de sa base de données, de sa messagerie, de ses files d'attente, de ses tâches planifiées, de ses sauvegardes et de son déploiement. Le fait de répondre à lui seul aux exigences du package ne permet pas de déployer une application Laravel autrement incomplète.

Zone

Exigence minimale

PHP

PHP 8.3 ou version ultérieure dans la gamme ^8.3 prise en charge par Composer, avec CLI et le moteur d'exécution Web utilisant la même version compatible

Cadre

Cadre Laravel 12.55+ ou 13.x

Gestionnaire de dépendances

Composer 2, disponible lors de l'installation et des mises à jour système natives du package

Extensions PHP déclarées par le package

mbstring, sodium et zip

Base de données de base de production

MySQL 8.0 avec InnoDB, une base de données et des informations d'identification que l'application peut utiliser pour les tables, les index, les clés étrangères et les transactions

Serveur Web

Nginx, Apache ou un serveur équivalent pouvant acheminer les requêtes Laravel via public/index.php

Racine du document

Le répertoire public/ de l'application hôte, jamais la racine de l'application

TLS

HTTPS pour l'administration de la production et le trafic public

Composer répond également aux exigences de la plate-forme Laravel. Le fournisseur doit autoriser composer check-platform-reqs à passer pour l'application hôte complète ; le tableau ci-dessus ne remplace pas ce contrôle.

Aucun minimum universel de mémoire PHP ni délai d’expiration des requêtes certifié pour la production n’a encore été établi. La qualification locale partielle actuelle a fourni les valeurs provisoires de planification suivantes :

Charge de travail testée

Valeur provisoire de planification

, sans transformations d'images GD

PHP memory_limit d'au moins 128 Mio

Un travailleur PHP pouvant transformer des images avec GD

Au moins 512 Mio de capacité de processus réelle par travailleur simultané, qualifié pour les images source jusqu'à 6 000 × 4 000 pixels (24 MP)

La valeur de 128 MiB est une valeur candidate provisoire pour le cœur : la suite complète de tests fonctionnels a réussi ses cinq exécutions à cette limite et a échoué à 96 MiB. Elle ne suffit pas à elle seule au traitement d’images avec GD. Lors du test WebP de 24 MP, PHP n’a signalé que 32.5 MiB, alors que le pic réel de mémoire résidente du processus a atteint 312.26 MiB ; GD alloue une quantité importante de mémoire en dehors de la limite suivie par PHP memory_limit. L’application de la marge de sécurité du protocole de qualification donne un profil provisoire de planification de 512 MiB de mémoire réelle pour chaque processus PHP transformant des images simultanément.

Le chiffre de 512 Mio correspond à la capacité du serveur et non à la RAM totale du serveur. Le serveur doit en outre prendre en charge le système d'exploitation, le serveur Web, la base de données, les caches et d'autres serveurs PHP simultanés. Étant donné que le CMS limite actuellement la taille des fichiers téléchargés, mais pas les dimensions en pixels de la trame, 512 Mio ne peuvent pas garantir des images arbitraires plus grandes que la charge de travail testée de 24 MP. Voir Résultats de capacité d’hébergement pour la limite de mesures et de qualification.

SQLite est utilisé par la suite de tests de packages et est pris en charge par des chemins de code de sauvegarde/restauration spécifiques, mais il ne s'agit pas de la référence d'hébergement de production. Des chemins de sauvegarde et de restauration compatibles MariaDB existent, mais une version MariaDB ne fait actuellement pas partie de la matrice d'acceptation de production. PostgreSQL ne doit pas être proposé en tant que cible de production entièrement prise en charge tant que les flux complets d'installation, de migration, d'exploitation, de sauvegarde et de restauration ne sont pas couverts et documentés.

Les extensions requises doivent être activées dans les CLI PHP-FPM/Apache PHP et PHP. Un panneau d'hébergement qui expose différentes configurations pour le Web et la CLI PHP doit les maintenir alignées.

Les capacités suivantes sont conditionnelles :

• gd, y compris les codecs pour les formats multimédias utilisés, permet la génération de vignettes et d'images réactives. Sans cela, les transformations éligibles reviennent aux URL des médias d'origine.
• Le pilote PDO de la base de données doit correspondre à la base de données sélectionnée ; le profil MySQL de production a donc besoin de pdo_mysql.
• Les exigences standard des plates-formes Laravel et Composer, incluant généralement OpenSSL et la prise en charge des informations sur les fichiers, doivent rester activées comme l'exige l'application hôte résolue.
• proc_open et l'autorisation d'exécuter les processus PHP et Composer sont requis pour le flux de travail de mise à jour du système natif du package. Si le fournisseur désactive l'exécution du processus, les déploiements et les mises à jour doivent être gérés par l'opérateur en dehors du CMS.

Ne déduisez pas une exigence d’extension à partir d’une commande doctor de développement uniquement. La vérification d'installation faisant autorité est la résolution de plate-forme Composer pour l'application hôte complète, suivie des vérifications de préparation au CMS.

Le code déployé doit être lisible par le runtime PHP. L'utilisateur d'exécution PHP, ou un groupe de déploiement partagé, a besoin d'un accès en lecture/écriture à :

• storage/, y compris storage/framework, storage/logs, les supports publics, les espaces de travail temporaires et le disque de sauvegarde configuré ;
• bootstrap/cache;
• public/site, où des ressources de remplacement de site et de page peuvent être créées ;
• la racine de l'application et l'espace de travail de mise à jour configuré uniquement lorsque les mises à jour système natives du package modifieront le package installé ; et
• tout autre disque Laravel configuré par l'hôte pour les supports CMS ou les sauvegardes.

Utilisez la propriété ou un groupe de déploiement à portée étroite ; n'utilisez pas les autorisations 777 accessibles en écriture universelle. Le serveur doit autoriser le lien symbolique public/storage de Laravel lorsque le média public utilise le disque storage/app/public standard. Si les liens symboliques ne sont pas disponibles, l'hôte doit fournir un arrangement de service de disque public équivalent.

La racine de l'application, .env, vendor/, storage/, .git/ et les fichiers sources ne doivent pas être directement accessibles sur le Web. Les demandes telles que /.env et /.git/config doivent renvoyer 404.

Le serveur doit :

• servez directement les fichiers existants sous public/ et envoyez d'autres demandes au public/index.php de Laravel ;
• préserve les informations HTTPS et hôte via n'importe quel proxy inverse afin que Laravel génère des URL sécurisées correctes ;
• permettre à l'administrateur CMS sous /webadmin et aux actifs du package statique sous /cms de coexister ;
• évitez d'ajouter un contrôleur frontal public/cms/index.php ou de traiter /cms comme une route d'administration ; et
• prend en charge les tailles de corps de téléchargement et les délais d'expiration des demandes sélectionnés par l'opérateur pour la politique multimédia du site.

WebBlocks CMS ne publie pas encore de minimum certifié en production pour la mémoire PHP ni de délai d'expiration des demandes. Les résultats actuels de capacité établissent un noyau provisoire PHP memory_limit candidat de 128 Mio et un profil de capacité de processus testé de 512 Mio pour un travailleur de transformation GD de 24 MP. Cette dernière n'est pas universelle car les dimensions des pixels raster sont actuellement illimitées. Le plafond actuel de validation des médias CMS est de 50 Mio par téléchargement, et la mise à jour système native du package a un plancher de contrôle en amont d'espace libre absolu de 500 Mio ; aucune de ces valeurs ne constitue à elle seule une garantie générale de mémoire, de requête ou de capacité de stockage. Une proposition de fournisseur doit indiquer ses limites réelles. Utilisez Validation de la capacité d'hébergement pour qualifier et publier les minimums sauvegardés par la charge de travail.

Capacité

Dépendance d'hébergement

Variantes d'images

PHP GD avec le codec JPEG, PNG ou WebP requis

Notifications de contact et courrier de réinitialisation du mot de passe

Un transport de courrier Laravel fonctionnel et des informations d'identification du fournisseur

Notifications programmées

Laravel schedule:run toutes les minutes ; requis pour les notifications de contact par lots/quotidiennes ou de chat en direct et les résumés quotidiens des messages en attente. Nécessite également du courrier sortant fonctionnel et un cache partagé avec des verrous atomiques lorsque plusieurs travailleurs s'exécutent.

Ménage programmé

Le même planificateur Laravel ; facultatif uniquement lorsqu'aucune fonctionnalité activée ne nécessite un traitement planifié et qu'un nettoyage manuel est suffisant

Files d'attente

Propriété de l'application hôte ; non requis pour la génération synchrone d'images CMS ou l'indexation de recherche publique

Mises à jour système natives du package

HTTPS sortant, ZIP et sodium, Composer 2, proc_open, exécutable PHP/Composer, chemins d'application/de mise à jour inscriptibles et suffisamment d'espace libre pour le téléchargement, l'extraction, la sauvegarde et la restauration.

Sauvegarde/restauration MySQL native

mysqldump ou mariadb-dump pour l'exportation et mysql ou mariadb pour l'importation, disponibles pour le processus PHP

Importation de médias à distance

HTTP/HTTPS sortant soumis aux contrôles de sécurité du réseau du CMS et à toute politique de pare-feu d'hébergement

Un serveur peut exécuter le CMS sans fonctionnalités facultatives uniquement lorsque la fonctionnalité correspondante est désactivée ou gérée de manière opérationnelle ailleurs. La limitation doit être enregistrée lors du transfert.

L'application hôte doit avoir un APP_KEY fort, un APP_DEBUG=false, un APP_URL public correct, des cookies de session sécurisés sur HTTPS, des informations d'identification de base de données fonctionnelles et des paramètres de session/cache/mail adaptés à la production. Les secrets appartiennent à l'environnement et ne doivent pas être validés ou exposés via la racine du document.

Le contrat d'hébergement doit également définir :

• comment la base de données et les fichiers téléchargés sont sauvegardés en dehors de l'application ;
• comment les versions sont déployées lorsque les mises à jour intégrées à l'application ne sont pas disponibles ;
• comment PHP-FPM ou le service correspondant est rechargé lorsque OPcache ne valide pas les horodatages ;
• où les journaux sont conservés et comment l'épuisement du disque est surveillé ; et
• qui est responsable du renouvellement TLS, de la maintenance de la base de données, des tests de restauration et de la réponse aux incidents.

Les sauvegardes au niveau de l'application ne remplacent pas les sauvegardes du fournisseur ou de l'infrastructure.

Avant d'approuver un hôte, examinez les résultats actuels de la capacité d'hébergement , sélectionnez ou qualifiez un profil testé à l'aide du Validation de la capacité d'hébergement, puis terminez la préparation à l'hébergement . Liste de contrôle. Après le déploiement, exécutez :

Vérifiez ensuite le site public, /webadmin/login, les ressources statiques /cms, le téléchargement de médias et tout service dépendant des fonctionnalités activé. System Update a son propre contrôle en amont réussite/échec et doit rester indisponible lorsque l'une de ses exigences échoue.

Voir également Installation, Sécurité, OOpérations et Media Image Variantes.