Nouveau sur Spip, je manque sans doute encore de compréhension, mais Spip me semble avoir quelques défauts pour permettre une exploitation en mode scalabilité horizontale.
Ce genre d’architecture est difficilement compatible avec des solutions « stateful ».
Quelques sujets qui me semblent clé :
Cache partagé, y compris i) sessions et ii) squelettes (Redis/Valkey?)
Stockage fichier externalisé (stockage objet type S3?)
Gestion du cron par « génie » plutôt qu’externalisation sur un broker / système de queue tiers (RabbitMQ, SQS…)
Bonnes remarques et, hélas, non, l’appli n’est pas 12factor friendly. La scalabilité d’un site SPIP n’est pas « jouable » en l’état.
En ordre dispersé, certaines contributions, plugins, pourraient répondre en partie au besoin. C’est encore assez éparse et sans réelle réflexion commune.
L’effort actuel de développement pour SPIP5 ne sera qu’un pas. Il y aurait encore beaucoup de travail pour que ce soit natif, ou alternatif dans le cadre d’une sorte de distribution spécifique.
Je « m’amuse » (pour un projet client) à déployer Spip sur AWS Lambda via le framework Bref.
Pour l’instant, j’ai pu gérer :
CDN CloudFront devant l’appli
BDD dans Aurora DSQL (PostgreSQL-like)
Sessions dans DynamoDB (je ne voulais pas devoir gérer un « VPC »)
Gestion des fichiers dans S3 en cours…
ca commence à passer, mais vraiment aux forceps. On sent que le core de l’appli n’est pas architecturé pour permettre ce genre d’adaptation (i.e. j’aurai du mal à partager de vrais " plugins" enfichables aisément.
Tout en prévenant que de mon point de vue ce n’est pas un mal si certains morceaux peuvent devenir plus polyvalents et être soit internes soit externes, mais il faut quand même préciser que ce n’est pas du tout dans l’esprit de SPIP de chercher en premier lieu (ce qui ne veut pas dire que ça ne se ferait pas du tout) à être installable sur des systèmes morcelés ultra complexes, et encore moins sur Amazon et autres clouds gafam du même genre. Le but étant avant tout d’avoir une architecture relativement simple, compréhensible en peu de temps par le commun des mortel⋅les, et installable sur le plus de serveurs classiques (php à jour, sql, et basta). Et non un truc installable que par des adminsys/devops chevronné⋅es.
Par curiosité, est-ce que tu te posais ces questions parce que tu as en tête des limites bien précises à venir dans tes possibles utilisations (immensément de contenus ? un nombre très élevé d’utilisateurs connectés ? etc), ou c’est purement intellectuel, pour le principe ?
@rastapopoulos j’héberge pas mal d’applications PHP sur Lambda via Bref.
Bénéfices :
Scale to Zero = env de test gratuits
Scale illimité = bon pour les charges de travail variables
Zero infra à maintenir, hautement disponible par conception
Intégré avec le reste de l’écosystème AWS
Là en l’occurrence c’est le client qui force le choix de Spip pour le backend de son application (à mon humble avis, c’est overkill fonctionnellement).
Je comprends complètement la cible très « self-hosted / facile par défaut » de Spip, aucun souci. Par contre,
je crois que LAMP touche sa limite en 2026 (Apache de façon évidente, MySQL qui perd de la traction face à PostgreSQL)
l’architecture de Spip fait que certaines extensions pour faire de la haute dispo nécessitent de l’override plutôt que de l’extension via plugin (nb : vu de mon LLM, je serais intéressé par une revue avec le point de vue d’un expert Spip)
J’ai l’impression que tu vois cela du point de vue de ton histoire personnelle et celle de SPIP, mais gérer un serveur « classique » est loin d’être aussi simple que tu ne le crois, même en simple hébergement, et il y a vraiment tout autant d’avantages à ces nouveaux choix d’architectures qui ne sont pas forcément toujours plus complexes (hormis le fait d’être potentiellement Gafam si tu passes par des solutions AWS ou Cloudflare également).
Par contre faire entrer SPIP dedans actuellement, je doute vraiment qu’il y rentre de son plein gré ! Je n’aurai même pas tenté d’essayer, mais des retours seront fort appréciables.
Merci de pousser cette expérience le plus loin possible.
Je vous adresse tous mes encouragements. Ceci devrait donner un peu de motivation aux (rares) dev qui tentent de moderniser la base de code et, qui sait, l’outillage de déploiement.
@marcimat Bé c’est un truisme de dire que je vois cela du point de vue de l’histoire de SPIP… évidemment puisque c’est de ça qu’on est en train de parler.
Et donc pas propre à mon histoire personnelle, mais à toutes celles et ceux qui ont eu à installer/utiliser SPIP depuis 20 ans. Pas forcément en pro (même si moi majoritairement mais pas que), pour une asso, pour une AMAP, que sais-je. Je suppute que le réseau Mutu n’aurait pas trop envie d’être hébergé chez AWS (et pourtant z’ont du trafic).
Il n’y a pas à gérer soi-même son serveur, les offres mutualisées (donc gérées globalement par d’autres, avec des coûts réduits puisque mutu) suffisent à l’immense majorité des petits/moyens sites.
Les infrastructures complexes peuvent bien sûr avoir un intérêt, c’est évident, mais il me semble dans des cas beaucoup plus rares, où les changements d’échelles sont attendus (contenus grossissant énormément, beaucoup d’inscription et de connexion et d’écriture en même temps, etc). D’où ma curiosité sincère des cas attendus où ça serait utile. Sinon pourquoi ?
Au delà de la scalabilité, une propriété intéressante est la haute disponibilité.
Il ne s’agit pas tant de rendre le truc « compatible AWS » que de pouvoir le déployer sur une archi classique « 2 (n) machines + load balancer + cache redis + S3 + CDN ».
Les offres mutualisées proposeront p’têt bientôt un mode « donne moi un helm chart »
Je viens mettre un peu mon grain de sel car le sujet m’intéresse également.
Dans le cadre de mes travaux récents autour de SPIP (notamment en environnement dockerisé avec des contraintes de CI/CD et d’observabilité), je me suis confronté à certaines des limites évoquées ici, en particulier sur la gestion des logs et, plus largement, sur la capacité à rendre une instance plus « stateless ».
Pour ce besoin, j’ai développé un plugin logs_stderr dont l’objectif est de rediriger les spip_log() vers la sortie d’erreur standard (stderr), plutôt que dans les fichiers du répertoire tmp/log/. Cela permet de s’intégrer plus proprement avec des environnements conteneurisés, où la collecte des logs est généralement centralisée (via Docker, Kubernetes, etc.). Ce n’est évidemment qu’une brique parmi d’autres, mais cela participe à rendre l’application plus compatible avec des architectures distribuées, en évitant une dépendance forte au système de fichiers local pour un aspect aussi central que les logs.
Plus globalement, je partage le constat fait plus haut : SPIP n’a pas été conçu à l’origine pour ce type d’architecture, mais certaines adaptations, souvent à la marge (logs, stockage, sessions…), permettent déjà d’aller assez loin sans remettre en cause le cœur. Dans une précédente mission, 10 ou 15 ans en arrière, j’ai un vague souvenir que nous avions du partager le répertoire tmp/sessions/ de SPIP pour du load balancing… et ne pas perdre la connexion lors du partage de charges.
En tout cas, je serais très intéressé par des retours d’expérience concrets sur des mises en place en scalabilité horizontale (même partielles), notamment sur :
Continuons la série des grains de sel, je vous en partage un de l’ouest
Voici ce qu’on arrive à faire chez Infini, hébergeur associatif brestois, chez qui je suis bénévole dans l’équipe tech.
Voir la présentation de notre infra pour le contexte Hébergement - Infini. On peut y lire qu’un site configuré pour tourner en PHP 8.4 est « posé » au minimum sur deux vms web afin d’assurer « le mode HA ».
Cache partagé, y compris i) sessions et ii) squelettes (Redis/Valkey?)
On branche le cache des SPIP sur notre cluster memcached avec le plugin memoization. Concernant les sessions, on configure PHP sur session_handler & save_path pour qu’elles soient sotckées dans le cluster memcached.
Stockage fichier externalisé
Tu penses à déporter uniquement le répertoire IMG, c’est bien ça ? Un montage réseau avec NFS ferait bien le job (même si PHP n’aime vraiment pas le NFS).
Gestion du cron par « génie » plutôt qu’externalisation sur un broker / système de queue tiers (RabbitMQ, SQS…)
Le cron de SPIP peut-être appelé depuis un cron system à l’aide de spip-cli, ça permet de ne pas être dépendant du déclenchement « classique » généré par les visites du site public.
Backup bdd via fichier local
Tu peux préciser le besoin ? Si l’objectif est de récupérer la base via un unique fichier, SQLITE répond au besoin, mais perso je ne recommande pas son usage, je préfère notre bon vieux cluster mariadb.
De mon côté, je me suis retrouvé plusieurs face au fait que les répertoires ne sont pas toujours bien gérés dans le code de base de SPIP. En particulier il y a trop d’adhérence entre le répertoire et la génération d’url.
J’ai déporté sur S3, et servi effectivement via un CDN.
Je vais utiliser ça. C’est même mieux si je peux désactiver le code qui gère le déclenchement classique (c’est autant de requêtes bdd en moins à chaque requête - @JamesRezo ça ne me choque pas que la gestion des tâches mobilise la BDD. Juste pas à chaque requête).
Je n’avais pas besoin. L’idée était plutôt pour de virer / masquer (et laisser ça côté infra).
Merci à tous pour vos réactions. Je suis preneur d’une séance de partage live où
je vous montre ce qui tourne / les adaptations faites
vous me dites
ce qui est crado d’un point de vue archi spip (et on identifie ensemble les évolutions du coeur de spip qui permettraient de faire moins crado)
ce que vous verriez bien atterrir dans un plugin (mon client veut bien que je partage)
Ouais, c’est l’une des grosses difficultés qu’on rencontre et qu’on aimerait bien pouvoir améliorer cela sur SPIP 5 (mais on n’est encore pas certains de pouvoir trouver une solution convenable — et il faut pouvoir y consacrer pas mal de temps) ! J’aime bien ton terme d’adhérence !
