Контейнеры

Последние несколько недель я изучал контейнеризацию окружений, точнее то, как нынче принято это делать. И повод есть: anotherhosting.net весь в виртуалках живёт, виртуалки содержаться на моём «облаке», ну а контейнеризация, насколько известно, помогает снизить накладные расходы, что ведёт к росту КПД «облака». Ну это в теории. Да и глупо это, казалось бы, иметь гипервизор, виртуализацию в CPU, когда любой продакшн-дистрибутив умеет и cgroup и namespaces. Но нет… Счастья не будет.

Если сильно не растекаться мыслью по листу… по текстбоксу, да, то всё упёрлось в недалёкость разработчиков современных. Вот что делали годные хардкорные админы при инициализации сервисов:

  1. приложение запускается, открывает все нужные для работы дескрипторы, которые нельзя открыть из chroot’а, например порты и сокеты;
  2. делается chroot куда-то;
  3. сброс привилегий до заданного уровня;
  4. открытие временных файлов и собственных данных, доступных в chroot’е.

У chroot’а правда много минусов. И мало возможностей. Но у нас же есть cgroups + namespaces! А ещё namespace’ы доступны пользователю, а значит по-хорошему контейнеры в Linux должны выглядеть как-то так:

  1. заводим супер бесправного пользователя и назначаем ему регион sub[u|g]id, жмём ему лимиты на всё с помощью cgroups;
  2. контейнер стартуем от этого пользователя, ставим разрешение ресурсов на него от рута, пользователь не имеет право что-либо менять в cgroups;
  3. PROFIT!

Но нет. Для продакшна у нас доступна только ущербная вилка, где возможно:

  1. запускать всё от root’а без использования sub[u|g]id;
  2. запускать от root’а с использованием sub[u|g]id;
  3. запускать от не привилигированного пользователя, но это требует самопальной обвязки, которую сильно лень писать.

Но это всё фуфел, так как первый вариант не возможно использовать в продакшне от слова «совсем» — небезопасно. Второй тоже не очень спасает, ибо в любой реализации возможны проблемы (например в 2016 году и в 2017 году). Ну а третий вариант и вовсе хипстерам из Canonical (LXC) и RH (systemd-nspawn) не интересен: вероятно он им кажется либо избыточным, либо не понятным. А зачем это надо? Лучше вместо проработки дополнительного варианта взять самокат и скататься на очередной саммит, чтобы испить смузи с коллегами.

Нет, шутки шутками, а вон intel начал пилить свой уродливый костыль. И они тут правы: во-первых они купируют проблемы изоляции конейнеров, во-вторых привязывают реализацию к своим технологиям. Контейнеризация нынче в моде, так что товарищи идут верной дорогой.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

11 − 5 =