डॉकर छवि "परतें" क्या हैं?

Question

मैं डॉकर के लिए बिल्कुल नया हूं और यह समझने की कोशिश कर रहा हूं कि डॉक की छवि क्या है। डॉकर छवि की हर एक परिभाषा में "परत" शब्द का उपयोग किया गया है, लेकिन यह परिभाषित नहीं करता है कि परत से क्या मतलब है ।

आधिकारिक डॉकर डॉक्स से :

हम पहले ही देख चुके हैं कि डॉकर छवियां केवल-पढ़ने के लिए टेम्प्लेट हैं, जिसमें से डोकर कंटेनर लॉन्च किए जाते हैं। प्रत्येक छवि में परतों की एक श्रृंखला होती है। डॉकर इन परतों को एक ही छवि में मिलाने के लिए यूनियन फाइल सिस्टम का उपयोग करता है। यूनियन फाइल सिस्टम, अलग-अलग फाइल सिस्टम की फाइलों और निर्देशिकाओं को अनुमति देता है, जिन्हें शाखाओं के रूप में जाना जाता है, एक सुसंगत फाइल सिस्टम बनाने के लिए पारदर्शी रूप से ओवरलैड किया जाता है।

तो मैं पूछता हूं, एक परत क्या है (बिल्कुल); क्या कोई उनमें से कुछ ठोस उदाहरण दे सकता है? और एक छवि बनाने के लिए ये परतें "एक साथ कैसे स्नैप करें"?

Answer 1

मुझे देर हो सकती है, लेकिन यहाँ मेरे 10 सेंट हैं (ashishjain के उत्तर को पूरक करते हुए):

मूल रूप से, एक परत, या छवि परत एक छवि, या एक मध्यवर्ती छवि पर एक बदलाव है । हर आदेश आपके द्वारा निर्दिष्ट ( FROM, RUN, COPY, आदि) अपने Dockerfile में, परिवर्तन के लिए पिछले छवि का कारण बनता है इस तरह एक नई परत बनाने। आप इसे परिवर्तन के रूप में सोच सकते हैं जब आप git का उपयोग कर रहे हैं: आप एक फ़ाइल का परिवर्तन जोड़ते हैं, फिर एक और, फिर एक और एक ...

निम्नलिखित Dockerfile पर विचार करें:

FROM rails:onbuild
ENV RAILS_ENV production
ENTRYPOINT ["bundle", "exec", "puma"]

सबसे पहले, हम एक प्रारंभिक छवि चुनते हैं: rails:onbuildजो बदले में कई परतें हैं । हम अपनी शुरुआती छवि के ऊपर एक और परत जोड़ते हैं, कमांड के RAILS_ENVसाथ पर्यावरण चर सेट करते हैं ENV। फिर, हम डॉकटर को चलाने के लिए कहते हैं bundle exec puma(जो रेल सर्वर को बूट करता है)। वह एक और परत है।

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

आप इसके बारे में और अधिक यहाँ पढ़ सकते हैं ।

Comments

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

— एडम

परतों की अवधारणा के पीछे का कारण बताने के लिए धन्यवाद जो अन्य उत्तरों से गायब है।

— सीता सोमगानी

@ डेविड, उपरोक्त उदाहरण में, कितनी परतें जोड़ी जाएंगी? 2? या 1?

— गौरव सिंगला

@GouravSingla यह होना चाहिए 2. बदलें ENV भी एक परिवर्तन है। ऐसा लगता है कि परत गिट की प्रतिबद्धता है।

— पोकरफेस्ट

अंतिम वेबलिंक ( https://labs.ctl.io/caching-docker-images/) टूट गया है। किसी को बदलने के लिए सुझाव मिले?

— जॉनी यूटाह

Answer 2

एक dockerfile का उपयोग करके एक docker कंटेनर छवि बनाई जाती है । डॉकटराइल में हर लाइन एक परत बनाएगी । निम्नलिखित डमी उदाहरण पर विचार करें:

FROM ubuntu             #This has its own number of layers say "X"
MAINTAINER FOO          #This is one layer 
RUN mkdir /tmp/foo      #This is one layer 
RUN apt-get install vim #This is one layer 

यह एक अंतिम छवि बनाएगा जहां परतों की कुल संख्या X + 3 होगी

Comments

जब मैंने नीचे नहीं किया था, तो मेरा अनुमान यह होगा कि यह बताता है कि परतों को कैसे बनाया जाए , लेकिन किसी भी तरह से इस सवाल का जवाब नहीं देता है कि परत क्या है।

— लास वी। कार्लसन जूल 4'15

मैं @ LasseV.Karlsen, ashishjain से सहमत हूं। मैंने आपको निराश नहीं किया और वास्तव में आप मेरी (इतनी +1) मदद करने की कोशिश कर रहे हैं - लेकिन मेरे लिए आपको ग्रीन चेक देने में सक्षम होने के लिए, मुझे यह समझने की ज़रूरत है कि वास्तव में एक परत क्या है! धन्यवाद फिर से, जारी रखें!

— Smeeb

सबसे अच्छा जवाब imo। हम में से बहुत से लोग जो "docker का उपयोग" करते हैं, यह हमें यह बताता है कि परतें कैसे काम करती हैं।

— dtc

"डॉकटरफाइल में हर लाइन एक परत बनाएगी" - यह मेरे लिए जानना बहुत मददगार था

— akirekadu

@akirekadu वह पूरी कहानी नहीं है। अधिकांश लाइनें एक परत बनाएंगी, लेकिन केवल एडीडी, सीओपीवाई या आरयूएन निर्देश परतें बनाएंगे जो परिणामस्वरूप कंटेनर की छवि का आकार बढ़ाते हैं। मैंने अधिकांश पंक्तियों को कहा क्योंकि यदि आप एक साथ कमांड को चेन करते हैं, या बैकस्लैश के साथ नईलाइन्स से बचते हैं, जंजीर कमांड्स / एस्केपेड न्यूलाइन्स का क्रम एकल कमांड बनाएगा।

— स्कॉट सिमोंटिस

Answer 3

वे एक उदाहरण के साथ मेरे लिए सबसे अधिक समझ में आता है ...

डॉक के साथ अपने स्वयं के निर्माण की परतों की जांच करना अलग है

चलिए एक आकस्मिक उदाहरण लेते हैं Dockerfile:

FROM busybox

RUN mkdir /data
# imagine this is downloading source code
RUN dd if=/dev/zero bs=1024 count=1024 of=/data/one 
RUN chmod -R 0777 /data
# imagine this is compiling the app
RUN dd if=/dev/zero bs=1024 count=1024 of=/data/two 
RUN chmod -R 0777 /data
# and now this cleans up that downloaded source code
RUN rm /data/one 

CMD ls -alh /data

उनमें से प्रत्येक ddकमांड डिस्क में 1M फाइल को आउटपुट करता है। अस्थायी कंटेनर को बचाने के लिए एक अतिरिक्त ध्वज के साथ छवि का निर्माण करें:

docker image build --rm=false .

आउटपुट में, आप देखेंगे कि चल रहे कमांड्स में से प्रत्येक अस्थायी कंटेनर में होता है जिसे अब हम स्वचालित रूप से हटाने के बजाय रखते हैं:

...
Step 2/7 : RUN mkdir /data
 ---> Running in 04c5fa1360b0
 ---> 9b4368667b8c
Step 3/7 : RUN dd if=/dev/zero bs=1024 count=1024 of=/data/one
 ---> Running in f1b72db3bfaa
1024+0 records in
1024+0 records out
1048576 bytes (1.0MB) copied, 0.006002 seconds, 166.6MB/s
 ---> ea2506fc6e11

यदि आप docker diffउन कंटेनर आईडी में से प्रत्येक पर चलते हैं , तो आप देखेंगे कि उन कंटेनरों में क्या फाइलें बनाई गई थीं:

$ docker diff 04c5fa1360b0  # mkdir /data
A /data
$ docker diff f1b72db3bfaa  # dd if=/dev/zero bs=1024 count=1024 of=/data/one
C /data
A /data/one
$ docker diff 81c607555a7d  # chmod -R 0777 /data
C /data
C /data/one
$ docker diff 1bd249e1a47b  # dd if=/dev/zero bs=1024 count=1024 of=/data/two
C /data
A /data/two
$ docker diff 038bd2bc5aea  # chmod -R 0777 /data
C /data/one
C /data/two
$ docker diff 504c6e9b6637  # rm /data/one
C /data
D /data/one

एक Aफ़ाइल के साथ उपसर्ग की गई प्रत्येक पंक्ति फ़ाइल को जोड़ रही है, Cएक मौजूदा फ़ाइल में परिवर्तन को इंगित करती है, और Dएक डिलीट को इंगित करती है।

यहाँ TL, DR हिस्सा है

इनमें से प्रत्येक कंटेनर फाइलसिस्टम ऊपर भिन्न होता है, एक "परत" में जाता है जो कि एक कंटेनर के रूप में छवि को चलाने पर इकट्ठा हो जाता है। ऐड या चेंज होने पर पूरी फाइल प्रत्येक लेयर में होती है, इसलिए उनमें से प्रत्येक chmodकमांड केवल अनुमति बिट को बदलने के बावजूद पूरी फाइल को अगली लेयर में कॉपी किया जाता है। हटाए गए / डेटा / एक फ़ाइल अभी भी पिछली परतों में है, वास्तव में 3 बार, और नेटवर्क पर कॉपी की जाएगी और जब आप छवि को खींचते हैं तो डिस्क पर संग्रहीत होता है।

मौजूदा छवियों की जांच

आप docker historyकमांड के साथ मौजूदा छवि की परतों को बनाने में जाने वाले कमांड देख सकते हैं । आप docker image inspectएक छवि पर भी चला सकते हैं और रूटएफएस अनुभाग के तहत परतों की सूची देख सकते हैं।

यहाँ उपरोक्त छवि के लिए इतिहास है:

IMAGE               CREATED             CREATED BY                                      SIZE                COMMENT
a81cfb93008c        4 seconds ago       /bin/sh -c #(nop)  CMD ["/bin/sh" "-c" "ls -…   0B
f36265598aef        5 seconds ago       /bin/sh -c rm /data/one                         0B
c79aff033b1c        7 seconds ago       /bin/sh -c chmod -R 0777 /data                  2.1MB
b821dfe9ea38        10 seconds ago      /bin/sh -c dd if=/dev/zero bs=1024 count=102…   1.05MB
a5602b8e8c69        13 seconds ago      /bin/sh -c chmod -R 0777 /data                  1.05MB
08ec3c707b11        15 seconds ago      /bin/sh -c dd if=/dev/zero bs=1024 count=102…   1.05MB
ed27832cb6c7        18 seconds ago      /bin/sh -c mkdir /data                          0B
22c2dd5ee85d        2 weeks ago         /bin/sh -c #(nop)  CMD ["sh"]                   0B
<missing>           2 weeks ago         /bin/sh -c #(nop) ADD file:2a4c44bdcb743a52f…   1.16MB

नवीनतम परतें शीर्ष पर सूचीबद्ध हैं। ध्यान दें, नीचे दो परतें हैं जो काफी पुरानी हैं। वे बिजीबॉक्स इमेज से ही आते हैं। जब आप एक छवि बनाते हैं, तो आप FROMपंक्ति में निर्दिष्ट छवि की सभी परतों को प्राप्त करते हैं । CMDलाइन की तरह छवि मेटा-डेटा में बदलाव के लिए भी परतें जोड़ी जा रही हैं । वे मुश्किल से किसी भी स्थान को लेते हैं और रिकॉर्ड के लिए अधिक होते हैं जो आपके द्वारा चलाए जा रहे चित्र पर लागू होते हैं।

क्यों परतें?

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

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

परत ब्लोट को कम करना

परतों के नीचे एक ऐसी छवियां बन रही हैं, जो फ़ाइलों या शिप फ़ाइलों की नकल करती हैं, जिन्हें बाद की परत में हटा दिया जाता है। समाधान अक्सर एक कमांड में कई कमांड को मर्ज करने के लिए होता है RUN। विशेष रूप से जब आप मौजूदा फ़ाइलों को संशोधित कर रहे हैं या फ़ाइलों को हटा रहे हैं, तो आप उन चरणों को उसी कमांड में चलाना चाहते हैं जहां वे पहली बार बनाए गए थे। उपरोक्त डॉकरीफाइल का पुनर्लेखन इस तरह दिखेगा:

FROM busybox

RUN mkdir /data \
 && dd if=/dev/zero bs=1024 count=1024 of=/data/one \
 && chmod -R 0777 /data \
 && dd if=/dev/zero bs=1024 count=1024 of=/data/two \
 && chmod -R 0777 /data \
 && rm /data/one

CMD ls -alh /data

और यदि आप परिणामी छवियों की तुलना करते हैं:

• बिजीबॉक्स: ~ 1 एमबी
• पहली छवि: ~ 6 एमबी
• दूसरी छवि: ~ 2 एमबी

बस एक साथ कुछ पंक्तियों को मर्ज किए गए उदाहरण में मिलाते हुए, हमें अपनी छवि में समान परिणामी सामग्री मिली, और हमारी छवि को 5MB से सिकोड़कर केवल 1MB फ़ाइल है जो आप अंतिम छवि में देखते हैं।

Comments

फ़ाइल रीड्स के दौरान परतों को ट्रैवर्स करना कुछ ओवरहेड, सही पर जोर देता है? उस ओवरहेड को बचाने के लिए, क्या यह एक RUN में कई कमांड (जो किसी भी तरह से एक साथ निष्पादित किए जाने की आवश्यकता है) को संयोजित करने के लिए समझ में आता है?

— सर्जियोकोलनिकोव

@SergiyKolesnikov इस बात पर निर्भर करता है कि आप समय से पहले अनुकूलन के लिए कितना समय बिताना चाहते हैं। जोखिम, डेवलपर समय के घंटे खर्च कर रहा है, अतिरिक्त बैंडविड्थ और भंडारण के gigs, रनटाइम के मिलीसेकंड को बचाने के लिए। जैसा कि कई चीजों के प्रदर्शन से संबंधित है, चरम सीमाएं हैं, और इसे ठीक करने में प्रयास करने से पहले मुद्दे को मापने की आवश्यकता है।

— बीएमसी

Answer 4

डॉकर v1.10 के बाद से, सामग्री पता योग्य भंडारण की शुरूआत के साथ, 'परत' की धारणा काफी अलग हो गई। परतों में छवि की कोई धारणा नहीं है या किसी छवि से संबंधित नहीं है, वे केवल फाइलों और निर्देशिकाओं के संग्रह बन जाते हैं जिन्हें छवियों के बीच साझा किया जा सकता है। परतें और चित्र अलग हो गए।

उदाहरण के लिए, एक आधार छवि से एक स्थानीय रूप से निर्मित छवि पर, मान लें, ubuntu:14.04, docker historyआदेश छवि श्रृंखला पैदावार, लेकिन छवि आईडी की कुछ 'के रूप में याद आ रही' क्योंकि निर्माण इतिहास नहीं रह गया है भरी हुई है दिखाया जाएगा। और इन छवियों को बनाने वाली परतें इसके माध्यम से मिल सकती हैं

docker inspect <image_id> | jq -r '.[].RootFS'

यदि लेयर /var/lib/docker/aufs/diffड्राइवर का चयन होता है तो लेयर कंटेंट को स्टोर किया जाता है aufs। लेकिन परतों को बेतरतीब ढंग से उत्पन्न कैश आईडी के साथ नाम दिया गया है, ऐसा लगता है कि एक परत के बीच की कड़ी है और इसकी कैश आईडी केवल सुरक्षा कारणों से डॉक इंजन के लिए जानी जाती है। मैं अभी भी इसका पता लगाने के लिए रास्ता ढूंढ रहा हूं

1. एक छवि और इसकी रचना परत (ओं) के बीच संबंधित संबंध
2. डिस्क पर एक परत का वास्तविक स्थान और आकार

इस ब्लॉग ने बहुत अंतर्दृष्टि प्रदान की।

Comments

इस SO प्रविष्टि में मैंने अपने द्वारा पोस्ट किए गए दो प्रश्नों के उत्तर देने के बजाय एक भोली तरीका पोस्ट किया।

— रुइफेंग मा

Answer 5

मोबी प्रोजेक्ट के माध्यम से प्रति डॉकर की छवि युक्ति :

छवियाँ परतों से बनी होती हैं। प्रत्येक परत फाइलसिस्टम परिवर्तनों का एक समूह है। परतों में कॉन्फ़िगरेशन मेटाडेटा जैसे कि पर्यावरण चर या डिफ़ॉल्ट तर्क नहीं हैं - ये किसी विशेष परत के बजाय छवि के गुण हैं।

इसलिए, अनिवार्य रूप से, एक परत फाइलसिस्टम में किए गए परिवर्तनों का एक सेट है।

Comments

इसे खोजने में मुझे केवल एक-दो घंटे लगे, लेकिन इस सहज-सरल उत्तर के साथ, आखिरकार मुझे समझ में आ गया कि एक परत क्या है: "Each [Docker] layer is a set of filesystem changes."(यह सच है कि मान लें।) किसी कारण से मैं कई अन्य डॉक्स पढ़ने के दौरान इस मूलभूत बिंदु को नहीं समझ पाया / ब्लॉग्स / क्यू + ए / के आदि, और मुझे संदेह है कि सीमा उनकी थी और मेरी नहीं। भले ही, ब्रावो आदित्य मामले के दिल में उतरने के लिए।

— जॉनी उटाह

Answer 6

मुझे लगता है कि आधिकारिक दस्तावेज एक विस्तृत विवरण देता है: https://docs.docker.com/engine/userguide/storagedriver/imagesandcontainers/ ।

_{(स्रोत: docker.com )}

एक छवि में कई परतें होती हैं, जो आमतौर पर डॉकरफाइल से उत्पन्न होती हैं, डॉकरफाइल में प्रत्येक पंक्ति एक नई परत बनाएगी, और परिणाम एक छवि है, जिसे प्रपत्र द्वारा दर्शाया जाता है repo:tag, जैसे ubuntu:15.04।

अधिक जानकारी के लिए, कृपया ऊपर दिए गए आधिकारिक डॉक्स को पढ़ने पर विचार करें।

Answer 7

उपयोगी जानकारी के लिए @David Castillo धन्यवाद । मुझे लगता है कि परत एक छवि के कुछ द्विआधारी परिवर्तन या निर्देश है जो आसानी से किया जा सकता है या आसानी से पूर्ववत किया जा सकता है। उन्हें चरण दर चरण किया जाता है जो एक परत पर एक परत के समान होता है, इसलिए हम "परत" कहते हैं।

अधिक जानकारी के लिए आप "docker history" को इस तरह देख सकते हैं:

डॉकटर चित्र --tree
चेतावनी: '--tree' को हटा दिया गया है, इसे जल्द ही हटा दिया जाएगा। उपयोग देखें।
└─511136ea3c5a आभासी आकार: 0 बी टैग: खरोंच: नवीनतम
  └─59e359cb35ef वर्चुअल आकार: 85.18 एमबी
    └─e8d37d9e3476 आभासी आकार: 85.18 एमबी टैग: डेबियन: wheezy
      └─c58b36b8f285 वर्चुअल आकार: 85.18 एमबी
        └─90ea6e05b074 वर्चुअल आकार: 118.6 एमबी
          └─5dc74cffc471 वर्चुअल साइज़: 118.6 एमबी टैग: vim: latest

Comments

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

— हिप्रोज़

Answer 8

मेरी व्यक्तिगत समझ यह है कि हम docker layer की तुलना github कमिट से कर सकते हैं। आपकी आधार छवि (आपके ताज़ा मास्टर रेपो) के लिए, आप कई कमिट करते हैं, हर कमिट आपके मास्टर स्टेटस को बदल रहा है, यह डॉकटर में भी ऐसा ही है, हर लेयर पिछली मध्यवर्ती परत के आधार पर कुछ ऑपरेशन कर रहा है। और फिर, यह परत अगली परत के लिए एक नई मध्यवर्ती परत बन जाती है।

Answer 9

मुझे लगता है कि करने के लिए वे तरह हैं इस्तेमाल किया डिफ पिछले परतों पर। यहाँ कुछ उत्तर पढ़ने के बाद मुझे इतना यकीन नहीं था; उन्हें फ़ाइल सिस्टम में परिवर्तन के सेट के रूप में वर्णित किया गया है । मैंने यह दिखाने के लिए कुछ डॉकफाइल्स लिखी हैं कि वे डिफरेंशियल की तरह हैं, यानी वे वास्तव में पिछली परतों पर निर्भर हैं।

इन दो डॉकफाइल्स को देखते हुए

FROM bash
RUN mkdir /data
RUN dd if=/dev/zero bs=1024 count=1024 of=/data/one
RUN dd if=/dev/zero bs=1024 count=1024 of=/data/two
RUN dd if=/dev/zero bs=1024 count=1024 of=/data/three

तथा

FROM bash
RUN mkdir /data
RUN dd if=/dev/zero bs=1024 count=1024 of=/data/three
RUN dd if=/dev/zero bs=1024 count=1024 of=/data/two
RUN dd if=/dev/zero bs=1024 count=1024 of=/data/one

परतों के एक ही सेट की उम्मीद होगी अगर वे सिर्फ फाइल सिस्टम में बदलाव के बारे में थे, लेकिन यह मामला नहीं है:

$ docker history img_1
IMAGE               CREATED             CREATED BY                                      SIZE
30daa166a9c5        6 minutes ago       /bin/sh -c dd if=/dev/zero bs=1024 count=102…   1.05MB
4467d16e79f5        6 minutes ago       /bin/sh -c dd if=/dev/zero bs=1024 count=102…   1.05MB
c299561fd031        6 minutes ago       /bin/sh -c dd if=/dev/zero bs=1024 count=102…   1.05MB
646feb178431        6 minutes ago       /bin/sh -c mkdir /data                          0B
78664daf24f4        2 weeks ago         /bin/sh -c #(nop)  CMD ["bash"]                 0B
<missing>           2 weeks ago         /bin/sh -c #(nop)  ENTRYPOINT ["docker-entry…   0B
<more missing...>

तथा

$ docker history img_2
IMAGE               CREATED             CREATED BY                                      SIZE
f55c91305f8c        6 minutes ago       /bin/sh -c dd if=/dev/zero bs=1024 count=102…   1.05MB
29b3b627c76f        6 minutes ago       /bin/sh -c dd if=/dev/zero bs=1024 count=102…   1.05MB
18360be603aa        6 minutes ago       /bin/sh -c dd if=/dev/zero bs=1024 count=102…   1.05MB
646feb178431        6 minutes ago       /bin/sh -c mkdir /data                          0B
78664daf24f4        2 weeks ago         /bin/sh -c #(nop)  CMD ["bash"]                 0B
<missing>           2 weeks ago         /bin/sh -c #(nop)  ENTRYPOINT ["docker-entry…   0B
<more missing...>

आप देख सकते हैं कि कैसे, भले ही फाइल सिस्टम में बदलाव दोनों मामलों में समान हो, ऑर्डर मायने रखता है।