Introduction
Le CMS Ametys se compose de 3 applications :
- Back-Office (cms)
- Front-Office (site)
- Indexation et recherche (solr)
Les 3 applications peuvent cohabiter sur un même serveur, chacune de ces applications peut également être installée sur une plateforme matérielle différente.
L'application back-office est accédée par les contributeurs pour les modifications des différents contenus gérés par Ametys. Elle prend la formation d'une application web déployée dans un serveur d'application Apache Tomcat.
L'application front-office est accédée par les visiteurs pour la consultation des sites web. Elle se présente comme une application web déployée dans un serveur d'application Apache Tomcat. Sa fonction principale est de gérer un cache de l'ensemble des ressources demandées par les utilisateurs. Les ressources non présentes dans le cache sont demandées à l'application back-office.
L'application d'indexation et de recherche, basée sur l'outil Apache Solr, est démarrée indépendamment des autres applications. Elle n'est pas accédée directement par les utilisateurs d'Ametys, mais en arrière-plan par l'application back-office.
Les serveurs Tomcat sont généralement accessibles au travers d'un reverse proxy, souvent mis en place avec le serveur Apache HTTPD.
Flux de données
Les demandes de page des utilisateurs sont reçues par Apache. Apache sert les fichiers statiques tels que les CSS, images, pages non dynamiques... et redirige les autres requêtes vers Tomcat.
La communication entre le back-office et le front-office s'effectue dans les deux sens par le biais de web-services :
- Le back-office doit pouvoir annuler le cache du front-office
- Le front-office doit pouvoir demander la production d'une ressource pour la mettre en cache et la servir à l'utilisateur final
Si le back-office et le front-office sont installés sur le même serveur, il est possible de les faire tourner au choix sur un seul serveur Tomcat ou sur deux Tomcat séparés.
Sources de données
Le CMS Ametys gère plusieurs "sources de données". Une installation standard suit l’architecture suivante :
Les bases de données ne sont pas nécessairement sur le même serveur que les applications. Cependant, pour des raisons de performances, il peut être conseillé d'avoir au moins le repository JCR placé sur la même machine que le CMS.
Back-Office
L'application CMS référence au moins deux sources de données :
- JCR : Il contient les données principales, c'est à dire, la structure des sites, les pages, les contenus, les ressources, etc.
- SQL : Cette base contient les données secondaires comme la définition des populations, groupes et utilisateurs, les profils, une partie des droits, etc. Il peut y avoir plusieurs bases SQL notamment pour séparer certaines données, et plusieurs types de base de données sont supportés comme MySQL, Oracle, etc.
Front-Office
Le front-office peut utiliser une ou deux bases de données SQL :
- L'une permettant de sotcker les informations des utilisateurs du front-office le cas échant (utilisateurs, groupes, préférences, etc.)
- L'autre (optionnelle) permet de stocker des informations utiles à l'analyseur de cache
Utilisateurs et groupes
Que ce soit dans le front-office ou le back-office, l'emplacement des utilisateurs et des groupes dépend des implémentations choisies.
Le CMS Ametys permet de choisir d'autres implémentations, par exemple LDAP.
Solr
En arrière-plan, on retrouve l'application Solr dans laquelle l'ensemble des données sont indexées. Cette application permet de faire des recherches efficaces avec de multiples critères et de gérer les facettes.
Seul le back-office fait appel à cette application.
Gestion du cache
Une requête (demande de page ou recherche) lancée sur le front-office (site) suit le flux suivant :
Lorsque des modifications effectuées côté back-office (CMS) impactent des pages du site, celui-ci envoie une requête au front-office afin d'invalider partiellement ou entièrement le cache.
Compléments d'informations
Le back-office utilise les schéma d'URL suivants pour parler au front-office :
-
_invalidate-site/*
- _invalidate-skin/*
-
_invalidate-page/*/**
-
_invalidate-images/**
où * = n'importe quel caractère sauf '/' et ** = n'importe quel caractère y compris '/'
Ainsi si on souhaite empêcher un composant extérieur à l'application d'effacer le cache, il y a deux solutions :
- Faire en sorte d'interdire ces URLs par Apache et faire en sorte que le CMS parle au Tomcat du front-office directement.
- Protéger ces URLs pour qu'elles ne soient accessibles que par l' IP de l'application du back-office.
Notes et Recommandations
- Le serveur HTTP recommandé est Apache HTTPD.
- Le moteur de servlet J2EE recommandé est Apache Tomcat.
- L’implémentation JCR utilisée en interne est Apache JackRabbit.
- La base de données SQL recommandée est MySQL. Cependant, Oracle et Derby sont aussi supportés (PostgreSQL est supporté de manière incomplète pour le moment).
Retour en haut