स्प्रिंग बूट एप्लिकेशन के लिए अनुकूलित डॉकर छवियां बनाना

कंटेनर किसी एप्लिकेशन को उसके सभी सॉफ़्टवेयर और ऑपरेटिंग सिस्टम निर्भरताओं के साथ पैकेजिंग करने और फिर उन्हें विभिन्न वातावरणों में वितरित करने का पसंदीदा साधन बन गए हैं।

यह आलेख स्प्रिंग बूट एप्लिकेशन को कंटेनरीकृत करने के विभिन्न तरीकों को शामिल करता है:

• डॉकर फ़ाइल का उपयोग करके डॉकर छवि बनाना,
• क्लाउड-नेटिव बिल्डपैक का उपयोग करके स्रोत से OCI छवि बनाना,
• और स्तरित टूल का उपयोग करके JAR भागों को विभिन्न स्तरों में अलग करके रनटाइम पर छवि अनुकूलन।

 कोड उदाहरण

यह आलेख एक कार्यशील कोड उदाहरण के साथ है गीथहब पर .

कंटेनर शब्दावली

हम पूरे लेख में प्रयुक्त कंटेनर शब्दावली से शुरुआत करेंगे:

• कंटेनर छवि: एक विशिष्ट प्रारूप की फ़ाइल। हम बिल्ड टूल चलाकर अपने एप्लिकेशन को एक कंटेनर छवि में परिवर्तित करते हैं।
• कंटेनर: कंटेनर छवि का एक निष्पादन योग्य उदाहरण।
• कंटेनर इंजन: कंटेनर चलाने के लिए जिम्मेदार डेमॉन प्रक्रिया।
• कंटेनर होस्ट: होस्ट मशीन जिस पर कंटेनर इंजन चल रहा है।
• कंटेनर रजिस्ट्री: कंटेनर छवि को प्रकाशित और वितरित करने के लिए उपयोग किया जाने वाला सामान्य स्थान।
• ओसीआई मानक: ओपन कंटेनर इनिशिएटिव (ओसीआई) लिनक्स फाउंडेशन द्वारा गठित एक हल्का, ओपन-सोर्स प्रबंधन ढांचा है। ओसीआई छवि विशिष्टता कंटेनर छवि प्रारूपों और रनटाइम के लिए उद्योग मानकों को परिभाषित करती है ताकि यह सुनिश्चित किया जा सके कि सभी कंटेनर इंजन किसी भी बिल्ड टूल द्वारा बनाई गई कंटेनर छवियों को चला सकें।

किसी एप्लिकेशन को कंटेनरीकृत करने के लिए, हम अपने एप्लिकेशन को एक कंटेनर छवि में लपेटते हैं और उस छवि को सार्वजनिक रजिस्ट्री में प्रकाशित करते हैं। कंटेनर रनटाइम इस छवि को रजिस्ट्री से पुनर्प्राप्त करता है, इसे अनपैक करता है, और इसके अंदर एप्लिकेशन चलाता है।

स्प्रिंग बूट का संस्करण 2.3 ओसीआई छवियों के निर्माण के लिए प्लगइन्स प्रदान करता है।

डाक में काम करनेवाला मज़दूर सबसे अधिक इस्तेमाल किया जाने वाला कंटेनर कार्यान्वयन है, और हम अपने उदाहरणों में डॉकर का उपयोग करते हैं, इसलिए इस आलेख में सभी बाद के कंटेनर संदर्भ डॉकर को संदर्भित करेंगे।

पारंपरिक तरीके से एक कंटेनर छवि का निर्माण

अपने डॉकरफ़ाइल में कुछ निर्देश जोड़कर स्प्रिंग बूट अनुप्रयोगों के लिए डॉकर छवियां बनाना बहुत आसान है।

हम पहले एक निष्पादन योग्य JAR फ़ाइल बनाते हैं और, डॉकर फ़ाइल निर्देशों के भाग के रूप में, आवश्यक सेटिंग्स लागू करने के बाद निष्पादन योग्य JAR फ़ाइल को आधार JRE छवि के शीर्ष पर कॉपी करते हैं।

आइए अपना स्प्रिंग एप्लिकेशन बनाएं स्प्रिंग इनिशियलाइज़र निर्भरता के साथ web, lombokи actuator. हम एपीआई प्रदान करने के लिए एक रेस्ट कंट्रोलर भी जोड़ रहे हैं GETतरीका।

डॉकरफ़ाइल बनाना

फिर हम इस एप्लिकेशन को जोड़कर एक कंटेनर में रख देते हैं Dockerfile:

FROM adoptopenjdk:11-jre-hotspot
ARG JAR_FILE=target/*.jar
COPY ${JAR_FILE} application.jar
EXPOSE 8080
ENTRYPOINT ["java","-jar","/application.jar"]

हमारी डॉकर फ़ाइल में एक आधार छवि शामिल है adoptopenjdk, जिसके शीर्ष पर हम अपनी JAR फ़ाइल को कॉपी करते हैं और फिर पोर्ट खोलते हैं, 8080जो अनुरोधों को सुनेगा।

एप्लिकेशन का निर्माण

सबसे पहले आपको मेवेन या ग्रैडल का उपयोग करके एक एप्लिकेशन बनाना होगा। यहां हम मेवेन का उपयोग करते हैं:

mvn clean package

यह एप्लिकेशन के लिए एक निष्पादन योग्य JAR फ़ाइल बनाता है। हमें डॉकर इंजन पर चलने के लिए इस निष्पादन योग्य JAR को डॉकर छवि में बदलने की आवश्यकता है।

एक कंटेनर छवि बनाना

फिर हम कमांड चलाकर इस JAR निष्पादन योग्य को डॉकर छवि में डालते हैं docker buildप्रोजेक्ट रूट निर्देशिका से जिसमें पहले बनाई गई Dockerfile शामिल है:

docker build  -t usersignup:v1 .

हम कमांड के साथ सूची में अपनी छवि देख सकते हैं:

docker images 

उपरोक्त कमांड के आउटपुट में हमारी छवि शामिल है usersignupआधार छवि के साथ, adoptopenjdkहमारी डॉकर फ़ाइल में निर्दिष्ट।

REPOSITORY          TAG                 SIZE
usersignup          v1                  249MB
adoptopenjdk        11-jre-hotspot      229MB

एक कंटेनर छवि के अंदर परतें देखें

आइए छवि के अंदर परतों के ढेर को देखें। हम इस्तेमाल करेंगे साधन  गोता लगाना, इन परतों को देखने के लिए:

dive usersignup:v1

यहां डाइव कमांड के आउटपुट का हिस्सा है: 

जैसा कि हम देख सकते हैं, एप्लिकेशन परत छवि आकार का एक महत्वपूर्ण हिस्सा बनाती है। हम अपने अनुकूलन के भाग के रूप में निम्नलिखित अनुभागों में इस परत के आकार को कम करना चाहते हैं।

बिल्डपैक के साथ एक कंटेनर छवि बनाना

असेंबली पैकेज (बिल्डपैक) एक सामान्य शब्द है जिसका उपयोग स्रोत कोड से एक कंटेनर छवि बनाने के लिए सेवा के रूप में विभिन्न प्लेटफ़ॉर्म (पीएएएस) द्वारा उपयोग किया जाता है। इसे 2011 में हेरोकू द्वारा लॉन्च किया गया था और तब से इसे क्लाउड फाउंड्री, गूगल ऐप इंजन, गिटलैब, नेटिव और कुछ अन्य लोगों द्वारा अपनाया गया है।

क्लाउड बिल्ड पैकेज का लाभ

छवियाँ बनाने के लिए बिल्डपैक का उपयोग करने का एक मुख्य लाभ यह है छवि कॉन्फ़िगरेशन परिवर्तनों को केंद्रीय रूप से (बिल्डर) प्रबंधित किया जा सकता है और बिल्डर का उपयोग करके सभी अनुप्रयोगों में प्रचारित किया जा सकता है।

बिल्ड पैकेजों को प्लेटफ़ॉर्म से मजबूती से जोड़ा गया था। क्लाउड-नेटिव बिल्डपैक ओसीआई छवि प्रारूप का समर्थन करके सभी प्लेटफार्मों पर मानकीकरण प्रदान करता है, जो यह सुनिश्चित करता है कि छवि को डॉकर इंजन द्वारा चलाया जा सकता है।

स्प्रिंग बूट प्लगइन का उपयोग करना

स्प्रिंग बूट प्लगइन बिल्डपैक का उपयोग करके स्रोत से ओसीआई छवियां बनाता है। का उपयोग करके छवियाँ बनाई जाती हैं bootBuildImageकार्य (ग्रैडल) या spring-boot:build-imageलक्ष्य (मावेन) और स्थानीय डॉकर स्थापना।

हम नाम निर्दिष्ट करके उस छवि के नाम को अनुकूलित कर सकते हैं जिसे हमें डॉकर रजिस्ट्री में धकेलना है image tag:

<plugin>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-maven-plugin</artifactId>
  <configuration>
    <image>
      <name>docker.io/pratikdas/${project.artifactId}:v1</name>
    </image>
  </configuration>
</plugin>

आइए इसे करने के लिए मावेन का उपयोग करें build-imageएक एप्लिकेशन बनाने और एक कंटेनर छवि बनाने के लक्ष्य। हम वर्तमान में किसी भी Dockerfiles का उपयोग नहीं कर रहे हैं।

mvn spring-boot:build-image

नतीजा कुछ ऐसा होगा:

[INFO] --- spring-boot-maven-plugin:2.3.3.RELEASE:build-image (default-cli) @ usersignup ---
[INFO] Building image 'docker.io/pratikdas/usersignup:v1'
[INFO] 
[INFO]  > Pulling builder image 'gcr.io/paketo-buildpacks/builder:base-platform-api-0.3' 0%
.
.
.. [creator]     Adding label 'org.springframework.boot.version'
.. [creator]     *** Images (c311fe74ec73):
.. [creator]           docker.io/pratikdas/usersignup:v1
[INFO] 
[INFO] Successfully built image 'docker.io/pratikdas/usersignup:v1'

आउटपुट से हम यह देखते हैं paketo Cloud-Native buildpackएक कार्यशील OCI छवि बनाने के लिए उपयोग किया जाता है। पहले की तरह, हम कमांड चलाकर डॉकर छवि के रूप में सूचीबद्ध छवि को देख सकते हैं:

docker images 

निष्कर्ष:

REPOSITORY                             SIZE
paketobuildpacks/run                  84.3MB
gcr.io/paketo-buildpacks/builder      652MB
pratikdas/usersignup                  257MB

जिब का उपयोग करके एक कंटेनर छवि बनाना

जिब Google का एक छवि निर्माण प्लगइन है जो स्रोत कोड से एक कंटेनर छवि बनाने के लिए एक वैकल्पिक विधि प्रदान करता है।

की स्थापना jib-maven-pluginpom.xml में:

      <plugin>
        <groupId>com.google.cloud.tools</groupId>
        <artifactId>jib-maven-plugin</artifactId>
        <version>2.5.2</version>
      </plugin>

इसके बाद, हम एप्लिकेशन बनाने और कंटेनर छवि बनाने के लिए मावेन कमांड का उपयोग करके जिब प्लगइन चलाते हैं। पहले की तरह, हम यहां किसी डॉकरफाइल्स का उपयोग नहीं कर रहे हैं:

mvn compile jib:build -Dimage=<docker registry name>/usersignup:v1

उपरोक्त मावेन कमांड को निष्पादित करने के बाद, हमें निम्नलिखित आउटपुट मिलता है:

[INFO] Containerizing application to pratikdas/usersignup:v1...
.
.
[INFO] Container entrypoint set to [java, -cp, /app/resources:/app/classes:/app/libs/*, io.pratik.users.UsersignupApplication]
[INFO] 
[INFO] Built and pushed image as pratikdas/usersignup:v1
[INFO] Executing tasks:
[INFO] [==============================] 100.0% complete

आउटपुट दिखाता है कि कंटेनर छवि बनाई गई है और रजिस्ट्री में रखी गई है।

अनुकूलित छवियाँ बनाने के लिए प्रेरणाएँ और विधियाँ

अनुकूलन के लिए हमारे पास दो मुख्य कारण हैं:

• निष्पादन: एक कंटेनर ऑर्केस्ट्रेशन सिस्टम में, एक कंटेनर छवि को छवि रजिस्ट्री से कंटेनर इंजन चलाने वाले होस्ट तक खींच लिया जाता है। इस प्रक्रिया को नियोजन कहते हैं। रजिस्ट्री से बड़ी छवियों को खींचने से कंटेनर ऑर्केस्ट्रेशन सिस्टम में लंबे समय तक शेड्यूलिंग समय और सीआई पाइपलाइनों में लंबे समय तक निर्माण होता है।
• सुरक्षा: बड़ी छवियों में कमजोरियों के लिए एक बड़ा क्षेत्र भी होता है।

एक डॉकर छवि परतों के ढेर से बनी होती है, प्रत्येक परत हमारे डॉकरफ़ाइल में एक कथन का प्रतिनिधित्व करती है। प्रत्येक परत अंतर्निहित परत में परिवर्तनों के डेल्टा का प्रतिनिधित्व करती है। जब हम रजिस्ट्री से डॉकर छवि खींचते हैं, तो इसे परतों में खींचा जाता है और होस्ट पर कैश किया जाता है।

स्प्रिंग बूट का उपयोग करता है "मोटा जार" में डिफ़ॉल्ट पैकेजिंग प्रारूप के रूप में। जब हम एक मोटे JAR को देखते हैं, तो हम देखते हैं कि एप्लिकेशन पूरे JAR का एक बहुत छोटा सा हिस्सा है। यही वह हिस्सा है जो सबसे ज्यादा बदलता है. बाकी में स्प्रिंग फ्रेमवर्क निर्भरताएँ शामिल हैं।

अनुकूलन फॉर्मूला स्प्रिंग फ्रेमवर्क निर्भरताओं से एक अलग स्तर पर एप्लिकेशन को अलग करने पर केंद्रित है।

निर्भरता परत जो मोटी JAR फ़ाइल का बड़ा हिस्सा बनाती है, केवल एक बार डाउनलोड की जाती है और होस्ट सिस्टम पर कैश की जाती है।

ऐप अपडेट और कंटेनर शेड्यूलिंग के दौरान ऐप की केवल एक पतली परत खींची जाती है, जैसा कि इस चित्र में दिखाया गया है:

निम्नलिखित अनुभागों में, हम देखेंगे कि स्प्रिंग बूट एप्लिकेशन के लिए इन अनुकूलित छवियों को कैसे बनाया जाए।

बिल्डपैक का उपयोग करके स्प्रिंग बूट एप्लिकेशन के लिए एक अनुकूलित कंटेनर छवि बनाना

स्प्रिंग बूट 2.3 एक मोटी JAR फ़ाइल के हिस्सों को अलग-अलग परतों में निकालकर लेयरिंग का समर्थन करता है। लेयरिंग सुविधा डिफ़ॉल्ट रूप से अक्षम है और इसे स्प्रिंग बूट मावेन प्लगइन का उपयोग करके स्पष्ट रूप से सक्षम करने की आवश्यकता है:

<plugin>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-maven-plugin</artifactId>
  <configuration>
    <layers>
      <enabled>true</enabled>
    </layers>
  </configuration> 
</plugin>

हम इस कॉन्फ़िगरेशन का उपयोग पहले बिल्डपैक के साथ और फिर निम्नलिखित अनुभागों में डॉकर के साथ अपनी कंटेनर छवि बनाने के लिए करेंगे।

आइए लॉन्च करें build-imageकंटेनर छवि बनाने के लिए मावेन लक्ष्य:

mvn spring-boot:build-image

यदि हम परिणामी छवि में परतों को देखने के लिए डाइव चलाते हैं, तो हम देख सकते हैं कि मोटे JAR प्रारूप का उपयोग करके हमें जो मिला, उसकी तुलना में एप्लिकेशन परत (लाल रंग में घिरा हुआ) किलोबाइट रेंज में बहुत छोटी है:

डॉकर के साथ स्प्रिंग बूट एप्लिकेशन के लिए एक अनुकूलित कंटेनर छवि बनाना

मावेन या ग्रैडल प्लगइन का उपयोग करने के बजाय, हम डॉकर फ़ाइल के साथ एक स्तरित डॉकर JAR छवि भी बना सकते हैं।

जब हम डॉकर का उपयोग करते हैं, तो हमें परतों को निकालने और उन्हें अंतिम छवि में कॉपी करने के लिए दो अतिरिक्त चरण करने की आवश्यकता होती है।

लेयरिंग सक्षम के साथ मेवेन का उपयोग करके निर्माण के बाद परिणामी JAR की सामग्री इस तरह दिखेगी:

META-INF/
.
BOOT-INF/lib/
.
BOOT-INF/lib/spring-boot-jarmode-layertools-2.3.3.RELEASE.jar
BOOT-INF/classpath.idx
BOOT-INF/layers.idx

आउटपुट नाम का एक अतिरिक्त JAR दिखाता है spring-boot-jarmode-layertoolsи layersfle.idxफ़ाइल। यह अतिरिक्त JAR फ़ाइल लेयरिंग क्षमताएं प्रदान करती है, जैसा कि अगले भाग में वर्णित है।

व्यक्तिगत परतों पर निर्भरता निकालना

हमारे स्तरित JAR से परतें देखने और निकालने के लिए, हम सिस्टम प्रॉपर्टी का उपयोग करते हैं -Djarmode=layertoolsचलाने के लिए spring-boot-jarmode-layertoolsएप्लिकेशन के बजाय JAR:

java -Djarmode=layertools -jar target/usersignup-0.0.1-SNAPSHOT.jar

इस कमांड को चलाने से उपलब्ध कमांड विकल्पों वाला एक आउटपुट उत्पन्न होता है:

Usage:
  java -Djarmode=layertools -jar usersignup-0.0.1-SNAPSHOT.jar

Available commands:
  list     List layers from the jar that can be extracted
  extract  Extracts layers from the jar for image creation
  help     Help about any command

आउटपुट कमांड दिखाता है list, extractи helpс helpडिफ़ॉल्ट हो. चलिए कमांड चलाते हैं listविकल्प:

java -Djarmode=layertools -jar target/usersignup-0.0.1-SNAPSHOT.jar list

dependencies
spring-boot-loader
snapshot-dependencies
application

हम निर्भरताओं की एक सूची देखते हैं जिन्हें परतों के रूप में जोड़ा जा सकता है।

डिफ़ॉल्ट परतें:

परत का नाम

सामग्री

dependencies

कोई भी निर्भरता जिसके संस्करण में स्नैपशॉट शामिल नहीं है

spring-boot-loader

जार लोडर क्लासेस

snapshot-dependencies

कोई भी निर्भरता जिसके संस्करण में स्नैपशॉट शामिल है

application

अनुप्रयोग वर्ग और संसाधन

परतों को परिभाषित किया गया है layers.idxफ़ाइल को उस क्रम में रखें जिसमें उन्हें डॉकर छवि में जोड़ा जाना चाहिए। ये परतें पहली बार लाने के बाद होस्ट पर कैश हो जाती हैं क्योंकि वे बदलती नहीं हैं। होस्ट पर केवल अद्यतन एप्लिकेशन परत डाउनलोड की जाती है, जो कम आकार के कारण तेज़ है .

अलग-अलग परतों में निकाली गई निर्भरताओं के साथ एक छवि बनाना

हम नामक विधि का उपयोग करके अंतिम छवि दो चरणों में बनाएंगे मल्टी-स्टेज असेंबली . पहले चरण में हम निर्भरताएँ निकालेंगे और दूसरे चरण में हम निकाली गई निर्भरताएँ अंतिम छवि में कॉपी करेंगे।

आइए मल्टी-स्टेज बिल्ड के लिए अपनी Dockerfile को संशोधित करें:

# the first stage of our build will extract the layers
FROM adoptopenjdk:14-jre-hotspot as builder
WORKDIR application
ARG JAR_FILE=target/*.jar
COPY ${JAR_FILE} application.jar
RUN java -Djarmode=layertools -jar application.jar extract

# the second stage of our build will copy the extracted layers
FROM adoptopenjdk:14-jre-hotspot
WORKDIR application
COPY --from=builder application/dependencies/ ./
COPY --from=builder application/spring-boot-loader/ ./
COPY --from=builder application/snapshot-dependencies/ ./
COPY --from=builder application/application/ ./
ENTRYPOINT ["java", "org.springframework.boot.loader.JarLauncher"]

हम इस कॉन्फ़िगरेशन को एक अलग फ़ाइल में सहेजते हैं - Dockerfile2.

हम कमांड का उपयोग करके डॉकर छवि बनाते हैं:

docker build -f Dockerfile2 -t usersignup:v1 .

इस कमांड को निष्पादित करने के बाद, हमें निम्नलिखित आउटपुट मिलता है:

Sending build context to Docker daemon  20.41MB
Step 1/12 : FROM adoptopenjdk:14-jre-hotspot as builder
14-jre-hotspot: Pulling from library/adoptopenjdk
.
.
Successfully built a9ebf6970841
Successfully tagged userssignup:v1

हम देख सकते हैं कि डॉकर छवि एक छवि आईडी के साथ बनाई गई है और फिर टैग की गई है।

अंत में, हम उत्पन्न डॉकर छवि के अंदर परतों का निरीक्षण करने के लिए पहले की तरह डाइव कमांड चलाते हैं। हम डाइव कमांड में इनपुट के रूप में एक छवि आईडी या टैग प्रदान कर सकते हैं:

dive userssignup:v1

जैसा कि आप आउटपुट से देख सकते हैं, एप्लिकेशन वाली परत अब केवल 11 KB है और निर्भरताएं अलग-अलग परतों में कैश की गई हैं। 

व्यक्तिगत परतों पर आंतरिक निर्भरताएँ निकालना

हम अपनी किसी भी कस्टम निर्भरता को एक अलग परत में निकालकर एप्लिकेशन परत के आकार को और कम कर सकते हैं बजाय उन्हें एप्लिकेशन के साथ घोषित करके पैक करने के। ymlसमान फ़ाइल नाम layers.idx:

- "dependencies":
  - "BOOT-INF/lib/"
- "spring-boot-loader":
  - "org/"
- "snapshot-dependencies":
- "custom-dependencies":
  - "io/myorg/"
- "application":
  - "BOOT-INF/classes/"
  - "BOOT-INF/classpath.idx"
  - "BOOT-INF/layers.idx"
  - "META-INF/"

इस फ़ाइल में layers.idxहमने नाम से एक कस्टम निर्भरता जोड़ी है, io.myorgजिसमें साझा भंडार से पुनर्प्राप्त संगठन निर्भरताएँ शामिल हैं।

उत्पादन

इस लेख में, हमने स्रोत से सीधे कंटेनर छवि बनाने के लिए क्लाउड-नेटिव बिल्डपैक का उपयोग करने पर ध्यान दिया। यह सामान्य तरीके से कंटेनर छवि बनाने के लिए डॉकर का उपयोग करने का एक विकल्प है: पहले, एक मोटी निष्पादन योग्य JAR फ़ाइल बनाई जाती है और फिर डॉकरफ़ाइल में निर्देशों को निर्दिष्ट करके एक कंटेनर छवि में पैक किया जाता है।

हमने एक लेयरिंग सुविधा को शामिल करके अपने कंटेनर को अनुकूलित करने पर भी ध्यान दिया, जो होस्ट पर कैश की गई अलग-अलग परतों में निर्भरता को निकालता है और कंटेनर के निष्पादन इंजन में शेड्यूलिंग समय पर एक पतली एप्लिकेशन परत लोड की जाती है।

आप आलेख में प्रयुक्त सभी स्रोत कोड यहां पा सकते हैं Github .

आदेश संदर्भ

इस आलेख में हमारे द्वारा उपयोग किए गए आदेशों का एक त्वरित विवरण यहां दिया गया है।

प्रसंग समाशोधन:

docker system prune -a

Dockerfile के साथ एक कंटेनर छवि बनाना:

docker build -f <Docker file name> -t <tag> .

स्रोत से कंटेनर छवि बनाएं (डॉकरफ़ाइल के बिना):

mvn spring-boot:build-image

निर्भरता परतें देखें. एप्लिकेशन जार फ़ाइल बनाने से पहले, सुनिश्चित करें कि स्प्रिंग-बूट-मेवेन-प्लगइन में लेयरिंग सुविधा सक्षम है:

java -Djarmode=layertools -jar application.jar list

निर्भरता परतें निकालना. एप्लिकेशन JAR फ़ाइल बनाने से पहले, सुनिश्चित करें कि लेयरिंग सुविधा स्प्रिंग-बूट-मेवेन-प्लगइन में सक्षम है:

 java -Djarmode=layertools -jar application.jar extract

कंटेनर छवियों की सूची देखना

docker images

कंटेनर छवि के अंदर बाईं ओर देखें (सुनिश्चित करें कि डाइव टूल स्थापित है):

dive <image ID or image tag>

स्रोत: www.habr.com