Incus и LXD: контейнеры, которые ведут себя как машины

MAATRIX

Голый LXC даёт контейнер, но не даёт удобства: создать его, настроить сеть, снять снапшот и перенести на другой хост — всё это руками через конфиги и утилиты командной строки. Incus и LXD берут эту рутину на себя и превращают системный контейнер в объект, с которым работаешь почти как с виртуальной машиной — одной командой создал, одной снял снапшот, одной мигрировал. Разберём, что именно даёт эта прослойка и чем сейчас отличаются два инструмента, которые её реализуют.

Зачем нужна прослойка поверх LXC

LXC — это низкоуровневый набор инструментов и API для системных контейнеров на базе namespaces и cgroups. Он умеет главное — изолировать процессы, ограничивать ресурсы, — но не умеет удобно управлять парком контейнеров. Создание контейнера через lxc-create требует ручной возни с шаблонами и конфигурационными файлами, у сети нет встроенного менеджера мостов и DHCP, снапшоты и миграция между хостами не оформлены в простые команды. Это осознанный дизайн: LXC — библиотека и набор примитивов, а не система управления.

LXD и Incus — это демоны с REST API и клиентской командной строкой, которые работают поверх LXC (используя те же примитивы ядра) и добавляют слой управления: единый CLI, хранилище образов, сетевые профили, снапшоты, кластеризацию, живую миграцию. По сути это то же самое, что Proxmox делает для KVM-виртуалок, — прослойка управления поверх низкоуровневой технологии, — только здесь низкоуровневая технология — LXC-контейнеры, а не QEMU/KVM. Разница между «сырым» LXC и Incus/LXD такая же, как между «настроить сеть виртуалки руками через virsh» и «нажать кнопку в Proxmox».

Важно: и Incus, и LXD — это инструменты для системных контейнеров (полноценный Linux с init-системой, своим адресным пространством пользователей, возможностью крутить несколько сервисов), а не для одноразовых контейнеров одного приложения в духе Docker. Если нужна база про разницу между контейнерами и полноценными VM в принципе, у нас есть отдельный разбор — KVM или LXC: что выбрать для сервера. Здесь речь не про «контейнер против VM» вообще, а про то, каким инструментом удобнее управлять системными LXC-контейнерами, когда вы уже решили, что вам нужен именно контейнер, а не виртуалка.

Управление жизненным циклом: контейнер как объект

Ключевая ценность Incus/LXD — контейнер перестаёт быть набором файлов в /var/lib/lxc и становится объектом с понятным жизненным циклом. Создание из готового образа:

# LXD
lxc launch images:debian/12 my-container

# Incus (синтаксис идентичен, команда просто называется incus)
incus launch images:debian/12 my-container

Дальше с контейнером работают так же, как с VM в Proxmox или libvirt:

incus stop my-container
incus start my-container
incus restart my-container
incus delete my-container
incus exec my-container -- bash
incus list

Ничего из этого в голом LXC не выглядит так просто — там нужно отдельно поднимать шаблон, руками прописывать конфиг сети и подключать rootfs. Здесь же весь workflow — создание, остановка, удаление, вход в консоль — единообразен и не требует знания внутреннего устройства namespaces и cgroups. Это тот самый «VM-подобный» опыт: команды и ментальная модель такие же, как при работе с виртуальными машинами, хотя под капотом — контейнер, а не гипервизор.

Снапшоты и клонирование без ручной возни

В сыром LXC снапшот контейнера — это ваша забота: либо ручной rsync файловой системы, либо самостоятельная настройка LVM/ZFS-снимков под каждый контейнер. Incus и LXD берут это на себя через встроенный слой хранилища:

incus snapshot create my-container before-upgrade
incus snapshot list my-container
incus snapshot restore my-container before-upgrade
incus copy my-container my-container-clone

Под капотом используется storage pool — ZFS, Btrfs, LVM или обычная директория, — и Incus/LXD сам решает, как эффективно сделать снапшот на выбранном бэкенде (copy-on-write для ZFS/Btrfs, LVM-снимки для LVM). Вам не нужно знать команды zfs snapshot или lvcreate --snapshot — интерфейс одинаковый независимо от бэкенда. Это прямая аналогия с тем, как Proxmox абстрагирует снапшоты VM от конкретного типа хранилища — тот же принцип, но применительно к LXC-контейнерам, что подробно разобрано в статье снапшоты в Proxmox: как устроены на примере полноценных VM.

Клонирование (copy) работает так же просто и полезно для быстрого тиражирования одинаковых окружений — например, поднять пять идентичных тестовых контейнеров из одного шаблона за секунды, без повторной установки системы и пакетов в каждом.

Сеть и хранилище: управление, а не только примитивы

Голый LXC ожидает, что вы сами настроите мост (br0), пропишете его в конфиге контейнера и позаботитесь о DHCP. Incus и LXD добавляют собственный слой сетевого управления:

incus network create my-bridge ipv4.address=10.10.10.1/24 ipv4.nat=true
incus network attach my-bridge my-container eth0
incus network list

Команда network create поднимает управляемый мост со своим DHCP-сервером и NAT одной строкой — то, что в голом LXC потребовало бы правки /etc/network/interfaces или netplan, плюс настройки dnsmasq вручную. Дополнительно доступны сетевые профили — шаблоны конфигурации, которые применяются сразу к группе контейнеров, что удобно, если у вас несколько однотипных сервисов на одном хосте.

То же самое со storage pool — единый интерфейс поверх ZFS, Btrfs, LVM, dir или даже Ceph для кластерных конфигураций:

incus storage create my-pool zfs size=50GiB
incus storage volume create my-pool my-data
incus config device add my-container data disk pool=my-pool source=my-data path=/data

Каждый контейнер может использовать свой storage pool или общий — это ближе к тому, как в Proxmox можно выбрать хранилище под конкретную VM или диск, только здесь речь про volume для контейнера. Разбор похожей логики выбора хранилища для VM — в статье хранилища в Proxmox: что и когда; принцип «единый интерфейс поверх разных бэкендов» там применяется к VM, а в Incus/LXD — к контейнерам.

Живая миграция между хостами

Ещё одна возможность, которой нет в голом LXC «из коробки», — перенос контейнера на другой физический сервер без остановки сервиса (при совместимом хранилище и сети):

# на исходном хосте
incus config set core.https_address "[::]:8443"
incus config trust add

# на целевом хосте — добавляем исходный как remote
incus remote add source-host https://source-ip:8443
incus move my-container source-host:my-container --target=target-host

На практике живая миграция контейнеров работает надёжнее, чем миграция полноценных VM, потому что переносить нужно только файловую систему и метаданные, а не весь образ памяти с состоянием процессора. Но это не полностью бесшовно: сетевые подключения к контейнеру на время переноса дискретны, а для миграции без общего хранилища данные копируются по сети, и время простоя зависит от объёма данных на диске — на десятках гигабайт это может занять заметное время. Для полноценных VM логика переноса между хостами устроена иначе и заслуживает отдельного рассмотрения — здесь мы говорим именно про контейнеры.

История разделения: почему LXD и Incus — два проекта

LXD изначально разрабатывался и поддерживался Canonical (компанией, стоящей за Ubuntu) как надстройка над LXC с удобным CLI и REST API. Проект много лет был де-факто стандартным способом получить «VM-подобный» опыт работы с LXC-контейнерами в экосистеме Ubuntu.

В 2023 году Canonical изменила модель управления проектом LXD — разработка была перенесена под более закрытую корпоративную структуру с иными условиями участия сообщества и лицензирования отдельных компонентов, чем было принято в предыдущей открытой модели разработки. В ответ часть основных разработчиков LXD (включая изначального технического лида проекта) начала независимый форк под названием Incus, размещённый под эгидой Linux Containers — того же проекта, который курирует LXC. Incus сохранил архитектуру и большую часть CLI-синтаксиса LXD (команды почти идентичны, разница чаще всего только в названии бинарника — lxc против incus), но развивается как отдельный проект со своим сообществом и циклом релизов.

Мы намеренно излагаем это нейтрально, без оценки «кто прав»: у Canonical есть свои причины для выбранной модели монетизации и управления проектом, у сообщества вокруг Incus — свои резоны для форка. Это стандартная для open source ситуация расхождения после смены модели управления проектом, аналогичная другим известным форкам в экосистеме.

Какую ветку выбрать сейчас

На конец августа 2026 года обе ветки — и LXD, и Incus — активно поддерживаются и получают обновления, но направление развития сообщества и большинства линуксовых дистрибутивов постепенно смещается в сторону одного из проектов. Мы намеренно не называем здесь однозначного победителя: ситуация с активностью репозиториев, частотой релизов и тем, какую ветку упаковывают по умолчанию основные дистрибутивы, могла измениться с момента написания этого материала. Перед стартом нового проекта стоит буквально потратить пять минут и проверить:

• дату последнего релиза и частоту коммитов в официальных репозиториях обоих проектов;
• какая версия идёт «из коробки» в актуальном на момент чтения выпуске вашего дистрибутива (Debian, Ubuntu, Alpine и т. д.) — пакетные менеджеры дистрибутивов часто быстрее всего отражают, куда сместилось сообщество;
• активность форумов и issue-трекеров — количество открытых и закрытых задач говорит о живости поддержки больше, чем маркетинговые страницы.

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

Практические сценарии использования

Incus/LXD особенно уместны там, где нужна полноценная Linux-система с изоляцией уровня отдельного сервера, но накладные расходы полной виртуализации избыточны:

• Тестовые и dev-окружения. Контейнер стартует за секунды, занимает минимум памяти по сравнению с VM, и снапшот перед рискованным экспериментом снимается одной командой — удобно поднимать и сносить окружения десятки раз в день.
• Изоляция нескольких сервисов на одном физическом сервере. Если у вас достаточно мощный выделенный сервер и несколько независимых Linux-сервисов (не Docker-приложений, а именно полноценных систем с разными пользователями, cron-задачами, systemd-юнитами), контейнеры Incus/LXD дают изоляцию между ними без накладных расходов полной виртуализации на каждый.
• Лёгкая альтернатива Proxmox. Если вам не нужны Windows-гостевые системы, вложенная виртуализация или полная аппаратная изоляция, а нужна быстрая, управляемая через понятный CLI или веб-интерфейс инфраструктура Linux-контейнеров — Incus (у него есть встроенный веб-интерфейс) закрывает эту задачу с меньшим потреблением ресурсов хоста, чем Proxmox с KVM-виртуалками.
• Хостинг нескольких клиентских Linux-окружений на одном сервере провайдера. Модель, близкая к тому, что раньше делал OpenVZ, — см. виртуализация: KVM против OpenVZ для исторического контекста контейнерной виртуализации у хостеров.

Ограничение стоит проговорить честно: если приложению нужно собственное ядро, кастомные модули ядра или запуск не-Linux ОС, контейнер (любой — что LXC, что Incus/LXD, что Docker) здесь не поможет в принципе, это ограничение архитектуры, а не конкретного инструмента управления. В таком случае нужна полная виртуализация — KVM через Proxmox или libvirt напрямую.

Частые вопросы