Привет, Хабр! На связи Даша Косова, я продакт менеджер Рег.облака. Представим знакомую многим ситуацию. У компании есть сервер. Он работает уже несколько лет. На нем крутятся базы данных, backend-сервисы, cron-скрипты, система мониторинга. Всё настроено, всё работает, и трогать это никто особенно не хочет.
Инфраструктуру собирали постепенно: что-то добавили год назад, что-то настроили два года назад, какие-то сервисы поднимали «на скорую руку». Со временем все это превратилось в полноценную рабочую систему. И в какой-то момент возникает идея переехать в облако. А что происходит дальше и как ничего не потерять при переезде — в этой статье.
Навигация по тексту
Почему компании идут в облако
Причины обычно вполне практичные.
Стоимость обслуживания инфраструктуры. Собственные серверы — это не только покупка железа. Это еще обслуживание оборудования, резервирование, мониторинг, поддержка сети, замена компонентов и регулярные обновления. Со временем инфраструктура разрастается, и все больше ресурсов уходит на ее поддержку.
Скорость развития технологий. На рынке постоянно появляются новые решения — от PaaS-сервисов до инструментов для работы с данными и ИИ. Экосистема облаков развивается быстрее, чем большинство команд успевает разворачивать инфраструктуру своими силами. Облако становится готовой платформой: провайдер поддерживает оборудование, обновляет систему и следит за ее состоянием, а клиент платит только за использованные ресурсы.
Безопасность. Есть распространенный стереотип, что облако менее безопасно, чем собственные серверы. На практике часто наоборот. В своей инфраструктуре безопасность нередко держится на одном-двух администраторах и обновлениях по cron. Отслеживать новые уязвимости и оперативно применять патчи в таких условиях сложно.
В облачных платформах этим занимаются отдельные команды. Инфраструктуру постоянно мониторят, проводят регулярные аудиты, быстро применяют обновления. И отдельно: облака давно адаптированы под требования регулирования — есть частные облака, публичные облака с соответствием ФЗ-152, изолированные среды для работы с персональными данными.
Поэтому сегодня облако используют не только для тестовых проектов, но и для production-нагрузок — включая системы с чувствительными данными. Но когда решение принято, появляется главный вопрос: как перенести существующую инфраструктуру так, чтобы не пересобирать ее с нуля?
Два подхода к миграции
Компании редко переходят в облако с чистого листа. К моменту миграции у бизнеса обычно уже есть сложившаяся инфраструктура: физические серверы, своя виртуализация или ресурсы у другого провайдера. На них работают приложения, базы данных, backend-сервисы, настроены политики безопасности, пользователи и сеть. И все это создавалось годами. Поэтому главный вопрос звучит не «как начать?», а «как перенести то, что уже работает?». Обычно выбирают один из двух подходов.
Пересобрать инфраструктуру. Воспроизвести ее заново — например, через Terraform, Ansible или другие инструменты Infrastructure as Code. Архитектуру описывают в коде и разворачивают с нуля. Подход современный и правильный, но требует времени и серьезной перестройки: нужно воспроизвести настройки, пакеты, зависимости и особенности конфигурации. Иногда это недели, а то и месяцы работы.
Перенести систему как есть. Снять образ диска текущего сервера и запустить его в новом облаке. Вместе с системой переезжают установленные пакеты, конфигурации сервисов, системные настройки и пользовательские данные. Сервер просто перемещается в новое окружение.
Именно для такого сценария в Рег.облаке появились пользовательские образы.
Что такое пользовательский образ
Пользовательский образ — это файл диска, из которого можно запускать виртуальные машины. Пользователь загружает свой образ операционной системы, сохраняет его в каталоге и запускает из него новые виртуальные машины.
После загрузки пользовательский образ становится таким же объектом платформы, как стандартные образы Linux или Windows. Разница только в том, что внутри — полностью подготовленная система пользователя.
В Рег.облаке уже есть маркетплейс готовых образов: популярные операционные системы, серверные окружения, панели управления Ubuntu, AlmaLinux и Debian, сборки с ispmanager. Для большинства типовых задач этого хватает. Но инфраструктура у всех разная, и иногда нужна система, которой в каталоге просто нет: Arch Linux, OpenSUSE, корпоративная сборка с нестандартными политиками безопасности или специализированная среда разработки, которую один раз настроили и больше не хотят трогать.
Когда пользовательские образы действительно нужны
Перенос инфраструктуры между провайдерами
Классическая ситуация — сервер работает у другого провайдера. На нем установлена конкретная версия Linux, настроены сервисы, базы данных, рабочее окружение. Переносить все вручную — значит заново устанавливать систему и воспроизводить конфигурацию. Это дни, а иногда и недели.
Есть и альтернативный вариант: снять образ диска сервера, загрузить его в облако и запустить виртуальную машину. Сервер переезжает целиком, без пересборки.
Golden image и воспроизводимая инфраструктура
В DevOps-процессах команды часто применяют концепцию golden image — заранее подготовленного эталонного образа операционной системы. В нем уже есть системные пакеты, настройки безопасности, агенты мониторинга, базовые сервисы и сетевые конфигурации. Когда нужен новый сервер, его запускают не из чистой ОС, а из такого подготовленного образа. Это сразу дает несколько плюсов:
единообразие: у всех серверов одинаковая конфигурация;
быстрое масштабирование: новый сервер поднимается за минуты;
предсказуемость: параметры системы известны заранее;
безопасность: образ регулярно обновляют и включают в него новые патчи.
Инфраструктура становится воспроизводимой: один образ = десятки одинаковых серверов.
Автоматизация через API и Terraform
Большинство облачных платформ дает API для управления инфраструктурой. Через API создают серверы, управляют сетями, подключают диски и IP-адреса, запускают виртуальные машины из образов. Поверх API обычно работают инструменты Infrastructure as Code — чаще всего Terraform. В конфигурации описывают виртуальные машины, сети, диски, балансировщики и IP-адреса, а дальше инфраструктуру разворачивают одной командой.
Типичный процесс выглядит так: CI/CD-пайплайн собирает новый системный образ, загружает его в облако, Terraform поднимает серверы из этого образа, старая инфраструктура постепенно заменяется новой.
Важная оговорка: сейчас в Рег.облаке полностью замкнуть цикл «загрузить образ → создать из него сервер» через API пока нельзя. S3 отвечает за загрузку файла, а виртуальные машины из образа создаются через интерфейс платформы. Мы уже работаем над полной поддержкой этого сценария через API..
Кастомные конфигурации ОС
Пользовательские образы пригодятся не только для миграции. С их помощью запускают конфигурации, которых в стандартном каталоге нет. Это удобно, когда инфраструктура требует нестандартной разметки дисков или специфичных настроек файловой системы. Примеры конфигураций, которые можно загрузить как пользовательский образ:
своя разметка дисков, включая LVM или отдельные разделы /var и /home;
файловые системы вроде XFS на корневом разделе;
read-only root filesystem;
преднастроенные агенты мониторинга;
специализированные сборки Linux, которых нет в публичном каталоге.
Как технически устроена загрузка
Загрузка образа в облако работает через S3-совместимый интерфейс. Это стандартный механизм для больших файлов: он устойчив к разрывам соединения, поддерживает multipart upload и легко автоматизируется. Файл передается через presigned URL — временную ссылку для загрузки, постоянные ключи доступа не нужны.
S3-интерфейс удобно автоматизировать: образы загружают из CI/CD-пайплайна, из скриптов сборки инфраструктуры или из систем управления образами. Объектное хранилище поддерживает версионирование — можно хранить несколько версий образа и при необходимости откатываться.
Cloud-init
Чтобы образ корректно работал в облаке, его желательно подготовить с Cloud-init — инструментом для автоматической настройки виртуальной машины при первом запуске. Cloud-init настраивает сеть, создает пользователя, добавляет SSH-ключи — даже если у машины новый IP-адрес. Сервер сразу готов к работе. Особенно удобно это, когда из одного образа запускают много машин.
Что происходит внутри платформы
После загрузки образ попадает в Glance — компонент OpenStack, который хранит образы виртуальных машин и управляет их метаданными. При запуске сервера платформа берет образ из Glance, передает его гипервизору, а тот создает диск виртуальной машины. В метаданных Glance держит тип ОС, архитектуру, формат диска, параметры загрузки — всё это нужно для корректного запуска.
Форматы и ограничения
Сейчас поддерживаются два формата:
qcow2 — основной формат виртуальных дисков в KVM-инфраструктурах, поддерживает copy-on-write, снапшоты и эффективное хранение данных;
raw — бинарная копия диска без дополнительной структуры.
Оба формата широко используются в KVM-инфраструктурах и покрывают большинство сценариев миграции. При необходимости формат конвертируют через qemu-img convert. Максимальный размер образа в Рег.облаке — 30 ГБ. Если нужно больше, лимит увеличим по запросу в поддержку. Чтобы образ корректно запустился, внутри должны быть драйверы виртуальных устройств, поддержка cloud-init и нужные модули ядра в initramfs.
Когда образ можно вообще не собирать
У подхода с пользовательскими образами есть логичное продолжение: собирать образ самому нужно не всегда. Часть типовых приложений удобно брать уже готовыми — механика та же, просто образ собран не тобой, а провайдером.
Например, в нашем каталоге сервисов лежит преднастроенный GitLab — отдельная ВМ, а не SaaS: репозитории, раннеры и данные остаются внутри инфраструктуры пользователя. По сути self-hosted GitLab, с которого снята рутина первичной установки. Тот же принцип работает и для других приложений из каталога — разница только в том, что лежит внутри образа.
А когда образов уже не хватает
Пользовательский образ — это инструмент уровня отдельного сервера. Один диск, одна ВМ, один перенос. Как только инфраструктура перестает быть «одним сервером», механики образа начинает не хватать.
Типичные случаи: распределенные сервисы с зависимостями между узлами, связанные базы и очереди, гибридная архитектура с частью нагрузки на bare metal, legacy-стек на физических серверах у другого провайдера. Здесь образ закрывает максимум одну маленькую задачу из большой — остальное приходится планировать отдельно: порядок переноса, окна простоя, репликацию данных, переключение DNS, откат.
Под такие сценарии обычно строится отдельный процесс спланированной миграции (если интересно, почитайте, как это устроено у нас) — с переносом хостингов, облачных серверов от других провайдеров и физических машин.
Как менялась инфраструктура
Если посмотреть на развитие инфраструктуры, видна понятная эволюция. Сначала компании работали напрямую с bare metal — физическими серверами. Затем появилась виртуализация, с ней на одном сервере стали запускать несколько виртуальных машин. Следующий шаг — облачная инфраструктура, где компании управляют уже не серверами, а ресурсами. После этого появилась концепция Infrastructure as Code, где инфраструктуру описывают в коде. А дальше — image-based-инфраструктура, где серверы поднимают из заранее подготовленных образов. Вместо ручной установки и настройки — golden image. Новый сервер создается за минуты и сразу готов к работе.
За видимой простотой пользовательского образа лежит развилка, с которой обычно и начинается разговор про миграцию: переписывать инфраструктуру под новое окружение или перенести как есть. Маркетплейс закрывает типовые задачи, но почти у всех найдется что-то свое — корпоративная сборка, нестандартная разметка, агент мониторинга, который живет в системе с прошлого ремонта. Пользовательские образы нужны ровно для таких случаев: когда дешевле перенести работающее, чем воспроизводить его по памяти.