Déploiement d'une même application plusieurs fois sur le même serveur d'application

Bonjour,

je cherche des conseils concernant le déploiement puis l'usage en mode SaaS d'une application auparavant déployée en standalone.

L'entreprise qui m'emploie déployait jusqu'à présent une solution basée sur des outils spécifiques (notamment 4D, InDesign, etc.). Chaque client disposait des infras nécessaires pour faire tourner sa propre copie de l'application dans ses locaux.

Je travaille quant à moi sur la prochaine version de l'application. Je dois porter celle-ci en Java et rendre celle-ci accessible en mode SaaS.

Plusieurs serveurs seront déployés chez nous, chacun hébergeant une partie du service global : un serveur d'application, un serveur de BDD, un autre pour le traitement d'images.

La question que je me pose est celle de savoir comment déployer mon appli Java plusieurs fois sur le même serveur, sachant que chaque client aura sa propre application accessible depuis une URL spécifique du genre : client1-application.com, client2-application.com, etc.
Chaque instance de l'application accèdera à ses données hébergées sur un serveur de BDD où chaque client disposera de sa propre BDD (PostgreSQL).

J'ai du mal à conceptualiser la façon dont je dois architecturer mon appli et notamment la partie réseau :

L'URL accessible par les clients (donc port 80) devra arriver jusqu'à mon routeur où, selon le client, cette URL fera l'objet d'une redirection vers mon serveur d'application.
Le client 1 accèdera à l'instance de l'appli mappée sur le port 8081
Le client 2 accèdera à l'instance de l'appli mappée sur le port 8082
etc.

D'autre part, certaines fonctionnalités seront accessible via des web services.

Je suis preneur de toute bonne idée, tout retour d'expérience, car c'est la première fois que j'ai à gérer ce type de problématique.

Merci d'avance pour vos éclaircissements.

Les divergences applicatives sont t'elles tellement significatives qu'il faille N versions de l'application ?

Pour moi, ce genre de chose se gèrent avec du paramétrage au niveau du compte utilisateur, voir dans le pire des cas la coexistence de deux ou trois versions de l'application et un reroutage vers la bonne version au moment du login.

Bonjour @ddoumeche et merci pour ta réponse

Tous les clients n'utilisent pas nécessairement les mêmes services mais tu as raison : l'application reste la même.

Je pensais que le fait d'instancier autant de fois l'appli qu'il y a de clients garantirait une bonne étanchéité et un bon cloisonnement du point de vue de la confidentialité et de la sécurité des données.
En effet, chaque client disposera de sa propre DB et il semblait approprié (mais je me trompe sans doute) que chaque DB soit accédée par une appli distincte.

Concernant ta suggestion, cela impliquerait de "sortir" les User de chaque DB client afin de constituer une base dédiée à l'authentification. A l'issue de cette authentification le User serait dirigé vers le contexte adapté, donc une instance spécifique de l'appli.
Comment fais-tu pour exécuter un contexte plutôt qu'un autre après authentification ?

++ et bon week end

Citation:

---

Envoyé par Lovegiver

Bonjour @ddoumeche et merci pour ta réponse

Tous les clients n'utilisent pas nécessairement les mêmes services mais tu as raison : l'application reste la même.

Je pensais que le fait d'instancier autant de fois l'appli qu'il y a de clients garantirait une bonne étanchéité et un bon cloisonnement du point de vue de la confidentialité et de la sécurité des données.
En effet, chaque client disposera de sa propre DB et il semblait approprié (mais je me trompe sans doute) que chaque DB soit accédée par une appli distincte.

Concernant ta suggestion, cela impliquerait de "sortir" les User de chaque DB client afin de constituer une base dédiée à l'authentification. A l'issue de cette authentification le User serait dirigé vers le contexte adapté, donc une instance spécifique de l'appli.
Comment fais-tu pour exécuter un contexte plutôt qu'un autre après authentification ?

++ et bon week end

---

Si tu veux un cloisonnement réellement total, tu peux faire une BDD par client, ce qui s'appelle du sharding et a l'avantage de pouvoir monter en charge en multipliant le nombre de serveurs de BDD, et de pouvoir maintenir N versions de ton/tes applications ... mais attention c'est complexe à gérer.

Si tu instancies autant d'applications que de clients, ta consommation mémoire serveur va exploser, sachant qu'aujourd'hui la moindre petite appli fait 500 Mo. Et je ne parle pas des patchs sur le code source, quand tu vas devoir appliquer 20 lignes de correctifs à 500 clients, donc à 500 codes sources.

Tu dois effectivement extraire les noms des utilisateurs, en utilisant par exemple leurs emails comme login (ce qui te garantit l'unicité), ce qui n'est pas choquant pour du Saas. Une fois authentifié, mets leur un cookie magique indiquant la version favorite, et renvoie-les à la bonne page (client-application.com/dashboard), le cookie étant utilisé par le redirecteur pour déterminer la bonne version.
Par expérience, je te conseille aussi de stocker les préférences dans la même base physique que les logins.

Vu qu'une url, c'est un contexte, c'est la redirection qui choisit le bon contexte. Tu peux utiliser mod-proxy pour cela, qui est plus souple que mod-jk, ou carrément écrire ton propre rerouteur.
C'est une architecture de base qui ne prend pas en compte les questions de haute-disponibilité bien, mais cela ne gène en rien.

une image vaut 10³ mots :
Pièce jointe 234798

Ton approche est très intéressante et je souhaite te remercier pour le temps que tu m'as consacré.
Je commence à regarder mod_proxy pour voir comment exploiter au mieux cet outil.

Dans l'hypothèse où tous mes clients utiliseraient la même application (versus une instance par client), comment gérer les lectures/écritures dans la DB ?

Je vais préciser ma question afin d'être plus clair :

Sans faire de sharding je vais faire en sorte que chaque client ait sa propre DB. Pour cela je vais m'appuyer sur PgSQL qui permet de multiplier les serveurs de DB.

Comme je compte utiliser Spring, j'ai vu qu'il était possible de travailler avec plusieurs DataSources, ce qui est plutôt positif dans mon cas.

Maintenant que j'ai 1 appli pointant vers N bases de données (1 par client), comment indiquer à Spring qu'un INSERT dans la DB doit être réalisé dans la DB du client1 plutôt que dans celle du client2 ?

D'autre part, dans l'hypothèse où je rajoute un nouveau client, je vais créer une nouvelle DB dans PgSQL, mais comment déclarer cette nouvelle DB à l'application ?
Est-ce qu'un fichier de paramètre peut suffire, fichier que l'on pourrait enrichir sans avoir à rebooter l'application ?

Si tu utilise spring, et que tu n'a pas de singletons (sesion ou request bean seulement), alors, lors de l'instanciation des DAO, tu va leur filer normalement un datasource à utiliser. Il suffit que le datasource choisi soit le résultat d'un appel de méthode dépendant de l'utilisateur. Ainsi le DAO pointe sur la DB de l'utilisateur en cours de traitement. L'inconvénient du coup, c'est que c'est au revoir les DAO en singleton, ceux là sont configurés une seule fois.

Personellement, sur les applis multi-client que j'ai géré par le passé, on gérait plus ça au niveau logique. Les données propres à un client possédant une colonne clientId, et les requêtes incluant systématiquement le clientId. Ca permet accessoirement aussi de gérer plus facilement les client qui fusionnent suite à une acquisition :)

Merci @tchize_

Je viens d'avoir une discussion avec mon resp. technique qui me fait savoir qu'il souhaite que chaque client dispose de sa propre instance de l'application.

En gros, sur mon infra physique je vais déployer un serveur d'appli Tomcat ou jBoss et, dans ce serveur d'appli, plusieurs fois la même appli.
Chaque instance sera mappée sur un port distinct (8081,8082, etc.), chaque port correspondant à un nom de domaine spécifique propre à chaque client.

Actuellement, je ne vois pas d'arguments techniques à opposer à un tel choix. Par exemple je ne sais pas dire si 250 users connectés sur une même application consomment moins de ressources physiques que 50 clients connectés sur mon instance applicative 1 + 50 clients connectés sur mon instance applicative 2, etc.
-> au "détail" près du poids de l'appli comme le signalait très justement @ddoumeche, cela va sans dire

Le choix qui semble avoir été fait par mon resp. est celui de la scalabilité simplifiée. Si l'infra physique est saturée, il sera plus simple selon lui de rajouter un serveur physique sur lequel il sera possible d'ajouter simplement de nouvelles instances au fur et à mesure des besoins.

Ce qui est sur, c'est que N instances consommeront N * la mémoire d'un seul serveur. Ca peux se faire, mais en calculant rapidement à 500M l'instance à minima, tu te retrouve avec 5G pour 10 clients, 10G pour 20, etc. Et là c'est la consommation statique, le serveur n'a pas encore commencé à servir.

Tu dois bien te dire qu'une application J2EE c'est plus que les données qu'elle traite, c'est tout le code du serveur, le code de l'application, tout ce qui supporte les servlets et le J2EE, etc.

Bref, je te conseille de commencer par des prototypes pour faire tes calculs.

Au passage, tu n'a pas besoin de ports séparés, ca t'évitera déjà les N serveur. Tu peux juste faire N déploiements dans le même serveur jboss / tomcat.

Hello @tchize_

oui il va falloir prototyper afin d'avoir de vrais chiffres sous les yeux. Je vais faire qqch de minimaliste afin de voir déjà comment tout ça cohabite et se comporte mais il me manque encore des clés.

Je suis surpris par ce que tu disais à la fin de ton message :

Citation:

---

tu n'a pas besoin de ports séparés, ca t'évitera déjà les N serveur. Tu peux juste faire N déploiements dans le même serveur jboss / tomcat

---

-> je comprends que le 'port' renvoie à un serveur d'application (jBoss / Tomcat) pas à une appli spécifique déployée sur le serveur
-> comment je fais, en partant du même EAR / WAR pour installer plusieurs fois celui-ci sans avoir besoin de ports spécifiques ?

Je connais peu jBoss. Quand on est dans l'interface de Tomcat, on peut déployer son archive et celle-ci est ensuite accessible via son url. Veux-tu dire qu'il suffit que mes archives portent un nom différent (donc une URL différente) pour qu'il n'y ait pas besoin de mapper plusieurs ports ?
Je suis franchement dans l'inconnu, je n'ai jamais eu à faire ce genre de manip ni de projet.

Je me permets de te poser une question supplémentaire car, sur ce point, je n'ai pas compris la réponse précédente de @ddoumeche :

si, pour mes clients, l'application est accessible au travers d'un nom de domaine du type "nom_application.nom_client.com", comment dois-je faire concrètement pour "mapper" un nom de domaine à l'une des applications déployées sur le serveur d'application ?
Je ne sais même pas où ce genre de paramétrage doit être fait ! Dans les fichiers de config de Tomcat ?

Merci pour tout.

Bien à toi et bon début de journée.

Tu l'installe sous des noms différents. Si on prends l'exemple d'un war, ton application.war, tu déploie sur le serveur:

tonapplication-clientW.war
tonapplication-clientX.war
tonapplication-clientY.war
tonapplication-clientZ.war

qui seront accessible respectivement sur les urls

http://tonServeurjboss:8080/tonapplication-clientW/
http://tonServeurjboss:8080/tonapplication-clientX/
http://tonServeurjboss:8080/tonapplication-clientY/
http://tonServeurjboss:8080/tonapplication-clientZ/


Ensuite sur ton apache en frontend t'as jsute à faire le mapping en fonction du serveur virtuel.

http://clientW.tonServeurPublic/ => http://tonServeurjboss:8080/tonapplication-clientW/
http://clientX.tonServeurPublic/ => http://tonServeurjboss:8080/tonapplication-clientX/
http://clientY.tonServeurPublic/ => http://tonServeurjboss:8080/tonapplication-clientY/
http://clientZ.tonServeurPublic/ => http://tonServeurjboss:8080/tonapplication-clientZ/


Tu peux aussi avoir ton jboss qui écoute sur des noms différents mais associer un déploiement à un nom dns, c'est un peu plus chaud.

Génial !
Merci @tchize_ t'es vraiment sympa

Le front end, c'est une bonne idée parce que ça évite d'exposer le serveur d'appli en direct.
Cette redirection, depuis le front vers le back, c'est à faire dans les fichiers de conf du Apache ?

Citation:

---

Envoyé par tchize_

Si tu utilise spring, et que tu n'a pas de singletons (sesion ou request bean seulement), alors, lors de l'instanciation des DAO, tu va leur filer normalement un datasource à utiliser. Il suffit que le datasource choisi soit le résultat d'un appel de méthode dépendant de l'utilisateur. Ainsi le DAO pointe sur la DB de l'utilisateur en cours de traitement. L'inconvénient du coup, c'est que c'est au revoir les DAO en singleton, ceux là sont configurés une seule fois.

---

Il peut utiliser des singletons en créant une classe qui hérite AbstractRoutingDataSource avec un intercepteur qui va gérer la clé pour chaque DataSource à utiliser.