Для проектов, где серверы находятся в Европе, а бюджет считается внимательно, немецкий провайдер Hetzner Cloud давно стал рабочей альтернативой гигантам. За сопоставимые деньги здесь получается в разы больше процессорных ядер и памяти, а управлять хозяйством удобнее всего через консольную утилиту hcloud, которая закрывает повседневные задачи без веб интерфейса. Разберём настройку инструмента, создание машин, работу с сетями и снимками, и честно посмотрим, где экономия оборачивается ограничениями по сравнению с тем же AWS.
Чем немецкий провайдер отличается и как устроено управление
Базовая модель здесь традиционна для старой европейской школы хостинга: фиксированные типы машин с понятной ценой в месяц, а не почасовая аренда каждого гигабайта с плавающими ставками. Машины размещаются в дата центрах Германии и Финляндии, позже появились площадки в Соединённых Штатах, и вся инфраструктура живёт под европейской юрисдикцией с её требованиями к обращению с данными. Для проектов с европейской аудиторией это одновременно и вопрос задержек, и вопрос соответствия правилам обращения с персональными данными.
Второе отличие философия сервиса. Здесь нет сотен управляемых служб на любой вкус: есть машины, сети, тома, балансировщики и хранилище объектов, а базы данных, очереди и всё остальное администратор поднимает и обслуживает сам. Это осознанный размен: меньше готовых служб, зато прозрачная цена, предсказуемый счёт и отсутствие эффекта ловушки, когда проект намертво привязывается к десяткам фирменных интерфейсов одного вендора.
Консольная утилита ставится из готовых пакетов под все основные системы и настраивается за минуту. Токен доступа создаётся в панели проекта, после чего утилита запоминает его в отдельном контексте, и переключение между несколькими проектами сводится к смене контекста одной командой. Такая организация удобнее, чем переменные окружения, когда одним человеком обслуживается несколько хозяйств.
hcloud context create myproject
hcloud ssh-key create --name deploy --public-key-from-file ~/.ssh/deploy.pub
hcloud server create --name web1 --type cx22 \
--image ubuntu-24.04 --location fsn1 --ssh-key deploy
hcloud server listТри команды из примера покрывают типовой ритуал: контекст, ключ, машина. Локация fsn1 означает площадку в Фалькенштайне, а выбор типа задаёт пропорции процессора и памяти. Новая машина появляется с назначенным адресом, и через минуту на неё можно заходить по ключу. Для тех, кто управляет несколькими машинами, полезно сразу привыкать к выводу списка с ярлыками: имена и описания задаются при создании, а фильтрация по ним экономит время на любом объёме.
Линейки серверов и как выбирать тип под задачу
Каталог типов разделён на линейки по характеру процессора. Общая линейка предлагает разделяемые ядра по минимальной цене и идеально подходит для небольших служб, тестовых стендов и внутренних инструментов. Линейка с выделенными ядрами гарантирует, что сосед по хосту не отберёт такты в момент пиковой нагрузки, и стоит на ступень дороже. Отдельная линейка построена на процессорах с архитектурой ARM и выдаёт впечатляющее соотношение памяти и вычислений за деньги, особенно для контейнерных нагрузок и сборочных ферм.
Практический подход к выбору простой: службы с ровным фоновым профилем живут на разделяемых ядрах, всё, что отвечает пользователям и чувствительно к скачкам, получает выделенные ядра, а задачи вроде сборки, перекодирования и анализа данных отлично чувствуют себя на архитектуре ARM. Смена типа машины выполняется одной командой с короткой перезагрузкой, поэтому выбор не приговор, а рабочий параметр, который подгоняется под фактическую нагрузку.
Сети, тома и защита машины средствами провайдера
Частные сети связывают машины изолированным контуром: трафик между ними не выходит в открытую сеть, адреса назначаются из выбранного диапазона, а подсети и маршруты описываются там же, где и машины. Схема с частной сетью и закрытым административным доступом сокращает поверхность уязвимости ещё на этапе размещения.
hcloud network create --name private-net --ip-range 10.0.0.0/16
hcloud network add-subnet private-net --network-zone eu-central \
--type cloud --ip-range 10.0.1.0/24
hcloud server attach-to-network web1 --network private-net
hcloud volume create --name data1 --size 50 --server web1 --automountТома добавляются машинам как дополнительные диски с выбором размера и площадки, а брандмауэр провайдера фильтрует входящий трафик правилами ещё до самой машины. Отдельного упоминания заслуживает плавающий адрес: он закрепляется за проектом, а не за машиной, и переставляется на другой сервер одной командой, что превращает перенос службы на новый узел в операцию без правки записей у клиентов.
Cloud init на Hetzner и автоматизация запуска
Машины при создании принимают пользовательский сценарий запуска, и это позволяет применить всю схему из облачных практик: ключи, пакеты и первые команды передаются при создании и исполняются при первом старте. Утилита принимает такой сценарий из файла одной опцией:
hcloud server create --name web2 --type cx22 \
--image ubuntu-24.04 --location fsn1 --ssh-key deploy \
--user-data-from-file cloud-init.ymlВ сочетании с системой управления конфигурациями это закрывает полный цикл: шаблон инфраструктуры описывает машину, сценарий запуска готовит её к приёму управления, а конфигурация доводит до рабочего состояния. Для небольших хозяйств описанного достаточно, чтобы новая машина становилась рабочей за считанные минуты после одной команды создания, а воспроизводимость обеспечивалась самими файлами, лежащими в репозитории. Такой порядок ценен ещё и прозрачностью: состав машины, её ключи и первые команды видны в одном файле, который проходят глазами перед запуском, а не спрятаны в выпадающих меню панели.
Резервные копии, снимки и восстановление
Защита данных здесь встроена в продукт и включается на уровне машины. Автоматическое резервное копирование берёт на себя ежедневные копии с хранением нескольких точек за разные дни и стоит небольшой надбавкой к цене машины. Снимки делаются вручную в любой момент и служат другому: зафиксировать состояние перед экспериментом, размножить настроенную машину в шаблон или перенести образ между площадками. Порядок работы с резервированием выглядит так:
- для боевых машин включается автоматическое копирование с ежедневным расписанием и хранением по окнам;
- перед каждым рискованным изменением снимается ручной снимок состояния;
- удачный шаблон машины сохраняется в образ и переиспользуется при масштабировании;
- копии, потерявшие актуальность, удаляются по расписанию, чтобы счёт не разрастался;
- восстановление из снимка в отдельную машину периодически проверяется на практике, а не только в планах.
Пятый пункт выглядит перестраховкой, пока однажды не выясняется, что копия давно не разворачивается из-за смены настроек сети. Проверка восстановления занимает минуты и оправдывает себя после первого же реального сбоя. Уверенность в собственной копии дорого стоит в тот вечер, когда основной узел неожиданно перестаёт отвечать.
Балансировщик, резервирование служб и безопасность машины
Для служб, которым нужен запасной узел, провайдер предлагает управляемый балансировщик: он принимает трафик, распределяет его по целевым машинам и сам исключает узлы, переставшие отвечать на проверочный запрос. Альтернатива для тех, кто любит полный контроль, классическая пара из службы распределения запросов и плавающего адреса: запасная машина держит копию службы, и при отказе ведущей адрес переставляется на неё одной командой. Обе схемы стоят несравнимо дешевле аналогичных конструкций у больших облаков, а разница в возможностях для типового проекта невелика.
Проверочные запросы балансировщика настраиваются под конкретную службу: не просто открытый порт, а страница здоровья, отвечающая только тогда, когда приложение готово принимать работу. Эта мелочь отличает схему, которая действительно спасает при отказе, от схемы, которая продолжает слать трафик на технически живой, но бесполезный узел.
Базовый уровень защиты здесь собирается из четырёх слоёв, и все они бесплатны. Первый слой брандмауэр провайдера: правила фильтруют входящий трафик ещё до машины, и наружу остаются открытыми только нужные порты. Второй слой вход по ключам с отключённым парольным входом, настроенный прямо в сценарии первого запуска. Третий слой автоматические обновления безопасности внутри системы, которые закрывают уязвимости без участия человека. Четвёртый слой защита административного входа от перебора: служба, отслеживающая неудачные попытки входа и блокирующая настойчивых гостей, ставится одной командой и радикально уменьшает шум в журналах.
К этому добавляется дисциплина токенов доступа к панели проекта: токен с правами только на чтение для сценариев наблюдения, полный токен только там, где он действительно нужен, и перевыпуск при любых сомнениях. Дешёвая инфраструктура не значит небрежная: те же привычки, что защищают дорогие хозяйства, стоят здесь ровно столько же.
Скрытая стоимость дешёвых машин это возможная привязка, и здесь её почти нет. Машины работают на стандартных образах без фирменных прослоек, данные лежат на обычных дисках и в объектном хранилище с совместимым интерфейсом, а частные сети повторяют то, что легко собрать на любом другом облаке. План выхода укладывается в один абзац: поднять машины у нового провайдера из тех же сценариев запуска, скопировать данные с помощью обычной синхронизации по защищённому каналу, переключить адреса в службе имён и погасить старые машины.
Выйти из привязки помогает и дисциплина описания инфраструктуры в файлах: когда состав машин, сетей и правил живёт в репозитории, переезд становится запуском тех же файлов против другого облака с поправкой на имена ресурсов. Опытные хозяйства устраивают такую тренировку на тестовом контуре раз в год, и отсутствие сюрпризов при реальном переезде оказывается прямым следствием привычки держать хозяйство переносимым.
Миграция, честное сравнение с AWS и границы применимости
По цене за единицу вычислений разница драматична: сопоставимая по ядрам и памяти машина стоит в несколько раз дешевле, а включённый пакет трафика размером в двадцать терабайт на машину усугубляет разрыв для проектов с большой отдачей данных, ведь у гигантов исходящий трафик тарифицируется отдельно и обходится заметно дороже за гигабайт. Для самостоятельных служб вроде веб серверов, сборочных агентов, хранилищ и отдельных площадок арифметика обычно решает вопрос сама.
Но гиганты продают не только машины, и здесь начинается честная часть сравнения. Управляемые базы с автоматическими резервами и репликацией, очереди сообщений, хранилище секретов, сотни региональных площадок и зрелые инструменты корпоративного уровня остаются сильной стороной больших облаков. Здесь же администратор сам разворачивает и обновляет базы, сам строит отказоустойчивость и сам отвечает за всё, что не входит в список служб провайдера. Поддержка отвечает по заявкам без многоуровневых тарифов сопровождения, что для одних лишний аргумент, а для других отсутствие страховки.
Практический вывод из сравнения звучит не как выбор победителя, а как раздел труда. Инфраструктура, которую обслуживает собственная команда, выигрывает у европейского провайдера ценой, прозрачностью и отсутствием привязки. Проекты, которым нужны готовые управляемые службы и глобальный охват площадок, продолжают жить у гигантов и платят за это осознанно. Многие хозяйства совмещают обе модели, размещая каждую службу там, где её цена и требования совпадают лучше всего. Такой раздел труда всё чаще выглядит не как компромисс, а как зрелая стратегия: недорогие машины в Европе держат то, что должна контролировать сама команда, а гигантам достаются те службы, которые дешевле купить, чем построить.