Dive, ferramenta para explorar imagens Docker e conteúdo de camadas

 (github.com/wagoodman)
10 pontos por GN⁺ 2024-01-09 | 1 comentários | Compartilhar no WhatsApp
  • Dive é uma ferramenta para explorar camadas e conteúdo de arquivos de imagens Docker/OCI e encontrar oportunidades para reduzir o tamanho da imagem
  • É possível executar dive <your-image-tag> com uma tag, ID ou digest de imagem, ou fazer a análise logo após o build de uma só vez com dive build -t <some-tag>.
  • Ao selecionar uma camada, a ferramenta mostra uma árvore de arquivos que combina essa camada com as anteriores, permitindo verificar arquivos adicionados, modificados e removidos, além das alterações acumuladas, na árvore de arquivos
  • A métrica experimental de image efficiency estima, em uma pontuação e no tamanho total, o espaço desperdiçado causado por arquivos duplicados, movimentação de arquivos entre camadas e arquivos que não foram completamente removidos
  • Com CI=true, é possível pular a UI e retornar aprovação/falha com base em critérios de eficiência da imagem e espaço desperdiçado, automatizando o gerenciamento do tamanho de imagens em pipelines de CI

O que o Dive faz

  • Dive é uma ferramenta para explorar imagens Docker, conteúdo de camadas e formas de reduzir o tamanho de imagens Docker/OCI
  • A execução básica consiste em passar uma tag, ID ou digest de imagem
    • dive <your-image-tag>
  • Também pode ser executado como um contêiner Docker; nesse caso, é necessário montar o socket do Docker
    • Usa a imagem docker.io/wagoodman/dive
    • nginx:latest é apresentado como imagem de exemplo
  • Para analisar uma imagem imediatamente após o build, pode-se usar o comando dive build no mesmo formato, em vez de docker build
    • dive build -t <some-tag> .
  • No macOS, a execução da análise de build via contêiner só oferece suporte ao mecanismo de contêiner Docker
  • O estado do projeto é beta quality, e solicitações de novos recursos ou bugs podem ser enviados como issues

Exploração de camadas e alterações de arquivos

  • Ao selecionar uma camada à esquerda, a árvore de arquivos que combina essa camada com as anteriores é exibida à direita
  • É possível navegar pela árvore de arquivos com as setas
  • O estado dos arquivos alterados em cada camada é exibido na árvore de arquivos
    • Alterado
    • Modificado
    • Adicionado
    • Removido
  • O modo de exibição das alterações pode ser ajustado com base em uma camada específica ou nas alterações acumuladas até aquela camada

Eficiência da imagem e estimativa de espaço desperdiçado

  • O painel inferior esquerdo mostra informações básicas das camadas e a métrica experimental de image efficiency
  • Essa métrica estima o espaço desperdiçado dentro da imagem
    • Duplicação de arquivos entre camadas
    • Movimentação de arquivos entre camadas
    • Arquivos que não foram completamente removidos
  • O resultado é fornecido como um score percentual e como o espaço total de arquivos desperdiçado

Uso como critério de aprovação/falha no CI

  • Ao executar com a variável de ambiente CI=true, o Dive pula a UI, analisa a imagem e fornece o resultado pass/fail pelo código de retorno
  • É possível configurar 3 critérios no arquivo .dive-ci na raiz do repositório
    • lowestEfficiency: falha se a eficiência ficar abaixo da proporção especificada
    • highestWastedBytes: falha se o espaço desperdiçado for igual ou superior ao tamanho especificado
    • highestUserWastedPercent: falha se a proporção de desperdício nas camadas do usuário for igual ou superior à proporção especificada
  • No cálculo de highestUserWastedPercent, a base image layer não é incluída no tamanho total da imagem
  • O caminho do arquivo de configuração de CI pode ser sobrescrito com a opção --ci-config

Fontes de imagem e mecanismos de contêiner

  • A opção --source permite escolher de onde a imagem de contêiner será obtida
    • dive <your-image> --source <source>
    • dive <source>://<your-image>
  • As opções de source compatíveis são:
    • docker: Docker engine, valor padrão
    • docker-archive: Docker Tar Archive no disco
    • podman: Podman engine, compatível apenas com Linux

Instalação e formas de execução

  • No Ubuntu/Debian, pode ser instalado por pacote .deb ou via Snap
  • O método via Snap não é recomendado quando o Docker foi instalado com apt-get, e há um aviso de que ele pode quebrar o Docker daemon existente
  • No RHEL/Centos, pode ser instalado por pacote .rpm
  • No Arch Linux, está disponível no extra repository e pode ser instalado com pacman
  • No macOS, pode ser instalado via Homebrew, MacPorts ou pelo build Darwin na releases page
  • No Windows, pode ser instalado via Chocolatey, scoop, winget ou pelo build Windows na releases page
  • Para instalar com a ferramenta do Go, é necessário Go 1.10 ou superior
    • go install github.com/wagoodman/dive@latest
    • Ao instalar por esse método, a versão correta não é exibida ao executar dive -v
  • Também são oferecidos métodos de instalação para Nix/NixOS e x-cmd
  • Ao executar como imagem Docker, é necessário incluir o arquivo de socket do Docker
    • -v /var/run/docker.sock:/var/run/docker.sock
  • Dependendo da versão local do Docker, pode ser necessário usar uma variável de ambiente como DOCKER_API_VERSION=1.37
  • Ao usar um runtime alternativo como Colima, pode ser necessário definir a variável de ambiente DOCKER_HOST para obter imagens locais

Operação e configuração da UI

  • Os principais atalhos alternam entre a visualização de camadas e a árvore de arquivos para navegação, filtragem e alternância de exibição
    • Ctrl+C ou Q: sair
    • Tab: alternar entre visualização de camadas e árvore de arquivos
    • Ctrl+F: filtro de arquivos
    • Ctrl+A: na visualização de camadas, mostrar alterações acumuladas da imagem; na árvore de arquivos, alternar exibição de arquivos adicionados
    • Ctrl+L: mostrar alterações da camada atual
    • Ctrl+R, Ctrl+M, Ctrl+U: alternar exibição de arquivos removidos, modificados e sem alterações
    • Ctrl+B: alternar exibição de atributos de arquivos
  • Nenhuma configuração separada é necessária, mas valores podem ser sobrescritos por um arquivo de configuração YAML
  • Os itens configuráveis incluem mecanismo de contêiner, opção de ignorar erros de parsing de arquivos de imagem, logs, atalhos de teclado, exibição de diff, largura da árvore de arquivos, estado padrão de diretórios recolhidos e exibição de alterações acumuladas de camadas
  • Os locais pesquisados para o arquivo de configuração são:
    • $XDG_CONFIG_HOME/dive/*.yaml
    • $XDG_CONFIG_DIRS/dive/*.yaml
    • ~/.config/dive/*.yaml
    • ~/.dive.yaml
  • Também é possível usar a extensão .yml em vez de .yaml

Leituras relacionadas

1 comentários

 
GN⁺ 2024-01-09
Comentários do Hacker News

  • Ao lidar com imagens e camadas, o crane é excelente, e a biblioteca base, go-containerregistry, também é boa
    Ele permite adicionar novas camadas a imagens existentes ou modificar metadados (env vars, labels, entrypoint etc.), e também “achatar” imagens com várias camadas em uma única camada
    Também é possível fazer “rebase”, reaplicando as mudanças sobre uma nova imagem base, e tudo isso é feito diretamente no registry, sem precisar do Docker
    https://github.com/google/go-containerregistry/blob/main/cmd...

    • Boa recomendação. Diferentemente do Docker, o crane funciona sem root e sem daemon, o que o torna bom de usar no Nix, e ele também está disponível no repositório do Nix com o nome crane
      Com isso, dá para gerenciar com Nix não só as dependências de build (por exemplo, Go), mas também ferramentas de empacotamento e distribuição (por exemplo, gnu tar, crane)
    • Fico curioso se há algum ganho de desempenho quando o número de camadas é menor. Como o tamanho total continua igual mesmo ao combinar imagens, entendo que não há benefício em si na mesclagem de camadas

  • O dive foi realmente útil para entender como imagens Docker funcionam e como escrever um Dockerfile eficiente
    Ler a documentação também é importante, mas ver diretamente como a estrutura de camadas resultante muda depois de alterar o Dockerfile foi decisivo para a compreensão

  • O Dive é excelente. Ferramentas como essa são importantes para aprender e ter confiança sobre exatamente o que estou construindo e distribuindo
    O Dredge também é uma ferramenta que vale conferir, e eu o uso para comparar diferenças entre camadas
    https://github.com/mthalman/dredge/blob/main/docs/commands/i...

  • Pode ser uma pergunta boba, mas fico curioso por que a maioria das ferramentas de contêineres e infraestrutura é escrita em Go
    Docker, Podman, nerdctl, Terraform e Kubernetes vêm à mente, e gostaria de saber se Go oferece alguma vantagem clara ao criar esse tipo de ferramenta

    • Sobre o Docker, posso responder. O primeiro protótipo foi escrito em Python, e a empresa também era centrada em Python
      O principal motivo para reescrever em Go foi aproveitar a popularidade do Go, que estava crescendo na época (2012). Eu estava lá
    • Go é a linguagem mais fácil para cross-compilation e distribuição, tem ótimo desempenho em relação à produtividade, boa concorrência embutida e excelentes recursos de rede na biblioteca padrão
      A diferença fica clara se você imaginar Docker e Kubernetes escritos em outra linguagem popular
    • Vejo ferramentas de sistema, utilitários, ferramentas de linha de comando e software de rede como as áreas em que Go mais brilha
      Como alternativa moderna e madura, Rust parece ser praticamente a única
    • Kubernetes foi escrito em Go porque o Google criou Go e também criou Kubernetes
      O fato de haver muitos engenheiros Go nas equipes internas vem do mesmo motivo
    • Ao executar contêineres, você quer se preocupar o mínimo possível com o sistema subjacente, e Go facilita operar dentro de seu próprio pequeno mundo
      Além disso, há o efeito de ecossistema: dá para aproveitar diretamente pacotes de outras implementações em partes do código

  • Gosto do Dive e o tiro da caixa de ferramentas várias vezes por mês
    Mas fico me perguntando se existe uma forma de ver diretamente o conteúdo do arquivo selecionado. Muitas vezes quero verificar se um arquivo existe dentro de uma camada e depois examinar seu conteúdo; hoje normalmente executo o contêiner e uso cat, ou extraio o conteúdo e entro na pasta

    • Com um pouco de habilidade, dá para acessar arquivos com rsync, mas não é muito diferente de usar cat

  • Ao estender vários contêineres Docker públicos, o Dive me salvou várias vezes no processo de desmontar e entender o que eles fazem por dentro
    É realmente um software nota A+

  • Existem outras ótimas ferramentas TUI de terminal como o dive. lazydocker e dry vêm à mente
    Também há algumas na categoria Docker
    [0] https://terminaltrove.com/

    • O Lazydocker tem uma funcionalidade parecida, mas mais simples
      Conferi e ele permite ver as camadas, mas mostra apenas o comando de cada camada

  • O Dive é uma ferramenta incrível no universo de contêineres/Docker. Fica muito mais fácil depurar o que realmente existe dentro de um contêiner
    Quando começamos o Depot [0], recebíamos muitas perguntas sobre como reduzir o tamanho das imagens e acelerar builds, então escrevi um texto curto [1] sobre como resolver esse problema com o Dive. Talvez esteja um pouco antigo agora, mas ainda pode ajudar alguém
    Inspirados pelo Dive, também tornamos mais fácil mostrar o que realmente existe dentro do contexto de build a cada build, e lançamos isso como recurso do Depot algumas semanas atrás
    [0] https://depot.dev
    [1] https://depot.dev/blog/reducing-image-size-with-dive
    [2] https://depot.dev/blog/build-context

  • Além de ser muito útil, o Dive tem uma vantagem subestimada: o autor é um excelente desenvolvedor e uma pessoa com quem é muito agradável trabalhar

  • A ferramenta container-diff do Google também é muito útil
    Eu a uso para verificar o que scripts arbitrários recomendados para serem executados via pipe no bash vão fazer no sistema

    • Embora seja um pouco menos relacionada a utilitários gerais de contêineres, uso bastante o GoogleContainerTools/container-structure-test
      É uma forma prática de executar testes de integração em apps ou imagens de contêiner
      É uma pena que muitos dos mantenedores originais desses projetos open source do Google tenham saído, então eles parecem precisar de atenção. Tento enviar PRs quando posso e às vezes fechar issues. Em especial, essa ferramenta de testes é muito valiosa para manter a sanidade ao lidar internamente com muitas imagens base que precisamos manter