Dans cet article


Offres d'emploi

Tags

NGINX tutorial

Qu’est ce que NGINX?

NGINX est un « nouveau » serveur WEB apparu en 2002 qui vient concurrencer de plus en plus APACHE, qui reste pour l’instant majoritaire. Dans cet article, nous allons faire une courte introduction sur NGINX.

Pourquoi NGINX?

NGINX à la différence d’APACHE, n’utilise pas un modèle Thread Driven mais un modèle Event Driven. La différence principale entre ces deux approches est la suivante:

Modèle Thread Driven

Dans un modèle Thread Driven, un thread est créé dès qu’un client demande une page web. Ce thread va être responsable du traitement de l’intégralité de la page web. Quand ce thread attend une I/O (entrée / sortie), il se bloque et passe son tour au prochain Thread. Cette stratégie pose problème dans le cas d’un très grand nombre de connexions simultanées car, un très grand nombre de thread sont créés et se bloquent les uns les autres. De plus, comme chaque thread possède sa propre pile d’appel et son pointeur d’instruction, une overhead non négligeable est à prendre en compte. Ainsi pour répondre au fameux problème c10k, cette architecture ne semble pas (plus) la mieux adaptée.

Modèle Event Driven

Dans un modèle Event Driven, au contraire on ne retrouve « qu’un seul thread » qui traite toutes les requêtes puis les dispatche sur des handlers compétents qui eux même redispathent si nécessaire. Dans cette approche, très peut de thread sont créées, ce qui améliore les performance générale de cette approche dans le cas du problème c10k. Pour information, NGINX utilise le pattern de conception réactor.

Problème c10k

Pour rappel, ce problème est celui d’être en mesure de gérer 10 000 connexions simultanées sur un serveur web (ce qui est le cas de plus en plus de site web actuel)

Installation de NGINX.

Pour ceux qui possède une debian ou une distribution avec gestionnaire de paquet, l’installation de NGINX est triviale et se résume le plus souvent à un apt-get install nginx. (ou équivalent).

Il est aussi possible de le compiler très simplement depuis les sources. Ceci s’avère utile quand l’on souhaite utiliser des modules qui ne sont pas fournis par défaut dans les distributions, ou que l’on souhaite utiliser un version différente de la version stable.

Dans la version de base d’NGINX (qui se prononce engine-x), on trouve les modules suivants, ces modules ne peuvent pas être désactivés:

Nom Description
Core module Outils et directives essentiels tels la gestion des processus ou la sécurité
Events module Permet de configurer les mécanismes internes de la capacité de mise en réseau
Configuration module Permet d’utiliser le système d’inclusion

L’intégralité de la configuration de ces modules se trouve dans le fichier nginx.conf.

Voici les autres fichiers de configurations d’NGINX.

Nom Description
nginx.conf Configuration de base de l’application
mime.types Une liste d’extensions de fichiers avec leurs types MIME associés
Fastcgi.conf FastCgi configuration
Proxy.conf Configuration Proxy

 

Configuration NGINX les basiques

Diminutifs

Vous pouvez utiliser des diminutifs dans les valeurs de vos directives.

  • k or K: Kilobytes
  • m or M: Megabytes

Variables

Les modules fournissent également des variables qui peuvent être utilisées dans la définition des valeurs des directives.

Par exemple, le module de base Nginx HTTP définit la variable _$__nginxversion.

Les variables dans Nginx commencent toujours par « $ »-le signe de dollar.

Chaînes de caractères

Les chaînes de caractère peuvent être écrites de plusieurs manières différentes :

  1. Sans côtes :  root /home/axopen.com/www;
  2. Avec des simples côtes : root ‘/home/axopen.com/my web pages’;
  3. Avec un backslash

 

Configuration de base NGINX

Dans le fichier nginx.conf, les paramètres importants sont les suivants:

user nginx nginx; // Spécifie l’utilisateur et le groupe avec lequel le serveur est lancé

worker_processes 4; // Spécifie le nombre de worker process. Mettre le nombre de coeur CPU que vous possédez si vous ne savez pas quoi mettre.

Puis il faut configurer les blocs http qui correspondent aux virtuals hosts d’APACHE. Pour ce faire, voici un exemple de configuration simple pour répondre au pages web d’un serveur nommé axopen.com. Voilà, vous avez ainsi un petit serveur HTTP basique pour traiter des requêtes avec NGINX.

 

http {
  gzip on;
  server {
    server_name axopen.com;
    listen 80;
     location / {
       try_files $uri $uri/ /index.html;
   }
  }
}

Pour en savoir plus sur NGINX:

L'équipe AXOPEN

Voir aussi les articles suivants

Firewall, GeoIP et IPTables

Firewall, GeoIP et IPTables

Le 04/03/2014 par Pierre Liseron

De plus en plus de serveurs sont attaqués par du flooding HTTP, mettant à genou votre serveur Apache, l’empêchant ainsi de répondre aux vraies requêtes qui lui sont adressées. Il est possible de se battre contre ces requêtes avec fail2ban par exemple ou d’autres solutions, mais contre une attaque de type DDOS ou aucune adresse IP n’est identique entre deux requêtes les efforts sont souvent vains. Le meilleur moyen trouvé pour faire baisser significativement le nombre de flood HTTP est de limité les pays pouvant accéder à votre serveur.
Lire l'article

Architecture applicative web dans un cloud

Architecture applicative web dans un cloud

Le 05/12/2013 par Pierre Liseron

Avec l’arrivée des offres « Private cloud » bon marché, il devient intéressant de virtualiser entièrement ses serveurs et son architecture web. Avec des systèmes de virtualisation comme VMWare et vSphère, il est très facile pour le même prix de créer un grand nombre de machines virtuelles et ainsi de découper au mieux son architecture web pour isoler chaque composante, et apporter robustesse aux différentes instances de services. L’objectif de cet article est donc de faire un retour d’expérience afin de fournir un exemple d’architecture type dans la mise en place et l’exploitation d’une application web.
Lire l'article

JBoss 7 et java.lang.IllegalArgumentException: null source
En développement un écran très complexe dans une de nos applications, nous avons reçu ce type d’erreur, qui nous ont – au début – parues aléatoire. Après de nombreuses recherches, surtout afin de créer un cas de test satisfaisant, nous nous sommes aperçu que le problème se posait à cause d’un trop grand nombre de paramètres POST. Voici l’anomalie qui se produit: java.lang.IllegalArgumentException: null source at java.util.EventObject.<init>(Unknown Source) at javax.faces.event.SystemEvent.<init>(SystemEvent.java:71) at javax.
Lire l'article