Заощадьте 15% на всіх хостингових послугах

Перевірте свої навички і отримайте Знижку на будь-який план хостингу

Використовуй код: Skills Почати
Рубрики
Linux Адміністрація

Sites-Enabled та Sites-Available: Повний посібник для NGINX та Apache

NGINX та Apache залишаються двома найбільш домінуючими веб-серверами в Інтернеті — і не без причини. Обидва є перевіреними в бою, дуже конфігурованими та здатними обслуговувати складні веб-сайти з високим трафіком з легкістю. Одна з найважливіших концепцій для будь-якого системного адміністратора, який керує сервером на базі Linux, — це розуміння того, як ці веб-сервери обробляють конфігурацію веб-сайту через структуру каталогів sites-available та sites-enabled.

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

Цей посібник надає комплексний покроковий опис того, як увімкнути, вимкнути та керувати веб-сайтами за допомогою NGINX та Apache на системах Linux.

Розуміння sites-available та sites-enabled

Як NGINX, так і Apache використовують двохдиректорійну модель для розділення конфігурації сайту від активації сайту. Цей архітектурний паттерн елегантний у своїй простоті та надзвичайно потужний на практиці.

sites-available

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

sites-enabled

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

Це розділення пропонує кілька ключових переваг:

  • Неруйнівне відключення: Ви можете деактивувати сайт без видалення його конфігурації.
  • Швидке розгортання: Підготування нового сайту настільки ж просто, як створення симлінка.
  • Чиста організація: Усі конфігурації існують в одному місці, незалежно від того, активні вони чи ні.

Управління веб-сайтами за допомогою Apache

1. Конфігурація віртуальних хостів Apache

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

Файли конфігурації для віртуальних хостів Apache зберігаються в:

/etc/apache2/sites-available/

Створення файлу конфігурації віртуального хоста

Щоб створити файл конфігурації для сайту під назвою test.oo.md, виконайте:

sudo nano /etc/apache2/sites-available/test.oo.md.conf

Всередині файлу визначте блок віртуального хоста:

<VirtualHost *:80>
    ServerAdmin admin@test.oo.md
    ServerName your_domain_or_IP
    ServerAlias www.test.oo.md
    DocumentRoot /var/www/test.oo.md

    ErrorLog ${APACHE_LOG_DIR}/error.log
    CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

> Примітка: Замініть your_domain_or_IP на вашу фактичну назву домену або IP-адресу сервера. Директива ServerAlias дозволяє Apache відповідати на поддомен www також.

Збережіть та закрийте файл, коли закінчите.

2. Активуйте сайт за допомогою a2ensite

Після того як файл конфігурації на місці, активуйте сайт за допомогою команди a2ensite (Apache 2 Enable Site):

sudo a2ensite test.oo.md.conf

Ця команда автоматично створює символічне посилання з sites-available на sites-enabled:

/etc/apache2/sites-enabled/test.oo.md.conf -> /etc/apache2/sites-available/test.oo.md.conf

Сайт тепер готовий до обслуговування, але зміни не вступлять в силу, поки Apache не буде перезавантажено.

3. Перевірте конфігурацію Apache

Перед перезавантаженням Apache завжди перевіряйте синтаксис конфігурації, щоб виявити будь-які помилки:

sudo apachectl configtest

Успішний результат буде показувати:

Syntax OK

Якщо є помилки, Apache опише проблему та номер рядка — виправте їх перед продовженням.

4. Перезавантажте Apache, щоб застосувати зміни

sudo systemctl reload apache2

Використання reload замість restart є кращим у виробничих середовищах, оскільки застосовує нову конфігурацію без розривання активних з’єднань.

5. Деактивуйте сайт за допомогою a2dissite

Щоб взяти сайт в офлайн без видалення його конфігурації, використовуйте команду a2dissite:

sudo a2dissite test.oo.md.conf

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

sudo systemctl reload apache2

Управління веб-сайтами за допомогою NGINX

1. Конфігурація блоку сервера NGINX

NGINX використовує Server Blocks — функціональний еквівалент Apache Virtual Hosts. Файли конфігурації блоку сервера зберігаються в:

/etc/nginx/sites-available/

Створення файлу конфігурації блоку сервера

Щоб створити файл конфігурації для test.oo.md, виконайте:

sudo nano /etc/nginx/sites-available/test.oo.md

Визначте ваш блок сервера всередині файлу:

server {
    listen 80;
    server_name test.oo.md www.test.oo.md;

    root /var/www/test.oo.md;
    index index.html index.htm;

    access_log /var/log/nginx/test.oo.md_access.log;
    error_log  /var/log/nginx/test.oo.md_error.log;

    location / {
        try_files $uri $uri/ =404;
    }
}

> Пояснення ключових директив:

> – listen 80 — Вказує NGINX прослуховувати HTTP-трафік на порту 80.

> – server_name — Визначає, на які імена доменів цей блок відповідає.

> – root — Встановлює каталог кореня документів для файлів сайту.

> – try_files — Намагається подати запитаний файл або каталог; повертає 404, якщо не знайдено.

2. Увімкніть сайт, створивши символічне посилання

На відміну від Apache, NGINX не надає вбудовану команду на кшталт a2ensite. Натомість ви вручну створюєте символічне посилання:

sudo ln -s /etc/nginx/sites-available/test.oo.md /etc/nginx/sites-enabled/

Це пов’язує файл конфігурації з каталогом sites-enabled, що дозволяє NGINX завантажити його.

3. Перевірте конфігурацію NGINX

Завжди перевіряйте конфігурацію NGINX перед перезавантаженням:

sudo nginx -t

Успішна перевірка повертає:

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Якщо повідомлені помилки, перегляньте зазначені рядки у файлі конфігурації та виправте їх перед продовженням.

4. Перезавантажте NGINX, щоб застосувати зміни

sudo systemctl reload nginx

Як і з Apache, reload плавно застосовує зміни конфігурації без переривання активних з’єднань — завжди переважніше за повне restart у живих середовищах.

5. Вимкніть сайт у NGINX

Щоб вимкнути сайт, видаліть його символічне посилання з каталогу sites-enabled:

sudo rm /etc/nginx/sites-enabled/test.oo.md

Потім перезавантажте NGINX, щоб застосувати зміну:

sudo systemctl reload nginx

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

Швидкий довідник: управління сайтами Apache та NGINX

ЗавданняКоманда ApacheКоманда NGINX
Створити файл конфігураціїnano /etc/apache2/sites-available/site.confnano /etc/nginx/sites-available/site
Увімкнути сайтsudo a2ensite site.confsudo ln -s /etc/nginx/sites-available/site /etc/nginx/sites-enabled/
Перевірити конфігураціюsudo apachectl configtestsudo nginx -t
Перезавантажити веб-серверsudo systemctl reload apache2sudo systemctl reload nginx
Вимкнути сайтsudo a2dissite site.confsudo rm /etc/nginx/sites-enabled/site

Найкращі практики управління сайтами за допомогою NGINX та Apache

1. Один файл конфігурації на сайт

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

2. Завжди тестуйте перед перезавантаженням

Зробіть невід’ємною звичкою запускати apachectl configtest або nginx -t перед кожним перезавантаженням. Синтаксична помилка у файлі конфігурації може вивести з ладу всі сайти на сервері — не тільки той, який ви редагуєте.

3. Використовуйте контроль версій для файлів конфігурації

Для серверів, які розміщують кілька сайтів або мають складні конфігурації, відстежуйте ваші файли конфігурації за допомогою Git:

cd /etc/nginx/sites-available/
git init
git add .
git commit -m "Initial configuration snapshot"

Це дає вам повну історію змін та можливість миттєво повернутися до відомого робочого стану.

4. Завжди примусово використовуйте HTTPS з SSL сертифікатами

Обслуговування сайтів через простий HTTP більше неприйнятне. Налаштуйте SSL сертифікати для кожного сайту, яким ви керуєте. Let’s Encrypt надає безплатні, автоматично поновлювані сертифікати та безперебійно інтегрується як з Apache (через mod_ssl та Certbot), так і з NGINX.

Після отримання сертифіката оновіть блок сервера або віртуальний хост, щоб прослуховувати порт 443 та перенаправляти весь трафік HTTP на HTTPS.

5. Налаштуйте комплексне логування

Завжди визначайте директиви access_log та error_log для кожного сайту. Логи — ваша перша лінія захисту при діагностиці проблем, розслідуванні інцидентів безпеки або аналізі шаблонів трафіку. Зберігайте логи у файлах, специфічних для сайту, замість того, щоб покладатися на глобальний журнал за замовчуванням.

6. Використовуйте описові, послідовні імена файлів

Назвіть ваші файли конфігурації за доменом, який вони обслуговують (наприклад, example.com.conf для Apache, example.com для NGINX). Це робить очевидним, який файл відповідає якому сайту при управлінні сервером з багатьма віртуальними хостами.

Вибір правильного хостинг-середовища

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

  • Спільний веб-хостинг — Ідеальний варіант для початківців або невеликих сайтів, де конфігурація сервера керується для вас. NGINX або Apache попередньо налаштовані, і ви взаємодієте з сайтами через панель керування.
  • VPS Hosting — Оптимальний варіант для розробників та системних адміністраторів, які потребують повного доступу root для налаштування NGINX або Apache точно так, як описано в цьому посібнику. У вас є повний контроль над sites-available, sites-enabled та кожним іншим аспектом сервера.
  • Виділені сервери — Найкращий варіант для сайтів з високим трафіком або додатків, що потребують максимальної продуктивності та ізоляції. Ви керуєте всім сервером, включаючи конфігурацію веб-сервера, без спільного використання ресурсів.
  • VPS з cPanel — Поєднує потужність VPS з графічною панеллю керування, роблячи управління віртуальними хостами доступним без глибоких знань командного рядка.

Висновок

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

Для підсумування ключових моментів:

  • sites-available зберігає всі файли конфігурації; sites-enabled містить лише активні символічні посилання.
  • Apache використовує a2ensite та a2dissite для оптимізованого управління сайтами.
  • NGINX покладається на ручне створення та видалення символічних посилань через ln -s та rm.
  • Завжди тестуйте вашу конфігурацію (apachectl configtest або nginx -t) перед перезавантаженням.
  • Перезавантажуйте — не перезапускайте — щоб застосувати зміни без розриву активних з’єднань.
  • Примусьте HTTPS на кожному сайті, використовуючи SSL Сертифікати.

Незалежно від того, керуєте ви особистим проектом чи флотом виробничих веб-сайтів, ці основи послужать фундаментом стабільного, добре організованого середовища веб-сервера. Якщо ви шукаєте надійну платформу для практики цих навичок, дослідіть плани VPS Хостингу AlexHost — спеціально розроблені для розробників та адміністраторів, які вимагають повного контролю над своїм серверним середовищем.