Discussion :

[Lovegiver]

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.

[ddoumeche]

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.

[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

[ddoumeche]

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 :

[Lovegiver]

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 ?

[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.

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

[Lovegiver]

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.

[tchize_]

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.

[Lovegiver]

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 :

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.

[tchize_]

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.

[Lovegiver]

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 ?

[andry.aime]

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.