En introduktion til NGINX for udviklere

Forestil dig dette - du har oprettet en webapplikation og søger nu efter den rigtige webserver, som den er vært for.

Din applikation kan bestå af flere statiske filer - HTML, CSS og JavaScript, en backend API-tjeneste eller endda flere webservices. Brug af Nginx kan være det, du leder efter, og der er nogle grunde til det.

NGINX er en stærk webserver og bruger en ikke-gevind, hændelsesdrevet arkitektur, der gør det muligt at overgå Apache, hvis den er konfigureret korrekt. Det kan også gøre andre vigtige ting, såsom belastningsafbalancering, HTTP-caching eller bruges som en omvendt proxy.

I denne artikel vil jeg dække et par grundlæggende trin til, hvordan du installerer og konfigurerer de mest almindelige dele af NGINX.

Grundlæggende installation - Arkitektur

Der er to måder at installere NGINX på, enten ved hjælp af en forudbygget binær eller opbygning fra kilde.

Den første metode er meget nemmest og hurtigere, men at opbygge den fra kilden giver mulighed for at inkludere forskellige tredjepartsmoduler, der gør NGINX endnu mere kraftfuld. Det giver os mulighed for at tilpasse det til applikationens behov.

For at installere en forudbygget Debian-pakke er det eneste du skal gøre:

sudo apt-get updatesudo apt-get install nginx

Når installationen er afsluttet, kan du kontrollere, at alt er OK ved at køre kommandoen nedenfor, som skal udskrive den nyeste version af NGINX.

sudo nginx -vnginx version: nginx/1.6.2

Din nye webserver installeres på stedet . Hvis du går ind i denne mappe, vil du se flere filer og mapper. De vigtigste, der kræver vores opmærksomhed senere, er filen og mappen ./etc/nginx/nginx.confsites-available

Konfigurationsindstillinger

Kerneindstillingerne for NGINX er i nginx.conffilen, som som standard ser sådan ud.

user www-data;worker_processes 4;pid /run/nginx.pid;events { worker_connections 768; # multi_accept on;}http { sendfile on; tcp_nopush on; tcp_nodelay on; keepalive_timeout 65; types_hash_max_size 2048; # server_tokens off; # server_names_hash_bucket_size 64; # server_name_in_redirect off; include /etc/nginx/mime.types; default_type application/octet-stream; access_log /var/log/nginx/access.log; error_log /var/log/nginx/error.log; gzip on; gzip_disable "msie6"; # gzip_vary on; # gzip_proxied any; # gzip_comp_level 6; # gzip_buffers 16 8k; # gzip_http_version 1.1; # gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript; include /etc/nginx/conf.d/*.conf; include /etc/nginx/sites-enabled/*;}

Filen er struktureret i sammenhænge . Den første er begivenhederne Kontekst, og den anden er http Konteksten. Denne struktur muliggør en vis avanceret lagdeling af din konfiguration, da hver kontekst kan have andre indlejrede sammenhænge, ​​der arver alt fra deres forælder, men kan også tilsidesætte en indstilling efter behov.

Forskellige ting i denne fil kan finjusteres ud fra dine behov, men NGINX er så enkel at bruge, at du kan følge med selv med standardindstillingerne. Nogle af de vigtigste dele af NGINX-konfigurationsfilen er:

  • worker_processes: Denne indstilling definerer antallet af arbejdsprocesser, som NGINX vil bruge. Da NGINX har en enkelt gevind, skal dette antal normalt være lig med antallet af CPU-kerner.
  • worker_connections: Dette er det maksimale antal samtidige forbindelser for hver arbejdsproces og fortæller vores arbejdsprocesser, hvor mange mennesker der samtidig kan betjenes af NGINX. Jo større det er, jo flere samtidige brugere kan NGINX tjene.
  • access_log & error_log: Dette er de filer, som NGINX vil bruge til at logge eventuelle fejl og adgangsforsøg. Disse logfiler gennemgås generelt til fejlfinding og fejlfinding.
  • gzip: Dette er indstillingerne for GZIP-komprimering af NGINX-svar. Aktivering af denne sammen med de forskellige underindstillinger, der som standard kommenteres, vil resultere i en ret stor ydeevneopgradering. Fra underindstillingerne til GZIP skal man være opmærksom på gzip_comp_level, som er kompressionsniveauet og varierer fra 1 til 10. Generelt bør denne værdi ikke være over 6 - gevinsten med hensyn til størrelsesreduktion er ubetydelig, da det har brug for meget mere CPU-brug. gzip_types er en liste over svarstyper, som komprimering vil blive anvendt på.

Din NGINX-installation kan understøtte langt mere end et enkelt websted, og de filer, der definerer din servers websteder, lever i mappen / etc / nginx / sites.

Filerne i denne mappe er dog ikke "live" - ​​du kan have så mange webstedsdefinitionsfiler herinde, som du vil, men NGINX gør faktisk ikke noget med dem, medmindre de er sammenkædet til / etc / nginx / webstedsbaseret bibliotek (du kan også kopiere dem der, men symlinking sikrer, at der kun er en kopi af hver fil at holde styr på).

Dette giver dig en metode til hurtigt at sætte websteder online og tage dem offline uden at skulle slette filer - når du er klar til et websted til at gå online, skal du linke det sammen til websteder-aktiveret og genstarte NGINX.

Den sites-availablemappe indeholder konfigurationer for virtuelle værter. Dette gør det muligt at konfigurere webserveren til flere websteder, der har separate konfigurationer. Webstederne i denne mappe er ikke live og er kun aktiveret, hvis vi opretter et symbolsk link til sites-enabledmappen.

Enten opret en ny fil til dit program, eller rediger standardfil. En typisk konfiguration ligner nedenstående.

upstream remoteApplicationServer { server 10.10.10.10;}upstream remoteAPIServer { server 20.20.20.20; server 20.20.20.21; server 20.20.20.22; server 20.20.20.23;}server { listen 80; server_name www.customapp.com customapp.com root /var/www/html; index index.html location / { alias /var/www/html/customapp/; try_files $uri $uri/ =404; } location /remoteapp { proxy_set_header Host $host:$server_port; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_pass //remoteAPIServer/; } location /api/v1/ { proxy_pass //remoteAPIServer/api/v1/; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection 'upgrade'; proxy_set_header Host $host; proxy_cache_bypass $http_upgrade; proxy_redirect // //; }}

I lighed med den nginx.confbruger denne også begrebet indlejrede sammenhænge (og alle disse er også indlejret i HTTP- konteksten af ​​nginx.conf, så de arver også alt fra det).

Den server kontekst definerer en specifik virtuel server til at håndtere dine kunders anmodninger. Du kan have flere serverblokke, og NGINX vælger mellem dem baseret på listenog server_namedirektiverne.

Inde i en serverblok definerer vi flere placeringskontekster , der bruges til at beslutte, hvordan klientanmodningerne skal håndteres. Hver gang en anmodning kommer ind, vil NGINX forsøge at matche sin URI til en af ​​disse placeringsdefinitioner og håndtere den i overensstemmelse hermed.

Der er mange vigtige direktiver, der kan bruges under placeringskonteksten, såsom:

  • try_files vil forsøge at servere en statisk fil, der findes under mappen, der peger på roddirektivet .
  • proxy_pass sender anmodningen til en specificeret proxxy-server.
  • omskrivning vil omskrive den indgående URI baseret på et regulært udtryk, så en anden placeringsblok er i stand til at håndtere den.

Den opstrøms kontekst definerer en pulje af servere, Nginx vilje proxy anmodninger til. Når vi har oprettet en opstrømsblok og defineret en server inde i den, kan vi derefter henvise til den ved navn inde i vores placeringsblokke. Desuden kan en upstream-kontekst have mange servere tildelt under den, så NGINX vil gøre noget belastningsafbalancering, når de proxyer anmodningerne.

Start NGINX

Når vi er færdige med konfigurationen, og vi har flyttet vores webapplikation til den relevante mappe, kan vi starte NGINX ved hjælp af nedenstående kommando:

sudo service nginx start

Derefter, når vi ændrer noget på vores konfiguration, behøver vi kun at genindlæse det (uden nedetid) ved hjælp af kommandoen nedenfor.

service nginx reload

Endelig kan vi kontrollere NGINXs status ved hjælp af kommandoen nedenfor.

service nginx status

Konklusion

Med så mange funktioner ude af boksen kan NGINX være en fantastisk måde at betjene din applikation på eller endda bruges som en HTTP-proxy eller load balancer til dine andre webservere. Forståelsen af, hvordan NGINX fungerer og håndterer anmodninger, giver stor styrke til at skalere og afbalancere belastningen på dine applikationer.