Налаштування хмарної інфраструктури на Hetzner Cloud під ключ

Інфраструктура в Hetzner Cloud: що ламається під час ручного налаштування

Ручне налаштування серверів майже завжди починається однаково: машину піднімають, налаштовують на місці, правки вносять прямо на працюючому вузлі.

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

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

Збої через розрізнені конфігурації накопичуються непомітно.

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

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

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

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

Що дає керована інфраструктура: ефект у строках і надійності

Керована інфраструктура змінює не окрему метрику, а поведінку системи під навантаженням і в момент збою.

Описи середовищ зберігаються в репозиторії, будь-яка правка проходить перевірку й відтворюється на всіх контурах однаково — на Hetzner Cloud це збирається з образів і шаблонів без ручних доопрацювань на серверах. Звідси випливають три вимірювані наслідки.

Швидкість виведення змін задається єдиним сценарієм від гілки до робочого контуру.

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

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

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

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

Hetzner Cloud: режими розгортання і коли який доречний

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

Зона відповідальності: де закінчується провайдер і починаємося ми

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

Якщо залізо деградувало — це до провайдера, якщо сервіс не піднявся після оновлення — розбираємося ми. Розподіл фіксуємо в регламенті, щоб не залишилося «сірих» зон.

Як вибираємо режим

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

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

Етапи впровадження: від аудиту до передачі в експлуатацію

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

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

2. Схема розгортання. Цільова топологія: кількість вузлів, розподіл ролей, межі відмов, що йде в приватну мережу. Погоджуємо до створення ресурсів у Hetzner Cloud — правки на схемі дешевші за перезбирання.

3. Налаштування мереж і доступів. Приватні мережі, правила міжмережевого екрана, бастіон для адміністративного доступу, рольова модель. Секрети лежать у сховищі, а не в репозиторії; доступ видається за мінімально необхідним.

4. Інфраструктура як код. Ресурси описані декларативно, стан — у захищеному сховищі, зміни проходять перевірку. Середовище відтворюється з нуля, ручні правки в панелі виключені.

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

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

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

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

Тому ми передаємо не «доступи за фактом», а повний комплект артефактів у ваш репозиторій — з ними ваша команда веде проєкт самостійно.

• Конфігураційні файли — декларативні описи серверів, приватної мережі, балансувальників, фаєрвола й томів зберігання. Середовище піднімається з них повторювано, а не «руками з пам'яті».
• Схеми інфраструктури — зв'язки між підмережами, точками входу, чергами й сховищами, окремо позначені зовнішні залежності та критичні шляхи.
• Регламент резервного копіювання — що копіюється, з якою частотою, де лежать копії, скільки зберігаються й як перевіряється відновлення на тестовому контурі.
• Політики доступу — ролі, ключі, розділення прав на читання й зміну, порядок видачі й відкликання доступів у разі звільнення співробітника.
• Інструкції для команди — розгортання релізу, відкат на попередню версію, додавання сервера, читання журналів, типові аварійні сценарії.
• Моніторинг і оповіщення — перелік метрик, пороги спрацювання, кому надходить повідомлення й що робити за кожним сигналом.
• Карта передачі — перелік акаунтів, сервісних облікових записів і місць зберігання секретів із зазначенням власника після передачі.

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

Кейс: переїзд сервісу в хмару та метрики до і після

Інфраструктура до робіт

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

Відмова диска давала простій 4-6 годин: шукали образ, піднімали середовище з пам'яті, правили конфіги на живому. Реліз виходив раз на два тижні, бо кожному вікну передувало ручне тестування на копії бази.

Що змінювали і що вийшло

Інфраструктуру описали як код — середовище перестворюється з репозиторію, ручні правки на серверах виключені.

Переїхали в Hetzner Cloud, розділивши мережу: база в приватному сегменті, доступ лише із застосунку, назовні дивиться балансувальник із перевіркою живості й автозаміною вузла.

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

Відновлення після відмови вузла скоротилося з 4-6 годин до 10-15 хвилин, робочий стенд розгортається за 20 хвилин замість половини дня, релізи вийшли на щоденний ритм, а відкат на попередній образ займає хвилини. Простій у планових роботах — кілька хвилин завдяки викладці без зупинки сервісу.

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

Чим хмарні віртуальні машини відрізняються від виділеного сервера

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

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

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

Хмарні віртуальні машини масштабуються під навантаження за хвилини — у Hetzner Cloud група вузлів додається за метриками, а зайві гасяться, коли трафік спадає.

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

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

Часті технічні питання: доступи й відмовостійкість

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

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

Які доступи отримують ваші інженери?

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

Як влаштовані резервні копії та відмовостійкість?

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

Чи можна потім поїхати назад або до іншого майданчика?

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

З чого почати перехід у хмару: обговоримо ваше завдання

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

• Що працює зараз: перелік сервісів і середовищ, що критично для бізнесу, що переносимо хвилями, а що дешевше переписати.
• Профіль навантаження: пікові значення, сезонність, вимоги до часу відгуку й доступності.
• Де лежать дані: бази, файлові сховища, резервні копії — і що з цього залишається на місці.
• Домени, сертифікати, DNS-зони та зовнішні інтеграції: їх перенесення дає найчутливіші збої.
• Вимоги до доступів: хто і як потрапляє на сервери, чи потрібен закритий контур без публічних адрес.
• Що вже автоматизовано — збирання, розгортання, керування конфігурацією — і що описуємо з нуля.
• Обмеження за строками та вікна обслуговування: коли допустимий простій і на який строк.

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