lancer une instance de nginx/apache par utilisateur, plus un reverse-proxy devant ?
Sur quelques dizaines de sites c'est une bonne solution mais elle est pour l'heure relativement difficile à industrialiser.
le monitoring et la conf sont très difficiles à gérer. Tu passes d'une sonde globale à une sonde par site (on parle des services pas de l'applicatif), d'un fichier de conf, php.ini unique … à un par site. Tu multiplie le risque d'erreur et le risque d'oublie. Si tu as par exemple 1000 vhosts par serveur web, cela multiplie tous ces éléments par mille et suppose une mise à l'échelle importante de tes outils (tes serveurs nagios par exemple). Si tu rajoutes à cela de la haute dispo ça devient vraiment très compliqué.
au niveau des ressources tu es obligé de partager à priori (typiquement avec apache un max_client par site). Tu gagne donc en cloisonnement mais tu perd en souplesse ("burst" d'un site). Eg : ton site fonctionne bien mais plante lors du passage d'un bot.
sur un très grand nombre de socket tu peux avoir des effets de bord difficiles à diagnostiquer.
idéalement tu chroot / jailise tout ça, alors tu as la problématique de gérer les points de montages (nullfs ou -o bind + /dev), les mails (fonction mail du php -> commande sendmail donc spool … )…
Par contre :
- le gain est énorme en sécurité
- le partage des ressources est efficace
Je suis en train d’essayer de prototyper ça sur une échelle assez importante. C'est loin d'être évident.
Avoir un serveur qui gère les différents utilisateurs est déja possible dans apache avec suexec. Cela offre un cloisonnement raisonnable (pour le fastcgi par exemple), facile à mettre en oeuvre et surtout une solution "facile" pour l'utilisateur final (son cms marche out of the box dans 90% des cas). Il est juste dommage de ne pas pouvoir en profiter pour les fichiers statiques également. Ce qui te permettrait de réduire considérablement les permissions sur les répertoires.
[^] # Re: Multi-utilisateur
Posté par Joris Dedieu (site web personnel) . En réponse à la dépêche Nginx 1.2, des progrès sur le code et les parts de marché. Évalué à 5.
Sur quelques dizaines de sites c'est une bonne solution mais elle est pour l'heure relativement difficile à industrialiser.
le monitoring et la conf sont très difficiles à gérer. Tu passes d'une sonde globale à une sonde par site (on parle des services pas de l'applicatif), d'un fichier de conf, php.ini unique … à un par site. Tu multiplie le risque d'erreur et le risque d'oublie. Si tu as par exemple 1000 vhosts par serveur web, cela multiplie tous ces éléments par mille et suppose une mise à l'échelle importante de tes outils (tes serveurs nagios par exemple). Si tu rajoutes à cela de la haute dispo ça devient vraiment très compliqué.
au niveau des ressources tu es obligé de partager à priori (typiquement avec apache un max_client par site). Tu gagne donc en cloisonnement mais tu perd en souplesse ("burst" d'un site). Eg : ton site fonctionne bien mais plante lors du passage d'un bot.
sur un très grand nombre de socket tu peux avoir des effets de bord difficiles à diagnostiquer.
idéalement tu chroot / jailise tout ça, alors tu as la problématique de gérer les points de montages (nullfs ou -o bind + /dev), les mails (fonction mail du php -> commande sendmail donc spool … )…
Par contre :
- le gain est énorme en sécurité
- le partage des ressources est efficace
Je suis en train d’essayer de prototyper ça sur une échelle assez importante. C'est loin d'être évident.
Avoir un serveur qui gère les différents utilisateurs est déja possible dans apache avec suexec. Cela offre un cloisonnement raisonnable (pour le fastcgi par exemple), facile à mettre en oeuvre et surtout une solution "facile" pour l'utilisateur final (son cms marche out of the box dans 90% des cas). Il est juste dommage de ne pas pouvoir en profiter pour les fichiers statiques également. Ce qui te permettrait de réduire considérablement les permissions sur les répertoires.