Програмування та комп’ютерне справа – це перспективно, передній край інформаційних технологій, висока кваліфікація фахівців, складні системи і «стабільно зростає» потік обмежень. Прийнято говорити про великі досягнення та чудові перспективи, але мало хто говорить про реальну ситуацію.

Задовго до віртуального хоста або серверного блока «клієнт інтернету» був обмежений діапазоном адресації IPv4. Це вважалося достатнім. У 2011 році IANA розподілила залишилися блоки адрес регіональних реєстраторів і з’явився черговий (ніби як нескінченний) «межа» – IPv6.

Хост, сервер і серверний блок

Кожен веб-сервер в інтернеті має унікальну адресу. Не суть важливо, за протоколом він доступний і до якої адресації він відноситься. Важливо що він один, а реальна потреба має звичку рости. Віртуальні хости, субдомени або кілька доменних імен – нормальне положення речей для одного сервера.

Адреса точки в просторі визначає все, включаючи саму точку. Віртуальний хост – ідея Apache. Самотня точка на сервері – нонсенс, який, можливо, колись існував.

Установка Apache та/або NGiNX – це робота одного веб-ресурсу. Другий ресурс ніколи не відрізняється від першого. Перспективні інформаційні технології, не настільки перспективні, щоб надати унікальність кожного процесу, кожного додатка або веб-ресурсу. Все завжди однотипно і формально працює.

Хост або віртуальний хост – термінологія Apache. Серверний блок – це термін NGiNX. В першому панує «.htaccess», у другому можна регулярним виразом визначити, що і як саме робить серверний блок.

Хост – це точка в інтернет-просторі, хто і як її обслуговує – неважливо. Але важливо, наскільки стабільно, надійно, безпечно і ефективно працює те, що обслуговує конкретний хост.

Традиція: потік обмежень

Сьогодні вже мало хто пам’ятає, скільки проблем пов’язано з числом 640. Забулися проблеми з двома цифрами для позначення року. А адже бар’єр в 640 Кб оперативної пам’яті долався довго і складно, а перехід від 1999 року до 2000-го показав, наскільки обмежені уявлення комп’ютерних фахівців інформації і питання її формалізації в динаміці часу.

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

Сказане відноситься до хостингу в першу чергу. Програмування остаточно перекочувало на веб-сервери і пішло в область розподіленої обробки інформації. Робота над сучасними програмними виробами – це діяльність багатонаціонального колективу фахівців, розподілених по всьому світу.

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

Мудрість або молодість: Apache і NGiNX

Серверів багато в інтернеті. Що лідирує, сказати важко. Можна вірити різним вікіпедіям і компетентним джерел. Але особливого сенсу для такої віри немає. Може бути, що кількома роками раніше панував Apache. Цілком може бути, що сьогодні серверів під NGiNX дійсно більше 24 мільйонів.

На просторах інтернету можна зустріти і Apache, NGiNX, а також IIS, lighttpd, Google Web Server, Resin, Cherokee, Rootage, THTTPD, Open Server і масу самостійних розробок. Який варіант кращий, сказати важко.

Важливо: Apache зіграв свою роль і продовжує дивувати стабільністю роботи, а NGiNX почав кар’єру значно пізніше і (з нуля) пішов далі. «Енджін-Ікс» завоював довіру як надійний веб-сервер нового покоління, заснованого на події та ідеї відділення статики від динаміки.

Apache & NGiNX можуть працювати у зв’язці. Останній може проксировать потік запитів від браузерів і перерозподіляти навантаження, виконувати поштові функції і маніпулювати потоками даних адекватно ситуації, що складається.

NGiNX (вітчизняна розробка Ігоря Сисоєва) молодий, амбітний і має великі плани. Apache «мудрий», що стабільно розвивається і впевнено підтримує багатомільйонну аудиторію веб-ресурсів.

Обидва продукту надають можливість організації віртуальних хостів в будь-якій кількості, але тут знову виникають обмеження: будь-який хост – це «ручна робота», автоматом ні Apache, ні NGiNX нічого ніколи не роблять.

Віртуальний хост

Один веб-сервер – один веб-ресурс. Так не було ніколи, а якщо й було, то давним-давно забулося. Сучасний сервер зобов’язаний утримувати то кількість додаткових хостів, скільки необхідно.

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

Основний хост – це той же IP-адресу, що виділений сервер. Віртуальний хост, підтримуваний цим самим сервером, може обслуговувати кілька IP-адрес, доменних імен або субдоменів (один сервер – безліч сайтів).

Істотний момент: асоціація будь-якого доменного імені з IP-адресою – це компетенція зовнішніх серверів. В основному це система спеціальних ресурсів (DNS), що забезпечують функціонування інтернету.

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

На початковому етапі, коли хост тільки створений, можна отримати помилку: веб-ресурсу немає або він недоступний. Потрібно час, щоб про факт появи нового хоста дізнався, якщо не весь світ, то хоча б ту його частину, що знаходиться поблизу розробника або відвідувача.

Підготовка і установка

Налаштування NGiNX на UBUNTU – це хороше поєднання надійного веб-сервера і відмінною операційної системи. Весь арсенал функцій UBUNTU підтримується компонентами NGiNX, що забезпечує безпечний і стабільний результат.

Можна встановити NGiNX і Apache. Налаштування двох серверів в парі дає широкі можливості. Щоб поставити NGiNX, достатньо однієї команди: “sudo apt-get install nginx”.

Сервер став, можна працювати. Рекомендується перед установкою оновити систему. Кращий варіант – новий сервер робити з нуля, тобто попередньо перевстановити операційну систему.

Ніщо не заважає встановити NGiNX на працюючу машину. Досить зазначеної (apt-get install nginx) команди і веб-сервер готовий до роботи.

Крім команди «service nginx status» можна скористатися командою «systemctl status nginx» – ефект однаковий. Коренева папка, в якій буде розміщуватися на сайті, поки тільки одна.

На цьому завершена базова установка. Налаштування сервера NGiNX і віртуальних хостів доступна.

Брандмауер дозвіл потоків запитів

Діючі профілі NGiNX можна подивитися командою (UBUNTU) “ufw app list”.

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

Відразу після установки дана команда покаже:

• Nginx Full – відкриті порт 80 – http і порт 443 – https.
• Nginx HTTP – доступний стандартний 80 порт.
• Nginx HTTPS – доступний стандартний порт 443 (TLS/SSL).

Командою “ufw allow” можна додати правила. Якщо правило вже діє, система видасть відповідне повідомлення.

Це фундамент NGiNX: настройка і підготовка завершені в цілому. Віртуальні хости – це початок набагато більш складної роботи.

NGiNX: налаштування хостів (серверних блоків)

Відразу після установки конфігурація NGiNX записана в папці /etc/nginx:

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

Активація (активація) нового хоста виконується шляхом створення символічного посилання: ln -s /etc/nginx/sites-available/vhost1 /etc/nginx/sites-enabled/ в папці активних віртуальних хостів.

NGiNX на CentOS

Підготовка до встановлення та налаштування NGiNX на CentOS відрізняються від UBUNTU. Існує думка, що UBUNTU – це надійний, але «робітничо-домашній» варіант сервера у виконанні «server» і «desktop», а CentOS – це сервер великих підприємств. Обидва сервера відмінно зарекомендували себе, але настройки відрізняються.

Тут показано, як був встановлений веб-сервер, і він підтримує один віртуальний хост. Брандмауер був відключений з тим, щоб дозволити вільний потік запитів. Причина в тому, що налаштування NGiNX в CentOS 7 вимагає доступу до портів 80 і 443. Тут це робиться дещо складніше, ніж в UBUNTU, а інформація з цього питання виходить за рамки статті.

Елементарні віртуальні хости NGiNX

Файл конфігурації NGiNX – настройка основного хоста. Знаходиться в папці /etc/nginx/conf.d.

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

Три хвилини роботи – і поруч з вказаною адресою з’явилося ще три папки, які визначають три нових віртуальних хоста: irm2, irm4, irm8, які висять на одній адресі 192.168.1.46 (irm0) і обслуговуються даним сервером.

Природно, не слід забувати:

• про права на папки;
• зміст файли hosts, всіх комп’ютерів, яким будуть доступні віртуальні хости (стосується локальної мережі, а не зовнішнього доступу, коли веб-сервер дивиться в інтернет, там все вирішують сервери DNS);
• обов’язкову перезавантаження NGiNX після змін;
• у файлі конфігурації хоста змінюється не тільки адреса (root), але і ім’я сервера (server_name).

Створення віртуальних хостів – справа не зовсім просте.

Реальні віртуальні хости та обмеження

Фактично NGiNX (установка і настройка) – це не складно. У різних линуксах є свої особливості, але все доступно і зрозуміло.

В реальності веб-сервера доводиться стикатися з кваліфікованим розробником або компетентним замовником.

Управління сервером Apache – це безліч правил файлу «.htaccess». Залежно від використовуваної системи управління сайтом (CMS), в кореневій папці може виявитися файл «.htaccess» з парою десятків правил і ще десяток «.htaccess» буде розкидане по важливим папок для цілей захисту або управління.

Управління сервером NGiNX – це регулярні вирази і значно більш легкі правила. Але в будь-якому випадку тільки практика допоможе створити правильні конфігураційні файли, які будуть працювати і які можна буде легко уточнювати по необхідності.

Ідеально, коли «.htaccess» порожній файл конфігурації віртуального хоста не змінювався (конфіг NGiNX: настройка = застосування). Чим більше записано в конфігурації, тим більше обмежень встановлено спочатку, тим складніше буде перенести, переналаштувати або просто згадати.

Регулярні вирази в логіці NGiNX – прогрес у порівнянні з громіздкими правилами «.htaccess». Наприклад, для NGiNX налаштування https або http простіше і зрозуміліше. Якщо Apache «закручений» на PHP в його класичному режимі роботи, то NGiNX спочатку орієнтований на швидкий варіант «php-fpm». Для NGiNX налаштування SSL – це «рідний» елемент, а не сторонній, потребує додаткової уваги.

В будь-якій реальній ситуації, як в юриспруденції: менше скажеш (напишеш) – менше на себе візьмеш (менше витратиш часу згодом на рішення проблем). Будь-яка конфігурація – це обмеження, чим менше цих обмежень, тим краще! Головне – не Apache або NGiNX і налаштування їх конфігурацій, головне – веб-ресурси, які підтримує сервер.

Реальність і динамічність

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

Менше стіг – менше проблем. Чим більше мов в коді сайту, чим більше записано у файлах конфігурації коментарів, а не правил, тим більше шансів на довге і успішне життя веб-сервера і його віртуальних хостів.