Российский облачный рынок, согласно прогнозам, к 2030 году вырастет до 1,2 трлн руб. — это почти втрое больше показателя 2024 года. При этом три четверти серверов в стране до сих пор работают на иностранном ПО. Насколько остро стоит вопрос переезда, сильно зависит от сферы и регуляторных требований, но у тех, кому мигрировать всё же нужно, картина обычно одна: инфраструктура складывалась годами, а воспроизводить ее в новом окружении с нуля долго.В статье поговорим про сервис загрузки пользовательских образов, который снимает значительную часть этой нагрузки.Развилка: перенести или настроить зановоК моменту переезда у бизнеса обычно уже есть рабочая инфраструктура. Сервисы работают, права настроены, мониторинг собирает метрики, сетевые политики определены. Всё это собиралось годами и зачастую нигде не задокументировано. Перед командой два пути.Первый — описать конфигурацию через Terraform и Ansible и развернуть всё в облаке с нуля. Подход правильный и, вопреки распространенному мнению, не такой уж дорогой: описать полноценный сервис в Ansible даже вручную и с тестированием — это чаще десятки минут, а не недели. Проблема в другом: воспроизвести надо всё — пакеты, версии, зависимости. И если конфигурацию никто никогда не описывал в коде, восстанавливать ее приходится по крупицам.Второй — снять дамп диска текущего сервера и поднять из него виртуальную машину в новом облаке. Тогда конфигурации, пакеты и пользовательские данные едут вместе с системой.Не все российские провайдеры поддерживают такой сценарий, а кто-то поддерживает с оговорками. В 2026 году мы запустили загрузку пользовательских образов в Рег.облаке.Что такое пользовательский образПользовательский образ — это полная копия диска, из которой облачная платформа умеет запускать виртуальные машины. Клиент загружает образ операционной системы в каталог, и платформа создает из него ВМ. Для платформы это такой же образ, как стандартные Ubuntu, AlmaLinux, Debian или сборки с ispmanager, которые уже есть в каталоге Рег.облака.Для большинства задач готовых образов достаточно: почти любое ПО, которое можно поставить, просто ставят поверх стандартной системы. Пользовательские образы нужны в другом случае — когда требуется дистрибутив или ОС, которых в каталоге нет (Arch Linux, OpenSUSE), или сборка с кастомом вроде пересобранного Hardened-ядра.Когда выбирать перенос через образ, а когда — настройку с нуляКритерий простой: насколько часто меняется конфигурация и насколько хорошо она задокументирована.Перенос через образ оправдан, когда:сервер настраивали руками «один раз и надолго», а тех рук в команде уже нет;нужных версий софта больше не достать, и у инстанса накопилась своя невоспроизводимая история;сроки миграции поджимают, и описать конкретный сервер в IaC за это окно не успеть.Настройка с нуля через IaC оправдана, когда:инфраструктура активно развивается, конфигурация меняется неделя к неделе;команда уже работает с Terraform или Ansible, и описание инфраструктуры есть и поддерживается.На практике чаще всего работает гибрид: критичные или сложные legacy-компоненты переносят «как есть», а остальное пересоздают через IaC. Поддержка образов важна именно потому, что делает такой сценарий возможным и снижает барьер миграции для существующих систем.Сценарии, в которых образ — основной инструментПеренос между провайдерамиСервер у другого провайдера или на собственном железе: своя версия Linux, базы, рабочее окружение. Настраивать заново и воспроизводить конфигурацию — это дни. Альтернатива — снять полную копию диска, загрузить в облако, запустить ВМ. Образ сокращает не время на синхронизацию данных, а время на обратную сборку среды, и это его главная ценность в таком переезде.Golden image и одинаковый старт всех серверовВ DevOps-процессах команды давно работают с golden image — заранее подготовленным эталонным образом. Суть golden image не столько в том, что в нем что-то предустановлено, сколько в том, что он один и заведомо известно, что внутри. Это дает понятную и, что важнее, одинаковую стартовую точку для всех серверов.Дальше есть варианты. Можно поднимать серверы из такого образа и докручивать их инструментом управления конфигурациями. А можно зашить весь софт и настройки прямо в образ — тогда инструмент управления конфигурациями вообще не нужен: конфигурацию подтягивают через cloud-init, а корень можно сделать read-only, что повышает безопасность и снижает шанс проблем внутри ВМ. Образ ведь тестируют до того, как пустить в работу.Обновление при таком подходе устроено просто: чтобы обновить софт, заливают новый golden image, а не обходят машины руками.Кастомные конфигурации ОСЧерез пользовательский образ запускают конфигурации, которых нет в стандартном каталоге: read-only root filesystem, преднастроенные агенты мониторинга, специализированные сборки Linux, нестандартную разметку дисков. Это случаи, когда маркетплейс готовых образов закрывает базовые потребности, но не позволяет воспроизвести особенности существующей системы без ручной донастройки.Что проверить перед загрузкой образаКраткий чек-лист для тех, кто впервые запускает ВМ из собственного образа в облаке.Драйверы виртуальных устройств. В образе должны быть драйверы виртуального диска и сетевого адаптера, используемых облачной платформой. Для Linux обычно нужны драйверы virtio, которые в большинстве современных дистрибутивов уже включены в ядро. Если драйвер диска отсутствует или недоступен на этапе загрузки, ОС может не загрузиться. Если отсутствует сетевой драйвер — ВМ может загрузиться, но сеть работать не будет.initramfs. Модули ядра для виртуальных устройств должны быть собраны в initramfs, иначе система не увидит свой корневой раздел при первом старте.Cloud-init. Рекомендуется установить и включить cloud-init. Он используется для первоначальной настройки ВМ: добавления SSH-ключей, настройки пользователя, hostname и сети. Без cloud-init образ может загрузиться, но автоматическая настройка ВМ средствами облака работать не будет.Формат диска. qcow2 — основной для QEMU/KVM, поддерживает copy-on-write и снапшоты. raw — бинарная копия диска, проще, но образы получаются заметно больше. Конвертация — через qemu-img convert.Размер. В Рег.облаке лимит — 30 ГБ. Если образ больше, его либо уменьшают (чистят кеши, логи, временные файлы, незанятое место), либо запрашивают увеличение лимита у поддержки.Серверные SSH-ключи. Зашитые в исходную систему ключи лучше удалить перед снятием образа — тогда sshd сгенерирует серверные ключи сам, а клиентские для доступа подтянет cloud-init. Иначе на новой машине окажется чужой identity — и в audit-логе, и в known_hosts.Режим загрузки и загрузчик. Убедитесь, что в образе установлен рабочий загрузчик и режим загрузки образа соответствует режиму, поддерживаемому облаком — BIOS или UEFI.Архитектура ОС. Образ должен соответствовать архитектуре виртуальных машин облака, например x86_64 / amd64.Как технически устроена загрузка в Рег.облакеЗагрузка идет через S3: multipart upload и presigned URL, без постоянных ключей доступа. Это стандартный механизм для больших файлов — он устойчив к разрывам соединения и легко вписывается в CI/CD-пайплайн или скрипт сборки инфраструктуры.Дальше платформа кладет образ в Glance — компонент OpenStack для хранения образов виртуальных машин и их метаданных. При запуске сервера платформа берет образ из Glance, передает гипервизору, и тот создает диск ВМ. В метаданных Glance хранит тип ОС, архитектуру, формат диска и параметры загрузки — те, что задал клиент при загрузке.Когда образа уже малоОбраз — это источник стартового содержимого диска для одной ВМ. Сам по себе он не мешает масштабированию: из одной полной копии диска можно поднять сколько угодно виртуалок. Но как только речь о распределенной инфраструктуре, одного образа недостаточно — и не потому, что он «не масштабируется», а потому что появляются задачи, которые образом в принципе не решаются.Типичный пример — перенос баз данных. Их обычно больно выключать, поэтому ту же PostgreSQL стоит сначала завести отдельно как реплику, переключить на нее мастер и только потом перевозить остальное. Образы для этого не нужны вообще. То же с гибридной архитектурой, где часть нагрузки на bare metal, и с legacy-стеком на нескольких физических серверах. Порядок переноса, окна простоя, репликацию данных, переключение DNS и откат приходится планировать отдельно, а образ становится одним из инструментов в наборе.Поэтому пользовательские образы не заменяют Terraform или Ansible, а встраиваются в автоматизированный пайплайн. Например, базовый образ собирают через Packer, загружают в облако, а дальнейшее развертывание и настройку выполняют через IaC-инструменты и cloud-init. Так воспроизводимость инфраструктуры сочетается с быстрым запуском уже подготовленных систем.ИтогоПользовательский образ — это полная копия диска, из которой платформа разворачивает виртуальную машину. За простой механикой стоит развилка, которая определяет, как пройдет миграция.Если сервер настроили один раз и он годами работает без изменений, перенос через образ обычно выгоднее, чем настройка с нуля. Если же сервер всё это время велся через Ansible и так же обновлялся, выгода уже не очевидна, и стоит смотреть в сторону IaC. При этом образы не противоречат DevOps-подходу: они хорошо ложатся на golden image-пайплайны, автоматическую загрузку через S3 и CI/CD.Для ИТ-инфраструктуры это означает простую вещь: у команды появляется еще одна опция в стратегии переезда в облако. Не маркетинговая, а инженерная — и у российских заказчиков она будет востребована.