Discussion :

[ptonnerre]

Bonjour,

nous devons administrer/exploiter des applications dans un environnement RHEL 6.6 / JBoss EAP 6.2

Nous avons testé la méthode CLI et, bien que pratique, l'application n'est plus visible dans le répertoire de déploiement.
La méthode Deployment scanner nous semble simple et les marqueurs offrent une grande souplesse d'utilisation.
La méthode console d'administration est pratique, mais nous semble moins complète que CLI par exemple.

Il nous semble que lorsqu'on choisit une méthode, il faut s'y tenir et éviter de mixer les méthodes : livrer une application via CLI et ensuite dans le filesystem via le Deployment scanner pose a priori des problèmes.
Désactiver puis réactiver via la console d'admin une application déployée via le Deployment scanner laisse le marqueur .undeployed et l'application est pourtant disponible.

Nous ne sommes pas des experts et ces premiers tests nous amènent à nous demander elle est la meilleure méthode pour déployer manuellement puis automatiquement (scripting depuis machine de livraison) des applications, quelles sont les règles à suivre (mixer ou non les méthodes de déploiement) ?

Merci pour vos conseils et retours d'expérience

[hasalex]

Vous n'êtes peut-être pas des experts, mais vous vous posez les bonnes questions.

Effectivement il ne faut pas mélanger le déploiement dans le répertoire deployments/ avec le déploiement par les outils d'admin. Par contre, la console d'admin et CLI sont parfaitement compatibles, vous pouvez mixer les deux.
A mon avis, CLI est la meilleure façon de procéder, surtout pour l'automatisation. Vous pourrez créer des scripts qui font tout le boulot de préparation, création de datasource, JMS detinations,..., et le déploiement. Avec le mode batch, vous pourrez en plus faire ça de façon atomique : on valide toute les opérations ou aucune.

Pour empêcher le mauvais mix, vous pouvez supprimer le deployment scanner et supprimer le répertoire deployments/.

[ehsavoie]

J'abonde la réponse d'Alexis.
En plus le scanner en fonctionne qu'en mode standalone et pas en mode domain.
Mixer les modes fonctionne avec WildFly mais il faut être sur les dernières versions d'EAP 6 pour éviter un certain nombre d'écueils.
Le contenu en CLI ne disparait pas il passe 'juste' dans le répertoire content et est récupérable il me semble.
Il est préférable de passer par la CLI ou la Web Console pour avoir une 'vue' des applications déployées.

[ptonnerre]

Bonjour,

merci pour ces précieux renseignements qui nous permettent d'avancer sur le sujet et de pressentir la solution future, CLI.
Nous avons commencé la rédaction d'outils en Perl intégrant les commandes CLI et venons de trouver sur CPAN, 2 modules dédiés à JBoss et qui pourraient nous apporter des fonctionnalités complémentaires (stats...). Des retours d'expérience/conseils sur ces modules :

http://search.cpan.org/~heince/Net-J.../Management.pm
http://search.cpan.org/~heince/Net-J...b/Net/JBoss.pm

Nous avons trouvé dans la doc JBoss comment désactiver de manière persistante le Deployment scanner :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

/subsystem=deployment-scanner/scanner=default:write-attribute(name=scan-enabled, value=false)

Celui-ci reste désactivé après un :reload ou un redémarrage via les script initd.

Par contre, nous n'avons pas trouvé comment récupérer une application livrée par CLI ou la console.

Enfin, est-il judicieux/conseillé/nécessaire de redémarrer le serveur (:reload ou initd) et de purger le répertoire tmp après une livraison ?

[ehsavoie]

/subsystem=deployment-scanner/scanner=default:remove() permet de l'enlever définitivement
Un :reload n'est pas l'equilavent d'un start/stop car il ne réinitialise pas la JVM, il redémarre les 'services' au sens JBoss/WildFly, donc ça n'a pas le même effet au niveau des classes chargées (après avec Java 8 la PermGen n'est plus là donc peut être que le gc fait qu'on y gagne).
Aucune idée sur ces modules CPAN mais le premier semble n'être qu'un wrapping sur ce que te permet la CLI donc d'un intérêt limité.

[hasalex]

Pas d'avis non plus sur les modules. Par contre, c'est intéressant de regarder le code source, pour voir qu'ils n'utilisent pas directement CLI, mais l'API de management HTTP.

Le résultat est strictement identique à CLI, sans nécessiter l'installation de CLI. En clair, tes outils PERL n'auront pas besoin de Java ou JBoss pour fonctionner.