Привет, Хабр! Меня зовут Матвей Мочалов, я — компьютерный инженер и один из авторов корпоративного блога cdnnow! Мы с вами познакомились в этом посте про историю DRM для видеоконтента. Сегодня я хочу поговорить с вами про Docker, а точнее про то, о чём многие забывают: различиях в нём для разных систем. Нам, как CDN-провайдеру Docker, все его 50 оттенков близки и знакомы. И, к счастью, наше взаимодействие с ним происходит из-под Linux, но, увы, не всем так везёт.
Как это часто бывает, с мультиплатформенностью и прочими «красивыми» словами в IT, всё не так однозначно. У всего своя цена, и под капотом один и тот же инструмент на разных системах, по сути своей может представлять из себя несколько разных вещей с различными принципами работы и производительностью. А обещания революции скрывают за собой эволюцию, либо вовсе регресс и топтание на месте.
Linux — дом, милый дом
Для начала кратко повторим знакомое: что Docker из себя представляет под Linux. Но не произнося как заклинание одни и те же “понятные” всем термины, а посмотрев на суть технологии.
Говоря привычно и заученно, как на новогодней ёлке перед Дедом Морозом:
Docker — это “революционная” технология контейнеризации с открытым исходным кодом, которая появилась в 2013 году, сразу же обретя огромную популярность со взрывным ростом аудитории, конца и края которому не видно и по сей день. Вплоть до того, что Docker местами становится очередной затычкой для мультиплатформенных десктоп-приложений, а не только в бэкенде находит своё применение.
Говоря же по-русски, а не на наречии корпоративных ящеров:
Идея контейнеризации, изоляции и песочниц — не нова. И админу, и простому линуксоиду хорошо знакомо судорожное восстановление сломанной системы. Из-под Live-ISO образа, вводя заветную команду chroot (change root), обозначающую “смена корневой папки”, для доступа к павшей смертью храбрых операционке.
Chroot в целях подобной некромантии и иных задач с нами уже очень давно — аж с 7 версии Unix из далёкого 1979 года. А в BSD — с 1982. Благодаря такой матрёшке с виртуализацией доступа к корневой системе одной ОС из-под другой, решалась одна важная задача, которая выделяет контейнеризацию от виртуальных машин по сей день — использование общего ядра с основной ОС, а не виртуализация всей системы целиком.
С одной стороны, разные версии и типы ядер для нас недоступны в отличие от виртуалок, а с другой — процессы, запущенные из-под chroot, виртуально отвязаны от зависимостей и библиотек основной ОС. Что, как нетрудно догадаться, не только экономит нам производительность, но и избавляет от головной боли с конфликтами зависимостей для тестирования/развёртывания/разработки и всего остального, что нам будет угодно при взаимодействии с конкретным софтом.
Да, за громкими и красивыми словами про контейнеризацию и изолированность кроются в своей сути ловкие фокусы вокруг файловой системы UNIX-подобных систем и навешенная поверх этого в целях безопасности дополнительная изоляция процессов друг от друга и от основной ОС.
На этом фоне особенно забавно то, как Docker любят сравнивать с виртуальными машинами, как нечто революционное. Полностью игнорируя почти полвека истории предшествовавших технологий, на которых он буквально до сих пор работает.
Справедливости ради стоит отметить, что Docker помогла прийти к успешному успеху и экосистема инструментов. Она написана на Go, при этом отличается простотой написания своих модулей, не прибегая к садомазохизму на чистом Bash.
А также удобство использования этой экосистемы в целом: от централизованных репозиториев с уже готовыми под любые нужды контейнерами, до графического интерфейса для тех, у кого вид консоли с командной строкой вызывает приступы тревоги.
Небольшое уточнение: под капотом Podman и его страшного, но богатого собрата Docker, в их рантайме — runc, используется всё-таки не chroot, а сын маминой подруги в делах смены корневой директории — pivot_root.
Ну и какая, спросите вы, разница? Да, в общем-то, никакой, но есть нюанс — pivot_root является более защищённым от эскалации привилегий в сравнении со своим старшим братом.
Даже man для chroot приводит нам пример, как с помощью банальной смены директории на предыдущую через «cd..» процесс может сбежать в основную ОС.
This call does not change the current working directory, so that
after the call '.' can be outside the tree rooted at '/'. In
particular, the superuser can escape from a "chroot jail" by
doing:
mkdir foo; chroot foo; cd ..
This call does not close open file descriptors, and such file
descriptors may allow access to files outside the chroot tree.Pivot_root же полностью изолирует запускаемый из-под него процесс и все его “дочки” от файловой системы основной ОС. Говоря по-человечески, «cd..» в лоб не сработает — придётся мудрить более заковыристые методы побега из “песочницы”. Но тут мы уже забредаем в степь FireJail и прочих методов изоляции, и ограничения процессов в рамках системы с одним и тем же корнем, а это уже совершенно другая история. Однако, как вы уже и так знаете, Docker с Podman полюбились изобретателям велосипедов и в этих целях.
Чужак в чужой стране
И тут назревает вопрос: а каким образом это всё у нас работает под Windows, где никакого общего ядра нет. Система даже не Unix-подобная. Куда и в какое место тут делать, что chroot, что pivot_root?
А ни в какое, ведь за пределами Linux и FreeBSD теряется основное преимущество Docker, о котором обычно упоминают — отказ от использования VM. Вы просто не можете запустить его под виндой без виртуалки. И то, как Docker сам это делает, и как нам предлагает делать это Microsoft — это то ещё извращение.
Во-первых, с использованием VM теряется главная маркетинговая фишка, но по дефолту Docker хочет упростить нам жизнь и за нас решает, что лучше под виндой запускать виртуалку с Linux из-под Hyper-V. А мелкомягкие нам предлагают жизнь ещё больше упростить, предлагая использовать WSL2, который, правда, тоже под всей своей мишурой скрывает Hyper-V.
Что же в этом плохого? Абстракция. Чем больше у нас слоёв абстракции, тем меньше мы понимаем, что наши программы и инструменты вообще делают, и тем меньше мы имеем возможности по их контролю. Особенно, когда это решение, которое как Hyper-V и WSL2, в отличие от VirtualBox, VMware или православного KVM, намеренно сделано так, чтобы что-то в нём персонализировать под себя было затруднительно.
И зачем это всё, какой ценой?
Ценой всего.
То, что на корню, к счастью, делает всё это извращение неконкурентоспособным относительно запуска из-под нативной системы с Linux — производительность.
Windows сама по себе достаточно прожорливая, плюсом ко всему нам из-под неё нужно запустить виртуалку с Linux, и уже оттуда запустить Docker. Сказывается ли это на производительности? Интриги тут не будет — конечно же, сказывается.
Прощай, немытый Microsoft — компания рабов, компания господ
А как же дела у нас обстоят под MacOS? Там ведь и система UNIX-подобная, и ядро на FreeBSD основано, всё же должно быть лучше, чем на Microsoft, и, глядишь, даже лучше, чем у этих красноглазых, роящихся в thinkpad(ах), а не в прекрасных макбуках, Линуксоидов. Ведь так?
Да вот как бы не так! В MacOS даже нет не то, что pivot-root как концепции, но и chroot. Прогресс и инновации с отставанием на 45 лет.
Хотя реализация подобного функционала под MacOS полностью возможна, и у энтузиастов даже получилось создать свои, нативные для MacOS, контейнеры.
Если же кто-то попытается поискать информацию по нативному запуску того же Docker под MacOS, то он радостно для себя может обнаружить проект Docker-OSX. Аж из-под Linux можем MacOS запустить и с почти нативной производительностью! Да вот только Docker, как и во многих других случаях, здесь выступает в роли очень тяжеловесного установщика виртуалки KVM и всех конфигов для неё, а не сам по себе запускает MacOS.
Да, в очередной раз матрёшка из абстракций, но в этот раз не Docker из-под Виртуалки, а Виртуалка из-под Docker.
Но не спешите радоваться: сам Docker снова окажется в роли внутренней части матрёшки.
Раз по умолчанию яблочные владыки из Купертино не предоставляют для своей ОС, то Docker, наверное, решили сами реализовать своё нативное решение? Хотя бы для x86 систем?
Конечно же, нет. Они написали свою виртуалку HyperKit, в которой запускают Linux, а на нём уже запускают Docker.
На машинах с Apple Silicon всё ещё веселее. В случае, если вам требуются образы под x86 системы.
Docker всё также запускается в виртуалке, но теперь с Линуксом для ARM, а до недавнего времени, чтобы запустить x86 образы, он запускал ещё одну Виртуалку из-под QEMU и, наконец-то, уже в ней непосредственно сам Docker-образ.
Но на радость яблочников, в октябре прошлого года из бета-теста вышла функция, добавляющая поддержку транслятора процессорных команд Rosetta 2. Которая хоть и является программным решением, а не аппаратным блоком, но относительно виртуалки внутри виртуалки, дала значительный прирост в производительности при запуске x86 Docker-образов.
И как теперь спать по ночам с этим знанием?
История с Docker — это один из многочисленных примеров того, как IT-индустрия в погоне за мультиплатформенностью и повторением как мантры красиво звучащих слов, теряется в том, что, зачем и как она делает.
Docker не являлся революцией — это была закономерная эволюция технологии. Но, как мы выяснили, за пределами Linux и FreeBSD — это и не эволюция, а топтание на месте, причем почти на 50 лет назад ещё и с немаленькой ценой для производительности.
И тем не менее раз за пределы Linux докер выбрался, то спрос на него есть. Но кто так упорно продолжает колоться, плакать и всё равно жрать кактус, в обмен получая непроходимое болото абстракций и меньшую производительность?
Разработчики.
Docker удобен не только для бизнеса и развёртывания сервисов, но и для создания персональных сред разработки, тестировки и однокликовой установки self-host решений.
Мы в cdnnow! для этого предпочитаем всё-таки использовать Linux в качестве рабочей ОС, так как и на личном ноуте простота и большая производительность лишними не будут.
Однако с интересом почитаем в комментариях, что вас останавливает с переходом на Linux для использования Docker, удерживая дальше на Windows, либо MacOS.
Комментарии (69)
Kenya-West
22.04.2024 14:09+6Автору просьба пояснить за Docker containers for Windows - они архитектурно не имеют ничего общего с обычными Контейнерами Docker. Может, там избавились от "матрёшечной" виртуализации на ровном месте?
cdnnow_writer
22.04.2024 14:09От этой матрёшочности избавились в Windows Server Containers, с релизом Windows Server 2016. Но там опционально, есть вариант дополнительно использовать Hyper-V для изоляции.
ritorichesky_echpochmak
22.04.2024 14:09В смысле есть вариант? Для запуска доцкеров на фортках всего два варианта: старый доцкер который всё запускает через VirtualBox, да новый, который захочет Hyper-V, которые в свою очередь захотят чтобы у вас была либо серверная винда, либо PRO редакция win10 1809 или новее. Дальше в этой матрёшке есть ещё нюансиков, например доцкер с isolation=process на 20H2 работал, а на более новых уже нет, т.к. ABI форточек не совпали и нужна полная виртуализация. Хотите isolation=process - валяйте на серверную версию или вечно сырую win11. И образы нехилого размера, которые внутри тащат реально целую ОС в случае с Windows Containers, но кривые настолько, что в какой-то момент даже дотнетчики переходят на Linux Containers (заодно решаются всякие детские баги типа пропадающей сетки между перезапусками и утекающей вёдрами ОЗУ)
nronnie
22.04.2024 14:09+12Докер никогда не умел и сейчас не умеет запускаться "через VirtualBox". Можно было только поставить под него "полновесную" виртуалку с линукс, а в неё уже ставить докер. На Home редакциях, где нет Hyper-V сейчас можно запускать Docker Desktop на WSL2. Для чего вообще может понадобиться запускать докер на винде для production лично я в душе не знаю, а для разработки докер под WSL2 полностью годится.
ritorichesky_echpochmak
22.04.2024 14:09До этих вот модных WSL "никогда" был Docker Toolbox for Windows, который и под Win7 работал. И такой же под Mac. Само собой VB запускает полновесные виртуалки.
Где нет Hyper-V он оказывается всё равно немножко есть
The newest version of WSL uses a subset of Hyper-V architecture to enable its virtualization. This subset is provided as an optional component named "Virtual Machine Platform," available on all Desktop SKUs.
Но да, то что теперь это иногда можно использовать на хомяке - это прям прогресс. Зря, выходит, доплачивал за Pro, надо было просто подождать пару лет)
Для разработки докер под WSL2 полностью годится, если у тебя вагон ОЗУ, ядер побольше и NVMe для прокачки немаленьких образов, когда под никсами уже и chiseled можно. Конечно поиграться в один контейнер любого корча хватит, но вот для нормальной разрабооотки...
И как бы там ниже не писали про Windows Containers без виртуалки... без фич виртуализации они всё ещё не летят никак (т.е. кусок Hyper-V, проц с оными, включение в BIOS). И за счёт того что часть виртуализации WC срезали, в официальной документации упоминается что они менее безопасны. Но всё ещё жрут как не в себя по сравнению с никсами.
nronnie
22.04.2024 14:09В общем-то, для меня никогда не было проблемой его и в любой обычной виртуалке запускать. Ну да, Docker Desktop совсем чуть-чуть удобней. Но я все равно с ним всегда работаю из командной строки - будет это просто "локальный" WT c PowerShell + DockerCompletion или тот же WT только подключенный по SSH к виртуалке - разницы почти что никакой.
cdnnow_writer
22.04.2024 14:09+1
Winand
22.04.2024 14:09Кажется, это устаревшая информация. Сейчас WSL2 доступен для Windows 10/11 Home, а следовательно и Docker.
mraat
22.04.2024 14:09+3А как на FreeBSD запускать контейнеры docker проще всего? Несколько лет назад пытался найти способ - какие-то пакеты были заброшены, что не рекомендовалось к использованию, что-то было в разработке. Пришлось просто использовать linux в bhyve и в нем поднять docker.
cdnnow_writer
22.04.2024 14:09+2К сожалению, судя по той же Wiki FreeBSD, нативный Docker там скорее мёртв, нежели жив. И полноценно использовать его так и придётся в связки bhyve + Linux.
У FreeBSD сообщества достаточно давняя история неприязни к Docker и Podman, так как их ОС из коробки предоставляет достаточно богатый набор инструментов для изоляции процессов.
И тут мы уже переходим в плоскость определений и различий контейнеров с песочницами.mraat
22.04.2024 14:09+2Просто из статьи можно было сделать вывод, что на FreeBSD c docker всё хорошо, поэтому подумал может чего пропустил. Широко использую jail'ы, но вот self-hosted sentry идет из коробки как контейнер docker.
cdnnow_writer
22.04.2024 14:09Во время написания статьи я честно говоря и сам думал, что на FreeBSD проект живёт себе спокой.
Но как выяснилось потом, не особо.
fearan
22.04.2024 14:09+9Chroot в целях подобной некромантии и иных задач с нами уже очень давно — аж с 7 версии Unix из далёкого 1979 года. А в BSD — с 1982.
Таки контейнеры - это всё-таки не просто чрут, но и изоляция процессов.
Так что всё-таки не 1982-й, а скорее 1991-й, когда там zones на всякое commodity железо портировали.
cdnnow_writer
22.04.2024 14:09+4Совершенно верно, это не просто чрут. Но я и не утверждал, что только им всё ограничивается, по моему мнению он является фундаментом для контейнеров. И тот же Docker с Podman, весьма трудно представить и без того же Go, в качестве скриптового языка всей их инфраструктуры. Да и видимый многими в кошмарах YAML, играет свою роль для конфигов.
Так что всё-таки не 1982-й, а скорее 1991-й, когда там zones на всякое commodity железо портировали.
Для Docker важнее будет скорее непосредственно cgroups, появившиеся в 2007. И Jails в BSD с namespaces в Linux появились в 2000 и 2002.
saboteur_kiev
22.04.2024 14:09+1Кроме дерева каталогов файловой системы, в линукс все построено по дереву.
Дерево процессов, дерево устройств, дерево маунтов. Поэтому докер это не навеска над файловой системой, а манипуляция этими деревьями.
Делаешь контейнер и по желанию делаешь в нем корневым процессом твой entry point, вот и изоляция процессов. А маунты и каталоги при этом можно не менять.
То есть у вас значимая неточность в определении - а именно, что не файловая система является фундаментом. Есть же правильный уровень иерархии - дерево маунтов, именно на этом уровне происходит chroot
gun_dose
22.04.2024 14:09+7Можно долго рассуждать о матрёшках, корпорациях и фичах Unix, добавленных в 79 году. Но факт остаётся фактом, я могу собрать проект на docker + docker-compose, закинуть всё это на гитхаб, и любой юзер, у которого есть docker + docker-compose, сможет запустить этот проект у себя на компе, независимо от того, какая у него ОС (хотя конечно есть нюансы с Apple M-серий и x86 контейнерами). А самое главное, что я сам через 10 лет смогу запустить его и не думать о совместимости старого софта и новой ОС. И в этом плане докеру нет равных.
Timyrlan
22.04.2024 14:09+6Любой разработчик запустит на другой ос и столкнётся с деталями реализации на это ос. Если проект не hello world конечно
В эпоху монолитов всё эти компоузы были не нужны как-то
Через 10 лет у вас будет другая ОС (см п1)
gun_dose
22.04.2024 14:09+6За 8 лет работы с докером на разных ОС единственное, с чем таким я сталкивался, это упомянутый мной эппловский процессор М1, под который просто пришлось заменить пару контейнеров в docker-compose.override.yml. Это проблема, которая решилась за 15 минут.
В эпоху монолитов люди плевались, когда приходилось работать с разными проектами с разными версиями php. Потом плевались, когда на разных проектах SASS компилился разными версиями компаса. Ну и далее можно продолжать подобные ситуации: разные версии Apache Solr, разные версии Node.js. Поэтому многие и стали использовать Docker. Вообще, монолитный LAMP стек обычно запускается минимум в трёх контейнерах. Это полнейшая глупость - полагать, что докер нужен только для микросервисов.
Вот именно, и на этой другой ОС всё прекрасно заведётся.
Ну или вот ещё свежий пример из недавней практики. Клиент просит доработать старый проект, там фронтенд собирался через Gulp 3 версии. Последний коммит по фронтенду за 2018 год. Естественно, на нынешней ноде 20 версии всё это не завелось. Чтобы обновить проект до совместимых версий пришлось бы переписывать все пайплайны галпа. Что я делаю: смотрю, какая нода была актуальной LTS в 2018 году, указываю эту версию в своём docker-compose.yml и всё запускается. Далее мы добавляем конфиги докера в репозиторий, и теперь всё у всех работает. И задача добавления пары строк в файл стилей в итоге решается за несколько минут, как это и должно быть. А самое главное, поскольку конфиг был добавлен в репозиторий, через 10 лет на другой ОС это всё точно также запустится.
Вот, кстати, пример обхода проблем специфики разных ОС: версии образов в docker-compose.yml добавляются из переменных среды. А в файле .env просто указываешь в комментариях версии для других ОС:
# Linux (uid 1000 gid 1000) PHP_TAG=8.3-dev-4.58.5 #PHP_TAG=8.2-dev-4.58.5 #PHP_TAG=8.1-dev-4.58.5 # macOS (uid 501 gid 20) #PHP_TAG=8.3-dev-macos-4.58.5 #PHP_TAG=8.2-dev-macos-4.58.5 #PHP_TAG=8.1-dev-macos-4.58.5Timyrlan
22.04.2024 14:09+3все красиво, когда есть специалист, который умеет правильно готовить. У нас вот в компании год цирк с конями (девопсами), не могут нормального найти. Наболело, прастити
gun_dose
22.04.2024 14:09Ну как во мне, докер - это база, которую должны знать все, независимо от стека. Это как bash. Неважно, кто ты девопс, бэкендер, фронтендер, ML-специалист - тебе это всё равно пригодится.
Timyrlan
22.04.2024 14:09+3про докер согласен, про баш уже нет) Но знаний одного докера ой как недостаточно для решения большинства вопросов
gun_dose
22.04.2024 14:09Я не говорю, что докер = баш, я имею в виду, что степень их важности одинаковая (хотя на самом деле баш важнее). Это разные инструменты для абсолютно разных целей. Но если разработчик не знает баш - это плохой разработчик, тут без вариантов. То же самое с докером, если разработчик не знает докер - это плохой разработчик. Вот, что я имею в виду.
jakobz
22.04.2024 14:09А зачем знать bash?
gun_dose
22.04.2024 14:09Например, чтобы не донимать тимлидов или девопсов дурацкими вопросами типа как сгенерить ключ через новомодную гуёвину, которой никто не пользуется. Или чтобы быть в состоянии самому написать какую-никакую автоматизацию, CI-пайплайн, кронджоб. Чтобы уметь запустить сайт на сервере. Можно долго перечислять.
Но вообще, у меня встречный вопрос: на какой круг задач рассчитан программист, не знающий баш?
jakobz
22.04.2024 14:09+1Ну я вот как-то 18 лет работы обхожусь без скриптов на баше. И даже без grep-а и пайпов команд друг в друга. Понятно что в command line вызвать git/openssh/ping/docker/etc - я могу. Но если что-то чуть сложнее - беру просто язык программирования, на котором все остальное в проекте, и на нем делаешь на нём всё что нужно. В человеческих языках, кроме grep-ов по файлам - можно и в API сходить, и сервак выставить, и в БД сходить, и алгоритм какой нетривиальный сделать. Не говоря уже что можно делать функции, циклы и переменные без каких-то нечеловеческих страданий.
gun_dose
22.04.2024 14:09Обходиться то можно. Но когда, например, ради запуска какого-нибудь npm run watch в двух директориях одновременно люди начинают всё усложнять процесс-менеджерами, вместо того чтобы просто поставить амперсанд после первой команды, то это уже никому не нужное усложнение на пустом месте
cdnnow_writer
22.04.2024 14:09+1Это всё здорово, но если бы об этом не рассуждали за вас, то и Docker у вас не было бы.
Либо у вас и дальше была производительность как на Apple Silicon до недавнего времени.
А помимо вашего личного использования, Docker также используется повсюду для бизнеса, где потеря и нескольких % процессорного времени выливается за год в миллионы убытков.Утверждение про 10 лет весьма сомнительно, проекты рождаются и умирают в течение считанных лет. Для чего достаточно им потерять поддержку всего одной библиотеки. Либо потерять поддержку централизованных репозиториев, чтобы большая часть бывших пользователей выбрала новое однокликовое решение.
gun_dose
22.04.2024 14:09+3В случае с докером единственное, что может случиться за 10 лет - это если пропадут какие-то репозитории. А все неподдерживаемые библиотеки при наличии репозиториев как раз загрузятся легко.
Docker также используется повсюду для бизнеса, где потеря и нескольких % процессорного времени выливается за год в миллионы убытков
Многие почему-то забывают, что локальное окружение может (и по хорошему должно) отличаться от продакшена. Например, локально мне нужны отладчик и мэйл-кэтчер, которым на продакшене не место. Это уже не говоря о том, что ещё несколько лет назад упомянутый мной docker-compose считался инструментом, недостаточно надёжным для использования на продакшене, о чём писали даже в официальных мануалах (может и сейчас пишут, я не знаю). И тем более, когда речь идёт о разных ОС, это всегда только о локальном окружении. Так вот, лучше на локалке получить 5-10-20-50% просадки производительности, чем пытаться установить в систему стек типа php + mysql + apache solr + node.js, да ещё если эта система MacOS или Windows.
И даже если у тебя на продакшене в принципе не используется никакая контейнеризация, всё равно удобно использовать докер для локальной разработки.
cdnnow_writer
22.04.2024 14:09+1А все неподдерживаемые библиотеки при наличии репозиториев как раз загрузятся легко.
При условие если этим кто-то захочет заниматься и разбираться. Чаще получается:
Можно долго рассуждать о матрёшках, корпорациях и фичах Unix, добавленных в 79 году. Но факт остаётся фактом...
И далее как на картинке -
Так вот, лучше на локалке получить 5-10-20-50% просадки производительности
Либо не получить, используя Docker в естественной для него среде обитания на Линуксе.
gun_dose
22.04.2024 14:09При условие если этим кто-то захочет заниматься и разбираться.
Нет, при условии, что docker-compose.yml лежит в репозитории.
cdnnow_writer
22.04.2024 14:09+1Это если зависимость из .yml, а если это касается зависимости используемой непосредственно самим докером или его компонентами, тем же рантаймом?
gun_dose
22.04.2024 14:09Вероятность такого расклада крайне мала. Я за 8 лет использования докера ни раз с таким не сталкивался.
Если лично для вас эта вероятность достаточно высока для того, чтобы отказаться от докера, то какие вы предлагаете альтернативы, не подверженные таким рискам?
cdnnow_writer
22.04.2024 14:09За 8 лет вы с этим не сталкивались, но 10 лет в будущее это громадный срок для софта, гарантий того что этого не случится в будущем - нету.
А самое главное, что я сам через 10 лет смогу запустить его и не думать о совместимости старого софта и новой ОС. И в этом плане докеру нет равных.
Для нас эта вероятность примерно такая же как и для всех остальных. Я о том, что эта вероятность есть в принципе и рассуждать и на 1 год вперёд, не обладая даром предвидения - сомнительная затея.
gun_dose
22.04.2024 14:09Сомнительная затея - это вообще не думать наперёд. Для параноиков есть опция экспортировать все образы и сложить в свой репозиторий. И тут опять же нет равных докеру в простоте этой манипуляции. Ну и опять же, на докер завязано очень много дорогущих бизнесов, что в некоторой степени гарантирует наличие обратной совместимости в будущем.
Но вообще, всё то, о чём вы говорите, скорее случится, если не использовать докер, нежели при его использовании.
Timyrlan
22.04.2024 14:09+1Я разрабатываю часть системы для большого бизнеса, и скажу вам, не все так однозначно
Мы работаем с k8s и тут всегда встает вопрос гарантированные ресурсы vc утилизация ресурсов. И очень большим % цпу и озу приходится жертвовать ради надежности.
Long story short: приходится задавать реквесты и лимиты, и они должны быть равны. А это значит, что я могу выделить 1 цпу на сервис или 0.5 или 2, но этот ресурс будет использоваться только этим сервисом, или не использоваться вообще. Честно говоря, меня это убивает, но ничего не поделаешь. И единственный ответ на эту ситуацию - масштабировать горизонтально. Но при этом все равно 10-50% ресурсов оказываются неутилизированными
chupasaurus
22.04.2024 14:09Long story short: приходится задавать реквесты и лимиты, и они должны быть равны.
А зря сокращаете. Вместо того, чтобы расписать PriorityClass по порядку переноса подов на другие ноды для освобождения ресурсов, вы их прибиваете гвоздями присвоением статуса Guaranteed (выставляет oom_score_adj в -997). Причём если контейнеры в поде потребляют меньше request-ов, а лимиты - больше, они вместе с Guaranteed точно также будут убиваться согласно приоритетам, кроме пришествия oom_killer.
Guaranteed сделали для мелких системных подов и наоборот больших, чтобы в случае потребности ресурсов для таковых мелочь перекидать на другие ноды и распихивать по NUMA правильно.
outlingo
22.04.2024 14:09А самое главное, что я сам через 10 лет смогу запустить его и не думать
... о всех тех десятках CVE которые за это время накопились?
gun_dose
22.04.2024 14:09Чтобы исправить CVE, проект нужно обновить. Чтобы обновить проект, его сперва нужно запустить (иначе как проверить, что в результате обновления ничего не сломалось). И если конфиг докера был в репе, то клонировал репозиторий, поднял всё быстренько и давай обновляй. А если нет, то сиди разбирайся, как это поднять, как это собрать, и как понять, что отвалилось, а что нет. Ситуация, когда проект сделали, развернули и потом он работает себе спокойно несколько лет и им никто не занимается, это вовсе не редкость. И я крайне удивлён, что есть люди, которым неочевидны такие вещи.
Mogwaika
22.04.2024 14:09Тут два момента:
1) Как работает обратная совместимость старых образов с новым ядром? (А может и наоборот иногда)
2) Где гарантия, что собранный образ будет где-то храниться вечно, он же тоже место занимает...gun_dose
22.04.2024 14:09По обоим пунктам при использовании докера вероятность наступить на грабли существенно ниже, чем при использовании каких-либо других решений. А хранить образ можно в принципе где угодно, в том числе на сервисах, которые выдадут вам ту самую гарантию в письменном виде.
Mogwaika
22.04.2024 14:09Думаете при использовании образа виртуалки вероятность не ниже?
gun_dose
22.04.2024 14:09А где гарантия, что через N лет на новом железе запустится та софтина, на которой можно запустить этот образ? :D На самом деле проблема в том, что при использовании образа виртуалки разработчики довольно быстро пошлют вас в одно место. При использовании докера клонировал репу, и запустил всё одной командой. Появился новый сервис в проекте - не проблема, сделал пулл и запустил всё той же самой командой. Все конфиги трекаются гитом, всем удобно. А с виртуалкой как работать? Всем сказать, чтобы скачали по ссылке образ? А как его версионировать? Обновил версию php, и надо оповестить всех разрабов, чтобы скачали новый образ.
А самое главное вот что: я могу сделать проект, развернуть у клиента на сервере, а потом наши пути разойдутся, я удалю его репозиторий за ненадобностью. А потом он наймёт другого разработчика, тот найдёт на сервере в корне проекта конфиг докера, стянет к себе и у него всё запустится. "Вот же хороший человек делал" - подумает он. А если я буду использовать виртуалку, то никто не узнает, что я хороший :D
А ещё, если работаешь с большим количеством проектов, то обмазываться виртаулками вообще такое себе удовольствие
Mogwaika
22.04.2024 14:09Подождите, у докер образов есть теги, по ним и версионировать, как и образы виртуалок (да, перекачивать. Но и слои докера не всегда работают автоматом, если образ большой).
Про клонирование репы не понял...
Конфиг докера не факт что пересоберётся, если он тянет что-то из интернета. Ну и часто для него самого нужно какие-то зависимости подключать с дистрибутивами, чтоб собрать.gun_dose
22.04.2024 14:09Про клонирование репы не понял...
Конфиги докера для локального окружения надо хранить в репозитории.
Конфиг докера не факт что пересоберётся, если он тянет что-то из интернета
Как это не факт, если факт?) Вот так работаешь годами в разных компаниях с десятками разных людей, с десятками проектов, и всегда у всех всё работает как часы. А тут приходит какой-то чел и говорит "не факт". Я даже не знаю, что на это сказать. Или речь о каких-то форс-мажорных обстоятельствах? Ну так знаете, бывает хочешь включить компьютер, а он не включается - сломался. И что тогда, всем перестать пользоваться компьютерами из-за этого?
Mogwaika
22.04.2024 14:09Ну какой-то репозиторий могут удалить с гита (xz) или архив с сайта и данные не скачаются.
Есть сайты, которые не отдают дистрибутивы без регистрации, так например нужно скачать компилятор/синтезатор ручками, собрать и запечатать докер образ с ними, чтоб в дальшейшем был референсный образ для компиляции/синтеза кода для всех разработчиков и каждому не нужно будет разворачивать на своей системе весь тулчейн + будет воспроизводимость.gun_dose
22.04.2024 14:09А образ виртуалки у вас обязательно будет храниться в каком-то божественном месте, откуда его никогда не удалят и всем раздадут без регистрации?
В реальной жизни большинство образов тянется с докер-хаба. И за основу берутся официальные образы. Я не знаю, что должно случиться, чтобы докер-хаб закрыли, или чтобы из него удалили официальный образ, например mysql. Есть конечно люди, которые умнее других и предпочитают исключительно собственные образы, где всё собрано собственноручно из исходников. Был у нас случай, девопс смотрит: "чего это у вас образ php весит аж 250МБ? Я сейчас свой соберу". Неделю собирал, в итоге сделал. Это чудо на локалке билдилось 40 минут и в итоге весило 400МБ. Ну что я могу в таком случае сказать? Тут наши полномочия, как говорится, всё.
Mogwaika
22.04.2024 14:09Что образ виртуалки, что сбилженный докер надо у себя хранить, это понятно...
Про базовый образ понятно, что скорее всего он доступен (но санкции тоже никто не отменял).
Я про следующие шаги, где вы какие-то внешние зависимости подтягиваете с гитхаба stm32 cmsis или ещё что-то что автор может взять и удалить, когда захочет, а потом какую-нибудь Vivado ide одним слоем на 120 гигов поставите (это уже к вопросу о размере) которая скачивается из под учётки только.gun_dose
22.04.2024 14:09Тут у меня много вопросов к тем, кто так делает. По уму один сервис - один контейнер. Тогда и не надо хранить сбилженные образы нигде - просто используешь базовые со своими конфигами среды. Иногда приходится конечно что-то делать своё, но там опять же в Dockerfile установка пары-тройки зависимостей в базовый образ. А если прямо постоянно приходится билдить какие-то сложные образы, то это повод задуматься, всё ли правильно ты делаешь.
Mogwaika
22.04.2024 14:09А вы где-то видели готовый образ под сборку микроконтроллеров или плисин (да, по одному сервису, только для билда, даже без отладки возьмём)?
gun_dose
22.04.2024 14:09Хм, я даже не думал, что кому-то придёт в голову использовать докер для этого.
Mogwaika
22.04.2024 14:09+1Ну чтоб и на ci и у разработчиков получался bit-exact build (ну возможно с точностью до таймстемпов, если они в бинарь попадают).
gun_dose
22.04.2024 14:09Тут уже надо смотреть по целесообразности. К примеру, в веб-разработке конфигурация даже очень сложного проекта завесит каких-нибудь пару килобайт и разворачиваться будет за считанные секунды. Поэтому там докер и удобнее виртуалки. Если же образ билдится очень долго и весит много гигабайт, тот тут уже преимуществ перед виртуалкой практически не остаётся. Скачать и запустить 100ГБ виртуалку будет наверное в разы быстрее, чем билдить образ на 100ГБ.
Mogwaika
22.04.2024 14:09Так его тоже не надо билдить каждый раз же (там проблемы со скачиванием у докера правда есть)...
А запускать программы из докера и правда удобнее, чем в виртуалке.
mayorovp
22.04.2024 14:09+1Ну вот у нас одно время через раз собирался проект из-за частой недоступности репозиториев Убунты. Потому что там apt-get первой же строчкой.
А в соседней комнате на старом проекте другая беда - сначала они сломали себе команду
npm ci, потому что сослались на модуль по прямой ссылке на репозиторий - а теперь у них постоянно ломается сборка из-за использованияnpm iИ это то что происходит прямо сейчас, несмотря на все докеры (и даже отчасти благодаря им). А что через 10 лет будет?
gun_dose
22.04.2024 14:09Ну вот у нас одно время через раз собирался проект из-за частой недоступности репозиториев Убунты. Потому что там apt-get первой же строчкой.
Это решается довольно просто - сбилдить образ и положить в место, которое более доступно, чем репозиторий убунты.
сначала они сломали себе команду
npm ciДокер не починит сломанный npm ci, но если надоело его чинить, то можно просто закоммитить это в репу, а через 10 лет продолжить чинить с того же места.
И это то что происходит прямо сейчас, несмотря на все докеры
Это происходит из-за того, что ваши фронтендеры не умеют работать с npm, а не из-за докера. Если сконфигурировать проект так, чтобы
npm ciс нуля всегда выполнялся без ошибок, и чтобы основной скрипт (build, watch, serve или что там у вас) всегда тоже запускался без ошибок, то он и в докере будет гарантированно работать.Чтобы понять, зачем при разработке фронтенда нужен докер, надо просто установить npm себе в систему и всё время работать под ним. Потом поставить один из проектов на паузу и вернуться к нему года через 2-3, тогда все вопросы отпадут сами собой.
mayorovp
22.04.2024 14:09+1Это решается довольно просто - сбилдить образ и положить в место, которое более доступно, чем репозиторий убунты.
Да, и постараться не потерять этот не вполне воспроизводимый артефакт в течении кучи лет.
gun_dose
22.04.2024 14:09Для этого создаётся кастомный реестр образов. Его не так уж просто потерять.
lrrr11
22.04.2024 14:09+2А самое главное, что я сам через 10 лет смогу запустить его и не думать о совместимости старого софта и новой ОС
только если все зависимости лежат локально в том же репозитории. По личному опыту, если в Dockerfile есть внешние зависимости, а это скорее норма чем исключение, то через пару лет что-то из них обязательно отвалится. А даже если все зависимости на месте, то все равно возможны спецэффекты вроде какого-нибудь протухшего сертификата.
Резюме: жизнь - боль, и контейнеры тут, увы, не панацея.
Timyrlan
22.04.2024 14:09+1Интересно, в k8s тоже наверное pivot_root использует?
cdnnow_writer
22.04.2024 14:09+1To use the systemd cgroup driver in /etc/containerd/config.toml with runc, set
apt-get install cri-o cri-o-runc
Docker Engine
Там и так понятно, тоже runchttps://docs.mirantis.com/mcr/23.0/release-notes/23-0-10.html?highlight=runc
MCR contains the following component updates:
containerd 1.6.30~rc.2 **runc** 1.1.12-rc1.m1 cri-dockerd 0.3.11 Fipster (Go runtime) go1.21.8m1Все рантаймы k8s в своей основе используют runc, так что да, pivot_root там задействован.
chupasaurus
22.04.2024 14:09+2И даже там, где нет runc, уже наверняка пришёл cyphar и показал как надо собирать дерево маунтов (это мейнтейнер этого дела примерно везде ещё до распила Docker на компоненты).
Poo-ool
22.04.2024 14:09+4Работаем под линукс как раз по необходимости разворачивать локальные стенды. 3 года работы а линукс все ещё использовать больно. Поэтому для личного пользования только винда, лучше медленный доверять и удобная среда чем наоборот
cdnnow_writer
22.04.2024 14:09[Здесь могла быть реклама вашего дистрибутива]
Я для личного использования везде устанавливаю EndeavourOS(Arch) с KDE Plasma, мне после неё любая другая система кажется неудобной и неповоротливой, в том числе и другие дистрибутивы.
Protosuv
22.04.2024 14:09+2За годы работы в отрасли довелось поработать с разными ОС. Так вот, если идёт речь о личном удобстве: обучение, разные RnD, просто каждодневная работа, то в общем то нет особой разницы между Linux, Windows, MacOS. Мне нравятся каждая по своему. Безусловно везде есть нюансы по юзабилити. Впрочем становится ясно, когда работаешь в крупной компании, то частенько рабочие инструменты, приложения для звонков/переписок, для VPN заточены ну больше на 1-2 среды. Это Windows или MacOS. Как это водится, часть вещей на Linux реализуемы через танцы с бубном. У меня не было желания сисадминить ещё и свой рабочий ноутбук, поэтому мой выбор MacOS. На домашнем ноутбуке Linux Mint. Так и живу.
cdnnow_writer
22.04.2024 14:09У меня для работы/дома везде EndeavourOS(Arch) с KDE Plasma стоит, из администрирования раз в год разве что Nvidia ака NoVidya радует.
Но и с ней, даже полностью мёртвая система чинится достаточно быстро -Захожу в LiveISO с usb-флэшки
Монтирую диск просто тыкнув на него в Dolphin
Делаю chroot в систему
sudo arch-chroot path-to-EOS-partitionНа всякий случай чищу pacman
sudo rm /var/lib/pacman/db.lcksudo pacman -S archlinux-keyringПереустанавливаю вообще всё, где-то 3 минуты на скачивание ~2 тысяч пакетов и 2 минуты они будут устанавливаться.
sudo pacman -S $(pacman -Qqn) --overwrite '*'
jakobz
22.04.2024 14:09А почему человечество не может придумать какой-то стандарт на ABI, чтобы у был способ запускать бинари на любой ОС? Хотя-бы для серверного софта. Там же вроде многого не надо - сокеты, треды, и файловая система. Веб же вон есть, и там 100500 стандартных API - вплоть до WebGL всяких, и гироскопов на мобилках. А в типичных применениях докера - все сильно проще же. Что я тут не понимаю? Зачем там привязка ко всем накопившимся API ядра того же линукса?
spirit1984
Интересная статья. Тогда вопрос - что является правильным эквивалентом докера под мак или винду? Вряд ли vmware/virtualbox. То есть такого эквивалента, который бы запускался, разделяя с ОС ее ядро, тут не имеется?
cdnnow_writer
Извиняюсь, комментарий подвис на модерации.
У Windows есть свои Windows Server Containers, с релиза Windows Server 2016, они могут запускаться по аналогии с Linux, без виртуалки, так и в режиме изоляции с Hyper-V. За основу там взят Docker и форк рантайма runc - runhcs.1,2
Для Мака, официальных попыток, по крайней мере публично-доступных, от самой Apple насколько я знаю нету. Но это получилось у энтузиастов(Darwin Containers), пример я привёл в посте: