Les pouvoirs magiques d'Unicorn 1.0.0

Posté par (page perso) . Modéré par baud123.
19
19
juin
2010
Ruby
Unicorn est un serveur applicatif HTTP en Ruby comparable à Mongrel ou à Thin, sous licence GPLv2. Il est utilisé notamment par Twitter et Github et vient d'atteindre la version 1.0.

Unicorn est compatible avec Rack, une interface entre les serveurs applicatifs et les frameworks. Il peut ainsi être utilisé pour servir des applications Ruby, dont celles écrites en Ruby on Rails. Il tourne avec Ruby 1.8, Ruby 1.9 et bientôt Rubinius. Rappelons que Rubinius est une implémentation alternative de Ruby dont la version 1.0 est sortie récemment.

Unicorn s'appuie au maximum sur les noyaux Unix pour éviter de réinventer la roue. Par exemple, la répartition des requêtes entre les différents processus se fait grâce à une socket partagée. Il est également possible de mettre à jour Unicorn, l'application ou l'interpréteur Ruby sans perdre la moindre connexion.

De même, Unicorn est optimisé pour servir des clients rapides. Il est donc très souvent utilisé derrière un reverse-proxy, qui pourra bufferiser les requêtes des clients lents.

A l'inverse, utiliser Unicorn pour des connexions longues comme du Comet (Comet désigne un ensemble de techniques où un serveur maintient des connexions HTTP ouvertes pour pouvoir pousser des contenus vers les clients) ou des websockets serait très inefficace, je vous conseille pour cela de regarder Rainbows : c'est un projet inspiré d'Unicorn qui vise justement à répondre à cette problématique particulère.
  • # licorne rose

    Posté par . Évalué à 0.

    Unicorn, rainbow , ruby ... He bien moi je joue avec la licorne sans serveur http en ruby :

    http://shanghai.waihuo.com/fuwusheng/a245149.shtml
  • # éviter de réinventer la roue

    Posté par . Évalué à 8.

    Quel est l'intéret d'avoir de faire des serveurs HTTP spécifiques à Ruby ? Pourquoi ne pas utiliser Apache directement ? Pourquoi les cacher systématiquement derrière un reverse-proxy ?

    Python, PHP ou Perl s'utilisent très bien via un mod_ pour apache (ou autre serveur) ou de façon plus portable / moins spécifique au serveur via CGI, FastCGI, WSGI, etc. Pourquoi pas Ruby ?

    (Je ne connais pas beaucoup le monde Ruby, ce sont de vrais questions :) ).
    • [^] # Re: éviter de réinventer la roue

      Posté par (page perso) . Évalué à 10.

      Ça fait beaucoup de questions d'un coup, mais je vais essayer d'y répondre.

      Tout d'abord, je me rends compte que ma dépêche pourrait laisser à penser qu'Unicorn est un concurrent d'apache2 ou de nginx. Ce n'est pas le cas, il est utilisé pour du contenu dynamiques, pas pour servir des ressources statiques.

      Les mod_* pour apache, ça existe aussi dans le monde Ruby : ça s'appelle phusion passenger. Il existait auparavant un mod_ruby, mais il n'est plus maintenu et personne ne l'utilisait car il avait des performances désastreuses.

      Mais ces solutions ne conviennent pas à tout le monde : certains utilisent d'autres serveurs web comme nginx, d'autres vont faire tourner les applications Rails sur plusieurs serveurs et n'ont pas envie de faire tourner apache sur tous ces serveurs, etc. Ces contraintes se rencontrent généralement sur des sites à fort trafic pour lesquels on cherche à séparer les problématiques pour différentes raisons : meilleures performances, plus facile d'isoler les bugs, maintenance plus aisée, etc. Pour arriver à cela, le serveur applicatif va servir des requêtes HTTP dynamiques très rapidement.

      On le place derrière un reverse-proxy pour un tas de raisons (sécurité, bufferiser les uploads, etc.) mais surtout pour éviter qu'il ne serve les fichiers statiques (nginx, ou à défaut apache, fait ça bien mieux).

      Maintenant, pourquoi utiliser HTTP plutôt que CGI ou FastCGI pour communiquer entre le reverse-proxy et les processus applicatifs ? J'aurais envie de dire que HTTP est un protocole connu qui convient bien pour ça, alors pourquoi utiliser autre chose ?

      Pour WSGI, il n'a pas vraiment sa place avec CGI ou fastCGI, c'est une interface pour les applications Python qui définit quelle fonction appeler (et comment) quand une requête HTTP arrive. Sous le capot, ça peut utiliser un mod_ pour apache, du CGI, du fastcgi, etc.

      En bref, nous avons quasiment une équivalence un pour un entre le monde Python et le monde Ruby :
      mod_python <-> mod_ruby (tous les 2 RIP)
      mod_wsgi <-> phusion passenger
      wsgi <-> rack
      gunicorn <-> unicorn

      PS : j'ai pris exemple sur Python, car en dehors de Ruby, c'est ce que je connais de mieux.
      PS2 : on a un bonus quand on arrive à caser 3 liens pertinents vers des dépêches LinuxFr.org que l'on a soi-même rédigé dans les 3 derniers mois ?
      • [^] # Re: éviter de réinventer la roue

        Posté par . Évalué à 3.

        D'accord, c'est utilisé comme FastCGI si je comprend bien.

        > d'autres vont faire tourner les applications Rails sur plusieurs serveurs et n'ont pas envie de faire tourner apache sur tous ces serveurs, etc.

        FastCGI permet de faire ça, et sans la lourdeur / complexité du protocole HTTP (enfin je suppose que ces serveurs Ruby n'implémentent que HTTP/1.0, ce qui limite la complexité). FastCGI est conçu dés le départ pour la performance, c'est un protocol binaire, plus facile à parser que HTTP, et qui peut fonctionner sur des sockets unix ou tcp (donc on peut avoir un apache/nginx qui transmet les requêtes à une ferme de serveurs FastCGI).

        > On le place derrière un reverse-proxy pour un tas de raisons (sécurité, bufferiser les uploads, etc.) mais surtout pour éviter qu'il ne serve les fichiers statiques (nginx, ou à défaut apache, fait ça bien mieux).

        C'est bien ce que j'avais compris, ce qui m'amenait à la question "pourquoi HTTP ?"

        > J'aurais envie de dire que HTTP est un protocole connu qui convient bien pour ça, alors pourquoi utiliser autre chose ?

        FastCGI a été créé spécifiquement pour ça :)
        • [^] # Re: éviter de réinventer la roue

          Posté par (page perso) . Évalué à 2.

          Alors, comme je ne connais pas bien FastCGI, je vais avoir du mal à répondre.

          Je constate juste qu'en pratique, les serveurs applicatifs qui utilisent HTTP sont en train de remplacer FastCGI et qu'ils ont l'air plus performants.
          • [^] # Re: éviter de réinventer la roue

            Posté par (page perso) . Évalué à 3.

            > Je constate juste qu'en pratique, les serveurs applicatifs qui utilisent HTTP sont en train de remplacer FastCGI et qu'ils ont l'air plus performants.

            Que ce soit du fcgi, du http, du ajp13 ça n'importe pas vraiment. L'implantation de fcgi en ruby à toujours été explosive (au sens propre du terme) d'où http.

            Pour php par exemple fastcgi va très bien. Pour python, il semble que wsgi soit en vogue ...
            l'important est la séparation frontal / application et l'implémentation.
  • # A noter que

    Posté par (page perso) . Évalué à 1.

    Puppet fonctionne très bien avec le couple unicorn / nginx

    Is it a Bird? Is it a Plane?? No, it's Super Poil !!!

  • # Merci beaucoup!

    Posté par . Évalué à 2.

    Merci pour la dépêche et les liens, c'est bien technique et très informatif a la fois, notamment les exemples sur comment font des sites webs a gros trafic pour s'améliorer.

    Est ce que la nouvelle version de linuxfr.org utiliseras Unicorn?
    • [^] # Re: Merci beaucoup!

      Posté par (page perso) . Évalué à 2.

      > Est ce que la nouvelle version de linuxfr.org utiliseras Unicorn?

      Je ne sais pas encore. J'étais plutôt parti pour thin, mais Unicorn est intéressant aussi. Va falloir que je regarde pus en détails les deux.
      • [^] # Re: Merci beaucoup!

        Posté par . Évalué à 1.

        Je serais curieux de voir le nombre de dyno / plan nécessaire pour faire tourner LinuxFR chez Heroku tiens.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.