On est parti ! nginx 1.0.0 est sorti

Posté par (page perso) . Modéré par patrick_g. Licence CC by-sa
44
13
avr.
2011
Internet

Nginx est à la fois un serveur HTTP et un proxy inverse pour HTTP et IMAP / POP3. Поехали, la version 1.0.0 est sortie hier.

Développé sous licence BSD, Nginx sert fidèlement de nombreux sites Web, dont LinuxFr.org, et leur apporte performances, fiabilité et configurabilité. Des études indiquent qu’il servirait entre 6,5 % et 7 % du Web mondial (derrière Apache et IIS, mais devant Google, Lighttpd et Cherokee).

Cette version 1.0.0 arrive après 9 ans de développements soutenus et montre, s’il en est besoin, la stabilité du projet. Je vous encourage à l’essayer.

  • # Petits joueurs

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

    Cette version 1.0.0 arrive après 9 ans de développements soutenus et montre, s’il en est besoin, la stabilité du projet.

    Boarf. Le seul projet stable que je connaisse c'est wine, avec ses 15 ans pour arriver à la version 1.

    Il existe deux catégories de gens : ceux qui divisent les gens en deux catégories et les autres.

    • [^] # Re: Petits joueurs

      Posté par . Évalué à 10.

      mplayer a la capacité de les battre tous, avec ses 11 ans de développement sans arriver à une 1.0.
      Surtout qu'il est en Release Candidate depuis bientôt 5 ans.

      • [^] # Re: Petits joueurs

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

        Et slrn ?

        • [^] # Re: Petits joueurs

          Posté par . Évalué à 1.

          Tu triches, tu parles de projects qui n'existent même pas.

          • [^] # Re: Petits joueurs

            Posté par . Évalué à -2.

            enlightenment aussi mais je pense que le record c'est dukenukem forever.
            Je pense ne jamais voir une version 1.0 de mon vivant ;)))

            • [^] # Re: Petits joueurs

              Posté par . Évalué à 4.

              Vous auriez oublié GNU/HURD ? Plus de 20 ans maintenant et toujours pas de version 1…

              • [^] # Re: Petits joueurs

                Posté par . Évalué à 4.

                Remaquez que Linux n'est pas mal non plus dans le genre : alors qu'il vient de fêter ses vingt ans, il n'en est qu'à la 2.6…

                Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

  • # Reverse Proxy

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

    J'ai jamais vraiment trouvé l'info (j'ai pas non plus passé des heures dessus) mais nginx fait-il la ré-écriture d'URL en mode reverse proxy. En gros l'instruction "ProxyHTMLURLMap" qu'on utilise dans Apache.

    Question annexe : y-a-t'il un autre reverse proxy qu'Apache qui sache faire cela et authentifier les utilisateurs sur un LDAP ?

    • [^] # Re: Reverse Proxy

      Posté par . Évalué à 3.

      Personnellement j'utilise squid3 pour faire un reverse proxy pour mes sites web (chacun sur sa VM). Je sais qu'il peut faire l'authentification (et même via ldap) et qu'il peut même passer cette identification au sites derrière.
      J'ai même réussi a faire du https: pour une application qui ne le supportait pas (tout est en https jusqu'au reverse)
      J'ai 4 lignes par vhost (c'est scriptable comme modification) au lieu de 1 vhost par site sur mon ancien apache reverse proxy.

      • [^] # Re: Reverse Proxy

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

        Tu as un exemple ou tu fais de la ré-écriture de lien HTML dans une page web ?

        En pratique, ce que tu fais avec squid, c'est exactement ce que je fais avec apache mais il faut que je ré-écrive partiellement les pages.

        Exemple de ré-écriture :

        intranet en interne, pas d'authentification, pas de SSL -> http://intranet...

        intranet en externe, authentification LDAP -> https://www..../intranet/

        Apache ré-écris les URL et c'est complètement transparent pour l'utilisateur.

        • [^] # Re: Reverse Proxy

          Posté par . Évalué à 1.

          Je triche, je ne fais pas de réécriture de page du tout!

          exemple réel : une application qui écoute sur le port *:4080, je suis pas allez mettre les mains dans le cambouis pour qu'elle réponde a un nom particulier (en fait si, j'ai essayé rewrite d'apache2 mais ça + le proxy + https ça donnait des résultats ...mitigés)

          cache_peer 192.168.0.56 parent 4080 0 no-query login=PASS originserver name=<APP>
          acl mydomain2 dstdomain <FULLDNSNAMEHERE>
          cache_peer_access <APP> allow mydomain2 http_access allow mydomain2

          Bon ca nécessite d'avoir un DNS mais je préfère avoir intranet.maboite.cool.fr plutôt que maboite.cool.fr/intranet.

          Pour avoir testé les 2 (avant squid j'avais un apache mod_proxy + rewrite ) je préfère mille fois la syntaxe squid que celle d'apache2 et ce bloc de 4 lignes est facilement ajoutable par script si on veut industrialisé le processus d'ajout de site.

          Tu rajoutes cette ligne en haut de ton squid et voilà :
          https_port 443 cert=/etc/squid3/mykey.crt key=/etc/squid3/mykey.key vhost

          Ton squid accepte des connections sur 443 et redirige vers une webapp qui écoute sur le port XXXX et ne sait pas, mais pas du tout parler https.

          Le lien proxy vers webapp est pas sécurisé mais c'est pas en clair sur le net, et c'est déjà pas mal.

    • [^] # Re: Reverse Proxy

      Posté par . Évalué à 2.

      Extrait de la doc nginx sur le module proxy : http://wiki.nginx.org/HttpProxyModule

      location  /name/ {
        rewrite      /name/([^/] +)  /users?name=$1  break;
        proxy_pass   http://127.0.0.1;
      }
      
      • [^] # Re: Reverse Proxy

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

        C'est limité à HTTP, ce qu'il demande c'est que le HTML soit ré-écrit lui aussi (quand les pages contiennent des URLs "en dur" vers le site que tu cherches a ReverseProxyser).

        • [^] # Re: Reverse Proxy

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

          cela s'appelle SSLstrip dans ce cas.

        • [^] # Re: Reverse Proxy

          Posté par . Évalué à 3.

          Au temps pour moi. J'avais lu "ré-écriture d'URL" en supposant que comme d'habitude il s'agissait de traitement des requêtes, et non de la réponse.

          A mon avis, c'est possible avec nginx, mais je n'ai jamais pratiqué ça.
          Il faudrait essayer les modules sub, voire substitutions, qui permet de filtrer la réponse (que l'on soit en reverse-proxy ou pas).

        • [^] # Re: Reverse Proxy

          Posté par . Évalué à 1.

          J'ai essayé de faire passer nginx chez mes collègues, mais ils ont tous bloqué sur le reverse proxy avec réécriture dans la réponse ainsi que la réécriture des cookies.
          Vu comment ca gueulait j'ai du mettre un apache2 :'(
          Mais si quelqu'un a des exemples je suis preneur.

    • [^] # Re: Reverse Proxy

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

      Si tu veux réécrire ce qui arrive du serveur web avant de le transmettre au client : SubModule.

      Sinon si tu veux faire des choses très très spécifiques et que tu sais faire du C, l'api pour coder des modules nginx est assez accessible.

  • # nginx vs the rest

    Posté par . Évalué à 4.

    A noter quand même que bien que nginx soit plus rapide que par ex Apache en fichiers statiques, il est plus lent que apache prefork+mod_php (nginx+fcgi+php-fpm) et encore plus que apache event+mod_php/thread safe (pas super stable ca par contre)

    c'est pour ca que en general ca fini en apache prefork+mod_php avec nginx en reverse caching proxy devant chez les gens "serieux" niveau perf

    • [^] # Re: nginx vs the rest

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

      Je n'ai pas poussé très loin la comparaison mais nginx+php_fastcgi est plus rapide qu'un apache+prefork+mod_php pour servir du magento sur une de mes VM de dev.

      Par contre, pas de modsecurity sans apache bien qu'il soit indiqué sur le site de modsecurity : "Trustwave's SpiderLabs is currently seeking community assistance with developing a port of ModSecurity for the Nginx platform." ce qui serai une bonne chose.

    • [^] # Re: nginx vs the rest

      Posté par . Évalué à 4.

      A noter quand même que bien que nginx soit plus rapide que par ex Apache en fichiers statiques, il est plus lent que apache prefork+mod_php (nginx+fcgi+php-fpm) et encore plus que apache event+mod_php/thread safe (pas super stable ca par contre)

      C'est possible. Mais il ne me bouffe pas les trois quarts de ma RAM et tout mon CPU sur mon SheevaPlug… (Désolé, je n'ai pas pu attendre vendredi)

      Knowing the syntax of Java does not make someone a software engineer.

      • [^] # Re: nginx vs the rest

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

        en quoi c'est grave qu'il utilise ta ram ?

        • [^] # Re: nginx vs the rest

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

          Certains s'en servent pour faire fonctionner d'autres programmes en même temps.

          • [^] # Re: nginx vs the rest

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

            Le gros problème c'est surtout quand il utilise plus de RAM que ce qu'il y a à disposition.

            J'ai eu le problème inverse hier, mysql n(utilisait pas assez de RAM. Ce qui fait qu'un import était long sur une machine de guerre. J'ai modifié la conf et tout est rentré dans l'ordre.

          • [^] # Re: nginx vs the rest

            Posté par . Évalué à 3.

            Ben c'est le boulot du noyau d'allouer la RAM correctement.

            En quoi est-ce un problème que tant qu'il reste de la RAM, elle soit allouée ?

            Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

            • [^] # Re: nginx vs the rest

              Posté par . Évalué à 2.

              J'ai la commande ultime (pas en root ! ) :

              sort /dev/zero
              
            • [^] # Re: nginx vs the rest

              Posté par . Évalué à 2.

              il est vrai qu'apache utilise plus de ram pour la même tâche en prefork en tout cas, j'ai pas fait attention s'il y avait une different en event, pour la raison qu'en event, apache est pas tres loin de nginx en statique ou php/fcgi (mais dans ce cas la autant utiliser nginx..) et en mod_php, c'est stable uniquement sur certain sites qui n'utilisent pas de lib non thread-safe (c'est pas la faute de apache, et c'est pour ca que y a pas de "modphp nginx" mais bon ca change rien au resultat)

      • [^] # Re: nginx vs the rest

        Posté par . Évalué à 2.

        Nginx est surtout efficace sur un grand nombre de connexions, servant des pages statiques ou non. On a fait quelques benchmarks (avec apache benchmark) pour un projet en cours, et on a vu la différence assez vite.

  • # NGINX les manques

    Posté par . Évalué à 2.

    Les petits défauts de NGINX c'est le non support d'ipv6, la relative perte de performance avec php.
    Au delà de cela ce n'est que du bonheur :

    • Faible consommation de ram

    • Tenue correcte sous forte charge

    Cependant je lui préfère yaws, pour la simple raison que le langage erlang me passionne.

Suivre le flux des commentaires

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