Containerization

Контейнеризация — способ упаковки программного обеспечения, при котором приложение и всё необходимое для его работы, включая среду выполнения, библиотеки, системные пакеты и конфигурацию, объединяются в образ. Образ запускается как изолированный процесс, называемый контейнером. Каждый контейнер видит собственную файловую систему, дерево процессов и сетевые интерфейсы, но все контейнеры на одном хосте используют общее ядро его операционной системы. Поэтому они намного легче виртуальных машин. В машинном обучении (ML) контейнеризация устраняет конфликты между проектами, которым нужны разные версии Python, CUDA или PyTorch, и позволяет запускать модель, обученную на рабочей станции, без изменений на сервере, в кластере или на устройстве периферийных вычислений.

Как работают контейнеры#

В основе контейнеров Linux лежат две возможности ядра. Пространства имён определяют, что может видеть процесс, предоставляя ему собственные идентификаторы процессов, сетевой стек, точки монтирования и пользователей; cgroups (группы управления) ограничивают доступные ресурсы, задавая пределы для CPU, памяти и операций ввода-вывода. Эта идея восходит к chroot 1979 года и джейлам FreeBSD 2000 года; cgroups появились в ядре Linux в 2008 году, а Docker сделал контейнеры массовой технологией в 2013 году. Основанная в 2015 году Инициатива открытых контейнеров (OCI) стандартизировала форматы образов и сред выполнения, поэтому образ, созданный одним инструментом, запускается с помощью другого.

Работу выполняет среда выполнения контейнеров. Среды высокого уровня, например containerd и CRI-O, загружают образы и управляют жизненным циклом контейнеров. Среда OCI низкого уровня, например runc, создаёт пространства имён и cgroups, а затем запускает процесс. Поскольку контейнерам Linux требуется ядро Linux, macOS и Windows запускают их внутри небольшой виртуальной машины Linux.

Образы, слои и реестры#

Образ — это набор слоёв только для чтения и конфигурация, в которой указана запускаемая команда. При запуске среда выполнения объединяет слои в одну файловую систему, обычно с помощью OverlayFS, и добавляет тонкий доступный для записи слой для конкретного контейнера. Поэтому многие контейнеры используют одну копию образа на диске. Реестры, например Docker Hub, GitHub Container Registry и реестры каждого облачного провайдера, хранят образы с тегами, например latest, и контентными дайджестами — хешами SHA-256, которые всегда указывают на одни и те же данные. При сборке неизменившиеся слои используются повторно; поэтому в Dockerfile зависимости устанавливают до копирования часто изменяемого кода:

Контейнеризация в рабочих процессах машинного обучения#

В конвейерах MLOps контейнеры переносят проект от эксперимента до рабочей среды. Образы с фреймворками, например из каталога NVIDIA NGC, фиксируют версии CUDA, cuDNN и фреймворка, поэтому на каждом узле задания распределённого обучения используется одно и то же ПО. Хост предоставляет только драйвер GPU, который NVIDIA Container Toolkit делает доступным контейнеру. Тесты непрерывной интеграции запускаются в том же образе, который позже отправляется в рабочую среду; серверы инференса для обслуживания моделей запускаются в виде образов, которые Kubernetes реплицирует и масштабирует в соответствии с нагрузкой, а устройства периферийного ИИ, например платы NVIDIA Jetson, обновляют модель, загружая новый тег образа.

Интеграция On Premise Ultralytics Platform для рабочих пространств Enterprise при необходимости устанавливает Docker и запускает один контейнер обработчика из официального образа Ultralytics, соответствующего оборудованию хоста: ARM64, CPU или GPU NVIDIA. Обработчик подключает папку с набором данных только для чтения, поэтому исходные изображения остаются на этом компьютере, а метрики обучения и лучшая контрольная точка каждого запуска YOLO26 отправляются на Platform.

Контейнеры и виртуальные машины#

Виртуальная машина запускает полноценную гостевую операционную систему с собственным ядром на гипервизоре, поэтому каждая ВМ содержит образ ОС объёмом в несколько гигабайт и загружается как отдельный компьютер. Контейнер — обычный процесс, работающий на общем ядре хоста: он запускается так же быстро, как его приложение, и занимает место только под собственные файлы. Совместное использование ядра также означает, что уязвимость в нём может поставить под угрозу все контейнеры на хосте. Поэтому эти технологии часто сочетают: общедоступные облака запускают контейнеры клиентов внутри ВМ, а изолированные среды выполнения добавляют дополнительную границу защиты для недоверенного кода, например кода, который ИИ-агенты пишут и запускают в изолированных средах агентов. gVisor от Google перехватывает системные вызовы контейнера с помощью собственного ядра в пространстве пользователя. Kata Containers запускает каждый контейнер внутри облегчённой виртуальной машины, а AWS создала микро-ВМ Firecracker для такой же изоляции функций AWS Lambda.