Вступ до NGINX для розробників

Уявіть собі це - ви створили веб-програму і зараз шукаєте правильний веб-сервер для розміщення.

Ваша програма може складатися з декількох статичних файлів - HTML, CSS та JavaScript, сервісу серверного API або навіть декількох веб-служб. Використання Nginx може бути саме тим, що ви шукаєте, і на це є кілька причин.

NGINX - потужний веб-сервер, який використовує непотокову архітектуру, керовану подіями, що дозволяє йому перевершити Apache, якщо його правильно налаштовано. Він також може виконувати інші важливі справи, такі як балансування навантаження, HTTP-кешування або бути використаним як зворотний проксі-сервер.

У цій статті я розгляну кілька основних кроків щодо встановлення та налаштування найпоширеніших частин NGINX.

Базова інсталяція - архітектура

Існує два способи встановити NGINX, використовуючи заздалегідь побудований двійковий файл або створюючи його з джерела.

Перший метод набагато найпростіший і швидший, але його створення з джерела надає можливість включати різні сторонні модулі, які роблять NGINX ще потужнішим. Це дозволяє нам налаштувати його відповідно до потреб програми.

Щоб встановити попередньо вбудований пакет Debian, єдине, що вам потрібно зробити, це:

sudo apt-get updatesudo apt-get install nginx

Після завершення процесу встановлення ви можете перевірити, що все в порядку, запустивши команду нижче, яка повинна надрукувати останню версію NGINX.

sudo nginx -vnginx version: nginx/1.6.2

Ваш новий веб-сервер буде встановлений у цьому місці . Якщо зайти в цю папку, ви побачите кілька файлів і папок. Найважливіші, що вимагатимуть нашої уваги згодом, - це файл та папка ./etc/nginx/nginx.confsites-available

Налаштування конфігурації

Основні налаштування NGINX знаходяться у nginx.confфайлі, який за замовчуванням виглядає так.

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

Файл структурований у контексти . Перший - це контекст подій , а другий - контекст http . Ця структура забезпечує деяке розширене шарування вашої конфігурації, оскільки кожен контекст може мати інші вкладені контексти, які успадковують все від своїх батьків, але також можуть замінювати налаштування за потреби.

Різні речі у цьому файлі можна налаштувати залежно від ваших потреб, але NGINX настільки простий у використанні, що ви можете відповідати навіть налаштуванням за замовчуванням. Деякі найважливіші частини конфігураційного файлу NGINX:

  • worker_processes: Цей параметр визначає кількість робочих процесів, які буде використовувати NGINX . Оскільки NGINX є однопоточним, це число зазвичай має дорівнювати кількості ядер процесора.
  • worker_connections: Це максимальна кількість одночасних підключень для кожного робочого процесу і повідомляє нашим робочим процесам, скільки людей може одночасно обслуговувати NGINX. Чим він більший, тим більше одночасних користувачів зможе обслуговувати NGINX.
  • access_log & error_log: Це файли, які NGINX використовуватиме для реєстрації помилок та спроб доступу. Ці журнали, як правило, перевіряються на предмет налагодження та усунення несправностей.
  • gzip: це параметри стиснення відповідей NGINX GZIP. Увімкнення цього разом із різними підналаштуваннями, які за замовчуванням коментуються, призведе до досить великого оновлення продуктивності. З підналаштувань GZIP слід подбати про рівень gzip_comp_level, який є рівнем стиснення і коливається від 1 до 10. Як правило, це значення не повинно бути вище 6 - виграш у плані зменшення розміру незначний, оскільки йому потрібно набагато більше використання процесора. gzip_types - це список типів відповідей, до яких застосовуватиметься стиснення.

Ваша інсталяція NGINX може підтримувати набагато більше, ніж один веб-сайт, а файли, що визначають сайти вашого сервера, знаходяться в каталозі / etc / nginx / sites-available.

Однак файли в цьому каталозі не є "активними" - тут ви можете мати стільки файлів визначення сайту, скільки захочете, але NGINX насправді нічого з ними робити не буде, якщо вони не будуть зв'язані в / etc / nginx / каталог із підтримкою веб-сайтів (ви також можете їх скопіювати туди, але символічне посилання гарантує, що кожен файл має лише одну копію для відстеження).

Це дає вам спосіб швидко перевести веб-сайти в Інтернет і перевести їх в автономний режим без необхідності фактично видаляти будь-які файли - коли ви будете готові до того, що веб-сайт перейде в Інтернет, знайдіть його посилання на сайти з підтримкою та перезапустіть NGINX.

sites-availableКаталог включає в себе конфігурацію для віртуальних хостів. Це дозволяє конфігурувати веб-сервер для декількох сайтів, які мають окремі конфігурації. Сайти в цьому каталозі не працюють, і їх можна активувати, лише якщо ми створимо символічне посилання в sites-enabledпапці.

Або створіть новий файл для своєї програми, або відредагуйте файл за замовчуванням. Типова конфігурація виглядає нижче.

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

Подібно до цього nginx.conf, цей також використовує концепцію вкладених контекстів (і всі вони також вкладені всередину контексту HTTP nginx.conf, тому вони також успадковують від нього).

Сервер контекст визначає конкретний віртуальний сервер для обробки запитів своїх клієнтів. Ви можете мати кілька блоків сервера, і NGINX буде вибирати між ними на основі директив listenand та server_name.

Усередині блоку сервера ми визначаємо кілька контекстів розташування , які використовуються для вирішення способу обробки запитів клієнта. Щоразу, коли надходить запит, NGINX намагатиметься зіставити свій URI з одним із цих визначень розташування та обробляти його відповідно.

Є багато важливих директив, які можна використовувати в контексті розташування, таких як:

  • try_files спробує подати статичний файл, знайдений у папці, яка вказує на кореневу директиву.
  • proxy_pass надішле запит на вказаний проксі-сервер.
  • rewrite перепише вхідний URI на основі регулярного виразу, так що інший блок розташування зможе його обробити.

Вище контекст визначає пул серверів, NGINX через проксі запити к. Після того, як ми створимо вихідний блок і визначимо сервер всередині нього, ми можемо посилатися на нього по імені всередині наших блоків розташування. Крім того, у висхідному контексті може бути призначено багато серверів, щоб NGINX виконував деяку балансування навантаження під час проксірування запитів.

Запустіть NGINX

Після того, як ми закінчили з конфігурацією та перенесли наш веб-додаток у відповідну папку, ми можемо запустити NGINX, використовуючи команду нижче:

sudo service nginx start

Після цього, коли ми щось змінюємо у своїй конфігурації, нам залишається лише перезавантажити це (без простою), використовуючи команду нижче.

service nginx reload

Нарешті, ми можемо перевірити стан NGINX за допомогою команди нижче.

service nginx status

Висновок

Завдяки такій кількості готових функцій, NGINX може стати чудовим способом обслуговувати вашу програму або навіть використовуватись як проксі-сервер HTTP або балансування навантаження для інших веб-серверів. Розуміння того, як NGINX працює та обробляє запити, надасть багато сил для масштабування та збалансування навантаження ваших програм.