Hébergement de geOrchestra ?

[Fabien Allamanche]

Bonjour à tous,

Ce petit sujet car je me pose la question de l'hébergement de la solution geOrchestra au sein de vos structures ?

Le projet était en standby ces derniers temps à ViennAgglo, faute de temps. Je reprends les rennes du projet et celui-ci repart sur de bonnes bases avec geOrchestra 16.12.

Pour le moment, geOrchestra tourne en interne sur 2 serveurs : 

• le premier fait tourner 2 instances de Jetty :
• la première pour CAS et security-proxy,
• la seconde pour tout le reste excepté geoserver et geowebcache
• le deuxième fait tourner 1 instance de Jetty pour Geoserver et Geowebcache.

J'ai remarqué que Jetty est plus stable lors du déploiement des webapps surtout avec Geoserver.

La disponibilité du service est assez fluctuante en interne donc je me pose la question de l'hébergement à l'extérieur.

Je reviens donc à la question principale, comment hébergez-vous geOchestra et plus implicitement quelle architecture de geOrchestra utilisez-vous et comment vous la mettez en oeuvre : 

• En interne/externe ? 
• Si en externe, chez quel hébergeur et quelle type d'offre avez-vous choisie ?
• Plusieurs serveurs dédiés afin de répartir les charges des Tomcat/Jetty,
• Un serveur physique surpuissant avec plusieurs VMs accueillant les différentes instances de geOrchestra ?
• En Interne, combien de serveurs font tourner geOrchestra ?
• Quelle est votre architecture ?
• Combien vous coûte l'hébergement à l'extérieur par an ?
• Et toute autre information utile à laquelle je n'ai pas pensé :)

Merci pour vos retours

Fabien ALLAMANCHE

[François Van Der Biest]

Bonjour Fabien,

A Camptocamp, nous utilisons pour (presque) tous nos clients une architecture dans laquelle chaque module georchestra est dans un Jetty, lui même dans un conteneur Docker.

Les conteneurs tournent sur des machines du cloud OVH ou AWS, et sont gérés par l'orchestrateur de Rancher, qui en assure notamment un monitoring actif.

Pour des raisons de partage de données géo entre instances geoserver, nous devons héberger les multiples instances geoserver sur une unique machine, mais cela n'est pas contraignant pour les niveaux de charge que nous gérons à l'heure actuelle. Un hébergement classique pour une région est un serveur avec 60 Go de RAM et 8 ou 16 coeurs.

Les images docker que nous utilisons sont basées sur les mêmes que les images publiques, buildées sur des branches stables, avec certaines optimisations que nous appliquons en surcharge. Nous utilisons aussi d'autres images (ldproxy, pydio, monitoring, sftp, etc) qui viennent compléter l'offre.

En espérant avoir répondu à tes questions,

F.

--
--
Vous avez reçu ce message, car vous êtes abonné au groupe
Groupe "georchestra" georc...@googlegroups.com
voir http://groups.google.fr/group/georchestra
 
Site web : http://www.georchestra.org

---
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "georchestra".
Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse georchestra+unsubscribe@googlegroups.com.
Pour obtenir davantage d'options, consultez la page https://groups.google.com/d/optout.

[Landry Breuil]

On 04/19/17 10:36, Fabien Allamanche wrote:
> Bonjour à tous,
>
> Ce petit sujet car je me pose la question de l'hébergement de la
> solution geOrchestra au sein de vos structures ?
>
> Le projet était en standby ces derniers temps à ViennAgglo, faute de
> temps. Je reprends les rennes du projet et celui-ci repart sur de bonnes
> bases avec geOrchestra 16.12.
> Pour le moment, geOrchestra tourne en interne sur 2 serveurs :
>

> * le premier fait tourner 2 instances de Jetty :
> o la première pour CAS et security-proxy,
> o la seconde pour tout le reste excepté geoserver et geowebcache
> * le deuxième fait tourner 1 instance de Jetty pour Geoserver et

> Geowebcache.
>
> J'ai remarqué que Jetty est plus stable lors du déploiement des webapps
> surtout avec Geoserver.
> La disponibilité du service est assez fluctuante en interne donc je me
> pose la question de l'hébergement à l'extérieur.
>
> Je reviens donc à la question principale, comment hébergez-vous
> geOchestra et plus implicitement quelle architecture de geOrchestra
> utilisez-vous et comment vous la mettez en oeuvre :
>

> o En interne/externe ?
> + Si en externe, chez quel hébergeur et quelle type d'offre
> avez-vous choisie ?
> # Plusieurs serveurs dédiés afin de répartir les charges
> des Tomcat/Jetty,
> # Un serveur physique surpuissant avec plusieurs VMs

> accueillant les différentes instances de geOrchestra ?

> + En Interne, combien de serveurs font tourner geOrchestra ?
> # Quelle est votre architecture ?

Ici, l'archi c'est ca :

http://fichiers.craig.fr/presentations/landry/20160524_geocom/infra_distribuee/

sur 2 serveurs physiques 'clones', chaque instance de georchestra est
dans un conteneur LXC, et chaque conteneur fait tourner 3 tomcat. Les
serveurs ont plein d'autres conteneurs LXC (web, mapserver, db, ftp,
etc..) et ont chacun 64Go de RAM (mais je donne pas tout a ces gloutons
de tomcat).

Si je devais refaire/upgrader, je virerais probablement tomcat pour jetty.

> o Combien vous coûte l'hébergement à l'extérieur par an ?

Pas cher, mais c'est parce qu'on a un arrangement particulièrement
interessant avec le centre de ressources info de l'université..

Landry

[kial]

Bonjour Fabien, 

coté INRA nous conservons la maîtrise (autant qu'il est possible avec georchestra) de l'infrastructure avec 2 machines virtuelles (portail + geoserver) qui hébergent plusieurs instances tomcat répartis comme sur la copie graphique ci-après :

Les réponse de François et Landry m'interpellent sur l'usage de Jetty. Les documentations vont dans le sens d'une installation sur Tomcat et l'on découvre que finalement il y a pas mal de Jetty. Est-ce uniqueent lié à l'usage de conteneurs qui serait plus facile avec jetty que Tomcat ou bien y-a-t-il une véritable autre raison?

[Landry Breuil]

On 04/20/17 08:58, kial wrote:
> Bonjour Fabien,
> coté INRA nous conservons la maîtrise (autant qu'il est possible avec
> georchestra) de l'infrastructure avec 2 machines virtuelles (portail +
> geoserver) qui hébergent plusieurs instances tomcat répartis comme sur
> la copie graphique ci-après :
>

> <https://lh3.googleusercontent.com/-3c2qAnYhf0c/WPhbCA1OuaI/AAAAAAAAANg/cqrHAQ6XO_IzHgcTrqQfvNrBcxYpEECcQCLcB/s1600/Capture.JPG>

>
> Les réponse de François et Landry m'interpellent sur l'usage de Jetty.
> Les documentations vont dans le sens d'une installation sur Tomcat et
> l'on découvre que finalement il y a pas mal de Jetty. Est-ce uniqueent
> lié à l'usage de conteneurs qui serait plus facile avec jetty que Tomcat
> ou bien y-a-t-il une véritable autre raison?

Pas forcément (sachant que moi j'utilise des conteneurs *comme des VMs*,
pas a la mode du jour/docker) - certes, la doc explique tomcat, parce
qu'historiquement c'est l'architecture utilisée (c'est ce que j'ai en
prod). Cependant, rien n'empeche d'utiliser jetty a la place, car on
utilise très peu/voire aucune des fonctionalités specifiques de tomcat,
qui est relativement complexe a mettre en place et gourmand, alors que
jetty est/serait plus simple/leger (pour du java hein, toutes
proportions gardées...) - Bref, c'est comme apache vs nginx.

On a commencé avec pierre a monter une instance de test (sur des
conteneurs lxc) avec un jetty par webapp, et c'est plus souple/simple a
priori. Reste a y finir, et a y documenter si on décide de conseiller
jetty en lieu et place de docker. Mais comme tout projet libre, la doc
peut lagguer...

Landry

[kial]

Ok toutefois je suis obligé de réagir à la phrase "comme tout projet libre , la doc 
peut lagguer... ". Il y a des projets libres où la documentation fait partie du cycle de développement, y compris sa maintenance et mise à jour.  Je préfère la phrase : dans notre contexte la doc est larguée ;)

Je suis personnellement plutôt favorable à suivre les préconisations ou doc plutôt que de tester d'autres solutions : c'est déjà suffisamment instable comme ça.

Bonne journée.

[Fabien Allamanche]

Merci pour vos retours !

J'y vois déjà un peu plus clair.

Je n'ai pas encore tester Docker, il va falloir que je m'y mette :)

[François Van Der Biest]

Bonsoir Alain,

En toute amitié, je me permets de réagir à ton message ci-dessous.

La documentation d'installation geOrchestra a été réalisée par des bénévoles sur leur temps libre. 

La documentation administrateur n'existe pas encore. La communauté a décidé d'y consacrer une pleine journée de travail après le geocom. Toute les bonnes volontés pour y contribuer seront les bienvenues.

Par ailleurs, il existe des documentations "utilisateur", disséminées sur chacune des plateformes. Un effort de synthèse est en cours, avec notamment le CRAIG, qui commence à travailler avec gitbook.

La doc n'est pas larguée, comme tu dis. Elle a sans aucun doute des points de faiblesse, auquel il s'agit de remédier, en contribuant. Pour celà, l'oeil d'un nouveau contributeur est idéal, car lui seul est à même de repérer ces zones de faiblesse. Regarde par exemple ce qui s'est passé très récemment avec le rapport de bug https://github.com/georchestra/georchestra/issues/1710 : le problème a été exposé par l'utilisateur, nous l'avons précisé, trouvé un workaround, puis mis à jour la documentation de suite.

 

Tu sous-entends que la plateforme est instable. Nous sommes pourtant plusieurs ici à exploiter des plateformes d'ampleur importante, sans constater les instabilités que tu rapportes. Les propos négatifs à l'encontre du projet ne sont utiles que s'ils sont constructifs.

Considérant l'énergie que nous consacrons à ce projet, je me permets donc de te demander de modérer tes propos.

Merci,

François

--

--
Vous avez reçu ce message, car vous êtes abonné au groupe
Groupe "georchestra" georc...@googlegroups.com
voir http://groups.google.fr/group/georchestra
 
Site web : http://www.georchestra.org

---
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "georchestra".
Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse georchestra+unsubscribe@googlegroups.com.

[Chiarello Ernest]

Le 21/04/2017 à 10:33, Fabien Allamanche a écrit :

Merci pour vos retours !

J'y vois déjà un peu plus clair.

Je n'ai pas encore tester Docker, il va falloir que je m'y mette :)

le concept Docker est intéressant. pour le GeoCom, je propose de faire un retour d'expérience sur la personnalisation de conteneurs Docker, pour les adapter à des besoins spécifiques.
ce qu'on peut dire, dans un premier temps, c'est qu'un déploiement de geOrchestra par Docker fonctionne du premier coup. ça, c'est une bonne nouvelle ! 8-)
en revanche, personnaliser les conteneurs nécessite de maîtriser la gestion des conteneurs, et la courbe d'apprentissage est assez longue.


Ernest.

--

--
Vous avez reçu ce message, car vous êtes abonné au groupe
Groupe "georchestra" georc...@googlegroups.com
voir http://groups.google.fr/group/georchestra
 
Site web : http://www.georchestra.org

---
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "georchestra".

Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse georchestra...@googlegroups.com.

Pour obtenir davantage d'options, consultez la page https://groups.google.com/d/optout.

-- 
Ernest CHIARELLO  -  Ernest.C...@univ-fcomte.fr
UMR6049 ThéMA - Théoriser et Modéliser pour Aménager
CNRS / université de Bourgogne Franche-Comté
32 rue Mégevand 25030 BESANÇON Cedex

Tel : 03 81 66 53 66           Mob : 07 82 99 11 08

[kial]

Bonjour François,

En toute amitié je réponds à ton message. En premier lieu je tiens à préciser qu’il n’y a aucune attaque personnelle et que je me sens libre de donner mon opinion, basée sur notre expérience, et ce même si elle ne va pas dans le sens de la communication générale qui à mon goût est un peu trop idyllique. Il faut parfois qu’il y ai des individus qui secouent un peu le cocotier et je n’accepte ce rôle qu’à mon grand regret ; tu te doutes bien que je préfèrerai indiquer que tous nos problèmes sont résolus dans des délais ultra-courts, que toutes les compilations marchent du premier coup, que le support technique est d’une réactivité impressionnante, que les migrations se font de manière transparentes, que la documentation comporte les informations qui nous manquent … Malheureusement nous sommes loin de cette situation, probablement pas les seuls, et je veux quand même rappeler que nous essayons de migrer, sous le contrôle du support technique, depuis fin novembre et que chaque petit obstacle levé en fait apparaître un nouveau avec des choses abérrantes comme un geoserver compilé sans le bandeau georchestra et que personne n’a vu ?? Je veux bien reconnaître être exténué par cette situation et probablement enclin à des commentaires négatifs mais je reste sincère et lorsqu’on compile geoserver / geofence sous couvert du support, qu’on mets en place un dossier de données vierge récupéré sur github et que cette situation élémentaire ne fonctionne pas correctement on peut exprimer du négatif sur la documentation, à minima.

Pour ce qui est de la constructivité j’ai fait une proposition de discussion au Geocom (nous verrons bien la suite donnée) et j’indique dans le post incriminé une piste en précisant que la documentation doit faire partie du cycle de développement – je cite souvent Postgresql ou aucun Commit n’est réalisé avant que la documentation concernée ne soit mise à jour…

Nous sommes dans une démarche ‘Maquettage / test / production’ et chaque changement de version est un cauchemar, à tel point que lorsque ça fonctionne on ne touche plus à rien ; voilà pourquoi je me permets de parler d’instabilité, constatant malheureusement que ce qui marchait hier ne fonctionne plus aujourd’hui ; suis-je vraiment le seul à faire ce constat ?

Je ne m’exprimerai plus sur ce fil de discussion.

Alain.

Bonsoir Alain,

Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse georchestra...@googlegroups.com.