Fedora CoreOS и Flatcar Container Linux: выбор immutable ОС

Fedora CoreOS и Flatcar Container Linux решают одну задачу: предоставляют минимальную операционную систему для контейнерных нагрузок, которую не предполагается администрировать как обычный Linux-сервер. Вместо последовательного обновления отдельных пакетов узел получает согласованный образ системы, а первоначальная конфигурация описывается декларативно.

Обе ОС используют Ignition, systemd, автоматические обновления и запускаются на виртуальных машинах. Проекты публикуют сборки для x86_64 и ARM64, однако внутреннее устройство обновлений, состав контейнерного стека, релизные каналы и каталог платформенных образов различаются. Эти параметры меняются от выпуска к выпуску, поэтому перед внедрением необходимо сверить метаданные выбранного stream или канала, архитектуры и платформы.

Краткий вывод

Fedora CoreOS подходит командам, которые используют Fedora, Podman, rpm-ostree, SELinux и инструменты экосистемы Red Hat. Система регулярно получает новые компоненты и рассчитана на воспроизводимые контейнерные узлы, которые удобно пересоздавать из декларативной конфигурации. Отдельной многолетней LTS-ветки у FCOS нет.

Flatcar Container Linux удобен для Docker-first окружений, где важны встроенные Docker и containerd, понятная A/B-схема системных разделов и выбор канала обновлений. Проект предлагает LTS-потоки, однако срок поддержки и правила перехода между ними следует проверять в документации конкретного потока: общий канал LTS может со временем указывать на другую ветку.

• Для Podman, SELinux и тесной связи с Fedora — Fedora CoreOS.
• Для Docker-first окружения, A/B-разделов и LTS-потоков — Flatcar.
• Для обеих систем важны автоматизированный первый запуск и корректная передача Ignition.
• На VDS решающим фактором часто становится возможность импортировать подходящий образ и передать Ignition без изменения его содержимого.

Для проверки образа, firmware, сети и передачи Ignition нужен сервер с доступом к параметрам виртуальной машины. Для тестового стенда подойдёт VPS-сервер, на котором можно проверить запуск экземпляра до переноса рабочей нагрузки.

Облачный VDS-сервер

Виртуальные серверы с быстрым запуском и гибкой конфигурацией от 390₽ / мес

Доступные локации

Россия Нидерланды

Смотреть тарифы

Что означает immutable в этих системах

Термин immutable не означает, что на сервере вообще нельзя изменить файлы. В обеих ОС системная основа отделена от изменяемого состояния, но каталоги с конфигурацией, журналами и данными приложений остаются записываемыми. Контейнеры также должны использовать постоянное хранилище для данных, которые необходимо сохранить между перезапусками.

Практический смысл модели состоит в том, что администратор не поддерживает уникальное состояние каждого узла длинной историей команд установки и обновления пакетов. Базовая система поставляется как единое протестированное целое, а необходимые настройки воспроизводятся из конфигурации.

• состав базовой ОС меньше различается между серверами;
• обновление не оставляет узел в промежуточном состоянии из смеси старых и новых пакетов;
• проще заменить неисправный сервер новым экземпляром;
• откат системной версии не требует ручного понижения десятков пакетов;
• уменьшается потребность устанавливать служебные программы непосредственно на хост.

Неизменяемая основа не защищает данные контейнеров и не отменяет резервное копирование. Она также не гарантирует совместимость новой версии ядра, container runtime или systemd с конкретной нагрузкой. Поэтому необходимы тестовая группа узлов, контролируемые перезагрузки и мониторинг.

Архитектура Fedora CoreOS

Fedora CoreOS, или FCOS, строится вокруг OSTree и rpm-ostree. Версия системы развёртывается как отдельный deployment: обновлённое дерево подготавливается рядом с текущим и активируется после перезагрузки. Системные файлы в /usr управляются образом, содержимое /etc предназначено для конфигурации, а постоянное состояние размещается в /var.

Такая схема не использует классическую пару полноценных системных разделов A/B. На диске хранятся OSTree-развёртывания, из которых загрузчик выбирает нужное. Для оператора результат похож: действующая система продолжает работать во время подготовки новой версии, а переключение происходит при загрузке.

Состояние deployment можно посмотреть командой:

rpm-ostree status

Команда показывает активную версию, предыдущие развёртывания и отклонения от стандартного образа. Это одна из основных диагностических команд FCOS.

В Fedora CoreOS технически доступно расширение базового образа через rpm-ostree, однако превращать каждый сервер в индивидуально собранную систему не стоит. Чем больше наложенных пакетов и сторонних репозиториев, тем выше вероятность конфликтов при переходе на следующую базовую версию Fedora. Служебные программы предпочтительнее запускать в контейнерах, а повторяемые изменения хоста включать в управляемый собственный образ или декларативную конфигурацию.

Архитектура Flatcar Container Linux

Flatcar использует традиционную для семейства Container Linux схему с активным и пассивным системными разделами. Обновление записывается в неактивную область, после чего при перезагрузке разделы меняются ролями. Рабочая система не перезаписывается по частям в процессе загрузки обновления.

Системная область /usr предназначена для поставляемых проектом файлов и монтируется только для чтения. Изменяемые настройки и данные располагаются отдельно. Поэтому следует заранее определить, какие файлы относятся к конфигурации узла, а какие должны находиться внутри контейнерного образа или постоянного тома.

A/B-модель проста для понимания: предыдущая системная версия физически остаётся на втором разделе и может использоваться при проблемной загрузке. Цена такого подхода — выделение дискового пространства под две системные области. Для обычного VDS это редко становится главным ограничением, но схему разделов нужно учитывать при импорте, конвертации и изменении размера дискового образа.

Flatcar допускает расширение хоста через предусмотренные механизмы, включая systemd-sysext в подходящих сценариях, но общий принцип совпадает с FCOS: базовую ОС желательно сохранять максимально близкой к опубликованному образу. Ручная установка случайных бинарных файлов на каждый сервер ухудшает воспроизводимость и усложняет обновление.

Атомарные обновления: rpm-ostree и A/B-разделы

Обе системы выполняют атомарное переключение системной версии, но достигают этого разными способами.

Fedora CoreOS

FCOS получает сведения об обновлениях через инфраструктуру Fedora CoreOS, подготавливает новый rpm-ostree deployment и ожидает разрешённого момента для перезагрузки. За автоматическое обновление отвечает Zincati. Он применяет настроенную стратегию и позволяет распределять перезагрузки узлов во времени.

systemctl status zincati
journalctl -u zincati

Эти команды показывают состояние сервиса и его журнал. Модель rpm-ostree удобна для диагностики: оператор видит несколько развёртываний, их версии и отличия текущего узла от стандартного образа. Системное обновление считается завершённым только после загрузки новой версии.

Flatcar Container Linux

Flatcar загружает системный payload в пассивный раздел. После успешной записи сервер готов к переключению, но новая версия начинает работать только после перезагрузки. Встроенная система обновлений связана с выбранным каналом, а стратегию перезапуска можно согласовать с требованиями инфраструктуры.

Для централизованного управления распространением обновлений Flatcar может использовать сервер Nebraska. Это полезно большим паркам, которым недостаточно публичного канала и требуется самостоятельно определять группы машин, проценты раскатки и момент допуска версии.

Состояние клиента и журнал обновлений можно проверить командами:

update_engine_client --status
journalctl -u update-engine

Что это меняет для эксплуатации

С точки зрения приложения разница невелика: контейнерный узел всё равно нужно безопасно вывести из обслуживания и перезагрузить. Существеннее то, как команда наблюдает и контролирует процесс. В FCOS основной объект — OSTree deployment и политика Zincati. В Flatcar — системный раздел, release channel и update-engine.

Ни одна модель не делает допустимой одновременную перезагрузку всего кластера. Обновление хоста следует связывать с проверкой готовности реплик, выводом узла из балансировки и контролем восстановления контейнеров после загрузки. На одиночном VDS автоматическая перезагрузка создаёт период недоступности, если приложение не продублировано на другом узле.

Rollback и границы отката

В Fedora CoreOS предыдущий deployment обычно остаётся доступным. Перед откатом следует посмотреть состояние:

rpm-ostree status

Для выбора предыдущего развёртывания используется:

sudo rpm-ostree rollback
sudo systemctl reboot

Команда меняет deployment, который будет загружен следующим. До перезагрузки активная версия не изменяется. После запуска необходимо проверить rpm-ostree status, контейнерные службы и состояние приложения.

В Flatcar предыдущая версия находится на rollback-разделе. Если новая система не смогла подтвердить успешную загрузку, загрузчик может вернуться к прежней. Возможен и ручной откат, но его пределы связаны с содержимым второго раздела и поддерживаемыми механизмами загрузчика. Рассматривать его как универсальный способ перехода на любую историческую версию нельзя.

В обоих случаях rollback касается базовой ОС, но не возвращает состояние /etc, /var, контейнерных томов и внешних баз данных к прошлому моменту. Если новый контейнер выполнил несовместимую миграцию данных, откат ядра или container runtime её не отменит.

Системный rollback — средство восстановления загрузки и работоспособности хоста, а не замена резервным копиям и стратегии отката приложения.

Перед массовым обновлением нужно отдельно проверить совместимость формата данных, сетевых настроек, модулей ядра, средств наблюдения и контейнерного runtime. При наличии stateful-нагрузки необходим собственный план восстановления данных.

Ignition и декларативное развёртывание

Обе ОС используют Ignition для первоначальной настройки. Он запускается в initramfs на первом старте, до обычных системных служб, и может создавать разделы, файловые системы, пользователей, SSH-ключи, файлы и unit-файлы systemd.

Человек обычно не пишет итоговый JSON Ignition вручную. Для подготовки читаемой YAML-конфигурации применяется Butane, который проверяет схему и преобразует описание в Ignition. Fedora CoreOS и Flatcar используют разные варианты спецификации Butane, поэтому в исходном файле необходимо правильно указать вариант целевой ОС и поддерживаемую версию схемы.

Общность Ignition не означает полной взаимозаменяемости конфигураций. При миграции следует проверить:

• значение варианта и версии спецификации Butane;
• имена пользователей и наличие нужных групп;
• пути к исполняемым файлам контейнерного runtime;
• названия и параметры системных служб;
• сетевой стек и формат его конфигурации;
• разметку дисков и имена блочных устройств;
• способ передачи Ignition на выбранной платформе.

Ignition рассчитан на первый запуск свежего образа. Если виртуальную машину уже загрузили без корректной конфигурации, простая замена user-data обычно не приводит к повторному выполнению всех операций. Надёжный путь — исправить конфигурацию, проверить её валидатором и создать новый экземпляр из исходного образа.

Это особенно важно для шаблонов VDS. Нельзя один раз запустить виртуальную машину, настроить её Ignition, а затем без подготовки сохранить диск как универсальный шаблон. Клонируемые экземпляры должны стартовать из образа, на котором первый запуск ещё не состоялся.

Поддержка поля user-data в панели провайдера сама по себе недостаточна. Платформа должна передать данные тем способом, который ожидает выбранный образ: через metadata service, config-drive, QEMU fw_cfg, VMware guestinfo или другой поддерживаемый источник. Если панель принимает только cloud-config, преобразует YAML либо добавляет собственную оболочку, готовый JSON Ignition может не дойти до гостевой системы в исходном виде.

Контейнерный стек

Fedora CoreOS: акцент на Podman

Fedora CoreOS тесно интегрирована с контейнерными инструментами Fedora. Основной выбор для новых развёртываний — Podman, поддерживающий обычные OCI-образы, rootful- и rootless-режимы. Долгоживущие контейнерные сервисы удобно описывать через systemd и Quadlet, чтобы их запуск, зависимости и перезапуск контролировал менеджер служб.

В отдельных выпусках FCOS могут присутствовать Moby-совместимые компоненты, однако конкретный набор необходимо сверять по метаданным и release notes выбранного stream. Immutable-систему не следует проектировать с предположением, что любой привычный пакет навсегда останется в базовом образе.

Установка стороннего Docker CE поверх штатных компонентов способна создать конфликт зависимостей при переходе на новую базовую Fedora. Если приложение требует определённую сборку Docker, это следует проверять на тестовом stream и рассматривать как осознанное отклонение от стандартного состава, а не как обычную установку пакета на сервер.

Для выбора модели запуска self-hosted-сервисов полезно сравнить Podman, Docker Compose и systemd units на одном сервере.

Flatcar: Docker и containerd в базовой системе

Flatcar поставляет Docker и containerd как штатные компоненты. Такой состав удобен для инфраструктуры, где существующие сценарии запуска, средства мониторинга и инструкции эксплуатации уже построены вокруг Docker Engine.

Наличие обоих компонентов не означает, что ими следует независимо управлять одними и теми же контейнерами. Нужно заранее выбрать уровень интеграции: Docker API либо прямую работу с containerd через совместимый инструмент или оркестратор. Иначе диагностика образов, snapshotter, сетей и жизненного цикла контейнеров становится неоднозначной.

Flatcar чаще оказывается более прямым вариантом для переноса Docker-хостов со старых специализированных Container Linux-систем. Fedora CoreOS лучше соответствует Podman-first модели и практике описания контейнеров unit-файлами systemd.

Что сравнивать кроме названия runtime

• поддержку формата Compose, если он используется в production;
• rootless-режим и требования к user namespaces;
• работу cgroup v2 и ограничения ресурсов;
• сетевые плагины, правила firewall и IPv6;
• драйвер хранения и расположение каталога контейнерных данных;
• интеграцию с журналированием и сбором метрик;
• доступность multi-arch образов приложения;
• совместимость security-профилей и монтируемых устройств.

Переход с x86_64 на ARM64 требует multi-arch контейнеров. Наличие ARM64-образа самой ОС не поможет, если прикладной образ, агент резервного копирования, сетевой плагин или exporter собран только для AMD64.

Релизные каналы и жизненный цикл

Fedora CoreOS

FCOS использует три stream: next, testing и stable. Изменения проходят через последовательные стадии до stable. Поток next позволяет заранее проверять будущую базу Fedora и крупные изменения, testing используется для проверки кандидатов перед продвижением, а stable предназначен для основной эксплуатации.

Fedora CoreOS следует ритму Fedora и регулярно переходит на новые базовые выпуски. Отдельного многолетнего LTS-stream у проекта нет. Команда получает свежие ядро, systemd, Podman и исправления безопасности, но парк нельзя оставить на одной крупной базе на несколько лет, рассчитывая только на небольшие исправления.

Практичная схема — держать небольшую группу узлов на testing, проверять на ней реальные контейнеры и только затем допускать обновление основной stable-группы. Для критичных платформ необходимо следить не только за исправлениями уязвимостей, но и за изменениями cgroup, SELinux, сети, systemd и container runtime.

Flatcar Container Linux

Flatcar использует каналы Alpha, Beta, Stable и LTS. Новые крупные изменения появляются в Alpha, стабилизируются в Beta и затем продвигаются в Stable. Для основной эксплуатации обычно выбирают Stable, а несколько Beta-узлов включают в проверочный пул, чтобы раньше выявлять несовместимость с рабочими нагрузками.

LTS-потоки Flatcar предназначены для случаев, когда команде нужен более предсказуемый темп крупных изменений базовой ОС. Точный срок сопровождения, список поддерживаемых потоков и период их перекрытия не являются постоянными свойствами всех веток: их следует сверять по жизненному циклу именно выбранного именованного потока.

Общий канал lts указывает на актуальный LTS-поток и со временем может переводиться на следующий. Поэтому он не равнозначен фиксации одной крупной версии на весь срок её поддержки. Если компании нужен контролируемый момент перехода, при развёртывании следует выбрать именованный поток вида lts-YEAR, если он опубликован проектом, а затем вручную изменить его после тестирования.

LTS уменьшает частоту крупных изменений базовой ОС, но не отменяет установку исправлений, перезагрузки и проверку приложения. Кроме того, сроки поддержки относятся к самому Flatcar, а не к контейнерам, агентам и сторонним расширениям, установленным поверх него.

Образы Fedora CoreOS для x86_64 и ARM64

Fedora CoreOS публикует машиночитаемые метаданные для каждого stream. По ним инструменты развёртывания могут выбирать актуальный артефакт без фиксации номера выпуска в скрипте. При сравнении архитектур важно смотреть не только на наличие сборки: перечень платформенных вариантов для x86_64 и aarch64 может различаться.

Варианты, которые следует искать для обеих архитектур

Для VDS на KVM в первую очередь проверяют QEMU-образ, обычно QCOW2 в архиве qcow2.xz. Для OpenStack нужен отдельный OpenStack QCOW2-образ. Для установки на физический или виртуальный диск применяются metal raw-образы, а при наличии удалённой консоли могут использоваться Live ISO либо PXE-артефакты.

FCOS также публикует платформенные образы для облачных и виртуализационных окружений. Их набор для каждой архитектуры нужно проверять в метаданных нужного stream: артефакт для AWS, Azure, Google Cloud, Hyper-V, VMware или другой платформы не следует считать автоматически доступным и одинаковым для x86_64 и ARM64.

Где набор может различаться

Каталог x86_64 обычно шире для традиционных гипервизоров и специализированных облачных интеграций. ARM64 чаще ориентирован на KVM/QEMU, OpenStack, bare metal и облака с физическими AArch64-хостами. Отсутствие отдельного платформенного артефакта для ARM64 не обязательно исключает запуск: иногда подходит универсальный QEMU или raw-образ. Но в таком случае команда самостоятельно проверяет firmware, модель виртуальной машины, устройства virtio, консоль и способ передачи Ignition.

Что требуется от VDS для FCOS

• Для x86_64 KVM — импорт распакованного QCOW2 или raw-диска и совместимая виртуальная модель.
• Для ARM64 — физические ARM-серверы, виртуальный CPU AArch64 и обычно UEFI firmware.
• Для OpenStack — загрузка QCOW2 в Glance и datasource, передающий Ignition через поддерживаемые metadata.
• При установке из Live ISO или PXE — возможность указать источник Ignition и целевой диск для coreos-installer.
• Для диагностики первого запуска — serial console, поскольку графическая консоль не является основным интерфейсом серверной ОС.

Получать актуальный FCOS-образ предпочтительнее через метаданные stream или coreos-installer. Имя файла содержит номер выпуска, поэтому постоянная ссылка на один конкретный QCOW2 быстро превратит автоматизацию в развёртывание устаревшей версии.

Образы Flatcar для x86_64 и ARM64

Flatcar использует обозначения amd64 и arm64. На странице релизов сначала выбирают канал и архитектуру, затем платформу. Оба обозначения указывают на поддерживаемую архитектуру, но не гарантируют одинаковый набор готовых файлов для каждого гипервизора.

Варианты, которые следует искать для обеих архитектур

• QEMU UEFI: основной вариант для ARM64 и подходящий вариант для современных x86_64 ВМ; могут потребоваться дисковый образ, UEFI code и vars.
• OpenStack: отдельный production-образ, если он опубликован для выбранного канала и архитектуры.
• KubeVirt: готовый диск для виртуальной машины, если он присутствует в каталоге выпуска.
• Bare metal: установочный ISO, PXE/iPXE-артефакты и production-образ для записи на диск.
• Публичные облака: платформенные образы и инструкции, доступность которых зависит от архитектуры, региона и типа инстанса.

Особенность Flatcar состоит в том, что QEMU-артефакт может публиковаться как полный дисковый файл .img, а для UEFI-варианта рядом могут находиться отдельные файлы firmware variables и firmware code в QCOW2. Панель обычного VDS не всегда позволяет загрузить такой комплект целиком. Тогда провайдеру потребуется импортировать основной диск и настроить UEFI на стороне гипервизора либо предоставить готовый шаблон.

Где x86_64 обычно удобнее

Для amd64 чаще доступны специализированные варианты под распространённую традиционную виртуализацию: VMware, VirtualBox, Proxmox VE, Nutanix, Hyper-V и отдельные облачные платформы. Их наличие нужно сверять в каталоге выбранного релиза, поскольку список не фиксирован между каналами и версиями.

Для arm64 наиболее предсказуемыми остаются QEMU с UEFI, OpenStack, KubeVirt, bare-metal установка и поддерживаемые ARM-инстансы публичных облаков. Нельзя компенсировать отсутствие ARM64-артефакта загрузкой файла для amd64: это другая архитектура процессора и гостевой системы.

Что требуется от VDS для Flatcar

• Поддержка импорта полного дискового образа .img либо его корректной конвертации в формат платформы.
• Для ARM64 — UEFI и возможность загрузить AArch64-гостя на физическом ARM-хосте.
• Для QEMU — передача Ignition через fw_cfg или другой способ, который поддерживает выбранная платформенная сборка.
• Для OpenStack — config-drive или metadata service, совместимые с механизмом получения Ignition.
• Для VMware — guestinfo и соответствующий платформенный образ, если используется этот гипервизор.
• Serial console и доступ к параметрам загрузки для диагностики ошибок Ignition и update-engine.

Прямое сравнение образов для VDS

Для распространённого KVM-VDS на x86_64 Fedora CoreOS часто проще импортировать, когда в метаданных доступен отдельный QEMU QCOW2. У Flatcar доступность QEMU production-образа также нужно проверить, но платформа может ожидать конвертацию .img в QCOW2 или создание шаблона администратором гипервизора.

В OpenStack обе системы следует сравнивать по конкретному stream, каналу и архитектуре. При наличии специализированных образов это наиболее прямой вариант, если VDS-провайдер разрешает загружать собственные образы в Glance. Важно, чтобы платформа передавала Ignition, а не только обычный cloud-init.

Для ARM64 KVM обе ОС требуют не только образа, но и совместимого окружения: физического AArch64-хоста, UEFI, virtio-устройств и способа передать Ignition. Готовый FCOS QCOW2 может быть удобнее для панели с простым импортом диска. Flatcar удобен, если провайдер заранее подготовил корректный UEFI-шаблон и передачу Ignition. В таком случае различие исходных форматов перестаёт быть существенным.

Для VMware и VirtualBox преимущество по широте готовых x86_64-артефактов зависит от конкретного релиза. ARM64-каталоги обычно уже. Эти форматы редко нужны для публичного VDS, зато важны для локальных стендов и частной виртуализации.

Для установки через ISO или PXE обе ОС подходят при наличии KVM/IPMI-подобного доступа, виртуального носителя или управляемой сетевой загрузки. Это более универсальный путь, чем импорт диска, но он требует от платформы значительно больше возможностей, чем обычно предоставляет стандартная панель VDS.

Как проверить совместимость VDS-платформы

Фраза «поддерживается x86_64 или ARM64» ещё не гарантирует, что образ можно развернуть у конкретного провайдера. Нужно проверить четыре отдельных уровня:

1. проект собирает ОС для нужной архитектуры;
2. существует образ подходящей платформы и формата;
3. панель или API провайдера позволяют импортировать и загрузить этот образ;
4. виртуальная машина получает Ignition при первом старте.

Перед выбором ОС нужно уточнить:

• можно ли импортировать QCOW2, raw или .img и требуется ли предварительная распаковка;
• сохраняет ли конвертация GPT, загрузочные и A/B-разделы;
• можно ли передать готовый JSON Ignition без преобразования в cloud-config;
• поддерживаются ли config-drive, metadata service, fw_cfg или guestinfo;
• доступна ли serial console для диагностики первого запуска;
• какой firmware используется: BIOS или UEFI;
• можно ли менять размер системного диска после импорта;
• как задаются статические IPv4- и IPv6-адреса;
• для ARM64 — действительно ли ВМ запускается на AArch64, а не только предлагается ARM-тариф без пользовательских образов.

Архив .xz, .gz или .bz2 обычно нужно распаковать до импорта, если платформа прямо не поддерживает сжатый формат. Нельзя определять тип диска только по расширению после распаковки: raw и QCOW2 требуют разных параметров импорта.

Конвертация между raw и QCOW2 обычно допустима, если она выполняется инструментом работы с дисковыми образами без изменения разметки. Но преобразование VMDK, VHD или специализированного облачного образа в QCOW2 не гарантирует корректный запуск на обычном KVM: внутри могут присутствовать платформенные настройки и ожидания по metadata.

Если провайдер разрешает только предустановленные универсальные дистрибутивы и не даёт импортировать образ, подключать ISO или использовать PXE, развернуть FCOS или Flatcar как штатный контейнерный хост может быть невозможно. Установка их компонентов поверх другой ОС не равноценна исходному immutable-образу и лишает систему предусмотренной модели обновления.

Эксплуатация, миграция и выбор

Immutable-узлы желательно считать заменяемыми. Исправление критичной ошибки вручную по SSH допустимо как аварийная мера, но итоговое изменение должно попасть в Ignition, unit-файл, контейнерный образ или сборку системного образа. Иначе следующий сервер снова развернётся с дефектом.

Для обеих ОС полезно наблюдать за текущей системной версией и release channel, наличием подготовленного обновления, временем с последней перезагрузки, ошибками агента обновлений и загрузчика, свободным местом, состоянием systemd units и успешностью резервного копирования постоянных данных.

Для Fedora CoreOS основными источниками диагностики будут rpm-ostree status, журналы Zincati, systemd и container runtime. Для Flatcar — версия из /etc/os-release или Flatcar-specific файла release, состояние update-engine, загрузочные разделы, systemd и журналы Docker или containerd. Перед автоматизацией reboot необходимо определить, как узел выводится из балансировки.

Перейти с FCOS на Flatcar или обратно обычным обновлением нельзя. Это разные операционные системы с разной разметкой, каналами и составом пакетов. Безопасная миграция выполняется через создание нового пула узлов, перенос нагрузки и удаление старых экземпляров после проверки.

Наиболее частые источники несовместимости: unit-файлы вызывают docker, когда новая система рассчитана на Podman; Ignition-конфигурация использует неверный вариант Butane; агенты мониторинга ожидают записываемый /usr; контейнеры зависят от конкретных SELinux-меток; на ARM64 отсутствуют прикладные или служебные образы; провайдер по-разному передаёт metadata и user-data.

Контейнерное хранилище не следует переносить простым копированием внутренних каталогов Docker, Podman или containerd. Надёжнее заново получить образы из registry, а постоянные данные переносить на уровне приложения, тома или резервной копии.

Итоговое сравнение

• Системное обновление: Fedora CoreOS использует rpm-ostree deployments, Flatcar — активный и пассивный разделы.
• Агент обновлений: в FCOS ключевую роль играет Zincati, в Flatcar — update-engine и политика канала.
• Rollback: FCOS переключается на предыдущий deployment, Flatcar загружается с rollback-раздела.
• Provisioning: обе ОС используют Ignition, но требуют разных вариантов и версий схемы Butane.
• Контейнеры: FCOS ориентирована прежде всего на Podman, Flatcar штатно поставляет Docker и containerd.
• Жизненный цикл: FCOS непрерывно следует Fedora, Flatcar дополнительно предлагает LTS-потоки, условия которых необходимо проверять для выбранной ветки.
• x86_64: обе системы подходят для KVM и могут иметь широкий набор платформенных образов; для FCOS стоит искать QEMU QCOW2, для Flatcar — подходящий QEMU или production-образ.
• ARM64: обе ОС требуют AArch64-хоста и совместимой передачи Ignition; платформенный каталог следует сверять отдельно, а UEFI особенно важен для Flatcar QEMU.
• VDS: обе требуют поддержки пользовательского образа и корректного способа передачи Ignition при первом запуске.

Если нужен современный Podman-хост, тесная интеграция с Fedora и регулярное получение новых компонентов, сильнее выглядит Fedora CoreOS. Если важнее Docker-first стек, A/B-разделы, выбор темпа обновлений и LTS-потоки, практичнее Flatcar Container Linux.

Перед окончательным решением стоит развернуть по несколько тестовых VDS обеих архитектур, применить реальный Ignition, запустить production-подобные контейнеры, выполнить обновление и откат. Этот тест покажет совместимость образа, firmware, сети, persistent volumes и контейнерного стека с инфраструктурой конкретного провайдера.