Контейнер LXC — это системный контейнер: внутри него работает полноценная операционная система со своими пользователями и службами, но ядро (главную программу, которая управляет железом) он делит с хостовой машиной — тем сервером, на котором запущен. Из-за общего ядра такой контейнер съедает примерно 10–30 МБ оперативной памяти вместо 200–500 МБ, которые уходят на полноценную виртуальную машину с той же ОС. Поэтому на сервере с 4 ГБ памяти реально держать 15–20 контейнеров вместо трёх-четырёх виртуалок, и по той же причине контейнерные тарифы дешевле. Разворачивают их на VPS с Linux, где есть root-доступ.
Материал для тех, кто впервые встретил слово LXC в панели провайдера или в документации Proxmox. Разберём устройство изоляции, сравнение накладных расходов в цифрах, ограничения общего ядра, установку на Ubuntu с набором команд, лимиты по памяти и процессору и типовые ошибки новичков.
Что такое системный контейнер и чем он отличается от контейнера приложения
LXC расшифровывается как Linux Containers — это набор инструментов, который запускает изолированное окружение поверх ядра хоста. Когда контейнер стартует, внутри него поднимается настоящий init-процесс (systemd или SysV) — первая программа системы, которая запускает все остальные службы, ведёт логи и крутит задачи по расписанию. Вы заходите внутрь и видите привычный Debian или Ubuntu: работает apt, есть каталог /etc с настройками, есть свои учётные записи.
Разница с Docker принципиальная и лежит не в технологии, а в назначении. Docker создан, чтобы упаковать один процесс — веб-сервер, бота, базу — и запустить его так, чтобы он вёл себя одинаково на ноутбуке разработчика и на бою. Init внутри докер-контейнера обычно нет, службы не стартуют, а всё, что записано в файловую систему, по умолчанию исчезает при пересоздании контейнера.
LXC ведёт себя как маленький сервер, который живёт годами: перезагружается, накапливает данные, обновляется через apt. Docker ведёт себя как программа: её убивают и поднимают заново из образа десятки раз в день. Правило простое: нужен «ещё один сервер» — LXC, нужен «ещё один сервис в сборке» — Docker.
Обе технологии стоят на одном фундаменте — механизмах ядра Linux namespaces («пространства имён») и cgroups («контрольные группы»). Первые дают контейнеру своё дерево процессов, свою сеть и свою файловую систему. Вторые режут потолок по памяти и процессорному времени, чтобы один контейнер не задушил соседей.
Почему общее ядро экономит память и что за это приходится отдать
Полноценная виртуальная машина под управлением KVM получает эмулированное железо: свой BIOS, свои виртуальные диски, свою сетевую карту. Поверх этого железа грузится отдельное ядро, которое сразу занимает память под собственные структуры, кеши и драйверы. Даже пустая виртуалка с Debian после загрузки показывает 200–500 МБ занятой памяти, из которых полезной нагрузки почти нет.
Контейнер не грузит ядро — он им пользуется. Запуск LXC-контейнера с той же Debian — это, по сути, старт нескольких десятков процессов в изолированном пространстве имён. Отсюда 10–30 МБ накладных расходов и старт за 1–2 секунды против 20–40 секунд у виртуальной машины, которой нужно пройти полный цикл загрузки.
Плата за экономию — потеря независимости. Версия ядра у вас ровно та, что стоит на хосте, и поменять её изнутри нельзя. Если провайдер работает на ядре 5.15, а софту нужны возможности 6.6, вариантов два: просить провайдера или переезжать на виртуалку. Устройство слоёв разобрано в материале о том, что такое виртуализация серверов.
Второе следствие общего ядра — контейнер всегда Linux. Windows Server в LXC не запустится ни при каких настройках: ему нужно собственное ядро NT.
LXC, Docker и KVM: таблица различий по восьми признакам
Три технологии часто ставят в один ряд, хотя решают они разные задачи. Ниже сведены свойства, которые реально влияют на выбор: что внутри, сколько ест, что можно менять и насколько прочна изоляция.
| Признак | LXC | Docker | KVM |
|---|---|---|---|
| Что внутри | Полная ОС с init | Один процесс | Полная ОС со своим ядром |
| Накладные расходы памяти | 10–30 МБ | 5–20 МБ | 200–500 МБ |
| Время старта | 1–2 с | меньше 1 с | 20–40 с |
| Ядро | Общее с хостом | Общее с хостом | Своё |
| Данные после перезапуска | Сохраняются | Теряются без тома | Сохраняются |
| Своя версия ядра и модули | Нет | Нет | Да |
| Windows внутри | Нет | Нет | Да |
| Плотность на 8 ГБ RAM | 30–50 штук | 50–100 штук | 6–10 штук |
Цифры плотности приблизительные: они считаются от накладных расходов, а не от потребления вашего софта. Если каждому контейнеру нужен PostgreSQL с буфером 256 МБ, экономия на оболочке роли уже не играет.
Когда выбирать Docker, а когда LXC: разбор по задачам
Спор «Docker или LXC» решается вопросом: вам нужна изоляция приложения или изоляция окружения. Если вы разворачиваете Python-бота, Node-сервис или связку из пяти небольших сервисов, которую описывает один compose-файл (текстовый файл с перечнем контейнеров и их настроек), — это территория Docker. Образ собирается один раз, переносится куда угодно, откат к прошлой версии занимает секунды.
Если вам нужен отдельный «сервер» под клиента, тестовый стенд с полным набором LAMP (Linux, Apache, MySQL, PHP), машина под 1С или окружение, куда несколько человек ходят по SSH и ставят пакеты руками, — это LXC. Внутри работает systemd, запускаются службы, живёт cron, и весь привычный опыт администрирования Linux переносится без переучивания.
На практике это не конкуренты, а слои. Частая схема: на сервере поднимают LXC-контейнеры под разные проекты, а внутри контейнера крутят Docker с сервисами. Граница между клиентами проходит по контейнеру, между сервисами — по образам. Если Docker вы ещё не ставили, начните с инструкции о том, как установить Docker.
Есть и обратная ситуация, когда контейнеры не подходят вовсе. Нужны свои модули ядра, вложенная виртуализация, Windows, отладка через собственный отладчик ядра или жёсткое требование по изоляции от соседей — берите KVM и не экономьте. Что именно даёт полная аппаратная виртуализация, разобрано в гайде о том, что такое KVM-виртуализация.
OpenVZ, LXC и «плавающая» память в тарифах провайдеров
У хостеров контейнерная виртуализация встречается в двух видах. Исторически это OpenVZ — давняя российская разработка, устроенная по тому же принципу общего ядра. Сейчас её постепенно вытесняет LXC, часто под управлением Proxmox VE, но в прайсах старое название ещё живёт.
Контейнерные тарифы дешевле KVM при тех же гигабайтах — разница по каталогу составляет примерно 30–50 % за сопоставимую конфигурацию. Причина в плотности: на одну физическую машину провайдер помещает в 4–6 раз больше контейнеров, чем виртуалок, и делит стоимость железа на большее число клиентов.
Обратная сторона — «плавающая» память: гигабайты не закрепляются за клиентом жёстко, а выдаются из общего котла. Пока соседи спят, доступно больше заявленного, а в час пик процесс получает отказ в выделении памяти, хотя лимит формально не выбран. У KVM 2 ГБ означают ровно 2 ГБ, выделенные при старте машины.
Отсюда вывод. Под сайт-визитку, бота, стенд или мониторинг контейнер подходит и экономит деньги. Под базу данных, биллинг и всё, где отказ в памяти означает потерю денег, берите KVM даже за двойную цену.
На каком сервере разворачивать LXC и сколько это стоит
Для запуска своих LXC-контейнеров нужен сервер с root-доступом и правом загружать модули ядра — дополнения, которые добавляют ядру поддержку устройств и функций. Такие права даёт KVM-виртуалка или физическая машина. Внутри чужого контейнера вложенный LXC чаще всего не поднимется: провайдеры отключают такую возможность. Если же вы просто хотите арендовать готовый контейнер как VPS, подойдут недорогие VPS на контейнерной виртуализации — они и стоят меньше всего.
Под три-четыре лёгких контейнера хватит 2 ядер, 2 ГБ памяти и 20 ГБ диска. Под десяток контейнеров с базами закладывайте 4 ядра, 8 ГБ и 80 ГБ NVMe: каждый шаблон Ubuntu занимает 400–600 МБ, а после установки пакетов вырастает до 1,5–2 ГБ.
| Провайдер | Стартовая цена | Что входит в младший тариф | Тарифов в каталоге |
|---|---|---|---|
| Cloudcore | от 59 ₽/мес | 1 ядро, 1 ГБ RAM, 10 ГБ NVMe | 12 |
| Hosting-Russia | от 99 ₽/мес | стартовая контейнерная конфигурация | — |
| 4VPS | от 110 ₽/мес | 1 ядро, 1 ГБ RAM, 5 ГБ NVMe | 568 |
| HostVDS | от 127 ₽/мес | 1 ядро, 1 ГБ RAM, 10 ГБ NVMe | 12 |
Данные проверены 04.09.2026.
Цены собраны по 44 площадкам каталога и относятся к младшим тарифам. Для собственного хоста под контейнеры смотрите на конфигурации от 8 ГБ памяти: там начинается смысл держать свой LXC вместо аренды нескольких мелких VPS.
Установка LXC на Ubuntu и запуск первого контейнера
Дальше — рабочая последовательность для Ubuntu 22.04 или 24.04. Команды выполняются от root или через sudo, подключение к серверу — по SSH.
- Обновите список пакетов и поставьте сам LXC вместе с утилитами для сетевого моста:
apt update && apt install -y lxc lxc-templates bridge-utils. Пакет lxc-templates даёт шаблоны дистрибутивов, bridge-utils нужен для сети между контейнерами. - Проверьте, что ядро готово к контейнерам:
lxc-checkconfig. Команда выводит список возможностей ядра: нужные строки должны быть в состоянии enabled, а красные missing означают, что такой опции в ядре нет. - Создайте первый контейнер из готового образа:
lxc-create -n web1 -t download -- -d ubuntu -r jammy -a amd64. Здесь web1 — имя контейнера, download — шаблон, который качает готовый образ, а после двойного дефиса идут дистрибутив, релиз и архитектура. - Запустите его:
lxc-start -n web1. Контейнер поднимется за 1–2 секунды и продолжит работать в фоне — никакого вывода в вашу консоль при этом не появится. - Проверьте состояние и адрес:
lxc-ls -f. Ключ-fвыводит таблицу со статусом RUNNING и полученным IP-адресом вида 10.0.3.x. - Зайдите внутрь:
lxc-attach -n web1. Вы попадаете в оболочку контейнера от имени root и работаете как на обычном сервере — ставите nginx, правите конфиги, добавляете пользователей.
Дальше контейнер живёт своей жизнью. Файловая система лежит на хосте в каталоге /var/lib/lxc/web1/rootfs и правится прямо оттуда, пока контейнер остановлен, — это спасает, если вы сломали конфиг SSH и потеряли доступ внутрь.
Команды управления контейнером: что вызывать в каких случаях
Набор утилит LXC компактен: десяток команд закрывает почти все задачи. Ниже те, что понадобятся в первую неделю, с пояснением, что происходит при вызове.
| Команда | Что делает | Когда нужна |
|---|---|---|
lxc-ls -f |
Список контейнеров со статусом и IP | Первая команда при разборе проблемы |
lxc-info -n web1 |
PID, потребление памяти и трафик | Когда нужно понять, кто ест ресурсы |
lxc-start -n web1 |
Запускает контейнер в фоне | После создания или перезагрузки хоста |
lxc-stop -n web1 |
Корректно гасит службы внутри | Перед бэкапом или правкой конфига |
lxc-attach -n web1 |
Открывает оболочку внутри | Ежедневная работа с контейнером |
lxc-destroy -n web1 |
Удаляет контейнер вместе с диском | Только после проверки бэкапа |
Команда lxc-destroy не спрашивает подтверждения и не кладёт данные в корзину — каталог с файловой системой удаляется сразу. Перед удалением скопируйте /var/lib/lxc/web1 на другой диск, если там есть что-то ценное.
Как ограничить контейнеру память и процессор
По умолчанию контейнер видит всю память хоста и может забрать её целиком, уронив соседей. Лимиты задаются в файле конфигурации /var/lib/lxc/web1/config — это обычный текстовый файл, который система читает при старте контейнера.
На современных системах с cgroup второй версии строки выглядят так:
lxc.cgroup2.memory.max = 512M
lxc.cgroup2.memory.swap.max = 256M
lxc.cgroup2.cpu.max = 50000 100000
lxc.start.auto = 1Первая строка ставит потолок оперативной памяти в 512 МБ: при попытке выйти за него ядро убьёт процесс внутри контейнера — это и называют срабатыванием OOM, «нехватки памяти». Вторая разрешает вытеснить в файл подкачки ещё 256 МБ. Третья ограничивает процессор половиной ядра: 50000 микросекунд работы на каждые 100000 микросекунд периода. Четвёртая включает автозапуск контейнера при перезагрузке хоста.
После правки файла контейнер нужно перезапустить командами lxc-stop -n web1 и lxc-start -n web1 — на лету значения не подхватываются. Проверить, что лимит применился, проще всего изнутри: lxc-attach -n web1 -- free -m покажет память с учётом ограничения, а не всю память хоста.
Proxmox VE: когда веб-интерфейс удобнее консоли
Proxmox VE — бесплатная платформа виртуализации, которая умеет одновременно и KVM-виртуалки, и LXC-контейнеры, и управляется через браузер. Ставится она на голое железо или на выделенный сервер и занимает около 4 ГБ диска и 2 ГБ памяти под сам гипервизор.
Смысл перехода появляется, когда контейнеров больше пяти-шести. В интерфейсе видно потребление каждого, лимиты правятся мышью, снимки делаются в один клик, бэкапы ставятся на расписание. Восстановление из архива занимает 1–3 минуты против ручной пересборки.
Терминология там своя: контейнеры называются CT и получают числовые идентификаторы вроде 101 и 102, а виртуальные машины — VM. Под капотом это тот же LXC, поэтому конфигурации при желании правятся из консоли. Если контейнеров два-три и меняются они раз в квартал, ставить Proxmox незачем — набор команд lxc-* закрывает задачу и не отъедает ресурсы.
Частые ошибки при работе с LXC
Большая часть проблем у новичков повторяется от раза к разу и связана не с настройкой, а с неверными ожиданиями от контейнерной модели. Ниже те, что чаще всего приводят к потере данных или к бесполезным часам отладки.
- Ожидать, что в контейнере заработает Windows или другая не-Linux система. Общее ядро делает это невозможным по устройству, а не по настройке.
- Пытаться загрузить свой модуль ядра или поднять вложенную виртуализацию внутри арендованного контейнера — провайдеры такие вызовы блокируют.
- Не ставить лимит памяти: один контейнер с утечкой забирает все 8 ГБ хоста и роняет остальные вместе с самим сервером.
- Считать снимок состояния бэкапом. Снимок лежит на том же диске и исчезнет вместе с ним при отказе накопителя.
- Хранить базу данных на контейнерном тарифе с плавающей памятью и удивляться отказам в выделении памяти в часы пиковой нагрузки.
- Вызывать
lxc-destroyдо проверки резервной копии: команда удаляет файловую систему без подтверждения и без возможности отката.
Частые вопросы
LXC или Docker — что выбрать новичку? Ориентируйтесь на объект изоляции. Если вы упаковываете конкретное приложение и хотите переносить его между машинами — Docker. Если вам нужно окружение, похожее на отдельный сервер, куда вы ходите по SSH и ставите пакеты руками, — LXC.
Сколько памяти реально экономит контейнер по сравнению с виртуалкой? Накладные расходы LXC составляют 10–30 МБ против 200–500 МБ у KVM с той же ОС. На десяти экземплярах разница доходит до 2–5 ГБ, то есть примерно до половины памяти среднего сервера.
Можно ли запустить Windows в LXC-контейнере? Нет. Контейнер использует ядро Linux хоста, а Windows требует собственное ядро NT. Единственный вариант — полноценная виртуальная машина на KVM или Hyper-V.
Почему провайдер не даёт загрузить модуль ядра? Модули грузятся в общее ядро и действуют на всех соседей по физической машине. Разрешить это одному клиенту означало бы дать ему контроль над остальными, поэтому загрузка модулей в контейнерах закрыта.
Что означает «плавающая память» в контейнерном тарифе? Память не резервируется за вами при старте, а выдаётся из общего пула по факту запроса. В спокойное время доступно больше заявленного, в пиковое — процесс может получить отказ, даже если формально лимит не выбран.
Сохранятся ли данные в LXC после перезапуска? Да, файловая система контейнера лежит на диске хоста в /var/lib/lxc и переживает и перезапуск контейнера, и перезагрузку сервера. Это принципиальное отличие от Docker, где без подключённого тома изменения теряются.
Какая конфигурация нужна, чтобы держать свои контейнеры? Под три-четыре лёгких контейнера хватит 2 ядер, 2 ГБ памяти и 20 ГБ диска. Под десяток с базами и веб-серверами закладывайте 4 ядра, 8 ГБ памяти и 80 ГБ NVMe.
Итог
LXC — это отдельный Linux-сервер за 10–30 МБ накладных расходов, который стартует за пару секунд и хранит данные между перезапусками. Он выигрывает у KVM по плотности и цене, но не даёт ни своего ядра, ни Windows, ни собственных модулей. Docker решает другую задачу — упаковку одного приложения, и спокойно живёт внутри LXC-контейнера вторым слоем.
Выбирайте контейнер под сайты, ботов, стенды и мониторинг, а виртуальную машину — под базы данных, 1С и всё, где нужны гарантированные ресурсы. Сравнить конфигурации и цены по обеим схемам виртуализации можно в каталоге VPS и VDS: там собраны тарифы 44 площадок с фильтрами по памяти, дискам и локациям.
