lazydocker : un dashboard terminal pour Docker, containerisé

Dans un article précédent, j'ai partagé les fonctions ZSH que j'utilise tous les jours : dex pour entrer dans un container, dstop pour en arrêter un, dlogs pour suivre ses logs. Elles sont rapides, justement parce qu'elles supposent que je sais déjà ce que je veux — choisir un container, faire une chose, terminé.

Mais ce n'est pas toujours la situation. Parfois je viens de démarrer cinq containers pour un test et je ne sais honnêtement pas encore lequel fait grimper le CPU, ni si cette ligne de log aperçue en diagonale était vraiment une erreur. Ce n'est pas un problème de « lancer une commande », c'est un problème de « laissez-moi juste regarder l'ensemble une seconde » — et aucune de mes fonctions dex/dstop/dlogs n'est faite pour ça.

Le dashboard en action​

Cinq panneaux, mis à jour en direct, sur les vrais containers de cette machine :

Le panneau de droite diffuse la sortie webpack réelle de ce serveur de dev Docusaurus pendant qu'il recompile — aucun docker logs -f tapé nulle part, juste le container sélectionné à gauche.

Ce que lazydocker affiche réellement​

Déplacez la sélection avec les flèches ou les touches hjkl à la vim ; chaque panneau se met à jour en direct. Sélectionnez un container et le panneau de droite affiche ses logs, en streaming, sans devoir taper docker logs -f <name> d'abord. Appuyez sur Enter sur un container pour ouvrir un menu d'actions — redémarrer, arrêter, supprimer, ouvrir un shell — au lieu de retenir le flag exact de chacune. Si lazydocker détecte un compose.yaml dans le dossier courant, le panneau Containers les regroupe par nom de service compose au lieu de tout lister à plat.

La containerisation​

Vous me connaissez assez bien maintenant : j'aime containeriser les choses, et je ne vais pas non plus installer un binaire Go directement sur mon host pour celui-ci.

Créons un nouveau dossier : mkdir -p ~/tools/lazydocker && cd $_

Puis créez le Dockerfile :

# syntax=docker/dockerfile:1.7-labs?

FROM alpine:3.20

# Check https://github.com/jesseduffield/lazydocker/releases for the current
# tag before building; this ARG makes bumping it a one-line change.
ARG LAZYDOCKER_VERSION=0.25.2?

# The Docker CLI (and the compose plugin) are what lazydocker actually shells
# out to behind the scenes — the binary below is only the TUI on top of them.
RUN apk add --no-cache docker-cli docker-cli-compose curl tar?

RUN curl -Lo /tmp/lazydocker.tar.gz \?
        "https://github.com/jesseduffield/lazydocker/releases/download/v${LAZYDOCKER_VERSION}/lazydocker_${LAZYDOCKER_VERSION}_Linux_x86_64.tar.gz" && \
    tar -xzf /tmp/lazydocker.tar.gz -C /tmp lazydocker && \?
    install -m 0755 /tmp/lazydocker /usr/local/bin/lazydocker && \?
    rm -f /tmp/lazydocker.tar.gz /tmp/lazydocker

ENTRYPOINT ["lazydocker"]?

Deux points méritent d'être soulignés. D'abord, l'image de base installe le CLI Docker lui-même (docker-cli et docker-cli-compose) — lazydocker ne parle pas directement au daemon, il appelle les mêmes commandes docker et docker compose que vous taperiez à la main, elles doivent donc exister dans l'image. Ensuite, la version est fixée via un ARG plutôt qu'écrite en dur dans la ligne curl — vérifiez la page des releases pour le tag actuel avant votre premier build.

Maintenant le compose.yaml :

services:
  lazydocker:
    build: .
    image: lazydocker
    container_name: lazydocker
    stdin_open: true?
    tty: true?
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock?
      - lazydocker-config:/root/.config/jesseduffield/lazydocker?
      - .:/workdir?
    working_dir: /workdir

volumes:
  lazydocker-config:
    # Pin the real volume name so the standalone `docker run` in the wrapper
    # script below reuses this exact volume instead of creating its own
    # project-prefixed one.
    name: lazydocker-config?

stdin_open et tty sont tous deux à true — sans eux, l'interface plein écran de lazydocker n'obtient jamais de terminal interactif pour s'afficher, et le container se terminerait immédiatement.

Buildez : docker compose build.

❯ docker compose build

[+] Building 6.7s (12/12) FINISHED
 => [internal] load local bake definitions                                                                                     0.0s
 => => reading from stdin 529B                                                                                                 0.0s
 => [internal] load build definition from Dockerfile                                                                           0.0s
 => => transferring dockerfile: 884B                                                                                           0.0s
 => resolve image config for docker-image://docker.io/docker/dockerfile:1.7-labs                                               1.0s
 => [auth] docker/dockerfile:pull token for registry-1.docker.io                                                               0.0s
 => CACHED docker-image://docker.io/docker/dockerfile:1.7-labs@sha256:b99fecfe00268a8b556fad7d9c37ee25d716ae08a5d7320e6d51c4d  0.0s
 => [internal] load metadata for docker.io/library/alpine:3.20                                                                 0.0s
 => [internal] load .dockerignore                                                                                              0.3s
 => => transferring context: 2B                                                                                                0.0s
 => CACHED [1/3] FROM docker.io/library/alpine:3.20                                                                            0.0s
 => [2/3] RUN apk add --no-cache docker-cli docker-cli-compose curl tar                                                        3.3s
 => [3/3] RUN curl -Lo /tmp/lazydocker.tar.gz         "https://github.com/jesseduffield/lazydocker/releases/download/v0.25.2/  1.5s
 => exporting to image                                                                                                         0.2s
 => => exporting layers                                                                                                        0.2s
 => => writing image sha256:298337a2dc6d444be7286d2fdde86f6cc3c7fab6599cd654c51c00bd599b7b46                                   0.0s
 => => naming to docker.io/library/lazydocker                                                                                  0.0s
 => resolving provenance for metadata file                                                                                     0.0s
[+] build 1/1
 ✔ Image lazydocker Built
▋

Le wrapper global​

Si je ne lançais lazydocker que depuis ~/tools/lazydocker, il me montrerait... le container de ~/tools/lazydocker lui-même, ce qui n'a aucun intérêt. L'astuce est de monter le dossier dans lequel vous êtes actuellement, pour que la détection de projet de lazydocker trouve le bon compose.yaml. Autrement dit, le simple docker compose run que j'utilise ailleurs ne convient pas ici — le working directory du fichier compose l'emporterait toujours.

Une petite fonction shell règle le problème : elle monte le dossier où vous vous trouvez, et comme elle vit dans un fichier que votre shell charge au démarrage (l'organisation expliquée dans mon workflow ZSH modulaire), lazydocker fonctionne depuis n'importe quel dossier sans toucher à /usr/local/bin ni à sudo :

# lazydocker: open the containerized lazydocker TUI on the current folder,
# so it picks up a local compose.yaml and shows a "project" view instead of
# a flat container list. Works in zsh and bash: save it as
# ~/.zsh/fns/lazydocker.zsh or ~/.bash/fns/lazydocker.sh (see the article).
lazydocker() {
    local image="lazydocker"?
    # Permanent home of the Dockerfile and compose.yaml, so the image can always be rebuilt.
    local build_dir="${HOME}/tools/lazydocker"
    # Shown as is in the messages, so the command can be copied for any user.
    # shellcheck disable=SC2016
    local build_dir_shown='${HOME}/tools/lazydocker'?
    local config_dir="/root/.config/jesseduffield/lazydocker"

    if ! command -v docker >/dev/null 2>&1; then?
        printf '\e[31mError: docker is not installed or not in your PATH.\e[0m\n' >&2
        return 1
    fi

    if ! docker image inspect "${image}" >/dev/null 2>&1; then?
        printf '\e[31mError: the Docker image "%s" does not exist on this machine.\e[0m\n\n' "${image}" >&2
        printf 'How to continue:\n' >&2
        if [[ -f "${build_dir}/compose.yaml" ]]; then
            printf '  1. (cd "%s" && docker compose build)\n' "${build_dir_shown}" >&2
            printf '  2. Run lazydocker again.\n' >&2
        else
            printf '  1. Get the Dockerfile and compose.yaml from https://www.avonture.be/blog/lazydocker\n' >&2
            printf '     and save them in %s\n' "${build_dir_shown}" >&2
            printf '  2. (cd "%s" && docker compose build)\n' "${build_dir_shown}" >&2
            printf '  3. Run lazydocker again.\n' >&2
        fi
        return 1
    fi

    # Your custom actions (see "Customize" in the article), mounted only when the file exists.
    local -a config_mount=()?
    if [[ -f "${build_dir}/config.yml" ]]; then
        config_mount=(-v "${build_dir}/config.yml:${config_dir}/config.yml")?
    fi

    docker run --rm -it \?
        -v /var/run/docker.sock:/var/run/docker.sock \
        -v "lazydocker-config:${config_dir}" \
        "${config_mount[@]}" \?
        -v "${PWD}:/workdir" \
        --workdir /workdir \
        "${image}"
}

Le code est identique pour zsh et bash ; seuls le dossier et le chargeur diffèrent.

for fn_file in ~/.zsh/fns/*.zsh; do
  source "$fn_file"
done

for fn_file in ~/.bash/fns/*.sh; do
  [[ -r "$fn_file" ]] && source "$fn_file"
done

Vérifiez que le shell connaît la fonction : type lazydocker doit répondre lazydocker is a shell function.

Si l'image manque, la fonction affiche la commande docker compose build exacte à lancer depuis ~/tools/lazydocker, ou renvoie vers cet article si ce dossier a disparu lui aussi.

Depuis n'importe quel dossier de projet maintenant — ce repo Docusaurus, l'API d'un client, peu importe — lancer lazydocker ouvre le dashboard limité aux containers de ce dossier.

Personnalisation​

Le menu d'actions de lazydocker est extensible : n'importe quelle commande shell peut y apparaître sous un nom, dans n'importe quel panneau — containers, images, volumes, réseaux. La configuration tient dans un seul fichier YAML que lazydocker lit depuis son dossier de config, celui-là même que le volume nommé lazydocker-config persiste déjà.

Les deux ajouts les plus utiles dépendent du panneau où vous êtes :

• Panneau Containers — le container tourne déjà ; docker exec y entre directement.
• Panneau Images — rien ne tourne encore ; docker run --rm démarre un container jetable à partir de l'image sélectionnée, vous dépose dans un shell, et supprime le container dès que vous sortez.

Les deux cas, les deux shells, dans un seul fichier. Créez ~/tools/lazydocker/config.yml :

customCommands:
  containers:
    - name: bash
      attach: true
      command: 'docker exec -it {{ .Container.ID }} bash'?
      serviceNames: []?
    - name: sh
      attach: true
      command: 'docker exec -it {{ .Container.ID }} sh'
      serviceNames: []
  images:
    - name: bash
      attach: true
      command: 'docker run -it --rm {{ .Image.Name }}:{{ .Image.Tag }} bash'?
      serviceNames: []
    - name: sh
      attach: true
      command: 'docker run -it --rm {{ .Image.Name }}:{{ .Image.Tag }} sh'
      serviceNames: []

Les quatre entrées utilisent attach: true pour que lazydocker cède le terminal au shell au lieu de lancer la commande en arrière-plan. bash et sh couvrent les images qui embarquent l'un ou l'autre — les images basées sur Alpine n'ont que sh.

Dites maintenant au fichier compose de bind-monter ce fichier par-dessus le volume nommé — Docker superpose les montages de fichiers aux montages de volumes pour les chemins qui se recouvrent, donc config.yml l'emporte pendant que le volume continue de persister la disposition des panneaux et l'ordre de tri :

volumes:
  - /var/run/docker.sock:/var/run/docker.sock
  - lazydocker-config:/root/.config/jesseduffield/lazydocker
  - ./config.yml:/root/.config/jesseduffield/lazydocker/config.yml
  - .:/workdir

La fonction lazydocker n'a besoin d'aucune modification : elle monte déjà ~/tools/lazydocker/config.yml dès que ce fichier existe.

Redémarrez lazydocker une fois pour prendre en compte le nouveau montage. Dans le panneau Containers, sélectionnez un container actif, appuyez sur Enter, et bash/sh apparaissent dans le menu — une touche pour y entrer. Dans le panneau Images, sélectionnez n'importe quelle image, appuyez sur Enter, et bash/sh vous permettent d'en démarrer un container jetable sur-le-champ.

Ma fonction dex face à lazydocker​

Docker Desktop mérite-t-il encore sa place ?​

Sous Windows, je garde Docker Desktop actif parce que c'est lui qui fournit le moteur — mais son interface graphique était aussi l'endroit où j'allais regarder les logs, redémarrer un container ou voir ce qui bouffait la mémoire. lazydocker fait cette partie de façon identique, plus vite, et de la même manière sur chaque machine au lieu de la seule machine Windows.

En pratique, depuis que j'ai installé lazydocker, j'ouvre cette fenêtre peut-être une fois par mois, pour augmenter une limite de ressources. Désinstaller Docker Desktop est une autre question — généralement motivée par les conditions de licence de Docker pour les grandes organisations plutôt que par lazydocker — et la réponse là, c'est Docker Engine qui tourne directement dans une distro WSL2, avec lazydocker par-dessus exactement comme configuré ci-dessus.

Points clés​

Conclusion​

dex, dstop et dlogs restent exactement ce que je dégaine dès que je sais ce que je veux faire. lazydocker comble le vide juste avant ce moment — le réflexe « laissez-moi juste regarder une seconde » auquel un menu fuzzy-finder n'est pas fait pour répondre. Et comme ce n'est qu'un container de plus qui partage un socket, il s'intègre dans le même modèle mental que l'article DooD sans ajouter un seul concept nouveau — juste un nouveau dashboard posé sur un mécanisme déjà compris. Prochaine étape : la version navigateur de cette même idée, pour les fois où le terminal n'est pas l'outil que quelqu'un d'autre a sous les yeux.