Comments 8
Третья иллюстрация (под спойлером), по моему мнению, не самая удачная:
Иллюстрация
В схеме полностью опущен контейнерный OCI-рантайм, в случае Docker это containerd.
Непонятно, почему с ресурсами хостовой машины, на которой запущен dockerd (сети, тома, контейнеры/образы, etc), соединен клиент, а не сервер, и почему он вообще оборачивает собой REST API. Для вводного материала для новичков (это же он, да, исходя из вступительных ремарок?) не очень удачно?
К слову, факт существования контейнерного рантайма в принципе опущен в статье, по ней можно подумать, что dockerd сам по себе занимается обслуживанием контейнеров.
Спасибо за хорошее уточнение. Поясню, почему выбран именно такой вариант схемы. В начале раздела специально сделана ремарка — мы рассматриваем "как с этим работать", а не "как это работает/устроено". В заявленной парадигме мы работаем через клиент, командами которого обращаемся к демону, просим скачать образ, запустить контейнер, прикрутить том с данными или сеть... Именно поэтому "внешним" на схеме является клиент, а ресурсов машины на ней нет вообще. Вы правы, если смотреть на схему с точки зрения "как это происходит" и взаимодействия с ресурсами — ее надо видоизменять. Но в логике объяснения на уровне холодильников и штанг — добавлять про рантайм и углубляться — только усложнять восприятие, имхо.
Объяснение простых концепций с помощью странных аналогий. Почему холодильник? Почему докер? Если приложению нужны свои лимиты, они тривиально выставляются в ulimit, или в cgroups, без привлечения докера.
Почему сковородка, почему плита? Пожарить мясо элементарно можно на костре. Логично, но абсолютно не уместно. Статья про докер, а не про лимиты или ручную изоляцию "без привлечения докера".
Именно, статья должна была быть про докер, а вместо этого пачка аналогий, которые не объясняют причину популярности докера. Вы зачем-то делаете упор на изоляцию, хотя docker - плохое средство изоляции (в сравнении, например, с VM). Ключевая особенность докера - унификация.
я бы сказал что ключевая особенность докера вообще не касается самого докера
ключевая его особенность это возникшая вокруг него экосистема с выбором из 100500 инструментов и интерфейсов
а всё что умеет докер до него умел lxc, и даже больше lxc может сильно больше и вариативнее
сейчас ещё есть systemd-nspawn который скорее всего так же являлся бы хорошей альтернативой если бы не отсутствие экосистемы
У LXC не было унификации delivery. Чтобы запустить что-то с LXC его нужно построить, а процесс построения не определён для LXC (сравнить с `docker build`), не было адекватного аналога hub'а чтобы быстро получить mpv и т.д. Вы правы про экосистемы, но она не "возникла", а было создано достаточно условий, чтобы она могла развиваться.
Ещё у LXC ужасная совместимость между версиями. Смена формата конфигов для subuserid в своё время была просто душераздирающей - новая версия не понимала старого формата, старая не понимала новый, и никакого transitional path (именно в этом месте я lxc и закопал).
systemd-nsspawn - это вообще не об этом. Запускалок в namespace'ах много (и firejail туда же). Ближайшее у systemd - это machinectl с image'ами сервисов
Каждый слой образа — это фиксация изменений (коммит) файловой системы. Суммарный вес штанги — это лишь итоговый вес образа, его объем в байтах. Конфигурация образа — это его содержимое на последнем слое, и вес тут никакой роли не играет.
Да, из соображений экономии диска, вес образа желательно сокращать, но это уже ньюансы сборки.
Docker: по ту сторону Hello World