Ось урок, створений спеціально для вас у стилі Гарвардського курсу CS50. Уявіть, що ви сидите в залі Сандерс-театру, а я ходжу сценою, активно жестикулюючи, і розповідаю про магію вебсерверів. Поїхали!

🎓 Урок: Керування Nginx (Запуск, Зупинка, Перезавантаження)

1. 🔥 Вступ: Коли ваш сервер ігнорує вас

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

Але гості скаржаться: "Соус старий! Нічого не змінилося!".

Чому? Ви ж змінили рецепт! Ви натиснули Save!

А проблема в тому, що ваші кухарі (процеси Nginx) не телепати. Вони взяли інструкції зранку, коли прийшли на роботу, і продовжують готувати по-старому, доки ви прямо не скажете їм: "Гей, увага! Читаємо нові інструкції!".

Питання до вас: Як змусити "кухарів" прочитати новий рецепт, не виганяючи всіх клієнтів із ресторану посеред обіду?

Сьогодні ми навчимося бути менеджерами цього ресторану. Без знання того, як перезавантажувати Nginx, ви будете змінювати налаштування сайту, але ніколи не побачите змін. Або, що гірше, "покладете" сайт інтернет-магазину в Чорну п'ятницю, просто щоб оновити колір кнопки.

2. 🧠 Теоретична база (Під капотом)

Давайте зазирнемо під капот. Nginx — це не одна велика програма-моноліт. Це команда.

Master Process (Головний процес): Це "Бос". Він читає конфігурацію і керує працівниками. Він не обслуговує клієнтів напряму.
Worker Processes (Робочі процеси): Це "Кухарі". Саме вони віддають ваші HTML-сторінки, картинки та обробляють запити.

Коли ми керуємо Nginx, ми зазвичай спілкуємося з операційною системою через systemd (менеджер послуг у Linux), використовуючи команду systemctl.

🔑 Ключова відмінність (запам'ятайте це назавжди!):

Ми маємо дві схожі, але кардинально різні команди: Restart та Reload.

🔴 Restart (Перезапуск): Це як вимкнути світло на кухні й увімкнути знову.
- Що відбувається: Всі процеси вбиваються. Всі поточні з'єднання з клієнтами розриваються (користувач побачить помилку). Сервер запускається з нуля.
- Коли треба: Коли Nginx "завис" або ви змінили щось глобальне (наприклад, відкрили новий порт).
🟢 Reload (Перечитати конфігурацію): Це як передати нову записку кухарям, не зупиняючи роботу.
- Що відбувається: Master-процес перевіряє новий конфіг. Якщо все ОК, він запускає нові робочі процеси з новими інструкціями. Старі процеси завершують обслуговувати своїх поточних клієнтів і спокійно йдуть на відпочинок.
- Результат: Нульовий час простою (Zero Downtime). Клієнти навіть не помітять змін.

3. 🧪 Приклади (Command Line Magic)

Припустимо, ви підключені до сервера через термінал.

Приклад 1: "Чи живий він?"

Перш ніж щось робити, перевіримо пульс пацієнта.

sudo systemctl status nginx

Що ви очікуєте побачити? Купу тексту. Але шукайте очима зелений напис active (running). Якщо бачите червоний failed — у нас проблеми, Х'юстоне.

Приклад 2: "М'яке оновлення" (Reload)

Це те, що ви будете робити 99% часу. Ви змінили файл nginx.conf або налаштування сайту.

sudo systemctl reload nginx

Чому це круто? Якщо ви зробили помилку в конфігу (наприклад, забули крапку з комою ;), Nginx при спробі reload часто скаже: "Ей, конфіг битий, я не буду перезавантажуватись, я залишусь на старому робочому!". Він врятує вас від падіння сайту.

Приклад 3: "Жорсткий перезапуск" (Restart)

Ви встановили новий модуль або змінили порти, і reload не допомагає.

sudo systemctl restart nginx

Обережно: У цей момент на мілісекунди (або секунди) ваш сайт стає недоступним.

4. 🛠 Практична частина

Час забруднити руки. Відкрийте термінал (або уявіть його).

🔹 Завдання 1: Перевірка статусу

Введіть команду перевірки статусу. Знайдіть рядок, де написано Process: 1234 (nginx). Запам'ятайте (або запишіть) цей номер (PID) головного процесу.

🔹 Завдання 2: "Зупинись, мить!"

Спробуйте зупинити сервер:

sudo systemctl stop nginx

Тепер спробуйте зайти на ваш сайт через браузер (або curl localhost). Що ви бачите? "Connection refused" або "Site can't be reached". Так і має бути.

🔹 Завдання 3: "Воскресіння"

Запустіть його знову:

sudo systemctl start nginx

Перевірте, чи змінився PID (номер процесу) через команду status. Спойлер: Так, бо це вже новий процес.

🔹 Завдання 4: Тест на уважність (Safety Check)

Це найважливіша команда для новачка. Перш ніж робити reload, зробіть це:

sudo nginx -t

(t означає test). Якщо він пише syntax is ok і test is successful — тільки тоді робіть reload.

🔹 Міні-кейс: "Диверсія"

Відкрийте конфіг (наприклад, /etc/nginx/nginx.conf).
Видаліть одну дужку } або крапку з комою ; випадково.
Збережіть.
Спробуйте виконати sudo nginx -t. Що він каже?
Спробуйте виконати sudo systemctl reload nginx. Чи впав сервер? (Ні, Nginx розумний, він відмовився застосовувати поламаний конфіг).
Виправте помилку назад!

5. 💡 Мислення як у розробника

Як відрізнити новачка від Senior Admin?

Помилка новачка: Новачок змінює конфіг і одразу пише restart. Наслідок: Якщо в конфігу помилка, сервер впаде і не підніметься. Сайт лежить, телефон дзвонить, паніка.

Мислення профі: Профі думає про доступність (uptime). Він діє за алгоритмом: 1. Змінив конфіг. 2. sudo nginx -t (Перевірив синтаксис). 3. Тільки якщо ОК -> sudo systemctl reload nginx (М'яке оновлення). 4. Перевірив логи або відкрив сайт, щоб переконатися.

Порада: Якщо ви працюєте на Linux, створіть собі "аліас" (скорочення). Наприклад, команду nginx_apply, яка сама робить тест і, якщо все добре, робить reload. Автоматизуйте безпеку!

6. 🧩 Підсумок

Отже, що ми сьогодні додали до вашого інструментарію?

Ви розумієте, що Nginx — це менеджер і робочі бджоли.
Ви знаєте, що restart — це молоток (вбиває і піднімає), а reload — це дипломат (домовляється про зміни без зупинки).
Ви вивчили рятівну команду nginx -t.

Тепер ви вмієте керувати життям вашого вебсервера.

Але... зараз наш сервер просто віддає файли. А що, якщо ми хочемо, щоб на одному сервері працювали й facebook.com, і google.com (умовно), і щоб Nginx розумів, кому яку сторінку показувати, маючи лише одну IP-адресу?

Про це — на наступному уроці: Віртуальні хости та Server Blocks.

Це був CS50. Побачимось!