Requisitos de alojamiento

Esta página define el contrato de hospedaje para una instalación de producción WebBlocks CMS. Está destinado a agencias, operadores de servidores y proveedores de alojamiento que evalúan un servidor antes de su implementación.

WebBlocks CMS es un paquete Composer instalado en una aplicación host Laravel. La aplicación host es propietaria de su entorno, servidor web, base de datos, correo, colas, tareas programadas, copias de seguridad e implementación. Cumplir los requisitos del paquete por sí solo no significa que se pueda implementar una aplicación Laravel que de otro modo estaría incompleta.

Area

Requisito mínimo

PHP

PHP 8.3 o posterior dentro del rango ^8.3 compatible con Composer, con CLI y tiempo de ejecución web que utilizan la misma versión compatible

Marco

Laravel Marco 12.55+ o 13.x

Administrador de dependencias

Composer 2, disponible durante la instalación y las actualizaciones del sistema nativas del paquete

PHP extensiones declaradas por el paquete

mbstring, sodium y zip

Línea base de base de datos de producción

MySQL 8.0 con InnoDB, una base de datos y credenciales que la aplicación puede usar para tablas, índices, claves foráneas y transacciones

Servidor web

Nginx, Apache o un servidor equivalente que pueda enrutar solicitudes Laravel a través de public/index.php

Raíz del documento

El directorio public/ de la aplicación host, nunca la raíz de la aplicación

TLS

HTTPS para administración de producción y tráfico público

Composer también resuelve los requisitos de plataforma propios de Laravel. El proveedor debe permitir que composer check-platform-reqs pase por la aplicación de host completa; la tabla anterior no reemplaza esa verificación.

Aún no se ha establecido un mínimo universal de memoria PHP ni un tiempo de espera de solicitudes certificado para producción. La cualificación local parcial actual produjo estos valores provisionales de planificación:

Carga de trabajo probada

Valor provisional de planificación

Núcleo CMS, sin transformaciones de imágenes GD

PHP memory_limit de al menos 128 MiB

Un trabajador PHP que puede transformar imágenes con GD

Al menos 512 MiB de capacidad de proceso real por trabajador simultáneo, calificado para imágenes de origen de hasta 6000 × 4000 píxeles (24 MP)

El valor de 128 MiB es un candidato provisional para el núcleo: la batería completa de pruebas pasó las cinco ejecuciones con ese límite y falló con 96 MiB. Por sí solo no basta para procesar imágenes con GD. En la prueba WebP de 24 MP, PHP informó solo de 32.5 MiB, mientras que el pico real de memoria residente del trabajador alcanzó 312.26 MiB; GD asigna una cantidad considerable de memoria fuera del límite registrado por PHP memory_limit. Al aplicar el margen de seguridad del protocolo de cualificación, se obtiene un perfil provisional de planificación de 512 MiB de memoria real por cada trabajador PHP que transforme imágenes simultáneamente.

La cifra de 512 MiB es la capacidad del trabajador, no la RAM total del servidor. El servidor debe alojar adicionalmente el sistema operativo, el servidor web, la base de datos, las cachés y otros trabajadores PHP simultáneos. Debido a que el CMS actualmente limita el tamaño de los archivos cargados pero no las dimensiones de píxeles rasterizados, 512 MiB no puede garantizar imágenes arbitrarias más grandes que la carga de trabajo probada de 24 MP. Ver Resultados de capacidad de alojamiento para las mediciones y el límite de calificación.

El conjunto de pruebas de paquetes utiliza SQLite y es compatible con rutas de código de copia de seguridad/restauración específicas, pero no es la base de alojamiento de producción. Existen rutas de copia de seguridad y restauración compatibles con MariaDB, pero actualmente una versión de MariaDB no forma parte de la matriz de aceptación de producción. PostgreSQL no debe ofrecerse como un destino de producción totalmente compatible hasta que se cubran y documenten todos los flujos de instalación, migración, operación, copia de seguridad y restauración.

Las extensiones requeridas deben estar habilitadas en PHP-FPM/Apache PHP y PHP CLI. Un panel de hosting que exponga diferentes configuraciones para web y CLI PHP debe mantenerlas alineadas.

Las siguientes capacidades son condicionales:

• gd, incluidos los códecs para los formatos multimedia en uso, permite la generación de miniaturas e imágenes responsivas. Sin él, las transformaciones elegibles recurren a las URL de medios originales.
• El controlador PDO de la base de datos debe coincidir con la base de datos seleccionada; por lo tanto, el perfil MySQL de producción necesita pdo_mysql.
• Los requisitos estándar de las plataformas Laravel y Composer, que normalmente incluyen OpenSSL y compatibilidad con información de archivos, deben permanecer habilitados según lo requiera la aplicación host resuelta.
• Se requieren proc_open y permiso para ejecutar los procesos PHP y Composer para el flujo de trabajo de actualización del sistema nativo del paquete. Si el proveedor deshabilita la ejecución del proceso, las implementaciones y actualizaciones deben ser administradas por un operador fuera del CMS.

No infiera un requisito de extensión a partir de un comando médico de solo desarrollo. La verificación de instalación autorizada es la resolución de la plataforma Composer para la aplicación host completa, seguida de las verificaciones de preparación del CMS.

El código implementado debe ser legible para el tiempo de ejecución PHP. El usuario de tiempo de ejecución PHP, o un grupo de implementación compartido, necesita acceso de lectura/escritura a:

• storage/, incluidos storage/framework, storage/logs, medios públicos, espacios de trabajo temporales y el disco de respaldo configurado;
• bootstrap/cache;
• public/site, donde se pueden crear recursos de anulación de páginas y sitios;
• la raíz de la aplicación y el espacio de trabajo de actualización configurado solo cuando las Actualizaciones del sistema nativas del paquete modifiquen el paquete instalado; y
• cualquier otro disco Laravel configurado por el host para medios CMS o copias de seguridad.

Use utiliza la propiedad o un grupo de implementación de alcance limitado; no utilice permisos de escritura mundial 777. El servidor debe permitir el enlace simbólico public/storage de Laravel cuando los medios públicos utilizan el disco estándar storage/app/public. Si los enlaces simbólicos no están disponibles, el host debe proporcionar un acuerdo de servicio de disco público equivalente.

La raíz de la aplicación, .env, vendor/, storage/, .git/ y los archivos fuente no deben ser accesibles directamente desde la web. Solicitudes como /.env y /.git/config deben devolver 404.

El servidor debe:

• servir archivos existentes debajo de public/ directamente y enviar otras solicitudes al public/index.php de Laravel;
• preservar HTTPS y la información del host a través de cualquier proxy inverso para que Laravel genere URL seguras correctas;
• permitir que coexistan el administrador de CMS en /webadmin y los activos de paquetes estáticos en /cms;
• evite agregar un controlador frontal public/cms/index.php o tratar a /cms como una ruta de administración; y
• admitir los tamaños del cuerpo de carga y solicitar tiempos de espera seleccionados por el operador para la política de medios del sitio.

WebBlocks CMS aún no publica un mínimo certificado de producción para la memoria PHP o el tiempo de espera de solicitud. Los resultados actuales de capacidad establecen un núcleo provisional PHP memory_limit candidato de 128 MiB y un perfil de capacidad de proceso probado de 512 MiB para un trabajador transformador de GD de 24 MP. Esto último no es universal porque las dimensiones de los píxeles rasterizados actualmente no tienen límites. El límite actual de validación de medios de CMS es de 50 MiB por carga, y la actualización del sistema nativa del paquete tiene un límite mínimo absoluto de verificación previa de espacio libre de 500 MiB; ninguno de los valores por sí solo es una garantía general de memoria, solicitud o capacidad de almacenamiento. La propuesta de un proveedor debe indicar sus límites reales. Utilice Validación de capacidad de alojamiento para calificar y publicar mínimos respaldados por cargas de trabajo.

Capacidad

Dependencia de alojamiento

Variantes de imagen

PHP GD con el códec JPEG, PNG o WebP requerido

Notificaciones de contacto y correo de restablecimiento de contraseña

Credenciales de proveedor y transporte de correo Laravel que funcionen

Notificaciones programadas

Laravel schedule:run cada minuto; requerido para contactos por lotes/diarios o notificaciones de chat en vivo y resúmenes diarios de mensajes pendientes. También requiere trabajar con correo saliente y un caché compartido con bloqueos atómicos cuando se ejecutan varios trabajadores.

limpieza programada

El mismo programador Laravel; opcional solo cuando ninguna función habilitada requiere un procesamiento programado y la limpieza manual es suficiente

Colas

Propiedad de la aplicación anfitriona; no es necesario para la generación síncrona de imágenes CMS o la indexación de búsqueda pública

Actualizaciones del sistema nativas del paquete

HTTPS saliente, ZIP y sodio, Composer 2, proc_open, ejecutable PHP/Composer, rutas de actualización/aplicación grabables y suficiente espacio libre para descarga, extracción, copia de seguridad y reversión

Copia de seguridad/restauración nativa de MySQL

mysqldump o mariadb-dump para exportación y mysql o mariadb para importación, disponibles para el proceso PHP

Importación remota de medios

HTTP/HTTPS saliente sujeto a las comprobaciones de seguridad de la red del CMS y a cualquier política de firewall de hosting

Un servidor puede ejecutar el CMS sin capacidades opcionales solo cuando la función correspondiente está deshabilitada o manejada operativamente en otro lugar. La limitación debe registrarse durante el traspaso.

La aplicación host debe tener un APP_KEY, un APP_DEBUG=false sólidos, un APP_URL público correcto, cookies de sesión seguras a través de HTTPS, credenciales de base de datos que funcionen y configuraciones de sesión/caché/correo apropiadas para producción. Los secretos pertenecen al entorno y no deben confirmarse ni exponerse a través de la raíz del documento.

El acuerdo de alojamiento también debe definir:

• cómo se realiza una copia de seguridad de la base de datos y los archivos cargados fuera de la aplicación;
• cómo se implementan las versiones cuando las actualizaciones en la aplicación no están disponibles;
• cómo se recarga PHP-FPM o el servicio relevante cuando OPcache no valida las marcas de tiempo;
• dónde se conservan los registros y cómo se monitorea el agotamiento del disco; y
• propietario de la renovación de TLS, el mantenimiento de la base de datos, las pruebas de restauración y la respuesta a incidentes.

Alas copias de seguridad a nivel de aplicación no reemplazan las copias de seguridad del proveedor o de la infraestructura.

Antes de aprobar un host, revise los resultados actuales de capacidad de hospedaje , seleccione o califique un perfil probado usando Hvalidación de capacidad de hospedaje, luego complete la preparación de hospedaje Lista de verificación. Después de la implementación, ejecute:

Luego verifique el sitio público, /webadmin/login, los activos estáticos de /cms, la carga de medios y cualquier servicio dependiente de funciones habilitado. La actualización del sistema tiene su propia verificación previa de aprobación/rechazo y no debe permanecer disponible cuando uno de sus requisitos falla.

Consulte también Instalación, Seguridad, Operaciones y Imagen multimedia Variantes.