10 puan yazan GN⁺ 2024-01-09 | 1 yorum | WhatsApp'ta paylaş
  • Dive, Docker/OCI imajlarının katmanlarını ve dosya içeriklerini inceleyen, ayrıca imaj boyutunu küçültme fırsatlarını bulmaya yardımcı olan bir araçtır
  • İmaj etiketi·ID·digest ile dive <your-image-tag> çalıştırabilir veya dive build -t <some-tag>. ile build sonrası anında analiz işlemini tek seferde gerçekleştirebilirsiniz
  • Bir katman seçildiğinde, o katman ile önceki katmanların birleşiminden oluşan dosya ağacı gösterilir; eklenen·değiştirilen·silinen dosyaları ve kümülatif değişiklikleri dosya ağacı içinde görebilirsiniz
  • Deneysel image efficiency göstergesi, yinelenen dosyalar, katmanlar arası dosya taşıma ve tamamen kaldırılmamış dosyalardan kaynaklanan boşa harcanan alanı puan ve toplam boyut olarak tahmin eder
  • CI=true ile UI atlanabilir ve imaj verimliliği·boşa harcanan alan eşiklerine göre başarı/başarısızlık sonucu döndürülebilir; böylece CI pipeline'larında imaj boyutu yönetimi otomatikleştirilebilir

Dive ne yapar?

  • Dive, Docker imajlarını, katman içeriklerini ve Docker/OCI imaj boyutunu küçültmenin yollarını inceleyen bir araçtır
  • Temel kullanım, imaj etiketi·ID·digest vermektir
    • dive <your-image-tag>
  • Docker container olarak da çalıştırılabilir; bu durumda Docker socket'inin mount edilmesi gerekir
    • docker.io/wagoodman/dive imajı kullanılır
    • Örnek hedef imaj olarak nginx:latest verilmiştir
  • Bir imajı build ettikten hemen sonra analiz etmek için docker build yerine aynı biçimde dive build komutu kullanılabilir
    • dive build -t <some-tag> .
  • macOS'ta build analizini container olarak çalıştırma yöntemi yalnızca Docker container engine'i destekler
  • Proje durumu beta quality düzeyindedir; yeni özellik istekleri veya hatalar issue olarak bildirilebilir

Katmanları ve dosya değişikliklerini inceleme

  • Soldan bir katman seçildiğinde, sağda o katman ile önceki katmanların birleşiminden oluşan dosya ağacı gösterilir
  • Yön tuşlarıyla dosya ağacı içinde gezilebilir
  • Her katmandaki değişen dosya durumları dosya ağacında gösterilir
    • değişti
    • düzenlendi
    • eklendi
    • kaldırıldı
  • Değişiklik gösterimi, belirli bir katman temelinde veya o katmana kadar olan kümülatif değişiklikler temelinde ayarlanabilir

İmaj verimliliği ve boşa harcanan alan tahmini

  • Sol alt panel, temel katman bilgilerini ve deneysel image efficiency göstergesini gösterir
  • Bu gösterge, imaj içindeki boşa harcanan alanı tahmin eder
    • katmanlar arasında dosya yinelenmesi
    • katmanlar arasında dosya taşınması
    • tamamen kaldırılmamış dosyalar
  • Sonuç, yüzde score ve toplam boşa harcanan dosya alanı olarak sunulur

CI'da başarı/başarısızlık kriteri olarak kullanım

  • CI=true ortam değişkeniyle çalıştırıldığında Dive UI atlanır, imaj analiz edilir ve dönüş kodu olarak pass/fail sonucu verilir
  • Depo kökündeki .dive-ci dosyasıyla 3 kriter ayarlanabilir
    • lowestEfficiency: verimlilik belirtilen oranın altındaysa başarısız
    • highestWastedBytes: boşa harcanan alan belirtilen boyuta eşit ya da daha fazlaysa başarısız
    • highestUserWastedPercent: kullanıcı katmanlarına göre boşa harcanan oran belirtilen orana eşit ya da daha fazlaysa başarısız
  • highestUserWastedPercent hesabında base image layer, toplam imaj boyutuna dahil edilmez
  • CI yapılandırma dosyası yolu --ci-config seçeneğiyle geçersiz kılınabilir

İmaj kaynağı ve container engine

  • --source seçeneğiyle container imajının nereden alınacağı seçilebilir
    • dive <your-image> --source <source>
    • dive <source>://<your-image>
  • Desteklenen source seçenekleri şunlardır
    • docker: Docker engine, varsayılan
    • docker-archive: disk üzerindeki Docker Tar Archive
    • podman: Podman engine, yalnızca Linux desteklenir

Kurulum ve çalıştırma yöntemleri

  • Ubuntu/Debian sistemlerinde .deb paketi veya Snap ile kurulabilir
  • Snap yöntemi, Docker apt-get ile kurulduysa önerilmez; mevcut Docker daemon'unu bozabileceğine dair uyarı vardır
  • RHEL/Centos sistemlerinde .rpm paketiyle kurulabilir
  • Arch Linux'ta extra repository üzerinden sunulur ve pacman ile kurulabilir
  • macOS'ta Homebrew, MacPorts veya releases page üzerindeki Darwin build'i ile kurulabilir
  • Windows'ta Chocolatey, scoop, winget veya releases page üzerindeki Windows build'i ile kurulabilir
  • Go aracıyla kurulum için Go 1.10 veya üzeri gerekir
    • go install github.com/wagoodman/dive@latest
    • Bu yöntemle kurulduğunda dive -v çalıştırıldığında doğru sürüm gösterilmez
  • Nix/NixOS ve x-cmd kurulum yöntemleri de sunulmaktadır
  • Docker imajı olarak çalıştırırken Docker socket dosyasının eklenmesi gerekir
    • -v /var/run/docker.sock:/var/run/docker.sock
  • Yerel Docker sürümüne bağlı olarak DOCKER_API_VERSION=1.37 gibi ortam değişkenleri gerekebilir
  • Colima gibi alternatif runtime'lar kullanılıyorsa, yerel imajları almak için DOCKER_HOST ortam değişkeninin belirtilmesi gerekebilir

Kullanım ve UI ayarları

  • Başlıca tuş kısayolları, katman görünümü ile dosya ağacı görünümü arasında geçiş yaparak gezinme·filtreleme·gösterim geçişleri sağlar
    • Ctrl+C veya Q: çıkış
    • Tab: katman görünümü ile dosya ağacı görünümü arasında geçiş
    • Ctrl+F: dosya filtresi
    • Ctrl+A: katman görünümünde kümülatif imaj değişikliklerini gösterme, dosya ağacı görünümünde eklenen dosyaları gösterme geçişi
    • Ctrl+L: mevcut katman değişikliklerini gösterme
    • Ctrl+R, Ctrl+M, Ctrl+U: kaldırılan·düzenlenen·değişmeyen dosyaları gösterme geçişi
    • Ctrl+B: dosya özelliklerini gösterme geçişi
  • Ayrı bir yapılandırma zorunlu değildir, ancak YAML yapılandırma dosyasıyla değerler geçersiz kılınabilir
  • Yapılandırılabilen öğeler arasında container engine, imaj arşivi ayrıştırma hatalarını yok sayma, log, tuş atamaları, diff gösterimi, dosya ağacı genişliği, dizinlerin varsayılan kapalı durumu ve katman kümülatif değişiklik gösterimi yer alır
  • Yapılandırma dosyası arama konumları şunlardır
    • $XDG_CONFIG_HOME/dive/*.yaml
    • $XDG_CONFIG_DIRS/dive/*.yaml
    • ~/.config/dive/*.yaml
    • ~/.dive.yaml
  • .yaml yerine .yml uzantısı da kullanılabilir

1 yorum

 
GN⁺ 2024-01-09
Hacker News yorumları
  • İmajlar ve katmanlarla çalışırken crane harika; temel kütüphanesi go-containerregistry de iyi.
    Mevcut bir imaja yeni katman ekleyebilir veya metadata’yı (env vars, labels, entrypoint vb.) değiştirebilir; çok katmanlı imajları tek katmana “düzleştirebilir” de.
    Ayrıca değişiklikleri yeni bir base image üzerine yeniden uygulayan “rebase” işlemini de yapabiliyor; tüm bu işlemleri doğrudan registry üzerinde gerçekleştirdiği için Docker gerekmiyor.
    https://github.com/google/go-containerregistry/blob/main/cmd...

    • İyi öneri. Docker’dan farklı olarak crane root ve daemon olmadan çalışıyor; bu yüzden Nix’te kullanması iyi ve Nix deposunda da crane adıyla sunuluyor.
      Böylece Nix ile yalnızca build bağımlılıklarını (ör. Go) değil, paketleme ve dağıtım araçlarını da (ör. gnu tar, crane) birlikte yönetebiliyorsunuz.
    • Katman sayısı az olunca performans açısından bir avantaj olup olmadığını merak ediyorum. İmajları birleştirseniz de toplam boyut aynı kaldığı için, katman birleştirmenin kendi başına bir kazanç sağlamadığını anlıyorum.
  • dive, Docker imajlarının nasıl çalıştığını ve verimli bir Dockerfile’ın nasıl yazılacağını anlamamda gerçekten faydalı oldu.
    Dokümantasyon okumak önemli ama Dockerfile’ı değiştirdikten sonra ortaya çıkan katman yapısının nasıl değiştiğini doğrudan görmek, anlamam açısından belirleyiciydi.

  • Dive harika. Bu tür araçlar, tam olarak neyi build edip dağıttığımı öğrenmek ve bundan emin olmak için önemli.
    Dredge de bakmaya değer bir araç; katman farklarını karşılaştırırken kullanıyorum.
    https://github.com/mthalman/dredge/blob/main/docs/commands/i...

  • Aptalca bir soru olabilir ama çoğu container ve altyapı aracının neden Go ile yazıldığını merak ediyorum.
    Aklıma Docker, Podman, nerdctl, Terraform, Kubernetes geliyor; bu tür araçları yaparken Go’nun sunduğu belirgin bir avantaj olup olmadığını bilmek isterim.

    • Docker için cevap verebilirim. İlk prototip Python ile yazılmıştı ve şirket de Python ağırlıklıydı.
      Go ile yeniden yazılmasının ana nedeni, o dönemde (2012) yükselen Go popülerliğinin rüzgârından yararlanmaktı. Oradaydım.
    • Go, cross-compile ve dağıtımı en kolay dillerden biri; üretkenliğe kıyasla performansı çok iyi, yerleşik eşzamanlılığı iyi ve standart kütüphanesinin networking özellikleri de mükemmel.
      Docker ve Kubernetes’in başka popüler dillerle yazıldığını hayal edince fark ortaya çıkıyor.
    • Sistem araçları, yardımcı programlar, komut satırı araçları ve networking yazılımları, Go’nun en çok parladığı alanlar bence.
      Olgun ve modern alternatif olarak yalnızca Rust var gibi görünüyor.
    • Kubernetes’in Go ile yazılmasının nedeni, Google’ın Go’yu da Kubernetes’i de yapmış olması.
      İç ekiplerde çok sayıda Go mühendisi olmasının nedeni de aynı.
    • Container çalıştırırken alttaki sistemi mümkün olduğunca dert etmek istemezsiniz; Go, kendi küçük dünyasının içinde çalışmayı kolaylaştırıyor.
      Üstelik ekosistem etkisi de var: başka implementasyonların paketlerini kodunuzun bazı bölümlerinde doğrudan kullanabiliyorsunuz.
  • Dive’ı seviyorum ve ayda birkaç kez araç kutumdan çıkarıp kullanıyorum.
    Ancak seçilen dosyanın içeriğini doğrudan görmenin bir yolu olup olmadığını merak ediyorum. Bir katmanın içinde bir dosyanın varlığını doğruladıktan sonra çoğu zaman içeriğine bakmak istiyorum; şu an genellikle container’ı çalıştırıp cat kullanıyor ya da içeriği çıkarıp klasörün içine gidiyorum.

    • Biraz numarayla dosyaya rsync üzerinden erişmek mümkün ama cat kullanmaktan çok da farklı değil.
  • Birçok public Docker container’ını genişletirken, içeride ne yaptıklarını kurcalama sürecinde Dive birkaç kez hayatımı kurtardı.
    Gerçekten A+ seviyesinde bir yazılım.

  • dive gibi harika terminal TUI araçları daha var. Aklıma lazydocker ve dry geliyor.
    Docker kategorisinde de birkaç tane var.
    [0] https://terminaltrove.com/

    • Lazydocker’da da benzer ama daha basit bir özellik var.
      Kontrol ettim: katmanları görebiliyor ama yalnızca her katmanın komutunu gösteriyor.
  • Dive, container/Docker alanında muazzam bir araç. Container’ın içinde gerçekten ne olduğunu debug etmeyi çok daha kolaylaştırıyor.
    Depot [0]’ı ilk başlattığımızda, imaj boyutunu nasıl küçültebileceğimiz ve build’leri nasıl hızlandırabileceğimiz sıkça soruluyordu; ben de Dive ile bu sorunu nasıl çözeceğimizi kısa bir yazıda [1] özetledim. Şimdi biraz eskimiş olabilir ama birilerine faydalı olabilir.
    Dive’dan ilham alarak her build’de build context içinde gerçekte ne olduğunu daha kolay görünür hale getirdik ve birkaç hafta önce bunu Depot özelliği olarak yayınladık.
    [0] https://depot.dev
    [1] https://depot.dev/blog/reducing-image-size-with-dive
    [2] https://depot.dev/blog/build-context

  • Dive’ın çok faydalı olmasının dışında, yeterince takdir edilmeyen bir avantajı daha var: yazarı harika bir geliştirici ve birlikte çalışması gerçekten keyifli biri.

  • Google’ın container-diff adlı aracı da gerçekten kullanışlı.
    Bash’e pipe edilerek çalıştırılması önerilen rastgele bir script’in sistemde ne yapacağını kontrol etmek için kullanıyorum.

    • Genel container araçlarıyla biraz daha az ilişkili ama GoogleContainerTools/container-structure-test’i yoğun biçimde kullanıyorum.
      Container uygulamaları veya imajları üzerinde entegrasyon testleri çalıştırmak için pratik bir yol.
      Bu Google açık kaynak projelerinde, onları başlangıçta sürdüren kişilerin çoğu ayrıldığı için ilgiye ihtiyaç var gibi; bu üzücü. Mümkün olduğunda PR göndermeye ve ara sıra issue kapatmaya çalışıyorum. Özellikle bu test aracı, içeride sürdürmemiz gereken çok sayıda base image ile uğraşırken akıl sağlığımı korumak için çok değerli.