Розгортання на власному сервері означає надання агенту доступу, подібного до SSH, до машини, за яку ви платите, і на якій можуть вже жити інші речі. Це інший рівень довіри, ніж публікація на безкоштовному піддомені, і налаштування це відображає — кілька полів, заповнених один раз, а потім кожна наступна збірка — це просто кнопка. Ось що люди насправді запитують до і після того, як налаштовують таку ціль.
Що мені потрібно для створення цілі?
П'ять речей у Налаштування → Розгортання:
- Назва, яку ви впізнаєте пізніше — "prod-vps", "client-hostgator", будь-що, що переживе випадаючий список об 11 вечора
- Хост і порт
- Облікові дані SFTP
- Шлях до кореня сайту (webroot)
Жодних API-токенів, жодного CLI для встановлення на сервері, жодного cron-завдання, за яким треба стежити. Якщо ваш хостинг надає доступ SFTP — а це стосується майже будь-якого спільного хостингу, будь-якого VPS, будь-якого керованого WordPress-хостингу — ви завершите за приблизно дві хвилини.
Пароль чи ключ?
Ключ, якщо ваш хостинг це підтримує. Паролі теж чудово працюють, і ми зберігаємо їх прив'язаними до вашого облікового запису, але ключ — це на один секрет менше, десь наявний — різниця між "відкликати ключ" і "скинути пароль усюди, де цей пароль випадково повторно використовувався", якщо щось піде не так пізніше. Багато дешевих налаштувань спільного хостингу SFTP пропонують лише автентифікацію паролем, і це теж нормально. Просто не використовуйте цей пароль ніде більше.
Як знайти правильний шлях до кореня сайту?
Це поле, у якому люди вперше помиляються, бо неправильна відповідь усе ще виглядає правдоподібно. Це не ваш домашній каталог, це не /var/www — це точна папка, з якої налаштований обслуговувати ваш веб-сервер.
| Сервер | Типовий webroot |
|---|---|
| Apache / cPanel | public_html |
| Nginx | /var/www/mysite/html — чи якийсь шлях, названий попереднім розробником три роки тому з причин, які ніхто не пам'ятає |
Якщо не впевнені, скиньте тестовий test.txt у папку, яку вважаєте правильною, за допомогою будь-якого SFTP-клієнта, а потім перевірте, чи завантажується він за адресою yoursite.com/test.txt. Помиліться тут, і розгортання все одно повідомить про успіх — агент сумлінно записує файли не в ту папку, і ви залишаєтесь дивитися на живий сайт, який не змінився, гадаючи, чому.
Чи може одна ціль охоплювати більше одного домену?
Так, і саме ця частина економить реальний час, коли ви пройшли свій перший сайт. Ціль — це один сервер і один набір облікових даних — вона не прив'язана до одного домену. У розділі Керування доменами ви прив'язуєте кожен домен до цілі з власним перевизначенням webroot. Запускаєте три сайти на одному VPS із серверними блоками Nginx?
site-a→/var/www/site-asite-b→/var/www/site-bsite-c→/var/www/site-c
Одна ціль, три прив'язки. Ви не вводите SSH-пароль повторно тричі, і не підтримуєте три майже однакові цілі, що розходяться в день, коли ви ротуєте ключ і забуваєте одну з них. Натисніть розгорнути на будь-якому з трьох доменів, і він уже знає, який сервер і яку папку — вам ніколи не доводиться вибирати під час розгортання.
Що насправді робить агент, коли підключається?
Спершу він оглядається — лише для читання, нічого ще не записано. Ця перевірка встановлює наявність:
- Порожньої папки
- Попередньої версії саме цієї збірки
- Старої інсталяції WordPress
- Заглушки "скоро буде", яку ваш хостинг залишив там за замовчуванням
Це визначає стратегію. Порожній webroot отримує просте завантаження. Webroot, у якому вже щось є, обробляється обережніше, бо в багатьох реальних налаштуваннях поруч із сайтом живе те, що не повинно зникнути:
- A
.well-knownпапка для перевірки SSL - Каталог
uploads, який ніхто не додав у git - A
wp-config.phpнікому не потрібно чіпати
Завдання тут ближче до "з'ясувати, що змінилося, і узгодити це", ніж до "стерти і замінити".
Потім, перш ніж хоч один байт буде перезаписано, наявний webroot фіксується як версія на вашому власному хостингу. Не запис у базі даних, не diff, який ми обчислюємо і сподіваємося, що він правильний — а справжній знімок того, що там лежало. Це найважливіше при найпершому розгортанні на будь-яку ціль, бо це розгортання завжди накладається на щось, навіть якщо це щось — нічого. Порожня папка — порожній знімок. П'ятирічний статичний сайт, про створення якого ніхто не пам'ятає — зберігається точно, безкоштовно, до того як його торкнуться. Саме це перше розгортання також те, у якому ви найменше впевнені, тому саме тут це має найбільше значення.
Завантажується мій вихідний код чи зібраний сайт?
Зібраний сайт, завжди. Для статичного сайту це згенеровані сторінки. Для збірки на фреймворку — Next.js, Vite, залежно від типу сайту — це скомпільований результат, папка dist або build , а не вихідне дерево коду. Я вважаю це правильним рішенням, навіть попри те, що це означає — ви не можете підключитися по SSH і запустити npm run dev на тому, що зараз на сервері. Завантаження вихідного коду означало б, що вашому продакшн-вебруту потрібне середовище виконання Node і інструментарій збірки лише для того, щоб віддавати HTML — перетворюючи сервер спільного хостингу, який ніколи не був призначений для запуску пайплайну збірки, саме на такий, і перетворюючи кожен деплой на "сподівання, що серверу вистачить пам'яті, щоб завершити npm install." Постачання лише скомпільованого результату утримує вебрут саме таким, яким його очікує статичний файловий сервер. Нудно. А нудне — це те, що вам потрібне о 2-й ночі, коли щось не так і ви дивитеся на цю папку, намагаючись зрозуміти, що насправді віддається.
Як я дізнаюся, що розгортання справді спрацювало?
Після завантаження агент звертається до живого URL і перевіряє, чи він відкривається — без 500-ї помилки, без порожньої сторінки. Усе, що він виявить, а також усе, що помітив під час перевірки і щодо чого хоче отримати вашу відповідь ("у цьому вебруті є папка wp-content , яку я залишив без змін, підтвердьте, що так і має бути"), потрапляє в чат-тред збірки. Це закономірність для всієї платформи: жодного тихого успіху, жодного тихого провалу, що перетворюється на тікет підтримки. Агент повідомляє, що він побачив і що вирішив, у тому самому треді, де ви попросили про збірку.
Що насправді міститься в історії версій?
Кожне розгортання додає версію — не лише перше. Тож історія — це не ваші збірки, нанесені на абстрактну шкалу часу; це буквальна послідовність того, що обслуговувалося з цього webroot, по порядку, починаючи з того, що там було до вашої появи. Версія перша — це завжди той стан до платформи, зафіксований автоматично. Вам не потрібно про це думати.
Що саме відновлює відкат?
Попередню живу версію, точно — не повторний запуск старої збірки, не наближення. Реальні файли, які обслуговували трафік раніше. Це суттєво сильніша гарантія, ніж більшість функцій "відкату", які я бачив десь ще, — вони зазвичай означають "повторно розгорнути зі старого коміту" і мовчки припускають, що ваш процес збірки детермінований, а ваше середовище не змінювалося з того часу. Тут відкат — це відновлення відомого справного знімка, тому до нього безпечно вдаватися під тиском — вам не потрібно розмірковувати, чи може відкат поводитися інакше, ніж те, до чого він відкочує.
І момент, коли він вам насправді потрібен, ніколи не буває спокійним; це "нова збірка зламала оформлення замовлення, а трафік йде прямо зараз".
Один клік, попередня версія відновлена, готово. Обґрунтування того, чому це вважається функцією першого рівня, а не другорядною, викладено в Ітерування без страху — варто прочитати один раз, до того як знадобиться. І історія, і елемент керування відновленням доступні на картці збірки та у власному вигляді історії цілі.
Чи резервує це також мою базу даних?
Ні, і я краще скажу це прямо, ніж дозволю комусь припустити протилежне. Історія версій на хостингу охоплює те, що цей конвеєр розгортання розмістив у webroot. Якщо у вашого сайту є база даних, чи завантаження користувачів, чи щось інше, що змінюється поза розгортаннями — це зовсім окреме питання; відкат цього не торкається і не повинен сприйматися як стратегія резервного копіювання, яка це робить.
