Docker
Dockerfiles
खोज…
परिचय
Dockerfiles ऐसी फाइलें हैं जिनका उपयोग प्रोग्रामर को Docker इमेज बनाने के लिए किया जाता है। वे आपको जल्दी और प्रतिलिपि प्रस्तुत करने के लिए डॉकटर छवि बनाने की अनुमति देते हैं, और इसलिए सहयोग करने के लिए उपयोगी होते हैं। Dockerfiles में Docker छवि बनाने के लिए निर्देश होते हैं। प्रत्येक निर्देश को एक पंक्ति पर लिखा जाता है, और उसे फॉर्म <INSTRUCTION><argument(s)>
। docker build
कमांड का उपयोग कर डॉकरीफाइल्स का उपयोग डोकर इमेज बनाने के लिए किया जाता है।
टिप्पणियों
Dockerfiles फार्म के हैं:
# This is a comment
INSTRUCTION arguments
- टिप्पणियाँ
#
शुरू होती हैं - निर्देश केवल ऊपरी मामला है
- बेस इमेज को निर्दिष्ट करने के लिए डॉकरफाइल का पहला निर्देश
FROM
होना चाहिए
डॉकरफाइल का निर्माण करते समय, डॉकर क्लाइंट डोकर डेमॉन को "बिल्ड संदर्भ" भेजेगा। निर्माण संदर्भ में Dockerfile के समान निर्देशिका में सभी फ़ाइलें और फ़ोल्डर शामिल हैं। COPY
और ADD
ऑपरेशन केवल इस संदर्भ से फ़ाइलों का उपयोग कर सकते हैं।
कुछ Docker फाइल के साथ शुरू हो सकता है:
# escape=`
इस प्रयोग के लिए डोकर पार्सर निर्देश देने के लिए प्रयोग किया जाता है `
के बजाय एक भागने चरित्र के रूप में \
। यह ज्यादातर विंडोज डॉकर फाइलों के लिए उपयोगी है।
हैलोवर्ल्ड डॉकरफाइल
एक न्यूनतम डॉकफाइल इस तरह दिखता है:
FROM alpine
CMD ["echo", "Hello StackOverflow!"]
यह डॉकटर को अल्पाइन ( FROM
) के आधार पर एक छवि बनाने, कंटेनरों के लिए एक न्यूनतम वितरण और परिणामस्वरूप छवि निष्पादित करते समय एक विशिष्ट कमांड ( CMD
) चलाने का निर्देश देगा।
इसे बनाएं और चलाएं:
docker build -t hello .
docker run --rm hello
यह आउटपुट होगा:
Hello StackOverflow!
फ़ाइलों की प्रतिलिपि बनाना
डॉकर छवि में बिल्ड संदर्भ से फ़ाइलों की प्रतिलिपि बनाने के लिए, COPY
निर्देश का उपयोग करें:
COPY localfile.txt containerfile.txt
यदि फ़ाइल नाम में स्थान हैं, तो वैकल्पिक सिंटैक्स का उपयोग करें:
COPY ["local file", "container file"]
COPY
कमांड वाइल्डकार्ड का समर्थन करता है। यह उदाहरण के लिए images/
निर्देशिका के लिए सभी छवियों को कॉपी करने के लिए इस्तेमाल किया जा सकता है:
COPY *.jpg images/
नोट: इस उदाहरण में, images/
मौजूद नहीं हो सकते हैं। इस मामले में, डॉकर इसे स्वचालित रूप से बनाएगा।
एक बंदरगाह का प्रदर्शन
एक Dockerfile से अवगत कराया बंदरगाहों घोषित करने के लिए उपयोग करें EXPOSE
अनुदेश:
EXPOSE 8080 8082
एक्सपोज्ड पोर्ट सेटिंग को डॉकर कमांडलाइन से ओवरराइड किया जा सकता है, लेकिन डॉकरफाइल में उन्हें स्पष्ट रूप से सेट करना एक अच्छा अभ्यास है क्योंकि यह समझने में मदद करता है कि एप्लिकेशन क्या करता है।
Dockerfiles सबसे अच्छा pratices
समूह सामान्य ऑपरेशन
डॉकर परतों के संग्रह के रूप में छवियों का निर्माण करता है। प्रत्येक परत केवल डेटा जोड़ सकती है, भले ही यह डेटा कहता हो कि कोई फ़ाइल हटा दी गई है। हर निर्देश एक नई परत बनाता है। उदाहरण के लिए:
RUN apt-get -qq update
RUN apt-get -qq install some-package
नीचे की एक जोड़ी है:
- यह दो परतों का निर्माण करेगा, एक बड़ी छवि का निर्माण करेगा।
-
RUN
स्टेटमेंट में अकेलेapt-get update
का उपयोग करने से कैशिंग समस्याएँ उत्पन्न होती हैं और बाद मेंapt-get install
निर्देश विफल हो सकते हैं । मान लीजिए कि आपने बाद में अतिरिक्त पैकेज जोड़करapt-get install
संशोधित किया है, तो docker प्रारंभिक और संशोधित निर्देशों को समान के रूप में व्याख्या करता है और पिछले चरणों से कैश का पुन: उपयोग करता है। परिणामस्वरूपapt-get update
कमांड को निष्पादित नहीं किया जाता है क्योंकि इसका कैश्ड संस्करण बिल्ड के दौरान उपयोग किया जाता है।
इसके बजाय, उपयोग करें:
RUN apt-get -qq update && \
apt-get -qq install some-package
के रूप में यह केवल एक परत का उत्पादन।
अनुरक्षक का उल्लेख करें
यह आमतौर पर डॉकरफाइल की दूसरी पंक्ति है। यह बताता है कि प्रभारी कौन है और मदद करने में सक्षम होगा।
LABEL maintainer John Doe <[email protected]>
यदि आप इसे छोड़ देते हैं, तो यह आपकी छवि को नहीं तोड़ेगा। लेकिन यह आपके उपयोगकर्ताओं को भी मदद नहीं करेगा।
संक्षिप्त रखें
अपने डॉकरीफाइल को छोटा रखें। यदि एक जटिल सेटअप आवश्यक है, तो एक समर्पित स्क्रिप्ट का उपयोग करने या आधार छवियों को स्थापित करने पर विचार करें।
USER निर्देश
USER daemon
USER
निर्देश उपयोगकर्ता के नाम या UID को छवि को चलाने के लिए उपयोग करता है और किसी RUN
, CMD
और ENTRYPOINT
निर्देशों के लिए ENTRYPOINT
करता है जो इसे Dockerfile
में अनुसरण करते हैं।
कार्य निर्देश
WORKDIR /path/to/workdir
WORKDIR
निर्देश किसी भी RUN
, CMD
, ENTRYPOINT
, COPY
और ADD
निर्देशों के लिए कार्यशील निर्देशिका को सेट करता है, जो इसे Dockerfile में अनुसरण करते हैं। यदि WORKDIR
मौजूद नहीं है, तो इसे तब भी बनाया जाएगा, जब इसका उपयोग किसी भी बाद के Dockerfile
निर्देश में नहीं किया गया हो।
यह एक Dockerfile
में कई बार इस्तेमाल किया जा सकता है। यदि कोई सापेक्ष पथ प्रदान किया जाता है, तो यह पिछले WORKDIR
निर्देश के पथ के सापेक्ष होगा। उदाहरण के लिए:
WORKDIR /a
WORKDIR b
WORKDIR c
RUN pwd
इस Dockerfile
में अंतिम pwd
कमांड का आउटपुट /a/b/c
।
WORKDIR
अनुदेश हल कर सकते हैं वातावरण चर पहले से उपयोग कर सेट ENV
। आप केवल Dockerfile
में स्पष्ट रूप से सेट किए गए पर्यावरण चर का उपयोग कर सकते हैं। उदाहरण के लिए:
ENV DIRPATH /path
WORKDIR $DIRPATH/$DIRNAME
RUN pwd
इस Dockerfile में अंतिम pwd
कमांड का आउटपुट /path/$DIRNAME
वीओएलएमई अनुदेश
VOLUME ["/data"]
VOLUME
निर्देश निर्दिष्ट नाम के साथ एक माउंट पॉइंट बनाता है और इसे बाहरी होस्ट या अन्य कंटेनरों से बाहरी माउंट किए गए वॉल्यूम के रूप में चिह्नित करता है। मान JSON सरणी, VOLUME ["/var/log/"]
, या एकाधिक तर्कों के साथ एक सादे स्ट्रिंग, जैसे VOLUME /var/log
या VOLUME /var/log /var/db
। डॉकर क्लाइंट के माध्यम से अधिक जानकारी / उदाहरण और बढ़ते निर्देशों के लिए, वॉल्यूम डॉक्यूमेंटेशन के माध्यम से शेयर डिरेक्टरीज़ देखें।
docker run
कमांड किसी भी डेटा के साथ नए बनाए गए वॉल्यूम को आरंभ करता है जो आधार छवि के भीतर निर्दिष्ट स्थान पर मौजूद है। उदाहरण के लिए, निम्नलिखित डॉकरीफाइल स्निपेट पर विचार करें:
FROM ubuntu
RUN mkdir /myvol
RUN echo "hello world" > /myvol/greeting
VOLUME /myvol
इस डॉकरीफाइल के परिणामस्वरूप एक छवि बनती है, जो डॉक रन का कारण बनती है, / myvol पर एक नया आरोह बिंदु बनाने के लिए और नए बनाए गए वॉल्यूम में ग्रीटिंग फ़ाइल की प्रतिलिपि बनाएँ।
नोट: यदि कोई बिल्ड स्टेप्स घोषित किए जाने के बाद वॉल्यूम के भीतर डेटा को बदलता है, तो उन परिवर्तनों को छोड़ दिया जाएगा।
नोट: सूची को JSON सरणी के रूप में पार्स किया गया है, जिसका अर्थ है कि आपको दोहरे उद्धरण चिह्नों (") का उपयोग करना चाहिए, शब्दों के आसपास नहीं-उद्धरण (')।
कॉपी निर्देश
COPY
के दो रूप हैं:
COPY <src>... <dest>
COPY ["<src>",... "<dest>"] (this form is required for paths containing whitespace)
COPY
निर्देश नई फ़ाइलों या निर्देशिकाओं को <src>
से COPY
करता है और उन्हें पथ के फ़ाइल सिस्टम में जोड़ता है <dest>
।
एकाधिक <src>
संसाधन निर्दिष्ट किया जा सकता है, लेकिन वे उस स्रोत निर्देशिका के सापेक्ष होना चाहिए जिसे बनाया जा रहा है (बिल्ड का संदर्भ)।
प्रत्येक <src>
में वाइल्डकार्ड शामिल हो सकते हैं और मिलान गो के filepath.Match
का उपयोग करके किया जाएगा। उदाहरण के लिए:
COPY hom* /mydir/ # adds all files starting with "hom"
COPY hom?.txt /mydir/ # ? is replaced with any single character, e.g., "home.txt"
<dest>
एक पूर्ण पथ, या एक पथ है जो WORKDIR
सापेक्ष है, जिसमें स्रोत को गंतव्य कंटेनर के अंदर कॉपी किया जाएगा।
COPY test relativeDir/ # adds "test" to `WORKDIR`/relativeDir/
COPY test /absoluteDir/ # adds "test" to /absoluteDir/
सभी नई फाइलें और निर्देशिकाएं 0 के यूआईडी और जीआईडी के साथ बनाई गई हैं।
नोट: यदि आप स्टडिन ( docker build - < somefile
) का उपयोग कर निर्माण करते हैं, तो कोई बिल्ड संदर्भ नहीं है, इसलिए COPY
उपयोग नहीं किया जा सकता है।
COPY
निम्नलिखित नियमों का पालन करता है:
<src>
पथ निर्माण के संदर्भ में होना चाहिए; आपCOPY
../something / कुछ नहीं कर सकते, क्योंकि docker build का पहला चरण do निर्देशिका डेमन को संदर्भ निर्देशिका (और उपनिर्देशिका) भेजना है।यदि
<src>
एक निर्देशिका है, तो निर्देशिका की संपूर्ण सामग्री की प्रतिलिपि बनाई जाती है, जिसमें फाइल सिस्टम मेटाडेटा शामिल है। नोट: निर्देशिका स्वयं कॉपी नहीं है, बस इसकी सामग्री।यदि
<src>
किसी अन्य प्रकार की फ़ाइल है, तो इसकी मेटाडेटा के साथ व्यक्तिगत रूप से कॉपी की जाती है। इस स्थिति में, यदि<dest>
एक अनुगामी स्लैश / के साथ समाप्त होता है, तो इसे एक निर्देशिका माना जाएगा और<src>
की सामग्री को<dest>/base(<src>)
पर लिखा जाएगा।यदि एकाधिक
<src>
संसाधनों को निर्दिष्ट किया गया है, या तो सीधे या वाइल्डकार्ड के उपयोग के कारण है, तो<dest>
एक निर्देशिका होनी चाहिए, और इसे स्लैश/
साथ समाप्त होना चाहिए।यदि
<dest>
एक अनुगामी स्लैश के साथ समाप्त नहीं होता है, तो इसे एक नियमित फ़ाइल माना जाएगा और<src>
की सामग्री<dest>
पर लिखी जाएगी।यदि
<dest>
मौजूद नहीं है, तो यह अपने पथ में सभी गुम निर्देशिकाओं के साथ बनाया गया है।
ईएनवी और एआरजी निर्देश
ENV
ENV <key> <value>
ENV <key>=<value> ...
ENV
निर्देश पर्यावरण चर <key>
को मान पर सेट करता है। यह मान सभी "वंशज" डॉकरीफाइल कमांड के वातावरण में होगा और कई में इनलाइन को भी बदला जा सकता है।
ENV
निर्देश के दो रूप हैं। पहला रूप, ENV <key> <value>
, एक मान के लिए एक एकल चर सेट करेगा। पहले स्थान के बाद पूरे स्ट्रिंग को <value>
रूप में माना जाएगा - जिसमें रिक्त स्थान और उद्धरण जैसे वर्ण शामिल हैं।
दूसरा रूप, ENV <key>=<value> ...
, एक समय में कई चर सेट करने की अनुमति देता है। ध्यान दें कि दूसरा रूप वाक्य रचना में बराबर चिह्न (=) का उपयोग करता है, जबकि पहला रूप नहीं है। कमांड लाइन पार्सिंग की तरह, मानों के भीतर रिक्त स्थान शामिल करने के लिए उद्धरण और बैकस्लैश का उपयोग किया जा सकता है।
उदाहरण के लिए:
ENV myName="John Doe" myDog=Rex\ The\ Dog \
myCat=fluffy
तथा
ENV myName John Doe
ENV myDog Rex The Dog
ENV myCat fluffy
अंतिम कंटेनर में एक ही शुद्ध परिणाम प्राप्त होगा, लेकिन पहला रूप पसंद किया जाता है क्योंकि यह एकल कैश परत का उत्पादन करता है।
ENV
का उपयोग करके सेट किया गया पर्यावरण चर तब जारी रहेगा जब कंटेनर को परिणामी छवि से चलाया जाएगा। आप docker run --env <key>=<value>
निरीक्षण का उपयोग करके मान देख सकते हैं, और docker run --env <key>=<value>
का उपयोग करके उन्हें बदल सकते हैं।
ARG
यदि आप सेटिंग को जारी रखना नहीं चाहते हैं, तो इसके बजाय ARG
उपयोग करें। ARG
बिल्ड के दौरान ही वातावरण सेट करेगा। उदाहरण के लिए, सेटिंग
ENV DEBIAN_FRONTEND noninteractive
भ्रमित हो सकते हैं apt-get
एक डेबियन-आधारित छवि पर होता है, जिस एक इंटरैक्टिव संदर्भ के माध्यम से में कंटेनर में प्रवेश docker exec -it the-container bash
।
इसके बजाय, उपयोग करें:
ARG DEBIAN_FRONTEND noninteractive
आप वैकल्पिक रूप से केवल प्रयोग करके एकल कमांड के लिए एक मूल्य निर्धारित कर सकते हैं:
RUN <key>=<value> <command>
विशेषज्ञ निर्देश
EXPOSE <port> [<port>...]
EXPOSE
निर्देश डॉकर को सूचित करता है कि कंटेनर रनटाइम पर निर्दिष्ट नेटवर्क पोर्ट पर सुनता है। EXPOSE
होस्ट के लिए कंटेनर के बंदरगाहों को सुलभ नहीं बनाता है। ऐसा करने के लिए, आपको पोर्ट की एक श्रृंखला को प्रकाशित करने के लिए या -p
ध्वज का उपयोग करना चाहिए या -P
सभी पोर्ट को प्रकाशित करने के लिए-ध्वज का उपयोग करना चाहिए। ये ध्वज docker run [OPTIONS] IMAGE [COMMAND][ARG...]
में उपयोग किए जाते हैं docker run [OPTIONS] IMAGE [COMMAND][ARG...]
होस्ट को पोर्ट को उजागर करने के लिए। आप एक पोर्ट नंबर को उजागर कर सकते हैं और इसे दूसरे नंबर के तहत बाहरी रूप से प्रकाशित कर सकते हैं।
docker run -p 2500:80 <image name>
यह कमांड <image> नाम के साथ एक कंटेनर बनाएगा और कंटेनर के पोर्ट 80 को होस्ट मशीन के पोर्ट 2500 से बांध देगा।
होस्ट सिस्टम पर पोर्ट पुनर्निर्देशन स्थापित करने के लिए, -P
ध्वज का उपयोग करके देखें। डॉकर नेटवर्क सुविधा नेटवर्क के भीतर बंदरगाहों को उजागर करने की आवश्यकता के बिना नेटवर्क बनाने का समर्थन करती है, विस्तृत जानकारी के लिए इस सुविधा का अवलोकन देखें)।
लेबल निर्देश
LABEL <key>=<value> <key>=<value> <key>=<value> ...
LABEL
निर्देश एक छवि में मेटाडेटा जोड़ता है। एक LABEL
एक कुंजी-मूल्य जोड़ी है। किसी LABEL
मान के भीतर रिक्त स्थान शामिल करने के लिए, कमांड-लाइन पार्सिंग में उद्धरण और बैकस्लैश का उपयोग करें। कुछ उपयोग उदाहरण:
LABEL "com.example.vendor"="ACME Incorporated"
LABEL com.example.label-with-value="foo"
LABEL version="1.0"
LABEL description="This text illustrates \
that label-values can span multiple lines."
एक छवि में एक से अधिक लेबल हो सकते हैं। कई लेबल निर्दिष्ट करने के लिए, डॉकर लेबल को एक एकल LABEL
निर्देश में संयोजन करने की सलाह देता है जहां संभव हो। प्रत्येक LABEL
निर्देश एक नई परत का उत्पादन करता है जिसके परिणामस्वरूप यदि आप कई लेबल का उपयोग करते हैं तो एक अक्षम छवि हो सकती है। यह उदाहरण एकल छवि परत में परिणाम करता है।
LABEL multi.label1="value1" multi.label2="value2" other="value3"
ऊपर के रूप में भी लिखा जा सकता है:
LABEL multi.label1="value1" \
multi.label2="value2" \
other="value3"
लेबल छवियों FROM
LABEL
सहित LABEL
हैं। यदि डॉकटर एक लेबल / कुंजी का सामना करता है जो पहले से मौजूद है, तो नया मान समान कुंजियों के साथ किसी भी पिछले लेबल को ओवरराइड करता है।
छवि के लेबल देखने के लिए, docker निरीक्षण कमांड का उपयोग करें।
"Labels": {
"com.example.vendor": "ACME Incorporated"
"com.example.label-with-value": "foo",
"version": "1.0",
"description": "This text illustrates that label-values can span multiple lines.",
"multi.label1": "value1",
"multi.label2": "value2",
"other": "value3"
},
सीएमडी निर्देश
CMD
अनुदेश के तीन रूप हैं:
CMD ["executable","param1","param2"] (exec form, this is the preferred form)
CMD ["param1","param2"] (as default parameters to ENTRYPOINT)
CMD command param1 param2 (shell form)
Dockerfile
में केवल एक CMD
निर्देश हो सकता है। यदि आप एक से अधिक CMD
सूचीबद्ध करते हैं तो केवल अंतिम CMD
ही प्रभावी होगा।
एक CMD
का मुख्य उद्देश्य एक निष्पादित कंटेनर के लिए चूक प्रदान करना है। इन चूक में एक निष्पादन योग्य शामिल हो सकता है, या वे निष्पादन योग्य को छोड़ सकते हैं, जिस स्थिति में आपको एक ENTRYPOINT
निर्देश भी निर्दिष्ट करना होगा।
नोट: यदि CMD
का उपयोग ENTRYPOINT
निर्देश के लिए डिफ़ॉल्ट तर्क प्रदान करने के लिए किया जाता है, CMD
और ENTRYPOINT
निर्देश दोनों को JSON सरणी प्रारूप के साथ निर्दिष्ट किया जाना चाहिए।
नोट: निष्पादन फॉर्म को JSON सरणी के रूप में पार्स किया गया है, जिसका अर्थ है कि आपको दोहरे-उद्धरणों (") का उपयोग करना चाहिए, शब्दों के आसपास एकल-उद्धरण (') नहीं।
नोट: शेल फॉर्म के विपरीत, निष्पादन फॉर्म कमांड शेल को लागू नहीं करता है। इसका मतलब है कि सामान्य शेल प्रसंस्करण नहीं होता है। उदाहरण के लिए, CMD [ "echo", "$HOME" ]
$HOME
पर परिवर्तनीय प्रतिस्थापन नहीं करेंगे। यदि आप शेल प्रोसेसिंग चाहते हैं तो या तो शेल फॉर्म का उपयोग करें या किसी शेल को सीधे निष्पादित करें, उदाहरण के लिए: CMD [ "sh", "-c", "echo $HOME" ]
।
जब शेल या निष्पादन प्रारूप में उपयोग किया जाता है, तो CMD
निर्देश छवि को चलाते समय निष्पादित होने के लिए कमांड सेट करता है।
यदि आप CMD
के शेल फॉर्म का उपयोग करते हैं, तो कमांड /bin/sh -c
में निष्पादित होगी:
FROM ubuntu
CMD echo "This is a test." | wc -
यदि आप बिना शेल के अपना कमांड चलाना चाहते हैं तो आपको कमांड को JSON सरणी के रूप में व्यक्त करना चाहिए और निष्पादन योग्य को पूरा रास्ता देना चाहिए। यह सरणी प्रपत्र CMD
का पसंदीदा प्रारूप है। किसी भी अतिरिक्त पैरामीटर को व्यक्तिगत रूप से सरणी में स्ट्रिंग के रूप में व्यक्त किया जाना चाहिए:
FROM ubuntu
CMD ["/usr/bin/wc","--help"]
यदि आप चाहते हैं कि आपका कंटेनर हर बार समान निष्पादन योग्य हो, तो आपको CMD
साथ संयोजन में ENTRYPOINT
का उपयोग करने पर विचार करना चाहिए। ENTRYPOINT
देखें।
यदि उपयोगकर्ता docker चलाने के लिए तर्क निर्दिष्ट करता है तो वे CMD
में निर्दिष्ट डिफ़ॉल्ट को ओवरराइड कर देंगे।
नोट: RUN
को CMD
साथ भ्रमित न करें। RUN
वास्तव में छवि निर्माण समय पर एक कमांड चलाता है और परिणाम देता है; CMD
बिल्ड टाइम पर कुछ भी निष्पादित नहीं करता है, लेकिन छवि के लिए इच्छित कमांड को निर्दिष्ट करता है।
मुख्य अनुदेशक
MAINTAINER <name>
MAINTAINER
निर्देश आपको उत्पन्न छवियों के लेखक फ़ील्ड को सेट करने की अनुमति देता है।
MAINTAINER प्रत्यक्ष का उपयोग न करें
आधिकारिक डॉक्यूमेंट डॉक्यूमेंटेशन के अनुसार MAINTAINER
निर्देश को हटा दिया गया है। इसके बजाय, किसी को उत्पन्न छवियों के लेखक को परिभाषित करने के लिए LABEL
निर्देश का उपयोग करना चाहिए। LABEL
निर्देश अधिक लचीला है, मेटाडेटा सेट करने में सक्षम करता है, और आसानी से कमांड docker inspect
साथ देखा जा सकता है।
LABEL maintainer="[email protected]"
निर्देश से
FROM <image>
या
FROM <image>:<tag>
या
FROM <image>@<digest>
FROM
अनुदेश बाद के निर्देशों के लिए बेस इमेज सेट करता है। जैसे, एक वैध Dockerfile होना आवश्यक है FROM
अपनी पहली अनुदेश के रूप में। छवि किसी भी वैध छवि हो सकती है - सार्वजनिक रिपॉजिटरी से छवि खींचकर शुरू करना विशेष रूप से आसान है।
FROM
Dockerfile में पहली गैर टिप्पणी अनुदेश होना चाहिए।
कई छवियों को बनाने के लिए FROM
एक एकल Dockerfile के भीतर कई बार दिखाई दे सकता है। प्रत्येक नई FROM
कमांड FROM
पहले कमिट द्वारा अंतिम इमेज आईडी आउटपुट का एक नोट बनाएं।
टैग या डाइजेस्ट वैल्यू वैकल्पिक हैं। यदि आप दोनों में से किसी को छोड़ देते हैं, तो बिल्डर डिफ़ॉल्ट रूप से एक नवीनतम मान लेता है। यदि यह टैग मान से मेल नहीं खा सकता है, तो बिल्डर एक त्रुटि देता है।
रुन निर्देश
RUN
के 2 रूप हैं:
RUN <command> (shell form, the command is run in a shell, which by default is /bin/sh -c on Linux or cmd /S /C on Windows)
RUN ["executable", "param1", "param2"] (exec form)
RUN
निर्देश वर्तमान छवि के शीर्ष पर एक नई परत में किसी भी कमांड को निष्पादित करेगा और परिणाम देगा। परिणामी प्रतिबद्ध छवि का उपयोग Dockerfile
में अगले चरण के लिए किया Dockerfile
।
RUN
निर्देश रखना और कमिट करना, Docker की उन मुख्य अवधारणाओं के अनुरूप है जहाँ कमिट सस्ते होते हैं और किसी इमेज के इतिहास में किसी भी बिंदु से कंटेनर बनाए जा सकते हैं, जैसे कि सोर्स कंट्रोल।
निष्पादन प्रपत्र शेल स्ट्रिंग मुंगिंग से बचने के लिए संभव बनाता है, और RUN
को एक आधार छवि का उपयोग करके आदेश देता है जिसमें निर्दिष्ट शेल निष्पादन योग्य नहीं होता है।
शेल रूप के लिए डिफ़ॉल्ट शेल को SHELL
कमांड का उपयोग करके बदला जा सकता है।
खोल रूप में आप एक का उपयोग कर सकते \
एक भी जारी रखने के लिए (बैकस्लैश) RUN
अगली पंक्ति पर अनुदेश। उदाहरण के लिए, इन दो पंक्तियों पर विचार करें:
RUN /bin/bash -c 'source $HOME/.bashrc ;\
echo $HOME'
साथ में वे इस एकल पंक्ति के बराबर हैं:
RUN /bin/bash -c 'source $HOME/.bashrc ; echo $HOME'
नोट: 'शेल / बिन / श' के अलावा किसी अन्य शेल का उपयोग करने के लिए, वांछित शेल में पास होने वाले निष्पादन फॉर्म का उपयोग करें। उदाहरण के लिए, RUN ["/bin/bash", "-c", "echo hello"]
नोट: निष्पादन फॉर्म को JSON सरणी के रूप में पार्स किया गया है, जिसका अर्थ है कि आपको दोहरे-उद्धरणों ( “
) का उपयोग करना चाहिए, शब्दों के आसपास एकल-उद्धरण ( '
) नहीं।
नोट: शेल फॉर्म के विपरीत, निष्पादन फॉर्म कमांड शेल को लागू नहीं करता है। इसका मतलब है कि सामान्य शेल प्रसंस्करण नहीं होता है। उदाहरण के लिए, RUN [ "echo", "$HOME" ]
$HOME
पर परिवर्तनीय प्रतिस्थापन नहीं करेगा। यदि आप शेल प्रोसेसिंग चाहते हैं तो या तो शेल फॉर्म का उपयोग करें या किसी शेल को सीधे निष्पादित करें, उदाहरण के लिए: RUN [ "sh", "-c", "echo $HOME" ]
।
नोट: JSON फॉर्म में, बैकस्लैश से बचना आवश्यक है। यह विंडोज पर विशेष रूप से प्रासंगिक है जहां बैकस्लैश पथ विभाजक है। निम्न पंक्ति को अन्यथा JSON के मान्य नहीं होने के कारण शेल रूप माना जाएगा, और अनपेक्षित तरीके से विफल: RUN ["c:\windows\system32\tasklist.exe"]
इस उदाहरण के लिए सही सिंटैक्स है: RUN ["c:\\windows\\system32\\tasklist.exe"]
RUN
निर्देशों के लिए कैश अगले बिल्ड के दौरान स्वचालित रूप से अमान्य नहीं है। RUN apt-get dist-upgrade -y
जैसे निर्देश के लिए कैश अगले निर्माण के दौरान पुन: उपयोग किया जाएगा। RUN
निर्देशों के लिए कैश को -no-cache ध्वज का उपयोग करके अमान्य किया जा सकता है, उदाहरण के लिए docker build --no-cache।
अधिक जानकारी के लिए डॉकरफाइल बेस्ट प्रैक्टिस गाइड देखें।
RUN
निर्देशों के लिए कैश को ADD
निर्देशों द्वारा अमान्य किया जा सकता है। जानकारी के लिए नीचे देखें।
ONBUILD निर्देश
ONBUILD [INSTRUCTION]
ONBUILD
निर्देश छवि को एक ट्रिगर अनुदेश को बाद के समय में निष्पादित करने के लिए जोड़ता है, जब छवि को किसी अन्य बिल्ड के लिए आधार के रूप में उपयोग किया जाता है। ट्रिगर को डाउनस्ट्रीम बिल्ड के संदर्भ में निष्पादित किया जाएगा, जैसे कि डाउनस्ट्रीम डॉकरीफाइल में FROM
निर्देश के तुरंत बाद इसे डाला गया था।
किसी भी निर्माण निर्देश को ट्रिगर के रूप में पंजीकृत किया जा सकता है।
यह उपयोगी है यदि आप एक ऐसी छवि का निर्माण कर रहे हैं जिसका उपयोग अन्य छवियों के निर्माण के लिए एक आधार के रूप में किया जाएगा, उदाहरण के लिए एक एप्लिकेशन बिल्ड वातावरण या डेमॉन जो उपयोगकर्ता-विशिष्ट कॉन्फ़िगरेशन के साथ अनुकूलित किया जा सकता है।
उदाहरण के लिए, यदि आपकी छवि एक पुन: प्रयोज्य पायथन एप्लिकेशन बिल्डर है, तो उसे किसी विशेष निर्देशिका में एप्लिकेशन स्रोत कोड को जोड़ना होगा, और इसके बाद एक बिल्ड स्क्रिप्ट की आवश्यकता हो सकती है। आप अभी ADD
और RUN
कॉल नहीं कर सकते हैं, क्योंकि आपके पास अभी तक एप्लिकेशन स्रोत कोड तक पहुंच नहीं है, और यह प्रत्येक एप्लिकेशन बिल्ड के लिए अलग होगा। आप केवल एप्लिकेशन डेवलपर्स को उनके आवेदन में कॉपी-पेस्ट करने के लिए बॉयलरप्लेट डॉकरफाइल के साथ प्रदान कर सकते हैं, लेकिन यह अक्षम, त्रुटि-प्रवण और अपडेट करने में मुश्किल है क्योंकि यह एप्लिकेशन-विशिष्ट कोड के साथ मिश्रित होता है।
समाधान अगले निर्माण चरण के दौरान बाद में चलाने के लिए अग्रिम निर्देशों को पंजीकृत करने के लिए ONBUILD
का उपयोग ONBUILD
है।
यहां देखिए यह कैसे काम करता है:
जब यह एक ONBUILD
निर्देश का सामना करता है, तो बिल्डर छवि के मेटाडेटा के लिए एक ट्रिगर जोड़ता है। निर्देश अन्यथा वर्तमान बिल्ड को प्रभावित नहीं करता है।
बिल्ड के अंत में, सभी ऑनर्स की एक सूची को ऑन-बाइल की कुंजी ऑनबिल्ड के तहत इमेज मेनिफ़ेस्ट में संग्रहीत किया जाता है। उन्हें docker inspect
कमांड के साथ निरीक्षण किया जा सकता है। बाद में छवि को नए निर्माण के लिए आधार के रूप में, FROM
अनुदेश का उपयोग करके उपयोग किया जा सकता है। FROM
अनुदेश के प्रसंस्करण के हिस्से के रूप में, डाउनस्ट्रीम बिल्डर ONBUILD
ट्रिगर्स के लिए ONBUILD
है, और उन्हें उसी क्रम में निष्पादित करता है जिस क्रम में वे पंजीकृत थे। यदि कोई भी ट्रिगर विफल हो जाता है, तो FROM
अनुदेश निरस्त कर दिया जाता है, जिसके कारण बिल्ड विफल हो जाता है। यदि सभी ट्रिगर सफल हो जाते हैं, तो FROM
अनुदेश पूरा हो जाता है और बिल्ड हमेशा की तरह जारी रहता है।
निष्पादित होने के बाद अंतिम छवि से ट्रिगर साफ़ हो जाते हैं। दूसरे शब्दों में, उन्हें "भव्य-बच्चों" द्वारा विरासत में नहीं मिला है।
उदाहरण के लिए आप कुछ इस तरह से जोड़ सकते हैं:
[...]
ONBUILD ADD . /app/src
ONBUILD RUN /usr/local/bin/python-build --dir /app/src
[...]
चेतावनी: ONBUILD
ONBUILD
का उपयोग करते हुए ONBUILD
निर्देशों का पालन करने की अनुमति नहीं है।
चेतावनी: ONBUILD
अनुदेश सकता है नहीं ट्रिगर FROM
या MAINTAINER
निर्देश।
STOPSIGNAL निर्देश
STOPSIGNAL signal
STOPSIGNAL
निर्देश सिस्टम कॉल सिग्नल सेट करता है जिसे कंटेनर से बाहर निकलने के लिए भेजा जाएगा। यह संकेत एक मान्य अहस्ताक्षरित संख्या हो सकती है जो कर्नेल की syscall तालिका में स्थिति से मेल खाती है, उदाहरण के लिए 9, या SIGNAME प्रारूप में संकेत नाम, उदाहरण के लिए SIGKILL।
स्वास्थ्य देखभाल निर्देश
HEALTHCHECK
अनुदेश के दो रूप हैं:
HEALTHCHECK [OPTIONS] CMD command (check container health by running a command inside the container)
HEALTHCHECK NONE (disable any healthcheck inherited from the base image)
HEALTHCHECK
निर्देश डॉकर को बताता है कि कंटेनर की जांच कैसे की जाए कि वह अभी भी काम कर रहा है। यह ऐसे वेब सर्वर जैसे मामलों का पता लगा सकता है जो एक अनंत लूप में फंसे हुए हैं और नए कनेक्शन को संभालने में असमर्थ हैं, हालांकि सर्वर प्रक्रिया अभी भी चल रही है।
जब एक कंटेनर में एक स्वास्थ्य परीक्षण निर्दिष्ट होता है, तो इसकी सामान्य स्थिति के अलावा एक स्वास्थ्य स्थिति भी होती है। यह स्थिति शुरू में शुरू हो रही है। जब भी कोई स्वास्थ्य जांच पास करता है, तो यह स्वस्थ हो जाता है (जो भी राज्य पहले था)। एक निश्चित संख्या में लगातार विफलताओं के बाद, यह अस्वस्थ हो जाता है।
CMD
सामने आने वाले विकल्प हैं:
--interval=DURATION (default: 30s)
--timeout=DURATION (default: 30s)
--retries=N (default: 3)
कंटेनर की शुरुआत होने के बाद स्वास्थ्य जांच पहले अंतराल सेकंड चलाएगी, और फिर प्रत्येक पिछले जांच पूरी होने के बाद फिर से अंतराल सेकंड।
यदि चेक का एक भी रन टाइमआउट सेकंड से अधिक समय लेता है, तो चेक को विफल माना जाता है।
यह अस्वास्थ्यकर माने जाने वाले कंटेनर के लिए स्वास्थ्य जांच की लगातार विफलताओं को पीछे छोड़ता है।
सिर्फ एक ही हो सकता है HEALTHCHECK
एक में शिक्षा Dockerfile
। यदि आप एक से अधिक सूची देते हैं तो केवल अंतिम HEALTHCHECK
प्रभावी होगा।
CMD
कीवर्ड के बाद कमांड या तो शेल कमांड हो सकती है (जैसे HEALTHCHECK CMD /bin/check-running
) या एक एग्जीक्यूटिव सरणी (जैसा कि अन्य Dockerfile कमांड के साथ है; विवरण के लिए ENTRYPOINT
देखें)।
कमांड की निकास स्थिति कंटेनर की स्वास्थ्य स्थिति को इंगित करती है। संभावित मूल्य हैं:
-
0: success
- कंटेनर स्वस्थ है और उपयोग के लिए तैयार है -
1: unhealthy
- कंटेनर सही ढंग से काम नहीं कर रहा है -
2: starting
- कंटेनर अभी तक उपयोग के लिए तैयार नहीं है, लेकिन सही तरीके से काम कर रहा है
यदि जांच 2 ("शुरुआती") वापस आती है, जब कंटेनर पहले से ही "शुरुआती" स्थिति से बाहर निकल गया है, तो इसके बजाय इसे "अस्वास्थ्यकर" माना जाता है।
उदाहरण के लिए, प्रत्येक पाँच मिनट या इतने पर जाँच करने के लिए कि एक वेब-सर्वर तीन सेकंड के भीतर साइट के मुख्य पृष्ठ की सेवा करने में सक्षम हो:
HEALTHCHECK --interval=5m --timeout=3s \
CMD curl -f http://localhost/ || exit 1
डिबग फ़ेलिंग प्रोब की मदद करने के लिए, कोई भी आउटपुट टेक्स्ट (UTF-8 एनकोडेड) जो कमांड स्टैडआउट पर लिखता है या स्टॉडर को स्वास्थ्य की स्थिति में संग्रहीत किया जाएगा और docker inspect
साथ docker inspect
किया जा सकता है। ऐसे आउटपुट को छोटा रखा जाना चाहिए (केवल पहले 4096 बाइट्स वर्तमान में संग्रहीत हैं)।
जब एक कंटेनर की स्वास्थ्य स्थिति बदलती है, तो एक health_status
घटना नई स्थिति के साथ उत्पन्न होती है।
HEALTHCHECK
1.12 में HEALTHCHECK
फीचर जोड़ा गया था।
शेल निर्देश
SHELL ["executable", "parameters"]
SHELL
निर्देश कमांड के शेल फॉर्म के लिए उपयोग किए जाने वाले डिफ़ॉल्ट शेल को ओवरराइड करने की अनुमति देता है। लिनक्स पर डिफ़ॉल्ट शेल ["/bin/sh", "-c"]
, और विंडोज पर ["cmd", "/S", "/C"]
। SHELL
निर्देश को JSON फॉर्म में Dockerfile में लिखा जाना चाहिए।
SHELL
अनुदेश विशेष रूप से विंडोज पर उपयोगी है जहां दो सामान्य रूप से उपयोग किए जाते हैं और काफी अलग देशी गोले हैं: सीएमडी और पॉवरशेल, साथ ही साथ वैकल्पिक शेल भी उपलब्ध हैं।
SHELL
निर्देश कई बार दिखाई दे सकता है। प्रत्येक SHELL
अनुदेश सभी पिछले ओवरराइड करता है SHELL
निर्देश, और बाद में सभी निर्देशों को प्रभावित करता है। उदाहरण के लिए:
FROM windowsservercore
# Executed as cmd /S /C echo default
RUN echo default
# Executed as cmd /S /C powershell -command Write-Host default
RUN powershell -command Write-Host default
# Executed as powershell -command Write-Host hello
SHELL ["powershell", "-command"]
RUN Write-Host hello
# Executed as cmd /S /C echo hello
SHELL ["cmd", "/S"", "/C"]
RUN echo hello
निम्नलिखित निर्देश SHELL
निर्देश से प्रभावित हो सकते हैं जब उनमें से शेल फॉर्म का उपयोग डॉकरीफाइल: RUN
, CMD
और ENTRYPOINT
।
निम्न उदाहरण विंडोज पर पाया जाने वाला एक सामान्य पैटर्न है जिसे SHELL
अनुदेश का उपयोग करके सुव्यवस्थित किया जा सकता है:
...
RUN powershell -command Execute-MyCmdlet -param1 "c:\foo.txt"
...
कमांडर द्वारा किया जाएगा:
cmd /S /C powershell -command Execute-MyCmdlet -param1 "c:\foo.txt"
यह दो कारणों से अक्षम है। सबसे पहले, एक आवश्यक-आवश्यक cmd.exe कमांड प्रोसेसर (उर्फ शेल) है, जिसका आह्वान किया जा रहा है। दूसरा, शेल फॉर्म में प्रत्येक RUN
निर्देश को कमांड को उपसर्ग करने के लिए एक अतिरिक्त शक्तियां -कमांड की आवश्यकता होती है।
इसे और अधिक कुशल बनाने के लिए, दो तंत्रों में से एक को नियोजित किया जा सकता है। एक RUN
कमांड के JSON फॉर्म का उपयोग करना है:
...
RUN ["powershell", "-command", "Execute-MyCmdlet", "-param1 \"c:\\foo.txt\""]
...
जबकि JSON फॉर्म असंदिग्ध है और संयुक्त राष्ट्र के आवश्यक cmd.exe का उपयोग नहीं करता है, इसमें दोहरे-उद्धरण और भागने के माध्यम से अधिक वाचालता की आवश्यकता होती है। वैकल्पिक तंत्र SHELL
निर्देश और शेल फॉर्म का उपयोग करना है, जो विंडोज उपयोगकर्ताओं के लिए एक अधिक प्राकृतिक वाक्यविन्यास बनाता है, खासकर जब एस्केप पार्सर निर्देश के साथ संयुक्त:
# escape=`
FROM windowsservercore
SHELL ["powershell","-command"]
RUN New-Item -ItemType Directory C:\Example
ADD Execute-MyCmdlet.ps1 c:\example\
RUN c:\example\Execute-MyCmdlet -sample 'hello world'
जिसके परिणामस्वरूप:
PS E:\docker\build\shell> docker build -t shell .
Sending build context to Docker daemon 3.584 kB
Step 1 : FROM windowsservercore
---> 5bc36a335344
Step 2 : SHELL powershell -command
---> Running in 87d7a64c9751
---> 4327358436c1
Removing intermediate container 87d7a64c9751
Step 3 : RUN New-Item -ItemType Directory C:\Example
---> Running in 3e6ba16b8df9
Directory: C:\
Mode LastWriteTime Length Name
---- ------------- ------ ----
d----- 6/2/2016 2:59 PM Example
---> 1f1dfdcec085
Removing intermediate container 3e6ba16b8df9
Step 4 : ADD Execute-MyCmdlet.ps1 c:\example\
---> 6770b4c17f29
Removing intermediate container b139e34291dc
Step 5 : RUN c:\example\Execute-MyCmdlet -sample 'hello world'
---> Running in abdcf50dfd1f
Hello from Execute-MyCmdlet.ps1 - passed hello world
---> ba0e25255fda
Removing intermediate container abdcf50dfd1f
Successfully built ba0e25255fda
PS E:\docker\build\shell>
SHELL
निर्देश का उपयोग उस तरीके को संशोधित करने के लिए भी किया जा सकता है जिसमें शेल संचालित होता है। उदाहरण के लिए, SHELL cmd /S /C /V:ON|OFF
करके Windows पर, विलंबित पर्यावरण चर विस्तार शब्दार्थ को संशोधित किया जा सकता है।
SHELL
निर्देश का उपयोग लिनक्स पर भी किया जा सकता है, एक वैकल्पिक शेल की आवश्यकता होनी चाहिए जैसे zsh, csh, tcsh और अन्य।
SHELL
फीचर को डॉकर 1.12 में जोड़ा गया था।
डेबियन / उबंटू पैकेज स्थापित करना
अद्यतन को मर्ज करने और स्थापित करने के लिए एकल रन कमांड पर स्थापित करें। यदि आप बाद में अधिक पैकेज जोड़ते हैं, तो यह अपडेट को फिर से चलाएगा और आवश्यक सभी संकुल को स्थापित करेगा। यदि अद्यतन अलग से चलाया जाता है, तो इसे कैश किया जाएगा और पैकेज इंस्टॉल विफल हो सकता है। स्क्रिप्ट को स्थापित करने के लिए गैर-सक्रिय और सीमा -y को स्थापित करने के लिए दृश्यपटल सेट करना आवश्यक है। स्थापना के अंत में सफाई और शुद्ध करना परत के आकार को कम करता है।
FROM debian
RUN apt-get update \
&& DEBIAN_FRONTEND=noninteractive apt-get install -y \
git \
openssh-client \
sudo \
vim \
wget \
&& apt-get clean \
&& rm -rf /var/lib/apt/lists/*