Discussion :

[PoichOU]

Bonjour à tous,

Je m'intéresse de près à l'intégration continue depuis quelques mois et je souhaite créer une "plate-forme" pour faire l'IC de tous mes projets (c'est des projets Java). Jusque là je montais un environnement spécifique pour chaque projets mais maintenant je voudrais centraliser et industrialiser un peu tout ça .

J'ai installé sur un serveur debian :

• Apache
• Mysql
• Php
• Java
• Maven
• Tomcat

Puis j'ai "déployé" dessus (enfin je suis entrain) :

• SVN
• USVN
• Hudson
• Sonar
• Artifactory

Voici les questions que je me pose :
- J'ai lu un peu partout qu'il était "mieux" de lancer hudson, sonar et artifactory dans un serveur tomcat (ou autre) plutôt qu’en standalone. Mais au niveau perf' ça m'inquiète un peu, n'est-ce pas trop gourmands pour un Tomcat ?
- Je souhaite collaborer avec d’autres personnes sur certains projets. Comment je peux gérer des projets multiples sur les différentes applications et surtout comment gérer les habilitations des utilisateurs ?
- Est-ce que quelqu'un a déjà crée un tel environnement ou quelque chose de similaire ?

Merci d’avance pour vos retours
PoichOU

[romaintaz]

Bonjour,

Je m'occupe de l'intégration continue dans mon service. Je ne suis toutefois pas en charge des machines, je suis plus axé sur la gestion des services Jenkins / Sonar.

J'ai lu un peu partout qu'il était "mieux" de lancer hudson, sonar et artifactory dans un serveur tomcat (ou autre) plutôt qu’en standalone. Mais au niveau perf' ça m'inquiète un peu, n'est-ce pas trop gourmands pour un Tomcat ?

Ca va dépendre de ta machine en réalité, mais également de tes besoins. Si tu as un petit projet, ça ne devrait pas être un gros problème, mais si tu dois gérer beaucoup de projets en même temps, avec beaucoup d'activité dessus, ça risque d'être moins facile.

Hudson en lui-même n'est pas très gourmand. Toutefois, son rôle principal étant d'exécuter des builds de projets, si tu as beaucoup de projets et beaucoup d'activité, alors cela risque de ralentir les performances de ta machine.
En général, on va considérer que le nombre de CPU de ton serveur = le nombre de jobs en parallèle réalisables par Jenkins / Hudson. Donc si tu as un dual-core, tu pourras exécuter 2 builds en parallèle. Sauf que dans ce cas là, il faudra se dire que c'est Jenkins qui va manger beaucoup de ressources de ta machine, phagocytant ainsi les autres services (Sonar, SVN, Artifactory).
Mais après, rien ne t'oblige à demander à Jenkins de vérifier SVN toutes les 5 minutes, tu peux espacer cet intervalle à 1/2 heure par exemple, réduisant la consommation du serveur.
Aussi, il faut profiter des moments calmes pour exécuter les builds gourmands. Ainsi, on lancera plutôt les analyses Sonar par Jenkins toutes les nuits, libérant ainsi les ressources pour la journée.

Concernant Sonar, il me semble qu'il faut lui attribuer en général 512Mo de mémoire.

Pour la gestion SVN, je ne saurais pas dire, mais je doute que ce soit très gourmand, mais attention quand même : Jenkins va aller interroger très souvent SVN, donc il faudra sans doute surveiller les statistiques pour voir si tout se passe bien.

Quant à Artifactory, je dirais pareil que SVN : ce n'est pas très gourmand mais il peut y avoir pas mal d'accès en lecture / écriture sur le disque, donc là aussi ce n'est pas négligeable.

Pour en revenir à ta question : je ne pense pas que ce soit un problème de faire tourner tout cela sur un Tomcat. Ca doit pouvoir tenir la charge. De toutes façons, lancer tous les services séparément ou dans un seul Tomcat ça revient un peu au même, tu auras besoin de ressources pour tout faire tourner. L'avantage de les séparer, c'est que si tu as Sonar qui tombe, alors Jenkins continuera à tourner. Alors que si ton Tomcat tombe, tous tes services s'arrêtent.

Bon pour résumer : je ne pense pas que ce soit là le problème. Ton principal problème est de t'assurer que ta machine a les reins suffisament solides pour tenir la charge. Et de toutes façons, rien ne t'empêche de changer ton fusil d'épaule si jamais tu as des problèmes de performances sur tes services. Hudson peut très bien être externalisé à Tomcat sans souci, vu que les données de configuration sont placées ailleurs sur le disque. Un simple arrêt et nettoyage de Tomcat, puis installation d'un service Hudson dédié suffira !

Bref, lance toi et monitore les performances de ton serveur !

- Je souhaite collaborer avec d’autres personnes sur certains projets. Comment je peux gérer des projets multiples sur les différentes applications et surtout comment gérer les habilitations des utilisateurs ?

Peux-tu être plus précis ? Tu t'interroges par rapport à SVN ? Sonar ? Hudson ?

- Est-ce que quelqu'un a déjà crée un tel environnement ou quelque chose de similaire ?

Pas vraiment. Comme dit au début de mon message, moi je me charge juste de l'installation et administration de Jenkins et Sonar / MySQL. Le reste (SVN, Nexus, etc.) ne sont de toutes façons pas sur la même machine, et je ne m'en occupe pas. Et en plus c'est sur des VM Windows

Voilà, j'espère t'avoir donné quelques billes, mais n'hésite pas à approfondir tes questions.

[PoichOU]

Aaaah une réponse de l'incontournable Romain.

Je m'occupe de l'intégration continue dans mon service. Je ne suis toutefois pas en charge des machines, je suis plus axé sur la gestion des services Jenkins / Sonar.

C'est un peu le rôle que je suis entrain de prendre, mais il faut aussi que je m'occupe d'installer la plate-forme.

Ca va dépendre de ta machine en réalité, mais également de tes besoins. Si tu as un petit projet, ça ne devrait pas être un gros problème, mais si tu dois gérer beaucoup de projets en même temps, avec beaucoup d'activité dessus, ça risque d'être moins facile.

L'idée est de créer une plateforme d'IC accessible à tous les projets (potentiellement 20-30 projets).

Hudson en lui-même n'est pas très gourmand. Toutefois, son rôle principal étant d'exécuter des builds de projets, si tu as beaucoup de projets et beaucoup d'activité, alors cela risque de ralentir les performances de ta machine.
En général, on va considérer que le nombre de CPU de ton serveur = le nombre de jobs en parallèle réalisables par Jenkins / Hudson. Donc si tu as un dual-core, tu pourras exécuter 2 builds en parallèle. Sauf que dans ce cas là, il faudra se dire que c'est Jenkins qui va manger beaucoup de ressources de ta machine, phagocytant ainsi les autres services (Sonar, SVN, Artifactory).
Mais après, rien ne t'oblige à demander à Jenkins de vérifier SVN toutes les 5 minutes, tu peux espacer cet intervalle à 1/2 heure par exemple, réduisant la consommation du serveur.
Aussi, il faut profiter des moments calmes pour exécuter les builds gourmands. Ainsi, on lancera plutôt les analyses Sonar par Jenkins toutes les nuits, libérant ainsi les ressources pour la journée.

Concernant Sonar, il me semble qu'il faut lui attribuer en général 512Mo de mémoire.

Pour la gestion SVN, je ne saurais pas dire, mais je doute que ce soit très gourmand, mais attention quand même : Jenkins va aller interroger très souvent SVN, donc il faudra sans doute surveiller les statistiques pour voir si tout se passe bien.

Quant à Artifactory, je dirais pareil que SVN : ce n'est pas très gourmand mais il peut y avoir pas mal d'accès en lecture / écriture sur le disque, donc là aussi ce n'est pas négligeable.

Pour en revenir à ta question : je ne pense pas que ce soit un problème de faire tourner tout cela sur un Tomcat. Ca doit pouvoir tenir la charge. De toutes façons, lancer tous les services séparément ou dans un seul Tomcat ça revient un peu au même, tu auras besoin de ressources pour tout faire tourner. L'avantage de les séparer, c'est que si tu as Sonar qui tombe, alors Jenkins continuera à tourner. Alors que si ton Tomcat tombe, tous tes services s'arrêtent.

Merci pour les conseils. Après réflexion la plate-forme aura 2 serveurs :

1. SVN + Artifactory : le besoin est surtout d'avoir un accès disque performant
2. Hudson + Sonar : le besoin est d'avoir une "machine de guerre" avec le + de RAM et de CPU possible

Bref, lance toi et monitore les performances de ton serveur !

Oui c'est un peu l'idée, je vais commencer à y mettre mes projets perso (y en a 4), puis je filerai des accès à d'autres personnes au compte goutte tout en surveillant un peu les perfs.

Je souhaite collaborer avec d’autres personnes sur certains projets. Comment je peux gérer des projets multiples sur les différentes applications et surtout comment gérer les habilitations des utilisateurs ?

Peux-tu être plus précis ? Tu t'interroges par rapport à SVN ? Sonar ? Hudson ?

Je m’interroge sur tous les sujets

• SVN : c'est ok j'ai trouvé (je passe par USVN)
• Artifactory : c'est ok il gère ça nativement plutôt bien
• Sonar : je mets en stand by pour le moment j'y reviendrai plus tard.
• Hudson : c'est pour le moment mon plus gros soucis. Je m'explique:
  • côté sécurité : c'est bon, j'ai configuré Hudson avec une "Stratégie d'autorisation matricielle basée sur les projets" et une authentification LDAP. Du coup chaque job peut avoir ses accès propres (la personne qui crée le job doit définir correctement les droits sur son job).
  • côté infra : j'ai besoin de faire 2 choses:
    1. fixer des quotas de stockage par projet (ex: projetA a le droit à 2Go d'espace disque)
    2. faire des sauvegardes par projets (cad sauvergader tous les jobs pour le projetA)
    
    C'est là que je galère car tous les jobs sont stockés dans le $hudson_home/jobs. Et comme chaque projet a plusieurs jobs (j'ai en monyenne 6 jobs par projet), je ne sais pas comment "rattacher" les jobs à un projet.

Pas vraiment. Comme dit au début de mon message, moi je me charge juste de l'installation et administration de Jenkins et Sonar / MySQL. Le reste (SVN, Nexus, etc.) ne sont de toutes façons pas sur la même machine, et je ne m'en occupe pas. Et en plus c'est sur des VM Windows

Windows ou Linux je ne pense pas que ça change beaucoup de chose. Par contre la personne qui s'occupe de l'infra connait un peu les outils, non ?

Voilà, j'espère t'avoir donné quelques billes, mais n'hésite pas à approfondir tes questions.

Oui oui merci de ta réponse détaillée (comme toujours), c'est toujours un plaisir d'échanger avec toi !

PoichOU

[romaintaz]

Aaaah une réponse de l'incontournable Romain.

Mais bien sûr que si, je suis contournable. Je ne suis pas si gros que ça !

L'idée est de créer une plateforme d'IC accessible à tous les projets (potentiellement 20-30 projets).


Merci pour les conseils. Après réflexion la plate-forme aura 2 serveurs :

1. SVN + Artifactory : le besoin est surtout d'avoir un accès disque performant
2. Hudson + Sonar : le besoin est d'avoir une "machine de guerre" avec le + de RAM et de CPU possible

Effectivement, ce sera sans doute mieux comme ça. Mais encore une fois, attention à la charge CPU / mémoire lors des builds Jenkins, surtout s'il y a 20 / 30 projets (faut-il encore qu'ils soient tous en activité en même temps).
Mais il ne faut pas oublier un point important : on peut améliorer la rapidité des builds de différentes façons. D'un point de vue configuration, par ex. en cochant la case "Build > Maven > Advanced > Incremental builds" (Maven 2.1+) qui permet de ne recompiler que le nécessaire. D'un point de vue projet aussi, en améliorant les tests unitaires pour qu'ils se lancent vite, etc.

Je m’interroge sur tous les sujets

• SVN : c'est ok j'ai trouvé (je passe par USVN)
• Artifactory : c'est ok il gère ça nativement plutôt bien
• Sonar : je mets en stand by pour le moment j'y reviendrai plus tard.
• Hudson : c'est pour le moment mon plus gros soucis. Je m'explique:
  
  • côté sécurité : c'est bon, j'ai configuré Hudson avec une "Stratégie d'autorisation matricielle basée sur les projets" et une authentification LDAP. Du coup chaque job peut avoir ses accès propres (la personne qui crée le job doit définir correctement les droits sur son job).
  • côté infra : j'ai besoin de faire 2 choses:
    
    1. fixer des quotas de stockage par projet (ex: projetA a le droit à 2Go d'espace disque)
    2. faire des sauvegardes par projets (cad sauvergader tous les jobs pour le projetA)
    
    C'est là que je galère car tous les jobs sont stockés dans le $hudson_home/jobs. Et comme chaque projet a plusieurs jobs (j'ai en monyenne 6 jobs par projet), je ne sais pas comment "rattacher" les jobs à un projet.
  
  

Il y a un plugin qui permet de structurer les jobs sous forme arborescente. Mais ce n'est pas sûr qu'il puisse régler tous tes problèmes.
Je recherche le plugin et je te dis.

Quant au 2e point, je ne comprends pas trop : tu veux sauvegarder quoi au juste ?

A noter que tu peux spécifier dans les configurations d'un job le nombre de builds que tu souhaites conserver (soit en nombre, soit en durée). Mais aussi, tu peux spécifier (il faut cliquer sur Advanced) le nombre d'artifacts que tu souhaites conserver, sur les mêmes critères.
Par exemple, mes jobs conservent un historique de 50 builds mais seulement 2 artifacts, ce qui limite fortement la taille utilisée par chaque job. En gros, si un build complet prend 200Mo, alors je vais conserver 200Mo x 2 + ~5 Mo x 48 (et non pas 200Mo x 50) car Jenkins me conserve pour les 48 autres jobs seulement les métadonnées + console.
C'est non seulement pratique, mais super important pour moi, car Sonar surveille aussi notre stabilité des builds, grâce au plugin "build stability plugin" : http://docs.codehaus.org/display/SON...ability+Plugin
(ça me fait penser que mon patch de la 1.1.2 de ce plugin n'a pas été intégré pour l'instant ).

Windows ou Linux je ne pense pas que ça change beaucoup de chose. Par contre la personne qui s'occupe de l'infra connait un peu les outils, non ?

Bah ici c'est assez simple : on demande une VM super puissante, et puis on obtient une VM pas si puissante que ça 6 mois après (j'attends toujours ma 2e VM d'ailleurs, parce que ma VM dual-core a du mal à gérer ma trentaine de jobs)

[romaintaz]

Il me semble que c'est le Nested View plugin :

https://wiki.jenkins-ci.org/display/...ed+View+Plugin