На прошлой неделе вышел Docker 0.9. Главное изменение в нём не на поверхности: команда заменила LXC драйвером собственной разработки – libcontainer. Теперь Docker по умолчанию работает с ядром Linux напрямую, без посредника. Для тех, кто планирует контейнеризацию в продакшене, это не косметика, а смена фундамента. Разберём, что именно изменилось и почему это важно для корпоративных и государственных систем.

Зачем Docker отказался от LXC

До версии 0.9 Docker был, по сути, удобной обёрткой над LXC. LXC – зрелый набор userspace-утилит, но он создавался как инструмент для системных администраторов, а не как стабильный программный интерфейс. Его поведение менялось от версии к версии и от дистрибутива к дистрибутиву. Контейнер, собранный на Ubuntu, мог повести себя иначе на RHEL – а для заказной разработки под госсектор, где целевая платформа часто фиксирована сертифицированным дистрибутивом, такая непредсказуемость недопустима.

libcontainer убирает эту зависимость. Библиотека написана на Go и обращается к примитивам ядра – namespaces, cgroups, capabilities, профилям apparmor и seccomp – напрямую через системные вызовы. LXC больше не обязателен: Docker несёт всё необходимое внутри себя. Поведение контейнера теперь определяется самим Docker, а не внешней утилитой, которую кто-то обновил в репозитории дистрибутива.

Что это даёт инфраструктуре

Первое – воспроизводимость. Образ, собранный на машине разработчика, разворачивается на тестовом и боевом контуре идентично. Это снимает класс проблем «у меня работало», который особенно дорого обходится при сдаче систем по госконтракту с жёсткими сроками приёмки.

Второе – изоляция зависимостей. Контейнер несёт своё окружение: версии библиотек, рантайма, конфигурации. Можно держать на одном хосте сервис на старом стеке рядом с новым, не разводя их по разным серверам. Для систем, где соседствуют legacy-компоненты и свежие модули – а это типичная картина в электронных архивах документов и интеграционных шинах – это прямая экономия на железе.

Третье – операционная гибкость. Контейнер стартует за доли секунды, его легко тиражировать и пересоздавать. Это естественная среда для архитектуры, которую мы недавно разбирали в материале про микросервисы: каждый сервис – отдельный контейнер со своим жизненным циклом, своим масштабированием и своим окном обновления.

Где осторожность ещё нужна

Docker и libcontainer – молодая технология, и до версии 1.0 авторы прямо предупреждают о смене API. В продакшене это значит: фиксируйте версию Docker, тестируйте обновления на стенде, не переносите контейнеры между несовместимыми ядрами вслепую.

Изоляция контейнеров слабее, чем у виртуальных машин: все они делят одно ядро хоста. Для приложений с разными требованиями к безопасности – например, при обработке персональных данных и информации ограниченного доступа – контейнеры не заменяют гипервизор, а дополняют его. Разумная схема: ВМ как контур безопасности, контейнеры как единица доставки внутри него.

Отдельный вопрос – состояние. Контейнеры эфемерны, а базы данных требуют надёжного хранения. Те же оговорки, что мы делали для NoSQL в продакшене, действуют и здесь: данные выносятся на смонтированные тома или внешние сервисы, а не живут внутри контейнера.

Вывод

libcontainer превращает Docker из обёртки над LXC в самостоятельную платформу контейнеризации с предсказуемым поведением. Это снижает риски при развёртывании и упрощает сопровождение – ровно то, что нужно корпоративным и государственным заказчикам. Технология ещё созревает, поэтому внедрять её стоит с пилота и под контролем инженеров. Контейнеризация продакшена начинается не с самого Docker, а с проектирования инфраструктуры под требования к надёжности и безопасности.