Безпечний чекліст розгортання статичного сайту на спільному сервері

Перевірка до будь-яких дій

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

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

systemctl --failed
sudo ss -lntp
sudo nginx -t
sudo ls -l /etc/nginx/sites-enabled/

Зафіксуйте базовий стан для порівняння

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

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

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

Окремий віртуальний хост в окремому файлі

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

Дайте новому хосту власне доменне ім’я й ніколи не додавайте до нього «голу» IP-адресу сервера. Вона зазвичай уже належить сайту, який був першим, і подвійна заявка на неї створює конфлікт, що розв’язується порядком завантаження, а не вашим наміром.

Не додавайте `default_server`

Сервер за замовчуванням відповідає на запити, чий заголовок Host не збігається ні з чим. На спільному сервері ця роль уже належить наявному сайту — байдуже, задана вона свідомо чи просто дісталася блоку, який завантажується першим.

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

Резервна копія перед редагуванням

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

sudo cp -p /etc/nginx/sites-available/example \
  /etc/nginx/sites-available/example.backup-$(date -u +%Y%m%d-%H%M%SZ)

Спершу тест, потім reload — ніколи restart

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

sudo nginx -t && sudo systemctl reload nginx

Reload замінює робочі процеси, поки головний продовжує працювати, а з’єднання завершуються коректно. Restart зупиняє сервер і запускає його знову — це помітний простій для кожного сайту на ньому. Після цього перевірте, що ідентифікатор головного процесу не змінився: це і є доказ, що був саме reload.

А якщо ви змінили лише вміст, а не конфігурацію, reload не потрібен узагалі. Перечитувати нічого.

Окремий сертифікат для окремого імені хоста

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

Спершу зробіть тестовий прогін на staging, переконайтеся, що він успішний, і лише тоді запитуйте справжній сертифікат. Після цього перевірте, що наявний сертифікат недоторканий — порівняння його серійного номера з базовим станом закриває питання.

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

Перевірте новий сайт

Перевіряйте обидва протоколи й сценарії помилок, а не лише щасливий шлях.

• HTTP перенаправляє на HTTPS тим самим шляхом
• сертифікат відповідає імені хоста й перевіряється без помилок
• потрібні сторінки повертають 200 з розумними типами вмісту
• перехід за редиректами десь завершується, без циклу
• неіснуюча адреса повертає справжній 404
• жодна адреса не перенаправляє на інший сайт того самого сервера

Перевірте проєкти, які вже там були

Цей крок найлегше пропустити й найцінніше зберегти. Повторіть кожен базовий вимір і порівняйте.

• контрольні суми конфігурацій не змінилися
• ідентифікатори процесів сервісів не змінилися
• нових юнітів зі збоями немає
• перелік відкритих сокетів не змінився
• наявні сайти повертають ті самі коди статусу й редиректи
• наявні сертифікати не змінилися, за серійним номером

Знайте відкат до того, як він знадобиться

Запишіть точну команду відкату як частину плану. Для зміни конфігурації це відновлення з резервної копії, тест і reload. Для зміни вмісту — повернення symlink на попередній реліз.

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

Не чіпайте те, що не ваше

Найкорисніше правило на спільному сервері — найменш технічне: змінюйте лише те, чого вимагає задача. Не фаєрвол, не DNS, не конфігурацію іншого проєкту, не встановлені пакети й не сертифікат, який створювали не ви.

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