Cet article apparaît également sur le blog de NGINX. Lire sur NGINX>
Traditionnellement, le développement et l'hébergement Web se faisaient principalement à l'aide de la pile LAMP - LAMP étant l'abréviation de L inux (système d'exploitation), A pache (serveur Web), M ySQL (base de données) et P HP (langage de programmation), les composants de base qui ont ensuite été utilisés pour exécuter les sites d'entreprise.
Alors que les piles Web et les équilibreurs de charge deviennent plus agiles, et que les besoins de l'entreprise imposent de meilleures performances et stabilité, il devient de plus en plus courant de remplacer Apache HTTP Server par une alternative légère et hautement évolutive, NGINX. Avec NGINX, la pile devient connue sous le nom de LEMP – L inux, (e )NGINX, M ySQL, P HP.
Atlantic.Net propose une gamme de solutions comprenant des services de stockage, d'hébergement et de gestion. Notre plate-forme d'hébergement VPS dispose d'une option LEMP en un clic qui permet à votre pile d'être opérationnelle en moins de 30 secondes. Pour ceux qui préfèrent exécuter NGINX à partir de Docker, nous avons des serveurs cloud Linux et Windows avec Docker. Nous fournissons également des services gérés pour ceux qui souhaitent ou ont besoin d'aide pour configurer NGINX.
Nous utilisons NGINX de manière fréquente et robuste, non seulement en tant que serveur Web, mais également en tant que proxy inverse et équilibreur de charge. Nous avons décidé d'utiliser NGINX après avoir recherché des solutions d'équilibrage de charge pour notre cluster de journalisation centralisé. En utilisant NGINX dans diverses capacités, nous obtenons une haute disponibilité pour nos serveurs frontaux et principaux, tout en conservant un encombrement extrêmement réduit, tout cela grâce à l'efficacité de NGINX en termes d'utilisation de la RAM et du processeur.
En ce qui concerne les fonctions spécifiques de NGINX les plus utiles, certaines que nous trouvons particulièrement puissantes sont le proxy TCP/UDP et l'équilibrage de charge, le contrôle d'accès et les poignées de main SSL à trois voies. Dans cet article de blog, je décrirai comment nous utilisons chacune de ces fonctionnalités.
Équilibrage de charge de notre journalisation centralisée avec les flux NGINX
Étant donné que la nécessité de fournir une journalisation pour l'audit et la sécurité est devenue une priorité, nous, chez Atlantic.Net, recherchions la bonne solution de proxy et d'équilibrage de charge, non seulement pour le trafic HTTP, mais aussi pour syslog. Syslog est généralement envoyé au format UDP (User Datagram Protocol), nous avions donc besoin de quelque chose qui gère UDP ainsi que HTTP.
C'est ici que le stream NGINX modules sont entrés en jeu, car ils permettent l'équilibrage de charge du trafic UDP. L'équilibrage de charge utilise un certain nombre de serveurs principaux pour une distribution efficace du trafic réseau. Comme le terme l'indique, le but est de répartir uniformément la charge de travail.
Dans l'extrait de code suivant, nous envoyons des messages syslog depuis notre infrastructure réseau vers notre backend de journalisation :
...
stream {
upstream networking_udp {
least_conn;
server 198.51.100.100:5910;
server 198.51.100.101:5910;
server 198.51.100.102:5910;
}
server {
listen 5910 udp;
proxy_timeout 0s;
proxy_bind $remote_addr transparent;
proxy_pass networking_udp;
}
}
... Les flux fonctionnent également bien pour SSL sur TCP, comme le montre l'exemple suivant qui envoie les journaux Filebeat en toute sécurité :
...
upstream filebeat_tcp {
least_conn;
server 198.51.100.100:5910;
server 198.51.100.101:5910;
server 198.51.100.102:5910;
}
server {
listen 5910 ssl;
ssl_certificate /etc/nginx/ssl/certs/cert.pem;
ssl_certificate_key /etc/nginx/ssl/private/priv-key.pem;
ssl_protocols TLSv1.2;
ssl_ciphers HIGH:!aNULL:!MD5;
ssl_session_cache shared:SSL:20m;
ssl_session_timeout 4h;
ssl_handshake_timeout 30s;
proxy_pass filebeat_tcp;
proxy_ssl on;
proxy_ssl_certificate /etc/nginx/ssl/certs/cert.pem;
proxy_ssl_certificate_key /etc/nginx/ssl/private/priv-key.pem;
proxy_ssl_protocols TLSv1.2;
proxy_ssl_session_reuse on;
proxy_ssl_ciphers HIGH:!aNULL:!MD5;
proxy_ssl_trusted_certificate /etc/nginx/ssl/certs/ca.pem;
}
... Comme vous pouvez le constater, NGINX est capable de proxy et d'équilibrage de charge du trafic UDP et TCP (Transmission Control Protocol).
L'utilisation de proxys inverses et d'équilibrage de charge est utile lorsque vous disposez d'un service, d'une base de données ou d'un programme qui communique via UDP ou TCP. À la base, ces méthodes sont pertinentes lorsque vous avez le même service, base de données ou instance de programme en cours d'exécution sur plusieurs serveurs en amont, tels qu'ils sont gérés par NGINX. Chez Atlantic.Net, nous profitons également du proxy inverse de NGINX, car il fournit une couche supplémentaire d'obscurcissement à nos services backend critiques, avec très peu de frais généraux.
Contrôle d'accès
Une autre étape importante pour sécuriser notre journalisation centralisée consistait à empêcher la suppression de toutes les données. De plus, les listes de contrôle d'accès (ACL) sont très utiles pour limiter le trafic en fonction de l'adresse IP. Pour nos besoins, nous voulions autoriser l'accès aux données de journal uniquement à partir de notre réseau de gestion interne.
NGINX nous permet de délimiter très précisément les types d'actions HTTP pouvant être effectuées et d'où, comme on peut le voir ici :
...
server {
listen 9200;
client_max_body_size 20M;
location / {
limit_except GET POST PUT OPTIONS {
deny all;
}
allow 198.51.100.0/24;
deny all;
proxy_pass http://elasticsearch_backend;
}
location ~* ^(/_cluster|/_nodes|/_shutdown) {
allow 198.51.100.0/24;
deny all;
proxy_pass http://elasticsearch_backend;
}
}
... NGINX prend également en charge une fonctionnalité IP transparente qui nous permet de voir l'adresse IP d'origine une fois que la requête a traversé le proxy. Cette fonctionnalité permet de suivre l'origine des journaux. NGINX rend cette tâche très simple :
...
server {
listen 5915 udp;
proxy_timeout 0s;
proxy_bind $remote_addr transparent;
proxy_pass vmware_udp;
}
... Positions de contact SSL à trois voies
NGINX gère proprement les deux côtés des transferts SSL pour notre journalisation centralisée. Cette implémentation est très importante, car elle signifie que les serveurs internes et clients peuvent communiquer en toute sécurité avec NGINX. Chaque serveur connecté dispose de son propre certificat pour la communication SSL bidirectionnelle, ce qui réduit encore les vulnérabilités. NGINX transmet ensuite les données en toute sécurité sur notre réseau interne, via SSL, aux serveurs de journalisation. Au total, trois certificats SSL sont impliqués pour chaque communication de bout en bout qui prend en charge la transmission sécurisée. (Consultez le deuxième extrait de configuration dans Équilibrage de la charge de notre journalisation centralisée avec les flux NGINX pour notre configuration SSL à trois voies préférée).
Perspectives et tests de NGINX
Diverses personnes et organisations ont fait l'éloge de NGINX au fil des ans, et nous avons bénéficié des mêmes avantages supplémentaires de NGINX qu'ils mentionnent.
L'ingénieur logiciel Chris Lea de NodeSource compare Apache à Microsoft Word, notant que les deux applications ont un nombre absurdement élevé de fonctionnalités, mais que seules quelques-unes sont généralement nécessaires. Lea préfère NGINX car il possède les fonctionnalités dont vous avez besoin, sans encombrement et avec de bien meilleures performances.
Selon Thomas Gieselman de la société de capital-risque BV Capital, quelques-unes des organisations qu'elles ont financées ont résolu des problèmes liés à la mise à l'échelle en changeant leur serveur pour NGINX. Gieselman considère que NGINX rend la croissance rapide plus simple et accessible à un plus grand nombre d'organisations.
Linux Journal a effectué un test simple à l'aide du logiciel de référence Apache, ab , pour comparer Apache à NGINX (versions 2.2.8 et 0.5.22, respectivement). Les programmes top et vmstat ont été utilisés pour vérifier les performances du système pendant que les deux serveurs fonctionnaient simultanément.
Le test a montré que NGINX était plus rapide qu'Apache en tant que serveur de contenu statique. Les deux serveurs fonctionnaient chacun de manière optimale, avec une simultanéité définie sur 100. Afin de traiter 6 500 requêtes par seconde, Apache a utilisé 17 Mo de mémoire, 30 % de processeur et 4 processus de travail (en mode threadé). Pour répondre à un rythme beaucoup plus rapide de 11 500 requêtes par seconde, NGINX n'avait besoin que de 1 Mo de mémoire, 15 % de processeur et 1 worker.
Bob Ippolito a fondé la plate-forme de jeu Mochi Media, qui comptait 140 millions d'utilisateurs uniques par mois à son apogée. Il comprend donc bien la demande de hautes performances. Ippolito a déclaré en 2006 qu'il avait effectué un test dans lequel il utilisait NGINX comme proxy inverse pour des dizaines de millions de requêtes HTTP par jour (c'est-à-dire quelques centaines par seconde) sur un serveur.
Lorsque le serveur NGINX était à pleine capacité, il consommait environ 10 % de processeur et 15 Mo de mémoire sur sa configuration, qui était FreeBSD (un système d'exploitation open source basé sur UNIX). En utilisant les mêmes paramètres, Apache a généré 1 000 processus et englouti une énorme quantité de RAM. Pound a créé un nombre excessif de threads et a utilisé plus de 400 Mo pour les différentes piles de threads. Légèrement besoin de plus de processeur et fuite de plus de 20 Mo par heure.
Essayez Atlantic.Net avec NGINX
Chez Atlantic.Net, nous avons trouvé des gains de performances similaires avec NGINX, comme décrit par ces différentes parties. Nous avons également bénéficié des spécificités décrites ci-dessus. Si vous utilisez actuellement Apache ou un autre serveur Web, vous voudrez peut-être essayer NGINX, pour voir si vous obtenez des améliorations similaires qui peuvent vous aider à mieux gérer l'évolutivité et le besoin toujours croissant de vitesse. Testez NGINX avec un serveur cloud dès aujourd'hui.