Moby: ईएनएसवी और एआरजी सेटिंग्स को मल्टी-स्टेज बिल्ड में सभी बाद के चरणों में जारी रखना

ENV var और ARG सहित सही, Dockerfile निर्देश बिल्ड-स्टेज के अनुसार बंद किए जाते हैं, और अगले चरण में संरक्षित नहीं किए जाएंगे; यह डिजाइन द्वारा है।

आप _can_, हालांकि, _global_ ARG (पहले बिल्ड-स्टेज से पहले सेट) सेट करते हैं, और प्रत्येक बिल्ड-स्टेज में उस मान का उपयोग करते हैं;

ARG version_default=v1

FROM alpine:latest as base1
ARG version_default
ENV version=$version_default
RUN echo ${version}
RUN echo ${version_default}

FROM alpine:latest as base2
ARG version_default
RUN echo ${version_default}

--build-arg सेट के बिना निर्माण करते समय;

docker build --no-cache -<<'EOF'
ARG version_default=v1

FROM alpine:latest as base1
ARG version_default
ENV version=$version_default
RUN echo ${version}
RUN echo ${version_default}

FROM alpine:latest as base2
ARG version_default
RUN echo ${version_default}
EOF

यह उत्पादन करता है:

Sending build context to Docker daemon  2.048kB
Step 1/9 : ARG version_default=v1
Step 2/9 : FROM alpine:latest as base1
 ---> 3fd9065eaf02
Step 3/9 : ARG version_default
 ---> Running in 702c05d6f294
Removing intermediate container 702c05d6f294
 ---> 1b2cac6e7585
Step 4/9 : ENV version=$version_default
 ---> Running in 6fb73bc8cdb9
Removing intermediate container 6fb73bc8cdb9
 ---> 656d82ccb6d7
Step 5/9 : RUN echo ${version}
 ---> Running in 403c720d0031
v1
Removing intermediate container 403c720d0031
 ---> d6071c5bd329
Step 6/9 : RUN echo ${version_default}
 ---> Running in d5c76d7d3aaa
v1
Removing intermediate container d5c76d7d3aaa
 ---> 554df1d8584b
Step 7/9 : FROM alpine:latest as base2
 ---> 3fd9065eaf02
Step 8/9 : ARG version_default
 ---> Running in 92400e85c722
Removing intermediate container 92400e85c722
 ---> 5f0cb12f4448
Step 9/9 : RUN echo ${version_default}
 ---> Running in f38802f0d690
v1
Removing intermediate container f38802f0d690
 ---> 4b8caab7870a
Successfully built 4b8caab7870a

और _with_ a --build-arg ;

docker build --no-cache --build-arg version_default=v2 -<<'EOF'
ARG version_default=v1

FROM alpine:latest as base1
ARG version_default
ENV version=$version_default
RUN echo ${version}
RUN echo ${version_default}

FROM alpine:latest as base2
ARG version_default
RUN echo ${version_default}
EOF

Sending build context to Docker daemon  2.048kB
Step 1/9 : ARG version_default=v1
Step 2/9 : FROM alpine:latest as base1
 ---> 3fd9065eaf02
Step 3/9 : ARG version_default
 ---> Running in 7f5dd5885859
Removing intermediate container 7f5dd5885859
 ---> 482ffb014095
Step 4/9 : ENV version=$version_default
 ---> Running in b6c6e9aa3489
Removing intermediate container b6c6e9aa3489
 ---> 83f1c0b82986
Step 5/9 : RUN echo ${version}
 ---> Running in 0805ec04fd20
v2
Removing intermediate container 0805ec04fd20
 ---> ef39d4bd6306
Step 6/9 : RUN echo ${version_default}
 ---> Running in f8747a5bfeeb
v2
Removing intermediate container f8747a5bfeeb
 ---> 72d497d25306
Step 7/9 : FROM alpine:latest as base2
 ---> 3fd9065eaf02
Step 8/9 : ARG version_default
 ---> Running in 57aa2e097787
Removing intermediate container 57aa2e097787
 ---> 45e167d234ce
Step 9/9 : RUN echo ${version_default}
 ---> Running in 8615cd6f6ab6
v2
Removing intermediate container 8615cd6f6ab6
 ---> 1674ad8d3b88
Successfully built 1674ad8d3b88

एक और तरीका कई चरणों के लिए बेस कंटेनर का उपयोग करना है:

FROM alpine:latest as base
ARG version_default
ENV version=$version_default

FROM base
RUN echo ${version}

FROM base
RUN echo ${version}

docker build --build-arg=version_default=123 --no-cache .   
Sending build context to Docker daemon  92.67kB
Step 1/7 : FROM alpine:latest as base
 ---> 3fd9065eaf02
Step 2/7 : ARG version_default
 ---> Running in a1ebfdf79f07
Removing intermediate container a1ebfdf79f07
 ---> 3e78800ed9ea
Step 3/7 : ENV version=$version_default
 ---> Running in 105d94baac3f
Removing intermediate container 105d94baac3f
 ---> a14276ddc77b
Step 4/7 : FROM base
 ---> a14276ddc77b
Step 5/7 : RUN echo ${version}
 ---> Running in d92f9b48a6cc
123
Removing intermediate container d92f9b48a6cc
 ---> 6505fe2a14bb
Step 6/7 : FROM base
 ---> a14276ddc77b
Step 7/7 : RUN echo ${version}
 ---> Running in 1b748eea4ef3
123
Removing intermediate container 1b748eea4ef3
 ---> f3311d3ad27e
Successfully built f3311d3ad27e
Time: 0h:00m:04s

मुझे इस मुद्दे को बंद करने दें, क्योंकि यह डिजाइन द्वारा है, लेकिन आशा है कि ऊपर दिए गए उदाहरण आपको आगे मदद करते हैं; बातचीत जारी रखने के लिए भी स्वतंत्र महसूस करें

यदि यह डिजाइन द्वारा है, तो डिजाइन गलत है। चरणों के बीच चर साझा करने के लिए एक संक्षिप्त तरीके के बिना यह DRY असंभव है। अपरिहार्य, असामयिक परिस्थितियां हैं जहां कई चरणों को समान चर तक पहुंच की आवश्यकता होगी। डुप्लिकेटिंग परिभाषाएँ त्रुटि प्रवण हैं, और इसलिए प्रत्येक चरण में साझा परिभाषाओं को हैक करने के लिए बॉयलरप्लेट को डुप्लिकेट कर रहा है।

"बेस कंटेनर" दृष्टिकोण गंभीर रूप से अभिव्यंजक शक्ति को सीमित करता है क्योंकि यह प्रत्येक चरण के लिए बेस कंटेनर को ठीक करता है, जबकि वैध उपयोग के मामले हैं जहां मध्यवर्ती चरण प्रत्येक को एक अलग न्यूनतम आधार छवि का उपयोग करने की आवश्यकता होती है जो चरण के लिए आवश्यक उपकरण प्रदान करता है।

@ तजजमत
क्या इस डिजाइन पर पुनर्विचार किया जा सकता है?

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

@ DMaxfield-BDS ARG का स्कोप नहीं बदलेगा, लेकिन आप एक अलग बिल्ड लक्ष्य बनाने पर विचार कर सकते हैं जो "FROM स्क्रैच" बेस इमेज बनाता है; रजिस्ट्री को धक्का दें, और यदि आपकी अन्य छवियों के लिए उपयोग करें;

FROM scratch AS scratch-base
ENV foo=bar
ENV bar=baz

इसे बनाएँ, और इसे अपनी (आंतरिक) रजिस्ट्री पर धकेलें, और वे 11 आधार चित्र इसे आधार के रूप में उपयोग कर सकते हैं

FROM scratch-base
RUN your stuff

EXPORT/IMPORT होने का एक और प्रस्ताव है, जो कुछ अन्य उपयोग-मामलों में फिट हो सकता है; https://github.com/moby/moby/issues/32100

@ तजजतह

आपकी प्रतिक्रिया के लिए धन्यवाद। एक बात जो मैंने नहीं बताई, वह यह है कि इन 11 अन्य छवियों में अलग-अलग आधार चित्र (अजगर, एनपीएम, पोस्टग्रेज, ओपनज्डक, आदि) हैं। इसलिए मैं जो करना चाह रहा हूं, वह सभी आम सेट-अप / प्रीप को एक बेस इमेज में डाल दिया गया है, जिसमें मेरी कंपनियों द्वारा उपयोग किए जाने वाले आवश्यक पर्यावरण चर को सेट करना शामिल है, जैसे निम्नलिखित:

FROM scratch AS scratch-base
ARG JAR_DIR='/Input/jars/'
ENV JAR_DOWNLOAD_DIR=$JAR_DIR

मेरी आंतरिक रजिस्ट्री पर पुश करें। फिर, अन्य 11 छवियों में से एक का उदाहरण निम्नलिखित होगा:

FROM scratch-base AS scratch-base
FROM openjdk:8-jdk
COPY --from=scratch-base $JAR_DOWNLOAD_DIR .
RUN <stuff that also uses the JAR_DOWNLOAD_DIR environment variable>

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

मैं इस तरह से कैसे कुछ करने वाला हूं?

RUN COMMIT_HASH = $ (git Rev-parse --short HEAD)

बाद के RUN चरणों में मुझे COMMIT_HASH चर का उपयोग करने की अनुमति कैसे दी जाती है? मैं चर को परिभाषित करने और इसे एक चरण में उपयोग करने के लिए मजबूर हूं?

मेरी राय में यह डिजाइन बहुत सीमित है। शायद कोई कर सकता है:

RUN COMMIT_HASH = $ (git Rev-parse --short HEAD) AS- हैश
ARG --from = प्रतिबद्ध-हैश COMMIT_HASH
RUN गूंज $ {COMMIT_HASH}

@ dnk8n यह वही है जो मैं इसके आसपास काम करता हूं:

बिल्ड स्टेज पर मैं:

RUN git rev-parse HEAD > commit_hash

फिर दूसरे चरण में मैं डेटा के साथ फ़ाइल की प्रतिलिपि बनाता हूं और अपने ऐप को चलाने से पहले पर्यावरण चर को सेट करता हूं जो इसका उपभोग करता है:

COPY --from=builder /<build_folder>/commit_hash /<other_stage_folder>/commit_hash

CMD export COMMIT_HASH=$(cat /<other_stage_folder>/commit_hash); java -jar myApp.jar

आपको ARG सेट करने के लिए कुछ समान करने में सक्षम होना चाहिए।

बहुत कम से कम हमें इस तरह का कुछ करने में सक्षम होना चाहिए कि दूसरे चरण / छवि से BAR चर की प्रतिलिपि वर्तमान बिल्ड स्कोप में बनाई जा सके।

ENV --from=stage1 FOO=$BAR

एक बाहरी छवि को एक मंच के रूप में उपयोग करते समय यह और भी महत्वपूर्ण है क्योंकि पर्यावरण चर में महत्वपूर्ण मेटाडेटा हो सकता है।

ENV --from=nginx:latest FOO=$BAR

मैं इस पैटर्न का उपयोग करके प्रत्येक चरण में फ़ाइल को पर्यावरण को बचाकर काम कर रहा हूं:

FROM base1:version1 AS BUILDER1
WORKDIR /build
RUN env | sort > env.BUILDER1

FROM base2:version2 AS BUILDER2
WORKDIR /build
RUN env | sort > env.BUILDER2

FROM finalbase:version AS FINAL
WORKDIR /build
ENV LANG=C.UTF-8
COPY --from=BUILDER1 /build/env.BUILDER1 .
COPY --from=BUILDER2 /build/env.BUILDER2 .
# Use ". ./env.BUILDER" instead of "source" if /bin/sh is true-POSIX
RUN set -eux ; \
        source ./env.BUILDER1 ; \
        source ./env.BUILDER2 ; \
        env | sort

कि अंत में 'डॉकटर' में 'सेव' कैसे किया जा सकता है, जैसे docker inspect मैं अनिश्चित होने पर दिखाई देता है, लेकिन यह उदाहरण के लिए / etc / प्रोफाइल में जा सकता है।

पिछले टिप्पणी इतनी ताज़ा रही, केवल मुझे इस बात पर एक झलक मिलती है कि डॉकफाइल के पीछे कितने डेवलपर्स डिजाइन के फैसलों पर सवाल उठा रहे हैं। जाहिरा तौर पर "DRY" महारत हासिल करने वाले कौशलों में से नहीं था। यदि आप कोशिश करना चाहते हैं, तो एक और परत जोड़ें और डॉकफाइल्स को अस्थायी करना शुरू करें ...

सच कहूं तो मैं इस बारे में बहुत हैरान हूं ... "ग्लोबल एर्ग" मेरे लिए काम नहीं करता है। अगर मैं बिल्ड आर्ग को किसी और चीज से पहले ऊपर ले जाता हूं, तो ऐसा लगता है कि वे FROM के बाद के चरणों में मौजूद नहीं हैं।

संपादित करें: मैंने देखा नहीं था कि मुझे एआरजी लाइनों को प्रत्येक FROM के बाद किसी भी मान के साथ फिर से दोहराना होगा ... यह काम करता है लेकिन आदर्श नहीं।

दूसरे चरण से पर्यावरण चर की नकल (प्राप्त करना) का स्पष्ट तरीका है। मेरे पास इसके लिए वैध उपयोग का मामला है।
यहाँ एक सरल उदाहरण दिया गया है:

FROM node:lts-alpine AS node
FROM php:7-fpm-alpine AS php

# Here goes some build instructions for PHP image, then

# Install nodejs, npm, yarn
COPY --from=node /usr/local/bin/node /usr/local/bin/node
COPY --from=node /usr/local/lib/node_modules /usr/local/lib/node_modules
COPY --from=node /opt /opt

# Create symlinks to npm, yarn binaries
RUN \
    ln -s "/usr/local/lib/node_modules/npm/bin/npm-cli.js" /usr/local/bin/npm \
    && ln -s "/usr/local/lib/node_modules/npm/bin/npx-cli.js" /usr/local/bin/npx \
    && ln -s /opt/yarn-v1.??.?/bin/yarn /usr/local/bin/yarn \
    && ln -s /opt/yarn-v1.??.?/bin/yarnpkg /usr/local/bin/yarnpkg

# Some other instructions

अब, मुझे यार्न संस्करण को कैसे जानना चाहिए अगर इसे पर्यावरण के चर में नोड छवि ( YARN_VERSION ) में परिभाषित किया गया है?

मल्टी-स्टेज बिल्ड को हमारे CI पाइपलाइनों में बड़े लाभों के साथ समायोजित किया गया है। "एनवायरनमेंट इनहेरिटेंस" जैसी सुविधा इसे दूसरे स्तर के रखरखाव और फीचर वार में भी आगे बढ़ाएगी।

मैं लगभग 5 परतें env vars के भारी उपयोग के साथ रख रहा हूं और हर अपडेट एक बुरा सपना है। उज्ज्वल पक्ष (?), मैं इससे पहले कि मैं एक नया चरण शुरू करने से पहले दो बार सोचता हूं।

वर्तमान एआरजी कार्यान्वयन कुछ जिज्ञासु व्यवहार देता है:

FROM python
ARG X=os    # or ENV, the same  
RUN echo import ${X:-sys}   # Proof that the syntax works with default SHELL
SHELL ["python", "-c"]
RUN import os
RUN import ${X}  # Fails
RUN import ${X:-sys}  # Fails too, but this is a documented syntax (for ENV)

या

FROM alpine
ARG X=ab.cd
RUN echo ${X%.*}  # it's ok but it looks like magic 
WORKDIR ${X%.*}  # Fails here 

यह इस तथ्य से जुड़ा हुआ है कि एआरजी प्रति-चरण पर्यावरण चर हैं, न कि टेंपलेटिंग।

मुझे पता है कि आपने (और मुझे) शायद कभी नहीं देखा है कि वास्तविक जीवन में (स्ट्रिंग हेरफेर शायद ...)।
लेकिन यह इस तथ्य को उजागर करता है कि डॉक सिंटैक्स अंडरलेयर शेल सिंटैक्स पर आधारित है। यह दस्तावेज़ झूठ बनाता है: (https://docs.docker.com/engine/reference/builder/#environment-replacement और काउंटर-उदाहरण " RUN import ${X:-sys} " देखें)

RUN विरासत की तरह 'कमांड' बनाने से पहले ARG की व्याख्या क्यों नहीं करता है?

$ cat Makefile
SHELL=python
X=os
test:
    import os
    import ${X}
$ make test
import os
import os

24 घंटे खत्म हो गए हैं =)

_Warning_ यह समाधान काम नहीं करता, हालाँकि मैं चाहता हूँ कि यह होगा!

पहले चरण में किसी फ़ाइल में env var लिखें और दूसरे चरण में उस एक फ़ाइल को कॉपी करें? आदि? इस प्रकार सं:

FROM golang:1.14 as cm_base
ARG commit_id
RUN echo "$commit_id" > /tmp/env.json
FROM golang:1.14
COPY --from=cm_base "/tmp/env.json" "/tmp/env.json"
ENV cm_cc_commit_id="$(cat /tmp/env.json)"

बूम, इसके अलावा यह काम नहीं करता है, क्योंकि cm_cc_commit_id शाब्दिक $(cat /tmp/env.json) , बाद वाले अभिव्यक्ति का मूल्यांकन नहीं किया जाता है, यह शाब्दिक रहता है। तो डायनामिक एनवी वर्सेस सेट करना असंभव लगता है?

हालाँकि क्या काम करता है एक फ़ाइल को लिख रहा है, आपके एंट्रीपॉइंट को बैश फ़ाइल बनाता है, और फिर यह कर रहा है:

#!/usr/bin/env bash
echo "the docker entrypoint args:" "$@"
export cm_cc_commit_id="$(cat /tmp/env.json)"
"$@"

इसके बारे में इस तरह से सोचें:

Dockerfile के पास वैश्विक ARG को छोड़कर चर घोषित करने का साधन नहीं है। यह स्वचालित रूप से प्रत्येक चरण में नहीं फैलता है क्योंकि इससे कैशिंग पर प्रभाव पड़ता है।
बिल्डर होशियार हो सकता है और यह निर्धारित कर सकता है कि क्या आप किसी विशेष चरण में ARG का उपयोग करने की कोशिश कर रहे हैं और इसे अनुमति देते हैं, लेकिन तब आपको यह अनुमान लगाना होगा कि क्या आप शाब्दिक चाहते थे या नहीं।

तो हाँ, आपको स्पष्ट रूप से वैश्विक ARG s को प्रत्येक चरण में आयात करना होगा जिसे आप इसका उपयोग करना चाहते हैं। हो सकता है कि बिल्डर या कोई लिंटर उन मामलों के लिए चेतावनी को लागू कर सके जहां ऐसा लगता है कि आप ARG का उपयोग करने का प्रयास कर रहे होंगे।
यह डिजाइन द्वारा नहीं तोड़ा गया है, यह कोड के कम लाइनों पर इष्टतम कैशिंग चुनने के लिए एक स्पष्ट विकल्प है।

यह निश्चित रूप से समझा जाता है कि वैश्विक ARG s का उपयोग शुरू में भ्रमित कर रहा है।