Bonsoir cher communauté du libre !
Voilà une petite info qui est passée inaperçue ici, mais qui a fait un peu de bruit dans le monde du développement Web Ruby on Rails : la sortie de Passenger (ou mod_rails) pour Apache.
Le déploiement d'une appli Rails n'a jamais été très simple : entre un mod_ruby qui s'est révélé rapidement inutilisable, un mod_fcgi qui a rapidement montré ses limites en terme de flexibilité, les développeurs n'ont plus eu beaucoup de choix.
Depuis, la solution typique est d'utiliser un front end qui fait reverse proxy et balance de charge.
Petit à petit le déploiement s'est simplifié et surtout s'est automatisé grâce à des outils exceptionnels tels que Capistrano...
Malgré cela il est vrai que pour des petites applications, on restait loin de la facilité d'un mod_php/apache où balancer ses fichiers sur un FTP suffit à faire tourner la machine.
Il y a quelques semaines est enfin sorti un vrai mod_rails pour Apache 2. Ce module installable en quelques secondes via le gestionnaire Gem de Ruby permet de déployer littéralement une application Rails en quelques secondes. Ce petit bijou nous viens d'une petite entreprise hollandaise, qui, bien que son développement fût privé, a sorti le module sous licence libre.
Les premiers retours en terme de performances sont relativement bons et la documentation est bien écrite.
Si vous avez boudé votre plaisir de vous mettre à fond dans Rails pour des soucis de déploiement compliqué, cette excuse ne marche plus ! A vos rails... de code !
http://www.modrails.com
Journal Déployer une appli Rails en quelques secondes
6
mai
2008
# Questions
Posté par maximegb . Évalué à 0.
Et Ruby lui-même, est-ce qu'il remplace Python ?
Non je dis ca car je voudrais trouver un remplaçant à PHP.
[^] # Re: Questions
Posté par Yusei (Mastodon) . Évalué à 4.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 4.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Questions
Posté par maximegb . Évalué à 1.
Ok, il manque l'UTF8 et les espaces de nom, et les libellés des fonctions sont un peu fouillis, mais :
On trouve facilement PHP5 sur n'importe quel ubuntu, Il gère plein de base de données de façon native, propose de nombreuses librairies, permet de créer facilement des services XML-RPC et REST. Des gros sites comme wikipedia tiennent bien la charge. On trouve des documentations de bonne qualité comme sur le site onlamp.com
[^] # Re: Questions
Posté par CrEv (site web personnel) . Évalué à 5.
ce qui est à mon avis déjà un très gros problème...
> On trouve facilement PHP5 sur n'importe quel ubuntu
ha ben si c'est dispo sur ubuntu.... (non mais franchement, ça veut rien dire comme phrase...)
sans rire, on trouve du ruby partout aussi...
> Il gère plein de base de données de façon native
idem
> propose de nombreuses librairies
idem
> permet de créer facilement des services XML-RPC et REST
idem (enfin, tout comme avec php ça dépend aussi des frameworks ou libs...)
pour la charge, je rentrerai pas dans le troll (surtout que j'ai pas testé mod_rails) et la doc, c'est parfois peut-être un peu pauvre mais sur http://www.ruby-doc.org il y a déjà de quoi faire.
Concernant la question initiale :
Qu'est ce que tu appel stabilisé ?
Parce que bon, php n'est pas stabilisé, php6 est en dev
et du côté ruby, ben ça évolue avec la 1.9, rails vient de sortir une version 2 mais ça c'est comme bcp de frameworks php ou autre
Et remplacer python ?
Je pense que c'est impossible pour la simple est bonne raison que ce sont deux visions complètement différentes.
Python est adèpte du "explicit is better than implicit" (que personnelement je trouve horrible), avec souvent une seule manière de faire les choses (ce qui bride à mon sens la création)
Ruby de son côté est très expressif, avec un langage souvent concis utilisant justement l'implicite et ayant plusieurs manières de faire les choses.
La vrai question serait plutôt de savoir si ruby va remplacer perl...
Je vois un peu ruby comme le perl6 tant attendu...
[^] # Re: Questions
Posté par Yusei (Mastodon) . Évalué à 4.
Quand j'ai appris Perl, c'était le langage novateur qui permettait de coder très vite de manière naturelle, maintenant cette description est plutôt appliquée à Ruby et Python.
Et en tout cas, en ce qui me concerne, j'ai commencé à utiliser Ruby à la place de Perl, puis à la place des autres langages aussi (dans la mesure du raisonnable).
[^] # Re: Questions
Posté par CrEv (site web personnel) . Évalué à 3.
c'est justement là où j'ai du mal avec python...
je ne trouve pas du tout qu'on puisse coder de manière naturelle avec, là où ruby s'en sort vraiment mieux
> mais je n'ai pas l'impression que ce soit un langage que beaucoup apprennent aujourd'hui, en dehors de domaines spécifiques comme la bio.
Il est aussi enseigné en sciences du langage (entre autre)
> Et en tout cas, en ce qui me concerne, j'ai commencé à utiliser Ruby à la place de Perl, puis à la place des autres langages aussi (dans la mesure du raisonnable).
pareil, même si ça dépasse parfois le raisonnable ;-)
[^] # Re: Questions
Posté par maximegb . Évalué à -3.
C'est évidemment empirique. Entre les versions présente dans Ubuntu 6.06 LTS et celle de la 8.04 LTS, Ruby On Rails a-t-il plus évolué que PHP5 ?
Ce fameux mod_rails dont parle le journal, n'est pas présent dans la 8.04 LTS, et la page d'accueil de rubyonrails n'en parle pas non plus.
Je me doute que les tutoriaux vont mettre un certain temps à en parler, pour quelque chose de fondamental :
“It is often said that Rails is weak on deployment; PHP runs fairly fast just by uploading scripts. Rails is slow on development mode, and requires restarting on production mode (and bit complex to configure). modrails might be the answer for it.”
Yukihiro Matsumoto (Matz), Creator of Ruby
[^] # Re: Questions
Posté par CrEv (site web personnel) . Évalué à 5.
(oui désolé, j'overdose de références à ubuntu tous les 3 mots)
Soit dit en passant, mod_rails existait avant la sortie de la dernière version d'ubuntulinuxleseullunique et vu qu'ils ont collé un firefox beta ils auraient pu coller un mod_rails
[^] # Re: Questions
Posté par maximegb . Évalué à -3.
Si on pousse en entreprise l'idée qu'une distribution Linux (par exemple la 6.06 LTS), c'est mieux que Windows, car tous les logiciels nécessaires pour faire un serveur sont intégrés (Apache, mod_php, mysql, toussa) et que c'est maintenu longtemps, c'est bête de se contredire ensuite en devant ajouter mod_rails à la mimine.
[^] # Re: Questions
Posté par Yusei (Mastodon) . Évalué à 3.
Si on veut vraiment utiliser un logiciel plus récent que sa distribution, il faut assumer le fait de l'installer soi-même.
D'autre part, Ruby fournissant un gestionnaire de packages qui lui est propre (rubygems), et rubygems étant packagé par Ubuntu, l'installation des extensions ruby se fait très simplement. Un coup de "gem install package" et c'est bon.
[^] # Re: Questions
Posté par maximegb . Évalué à -1.
Je n'ai pas espéré un tel voyage dans le temps.
Baser son argumentaire là dessus pour "pousser" Linux en entreprise serait pour le moins amusant.
Sur cette page, j'ai bien l'impression que Canonical défend l'idée de la stabilité dans le temps pour pousser Linux en entreprise :
http://www.ubuntu.com/products/whatisubuntu/serveredition/be(...)
(et dépense de l'argent dans ce sens !)
[^] # Re: Questions
Posté par Yusei (Mastodon) . Évalué à 3.
Je suppose que tu es au courant que Rails est inclus dans les précédentes Ubuntu (au moins les deux dernières), et ne nécessite pas Passenger pour fonctionner. Je n'arrive pas à comprendre en quoi l'arrivée de Passenger remet en question la stabilité de Rails, ou la pertinence du choix de Rails pour développer un site.
Il y a des critiques à faire concernant Rails, mais celle là me semble complètement infondée. Autant que de critiquer PHP5 parce que Redhat 5.2 ne l'inclue pas.
[^] # Re: Questions
Posté par maximegb . Évalué à 2.
Et je souligne que par ailleurs PHP5 n'a pas bougé en 2 ans, ce qui peut rassurer certains (donc être vu comme un avantage sur Rails).
[^] # Re: Questions
Posté par Yusei (Mastodon) . Évalué à 2.
Rails, quant à lui, est trop jeune pour qu'on lui demande de ne plus bouger, je pense. Je n'ai aucune idée de la durée de vie programmée de la branche 2, d'ailleurs je suis resté à Rails 1 pour mon usage personnel (différentes versions de rails cohabitent bien si elles sont installées avec Gem).
[^] # Re: Questions
Posté par Jean B . Évalué à 2.
Autrement dit rien ne t'oblige à migrer sur une version plus récente. De plus une appli rails a la possibilité d'embarquer rails lui même pour faciliter les migrations serveur.
[^] # Re: Questions
Posté par CrEv (site web personnel) . Évalué à 3.
on a vu pire comme installe à la mimine (et vu que le serveur est bien évidemment en console, on n'y verra que du feu)
Maintenant, pour ce qui est de l'intégration d'un soft récent dans une version datant de 2 ans mais toujours supportée... ben faut ptetre voir s'il y a des backports, mais franchement avec la commande ci-dessus pas besoin du tout
Et à mon avis, l'intérêt de passer du linux en prod sur des serveurs est vraiment ailleurs que dans l'intégration de divers softs mais beaucoup plus dans les perfs et la stabilité.
Et pour bcp de cas, il est même préférable de repasser par une installe à la mano de l'ensemble des serveurs (apache, php, rails, bases de données, ...) pour que ça colle vraiment aux besoins.
(tiens, sur les perfs, petit discours sympa d'un commercial venu nous expliquer comment dimensionner les serveurs pour leurs appli :
au niveau de la ram, il faut compter qu'à partir de 70% d'occupation, windows swap, donc il faut toujours avoir 1/0,7 fois plus de ram que prévu...
pitoyable...
mais c'est pour des points comme ça que je bénis mon linux qd j'occupe plus de 90% de la ram et que j'utilise 10ko de swap...)
[^] # Re: Questions
Posté par Yusei (Mastodon) . Évalué à 4.
Je ne connais pas de framework PHP, mais je peux comparer les langages PHP et Ruby. J'ai commencé à utiliser massivement Ruby aux alentours de 2003, et je n'ai pas remarqué de changement ou d'instabilité depuis au niveau de la version principale, la 1.8. PHP 5, quant à lui, est sorti en juillet 2004, il existe donc depuis moins longtemps.
Maintenant, niveau framework, Rails est très jeune, et bouge pas mal. Il y avait assez peu de changements problématiques entre la 1.0 et la 1.2, mais il y en a plus entre la 1.2 et la 2.0, ce qui semble logique. Certains ont reproché à Rails de trop souvent casser la compatibilité ascendante au lieu de simplement déprécier les choses.
Quant à modrails, il vient de sortir, pas étonnant qu'il ne soit pas encore dans les distributions. Il faut quand même relativiser la difficulté de déploiement de Rails. C'est un peu plus pénible que de simples scripts à placer dans un répertoire accessible à apache, mais c'est beaucoup moins problématique depuis que la méthode "officielle" consiste à coupler mongrel et apache+mod_proxy.
Le principal obstacle au déploiement, c'est surtout que l'on a besoin de contrôler la config du serveur pour configurer mod_proxy. modrails ne changera ça que s'il commence à être activé massivement par les hébergeurs, ce qui est loin d'être gagné.
[^] # Re: Questions
Posté par maximegb . Évalué à -1.
Alors que pensez de ce texte ou l'auteur du PHP semble considérer son langage comme équivalent d'un framework (comme pouvant fournir les services que fournissent un framework) ?
http://toys.lerdorf.com/archives/38-The-no-framework-PHP-MVC(...)
Sur le site de mod_rails, PHP est bien en tant que tel un "modèle" de déploiement :
Phusion Passenger (a.k.a. mod_rails) is our commercial supported open source product that enables people to deploy their Ruby on Rails applications in an upload-and-go manner, which is very reminiscent of the PHP way of deploying.
L'auteur de Ruby on Rails parle de PHP sur son blog en terme de "plateform". :
http://www.loudthinking.com/posts/23-the-immediacy-of-php
[^] # Re: Questions
Posté par Yusei (Mastodon) . Évalué à 3.
Je suppose qu'il faut préciser ce qu'on veut dire par framework, puisque c'est un mot qui n'est pas clairement défini. Si on décide qu'un framework, c'est un langage associé à un ensemble de bibliothèques, alors PHP est un framework, ainsi que Ruby, Python, Perl, Java, et les autres.
Dans ce cas, Rails n'est pas un framework, mais quelque chose qui se situe un niveau au dessus, de la même manière qu'en PHP on trouve CakePHP, Horde, et autres. Mais comme je ne les ai pas utilisés, je ne peux pas commenter.
Maintenant, après avoir jeté un oeil sur l'article en lien, j'ai simplement l'impression que l'auteur montre comment on code un framework MVC simple en PHP. Il y en a plein, des frameworks reposant sur PHP, mais ça n'empêche pas PHP d'être un langage, pas plus.
"PHP est bien en tant que tel un "modèle" de déploiement"
Si "cp" est un modèle de déploiement, alors oui. Mais ça n'a rien à voir avec PHP, il s'agit juste du fait qu'apache sait exécuter des scripts si on le configure bien. On peut obtenir la même chose avec d'autres langages de scripts, y compris Ruby-tout-seul, et en règle générale tous les langages pour lesquels il existe un mod_langage pour apache.
Pour remplacer PHP par Ruby, il faut activer mod_ruby. Ruby est livré avec un système de templates (ERB) semblable à celui de PHP, qui permet de l'utiliser de la même manière.
[^] # Re: Questions
Posté par Larry Cow . Évalué à 2.
Hein? Autant pour la maxime, ça est vrai (encore que ça n'est qu'une des "lignes directrices" de python, et pas la plus prioritaire ... cf la définition des blocs), autant le "une seule manière" est abusif. Pour la plupart des choses, il y a au moins l'approche procédurale et l'approche fonctionnelle (compréhension de listes, etc.). Avec parfois, en plus, des choses bizarres à base de générateurs.
# super !
Posté par Adrien . Évalué à 1.
J'espère que ce langage ( Ruby ) et ce framework ( rails) vont de généraliser sur les hébergements maintenant... que du bonheur en perspective.
# Performances
Posté par yellowiscool . Évalué à 3.
Avec 5 threads maximums:
- fastcgi 7 pages par seconde
- mod_rails 19.5 pages par seconde
Par ailleurs, c'est des performances ridicules.
Mais mod_rails est clairement une grande avancée tellement c'est simple à installer, et pratique.
Envoyé depuis mon lapin.
[^] # Re: Performances
Posté par yellowiscool . Évalué à 2.
En mode production, c'est bizarrement des résultats semblables (33 pages par seconde), avec un avantage pour lighttpd.
Ça doit légèrement varier dans des conditions réelles, mais ça prouve que mod_rails est déjà performant.
Envoyé depuis mon lapin.
[^] # Re: Performances
Posté par Jean-Philippe (site web personnel) . Évalué à 1.
Il me semble avoir vu des benchs ou nginx + thin était "assez plus" performant que passenger.
Reste à voir le niveau de stabilité de passenger (et thin) par rapport à mongrel...
[^] # Re: Performances
Posté par yellowiscool . Évalué à 0.
Envoyé depuis mon lapin.
[^] # Re: Performances
Posté par zerchauve . Évalué à 2.
ca doit etre marqué 430240298324298 fois dans la doc qu'il faut acheminer les fichiers statiques par le load balancer (nginx ou apache par exemple)....
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.