Comments 26
Существовали и проекты изоляций процессов на уровне файловой системы вроде jails и chroot, но это совсем другая история
На мой взгляд это часть той же истории - сначала в Unix v7 был chroot, потом в FreeBSD придумали более продвинутый jail, после в Linux его обобщили до namespaces, которые уже стали ключевым элементом реализации контейнеров в целом и Docker в частности.
А чем supervisor плох внутри контейнера?
Supervisor вообще потерял какой-либо смысл с момента распространения systemd
Дело не том что он плох внутри контейнера, он в принципе не то чтобы очень хорош. Но суть в том, что не нужно плодить процессы внутри контейнера. Один контейнер/один сервис/одна задача.
Кто сказал что один сервис == один процесс? И как это должно выглядень на каком-нибудь php или ruby? Они однопоточные, им надо воркеров запускать.
Имеется ввиду мастер-процесс. А когда нужно запустить несколько одинаковых бэкендов (ну, например для грейсфул рестарта, или для размазывания по разным хостам нагрузки) -- ничто не мешает запустить несколько контейнеров в которых будет запускаться один мастер процесс того же php-fpm.
Автор имел ввиду то, что бывают кейсы когда в одном контейнере запускают mysql, php, nginx, redis ещё какой нибудь, да и бог знает что ещё. И в целом то оно будет работать, но php-fpm всё ещё течет в некоторых случаях по памяти (ну, по крайней мере в нашем специфичном окружении), и его приходится релоадить. И в случае если же он будет жить в отдельном контейнере -- рестартанул его и всё, а в случае когда всё в одном, то это время на грейсфул шатдаун мускуля, редиса, а потом ещё и время тратится на запуск всего этого.
Когда хочется сделать сервис с кучей зависимостей, ну, как самый простой вариант, использовать docker-swarm (ну, гораздо проще, понятнее и легче для изучения, чем тот же самый minikube, особенно когда на "твои" полтора бложика ну нафиг не нужен кубер) и описывать всё что нужно сервису в docker-compose.
Ну вот если для одной задачи нужно внутри дока запустить три сервиса. 1 сервис - собственно задача докера, и 2 сервиса - зависимости, от которых зависит задача.
Каков тут путь? Три докер-контейнера? Не всегда возможно, да и просто не удобно :)
Потому что docker будет следить за здоровьем процесса супервизора, а не вашего приложения, которое внутри ушло в вечный ребут. Такой контейнер будет здоровым, но бесполезным.
Ещё одна - особенность работы CFS. Когда количество потоков меньше лимитов, то могут быть ложные провалы хелсчеков. Например тому процессу, который обрабатывает хелсчек, просто не дали времени.
Кажется, сейчас уже тяжело представить мир без docker
Я вообще девопсер ненастоящий, могу ошибаться. Но мне кажется сейчас есть альтернативы. Например nix-shell - чем не замена докеру?
Почему? Как-то проработали это 10 лет без докеров
Не поверите, очень легко без всего этого живётся мне - вебмастеру-адммну со стажем 22 года.
Вообще не представляю, для чего мне в хозяйстве из 3 офисов и 15 сайтов нужен докер.
Он очень много где не нужен, куда его пытаются натянуть.
1) быстрая настройка машины. для запуска проекта не надо игратся с утановкой вебсервера пхп ноа и баз данных ожно просто склонировать репу и сделать docker compose up
2) невозможность ситуации когда для запуска нескольких проектов требующих разные версии одного языка нужно танцевать с бубном. Один сайт спокойно в докере запустится на старом пхп 5.6 другой сайт спокойно запустится на пхп8
3)возможность быстро попробовать чтото и удалить не оставляя мусора в системе. Запустить пачку контейнеров вдохновившись статьей по заббиксу и разочароввшись в нем очен ьпросто снести его не выковыривая каждый конфиг из отдельной папки и менять обратнокакието системные настройки.
я работал без докера 6 лет и было норм. но сейчас перешел на докер и не жалею. стало удобнее
Вообще пора вводить премию за выдающийся вклад в IT, и дать ее docker
Статья уровня «сепулек». Куча восхваляющих тезисов, как обычно любят маркетологи, но никакой конкретики относительно того, как это устроено, на какие принципы полагается и за счёт чего.
jail в FreeBSD всегда был понятен: никто никогда не говорил, что это супер-штука, которая революционно изменит вашу жизнь. Всегда декларировалось, что это заложенный в ОС механизм, который изолирует процессы, и создаёт для процесса иллюзию, будто бы он работает внутри обособленной физической машины под управлением FreeBSD, хотя на самом деле ФС, которую видят процессы в джейле и дерево процессов, которые видны в джейле (и ряд других ресурсов), являются только подмножеством родительской ФС, родительского дерева процессов и родительского набора системных вопросов.
И в общем-то из описания автоматически понятно, как такой механизм может быть устроен: поскольку он часть ОС, а ОС используют защищенный режим процессора и концепцию контроля за доступом разных процессов к разным системным объектам, нет никакой проблемы на уровне ОС не только ограничить доступ процессам к объектам и ресурсам, но и создать им иллюзию работы в изолированной среде, причём такую, что юзер-модный процесс «вырваться из матрицы» никакими ухищрениями не сможет?
Но как быть с Докером? Про него вы не пишите ничего.
Это обёртка над уже существующими в ОС инструментами для создания изолированных сред (вроде jail в FreeBSD)? Так бы сразу и писали. Но тогда не понятно, о какой гибкости и универсальности может идти речь, если это примочка для одной отдельно взятой ОС, которая внутри виртуализируемой среды может создавать только видимость той же самой ОС? jail же не умеет на FreeBSD внутри джейла создать видимость ReactOS или MacOS...
Если это не обёртка над jail (или аналогичными инструментами в др. ОС), то тогда ещё интереснее узнать, за счёт чего оно способно создать изоляцию процессов и иллюзию изолированной среды, не работая в режиме ядра и серьёзнейшим образом не вклиниваясь в работу ОС?
Так оно лезет в режим ядра или умудряется создавать видимость изолированной среды чисто из пользовательского режима (перехватывая системные вызовы и подменяя аргументы/возвраты/поведение)?
Вот классические виртуальные машины не нуждаются в режиме ядра и каких-то особых привилегиях, потому что виртуализиремую среду они эмулируют на уровне аппаратной части. Поэтому внутри виртуальной среды может не только другая ОС крутиться, там может эмулироваться принципиально иная аппаратная архитектура.
Например эмулятор Сеги Gens32 или эмулятор автомобильных диагностических сканеров Cascade.
Судя по имеющемуся в статье противопоставлению докера и классических виртуальных машин, Докер это не про этот подход.
Так всё-таки, как это работает? На каком уровне оно виртуализирует? На какие нижележащие средства оно полагается? Ни слова об этом в статье.
В общем, это статья о том, что такое Докер, для тех, кто уже и так знает, что такое Докер, чтобы они почитали и пописались кипятком от восторга...
обёртка над jail (или аналогичными инструментами в др. ОС)
Всё так. Причём для линукса и винды это совершенно разные инструменты. Ну и вообще на сегодняшний день докер - это обертка над оберткой над оберткой: docker -> containerd -> runc -> Linux namespaces. И именно поэтому в Kubernetes выкинули докер и напрямую стали работать с containerd, т.к. для них докер не несет в себе никакой дополнительной пользы.
Докер сделал три важные вещи:
Удобный CLI
Дистрибуцию образов
Докерфайлы
Чем ответить на ваш «сепулек», не представляю, боюсь опускаться до такого уровня.
С вашей точкой зрения всё ясно, однако она не является единственно верной. Как моя статья — субъективное отражение моего понимания вещей, не претендующая на истину в последней инстанции.
Писать всеобъемлющие технические статьи долго, тяжело и как правило не оправдывает средств. Написать статью, которая привлечет интерес читателя и не заставит его заснуть после пяти минут чтения, а возможно еще и заинтересует и вызовет вопросы — тоже та еще задачка. И потом, если бы люди писали статьи не оставляющие вопросов, (где бы токсики сбрасывали яд?) на Хабре не было бы смысла в комментах.
На мой взгляд, человек интересующийся чем-то, должен уметь всесторонне оценивать информацию, делать свои выводы, сравнивая разные точки зрения и не упрощать вещи (в которых 245k+ строк кода) до уровня "обертки" или "изоляции".
Здравствуйте. Ничего толком о Докере не знаю, но постоянно вижу отзывы об этой технологии и нутром чую - "мне надо". Что посоветуете почитать для нулевого новичка?
Слега переигрывая классика, “Очень жаль, что так и не удалось заслушать начальника транспортного цеха главного революционера”. А без его пояснений ничего революционного в давным-давно работающей идее изоляции процессов, эволюционировавшей в идею изоляции среды исполнения, рассмотреть не получается. Но громкого заголовка без упоминания “революции” не получается, да...
Докер мёртв. Сегодня в него вписываются лишь те, кто отстаёт лет так на 10.
10 лет Docker: от революционной идеи до современной практики