Docker इमेज और लेयर कंटेंट एक्सप्लोर करने का टूल 'Dive'

 (github.com/wagoodman)
10 पॉइंट द्वारा GN⁺ 2024-01-09 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Dive Docker/OCI इमेज की layers और file contents को एक्सप्लोर करने, और image size घटाने की गुंजाइश खोजने का टूल है
  • image tag, ID या digest के साथ dive <your-image-tag> चलाया जा सकता है, या dive build -t <some-tag>. से build के तुरंत बाद analysis भी एक साथ किया जा सकता है
  • layer चुनने पर यह उस layer और पिछली layers को मिलाकर बना file tree दिखाता है, और जोड़ी गई, बदली गई, हटाई गई files व cumulative changes को file tree में देखा जा सकता है
  • experimental image efficiency metric duplicate files, layers के बीच file moves, और पूरी तरह न हटाई गई files से बने wasted space का score और total size के रूप में अनुमान लगाता है
  • CI=true से UI skip करके image efficiency और wasted space criteria के आधार पर pass/fail लौटाया जा सकता है, जिससे CI pipeline में image size management automate किया जा सकता है

Dive क्या करता है

  • Dive Docker images, layer contents, और Docker/OCI image size घटाने के तरीके एक्सप्लोर करने का टूल है
  • basic execution में image tag, ID या digest पास किया जाता है
    • dive <your-image-tag>
  • इसे Docker container के रूप में भी चलाया जा सकता है; इस दौरान Docker socket mount करना होगा
    • docker.io/wagoodman/dive image इस्तेमाल करें
    • example target image के रूप में nginx:latest दिया गया है
  • image build करने के तुरंत बाद analysis करना हो तो docker build की जगह उसी format का dive build command इस्तेमाल किया जा सकता है
    • dive build -t <some-tag> .
  • macOS पर container के रूप में build analysis चलाने का तरीका केवल Docker container engine को support करता है
  • project status beta quality है, और नई feature requests या bugs issues के रूप में submit किए जा सकते हैं

Layers और file changes एक्सप्लोर करना

  • बाईं ओर layer चुनने पर दाईं ओर उस layer और previous layers को मिलाकर बना file tree दिखता है
  • arrow keys से file tree navigate किया जा सकता है
  • हर layer में बदली हुई file status file tree में दिखाई जाती है
    • बदला गया
    • modified
    • जोड़ा गया
    • हटाया गया
  • change display mode को किसी specific layer के आधार पर या उस layer तक के cumulative changes के आधार पर adjust किया जा सकता है

Image efficiency और wasted space का अनुमान

  • bottom-left panel basic layer information और experimental image efficiency metric दिखाता है
  • यह metric image के अंदर wasted space का अनुमान लगाता है
    • layers के बीच file duplication
    • layers के बीच file moves
    • पूरी तरह न हटाई गई files
  • results percentage score और total wasted file space के रूप में दिए जाते हैं

CI में pass/fail criteria के रूप में इस्तेमाल

  • CI=true environment variable के साथ चलाने पर Dive UI skip करता है, image analyze करता है, और return code से pass/fail result देता है
  • repository root की .dive-ci file से 3 criteria set किए जा सकते हैं
    • lowestEfficiency: efficiency specified percentage से कम हो तो fail
    • highestWastedBytes: wasted space specified size या उससे अधिक हो तो fail
    • highestUserWastedPercent: user layers के आधार पर wasted percentage specified percentage या उससे अधिक हो तो fail
  • highestUserWastedPercent calculation में base image layer total image size में शामिल नहीं होती
  • CI config file path को --ci-config option से override किया जा सकता है

Image source और container engine

  • --source option से container image लाने की location चुनी जा सकती है
    • dive <your-image> --source <source>
    • dive <source>://<your-image>
  • supported source options ये हैं
    • docker: Docker engine, default
    • docker-archive: disk पर Docker Tar Archive
    • podman: Podman engine, केवल Linux support

Installation और execution methods

  • Ubuntu/Debian में .deb package या Snap से install किया जा सकता है
  • Snap method तब recommended नहीं है जब Docker को apt-get से install किया गया हो; चेतावनी है कि इससे existing Docker daemon खराब हो सकता है
  • RHEL/Centos में .rpm package से install किया जा सकता है
  • Arch Linux में यह extra repository में उपलब्ध है और pacman से install किया जा सकता है
  • macOS में Homebrew, MacPorts, या releases page के Darwin build से install किया जा सकता है
  • Windows में Chocolatey, scoop, winget, या releases page के Windows build से install किया जा सकता है
  • Go tool से install करने के लिए Go 1.10 या उससे ऊपर चाहिए
    • go install github.com/wagoodman/dive@latest
    • इस method से install करने पर dive -v चलाते समय सही version दिखाई नहीं देता
  • Nix/NixOS और x-cmd installation methods भी उपलब्ध हैं
  • Docker image के रूप में चलाते समय Docker socket file शामिल करनी होगी
    • -v /var/run/docker.sock:/var/run/docker.sock
  • local Docker version के आधार पर DOCKER_API_VERSION=1.37 जैसा environment variable जरूरी हो सकता है
  • Colima जैसे alternative runtime का उपयोग करने पर local images लाने के लिए DOCKER_HOST environment variable set करना पड़ सकता है

Controls और UI settings

  • main key bindings layer view और file tree view के बीच जाकर navigation, filtering और display toggles perform करती हैं
    • Ctrl+C या Q: exit
    • Tab: layer view और file tree view switch
    • Ctrl+F: file filter
    • Ctrl+A: layer view में cumulative image changes view, file tree view में added files display toggle
    • Ctrl+L: current layer changes view
    • Ctrl+R, Ctrl+M, Ctrl+U: removed, modified और unchanged files display toggle
    • Ctrl+B: file attributes display toggle
  • अलग configuration जरूरी नहीं है, लेकिन YAML config file से values override की जा सकती हैं
  • configurable items में container engine, image archive parsing errors ignore करना या नहीं, logs, key bindings, diff display, file tree width, directories की default collapsed state, और layer cumulative change display शामिल हैं
  • config file search locations ये हैं
    • $XDG_CONFIG_HOME/dive/*.yaml
    • $XDG_CONFIG_DIRS/dive/*.yaml
    • ~/.config/dive/*.yaml
    • ~/.dive.yaml
  • .yaml के बजाय .yml extension भी इस्तेमाल किया जा सकता है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-01-09
Hacker News की राय

  • इमेज और लेयर के साथ काम करते समय crane शानदार है, और इसकी बेस लाइब्रेरी go-containerregistry भी अच्छी है
    यह मौजूदा इमेज में नई लेयर जोड़ सकता है या metadata (env vars, labels, entrypoint आदि) बदल सकता है, और कई लेयर वाली इमेज को एक ही लेयर में “flatten” भी कर सकता है
    बदलावों को नई base image पर फिर से लागू करने वाला “rebase” भी संभव है, और ये सारे काम सीधे registry में होते हैं, इसलिए Docker की जरूरत नहीं पड़ती
    https://github.com/google/go-containerregistry/blob/main/cmd...

    • अच्छी सिफारिश है। Docker के उलट crane root और daemon के बिना चलता है, इसलिए Nix में इस्तेमाल के लिए अच्छा है, और Nix repository में भी crane नाम से उपलब्ध है
      इसकी वजह से Nix के साथ build dependencies (जैसे Go) ही नहीं, packaging और deployment tools (जैसे gnu tar, crane) भी साथ में manage किए जा सकते हैं
    • सोच रहा/रही हूँ कि layer की संख्या कम होने पर performance का कोई फायदा होता है या नहीं। इमेज merge करने पर कुल size तो वही रहता है, इसलिए मेरी समझ में layer merge से अपने-आप कोई लाभ नहीं मिलता

  • dive यह समझने में वाकई उपयोगी रहा कि Docker image कैसे काम करती है और efficient Dockerfile कैसे लिखा जाता है
    documentation पढ़ना भी जरूरी है, लेकिन Dockerfile बदलने के बाद resulting layer structure कैसे बदलता है, यह खुद देखकर समझना निर्णायक रहा

  • Dive बेहतरीन है। ऐसे tools यह सीखने और भरोसा करने के लिए जरूरी हैं कि मैं असल में क्या build और deploy कर रहा/रही हूँ
    Dredge भी देखने लायक tool है, और layer differences compare करते समय इस्तेमाल करता/करती हूँ
    https://github.com/mthalman/dredge/blob/main/docs/commands/i...

    • वाकई अच्छा दिखता है। HN और Reddit की मदद से server room में पड़े संदिग्ध Raspberry Pi का पता लगा रहा/रही था कि वह क्या कर रहा है—तब ऐसे tool की जरूरत थी
      https://blog.haschek.at/2019/the-curious-case-of-the-RasPi-i...

  • यह बेवकूफी भरा सवाल हो सकता है, लेकिन उत्सुकता है कि ज्यादातर container और infrastructure tools Go में क्यों लिखे जाते हैं
    Docker, Podman, nerdctl, Terraform, Kubernetes याद आते हैं; जानना चाहता/चाहती हूँ कि ऐसे tools बनाते समय Go कोई साफ फायदा देता है क्या

    • Docker के बारे में जवाब दे सकता/सकती हूँ। पहला prototype Python में लिखा गया था, और कंपनी भी Python-केंद्रित थी
      Go में दोबारा लिखने की मुख्य वजह उस समय (2012) बढ़ती Go की लोकप्रियता की लहर पर सवार होना था। मैं वहाँ मौजूद था/थी
    • Go cross-compilation और deployment के लिए सबसे आसान language है, productivity के मुकाबले performance शानदार है, built-in concurrency अच्छी है, और standard library की networking capabilities भी बेहतरीन हैं
      अगर Docker और Kubernetes किसी दूसरी popular language में लिखे गए होते, तो फर्क साफ दिखता
    • मेरे हिसाब से system tools, utilities, command-line tools और networking software वे क्षेत्र हैं जहाँ Go सबसे ज्यादा चमकता है
      mature modern alternative के रूप में सिर्फ Rust ही दिखता है
    • Kubernetes Go में इसलिए लिखा गया क्योंकि Google ने Go बनाया और Kubernetes भी बनाया
      internal teams में Go engineers ज्यादा होने की वजह भी यही है
    • container चलाते समय आप underlying system की चिंता जितना हो सके कम करना चाहते हैं, और Go अपने छोटे-से अलग world में चलना आसान बनाता है
      ऊपर से ecosystem effect भी है, जिससे दूसरे implementations के packages को code के हिस्सों में सीधे इस्तेमाल किया जा सकता है

  • मुझे Dive पसंद है, और महीने में कई बार अपने toolbox से निकालकर इस्तेमाल करता/करती हूँ
    बस यह जानना है कि selected file की contents सीधे देखने का कोई तरीका है क्या। अक्सर layer के अंदर file मौजूद है या नहीं यह confirm करने के बाद उसकी contents देखना चाहता/चाहती हूँ, लेकिन अभी आम तौर पर container run करके cat इस्तेमाल करता/करती हूँ या contents extract करके folder में जाकर देखता/देखती हूँ

    • थोड़ी तरकीब से rsync के जरिए file तक पहुंचा जा सकता है, लेकिन यह cat इस्तेमाल करने से बहुत अलग नहीं है

  • कई public Docker containers को extend करते समय, अंदर क्या चल रहा है यह खंगालने की प्रक्रिया में Dive ने मुझे कई बार बचाया
    यह सचमुच A+ स्तर का software है

  • dive जैसे और भी बढ़िया terminal TUI tools हैं। lazydocker और dry याद आते हैं
    Docker category में भी कुछ हैं
    [0] https://terminaltrove.com/

    • Lazydocker में भी मिलता-जुलता लेकिन ज्यादा simple feature है
      check करने पर लगा कि layers देख सकते हैं, लेकिन यह हर layer की command ही दिखाता है

  • Dive container/Docker space में कमाल का tool है। इससे container के अंदर असल में क्या है, उसे debug करना काफी आसान हो जाता है
    जब Depot [0] शुरू किया था, तो image size घटाने और builds तेज करने के तरीके पर अक्सर सवाल मिलते थे, इसलिए Dive से उस समस्या को कैसे हल करें इस पर एक छोटी post [1] लिखी थी। अब शायद थोड़ी पुरानी हो, लेकिन किसी के काम आ सकती है
    Dive से प्रेरित होकर हमने हर build में build context के अंदर असल में क्या है, यह भी आसानी से दिखाना शुरू किया, और कुछ हफ्ते पहले इसे Depot feature के रूप में release किया
    [0] https://depot.dev
    [1] https://depot.dev/blog/reducing-image-size-with-dive
    [2] https://depot.dev/blog/build-context

  • Dive के बेहद उपयोगी होने के अलावा एक underestimated फायदा भी है। इसके author बेहतरीन developer हैं और उनके साथ काम करना वाकई सुखद है

  • Google का container-diff नाम का tool भी बहुत उपयोगी है
    bash में pipe करके चलाने की सलाह दिए गए arbitrary scripts system पर क्या करेंगे, यह देखने के लिए इसका इस्तेमाल करता/करती हूँ

    • सामान्य container utilities से थोड़ा कम संबंधित है, लेकिन मैं GoogleContainerTools/container-structure-test का खूब इस्तेमाल करता/करती हूँ
      container apps या images पर integration tests चलाने का यह सुविधाजनक तरीका है
      अफसोस है कि ऐसे Google open source projects को मूल maintainers में से कई लोगों के चले जाने के बाद शायद देखभाल की जरूरत है। जब संभव हो PR भेजने और कभी-कभी issues बंद करने की कोशिश करता/करती हूँ। खासकर यह testing tool अंदर maintain करनी पड़ने वाली बहुत-सी base images से निपटते समय मानसिक संतुलन बनाए रखने के लिए बेहद कीमती है