Comments 85
Интересная статья. Тогда вопрос - что является правильным эквивалентом докера под мак или винду? Вряд ли vmware/virtualbox. То есть такого эквивалента, который бы запускался, разделяя с ОС ее ядро, тут не имеется?
Извиняюсь, комментарий подвис на модерации.
У Windows есть свои Windows Server Containers, с релиза Windows Server 2016, они могут запускаться по аналогии с Linux, без виртуалки, так и в режиме изоляции с Hyper-V. За основу там взят Docker и форк рантайма runc - runhcs.1,2
Для Мака, официальных попыток, по крайней мере публично-доступных, от самой Apple насколько я знаю нету. Но это получилось у энтузиастов(Darwin Containers), пример я привёл в посте:
Хотя реализация подобного функционала под MacOS полностью возможна, и у энтузиастов даже получилось создать свои, нативные для MacOS, контейнеры.
У Windows есть свои Windows Server Containers, с релиза Windows Server 2016, они могут запускаться по аналогии с Linux, без виртуалки, так и в режиме изоляции с Hyper-V. За основу там взят Docker и форк рантайма runc - runhcs.1,2
Для Мака, официальных попыток, по крайней мере публично-доступных, от самой Apple насколько я знаю нету. Но это получилось у энтузиастов(Darwin Containers), пример я привёл в посте:
Хотя реализация подобного функционала под MacOS полностью возможна, и у энтузиастов даже получилось создать свои, нативные для MacOS, контейнеры.
Автору просьба пояснить за Docker containers for Windows - они архитектурно не имеют ничего общего с обычными Контейнерами Docker. Может, там избавились от "матрёшечной" виртуализации на ровном месте?
От этой матрёшочности избавились в Windows Server Containers, с релизом Windows Server 2016. Но там опционально, есть вариант дополнительно использовать Hyper-V для изоляции.
В смысле есть вариант? Для запуска доцкеров на фортках всего два варианта: старый доцкер который всё запускает через VirtualBox, да новый, который захочет Hyper-V, которые в свою очередь захотят чтобы у вас была либо серверная винда, либо PRO редакция win10 1809 или новее. Дальше в этой матрёшке есть ещё нюансиков, например доцкер с isolation=process на 20H2 работал, а на более новых уже нет, т.к. ABI форточек не совпали и нужна полная виртуализация. Хотите isolation=process - валяйте на серверную версию или вечно сырую win11. И образы нехилого размера, которые внутри тащат реально целую ОС в случае с Windows Containers, но кривые настолько, что в какой-то момент даже дотнетчики переходят на Linux Containers (заодно решаются всякие детские баги типа пропадающей сетки между перезапусками и утекающей вёдрами ОЗУ)
Докер никогда не умел и сейчас не умеет запускаться "через VirtualBox". Можно было только поставить под него "полновесную" виртуалку с линукс, а в неё уже ставить докер. На Home редакциях, где нет Hyper-V сейчас можно запускать Docker Desktop на WSL2. Для чего вообще может понадобиться запускать докер на винде для production лично я в душе не знаю, а для разработки докер под WSL2 полностью годится.
До этих вот модных 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 срезали, в официальной документации упоминается что они менее безопасны. Но всё ещё жрут как не в себя по сравнению с никсами.
В общем-то, для меня никогда не было проблемой его и в любой обычной виртуалке запускать. Ну да, Docker Desktop совсем чуть-чуть удобней. Но я все равно с ним всегда работаю из командной строки - будет это просто "локальный" WT c PowerShell + DockerCompletion или тот же WT только подключенный по SSH к виртуалке - разницы почти что никакой.
WSL2 по факту тоже использует Hyper-V.
Кажется, это устаревшая информация. Сейчас WSL2 доступен для Windows 10/11 Home, а следовательно и Docker.
А как на FreeBSD запускать контейнеры docker проще всего? Несколько лет назад пытался найти способ - какие-то пакеты были заброшены, что не рекомендовалось к использованию, что-то было в разработке. Пришлось просто использовать linux в bhyve и в нем поднять docker.
К сожалению, судя по той же Wiki FreeBSD, нативный Docker там скорее мёртв, нежели жив. И полноценно использовать его так и придётся в связки bhyve + Linux.
У FreeBSD сообщества достаточно давняя история неприязни к Docker и Podman, так как их ОС из коробки предоставляет достаточно богатый набор инструментов для изоляции процессов.
И тут мы уже переходим в плоскость определений и различий контейнеров с песочницами.
Chroot в целях подобной некромантии и иных задач с нами уже очень давно — аж с 7 версии Unix из далёкого 1979 года. А в BSD — с 1982.
Таки контейнеры - это всё-таки не просто чрут, но и изоляция процессов.
Так что всё-таки не 1982-й, а скорее 1991-й, когда там zones на всякое commodity железо портировали.
Совершенно верно, это не просто чрут. Но я и не утверждал, что только им всё ограничивается, по моему мнению он является фундаментом для контейнеров. И тот же Docker с Podman, весьма трудно представить и без того же Go, в качестве скриптового языка всей их инфраструктуры. Да и видимый многими в кошмарах YAML, играет свою роль для конфигов.
Так что всё-таки не 1982-й, а скорее 1991-й, когда там zones на всякое commodity железо портировали.
Для Docker важнее будет скорее непосредственно cgroups, появившиеся в 2007. И Jails в BSD с namespaces в Linux появились в 2000 и 2002.
Кроме дерева каталогов файловой системы, в линукс все построено по дереву.
Дерево процессов, дерево устройств, дерево маунтов. Поэтому докер это не навеска над файловой системой, а манипуляция этими деревьями.
Делаешь контейнер и по желанию делаешь в нем корневым процессом твой entry point, вот и изоляция процессов. А маунты и каталоги при этом можно не менять.
То есть у вас значимая неточность в определении - а именно, что не файловая система является фундаментом. Есть же правильный уровень иерархии - дерево маунтов, именно на этом уровне происходит chroot
Можно долго рассуждать о матрёшках, корпорациях и фичах Unix, добавленных в 79 году. Но факт остаётся фактом, я могу собрать проект на docker + docker-compose, закинуть всё это на гитхаб, и любой юзер, у которого есть docker + docker-compose, сможет запустить этот проект у себя на компе, независимо от того, какая у него ОС (хотя конечно есть нюансы с Apple M-серий и x86 контейнерами). А самое главное, что я сам через 10 лет смогу запустить его и не думать о совместимости старого софта и новой ОС. И в этом плане докеру нет равных.
Любой разработчик запустит на другой ос и столкнётся с деталями реализации на это ос. Если проект не hello world конечно
В эпоху монолитов всё эти компоузы были не нужны как-то
Через 10 лет у вас будет другая ОС (см п1)
За 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.5все красиво, когда есть специалист, который умеет правильно готовить. У нас вот в компании год цирк с конями (девопсами), не могут нормального найти. Наболело, прастити
Ну как во мне, докер - это база, которую должны знать все, независимо от стека. Это как bash. Неважно, кто ты девопс, бэкендер, фронтендер, ML-специалист - тебе это всё равно пригодится.
про докер согласен, про баш уже нет) Но знаний одного докера ой как недостаточно для решения большинства вопросов
Я не говорю, что докер = баш, я имею в виду, что степень их важности одинаковая (хотя на самом деле баш важнее). Это разные инструменты для абсолютно разных целей. Но если разработчик не знает баш - это плохой разработчик, тут без вариантов. То же самое с докером, если разработчик не знает докер - это плохой разработчик. Вот, что я имею в виду.
А зачем знать bash?
Например, чтобы не донимать тимлидов или девопсов дурацкими вопросами типа как сгенерить ключ через новомодную гуёвину, которой никто не пользуется. Или чтобы быть в состоянии самому написать какую-никакую автоматизацию, CI-пайплайн, кронджоб. Чтобы уметь запустить сайт на сервере. Можно долго перечислять.
Но вообще, у меня встречный вопрос: на какой круг задач рассчитан программист, не знающий баш?
Ну я вот как-то 18 лет работы обхожусь без скриптов на баше. И даже без grep-а и пайпов команд друг в друга. Понятно что в command line вызвать git/openssh/ping/docker/etc - я могу. Но если что-то чуть сложнее - беру просто язык программирования, на котором все остальное в проекте, и на нем делаешь на нём всё что нужно. В человеческих языках, кроме grep-ов по файлам - можно и в API сходить, и сервак выставить, и в БД сходить, и алгоритм какой нетривиальный сделать. Не говоря уже что можно делать функции, циклы и переменные без каких-то нечеловеческих страданий.
Обходиться то можно. Но когда, например, ради запуска какого-нибудь npm run watch в двух директориях одновременно люди начинают всё усложнять процесс-менеджерами, вместо того чтобы просто поставить амперсанд после первой команды, то это уже никому не нужное усложнение на пустом месте
В человеческих языках, кроме grep-ов по файлам - можно и в API сходить, и сервак выставить, и в БД сходить, и алгоритм какой нетривиальный сделать. Не говоря уже что можно делать функции, циклы и переменные без каких-то нечеловеческих страданий.
В баш можно и в API сходить и в базу и алгоритм нетривиальный сделать.
И функции и циклы и переменные там есть без нечеловеческих странадий. Что тут нечеловеческого????
function () {
blabla
}
variable=blabla
for variable in @list; do
blabla
done
Я не понимаю, почему люди так извращаются и боятся освоить основы баш, приплетая ему какие-то небылицы.
потому что баш это
1) не только язык программирования, но еще и понятная и удобная оболочка, через которую ты подключаешься на удаленный сервер или даже внутрь контейнера.
Ведь если не брать виндовые сервера, все остальные (а их подавляющее большинство) крутится без графического интерфейса, и нужно просто уметь работать в командной строке для базовых вещей - ориентироваться в файловой системе, пользоваться широчайшим набором консольных команд ну и базовые скриптики для автоматизации
2) баш, а точнее *nix shel ( sh, bash, ksh, zsh) - это скриптовый язык, который выступает основным клеем при интеграции огромного количества инструментов. Где-то юзаются yaml и даже helm, но CLI реально очень часто встречается чтобы интегрировать продукты, которые не задекларированы или просот чтобы не мучаться, не так сложно их связать.
3) Ну и это удобный язык для автоматизации повседневных вещей. Вызывать ffmpeg или openssl или что-то еще в этом роде, удобнее через нормальный шелл типа bash или powershell, а не из питона или из го.
Это всё здорово, но если бы об этом не рассуждали за вас, то и Docker у вас не было бы.
Либо у вас и дальше была производительность как на Apple Silicon до недавнего времени.
А помимо вашего личного использования, Docker также используется повсюду для бизнеса, где потеря и нескольких % процессорного времени выливается за год в миллионы убытков.
Утверждение про 10 лет весьма сомнительно, проекты рождаются и умирают в течение считанных лет. Для чего достаточно им потерять поддержку всего одной библиотеки. Либо потерять поддержку централизованных репозиториев, чтобы большая часть бывших пользователей выбрала новое однокликовое решение.
В случае с докером единственное, что может случиться за 10 лет - это если пропадут какие-то репозитории. А все неподдерживаемые библиотеки при наличии репозиториев как раз загрузятся легко.
Docker также используется повсюду для бизнеса, где потеря и нескольких % процессорного времени выливается за год в миллионы убытков
Многие почему-то забывают, что локальное окружение может (и по хорошему должно) отличаться от продакшена. Например, локально мне нужны отладчик и мэйл-кэтчер, которым на продакшене не место. Это уже не говоря о том, что ещё несколько лет назад упомянутый мной docker-compose считался инструментом, недостаточно надёжным для использования на продакшене, о чём писали даже в официальных мануалах (может и сейчас пишут, я не знаю). И тем более, когда речь идёт о разных ОС, это всегда только о локальном окружении. Так вот, лучше на локалке получить 5-10-20-50% просадки производительности, чем пытаться установить в систему стек типа php + mysql + apache solr + node.js, да ещё если эта система MacOS или Windows.
И даже если у тебя на продакшене в принципе не используется никакая контейнеризация, всё равно удобно использовать докер для локальной разработки.
А все неподдерживаемые библиотеки при наличии репозиториев как раз загрузятся легко.
При условие если этим кто-то захочет заниматься и разбираться. Чаще получается: Можно долго рассуждать о матрёшках, корпорациях и фичах Unix, добавленных в 79 году. Но факт остаётся фактом...
И далее как на картинке -
Так вот, лучше на локалке получить 5-10-20-50% просадки производительности
Либо не получить, используя Docker в естественной для него среде обитания на Линуксе.
При условие если этим кто-то захочет заниматься и разбираться.
Нет, при условии, что docker-compose.yml лежит в репозитории.
Это если зависимость из .yml, а если это касается зависимости используемой непосредственно самим докером или его компонентами, тем же рантаймом?
Вероятность такого расклада крайне мала. Я за 8 лет использования докера ни раз с таким не сталкивался.
Если лично для вас эта вероятность достаточно высока для того, чтобы отказаться от докера, то какие вы предлагаете альтернативы, не подверженные таким рискам?
За 8 лет вы с этим не сталкивались, но 10 лет в будущее это громадный срок для софта, гарантий того что этого не случится в будущем - нету.
А самое главное, что я сам через 10 лет смогу запустить его и не думать о совместимости старого софта и новой ОС. И в этом плане докеру нет равных.
Для нас эта вероятность примерно такая же как и для всех остальных. Я о том, что эта вероятность есть в принципе и рассуждать и на 1 год вперёд, не обладая даром предвидения - сомнительная затея.
Сомнительная затея - это вообще не думать наперёд. Для параноиков есть опция экспортировать все образы и сложить в свой репозиторий. И тут опять же нет равных докеру в простоте этой манипуляции. Ну и опять же, на докер завязано очень много дорогущих бизнесов, что в некоторой степени гарантирует наличие обратной совместимости в будущем.
Но вообще, всё то, о чём вы говорите, скорее случится, если не использовать докер, нежели при его использовании.
Я разрабатываю часть системы для большого бизнеса, и скажу вам, не все так однозначно
Мы работаем с k8s и тут всегда встает вопрос гарантированные ресурсы vc утилизация ресурсов. И очень большим % цпу и озу приходится жертвовать ради надежности.
Long story short: приходится задавать реквесты и лимиты, и они должны быть равны. А это значит, что я могу выделить 1 цпу на сервис или 0.5 или 2, но этот ресурс будет использоваться только этим сервисом, или не использоваться вообще. Честно говоря, меня это убивает, но ничего не поделаешь. И единственный ответ на эту ситуацию - масштабировать горизонтально. Но при этом все равно 10-50% ресурсов оказываются неутилизированными
Long story short: приходится задавать реквесты и лимиты, и они должны быть равны.
А зря сокращаете. Вместо того, чтобы расписать PriorityClass по порядку переноса подов на другие ноды для освобождения ресурсов, вы их прибиваете гвоздями присвоением статуса Guaranteed (выставляет oom_score_adj в -997). Причём если контейнеры в поде потребляют меньше request-ов, а лимиты - больше, они вместе с Guaranteed точно также будут убиваться согласно приоритетам, кроме пришествия oom_killer.
Guaranteed сделали для мелких системных подов и наоборот больших, чтобы в случае потребности ресурсов для таковых мелочь перекидать на другие ноды и распихивать по NUMA правильно.
А самое главное, что я сам через 10 лет смогу запустить его и не думать
... о всех тех десятках CVE которые за это время накопились?
Чтобы исправить CVE, проект нужно обновить. Чтобы обновить проект, его сперва нужно запустить (иначе как проверить, что в результате обновления ничего не сломалось). И если конфиг докера был в репе, то клонировал репозиторий, поднял всё быстренько и давай обновляй. А если нет, то сиди разбирайся, как это поднять, как это собрать, и как понять, что отвалилось, а что нет. Ситуация, когда проект сделали, развернули и потом он работает себе спокойно несколько лет и им никто не занимается, это вовсе не редкость. И я крайне удивлён, что есть люди, которым неочевидны такие вещи.
Тут два момента:
1) Как работает обратная совместимость старых образов с новым ядром? (А может и наоборот иногда)
2) Где гарантия, что собранный образ будет где-то храниться вечно, он же тоже место занимает...
По обоим пунктам при использовании докера вероятность наступить на грабли существенно ниже, чем при использовании каких-либо других решений. А хранить образ можно в принципе где угодно, в том числе на сервисах, которые выдадут вам ту самую гарантию в письменном виде.
Думаете при использовании образа виртуалки вероятность не ниже?
А где гарантия, что через N лет на новом железе запустится та софтина, на которой можно запустить этот образ? :D На самом деле проблема в том, что при использовании образа виртуалки разработчики довольно быстро пошлют вас в одно место. При использовании докера клонировал репу, и запустил всё одной командой. Появился новый сервис в проекте - не проблема, сделал пулл и запустил всё той же самой командой. Все конфиги трекаются гитом, всем удобно. А с виртуалкой как работать? Всем сказать, чтобы скачали по ссылке образ? А как его версионировать? Обновил версию php, и надо оповестить всех разрабов, чтобы скачали новый образ.
А самое главное вот что: я могу сделать проект, развернуть у клиента на сервере, а потом наши пути разойдутся, я удалю его репозиторий за ненадобностью. А потом он наймёт другого разработчика, тот найдёт на сервере в корне проекта конфиг докера, стянет к себе и у него всё запустится. "Вот же хороший человек делал" - подумает он. А если я буду использовать виртуалку, то никто не узнает, что я хороший :D
А ещё, если работаешь с большим количеством проектов, то обмазываться виртаулками вообще такое себе удовольствие
Подождите, у докер образов есть теги, по ним и версионировать, как и образы виртуалок (да, перекачивать. Но и слои докера не всегда работают автоматом, если образ большой).
Про клонирование репы не понял...
Конфиг докера не факт что пересоберётся, если он тянет что-то из интернета. Ну и часто для него самого нужно какие-то зависимости подключать с дистрибутивами, чтоб собрать.
Про клонирование репы не понял...
Конфиги докера для локального окружения надо хранить в репозитории.
Конфиг докера не факт что пересоберётся, если он тянет что-то из интернета
Как это не факт, если факт?) Вот так работаешь годами в разных компаниях с десятками разных людей, с десятками проектов, и всегда у всех всё работает как часы. А тут приходит какой-то чел и говорит "не факт". Я даже не знаю, что на это сказать. Или речь о каких-то форс-мажорных обстоятельствах? Ну так знаете, бывает хочешь включить компьютер, а он не включается - сломался. И что тогда, всем перестать пользоваться компьютерами из-за этого?
Ну какой-то репозиторий могут удалить с гита (xz) или архив с сайта и данные не скачаются.
Есть сайты, которые не отдают дистрибутивы без регистрации, так например нужно скачать компилятор/синтезатор ручками, собрать и запечатать докер образ с ними, чтоб в дальшейшем был референсный образ для компиляции/синтеза кода для всех разработчиков и каждому не нужно будет разворачивать на своей системе весь тулчейн + будет воспроизводимость.
А образ виртуалки у вас обязательно будет храниться в каком-то божественном месте, откуда его никогда не удалят и всем раздадут без регистрации?
В реальной жизни большинство образов тянется с докер-хаба. И за основу берутся официальные образы. Я не знаю, что должно случиться, чтобы докер-хаб закрыли, или чтобы из него удалили официальный образ, например mysql. Есть конечно люди, которые умнее других и предпочитают исключительно собственные образы, где всё собрано собственноручно из исходников. Был у нас случай, девопс смотрит: "чего это у вас образ php весит аж 250МБ? Я сейчас свой соберу". Неделю собирал, в итоге сделал. Это чудо на локалке билдилось 40 минут и в итоге весило 400МБ. Ну что я могу в таком случае сказать? Тут наши полномочия, как говорится, всё.
Что образ виртуалки, что сбилженный докер надо у себя хранить, это понятно...
Про базовый образ понятно, что скорее всего он доступен (но санкции тоже никто не отменял).
Я про следующие шаги, где вы какие-то внешние зависимости подтягиваете с гитхаба stm32 cmsis или ещё что-то что автор может взять и удалить, когда захочет, а потом какую-нибудь Vivado ide одним слоем на 120 гигов поставите (это уже к вопросу о размере) которая скачивается из под учётки только.
Тут у меня много вопросов к тем, кто так делает. По уму один сервис - один контейнер. Тогда и не надо хранить сбилженные образы нигде - просто используешь базовые со своими конфигами среды. Иногда приходится конечно что-то делать своё, но там опять же в Dockerfile установка пары-тройки зависимостей в базовый образ. А если прямо постоянно приходится билдить какие-то сложные образы, то это повод задуматься, всё ли правильно ты делаешь.
А вы где-то видели готовый образ под сборку микроконтроллеров или плисин (да, по одному сервису, только для билда, даже без отладки возьмём)?
Хм, я даже не думал, что кому-то придёт в голову использовать докер для этого.
Ну чтоб и на ci и у разработчиков получался bit-exact build (ну возможно с точностью до таймстемпов, если они в бинарь попадают).
Тут уже надо смотреть по целесообразности. К примеру, в веб-разработке конфигурация даже очень сложного проекта завесит каких-нибудь пару килобайт и разворачиваться будет за считанные секунды. Поэтому там докер и удобнее виртуалки. Если же образ билдится очень долго и весит много гигабайт, тот тут уже преимуществ перед виртуалкой практически не остаётся. Скачать и запустить 100ГБ виртуалку будет наверное в разы быстрее, чем билдить образ на 100ГБ.
Ну вот у нас одно время через раз собирался проект из-за частой недоступности репозиториев Убунты. Потому что там apt-get первой же строчкой.
А в соседней комнате на старом проекте другая беда - сначала они сломали себе команду npm ci, потому что сослались на модуль по прямой ссылке на репозиторий - а теперь у них постоянно ломается сборка из-за использования npm i
И это то что происходит прямо сейчас, несмотря на все докеры (и даже отчасти благодаря им). А что через 10 лет будет?
Ну вот у нас одно время через раз собирался проект из-за частой недоступности репозиториев Убунты. Потому что там apt-get первой же строчкой.
Это решается довольно просто - сбилдить образ и положить в место, которое более доступно, чем репозиторий убунты.
сначала они сломали себе команду
npm ci
Докер не починит сломанный npm ci, но если надоело его чинить, то можно просто закоммитить это в репу, а через 10 лет продолжить чинить с того же места.
И это то что происходит прямо сейчас, несмотря на все докеры
Это происходит из-за того, что ваши фронтендеры не умеют работать с npm, а не из-за докера. Если сконфигурировать проект так, чтобы npm ciс нуля всегда выполнялся без ошибок, и чтобы основной скрипт (build, watch, serve или что там у вас) всегда тоже запускался без ошибок, то он и в докере будет гарантированно работать.
Чтобы понять, зачем при разработке фронтенда нужен докер, надо просто установить npm себе в систему и всё время работать под ним. Потом поставить один из проектов на паузу и вернуться к нему года через 2-3, тогда все вопросы отпадут сами собой.
А самое главное, что я сам через 10 лет смогу запустить его и не думать о совместимости старого софта и новой ОС
только если все зависимости лежат локально в том же репозитории. По личному опыту, если в Dockerfile есть внешние зависимости, а это скорее норма чем исключение, то через пару лет что-то из них обязательно отвалится. А даже если все зависимости на месте, то все равно возможны спецэффекты вроде какого-нибудь протухшего сертификата.
Резюме: жизнь - боль, и контейнеры тут, увы, не панацея.
Интересно, в k8s тоже наверное pivot_root использует?
To 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 там задействован.
Работаем под линукс как раз по необходимости разворачивать локальные стенды. 3 года работы а линукс все ещё использовать больно. Поэтому для личного пользования только винда, лучше медленный доверять и удобная среда чем наоборот
[Здесь могла быть реклама вашего дистрибутива]
Я для личного использования везде устанавливаю EndeavourOS(Arch) с KDE Plasma, мне после неё любая другая система кажется неудобной и неповоротливой, в том числе и другие дистрибутивы.
Такая-же фигня. Занимаюсь "переездом" на скрепные ПО/ОС, после стольких лет винды Линукс пока что боль. Да и не подходит она мне для дома по разным причинам, помимо нежелания танцевать с бубном, на линь просто нет софта, который мне нужен.
За годы работы в отрасли довелось поработать с разными ОС. Так вот, если идёт речь о личном удобстве: обучение, разные RnD, просто каждодневная работа, то в общем то нет особой разницы между Linux, Windows, MacOS. Мне нравятся каждая по своему. Безусловно везде есть нюансы по юзабилити. Впрочем становится ясно, когда работаешь в крупной компании, то частенько рабочие инструменты, приложения для звонков/переписок, для VPN заточены ну больше на 1-2 среды. Это Windows или MacOS. Как это водится, часть вещей на Linux реализуемы через танцы с бубном. У меня не было желания сисадминить ещё и свой рабочий ноутбук, поэтому мой выбор MacOS. На домашнем ноутбуке Linux Mint. Так и живу.
У меня для работы/дома везде EndeavourOS(Arch) с KDE Plasma стоит, из администрирования раз в год разве что Nvidia ака NoVidya радует.
Но и с ней, даже полностью мёртвая система чинится достаточно быстро -
Захожу в LiveISO с usb-флэшки
Монтирую диск просто тыкнув на него в Dolphin
Делаю chroot в систему
sudo arch-chroot path-to-EOS-partition
На всякий случай чищу pacman
sudo rm /var/lib/pacman/db.lck
sudo pacman -S archlinux-keyring
Переустанавливаю вообще всё, где-то 3 минуты на скачивание ~2 тысяч пакетов и 2 минуты они будут устанавливаться.
sudo pacman -S $(pacman -Qqn) --overwrite '*'
А почему человечество не может придумать какой-то стандарт на ABI, чтобы у был способ запускать бинари на любой ОС? Хотя-бы для серверного софта. Там же вроде многого не надо - сокеты, треды, и файловая система. Веб же вон есть, и там 100500 стандартных API - вплоть до WebGL всяких, и гироскопов на мобилках. А в типичных применениях докера - все сильно проще же. Что я тут не понимаю? Зачем там привязка ко всем накопившимся API ядра того же линукса?
Потому что "человечества" как субъектной сущности нету, есть группы индивидов своими интересами. В рамках одного только Линукса есть грызня между дистрибутивами и внутри проектов и подпроектов дистрибутивов.
Если верить всплывающей и непонятно откуда взявшейся везде статистике что топ 1 миллион сайтов - это 96% Линукс на серверах в бэкенде, то это коммерчески смысла не имеет.
Унификация в Вебе не магическим образом работает и под капотом для каждой системы нужны свои оптимизации под низкий уровень. Да и то, уж который год поддержка того же GPU-ускорения с горем пополам то работает, то нет, то требует отрубить песочницу для её работы.
Ну вроде бы никто и не утверждал что революция докера заключается в какой-то хитрой изоляции процессов - для этого он полагается на функции операционной системы.
Революция ведь заключается в том что они сделали удобный стандарт для образов и их создания.
Странная революция. Стандартная история когда на основе многих ранее существовавших идей и инструментов предложили готовый из коробки продукт + экосистему к нему.
Революция ведь заключается в том что они сделали удобный стандарт для образов и их создания.
Но были и те кто до них были и делали это для себя/своей фирмы на основе множества баш скриптов или ещё чего-то.
Революционность подразумевает радикальную смену парадигмы/что-то совершенно новое.
Ну и вторая основная претензия к маркетингу контейнеризации - это сравнение её с виртуализацией, хотя это 2 совершенно разных технологии, имеющих мало общего.
точнее удобные cli утилиты и репозиторий
Винда умеет в lcow (linux containers on windows) и wcow (windows containers on windows). В статье только первый вариант описан, тут без вопросов, оно никак иначе не работает, отсюда и все минусы. А вот как раз wcow имеет две реализации и одна из них является вполне себе нативной контейнеризацией.
Docker — не то, чем кажется