Lazydocker — GUI для Docker прямо в терминале

[gecube]

Когда докер должен уже наконец-то пойти на покой, парни наконец-то раскочегарились и начали писать к нему утилиты…
И, да, мне проще запомнить 100500 логичных команд docker, тем более, если помогает автодополнение в шелле, чем пользоваться какой-то сторонней непонятной утилитой с непонятными перспективами развития.

[esd]

а с чего он должен на покой то уйти? тот же куб работает на докере по факту.

[gecube]

хотя бы с того, что

• докер — лишний элемент. Он все равно работает поверх containerd, и поверх cgroups/namespaces. Зачем плодить лишние сущности?
• RedHat прилагают достаточные усилия, чтобы отказаться от docker (см. buildah/podman/skopeo)
• производительность и расходование ресурсов лучше БЕЗ докера: https://habr.com/ru/company/flant/blog/414875/

И еще:
https://habr.com/ru/company/flant/blog/340010/
https://habr.com/ru/company/flant/blog/426141/

[pronvis]

а ведь JVM работает поверх операционной системы, зачем плодить лишние сущности?

[gecube]

Да, в случае, если у Вас проект на Java, то необходимость дополнительной контейнеризации переоценена. Тут даже не спорю. Но кубернетес приносит с одной одну штуку, которой в джаве нет — оркестрацию. И все что с этим связано. Джавовскими приложениями ведь все равно нужно управлять!?

[pronvis]

Вы меня не правильно поняли, я ЗА контейнеризацию, даже под Java. А комментарий мой был по поводу вашего `докер — лишний элемент. Он все равно работает поверх containerd, и поверх cgroups/namespaces. Зачем плодить лишние сущности?`. Все эти «лишние» сущности в этих ваших компутарах призваны экономить время и упрощать работу. Да, зачастую ценой потери производительности. А по вашей логике нужно на сях писать, или на ассемблере.

[gecube]

нет, по моей логике все правильно. Сам docker как клиент-серверная штука для управления контейнерами — лишняя. Есть же containerd/runc/cri-o.

А по вашей логике нужно на сях писать, или на ассемблере.

Нет, это было хейтерство именно докера. Повторюсь. Честь им и хвала, что они популяризировали контейнеризацию. В остальном — их продукт (сам движок докера и обвязка к нему) зашел в тупик. Возможно, что здесь есть коммерческий мотив, т.к. крупные корпорации вроде Гугля и РедХата попросту не договорились с Docker Inc., но нам как потребителям и пользователям от этого не легче :-) а продать Docker-EE обычному клиенту практически нереально.

[Karroplan]

благородный дон в курсе, что если бы не было докера, то не было бы containerd? последний когда был частью докера и был насильно отделен от всего проекта.

[gecube]

насильно — это громко сказано. Но что сделано — то сделано. И нужно двигаться дальше :-)

[saboteur_kiev]

сами контейнеры появились задолго до докера.
Докер уложил в красивую коробочку и добавил докерхаб.

Учитывая наличие репозиториев, гитхабов, и так далее — идея в принципе уже витала в воздухе. Был бы не докер, был бы кто-то другой, причем максимум на 1-5 лет позже, не больше.

[saboteur_kiev]

По факту куб работает на containerd

[gecube]

Это ещё и огромная экосистема — докерхаб, где есть образы почти для всего

На первый взгляд — да, но если присмотреться, то оказывается, что все это пригодно только для тестовых сред. Для продуктивной СВОЕЙ среды все придется пересобирать. И хорошо, если не с нуля. Например, типичная проблема — инжект своего корневого сертификата, который используется в энтерпрайзе для выхода в интернет. И это нужно делать в самом начале, т.к. иначе ничего не установится.

приватные реджистри, которые используются во всех энтерпрайзах и поддерживаются уже всеми облаками

Это к докеру никакого отношения не имеет. Более того — формат образа докера стандартизирован и это OCI. Т.е. фактически как такового отдельного формата "докер-образа" и нет.

А всякие убийцы докера далеко не всегда могут предложить такое же удобство использования и такие же возможности, как докер.

На самом деле да, могут. Потому что если докер — это нижележащий слой для кубернетеса, то его замена ± безболезненна, т.к. Вам все равно, что там внутри. Для stand-alone docker хостов — да, там мороки побольше, т.к. нужно изучать новый инструментарий и т.п., причем который пока еще не стандартизирован, но это дело времени. Третий сценарий — использование в тестовых средах. Да кого вообще волнует, что там в тестовых средах? Это прерогатива самого разраба программировать и тестировать в той среде, в которой ему удобно (и, да, внезапно, но для меня было открытием, что до сих пор многие разрабы не умеют в докер).

И еще. В докере много что сделано через… скажем так, неудобно. Те же Dockerfile. Те же лейблы, которые было бы неплохо инжектить в образ с метаданными (кто собрал? когда собрал? из чего собрал?). В принципе, поэтому каждый пайплайн поэтому и уникален и состоит из своих велосипедов, потому что нам не дали готовое решение, а полуфабрикат.

Поэтому я и говорю, что докер — молодцы, что популяризировали контейнеры… но вот теперь нужно двигаться дальше.

[shurup]

ещё вчера количество его GitHub stars не достигало 3000, а уже сегодня перевалило за 4000

Уже 6500+ GitHub stars. И коммиты летят:

[dchusovitin]

Схожие утилиты всегда были, например ctop для Docker, или k9s для Kubernetes.
Хотя у lazydocker сейчас функционала больше.