Контейнеры — это не просто Linux-процессы: разбираемся в OCI

Когда мы говорим «контейнер», в голове у разработчика всплывает Docker, пара заклинаний docker run и счастливое неведение о том, что творится под капотом. Но если копнуть чуть глубже, выясняется: контейнер — это не просто Linux-процесс с веточкой chroot. Это целый зоопарк абстракций, стандартизированных OCI (Open Container Initiative).

Что скрывается за магией docker run?

OCI — это не один стандарт, а целых три спецификации, которые вместе описывают, как должен выглядеть «правильный» контейнер:

• Runtime Specification — как запускать и останавливать контейнер, используя namespaces, cgroups и прочие радости ядра.
• Image Specification — что внутри образа: слои, конфиг, метаданные. Всё то, что мы привыкли пушить в registry.
• Distribution Specification — как обмениваться образами через сеть, чтобы не изобретать велосипед.

По сути, OCI — это джентльменский набор правил, благодаря которому Podman, containerd, CRI-O и даже ваш домашний скрипт на bash могут понимать друг друга. Без этого мы бы до сих пор жили в мире «а у меня работает».

Почему это не просто процессы?

Да, в основе контейнера лежит процесс (или группа процессов), но между вами и этим процессом — целая прослойка магии: монтирование файловых систем, настройка сети, управление ресурсами. Попробуйте вручную настроить cgroups для CPU и памяти — и вы поймёте, почему Docker зарабатывает деньги. OCI берёт на себя всю эту боль, предлагая единый интерфейс.

Кстати, если вы когда-нибудь писали свой рантайм для контейнеров (а кто не писал?), то знаете: реализация OCI Runtime — это квест уровня «собрать IKEA в полной темноте». Но результат того стоит: ваш контейнер будет работать везде, где есть OCI-совместимый рантайм.

Комментарий студии METABYTE: Мы тоже любим копаться в OCI, но обычно доверяем containerd — он реже просит перезагрузить ноутбук. А если вам нужна кастомная сборка контейнеров для продакшена, мы знаем, где лежат грабли.