Comments 13
Круто и базовом. Реально многим не хватает этого понимания. Спасибо, буду кидать ссылки.
Насколько я помню namespaces было аж на рубеже тысячелетий в FreeBSD в виде jails и в Solaris в виде Zones или Containers, уже не помню. 10 лет везли до Linux? Или это разные вещи?
Zones и jails — это целостные контейнерные решения, существующие и на уровне ядер соответствующих ОС
namespaces — это технология изоляции процессов на уровня ядра, не являющаяся самой по себе технологией контейнеризации — в ней нет квот ресурсов, ограничений досутпа (к тому, что видно), виртуальной сети
Разработчики ядра Linux 10 лет решали, нужны ли там контейеры — в итоге контейнеры Linux сделали чисто userspace объектами
Не хватало докера, который предоставил удобную утилиту для настройки и управления контейнером, а с кубером/опенщифтом еще и оркестрацию всем этим делом.
Вручную делать все через неймспейсы - было не так очевидно что это дает.
К сожалению, я не разбираюсь на глубоком уровне в BSD-like системах, так как сталкивался с ними крайне ограниченно. Но, насколько я помню, концепция jails очень похожа на Linux namespaces. Ключевое отличие в возрасте технологий и целеполагании. В Jail из коробки можно поднять полноценный инстанс ОС, запустить INIT Daemon, поработать с сервисами. В Linux надо костылить, systemd, насколько я помню, целое приключение запустить в контейнере.
В целом, довольно логично и ожидаемо, что ОС общего назначения приходят к схожим архитектурным решениям рано или поздно. Требования безопасности и потребности пользователей в целом едины и должны реализовываться на любой системе.
Конвергентная эволюция, все дела )
Весьма холиварная тема. Я (как в прошлом Solaris и BSD администратор) даже разжевывать боюсь, комментируя то, что здесь в треде уже написали :)
Да, причем не "или", а "и" Zones и Containers, причем в Solaris 8 и 9 не было никаких zones, были только containers. Если совсем упрощать, то containers - это абстракция для изоляции (ну типа namespace), а когда поверх этого наворачивалось resource management, то solaris container превращался в solaris zone.
jails - это в общем-то namespaces до того, как "линукс победил", причем сделанные гораздо лучше (господа, желающие сразу минусовать, сначала просто сравните, как сделаны user isolation в freebsd jail и в linux namespace с его uid mapping, где uid 25 внутри контейнера "на самом деле uid 100025 снаружи").
Но победило то, что победило, с этим и жить.
Смахнул скупую слезу, помню получение бесплатных дисков с убунтой, а до этого бокс с кучей дисков от Майкрософт )
А на сколько большие накладные расходы контейнеризации? А то в приложениях спины крутят, чтобы квант не отдавать, а тут еще и контейнер.
Совсем небольшие. Пока вы не делаете вызовы в ядро всё равно в контейнере вы или на голом железе.
А ядро вообще то же самое что и на голом железе. Ну добавится капелька проверок на namespace (хотя она и на голом железе должна быть).
По диску получается чуть побольше, потому что вы тянете свою копию библиотек, но это тоже копейки, видел кучу проектов где статическая линковка (все библиотеки зашивают в исполняемый файл).
Собственно поэтому с контейнерами и носятся, можно же вообще образ виртуалки таскать, будет безопаснее, но там эмуляции побольше и расходов уже процентов 30 (не помню откуда в голове эта цифра, можно ей не верить)
И как у вас дела с переходом на РедОС идут??? Почему в статье cgroup стороной обошли??? Может поделитесь нюансами тюнинга ОС для корректной работы докеров?
Я всего лишь спец. по импортозамещению в ГМИ.
К сожалению, не участвую в рабочей группе импортозамещания ОС, смотрел РедОС самостоятельно, лично мне понравилась, каких-то больших проблем не заметил. Cgroups, как мне кажется, лучше рассмотреть в отдельной статье. Я в свою очередь, в процессе наставничества джунов стараюсь разбирать cgroups только после просветления на тему fork/exec. А по поводу тюнинга — на моей практике любой тюнинг был под конкретные задачи, в большинстве случаев из коробки все работает корректно.
Спасибо за статью, хорошо и понятно описывает базовые принципы!
Буду рекомендовать падаванам!
Ну и скорее всего, придётся тесно взаимодействовать с мейнтейнерами дистрибутивов, чтобы всё устанавливалось и собиралось, как задумано. Дорого. Сложно.
Тысячи приложений живут в пакетах для дистрибутивов и им прекрасно. Вовсе не так сложно и не так дорого. Проблема не в этом.
Просто когда у вас одно-два приложения, например, веб-приложение и его БД, запускаются на голой ОС, все в большинстве своем прекрасно работает. Проблемы начинаются, когда это одно веб-приложение разделяется на пяток-десяток в рамках распиливания монолита, разработка которых идет в разном темпе, которым со временем начинают требоваться разные версии языков, библиотек, тех же БД, или какого-нибудь вспомогательного ПО — одно приложение хочет nginx, второе апач, третье еще что-нибудь, и все эти версии начинают уже с проблемами ставиться в рамках одного дистрибутива, конфликтовать, требовать необходимости запускаться с разными конфигами и так далее. Обновлять эту радость тоже больно — где-то кто-то чужой конфиг затер, где-то подключаемую библиотеку другое приложение обновило, и все.
А с контейнерами любые приложения с самыми наркоманскими требованиями и долбанутыми окружениями превращаются в черные ящики — ты ему показываешь "вот сюда клади файлы, которые хочешь сохранить, вот отсюда бери конфиг запуска, вот тебе сетевой адрес до БД, работай". Все остальное, что происходит в образе, тебя не волнует, пусть приложение там хоть системные файлы своими правленными копиями подменяет, если само приложение при этом корректно работает и переживает редеплой, то хост-системе и другим контейнерам на это плевать. И это очень удобно.
Зачем рассказывать про контейнеризацию в 2023 году