Bevezetés az NGINX fejlesztőknek

Képeld ezt: létrehoztál egy webalkalmazást, és most keresed a megfelelő webkiszolgálót, ahonnan azt tárolhatod.

Alkalmazása több statikus fájlból állhat - HTML, CSS és JavaScript, háttér-API-szolgáltatásból vagy akár több webszolgáltatásból. A Nginx használata lehet az, amit keres, és ennek pár oka van.

Az NGINX egy erőteljes webszerver, amely nem szálas, eseményvezérelt architektúrát használ, amely lehetővé teszi az Apache jobb teljesítményét, ha helyesen van beállítva. Más fontos dolgokat is megtehet, például terheléselosztás, HTTP gyorsítótárazás, vagy fordított proxyként használható.

Ebben a cikkben néhány alapvető lépést ismertetek az NGINX leggyakoribb részeinek telepítésével és konfigurálásával kapcsolatban.

Alapszerelés - építészet

Az NGINX telepítésének két módja van, vagy előre elkészített bináris fájl használatával, vagy forrásból építve.

Az első módszer sokkal egyszerűbb és gyorsabb, de a forrásból történő felépítés lehetővé teszi különféle külső modulok beépítését, amelyek még erőteljesebbé teszik az NGINX-et. Ez lehetővé teszi számunkra, hogy testre szabjuk, hogy megfeleljen az alkalmazás igényeinek.

Egy előre telepített Debian csomag telepítéséhez csak annyit kell tennie:

sudo apt-get updatesudo apt-get install nginx

A telepítés befejezése után ellenőrizheti, hogy minden rendben van-e az alábbi parancs futtatásával, amelynek ki kell nyomtatnia az NGINX legújabb verzióját.

sudo nginx -vnginx version: nginx/1.6.2

Az új webszerver telepítve lesz a helyszínre . Ha belép a mappába, több fájlt és mappát fog látni. A legfontosabbak, amelyekre később figyelmet kell fordítani, a fájl és a mappa ./etc/nginx/nginx.confsites-available

Konfigurációs beállítások

Az NGINX alapvető beállításai a fájlban vannak nginx.conf, amely alapértelmezés szerint így néz ki.

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/*;}

A fájl összefüggésekbe van strukturálva . Az első az események kontextusa, a második pedig a http kontextus. Ez a struktúra lehetővé teszi a konfiguráció bizonyos fokozott rétegzését, mivel minden kontextusnak lehetnek más beágyazott összefüggései, amelyek mindent örökölnek a szülőktől, de szükség szerint felül is írhatnak egy beállítást.

Ebben a fájlban különféle dolgokat lehet módosítani az Ön igényei alapján, de az NGINX használata olyan egyszerű, hogy az alapértelmezett beállításokkal is együtt járhat. Az NGINX config fájl legfontosabb darabjai a következők:

  • worker_processes: Ez a beállítás meghatározza az NGINX által alkalmazott munkavállalói folyamatok számát. Mivel az NGINX egyszálú, ennek a számnak általában meg kell egyeznie a CPU magok számával.
  • worker_connections: Ez az egyidejű kapcsolatok maximális száma az egyes munkásfolyamatoknál, és megmondja a munkásfolyamatainknak, hogy hány embert tud egyszerre kiszolgálni az NGINX. Minél nagyobb, annál több egyidejű felhasználót tud majd kiszolgálni az NGINX.
  • access_log & error_log: Ezeket a fájlokat használja az NGINX az errók és a hozzáférési kísérletek naplózásához. Ezeket a naplókat általában hibakeresés és hibaelhárítás céljából ellenőrizzük.
  • gzip: Ezek az NGINX válaszok GZIP tömörítésének beállításai. Ennek engedélyezése a különféle albeállításokkal, amelyeket alapértelmezés szerint kommentálnak, meglehetősen nagy teljesítményfrissítést eredményez. A GZIP albeállításaiból figyelni kell a gzip_comp_level értékre, amely a tömörítés szintje és 1 és 10 között mozog. Általában ez az érték nem lehet nagyobb 6 felett - a méretcsökkentés szempontjából a nyereség jelentéktelen, mivel sokkal több CPU-használatra van szüksége. A gzip_types egy olyan választípusok listája, amelyekre a tömörítést alkalmazzák.

Az NGINX telepítése sokkal többet támogat, mint egy webhely, és a kiszolgáló webhelyeit meghatározó fájlok az / etc / nginx / sites-available könyvtárban élnek.

Azonban az ebben a könyvtárban található fájlok nem „élő” - annyi webhelydefiníciós fájl lehet itt, amennyit csak akar, de az NGINX valójában nem csinál velük semmit, hacsak nincsenek összekapcsolva az / etc / nginx / helyekkel engedélyezett könyvtár (másolhatja őket is oda, de a szimlinkelés biztosítja, hogy minden fájlból csak egy példány legyen nyomon követhető).

Ez egy módszert kínál a weboldalak gyors online elérésére és offline állapotba hozatalára, anélkül, hogy valóban törölnie kellene fájlokat - amikor készen áll arra, hogy egy webhely online állapotba lépjen, kapcsolja össze a webhelyeket támogató helyekkel, és indítsa újra az NGINX-t.

A sites-availablekönyvtár tartalmazza a virtuális gépek konfigurációit. Ez lehetővé teszi a webkiszolgáló konfigurálását több, külön konfigurációval rendelkező webhely számára. Az ebben a könyvtárban található webhelyek nem aktívak, és csak akkor engedélyezettek, ha szimbolikus linket hozunk létre a sites-enabledmappába.

Vagy hozzon létre egy új fájlt az alkalmazásához, vagy szerkessze az alapértelmezettet. Egy tipikus konfiguráció úgy néz ki, mint az alábbiakban.

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 // //; }}

Hasonlóan nginx.confehhez, ez is a beágyazott összefüggések fogalmát használja (és mindezek az nginx.conf HTTP kontextusában is be vannak ágyazva, tehát mindent örökölnek is tőle).

A kiszolgálói környezet meghatároz egy adott virtuális kiszolgálót az ügyfelek kéréseinek kezelésére. Több kiszolgálóblokkja lehet, és az NGINX a listenés server_nameirányelvek alapján választani fog közülük .

A kiszolgálóblokkban több helykontextust határozunk meg, amelyek alapján eldönthető az ügyfélkérelmek kezelése. Amikor egy kérés bejön, az NGINX megpróbálja összehangolni URI-ját a helymeghatározások egyikével, és ennek megfelelően kezeli.

Számos fontos irányelv alkalmazható a helykontextusban, például:

  • A try_files megpróbál egy statikus fájlt kiszolgálni a mappa alatt, amely a root irányelvre mutat.
  • A proxy_pass elküldi a kérést egy megadott proxykiszolgálóra .
  • az rewrite átírja a bejövő URI-t egy reguláris kifejezés alapján, hogy egy másik helyblokk képes legyen kezelni.

Az upstream kontextus olyan kiszolgálók készletét definiálja, amelyekhez az NGINX proxy-t küld a kéréseknek. Miután létrehoztunk egy upstream blokkot és definiáltunk benne egy szervert, akkor név szerint hivatkozhatunk rá a helyblokkjainkban. Ezenkívül egy upstream kontextusban sok szerver lehet hozzárendelve, így az NGINX némi terheléselosztást végez a kérések proxyként.

Indítsa el az NGINX-et

Miután befejeztük a konfigurációt és áthelyeztük webalkalmazásunkat a megfelelő mappába, elindíthatjuk az NGINX-et az alábbi paranccsal:

sudo service nginx start

Ezt követően, valahányszor megváltoztatunk valamit a konfigurációnkon, csak az alábbi paranccsal kell újra feltölteni (leállás nélkül).

service nginx reload

Végül az alábbi paranccsal ellenőrizhetjük az NGINX állapotát.

service nginx status

Következtetés

With so many features out of the box, NGINX can be a great way to serve your application or even be used as a HTTP proxy or load balancer for your other web servers. Understanding the way NGINX works and handles requests will give a lot of power to scaling and balancing the load of your applications.