Passer au contenu 
Le CloudLinux PHP Selector permet de contrôler, pour chaque compte, la version spécifique de PHP et les extensions activées, sans modifier le paramètre par défaut à l'échelle du serveur. Je vais vous montrer comment cette technologie fonctionne dans CageFS et LVE, et quelles Frontières sont applicables et comment utiliser le Selector en toute sécurité au quotidien.
Points centraux
- Architecture: alt-php s'exécute de manière isolée dans CageFS avec son propre espace de noms.
- Conditions préalables: CageFS activé, paquets « alt-php » installés, gestionnaire adapté.
- Utilisez: Choisir une version, activer les extensions, modifier les paramètres du fichier php.ini.
- Délimitation: MultiPHP Manager utilise la valeur par défaut, Selector la remplace dans le compte.
- Cabinet médical: Configuration par site via des isolats pour les environnements de projets mixtes.
Fonctionnement interne du CloudLinux PHP Selector
Je considère le « Selector » comme un commutateur qui, dans l'espace de noms CageFS personnel du compte, sélectionne les ancien PHP-affiche les binaires. Ces versions alternatives sont distinctes du PHP système et utilisent leurs propres chemins d'accès ainsi que leur propre configuration. Dès que je définis la version dans le panneau de configuration, l'appel de php dans mon contexte utilisateur accède précisément à ce binaire. Le PHP système n’est pas affecté par cette opération, ce qui permet aux administrateurs de conserver leur Défaut . L'isolation assurée par LVE et CageFS est déterminante : chaque projet s'exécute dans son propre contexte, de sorte que les dépendances et les chemins d'accès des projets voisins n'ont aucune incidence.
Conditions préalables et compatibilité
Le Selector ne fonctionne pas sans CageFS actif, car seul cet environnement encapsule le Compte correctement. De plus, les paquets « alt-php » doivent être installés, sinon le panneau d'administration n'affiche aucune option. Le gestionnaire PHP existant du serveur reste déterminant ; le sélecteur ne le remplace pas, mais s'appuie sur lui. Pour choisir entre CGI, FCGI, LSAPI ou FPM, voici un petit Comparaison des gestionnaires PHP, afin que je puisse planifier correctement l'environnement d'exécution. mod_php/DSO ou certaines configurations FPM peuvent poser problème s'ils ne sont pas conçus pour être utilisés avec CageFS ont été préparés.
Processus d'installation et d'administration
Dans la pratique, je configure toujours le Selector en suivant une procédure claire : je commence par installer les versions d'alt-php nécessaires, ainsi que les extensions standard (par exemple 8.1, 8.2, 8.3, et éventuellement 7.4 pour les applications héritées). Ensuite, j’initialise et mets à jour CageFS afin que les nouveaux binaires soient intégrés dans les squelettes des utilisateurs. Dans le panneau de configuration, j’active le Selector et je définis les versions et les modules qui seront proposés. Je veille à ce que la liste reste volontairement concise afin de limiter l’empreinte mémoire et d’éviter les conflits.
Pour m'assurer de la qualité, je teste avec un compte de démonstration : phpinfo() sur le Web et php -v dans la session SSH me permettent de vérifier si les chemins d'accès sont correctement affichés dans CageFS. Ce n’est que lorsque les cas CGI/FCGI/LSAPI fonctionnent correctement et que la liste des extensions apparaît dans son intégralité que je mets la fonctionnalité à la disposition des clients. J’effectue ensuite les mises à jour en versionnant : les nouveaux paquets alt-php sont d’abord déployés sur les hôtes de préproduction, puis sur les nœuds de production avec une fenêtre de maintenance et une surveillance.
CloudLinux PHP Selector vs MultiPHP Manager
Je fais une distinction claire entre le niveau administrateur et le niveau utilisateur afin d'éviter tout malentendu. Le MultiPHP Manager définit, par domaine ou de manière globale, les paramètres système Version s'applique. Le CloudLinux PHP Selector me permet d'utiliser, au sein de mon compte, une version différente avec ses extensions et ses paramètres php.ini. Si la configuration par défaut du domaine et le choix effectué via le Selector coïncident de manière pertinente, la sélection de l'utilisateur s'applique de manière transparente. C'est ainsi que les administrateurs gèrent la sécurité Ligne de base-état, tandis que les utilisateurs peuvent passer librement à des versions antérieures ou plus récentes.
Fonctions pour les utilisateurs : version, extensions, php.ini
Au quotidien, je change de version PHP en fonction des besoins du projet, par exemple de la 7.4 à la 8.2, sans mettre en danger le reste du compte. Via l'interface graphique, j'active les options souhaitées Extensions PHP tels que intl, imagick, redis ou opcache en quelques clics. De plus, j'adapte les php.ini- des paramètres tels que memory_limit, upload_max_filesize, post_max_size ou max_execution_time. La liste blanche des directives modifiables est définie par l’administrateur, ce qui permet de protéger les options critiques pour la sécurité. Pour les logiciels plus anciens, j’utilise si nécessaire des versions Hardened PHP, qui intègrent des correctifs de sécurité pour les versions obsolètes Communiqués mettre à disposition.
Fonctionnement du fichier php.ini et héritage
Important pour l'utilisation quotidienne : quel fichier php.ini s'applique où ? Dans le Selector, je définis les paramètres par défaut valables pour tous les comptes. De plus, des fichiers .user.ini peuvent s'appliquer par répertoire, par exemple dans la racine des documents ou dans des sous-dossiers. Ces fichiers locaux remplacent alors certaines directives sans modifier la configuration globale du compte. Si j’utilise Apache, j’ajoute les valeurs nécessaires dans le fichier .htaccess via php_value/php_flag pour les gestionnaires concernés – à condition que l’administrateur l’autorise. Je veille à ce que la configuration soit claire et documentée : les paramètres à l’échelle du compte dans le Selector, les ajustements spécifiques au projet dans les fichiers .user.ini à proximité de l’application.
Sélecteur PHP par site et isolats
Auparavant, tous les sites web d'un même compte partageaient une configuration commune, ce qui compliquait la gestion d'environnements de projets hétérogènes. Grâce au sélecteur PHP par site, je peux attribuer à chaque site isolé sa propre Version et un ensemble d'extensions adapté. Cela me permet de faire fonctionner du code hérité sous la version 7.x, tandis qu'un nouveau projet tourne en parallèle sous la version 8.3. Le contrôle fonctionne actuellement de manière optimale dans les environnements cPanel et se configure via des outils CLI. Pour les agences, cela apporte une grande Avantages, car cela me permet de mettre en œuvre les migrations étape par étape et de manière transparente.
CLI, Cron et automatisation
L'environnement Web et l'interface CLI doivent utiliser la même version, sinon des erreurs difficiles à expliquer peuvent survenir. Dans les tâches Cron et les scripts de déploiement, j'appelle explicitement le binaire souhaité, par exemple via un chemin d'accès à l'ancienne version PHP du projet. Composer, WP-CLI et Artisan fonctionnent alors exactement avec les extensions et les limites de l'environnement sélectionné. Je vérifie à l'aide des commandes `php -v` et `php -m` dans le journal Cron si la version attendue et l'ensemble des modules sont bien actifs.
Pour les modifications en masse, je mise sur l'automatisation : pour chaque client, je peux basculer entre les versions et les modules via l'interface CLI, ce qui me permet d'harmoniser l'ensemble des comptes revendeurs. Je prévois d’emblée les retours en arrière en notant la version précédente et en revenant automatiquement à celle-ci si nécessaire. Ainsi, les mises à jour restent reproductibles et j’évite les états mixtes incohérents.
Limites et écueils typiques
Le Selector ne remplace pas la gestion centralisée de la version du système ; le contrôle par défaut reste donc assuré par les outils du panneau de configuration. Si CageFS est absent ou si les paquets « alt-php » ne sont pas installés, c'est le choix de l'utilisateur qui prévaut. pas comme prévu. Les utilisateurs ne modifient que les directives autorisées ; les paramètres plus avancés restent protégés. Dans les environnements où plusieurs outils coexistent, je veille à ce que deux systèmes ne modifient pas les versions en même temps. Ceux qui souhaitent utiliser des fonctions par site en dehors de cPanel doivent prévoir des solutions de contournement ou s'en tenir, pour l'instant, aux fonctions par compte.Paramètres.
Performances et sécurité
La présence de plusieurs versions sur un même serveur entraîne des besoins supplémentaires en mémoire vive, car chaque ancienne version de PHP gère son propre OPcache. Je limite donc le nombre de versions réellement nécessaires Communiqués et je mesure la consommation. Les limites LVE et CageFS protègent les comptes les uns des autres, ce qui reste particulièrement important sur les nœuds fortement sollicités. Pour les anciens systèmes, je mise sur Hardened-PHP afin de combler les failles critiques sans imposer immédiatement une migration du code ; je résume ici de manière pratique les détails concernant alt-php et les aspects liés à la sécurité : L'ancien PHP et la sécurité. Si l'on dimensionne judicieusement l'OPcache et que l'on évite les extensions superflues à partir depermet de maintenir les latences à un faible niveau.
Réglage fin d'OPcache et caches
Je configure l'OPcache pour chaque version et chaque compte de manière à ce qu'il reflète l'empreinte réelle du code : ne pas définir une valeur trop faible pour `opcache.memory_consumption`, définir une valeur raisonnable pour `revalidate_freq` et laisser les vérifications d'horodatage activées pour les projets de développement. Lors de déploiements comportant de nombreux fichiers, il est utile de vider les anciens caches avant la prochaine version, afin d’éviter l’exécution d’un bytecode obsolète. Si plusieurs versions sont actives en parallèle, je tiens compte du fait que chacune gère son propre cache ; cela influe sur les temps de préchauffage et les besoins en RAM. Je n’utilise APCu ou Redis que si l’application en tire profit : un nombre réduit de modules diminue la surface d’attaque et les incompatibilités.
Utilisation dans les agences et chez les revendeurs
Je fais la distinction entre maintenance et innovation en examinant d'abord les anciens projets, puis en les migrant de manière ciblée. Pour les tests, je transfère certains comptes vers une nouvelle plateforme à titre d'essai. Version, je mesure les temps de chargement et j’examine les journaux d’erreurs. Cela me permet de réduire au minimum les pannes et de proposer des mesures concrètes à mes clients. Parallèlement, je configure des paramètres spécifiques à chaque site afin que la boutique en ligne, la page d’accueil et l’environnement de test bénéficient chacun d’un environnement optimal. Cette approche réduit le volume des demandes d’assistance et augmente la Planification lors des mises à jour.
Guide de migration : de la version 7.x à la version 8.x
Pour les mises à jour importantes, je procède selon une liste de contrôle : je commence par créer une copie « staging » et j'y active la version cible (par exemple 8.2/8.3). Ensuite, je vérifie les éléments obsolètes dans le journal d'erreurs, j'active temporairement `display_errors` dans l'environnement de staging et j'utilise les contrôles de santé propres à l'application. Je teste explicitement les extensions critiques telles que intl, mbstring, gd, imagick, sodium et pdo_mysql. Si Composer est impliqué, je renouvelle les fichiers de verrouillage et je m'assure que les vérifications de plate-forme correspondent à la nouvelle version de PHP. Ce n’est que lorsque les tests fonctionnels, les caches et les tâches Cron fonctionnent correctement que je bascule le domaine de production. En cas d’urgence, je prévois une procédure de retour en arrière (état précédent du sélecteur, réinitialisation de l’OPcache, invalidation du cache).
Bonnes pratiques pour les prestataires
J'active systématiquement CageFS et je teste le sélecteur avec des sites de démonstration avant de valider la fonctionnalité. Je configure la version PHP à l'échelle du système de manière prudente, afin que le Défaut reste sécurisé, tandis que les clients peuvent passer à une version supérieure ou inférieure en toute flexibilité. Pour les applications populaires, j'indique des chemins de version clairs, par exemple „ WordPress à partir de la version 8.1, boutiques en ligne à partir de la version 8.2 “, accompagnés de brèves justifications. Je n’autorise que les extensions pertinentes et je supprime les modules expérimentaux susceptibles de poser des problèmes. De plus, je conserve les paquets « alt-php » et les correctifs « Hardened PHP » actuel, afin que les failles connues soient corrigées.
Compatibilité par gestionnaire : aperçu
Pour une configuration propre, je vérifie d’abord quel gestionnaire est utilisé en production et s’il est compatible avec CageFS. CGI, FastCGI et LSAPI fonctionnent généralement très bien, tandis que DSO n’est pas vraiment pertinent, car cela nuit à l’isolation. PHP-FPM peut fonctionner, mais nécessite des paramètres adaptés Profils et une attribution claire des processus par compte. suPHP est une solution historique, mais elle est souvent lente ; sur les serveurs très fréquentés, je préfère utiliser LSAPI ou FCGI. Le tableau suivant présente une vue synthétique des solutions courantes manipulateur et leur compatibilité avec le Selector.
| manipulateur | Compatibilité avec Selector | Brève |
|---|---|---|
| CGI (suexec) | Bon | Simple, isolé ; débit modéré, séparation fiable des défauts. |
| FastCGI (mod_fcgid) | Très bon | Rapide, configurable par compte ; utilisation efficace de la mise en cache. |
| LiteSpeed/LSAPI | Très bon | Haute performance, faible latence ; intégration testée avec CageFS. |
| PHP-FPM | En partie | Fonctionne avec une affectation correcte ; une configuration particulière est nécessaire. |
| mod_php/DSO | Faible | Absence d'isolation ; ne convient pas aux modèles CageFS/Selector. |
| suPHP | Suffisamment | Fiable, mais lent ; convient aux serveurs plus anciens, sinon prévoyez un remplacement. |
Extensions et bibliothèques natives : pièges à éviter
Outre les modules PHP, les bibliothèques système jouent également un rôle. intl dépend des versions d’ICU, imagick d’ImageMagick : si les paquets ne sont pas compatibles entre eux, certaines fonctions manquent ou les processus plantent. Je veille à ce que les extensions « alt-php » soient installées de manière cohérente par rapport à leurs dépendances et je supprime les doublons. Pour les applications héritées cryptées, je vérifie si des chargeurs sont disponibles pour la version choisie ; pour les versions très récentes de PHP, ceux-ci peuvent faire défaut, ce qui justifie alors une version intermédiaire (par exemple 8.1 au lieu de 8.3). En règle générale : le moins de modules possible, autant que nécessaire, et toujours documenter les modifications.
Troubleshooting : images typiques d'erreurs
Si la version configurée semble être ignorée, je vérifie d'abord CageFS et les ancien PHP-Paquets. Si le panneau n’affiche aucune extension, cela signifie généralement que des paquets manquent ou que la liste blanche bloque l’affichage. Si un site fonctionne de manière inopinément lente, je vérifie les tailles de l’OPcache, la liste des extensions et le choix du gestionnaire. L'absence de droits d'écriture dans le dossier tmp ralentit les sessions et les téléchargements ; c'est pourquoi je définis clairement les chemins d'accès et les droits. En cas d'erreurs 502/504, j'augmente à titre d'essai la valeur de `max_execution_time` et je fixe des limites réalistes avant de procéder à des modifications plus importantes. Migrations-étapes.
Surveillance et diagnostic en service
Je simplifie l'observabilité : pour chaque site, je mets en place un fichier error_log propre et, après chaque changement de version, je surveille de très près les premières heures. Avec FPM/LSAPI, j'utilise les options « slow log » ou de débogage pendant les phases de test afin de mettre en évidence les goulots d'étranglement. Au niveau du serveur, je surveille les limites LVE (CPU, RAM, E/S, EP) et j'analyse les pics : ceux qui atteignent régulièrement ces limites ont tout intérêt à procéder à un réglage ou à opter pour une offre plus puissante. À l’aide de petits tests de charge (par exemple, des warm-ups ou des cron-seeds), je recueille des valeurs de référence afin de pouvoir déterminer rapidement, en cas de réclamations, si le problème provient de l’application, du gestionnaire, du réseau ou des limites.
En bref
Le CloudLinux PHP Selector m'offre la Liberté, de choisir pour chaque compte ou site la version PHP adaptée ainsi que ses extensions. La technologie s'appuie sur LVE et CageFS, utilise alt-php indépendamment du système et respecte le gestionnaire existant. En respectant les conditions préalables, vous bénéficiez d'une isolation, de performances prévisibles et d'une réduction des demandes d'assistance. Je garde les paramètres par défaut prudents, je laisse aux utilisateurs une marge de manœuvre ciblée et je documente des parcours de migration clairs. Ainsi, l’hébergement reste fiable, flexible et en toute sécurité – aussi bien pour WordPress que pour les boutiques en ligne et les projets personnalisés.
