Ir al contenido 
El CloudLinux PHP Selector controla, para cada cuenta, la versión concreta de PHP y las extensiones activadas, sin modificar la configuración predeterminada de todo el servidor. Te mostraré cómo funciona esta tecnología en CageFS y LVE, y cuáles Límites y cómo utilizar el selector de forma segura en el día a día.
Puntos centrales
- Arquitectura: alt-php se ejecuta de forma aislada en CageFS con su propio espacio de nombres.
- Requisitos previos: CageFS activado, paquetes «alt-php» instalados, controlador adecuado.
- Utilice: Seleccionar la versión, activar las extensiones, ajustar los parámetros de php.ini.
- Demarcación: MultiPHP Manager establece el valor por defecto, pero el selector lo anula en la cuenta.
- Práctica: Configuración por sitio mediante Isolates para entornos de proyectos mixtos.
Cómo funciona internamente el CloudLinux PHP Selector
Considero que el selector es un conmutador que, dentro del espacio de nombres personal de CageFS de la cuenta, activa los php antiguo-Muestra los binarios. Estas versiones alternativas están separadas del PHP del sistema y utilizan sus propias rutas y su propia configuración. En cuanto configuro la versión en el panel, al llamar a php dentro de mi contexto de usuario se accede precisamente a este binario. El PHP del sistema no se ve afectado por ello, lo que permite a los administradores seguir contando con su fiable Por defecto mantener. Lo decisivo es el aislamiento que proporcionan LVE y CageFS: cada proyecto se ejecuta en su propio contexto, por lo que las dependencias y las rutas de los proyectos vecinos no influyen en nada.
Requisitos y compatibilidad
El selector no funciona si CageFS no está activo, ya que solo este entorno encapsula el Cuenta correcto. Además, deben estar instalados los paquetes «alt-php»; de lo contrario, el panel no mostrará ninguna opción de selección. El gestor de PHP existente del servidor sigue siendo el determinante; el selector no lo sustituye, sino que se basa en él. Para elegir entre CGI, FCGI, LSAPI o FPM, resulta útil una breve Comparación de gestores PHP, para que pueda planificar correctamente el entorno de ejecución. mod_php/DSO o determinadas configuraciones de FPM pueden suponer un problema si no están preparadas para su uso con CageFS se prepararon.
Flujo de trabajo de instalación y administración
En la práctica, siempre configuro el Selector siguiendo un proceso claro: primero instalo las versiones antiguas de PHP necesarias, junto con las extensiones estándar (por ejemplo, 8.1, 8.2, 8.3 y, si es necesario, 7.4 para sistemas heredados). A continuación, inicializo y actualizo CageFS para que los nuevos binarios se incorporen a los plantillas de usuario. En el panel de control, activo el selector y defino qué versiones y módulos se van a ofrecer. Mantengo la lista deliberadamente reducida para limitar el consumo de RAM y evitar conflictos.
Para garantizar la calidad, realizo pruebas con una cuenta de demostración: phpinfo() en la web y php -v en el inicio de sesión SSH me indican si las rutas se muestran correctamente en CageFS. Solo cuando los casos de CGI/FCGI/LSAPI funcionan correctamente y la lista de extensiones aparece al completo, habilito la función para los clientes. A continuación, aplico las actualizaciones con numeración de versión: los nuevos paquetes de «alt-php» se instalan primero en los servidores de staging y, después, en los nodos de producción con una ventana de mantenimiento y supervisión.
CloudLinux PHP Selector frente a MultiPHP Manager
Distingo claramente entre el nivel de administrador y el nivel de usuario para evitar malentendidos. El MultiPHP Manager establece, por dominio o de forma global, qué ajustes a nivel del sistema Versión se aplica. El CloudLinux PHP Selector me permite utilizar, dentro de mi cuenta, una versión diferente, junto con sus extensiones y la configuración del archivo php.ini. Si la configuración predeterminada del dominio y la elección del selector coinciden de forma adecuada, la selección del usuario se aplica de forma transparente. De este modo, los administradores controlan la seguridad Línea de base-Estado, mientras que los usuarios pueden cambiar de forma flexible a versiones anteriores o posteriores.
Funciones para usuarios: versión, extensiones, php.ini
En mi día a día, cambio la versión de PHP según las necesidades del proyecto, por ejemplo, de la 7.4 a la 8.2, sin poner en riesgo el resto de la cuenta. A través de la interfaz gráfica, activo la versión deseada Extensiones PHP como intl, imagick, redis u opcache con solo unos clics. Además, adapto los típicos php.iniValores como memory_limit, upload_max_filesize, post_max_size o max_execution_time. La lista blanca de las directivas modificables la establece el administrador, lo que garantiza que las opciones críticas para la seguridad permanezcan protegidas. Para el software más antiguo, utilizo, cuando es necesario, versiones de PHP reforzadas que incluyen correcciones de seguridad para versiones descatalogadas Comunicados proporcionar.
Mecánica del archivo php.ini y herencia
Importante para el día a día: ¿qué archivo php.ini se aplica en cada lugar? En el selector defino los valores predeterminados para toda la cuenta. Además, pueden aplicarse archivos .user.ini por directorio, por ejemplo, en la raíz de documentos o en subcarpetas. Estos archivos locales anulan entonces determinadas directivas sin modificar la configuración global de la cuenta. Si trabajo con Apache, añado los valores necesarios en el archivo .htaccess mediante php_value/php_flag para los controladores adecuados, siempre que el administrador lo permita. Mantengo la configuración clara y documentada: ajustes para toda la cuenta en el Selector y ajustes específicos del proyecto en el archivo .user.ini, cerca de la aplicación.
Selector de PHP por sitio y aislamientos
Antes, todos los sitios web de una misma cuenta compartían una misma configuración, lo que complicaba la gestión de entornos de proyectos mixtos. Con el selector de PHP por sitio, puedo asignar una configuración propia a cada sitio aislado. Versión y un conjunto de extensiones adecuado. Así consigo que el código heredado funcione en la versión 7.x, mientras que un nuevo proyecto funciona al mismo tiempo en la 8.3. El control funciona mejor actualmente en entornos cPanel y se configura mediante herramientas de la línea de comandos. Para las agencias, esto supone una clara Ventajas, porque puedo llevar a cabo las migraciones de forma gradual y transparente.
CLI, Cron y automatización
El entorno web y el de la CLI deben utilizar la misma versión; de lo contrario, se producen errores difíciles de explicar. En las tareas de Cron y en los scripts de implementación, invoco explícitamente el binario deseado, por ejemplo, mediante una ruta a la versión «alt-php» del proyecto. De este modo, Composer, WP-CLI y Artisan se ejecutan exactamente con las extensiones y los límites del entorno seleccionado. Compruebo en el registro de Cron, mediante los comandos `php -v` y `php -m`, si están activas la versión y el conjunto de módulos esperados.
Para los cambios masivos, apuesto por la automatización: por cada cliente, puedo cambiar de versión y de módulo a través de la CLI y, de este modo, armonizar todos los carteras de los revendedores. Planifico las reversiones desde el principio, anotando la versión anterior y volviendo a ella automáticamente si es necesario. De este modo, las actualizaciones siguen siendo reproducibles y evito situaciones de inconsistencia.
Límites y obstáculos típicos
El selector no sustituye a la gestión centralizada de la versión del sistema, por lo que el control por defecto sigue recayendo en las herramientas del panel. Si no se dispone de CageFS o no se han instalado los paquetes «alt-php», se aplica la selección del usuario. no Como era de esperar. Los usuarios solo pueden modificar las directivas compartidas; los parámetros más avanzados permanecen protegidos. En entornos con herramientas que compiten entre sí, me aseguro de que no haya dos sistemas actualizando versiones al mismo tiempo. Quien quiera utilizar funciones por sitio fuera de cPanel, debe planificar soluciones alternativas o, por el momento, seguir utilizando las funciones por cuenta-Ajustes.
Rendimiento y seguridad
Tener varias versiones en un servidor genera una mayor necesidad de RAM, ya que cada versión antigua de PHP mantiene su propio OPcache. Por eso limito la variedad de versiones que realmente se necesitan Comunicados y mido el consumo. Los límites de LVE y CageFS protegen las cuentas entre sí, lo cual sigue siendo importante, sobre todo en nodos con una alta carga de trabajo. Para los sistemas antiguos, apuesto por Hardened-PHP para cerrar vulnerabilidades críticas sin forzar una migración inmediata del código; aquí resumo de forma práctica los detalles sobre alt-php y los aspectos de seguridad: El PHP antiguo y la seguridad. Quien configure OPcache de forma adecuada y evite ampliaciones innecesarias demantiene bajas las latencias.
Ajuste preciso de OPcache y cachés
Configuró el OPcache para cada versión y cada cuenta de manera que reflejara la huella real del código: no establecer un valor demasiado bajo para «opcache.memory_consumption», ajustar «revalidate_freq» de forma adecuada y mantener activadas las comprobaciones de marca de tiempo en los proyectos de desarrollo. En implementaciones con muchos archivos, resulta útil eliminar las cachés antiguas antes del siguiente lanzamiento, para evitar que se ejecute código byte obsoleto. Si hay varias versiones activas en paralelo, tengo en cuenta que cada una mantiene su propia caché; esto influye en los tiempos de calentamiento y en los requisitos de RAM. Solo utilizo APCu o Redis si la aplicación se beneficia de ello: un menor número de módulos reduce la superficie de ataque y las incompatibilidades.
Uso en agencias y distribuidores
Distingo entre mantenimiento e innovación: primero reviso los proyectos antiguos y luego los migro de forma selectiva. Para realizar pruebas, cambio algunas cuentas a prueba a un nuevo Versión, mido los tiempos de carga y reviso los registros de errores. De este modo, minimizo las interrupciones del servicio y puedo indicar a los clientes los pasos concretos que deben seguir. Al mismo tiempo, configuro los ajustes por sitio para que la tienda, la página de destino y el entorno de pruebas dispongan cada uno de un entorno óptimo. Este procedimiento reduce el volumen de solicitudes de asistencia y aumenta la Planificabilidad para actualizaciones.
Guía de migración: de la versión 7.x a la 8.x
Para cambios importantes, sigo una lista de comprobación: primero creo una copia de staging y activo allí la versión de destino (por ejemplo, 8.2/8.3). A continuación, compruebo las funciones obsoletas en el registro de errores, activo temporalmente display_errors en el entorno de staging y utilizo las comprobaciones de estado propias de la aplicación. Pruebo explícitamente las extensiones críticas como intl, mbstring, gd, imagick, sodium y pdo_mysql. Si interviene Composer, renuevo los archivos de bloqueo y me aseguro de que las comprobaciones de plataforma se ajusten a la nueva versión de PHP. Solo cuando las pruebas funcionales, las cachés y las tareas cron funcionan correctamente, realizo la conmutación del dominio de producción. Por si acaso, tengo preparada una medida de reversión (estado anterior del selector, reinicio de OPcache, invalidación de la caché).
Buenas prácticas para proveedores
Activo CageFS de forma sistemática y pruebo el selector con sitios de demostración antes de habilitar la función. Configuro la versión de PHP para todo el sistema de forma conservadora, para que el Por defecto se mantenga segura, mientras que los clientes puedan actualizar o volver a versiones anteriores de forma flexible. Para las aplicaciones más populares, indico rutas de versiones claras, como „WordPress a partir de la versión 8.1, tiendas a partir de la 8.2“, con breves explicaciones. Solo permito extensiones que tengan sentido y elimino los módulos experimentales que puedan causar problemas. Además, mantengo los paquetes «alt-php» y las correcciones de «Hardened PHP» actual, para que se hayan solucionado las vulnerabilidades conocidas.
Compatibilidad por controlador: resumen
Para garantizar una configuración correcta, lo primero que compruebo es qué gestor se utiliza en producción y si es compatible con CageFS. CGI, FastCGI y LSAPI suelen funcionar muy bien, mientras que DSO no tiene mucho sentido, ya que afecta negativamente al aislamiento. PHP-FPM puede funcionar, pero requiere una configuración adaptada Perfiles y una asignación clara de procesos por cada cuenta. suPHP tiene su historia, pero a menudo resulta lento; en servidores con mucho tráfico, prefiero utilizar LSAPI o FCGI. La siguiente tabla ofrece una visión resumida de los más habituales manipulador y su idoneidad con el Selector.
| manipulador | Compatibilidad con Selector | Nota breve |
|---|---|---|
| CGI (suexec) | Bien | Sencillo, aislado; rendimiento moderado, separación de errores sólida. |
| FastCGI (mod_fcgid) | Muy buena | Rápido, controlable por cuenta; permite un uso eficiente del almacenamiento en caché. |
| LiteSpeed/LSAPI | Muy buena | Alto rendimiento, baja latencia; integración probada con CageFS. |
| PHP-FPM | En parte | Funciona con una asignación correcta; requiere una configuración especial. |
| mod_php/DSO | Débil | Falta de aislamiento; no apto para CageFS/Selector. |
| suPHP | Suficiente | Es seguro, pero lento; vale para servidores antiguos, pero en los demás casos conviene prever su sustitución. |
Extensiones y bibliotecas nativas: dificultades
Además de los módulos de PHP, las bibliotecas del sistema también desempeñan un papel importante. «intl» depende de las versiones de ICU, e «imagick» de ImageMagick: si los paquetes no son compatibles entre sí, faltan funciones o los procesos se bloquean. Me aseguro de que las extensiones «alt-php» se instalen de forma coherente con sus dependencias y elimino los duplicados. En el caso de aplicaciones heredadas cifradas, compruebo si hay cargadores disponibles para la versión elegida; en las versiones de PHP muy recientes pueden faltar, lo que justifica entonces un paso intermedio (por ejemplo, 8.1 en lugar de 8.3). En general, se aplica lo siguiente: el menor número posible de módulos, tantos como sean necesarios, y documentar siempre los cambios.
Solución de problemas: patrones de error típicos
Si parece que no se tiene en cuenta la versión configurada, lo primero que hago es comprobar CageFS y los programas instalados php antiguo-Paquetes. Si el panel no muestra ninguna extensión, lo más probable es que falten paquetes o que la lista blanca bloquee su visualización. Si un sitio web funciona con una lentitud inesperada, compruebo los tamaños de OPcache, la lista de extensiones y la elección del gestor. La falta de permisos de escritura en la carpeta «tmp» ralentiza las sesiones y las subidas de archivos, por lo que defino claramente las rutas y los permisos. En caso de errores 502/504, aumento «max_execution_time» a modo de prueba y establezco límites realistas antes de realizar cambios más importantes. Migraciones-Planifico los pasos.
Supervisión y diagnóstico durante el funcionamiento
Para mí, la observabilidad es sencilla: en cada sitio web configuro un archivo `error_log` limpio y, tras cada cambio de versión, reviso con especial atención las primeras horas. Con FPM/LSAPI utilizo el `slow-log` o las opciones de depuración durante las fases de prueba para detectar cuellos de botella. A nivel de servidor, superviso los límites de LVE (CPU, RAM, E/S, EP) y analizo los picos: quien se topa con los límites de forma habitual se beneficia de un ajuste del sistema o de un paquete de mayor capacidad. Mediante pequeñas pruebas de carga (por ejemplo, warmups o cron-seeds) recopilo valores comparativos para poder determinar rápidamente, ante cualquier incidencia, si el problema se debe a la aplicación, al handler, a la red o a los límites.
Brevemente resumido
El CloudLinux PHP Selector me proporciona la Libertad, seleccionar la versión adecuada de PHP, incluidas las extensiones, para cada cuenta o sitio web. La tecnología se basa en LVE y CageFS, utiliza «alt-php» de forma independiente del sistema y respeta el gestor existente. Quien cumpla los requisitos previos se beneficiará de aislamiento, un rendimiento predecible y un menor número de incidencias de soporte técnico. Mantengo unos valores predeterminados conservadores, dejo a los usuarios un margen de maniobra específico y documento rutas de migración claras. De este modo, el alojamiento sigue siendo fiable, flexible y seguro – tanto para WordPress como para tiendas online y proyectos personalizados.
