Налаштування systemd-nspawn для ізоляції Linux-контейнерів

Налаштування контейнерної віртуалізації systemd-nspawn

Уявіть: вам потрібне ізольоване середовище для CI-збірок на сервері з жорсткими політиками безпеки. Docker демон заборонений через SELinux або airgap, а повноцінна віртуалка на KVM витрачає занадто багато ресурсів (RAM, CPU, диск). systemd-nspawn — вбудований у systemd інструмент, який вирішує це завдання без встановлення додаткових пакетів і окремого демона. Ми використовуємо його понад 5 років у продакшені для десятків проектів і гарантуємо стабільну ізоляцію з мінімальним оверхедом. Економія на ліцензійних відрахуваннях може бути суттєвою, а зниження витрат на обчислювальні ресурси — до 40% при переході з Docker.

systemd-nspawn працює на основі namespaces та cgroups v2, керується командами systemctl і machinectl. На відміну від chroot, він ізолює PID, IPC, UTS та монтування. З PrivateUsers=yes — ще й user namespaces, що дозволяє запускати контейнери без root. Це легше Docker (немає демона, registry, overlayfs), швидше LXC, і ідеально для: ізольованих збірок, тестування скриптів встановлення, chroot-середовищ, IoT-пристроїв з обмеженими ресурсами.

Чому systemd-nspawn швидше Docker?

nspawn не вимагає запуску окремого демона — контейнер стартує як дочірній процес systemd. Час запуску: ~0.5 секунди проти 3-5 секунд у Docker (з pull образу). Економія оперативної пам'яті: до 200 MB на сервер за рахунок відсутності dockerd, containerd і registry.

Порівняння продуктивності

Таблиця показує: nspawn швидше в 4-10 разів при старті і не потребує демона, що критично для airgapped середовищ і CI-раннерів з обмеженими ресурсами.

Покрокова інструкція: створення та налаштування контейнера

1. Встановлення базової системи. Використовуйте debootstrap для Debian/Ubuntu в /var/lib/machines/:

   debootstrap --arch=amd64 jammy /var/lib/machines/mycontainer http://archive.ubuntu.com/ubuntu/ 

2. Запуск контейнера. Інтерактивно: systemd-nspawn -D /var/lib/machines/mycontainer. Для повноцінного завантаження з systemd init: --boot.
3. Налаштування конфігурації. Створіть файл /etc/systemd/nspawn/mycontainer.nspawn:

   [Exec] PrivateUsers=yes [Network] VirtualEthernet=yes [Files] Bind=/opt/app:/app 

4. Мережевий доступ. Увімкніть IP-форвардинг на хості та налаштуйте NAT:

   iptables -t nat -A POSTROUTING -s 192.168.163.0/24 -j MASQUERADE 

   Для автоматичного налаштування використовуйте systemd-networkd з IPMasquerade=yes.
5. Обмеження ресурсів. Через systemd unit override:

   systemctl edit [email protected] 

   Додайте CPUQuota=50%, MemoryMax=1G, MemorySwapMax=0.
6. Автостарт. Виконайте machinectl enable mycontainer — тепер контейнер запускається при завантаженні системи.

Як налаштувати мережу для контейнера?

При VirtualEthernet=yes створюється veth-пара: один кінець у контейнері (зазвичай host0), інший на хості з ім'ям ve-<container>. Для доступу назовні потрібен NAT через iptables або IPMasquerade в systemd-networkd. Альтернативно можна використовувати bridge-мережу: створіть bridge (наприклад, br0) і вкажіть у .nspawn Bridge=br0 (потрібне додаткове налаштування DHCP на bridge).

Порівняння способів підключення мережі

Знімки та клонування через btrfs

Якщо файлова система — btrfs, machinectl clone створює миттєві знімки без копіювання даних. Це зручно для CI: за пару секунд можна розгорнути десятки ізольованих середовищ.

# Клонувати контейнер для тестів
machinectl clone mycontainer mycontainer-test

# Відкотити зміни
machinectl clone mycontainer-backup-latest mycontainer

Інтеграція з CI

nspawn-контейнери легко вбудовуються в GitLab CI або Jenkins: кожна джоба отримує свіжий знімок, після завершення контейнер видаляється. Навантаження на CPU при паралельних збірках контролюється через CPUQuota — можна виставити 25% на джобу.

Що входить у налаштування systemd-nspawn під ключ?

Наші інженери з 5-річним досвідом у DevOps виконують:

• Аудит інфраструктури: оцінка необхідності ізоляції, сумісність з btrfs, поточні політики безпеки.
• Створення контейнерів: вибір дистрибутива, налаштування .nspawn, оптимізація під навантаження.
• Мережа: налаштування NAT, bridge, firewall rules, DNS (systemd-resolved).
• CI-інтеграція: автоматичне клонування знімків для джоб, очищення після завершення.
• Документація та навчання: runbook з управління, шаблони для типових завдань.
• Підтримка: 2 тижні після впровадження (виправлення помилок, доналаштування).

Терміни: від 1 дня для базового контейнера до 3 днів для multi-container setup з CI. Вартість розраховується індивідуально. Отримайте консультацію — оцінимо ваш проект.

Чому обирають systemd-nspawn?

• Жодних зайвих демонів: не потрібен Docker daemon, registry, overlayfs. Економія пам'яті до 200 MB на сервер.
• Надійність: працює навіть на зламаній системі, якщо живий systemd.
• Швидкість: контейнер стартує за 0.5 секунди проти 3-5 у Docker.
• Простота: один конфігураційний файл, знайома система керування (systemctl).

Якщо ваше завдання — ізольоване середовище без Docker-daemon, systemd-nspawn — оптимальне рішення. Замовте налаштування — ми реалізуємо під ваші вимоги.

Зв'яжіться з нами для обговорення інтеграції — ми підберемо оптимальну конфігурацію. Документація systemd: https://www.freedesktop.org/software/systemd/man/systemd-nspawn.html