Vous reprendrez bien un peu de lourd ?
DISCLAIMER : Ceci est un post à haute teneur en troll.
Redmine est de loin le meilleur outil web multiprojet pour le développement que j'ai pu utiliser en opensource. De plus il a l'avantage de bien s'interfacer avec mercurial, git et autres (D)VCS, parfait non ? Oui mais voila redmine pose plusieurs soucis :
- les dépendances a des versions très précises : rack 1.0.1 (pas 1.0 ni 1.1.0 mais uniquement 1.0.1) par exemple mais beaucoup d'autres comme ça.
- la surconsommation de ruby dès qu'il s'agit du web (je sais il existe REE pour ça mais quand même) j'ai testé thin, passenger, etc et dans tous les cas j'obtiens un gros ogre jamais rassasié de manger toute ma RAM.
Si en plus on rajoute les contraintes suivantes :
- pas d'accès internet sur les machines de prod,
- il faut pouvoir redéployer toutes les installations de façons simple et automatique.
Et bien déployer du ruby deviens tout de suite peu évident. Je précise que j'ai une faible connaissance du ruby et de son écosystème, ce qui n'aide pas. Or j'ai bien l'impression que c'est un sujet qu'il faut suivre de près si l'on si l'on veut pouvoir réellement l'utiliser efficacement en production.
Je ne vais tout de même pas m'arrêter là, cet outil répond au besoin, il faut donc trouver un moyen de l'installer et répondant aux contraintes.
C'est là que je tombe sur jruby, je me renseigne dessus et apprend que des applis rails de type redmine peuvent tourner sur des serveurs d'application java de type tomcat ou jetty par exemple et que les performances seraient plutôt bonnes. C'est peut être une bonne piste pour les performances, mais il reste la problématique de la reproductibilité de l'installation sur des machines sans accès à Internet.
Un peu de recherche et je tombe sur warbler ce petit outil me permettrai de pouvoir fabriquer un war (donc un package déployable sur un serveur d'application java) embarquant tout le nécessaire du monde ruby, plutot pas mal.
Je me lance donc, je prend une machine ChiantOS (oui la pire des contraintes c'est que ça doit tourner sur du chiantos :(), j'installe l'openjdk et j'installe jruby.
j'ai plus qu'à installer tout le nécessaire pour redmine :
$gem install rails -v=2.3.5
$gem install jruby-openssl warbler activerecord-jdbcpostgresql-adapter
Je fais une installation classique de redmine (je choisi la 0.9.4 là dernière au moment de ce post) je configue tout normalement, j'applique le patch pour le support de jruby 1.5.0
Attention dans le fichier config/database.yml il faut bien faire attention de précéder le nom du driver par jdbc :
adapter: postgresql devient adapter: jdbcpostgresql
Dans le répertoire redmine, taper :
$warble config
il faut maintenant éditer le fichier config/warble.rb générer :
embarquer les gems utilisées dans le war :
config.gems+= ["activerecord-jdbcpostgresql-adapter", "rack"]embarquer tous les fichiers :
config.dirs = %w(app config lib log vendor tmp extra files lang)
il suffit maintenant de générer le fichier war :
$warble
il doit avoir créé un fichier redmine.war qui embarque tout le nécessaire, il ne reste plus qu'à le déployer dans votre serveur d'application java de choix.
Dans mon cas j'ai choisi jetty.
Le résultat est surprenant, sur la même machine, redmine semble être boosté aux amphétamines et la consommation mémoire toujours élevée est quand même très largement réduite, par rapport au ruby classique.
du café commerce équitable pour freebsd
Bon alors voila, depuis quelque temps le support des BSD (MacOS X compris) pour openJDK est officialisé au sein de projet bsd-port.
Ne voyant toujours rien venir dans les ports (on est obligé de se farcir du java pas libre et surtout de ce faire chier à dl à la mano tous les trucs qui vont bien pour pouvoir l'installer en acceptant des licences à droite et à gauche), je dis que je vais me le builder moi même depuis les sources.
Il y a deux possibilités d'avoir l'OpenJDK en libre : la version officielle, et la version icedtea.
Je me suis d'abord rabattu sur la version Icedtea, en effet la version 1.8 annonce intégrer le projet bsd-port. Icedtea me semblait plus simple de prime abord car toutes les dépendances sont testées par les autotools, et qu'un presque simple ./configure && make && make install devrait faire l'affaire.
C'est sans compter sur les linuxismes, en effet, il lui faut gawk, md5sum (appelé md5 sur FreeBSD donc il ne le trouve pas) plus plein de choses à droite à gauche. En ayant eu marre de patcher toutes les 5 mins les autotools, de rajouter les 25000 dépendances qui me sont inutiles, j'ai honteusement lâché l'affaire pour me rabattre sur l'OpenJDK officiel. Et là magique simple et rapide pour le faire (pas rapide à compiler par contre) :
Tout d'abord il faut commencer par préparer son environnement, pour cela il faut installer :
- cups
- les libs Xorg
- diablog-jdk ou un jdk quelconque > 1.5
- freetype
Ensuite il faut récupérer les sources pour cela deux manières : celle recommandée mais chiantes (que j'ai moi) passe par mercurial, l'autre passe par un snapshot mercurial :
installer mercurial ajouter le plugin forest :
$ hg clone http://www.bitbucket.org/pmezard/hgforest-crew/
$ cp hgforest-crew/forest.py /laoujaienvie/forest.py
Puis dans le ~/.hgrc, ajouter :
[extensions]
hgext.forest=/laoujaienvie/forest.py
cloner l'aborescence openjdk :
$ hg fclone http://hg.openjdk.java.net/bsd-port/bsd-port
récupérer les plugs icedtea
$ fetch http://www.intricatesoftware.com/distfiles/jdk-7-icedtea-plugs-1.6a.tar.gz
compiler le tout (attention c'est long)
$ gmake \
ALT_BOOTDIR=/usr/local/diablo-jdk1.6.0/ \
ALT_FREETYPE_HEADERS_PATH=/usr/local/include \
ALT_FREETYPE_LIB_PATH=/usr/local/lib \
ALT_BINARY_PLUGS_PATH=/home/build/jdk-7-icedtea-plugs \
ANT_HOME=/usr/local \
NO_DOCS=true \
HOTSPOT_BUILD_JOBS=1 \
OPENWIN_HOME=/usr/local \
OPENWIN_LIB=/usr/local/lib \
X11_PATH=/usr/local
Attention pour tout cela il vous faudra environ 1.2Go d'espace disque.
Une fois toute cette opération terminée vous obtiendrez dans le rép bsd-port/build un joli répertoire bsd-i586 ou un joli répertoire bsd-amd64 suivant votre archi contenant votre jdk libre tout propre.
La seconde méthode consiste à ne pas utiliser mercurial mais à prendre un snapshot depuis l'hgweb
Par exemple, pour la dernière version disponible :
$ fetch http://hg.openjdk.java.net/bsd-port/bsd-port/archive/tip.tar.bz2
Le reste est identique.
Résultat :
$ /home/build/bsd-port/build/bsd-i586/bin/java -version
openjdk version "1.7.0-internal"
OpenJDK Runtime Environment (build 1.g7.0-internal-root_2009_01_12_16_54-b00)
OpenJDK Client VM (build 14.g0-b10, mixed mode)
Voila il ne me reste plus qu'a pondre une joli ports et hop.
A noter que pour la permière compilation il faudra quand même diablo-jdk, mais ensuite votre openjdk pourra compiler les nouvelles version d'openjdk.
PS: En fait ça me fait chier les post en Anglais :)
Du thé glacé sous Linux
J'avais besoin de java sur mon amd64 (avec le plugin). Bon jusqu'à maintenant c'était pas gagné, mais heureusement Sun a libéré une Bonne partie de Java (OpenJDK) et les petits de gars de GNU classpath la complète avec leur propre implémentation, la mixture ainsi obtenu est icedtea, qui a le bon goût de venir avec un plugin officiel pour amd64 ce qui n'est pas le cas de la VM de SUN.
J'en ai donc fait un PKGBUILD qui compile parfaitement sous mon archlinux, et j'ai ainsi un java fonctionnel et libre.
Voila pour plus d'informations : le PKGBUILD a tester : icedtea.tar.gz
Je n'ai tester que sur amd64 mais il devrait fonctionner sur x86.
Il sera disponible sur mon AUR dès qu'il aura été tester et valider sur x86
PS: 2h30 de compilation et plus de 3G de consommés quand même, beau bébé.
EDIT : Résultat
java version "1.7.0"
IcedTea Runtime Environment (build 1.7.0-root_28_nov_2007_12_45-b00)
IcedTea 64-Bit Server VM (build 11.0-b05, mixed mode)
Pages : 1