Incus как мост между Docker и системными контейнерами

Incus как мост между Docker и виртуальными машинами

Docker отлично подходит для упаковки приложений, а Kubernetes — для оркестрации кластеров. Но для appliance-решений, изолированных окружений и staging оба инструмента оказываются либо слишком лёгкими, либо слишком тяжёлыми. Docker превращает каждый сервис в набор контейнеров с костылями для данных и логов. Kubernetes требует манифестов, etcd и CNI даже для простого Nextcloud. А Proxmox при всех своих возможностях остаётся гипервизором с кастомным ядром, которое ломает драйверы и обновляется с задержками на месяцы.

Между ними остаётся ниша, которую Incus заполняет лучше всех остальных: это системные контейнеры, которые ведут себя как полноценные Linux-серверы, но при этом остаются лёгкими, быстрыми и простыми в управлении. В октябре 2023 года форк LXD превратился в независимый проект Incus, после того как Canonical перелицензировала LXD на AGPLv3 и ввела обязательное подписание CLA для новых контрибьюторов. Стефан Грабер, бывший ведущий инженер LXD, возглавил команду Incus — и проект получил независимый импульс развития.

Docker не для системных ролей
Docker оптимизирован под микросервисы: один контейнер — один процесс, логирование в stdout, образы как единственный способ обновления. Если развернуть в Docker PostgreSQL вместе с приложением, то для данных, логов и пользователей придётся городить объёмные конфигурации. Такой подход работает, когда приложение действительно изолировано, но превращается в костыли, когда нужен полноценный сервер с systemd, cron, пользователями и пакетным менеджером.

Пример: Nextcloud на Docker требует как минимум три контейнера — веб-приложение, Redis и базу данных. Каждый контейнер обновляется отдельно, каждый хранит логи по-своему. В Incus тот же стек можно развернуть в одном системном контейнере с Debian, PostgreSQL и Nginx. Обновления делаются привычно: apt update && apt upgrade. Те же инструменты, тот же контроль, но без оверхеда виртуальных машин.

Kubernetes — избыточен для appliance
Kubernetes — мощный инструмент, но его оверхед на etcd, CNI и манифесты не оправдан, когда нужны isolated tenant environments или staging с быстрым клонированием. В Kubernetes контейнеры часто становятся sidecar к манифестам, а управление пользователями, cron и пакетами — через кастомные операторы.

Incus не требует ни кластеров, ни манифестов. Контейнеры запускаются так же просто, как приложения в Docker, но с полным контролем над окружением: systemd, cron, пользователи, пакетные менеджеры. Это не оркестрация, но и не упаковка ради упаковки — это управление системными окружениями без виртуальных машин.

Proxmox: гипервизор с проблемами
Proxmox критикуют не за функциональность, а за реализацию. Кастомное ядро на базе Ubuntu ломает драйверы (например, Realtek или OpenVPN) и обновляется с задержками на месяцы. Даже простой старт системы замедляется из-за лишних демонов и плохо написанных сервисов. В одном из отчётов приводится пример, когда после обновления хоста Proxmox контейнеры LXC перестали запускаться из-за несовместимости ядра.

Incus лишён этих проблем. Он не привязан к конкретной дистрибуции или ядру, работает поверх стандартного LXC и не требует кастомных патчей. Это не гипервизор, но и не легковесная упаковка — это мост между ними.

Почему Incus, а не LXD
В октябре 2023 года Canonical изменила лицензию LXD на AGPLv3 и ввела обязательное подписание CLA для новых контрибьюторов. Это фактически закрыло путь для импорта изменений в форк. Incus остался под Apache 2.0 и перешёл под управление команды вокруг Стефана Грабера.

Что это меняет на практике:

• LXD теперь зависим от решений Canonical. Новые функции могут блокироваться юридически.
• Incus развивается независимо, без риска внезапных лицензионных изменений.
• Сообщество вокруг Грабера обеспечивает стабильное развитие, а не маркетинговые циклы.

Миграция нужна не всем. Если LXD уже стабильно работает и не планируются крупные обновления инфраструктуры, смысла в срочной миграции нет. Но для новых проектов Incus — более надёжный выбор.

Как Incus закрывает разрыв
Incus запускает системные контейнеры, которые ведут себя как полноценные Linux-окружения: поддерживают systemd, cron, пользователей и пакетные менеджеры. Это не приложение в Docker, не sidecar в Kubernetes, а отдельный сервер внутри контейнера.

Пример из практики:

• Home Assistant развёрнут как ВМ (из-за сложностей с контейнеризацией).
• NAS-сервисы (Syncthing, Samba) работают в системном контейнере на Debian 12.

Такой подход сочетает лёгкость Docker с контролем системных контейнеров:

• Быстрое развёртывание: incus launch images:debian/12 myapp.
• Управление как отдельным сервером: incus exec myapp apt update.
• Возможность запускать Docker внутри контейнера (например, для CI/CD).

Что не хватает Docker:

• Нет нормального управления пользователями и cron.
• Volume-ы — костыль для данных, а не полноценная файловая система.
• Нет встроенной поддержки миграций между хостами с разными ядрами.

Incus не заменяет Docker для упаковки приложений, но становится лучшим выбором для системных ролей.

Что нового в Incus 0.4
В декабре 2023 года вышла версия 0.4 с изменениями, которые важны для production:

• Режим keep-alive в CLI-клиенте: снижение латентности до 30% для сценариев с частым запуском команд (например, Ansible).
• Поддержка описаний для сертификатов, улучшенный вывод incus config trust list.
• Новые ключи конфигурации для OVN (CephFS, SSL-сертификаты).
• Возможность прямого создания CephFS-файловых систем без предварительной настройки в Ceph.

Эти изменения делают Incus более удобным для окружений, где важны производительность и удобство управления.

Где Incus выигрывает

• Appliance-решения (Nextcloud, ERP, AI):
  Один контейнер с Nextcloud, PostgreSQL, Redis и Nginx вместо трёх Docker-контейнеров. Быстрое клонирование для staging, миграции между серверами без изменений конфигурации.

• AI-окружения:
  Изоляция окружения для моделей с зависимостями (CUDA, специфичные библиотеки). Можно заморозить контейнер с моделью и развернуть на другом хосте без проблем с совместимостью.

• Коммуникационные шлюзы (почта, VPN, VoIP):
  Отдельный контейнер для каждого сервиса с полным контролем над сетью. Проще управлять firewall-ом (например, включить ufw внутри контейнера).

• Изоляция клиентов (tenant isolation):
  Разграничение окружений на одном сервере без полноценных ВМ. Быстрое создание/удаление изолированных инстансов.

Incus позволяет управлять окружениями так, как это делают с отдельными серверами: через systemd, cron, пакетные менеджеры и стандартные инструменты мониторинга.

Когда мигрировать, а когда оставить LXD
Миграция с LXD на Incus нужна, если:

• Вы собираетесь разворачивать новые appliance-решения (Nextcloud, ERP, AI).
• Вам важна независимость от решений Canonical и стабильное развитие проекта.
• Вы хотите избежать юридических рисков, связанных с CLA и лицензией AGPLv3.

Если LXD уже стабильно работает и не планируются крупные обновления инфраструктуры, миграция не обязательна. Но если вы начинаете проект с нуля, Incus — более предсказуемый выбор.

Чистый вывод
Incus — это инструмент, который сочетает лёгкость Docker с контролем системных контейнеров. Он не заменяет Docker для упаковки приложений, но становится лучшим выбором для appliance-решений, изолированных окружений и staging.

Если вы собираете self-hosted-инфраструктуру, где важны изоляция, клонирование и миграции, Incus стоит рассмотреть. Если же у вас уже стабильно работает LXD и нет планов на масштабные изменения, смысла в миграции нет — пока.