company_banner

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



    Два года назад мы уже делали обзор GUI-интерфейсов для работы с Docker, однако мир любителей подобных решений не стоит на месте. На днях до версии 0.2 обновился, а вместе с тем и получил широкую огласку, молодой проект lazydocker, позиционирующий себя как «более ленивый путь управлять всем в Docker». Утилита стремительно набирает популярность — ещё вчера количество его GitHub stars не достигало 3000, а уже сегодня перевалило за 4000.

    Возможности


    Авторы lazydocker так поясняют появление своего детища:

    «Запоминать команды docker тяжело. Запоминать алиасы чуть менее тяжело. Следить за состоянием контейнеров по многочисленным окнам терминала практически невозможно. А что, если вся требуемая информация была бы в одном окне, а каждая типовая команда — доступна по нажатию на одну клавишу (и имелась возможность добавлять свои команды)? Цель lazydocker — превратить эту мечту в реальность».

    Итак, lazydocker делает из терминала интерактивный интерфейс для Docker и Docker Compose, позволяющий быстро и удобно переключаться между сервисами, запущенными в разных контейнерах, и связанными с ними ресурсами (образами, томами), просматривать их статус и выполнять различные команды. Поскольку «иногда лучше один раз увидеть», авторы позаботились о весьма самодостаточной gif'ке-иллюстрации:



    Навигация по интерфейсу поддерживается как с помощью клавиатуры, так и мыши. При выборе нужного элемента для него доступно контекстное меню:


    Пример контекстного меню для выбранного контейнера

    Как видно, для каждой команды также предопределена клавиша для быстрого выполнения популярных действий. Полный их список можно увидеть здесь (кстати, у меню есть локализации для нескольких языков, среди которых всё ещё отсутствует русский).

    Отдельного уважения заслуживает то внимание, которое уделено просмотру состояния контейнеров: тут не только вывод логов и конфига, но и графически отображаемая статистика (по умолчанию это потребление CPU/памяти), и top процессов. Эти возможности распространяются и на произвольные метрики, для наглядного просмотра которых тоже настраиваются графики (см. секцию stats в конфиге).

    Для выбранных образов можно увидеть выполняемые при их запуске команды из Dockerfile, унаследованные слои. Предусмотрена очистка неиспользуемых контейнеров, образов, томов (prune).

    Доступные команды можно модифицировать, а также дополнять своими. Как это делать, легко увидеть в блоках commandTemplates и customCommands конфига (к слову, конфиг тоже можно редактировать прямо из самой утилиты):

    commandTemplates:
      dockerCompose: docker-compose
      restartService: '{{ .DockerCompose }} restart {{ .Service.Name }}'
      stopService: '{{ .DockerCompose }} stop {{ .Service.Name }}'
    …
    customCommands:
      containers:
      - name: bash
        attach: true
        command: docker exec -it {{ .Container.ID }} /bin/sh
        serviceNames: []
    …

    Инсталляция


    Lazydocker написан на Go с использованием библиотеки gocui, предназначенной для создания консольных интерфейсов. Требуется версия Go 1.12. Исходный код распространяется на условиях свободной лицензии BSD 3-Clause (New).

    Установка сводится к простой команде:

    go get github.com/jesseduffield/lazydocker

    В остальном — проще попробовать и увидеть своими глазами.

    Перспективы


    Разработкой lazydocker до сих пор преимущественно занимался один человек, но его популярность принесла «свежую кровь» в лице более широкого сообщества. Например, сейчас обсуждаются инициированные менее суток назад PR по переработанному Dockerfile и упрощённой установке бинарного релиза утилиты в Linux-дистрибутивах.

    В issues проекта можно увидеть такие запросы на улучшения, как настраиваемые keybindings и поддержка команды docker stack. Опять же, они появились менее суток назад.

    Всё это говорит о том, что уже в ближайшее время можно ожидать созревания lazydocker до более функционального и удобного решения, на которое у Docker-сообщества оказался явный спрос.

    P.S.


    Читайте также в нашем блоге:

    Флант
    325,44
    Специалисты по DevOps и Kubernetes
    Поддержать автора
    Поделиться публикацией

    Комментарии 16

      –2

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

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

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


          • докер — лишний элемент. Он все равно работает поверх 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/

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

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

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

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


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

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

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

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

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

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

                  Ну так напишут то же самое для podman :) Чего только народ не придумает, лишь бы терминал не открывать.

                  0
                  По факту куб работает на containerd
                  +1
                  Как ни крути, докер — это не просто контейнеры. Это ещё и огромная экосистема — докерхаб, где есть образы почти для всего, приватные реджистри, которые используются во всех энтерпрайзах и поддерживаются уже всеми облаками, и миллионы таких вот утилит, которые тоже облегчают жизнь.
                  А всякие убийцы докера далеко не всегда могут предложить такое же удобство использования и такие же возможности, как докер.
                    +1
                    Это ещё и огромная экосистема — докерхаб, где есть образы почти для всего

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


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

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


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

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


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


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

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

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

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

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

                    Самое читаемое