Moby: 1.13 में `डॉकर स्टैक परिनियोजन` `.env` फ़ाइल को `डॉकर-कंपोज़ अप` के रूप में लोड नहीं करता है

यह डिजाइन द्वारा है। .env समर्थन लिखें की एक विशेषता है, फ़ाइल स्वरूप की नहीं।

हम इसे भविष्य में रिलीज के लिए जोड़ने पर चर्चा कर सकते हैं, लेकिन मुझे नहीं पता कि यह वास्तव में सबसे अच्छा विकल्प है या नहीं।

कंपोज़ में .env सपोर्ट काफी उपयोगी है, हमने इसे अपनी कई कंपोज़ फाइलों में इस्तेमाल किया है। यह docker-compose.yml फ़ाइल के गतिशील भागों और स्थिर भागों को अलग करता है। डिफ़ॉल्ट रूप से लोड .env के साथ, हम अलग-अलग वातावरण के लिए अलग-अलग .env फ़ाइल प्रदान कर सकते हैं, और docker-compose.yml और संबंधित स्क्रिप्ट को स्थिर रख सकते हैं।

समान envvars प्रतिस्थापन परिणाम प्राप्त करने के लिए env_file या environment में docker-compose.yml का उपयोग करना संभव नहीं है। .env इसे करने का सबसे आसान तरीका है।

अन्यथा, हमें export को .env फ़ाइल की प्रत्येक पंक्ति में उपसर्ग करना होगा और मैन्युअल रूप से source .env हर बार docker-compose.yml लोड करने से पहले, और अतिरिक्त कदम कभी-कभी प्रवण होते हैं गलती करने के लिए।

मैंने अभी इस पर गौर किया है।
मैंने माना/उम्मीद की थी कि यह उसी तरह काम करेगा जैसे यह कंपोज़ के लिए करता है, लेकिन ऐसा नहीं है docker deploy ।

मेरे विशेष मामले में, मैं स्टैक में बनाई जा रही सेवाओं में उपयोग किए जाने वाले संवेदनशील डेटा (पासवर्ड, एपीआई कुंजी, आदि) को स्टोर करने के लिए .env फ़ाइल का उपयोग करने की उम्मीद कर रहा था:

version: '3'

volumes:
  data:
    driver: local

networks:
  backend:
    driver: overlay

services:
  rabbitmq:
    image: rabbitmq:${EXCHANGE_RABBITMQ_TAG}
    volumes: [ "data:/var/lib/rabbitmq" ]
    logging: { driver: gelf, options: { gelf-address: "udp://0.0.0.0:12201" } }
    networks: [ "backend" ]
    ports: [ "15672:15672", "5672:5672" ]
    environment:
      RABBITMQ_DEFAULT_USER: ${EXCHANGE_RABBITMQ_USER}
      RABBITMQ_DEFAULT_PASS: ${EXCHANGE_RABBITMQ_PASS}
    deploy:
      replicas: 1
      restart_policy:
        condition: on-failure
      placement:
        constraints:
          - node.labels.queue-host == true

जबकि इस कंपोज़ फ़ाइल को Git पर चेक किया जाएगा, .env फ़ाइल को नज़रअंदाज़ कर दिया जाएगा।

मैंने *.dab बनाम कंपोज़ फाइल्स की पूरी सामग्री/इतिहास का पालन किया है, और मुझे लगता है कि आप लोग कुछ टालने की कोशिश कर रहे हैं - या एक बेहतर समाधान का प्रस्ताव दे रहे हैं - लेकिन मैंने पूरी चर्चा का ट्रैक खो दिया है ...

हैलो सभी को,

डॉकर संस्करण: v1.13.0-rc4

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

और network_mode के लिए भी यही त्रुटि हो रही है: असमर्थित विकल्पों को अनदेखा करना: network_mode.

नीचे आदेश है:
DOCKER_IMAGE=akhil123 डॉकटर स्टैक परिनियोजित -c docker-compose.yml foo

अग्रिम में बहुत धन्यवाद।

@akhildangore कृपया उन मुद्दों पर टिप्पणी न करें जो सीधे तौर पर संबंधित नहीं हैं। docker stack deploy फीचर, _by design_ बिल्ड नहीं करता है। इसका कारण यह है कि जिस होस्ट से कमांड चलाया जाता है उस पर एक _build_ किया जाता है, इसलिए छवि केवल _that_ नोड पर उपलब्ध होगी। उस छवि को झुंड में तैनात करते समय, सेवा अन्य नोड्स पर शुरू नहीं की जा सकती है। सेवाओं को परिनियोजित करने के लिए, सुनिश्चित करें कि जिस छवि को आप परिनियोजित कर रहे हैं उसे रजिस्ट्री में धकेल दिया गया है (या परीक्षण के लिए; सुनिश्चित करें कि छवि झुंड में प्रत्येक नोड पर उपलब्ध है)

क्या docker deploy पर इस व्यवहार का समर्थन करने के पक्ष में/विरुद्ध कोई मामला/चर्चा है?

@vovimayhem .env फ़ाइल पर अभी तक कोई निर्णय नहीं लिया गया था, लेकिन आपको https://github.com/docker/docker/pull/30144 में रुचि हो सकती है, जो कंपोज़ फ़ाइल में रहस्यों के लिए समर्थन जोड़ता है

मुझे अभी वह चर्चा मिली है। उत्कृष्ट!

मैं वर्कअराउंड के रूप में बैश फ़ंक्शन का उपयोग कर रहा हूं।

secrets सुविधा जारी होने तक आप इसे अपनी आवश्यकताओं के अनुसार अनुकूलित कर सकते हैं:

dsd() {
    stack=${1:-${PWD##*/}} # by default, the name of the cointaining folder
    compose_file=${2:-docker-compose.yml}

    if [ ! -f $compose_file ]; then
        echo "Misses compose file: $compose_file" >&2
        return 1
    fi

    # execute as a subcommand in order to avoid the variables remain set
    (
        # export variables excluding comments
        [ -f .env ] && export $(sed '/^#/d' .env)

        # Use dsd your_stack your_compose_file to override the defaults
        docker stack deploy --compose-file $compose_file $stack
    )
}

इस मुद्दे की सदस्यता लेने वालों के लिए; डॉकटर-कंपोज़ फ़ाइलों के लिए गुप्त समर्थन 1.13.1 रिलीज़ में शामिल किया जाएगा, जो भविष्य में बहुत दूर नहीं होना चाहिए

@ मैं इसे वर्कअराउंड के रूप में उपयोग कर रहा हूं:

env $(cat .env | grep ^[A-Z] | xargs) docker stack deploy --compose-file docker-compose.yml [STACK_NAME]

इस तरह, वेरिएबल टर्मिनल विंडो पर अटकते नहीं हैं

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

आइए मान लें कि आप एक पूर्ण स्टैक को परिनियोजित करने के लिए docker stack deploy का उपयोग करते हैं और आपके पास निम्नलिखित आवश्यकताएं हैं:

• आप अलग-अलग परिवेशों के लिए ठीक उसी कॉन्फ़िगरेशन का उपयोग करना चाहते हैं - स्टेजिंग और प्रोडक्शन कहें
  
  
  
  • आपको प्रत्येक पर्यावरण के लिए अलग-अलग पैमाने के मूल्यों की आवश्यकता है
  
  

यदि आप इसे .env फ़ाइल के साथ कॉन्फ़िगर नहीं कर सकते हैं, तो आपको हर बार स्टैक को परिनियोजित करने से पहले मैन्युअल रूप से docker-compose.yml फ़ाइल को बदलना होगा, अन्यथा सेवा स्केल मान वापस 1 पर वापस आ जाएगा।

आप उपरोक्त को नेटवर्क जैसी चीजों के साथ बढ़ा सकते हैं, DNS को कॉन्फ़िगर कर सकते हैं जिसे एक सेवा को सुनना चाहिए, आदि।

मैं एक पीआर का मसौदा तैयार कर सकता हूं जो .env फ़ाइल लोड करेगा, अगर कोई उसी निर्देशिका में docker-compose.yml के रूप में मौजूद है यदि हमें लगता है कि उपरोक्त उपयोग के मामले समझ में आते हैं।

docker stack परिनियोजन का डिज़ाइन docker-compose कमांड से थोड़ा अलग है। मुझे नहीं लगता कि डिफ़ॉल्ट रूप से केवल .env पढ़ने का कोई मतलब है। डिफ़ॉल्ट रूप से docker-compse.yml भी नहीं पढ़ा जाता है, क्योंकि भविष्य में डिफ़ॉल्ट परिनियोजन स्रोत कुछ और होने की संभावना है।

stack deploy चलाने से पहले आप हमेशा .env फ़ाइल स्वयं स्रोत कर सकते हैं।

बस . .env कॉल करने से पहले docker stack deploy मदद नहीं करता है, $variables प्रतिस्थापित नहीं किए जाते हैं। केवल env .. xargs ट्रिक ने मदद की।
--env-file=FILE विकल्प जैसे docker run में होना अच्छा होगा।

अभी - अभी । डॉकर स्टैक परिनियोजन को कॉल करने से पहले .env मदद नहीं करता है

इससे @ सी-प्रो को मदद मिलनी चाहिए - आपको अपनी .env फ़ाइल में export ... लाइनें रखनी होंगी। वैकल्पिक रूप से, आप export $(cat .env) कर सकते हैं, जो ज्यादातर मामलों के लिए काम करेगा।

हैलो सभी को,
आज मैंने docker stack deploy चलाने की कोशिश की।
मेरी docker-compose.yml फ़ाइल:

version: '3'
services:
  simple:
    image: alpine
    environment:
      - FOO: ${BAR}
    env_file: .env

और उसी निर्देशिका में .env फ़ाइल:

BAR=worked

लॉन्च करने के बाद docker stack deploy -c docker-compose.yml test , मैंने कंटेनर का निरीक्षण किया और इसे प्राप्त किया:

$ env
BAR=worked
FOO=
...

ऐसा लगता है, .env कंटेनर में प्रदान किया गया, लेकिन होस्ट मशीन पर प्रदान नहीं किया गया।
इसका मतलब है, कि मैं environment अनुभाग के बजाय .env फ़ाइल का उपयोग कर सकता हूं, लेकिन मैं परिवर्तनीय प्रतिस्थापन के साथ .env फ़ाइल का उपयोग नहीं कर सकता।
डॉकर संस्करण: v17.03

@ddpaimon
वातावरण:
- फू = $ {बार}

ऐसा लगता है कि .env फ़ाइल केवल कंटेनर के लिए काम करती है, लेकिन docker-compose.yml फ़ाइल चर प्रतिस्थापन के लिए नहीं।

मैक के लिए डॉकर, डॉकर संस्करण 17.03.1-सीई, बिल्ड c6d412e

@realcbb
हां। लेकिन कंटेनर के अंदर .env फ़ाइल चर का उपयोग करने के लिए, आपको उन्हें environment अनुभाग में निकालना होगा।
उदाहरण के लिए:
docker-compose.yml

...
environment:
  - FOO=${FOO:-empty}
...

.env

FOO=filled

कंटेनर में मुझे यह मिला:

$ env
FOO=empty

लेकिन अगर मैं FOO को environment अनुभाग से docker-compose.yml में हटा देता हूं, तो मुझे यह मिल गया:

$ env
FOO=filled

@ddpaimon
पर्यावरण में निर्दिष्ट पर्यावरण चर .env फ़ाइल में निर्दिष्ट इन मानों को ओवरराइड करते हैं।

@dnephin : आप कहते हैं कि .env डॉकर कंपोज़ फ़ाइल स्वरूप का हिस्सा नहीं है। हालाँकि, .env फ़ाइल सुविधा को कम्पोज़ फ़ाइल संस्करण 3 संदर्भ में प्रलेखित किया गया है: https://docs.docker.com/compose/compose-file/#variable -substitution ।
इससे यह आभास होता है कि .env को डॉकटर स्टैक परिनियोजन के साथ भी काम करना चाहिए।
इसके अलावा, जैसा कि पहले ही दूसरों द्वारा उल्लेख किया गया है, वास्तविक पर्यावरण विशिष्ट मूल्यों को स्टैक परिभाषा yaml से अलग करना एक बहुत वांछित/आवश्यक विशेषता है। विशेष रूप से हम इसका उपयोग छवि संस्करणों और प्रतिकृतियों को निर्दिष्ट करने के लिए करना चाहते हैं।

धन्यवाद, मैंने डॉक्स को ठीक करने के लिए https://github.com/docker/docker.github.io/issues/3654 खोला

docker stack deploy एक जेनरेट की गई फाइल ले सकता है। यह मेरे सभी चर के लिए बैश में काम करता है और रहस्यों को भी गुप्त रखता है:

docker stack deploy --with-registry-auth --compose-file=<(ENV1=value1 ENV2=value2 docker-compose -f docker-compose.yaml -f docker-compose.override.yaml -f third-sample-compose.yaml config) stack-name

कृपया ध्यान दें कि मैंने इन-लाइन ईएनवी चर को अतिरिक्त या ओवरराइड के रूप में जोड़ा है। मेरी लिखें फ़ाइलें संदर्भ .env फ़ाइलें और यह काम करता है। आशा है कि यह मददगार है

docker-compose config की कार्यक्षमता ही इसे एक साथ जोड़ती है।

मेरे .env द्वारा docker stack deploy में नहीं पढ़े जाने के समाधान की तलाश में मैं इस मुद्दे पर आया था। मुझे यह देखकर थोड़ा आश्चर्य हुआ कि यह समर्थित नहीं था (दस्तावेज़ों को स्पष्ट किया जा सकता है), लेकिन .env के लिए अपना समर्थन जोड़ना चाहते हैं, जैसे लिखें।

मेरा उपयोग मामला यह है कि मैं देव, परीक्षण, मंचन वातावरण में docker stack deploy का उपयोग करता हूं और yml फ़ाइल को समान रखने के लिए स्टैक विकल्पों के लिए पर्यावरण चर का उपयोग करता हूं।

वर्तमान में यहां पोस्ट किए गए वर्कअराउंड में से एक का उपयोग करना लेकिन .env फ़ाइल का उपयोग करना पसंदीदा मार्ग होगा।

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

अन्य सामानों के लिए, क्या मैं सुझाव दे सकता हूं कि प्रति तैनात/तैनाती योग्य वातावरण में एक फ़ाइल लिखें? विभिन्न वातावरणों के बीच परिवर्तन करने वाली अधिकांश सामग्री उपलब्ध सर्वर, विभिन्न सर्वर संगठन, आदि होगी... और इस प्रकार deploy प्रमुख सामग्री ( placement नियम, resources पर विभिन्न मूल्यों की आवश्यकता होगी।

वास्तव में मुझे यह सुविधा चाहिए, डोकर स्टैक परिनियोजन का उपयोग करते समय कंपोज़ फ़ाइल में चर को अलग-अलग होस्ट पर अलग-अलग मान के रूप में माना जा सकता है।

"अन्य सामानों के लिए, क्या मैं सुझाव दे सकता हूं कि प्रति तैनात/तैनाती योग्य वातावरण में एक फ़ाइल लिखें? विभिन्न वातावरणों के बीच परिवर्तन करने वाली अधिकांश सामग्री उपलब्ध सर्वर, विभिन्न सर्वर संगठन इत्यादि होगी ... और इस प्रकार तैनाती कुंजी पर विभिन्न मूल्यों की आवश्यकता होगी सामग्री (नियुक्ति नियम, संसाधन आरक्षण, आदि), सब कुछ के लिए एक फ़ाइल का उपयोग करना थोड़ा जटिल है।"

@vovimayhem कुंद होने के लिए क्षमा करें, लेकिन यह एक env_file का उपयोग करके परिवर्तनीय प्रतिस्थापन के साथ एक एकल लिखें फ़ाइल का उपयोग करने के रूप में ज्यादा समझ में नहीं आता है। मैं env_file प्रारूप का उपयोग करना पसंद करूंगा क्योंकि यह मेरे लिए अपने ग्राहकों के लिए एक डिलिवरेबल के रूप में स्टैक प्रदान करना और उन्हें एक कंपोज़ फ़ाइल के साथ गड़बड़ करने की तुलना में एक एकल आईएनआई-स्टाइल वर्र्स फाइलों को अपडेट करने के लिए प्रशिक्षित करना आसान बनाता है (जो मैं नहीं करता हूं) 'टी चाहते हैं)।

@ntwrkguru https://docs.docker.com/engine/swarm/configs/

सेवा कॉन्फ़िगरेशन एक बढ़िया अतिरिक्त हैं, लेकिन वे परिनियोजन समय प्रक्षेप (उदा. $TAG) के लिए उपयोग करने योग्य नहीं लगते हैं।

यदि पर्यावरण चर बिल्कुल समर्थित हैं, तो उन्हें सभी उपकरणों में हल करने के लिए उपयोग किए जाने वाले तंत्र में सुसंगत रहें। ऐसा लगता है कि स्टैक परिनियोजन पर्यावरण परिवर्तनशील व्यवहारों को मौलिक रूप से बदले बिना असंगत होना चुनता है। पर्यावरण चर के कुछ उपयोगों के लिए रहस्य और सेवा विन्यास बेहतर विकल्प हैं, लेकिन वे समाहित नहीं होते हैं।

आपको यह @vovimayhem समझ में नहीं आ रहा है। मैं कंटेनरों में envs पास करने की बात नहीं कर रहा हूँ; जो अपेक्षा के अनुरूप काम करता है। मेरा मतलब एक env_file का उपयोग करना है जिसे stack deploy के दौरान पार्स किया गया है क्योंकि यह compose up के दौरान था।

@ntwrkguru मैंने सोचा था कि यह नई सुविधा आपकी मदद करेगी ... मैं बहुत दुखी हूं ऐसा नहीं है।

यह अभी भी एक विकल्प के रूप में काम करता है;

$ echo 'BAR=worked' > ./.env

$ export $(cat .env) && docker stack deploy testing -c -<<'EOF'
version: '3'
services:
  simple:
    image: nginx:alpine
    environment:
      FOO: ${BAR}
    env_file: .env
EOF

$ docker inspect testing_simple -f '{{json .Spec.TaskTemplate.ContainerSpec.Env}}'
["BAR=worked","FOO=worked"]

@thaJeztah , वास्तव में यह करता है। मेरे पास एक वातावरण फ़ाइल स्रोत करने के लिए मेरी प्लेबुक में एक कार्य है, लेकिन इसमें बड़ा बिंदु गुम है। यह compose के साथ संभव हुआ करता था और अब stack के साथ संभव नहीं है। आईएमओ, यह एक रिग्रेशन है। साथ ही, आपके उदाहरण में, आप अभी भी कंटेनर में एक पर्यावरण चर पारित कर रहे हैं। मैं आज env_files के साथ ऐसा कर सकता हूं; stack deploy -c docker-compose.yml ऑपरेशन के दौरान समस्या env_file को पार्स कर रही है।

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

इसके अलावा, एफडब्ल्यूआईडब्ल्यू, configs वास्तविक कॉन्फ़िगरेशन के लिए मेरे अनुभव में वास्तव में सबपर है। मैं कल्पना कर रहा था (उम्मीद कर रहा था) कि मेरे पास स्रोत में /application/config.conf हो सकता है। उस फ़ाइल को अपडेट करें, प्रतिबद्ध करें, पुश करें और सीआई नई कॉन्फ़िगरेशन के साथ स्टैक को फिर से तैनात करेगा। फ़ाइल नाम या किसी अन्य तंत्र को बदलने के लिए कुछ हैकरी के बिना यह संभव नहीं है। निश्चित रूप से हम फ़ाइल को कम से कम चेकसम कर सकते हैं, या सामग्री परिवर्तन के लिए स्कैन कर सकते हैं और फ़ाइल के आधार पर अपडेट कर सकते हैं? कुल मिलाकर ऐसा लगता है कि हम पीछे की ओर जा रहे हैं। अब K8s के लिए समर्थन में फेंको और यह मुझे आश्चर्यचकित करता है कि क्या झुंड सिर्फ बेल पर तब तक रहेगा जब तक कि यह पर्याप्त उपयोग नहीं खो देता है कि इसे चुपचाप गिरा दिया जाता है।

साथ ही, एफडब्ल्यूआईडब्ल्यू, कॉन्फ़िगरेशन वास्तविक कॉन्फ़िगरेशन के लिए मेरे अनुभव में वास्तव में सबपर है। मैं कल्पना कर रहा था (उम्मीद कर रहा था) कि मेरे पास स्रोत में /application/config.conf हो सकता है। उस फ़ाइल को अपडेट करें, प्रतिबद्ध करें, पुश करें और सीआई नई कॉन्फ़िगरेशन के साथ स्टैक को फिर से तैनात करेगा। फ़ाइल नाम या किसी अन्य तंत्र को बदलने के लिए कुछ हैकरी के बिना यह संभव नहीं है।

@ntwrkguru सरल समाधान फ़ाइल नाम नहीं, बल्कि कॉन्फ़िगरेशन का नाम बदल रहा है। मैंने अपने कॉन्फ़िगरेशन नामों के लिए एक संस्करण योजना नियोजित की, उदाहरण के लिए config_v1 , config_v2 , ..

इसलिए कॉन्फिग फाइल को बदलने के बाद बस उस वर्जन को अप करना याद रखें।

services:
  app:
    [...]
    configs:
      - source: config_v2
      - target: /config.yml

configs:
  config_v2:
    file: ./config.yml

मैं अभी तक एक संस्करण विन्यास और रहस्य नहीं होने के पीछे के तर्क को समझता हूं, इसलिए व्यक्तिगत रूप से मैं वर्तमान में इस (आसान) समाधान के साथ ठीक हूं।

धन्यवाद @djmaze , लेकिन यह अंततः एक हास्यास्पद बात है जब हर स्रोत नियंत्रण प्रणाली में अंतर्निहित संस्करण ट्रैकिंग निर्मित होती है। इसके अलावा, लिंक के लिए धन्यवाद; मैंने वहां भी टिप्पणी की। मैं यह नहीं देखता कि डॉकर वर्तमान संस्करण के अलावा अन्य संस्करण की परवाह क्यों करता है। रोलबैक के लिए इन संस्करणों की आवश्यकता के लिए मैं केवल एक ही कारण देख सकता था, लेकिन वैसे भी कई चीजों को ट्रैक करने की आवश्यकता है, तो कुछ और क्या है? (वह आदमी कहता है जिसे कोड नहीं लिखना है) :-)

इसे इस्तेमाल करे:
echo "$(docker-compose -f stack.yml config 2>/dev/null)" | docker stack deploy -c- stack_name

यह कॉन्फ़िगरेशन फ़ाइल को पार्स करने के लिए docker-compose का उपयोग करता है, env vars को प्रतिस्थापित करता है, आउटपुट से चेतावनियां स्ट्रिप्स करता है और फिर इसे stdin के माध्यम से docker स्टैक परिनियोजित करने के लिए पाइप करता है।
'-f stack.yml' को अपनी कॉन्फ़िग फ़ाइल के नाम से बदलें या डिफ़ॉल्ट docker-compose.yml का उपयोग करने के लिए इसे छोड़ दें।

+1

एक साल बाद और हमें अभी भी इसे काम करने के लिए हैक करना है। 17.09.1 ​​तक, docker stack deploy -f compose.yml ज्ञात शेल वर्रों का उपयोग करके भी प्रतिस्थापित नहीं होगा।

$ printenv | grep PORTAINER
PORTAINER_VER=1.14.3

portainer:
    image: "portainer/portainer:${PORTAINER_VER}"

$ sudo docker stack deploy -c /tmp/docker/jedi-core.yml --with-registry-auth --prune --resolve-image always jedi-core
Updating service jedi-core_redis_server (id: 0csjyandro713y13ncitk6c0k)
Updating service jedi-core_api-gateway (id: gzcz2eturuxqkjojsc9e6954l)
Updating service jedi-core_auto_results_api (id: tw43c6e0x98q6f0m2g0zttwhf)
Updating service jedi-core_auto_results_api_mongo (id: qpwpypyzd9aigpa71xgxxdzcp)
invalid reference format

टैग के लिए कोई भी वेरिएबल invalid reference format उत्पन्न करेगा।

एक साल बाद और हमें अभी भी इसे काम करने के लिए हैक करना है। 17.09.1 ​​तक, डॉकर स्टैक परिनियोजन -f compose.yml ज्ञात शेल वर्र्स का उपयोग करके भी स्थानापन्न नहीं होगा।

देखें कि SUDO का उपयोग करते समय पर्यावरण चर कैसे रखें

$ export PORTAINER_VER=1.14.3
$ printenv | grep PORTAINER
PORTAINER_VER=1.14.3

$ sudo printenv | grep PORTAINER

$ sudo -E printenv | grep PORTAINER
PORTAINER_VER=1.14.3


$ cat > docker-compose.yml <<'EOF'
version: '3'
services:
  portainer:
    image: "portainer/portainer:${PORTAINER_VER}"
EOF


$ sudo -E docker stack deploy -c docker-compose.yml foobar
Creating network foobar_default
Creating service foobar_portainer

$ sudo docker service ls
ID                  NAME                MODE                REPLICAS            IMAGE                        PORTS
vt4h0g8yygcg        foobar_portainer    replicated          1/1                 portainer/portainer:1.14.3   

धन्यवाद, लेकिन फ़ाइल से केवल परिवर्तनीय प्रतिस्थापन का समर्थन करने पर कोई शब्द?

[संपादित करें] यह कोई मुद्दा नहीं होना चाहिए (लेकिन हो सकता है) क्योंकि मैं become: yes के साथ कार्य करने के लिए Ansible का उपयोग कर रहा हूं, लेकिन उपयोगकर्ता अभी भी वही उपयोगकर्ता है जो पर्यावरण संस्करण का स्रोत है।

मुझे विश्वास नहीं हो रहा है कि यह संभव नहीं है। हम एक एकल स्टैक फ़ाइल रखना चाहते हैं और गतिशील चर का उपयोग करके परिनियोजन विकल्पों को बदलने में सक्षम होना चाहते हैं।

यह काम करेगा लेकिन बदसूरत और एक हैक है:

echo "$(docker-compose -f stack.yml config 2>/dev/null)" | docker stack deploy -c- stack_name

मैं इसके साथ कई घंटों से खिलवाड़ कर रहा हूं और ऐसा लगता है कि इन विभिन्न टुकड़ों से एक डीएबी फ़ाइल बनाने के लिए कुछ पृष्ठभूमि स्क्रिप्ट काम कर रहा हूं (मैं ऐसा करने के लिए सीआई का उपयोग करूँगा)। एक डॉकर टूल होना अच्छा होगा जो ऐसा करेगा... :-) शायद --env-file version.env को docker-compose bundle $ में जोड़ा जाए?

मेरे उपयोग के मामले में, मैं कंटेनर/छवियों के संस्करणों को ट्रैक और नियंत्रित करने के लिए version.env "प्रकट" का उपयोग करना चाहता हूं जिसमें एक प्लेटफॉर्म शामिल है। मेरी प्रक्रिया इस तरह दिखती है:

• .env फ़ाइल अपडेट करें
• स्रोत .env शेल संस्करण को पॉप्युलेट करने के लिए फ़ाइल
• docker-compose -f stack.yml config > docker-compose.yml . चलाएँ
• इमेज डाइजेस्ट रजिस्टर करने के लिए docker-compose pull चलाएँ
• docker-compose bundle -o stack.version.dab DAB फ़ाइल चलाएँ

इस बिंदु पर, आदर्श रूप से मैं docker deploy --host manager.swarm.com --bundle-file stack.version.dab --with-registry-auth --resolve-image always stack-name में सक्षम हो जाऊंगा, लेकिन मुझे लगता है कि यह अब संभव नहीं है। इस मामले में, मैं प्रबंधक को डीएबी फ़ाइल भेजूंगा और docker deploy निष्पादित करूंगा।

क्या यह वर्कफ़्लो डॉकर के दिमाग में @thaJeztah था? क्या कोई बेहतर तरीका है?

[संपादित करें] यह काम नहीं करता है क्योंकि एक डीएबी volume: , network: , और deploy: निर्देशों की उपेक्षा करता है। मैंने बस एक env फ़ाइल को शेल में सोर्स करने के लिए लिया है, एक अस्थायी कंपोज़ फ़ाइल का पुनर्निर्माण, फिर उसे तैनात करना।

मुझे अच्छा लगेगा अगर .env फाइलें डिफ़ॉल्ट रूप से पढ़ी जाती हैं जैसे डॉकर कंपोज और --env-file (लघु -e ) को ओवरराइड करने में सक्षम होने के लिए docker stack deploy के लिए जोड़ा जाएगा पर्यावरण चर और डिफ़ॉल्ट .env फ़ाइल से।

+1
पहली बार में .env को पढ़ना काफी सुविधाजनक होगा जैसा कि docker-compose करता है।
या तो डिफ़ॉल्ट रूप से या बस env फ़ाइल को docker स्टैक कमांड लाइन में पैरामीटर के रूप में पास करें।

दो पहले से ही उल्लिखित वर्कअराउंड (_उन्हें भी नीचे खोजें_) काम करने लगते हैं, हालांकि प्रस्तावित 'फिक्स' की तुलना में थोड़ा बदसूरत है।

_echo "$(docker-compose -f stack.yml config 2>/dev/null)" | डोकर स्टैक परिनियोजन -c- stack_name_

_env $(cat .env | grep ^[AZ] | xargs) डॉकटर स्टैक परिनियोजित --compose-file docker-compose.yml [STACK_NAME]_

मैं जोड़ूंगा कि इन चरों को संसाधित करने में सक्षम होने के लिए केवल docker-compose स्थापित करना भी वास्तव में काफी खतरनाक हो सकता है।

यदि कोई डॉकटर स्टैक परिनियोजन का उपयोग करने के बजाय गलती से docker-compose up -d का उपयोग करके स्टैक को तैनात करता है, तो यह संभवतः एप्लिकेशन त्रुटियों और फ़ाइल भ्रष्टाचार को प्रेरित करेगा।

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

'.env' के उपयोग के साथ एक समस्या यह है कि यह समान फ़ाइल नामों के साथ ओवरलैप करता है, उदाहरण के लिए, रूबी ऑन रेल्स, तर्क द्वारा पर्यावरण फ़ाइल निर्दिष्ट करने की क्षमता बेहतर है।

@ntelisil के सुझावों को अच्छी तरह से लिया गया है, उन्हें पूरक या संशोधित किया जा सकता है:

https://unix.stackexchange.com/questions/294835/replace-environment-variables-in-a-file-with-their-actual-values :

आप envsubst (gnu gettext का हिस्सा) का उपयोग कर सकते हैं:
envsubst <इनफाइल

मैंनें इस्तेमाल किया:

$ envsubst < docker-compose.yml-template > docker-compose.yml

और यह ठीक काम करता है, लेकिन मुझे अपने कंटेनर में 3 एमबी या उससे भी ज्यादा जोड़ने की जरूरत है।

अच्छा @rnickle , लेकिन अभी भी "हैकी" डॉकर की तुलना में ऐसा करने में सक्षम है जिस तरह से यह करता था। ऐसा लगता है (और अगर मैं गलत हूं तो कृपया डॉकर दोस्तों ने मुझे सही किया) कि K8s समर्थन की घोषणा के बाद से झुंड-मोड में बहुत कम प्रयास हो रहे हैं, इसलिए मुझे संदेह है कि इनमें से किसी भी प्रतिगमन को संबोधित किया जाएगा।

और यह ठीक काम करता है, लेकिन मुझे अपने कंटेनर में 3 एमबी या उससे भी ज्यादा जोड़ने की जरूरत है।

यदि पर्यावरण चर सेट हैं, तो docker slack deploy उन्हें पहले से ही प्रक्षेपित करना चाहिए

डॉकर की तुलना में ऐसा करने में सक्षम होने के कारण।

डॉकर में यह सुविधा कभी नहीं थी; डॉकर कंपोज़ था; डॉकर कंपोज़ और डॉकर स्टैक परिनियोजन _file format_ साझा करते हैं, लेकिन आवश्यक रूप से सॉफ़्टवेयर के सभी व्यवहारों को साझा नहीं करते हैं।

K8s समर्थन की घोषणा के बाद से झुंड मोड में जाने का बहुत कम प्रयास है

कंपोज़ फ़ाइल हैंडलिंग सभी क्लाइंट साइड पर किया जाता है, और k8s और swarmkit दोनों के लिए उपयोग किया जाता है, इसलिए इस क्षेत्र में कुछ भी धीमा नहीं होता है, इसके अलावा "किसी भी समय हम केवल इतना ही कर सकते हैं"

उस सुविधा की प्रतीक्षा करने वालों के लिए; आगामी रिलीज़ में docker stack deploy के लिए कई कंपोज़ फ़ाइलों का समर्थन होगा, इसलिए यदि आप वर्तमान में docker कंपोज़ में उस सुविधा का उपयोग कर रहे हैं: आगामी docker रिलीज़ भी इसका समर्थन करेगी

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

मैं सराहना कर सकता हूं कि वे अलग हैं, लेकिन एक ही फ़ाइल प्रारूप का उपयोग करते हैं, लेकिन इससे वास्तव में अधिक भ्रम होता है, और संभावित रूप से निराश होता है, जब उपयोगकर्ताओं को पता चलता है कि उन्हें झुंड का उपयोग करने के लिए सुविधाओं का व्यापार करना है। वह और तथ्य यह है कि डीएबी फाइलें अभी भी प्रयोगात्मक के रूप में सूचीबद्ध की जा रही हैं। दुर्भाग्य से, हमने एक बड़ी परियोजना में झुंड-मोड का उपयोग करने का निर्णय लिया है, या मुझे परवाह भी नहीं है। सौभाग्य से, हम फिर से वह गलती नहीं करेंगे।

[संपादित करें]

यदि पर्यावरण चर सेट हैं, तो डॉकटर स्लैक परिनियोजन को पहले से ही उन्हें प्रक्षेपित करना चाहिए

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

_EDIT: मुझे आशा है कि यह पोस्ट आक्रामक रूप से नहीं आएगी। मुझे डॉकर स्टैक अवधारणा पसंद है और मुझे लगता है कि पूरा डॉकर सूट बहुत अच्छी तरह से समर्थित है। ऐसा लगता है कि डॉकर (संगठन) वर्तमान में अपने उत्पादों को उसी तरह नहीं देखता है जैसे उपयोगकर्ता देखते हैं, जो दुर्भाग्यपूर्ण है और ऐसा लगता है कि मैंने कंपोज़ और स्टैक का उपयोग करने में अधिकांश मुद्दों का कारण बना दिया है।_

डॉकर में यह सुविधा कभी नहीं थी; डॉकर कंपोज़ था; डॉकर कंपोज़ और डॉकर स्टैक परिनियोजन फ़ाइल स्वरूप को साझा करते हैं लेकिन सॉफ़्टवेयर के सभी व्यवहारों को अनिवार्य रूप से नहीं।

मुझे ऐसा लगता है कि यह कथन डॉकर के डेवलपर्स और उपयोगकर्ताओं के इन उत्पादों को देखने के तरीके के बीच एक मौलिक डिस्कनेक्ट को प्रकट करता है। एक उपयोगकर्ता के रूप में, चाहे मैं डॉकर इंजन, डॉकर कंपोज़ या डॉकर झुंड के साथ काम कर रहा हूं, यह सब डॉकर है और जहां तक ​​संभव हो लगातार व्यवहार करना चाहिए।

इन उत्पादों के उद्देश्य के बारे में मेरी समझ है:

• डॉकर इंजन अलग-अलग कंटेनर बनाने और चलाने के लिए है
• डॉकर कंपोज़ विकास में कंटेनरों का एक सूट चलाने के लिए है
• डॉकर स्टैक उत्पादन के लिए कंटेनरों को तैनात करने के लिए है

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

मैं यह नहीं कहूंगा कि रचना देव के लिए है और ठेस के लिए ढेर, जरूरी है। मैं एक बहु-कंटेनर एप्लिकेशन या "सिस्टम" के लिए रचना के रूप में देखता हूं और शेड्यूलर/ऑर्केस्ट्रेटर के रूप में झुंड-मोड का उपयोग करके बहु-होस्ट परिनियोजन के लिए ढेर करता हूं। अन्यथा, आपकी टिप्पणी 100% हाजिर है। मैं भी निराश हूं (यदि यह मेरी अन्य टिप्पणियों से स्पष्ट नहीं था) कि डेवलपर्स और उपयोगकर्ताओं के बीच एक डिस्कनेक्ट है कि उत्पाद का उपयोग कैसे किया जा रहा है।

ओह वाह। मैं एक बड़ी परियोजना के लिए डॉकर झुंड का मूल्यांकन करते समय भी भ्रम और दर्द में शामिल हो गया।
रहस्य सभी मजेदार और खेल हैं, बस सभी बाहरी डॉकटर छवियां फाइलों से रहस्यों को पढ़ने का समर्थन नहीं करती हैं। मैं उनमें से प्रत्येक के लिए संशोधित नहीं करना चाहता और एक कस्टम छवि नहीं रखना चाहता। मेरी परियोजनाओं के लिए उनका उपयोग कर सकते हैं, हां, लेकिन बाहरी परियोजनाओं के लिए नहीं जाना होगा।
तो वह env चर छोड़ देता है। लेकिन हे, वे कंपोज़ से स्टैक तक अलग तरह से व्यवहार करते हैं! मेरे आश्चर्य की कल्पना कीजिए जब मैंने देखा कि वे वास्तव में काम नहीं करते हैं।
बिना एनवी सपोर्ट के डॉकटर स्टैक कैसे संभव है? मेरी राय में सबसे अच्छा होगा --env-file=dev.env , इसलिए यह अन्य एनवी फाइलों में हस्तक्षेप नहीं करेगा ... लेकिन इसके लिए समर्थन भयानक है। मुझे दुर्भाग्य से k8s पर वापस जाना चाहिए, क्योंकि स्टैक शुरू से ही गायब है, उत्पादन के दौरान एक भयानक विकल्प साबित हो सकता है, कौन जानता है कि कितनी अन्य चीजें गायब होंगी।

दो साल हो गए हैं और हम अब भी ऐसे ही हैं... मैं असभ्य नहीं दिखना चाहता, लेकिन चलो! यह docker-compose से कुछ कोड का पुन: उपयोग करने की बात है!

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

मैं प्रोजेक्ट रूट से निर्दिष्ट पथ लोड करने के लिए env_file का उपयोग करता हूं, लेकिन मेरी लिखें फ़ाइल एक अलग उपनिर्देशिका में है। docker-compose के साथ लॉन्च करने के लिए, मैं बस --project-directory का उपयोग करता हूं। -f पथ/से/docker-compose.yml

docker stack मुझे प्रोजेक्ट-निर्देशिका निर्दिष्ट करने की अनुमति नहीं देता है, जिससे मेरी सभी env_files लोड होने में विफल हो जाती हैं।

Env_file को "../../path/to/envrc" में बदलना docker-compose के साथ काम नहीं करता है, क्योंकि ये फ़ाइलें प्रोजेक्ट रूट dir के अंदर होनी चाहिए

+1

+1

+1 यह वास्तव में उपयोगी होगा। वास्तव में कोई कमी न देखें।

यह अविश्वसनीय रूप से गूंगा है कि डॉकर अभी तक इसका समर्थन नहीं करता है।

+1 @ जोआओ-फिडाल्गो यह निश्चित रूप से है।

+1

बस उसी चीज़ में भाग गया जैसे हम झुंड की कोशिश कर रहे हैं। मैंने सभी संदेशों को विभिन्न धागों में पढ़ा है और मैं बेहद निराश हूं। IMO, कुछ बहुत अच्छे बिंदु और मजबूत तर्क @ntwrkguru और अन्य द्वारा दिए गए थे। मुझे आशा है कि हम इस सुविधा को प्राप्त करने के लिए उन पर विचार कर सकते हैं; हैक्स इसे नहीं काटेंगे।

.env फ़ाइल

export MYSQL_USER=user

source .env && docker stack deploy

यह बैश के लिए docker-compose up के साथ भी काम करेगा

.env फ़ाइल

export MYSQL_USER=user

source .env && docker stack deploy

यह docker-compose up के साथ भी काम करेगा

यह केवल बैश के लिए काम करेगा न कि अन्य गोले के लिए।

इसने मुझे पागलों की तरह भ्रमित कर दिया। मेरा ऐप डॉकर-कंपोज़ का उपयोग करके आएगा, लेकिन डॉकर स्टैक परिनियोजन के साथ नहीं। दस्तावेज़ों में कम से कम एक अस्वीकरण प्रमुखता से प्रदर्शित होना चाहिए

लेकिन आईएमओ यह एक बग है, और डॉकर अनुभव को कम कर रहा है।

हमें इस बारे में जवाब चाहिए

लगभग 2 साल और किसी ने इसे नहीं उठाया ... अपनी सांस न रोकें @jorgelimafeitosa

मुझे नहीं लगता कि सीएलआई कभी भी .env समर्थन जोड़ने जा रहा है। docker stack deploy कमांड मूल रूप से डिस्ट्रीब्यूटेड एप्लिकेशन बंडल फाइलों को ध्यान में रखकर बनाया गया था (इसलिए --bundle-file विकल्प)। डीएबी फाइलें डॉकर कंपोज द्वारा docker-compose bundle कमांड के साथ जेनरेट की गई थीं। .env और अन्य लिखें सुविधाओं को docker-compose द्वारा नियंत्रित किया जाएगा, docker stack deploy को पास किए जाने से पहले। docker stack deploy में कंपोज़ फ़ाइलों के लिए प्रत्यक्ष समर्थन हमेशा एक समझौता था।

डीएबी फाइलों का मूल वादा अब डॉकर ऐप में रहता है, जो .env को भी संसाधित नहीं करता है।

मेरे पास मेरे डेवलपर्स docker-compose config का उपयोग डॉकर कंपोज़ प्रोजेक्ट्स को docker stack deploy पर पास करने से पहले प्री-प्रोसेस करने के लिए करते हैं। आप इसे एक पंक्ति में कर सकते हैं:

docker stack deploy -c <(docker-compose config) stack-name-here

इस तरह, .env प्रोसेसिंग सहित सभी डॉकर कंपोज़ सुविधाएँ पूरी तरह से लागू होती हैं।

@kinghuang ने आपके समाधान की कोशिश की, लेकिन काम नहीं किया। "docker-compose config" एक ही निर्देशिका में सही आउटपुट उत्पन्न करता है, लेकिन "docker स्टैक परिनियोजित -c docker-compose.yaml my_stack" .env से वेरिएबल को स्थानापन्न नहीं करेगा। मुझे किसकी याद आ रही है? यह डॉकर संस्करण 18.09.0 है, बिल्ड 4d60db4.

@kinghuang ने आपके समाधान की कोशिश की, लेकिन काम नहीं किया। "docker-compose config" एक ही निर्देशिका में सही आउटपुट उत्पन्न करता है, लेकिन "docker स्टैक परिनियोजन -c docker-compose.yaml my_stack" .env से वेरिएबल को स्थानापन्न नहीं करेगा। मुझे किसकी याद आ रही है? यह डॉकर संस्करण 18.09.0 है, बिल्ड 4d60db4.

डॉकटर स्टैक परिनियोजन-सी <(डॉकर-कंपोज़-एफ डॉकर-कंपोज़-एफआरपीसी-स्वार्म-ट्रैफिक.वाईएमएल कॉन्फिग) ट्रैफिक

@kinghuang

open /dev/fd/63: ऐसी कोई फ़ाइल या निर्देशिका नहीं है

चेतावनी: कुछ सेवाएं (प्रोजेक्ट1, प्रोजेक्ट2) 'तैनाती' कुंजी का उपयोग करती हैं, जिसे अनदेखा कर दिया जाएगा। लिखें 'तैनाती' कॉन्फ़िगरेशन का समर्थन नहीं करता - झुंड में तैनात करने के लिए docker stack deploy का उपयोग करें।

@kinghuang
केवल रूट वातावरण त्रुटि की रिपोर्ट नहीं करेगा।

.env और env_file का समर्थन करना हमेशा परिनियोजन/उत्पादन परिवेश में कोई अर्थ नहीं रखता है। डॉकर झुंड की अन्य सुविधाओं में से किसी के लिए आपको फाइल सिस्टम तक सीधे पहुंच की आवश्यकता नहीं है। तो, उस सिस्टम का एक जिम्मेदार डिजाइनर/ऑपरेटर आपको फाइल सिस्टम पर पर्यावरण फाइलों को डंप करने की क्षमता नहीं देना चाहेगा।

सैद्धांतिक रूप से झुंड स्वचालित रूप से पर्यावरण में लोडिंग रहस्यों का समर्थन कर सकता है लेकिन https://github.com/moby/moby/issues/30866#issuecomment -278924983 देखें कि सुरक्षा के लिहाज से यह एक अच्छा विचार क्यों नहीं हो सकता है।

आज आप क्या कर सकते हैं रहस्यों का उपयोग करें और कंटेनर चलने पर उन्हें अपने ऐप के वातावरण में लोड करें। यह आपको इस बात पर नियंत्रण देता है कि गुप्त पर्यावरण मूल्यों को कहाँ देखा जा सकता है।

+1
डॉकर स्टैक परिनियोजन को वास्तव में --env-file का समर्थन करना चाहिए।
मैं विकास/परीक्षण/उत्पादन वातावरण के लिए अलग-अलग ढेर को तैनात करने के लिए उसी .yml फ़ाइल का पुन: उपयोग करने के लिए संघर्ष कर रहा हूं और मैं स्टैक को तैनात करने से पहले पर्यावरण चर के कुछ निर्यात/सोर्सिंग से निपटना नहीं चाहता हूं। यह बहुत त्रुटि-प्रवण है (और एक ** में दर्द भी हर बार सटीक आदेशों को याद रखने के लिए)।
मेरे विशेष मामले में मैं उदाहरण के लिए प्रति पर्यावरण अलग-अलग इंडेक्स-नाम (लोचदार खोज) सेट करना चाहता हूं - लेकिन शेष कॉन्फ़िगरेशन वही रहता है। इसका "रहस्य" से कोई लेना-देना नहीं है जैसा कि पहले की पोस्ट में बताया गया है।
उपरोक्त टिप्पणी इतिहास के आधार पर डॉकर स्टैक परिनियोजन के लिए --env-file की वास्तविक आवश्यकता प्रतीत होती है, लेकिन दुख की बात है कि डॉकर डेवलपर्स इसे नहीं देख रहे हैं।

अपने झुंड के माहौल में मैं कुछ कामकाज पर बस गया:

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

बस अपने docker-compose.yml में .env फ़ाइल निर्दिष्ट करें और यह काम करता है:

env_file:
  - .env

देखें https://stackoverflow.com/questions/44694640/docker-swarm-with-image-versions-externalized-to-env-file

डॉकर को कॉल करने से पहले .env फ़ाइल को पार्स करने के लिए विंडोज़ पर उपयोग करने के लिए पावरहेल में एक काम:

स्विच -रेगेक्स -फाइल "./.env" { "^\s ([^#].+?)\s =\s (. )" { $name,$value = $matches[1..2]; सेट-आइटम "env:$name" $value}}

.ini फ़ाइलों को पार्स करने से बहुत प्रेरित: https://stackoverflow.com/questions/417798/ini-file-parsing-in-powershell

एक और समाधान है: set -a && . .env && set +a && docker stack deploy... ।

यह मज़ाकीय है। मैंने इसे काम पर लाने की कोशिश में सारा दिन बिताया। डॉक्स में कहीं न कहीं एक अस्वीकरण की आवश्यकता है कि .env docker stack कमांड द्वारा नहीं पढ़ा जाता है।

@cjancsar वे करते हैं। दस्तावेज़ीकरण कहता है:

महत्वपूर्ण: .env फ़ाइल सुविधा केवल तभी काम करती है जब आप docker-compose up कमांड का उपयोग करते हैं और docker स्टैक परिनियोजन के साथ काम नहीं करते हैं

दिलचस्पी से बाहर। झुंड मोड में लोग वर्तमान में क्या करते हैं, और वे अपनी नई निर्मित डॉकटर छवि को अपडेट करना चाहते हैं, उदाहरण के लिए ap plication:v1 to ap plication:v2 , वही सेवा (और कुछ नहीं बदला)?

यही कारण है कि मैं इस मुद्दे पर आया हूं। इसलिए मुझे दिलचस्पी है।

वर्तमान में डॉकटर-कंपोज़ में, छवि संस्करण को अपडेट करने के लिए स्रोत-नियंत्रण अनट्रैक की गई फ़ाइल . env के साथ इंटरैक्ट करने के लिए ऑटोमेशन प्राप्त करना तुच्छ है, फिर docker-compose up -d

अक्सर मैं 'स्टेजिंग' तैनाती (पर्याप्त परीक्षण चक्रों के बाद वास्तविक रिलीज के लिए उपयोग किए जाने वाले गिट टैग) के लिए डॉकर छवि संस्करण के रूप में प्रतिबद्ध शा का उपयोग करता हूं, इसलिए स्रोत नियंत्रण में नया छवि संस्करण करना वास्तव में संभव नहीं है।

क्या वर्कअराउंड के रूप में एक डॉकर रहस्य (भले ही यह वास्तव में एक रहस्य नहीं है) को अपडेट करना संभव है? क्या लोग यही करते हैं, या फिर कुछ और किया जाता है।

मैं इस मुद्दे के भविष्य के आगंतुकों के लिए पूछ रहा हूं, ताकि वे वास्तव में वर्तमान सर्वोत्तम अभ्यास के साथ आ सकें, क्योंकि वे जिस कार्यक्षमता की तलाश कर रहे थे वह (अभी तक?) मौजूद नहीं है।

नमस्ते, मैं सीआई/सीडी पाइपलाइनों में उपयोग के लिए स्टैक परिनियोजन में व्यस्त हूं, एक .env फ़ाइल का उपयोग करने में सक्षम होना बहुत उपयोगी होगा, इस पर कोई प्रतिक्रिया क्या यह विकल्प किसी भी स्तर पर पेश किया जाएगा?

ऐसा लगता है कि आधिकारिक सिफारिश, वास्तव में, एक गुप्त पाठ फ़ाइल से इस प्रकार के चर को पढ़ने में सहायता के लिए आपके छवि कोड को माइग्रेट करने के लिए है ± गैर-स्टैक/झुंड पीछे संगतता के लिए पर्यावरण चर से इन्हें पढ़ने की क्षमता बनाए रखना।

उदाहरण प्रति पाठ फ़ाइल में एक रहस्य का उपयोग करता है, जो पुरानी .env फ़ाइल को पार्स करने से बचाता है।

https://docs.docker.com/engine/swarm/secrets/#use -secrets-in-compose पर प्रलेखन से स्पष्ट:

services:
   db:
     image: mysql:latest
     environment:
       MYSQL_ROOT_PASSWORD_FILE: /run/secrets/db_root_password
       MYSQL_DATABASE: wordpress
       MYSQL_USER: wordpress
       MYSQL_PASSWORD_FILE: /run/secrets/db_password
     secrets:
       - db_root_password
       - db_password

secrets:
   db_password:
     file: db_password.txt
   db_root_password:
     file: db_root_password.txt

विलाप

यह दस्तावेज़ीकरण में और अधिक स्पष्ट होना चाहिए। हालांकि यह कहा जाता है कि .env प्रति @lengxuehx पर परिवर्तनीय प्रतिस्थापन अनुभाग में समर्थित नहीं है, यह उल्लेख नहीं किया गया है कि env_file को स्टैक परिनियोजन के लिए अनदेखा किया जाता है।

मैं पुष्टि कर सकता हूं कि @kinghuang द्वारा प्रस्तावित समाधान काम करता है और किसी की तरह तैनाती कुंजी को बाहर नहीं करता है ।

docker stack deploy -c <(docker-compose config) stack-name-here

यह दस्तावेज़ीकरण में और अधिक स्पष्ट होना चाहिए। हालांकि यह कहा जाता है कि .env प्रति @lengxuehx पर परिवर्तनीय प्रतिस्थापन अनुभाग में समर्थित नहीं है, यह उल्लेख नहीं किया गया है कि env_file को स्टैक परिनियोजन के लिए अनदेखा किया जाता है।

मैं पुष्टि कर सकता हूं कि env_file का उपयोग किया जाता है और स्टैक कमांड को तैनात करने के लिए काम कर रहा है, ठीक उसी तरह जैसे docker कंपोज़ करता है।

docker version
Client: Docker Engine - Community
 Version:           19.03.4
 API version:       1.40
 Go version:        go1.12.10
 Git commit:        9013bf5
 Built:             Thu Oct 17 23:44:48 2019
 OS/Arch:           windows/amd64
 Experimental:      false

Server: Docker Engine - Community
 Engine:
  Version:          19.03.4
  API version:      1.40 (minimum version 1.12)
  Go version:       go1.12.10
  Git commit:       9013bf5
  Built:            Thu Oct 17 23:50:38 2019
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          v1.2.10
  GitCommit:        b34a5c8af56e510852c35414db4c1f4fa6172339
 runc:
  Version:          1.0.0-rc8+dev
  GitCommit:        3e425f80a8c931f88e6d94a8c831b9d5aa481657
 docker-init:
  Version:          0.18.0
  GitCommit:        fec3683

संक्षेप में, मेरे जैसे लोगों के लिए, जिन्होंने इसे अब तक पढ़ा है:

• docker stack deploy "परिवर्तनीय प्रतिस्थापन" का समर्थन करता है लेकिन आपको किसी तरह से .env फ़ाइल से पर्यावरण चर सेट करने की आवश्यकता है। ऊपर कई विकल्पों की व्याख्या की गई है। सबसे अच्छे वर्कअराउंड में से एक प्री-प्रोसेसर के रूप में docker-compose config का उपयोग कर रहा है।
  तो आप docker stack deploy -c <(docker-compose config) STACK_NAME के साथ अपना स्टैक बना सकते हैं।
• हालांकि डॉकर ने कॉन्फिग और सीक्रेट क्षमताओं को पेश किया, उनके पास उनके उपयोग के मामले हैं लेकिन वे "वैरिएबल सबस्टीट्यूशन" के समान काम नहीं करेंगे।
• env_file docker-compose.yml $ पैरामीटर पर्यावरण चर को बनाए गए कंटेनर में सेट करेगा, न कि docker-compose.yml फ़ाइल पर (और इसलिए इसे "के विकल्प के रूप में उपयोग नहीं किया जा सकता है" परिवर्तनीय प्रतिस्थापन")।

अद्यतन:

मुझे @thaJeztah द्वारा ठीक किया गया था।

डॉकर डॉक स्टैक परिनियोजन का उपयोग करके परिवर्तनीय प्रतिस्थापन का समर्थन नहीं करता है, और प्रस्तावित समाधान में से कोई भी काम नहीं करता है।

docker stack deploy परिवर्तनीय प्रतिस्थापन का समर्थन करता है, लेकिन .env फ़ाइल का मूल्यांकन नहीं करता है; नीचे दिए गए उदाहरण में, HELLO_VERSION को linux पर सेट किया गया है, और सेवा hello-world:linux टैग का उपयोग करेगी (डिफ़ॉल्ट hello-world:latest के बजाय)

HELLO_VERSION=linux docker stack deploy -c docker-compose.yml mystack
Creating network mystack_default
Creating service mystack_hello

docker service inspect --format '{{.Spec.TaskTemplate.ContainerSpec.Image}}' mystack_hello
hello-world:linux<strong i="14">@sha256</strong>:d073a5775c0b99d653c413161a8ed0e9685061afe697931d30eddf6afeef40f6

कहा जा रहा है, आप अभी भी अपने docker-compose.yml फ़ाइल में env_file पैरामीटर का उपयोग करके पर्यावरण चर का उपयोग कर सकते हैं

env_file एक अलग उद्देश्य को पूरा करता है (और docker run --env-file के बराबर है); env_file विकल्प निर्दिष्ट करता है कि बनाए गए कंटेनर पर कौन सा env-vars सेट करना है, लेकिन इसका उपयोग कंपोज़ फ़ाइल में ही नहीं किया जाता है (और स्टैक को परिनियोजित करने से पहले कंपोज़ फ़ाइल में चर को प्रतिस्थापित करने के लिए उपयोग नहीं किया जाता है)।

मुझे डॉकर-कंपोज़ और डॉकर स्टैक के बीच अन्य मामूली अंतरों के साथ भी यही समस्या थी।
मैंने पाइप के साथ इस मुद्दे को संभालने के लिए https://github.com/egyel/dcsh स्क्रिप्ट/टूल बनाना समाप्त कर दिया।

सभी को नमस्कार, इससे मुझे अपने डॉकटर-कंपोज़ में env_file डालने में मदद मिली:

env_file: /path/to/env/file
नहीं

env_file:
  - /path/to/env/file

मैंने इसे किसी अन्य पोस्ट से देखा है और मैं केवल अनुमान लगा सकता हूं कि यह क्यों काम करता है (आपकी अटकलों के समान) लेकिन हमें इस बात की पुष्टि की आवश्यकता है कि यह डॉकर के रूप में स्पष्ट रूप से उल्लिखित डॉकर के रूप में क्यों काम कर रहा है कि env_file काम नहीं करता है।

मेरी समझ यह है कि एनवी फाइलों का उपयोग प्लेसहोल्डर्स को फिल करने के लिए नहीं किया जा सकता है
docker-stack.yml फ़ाइल लेकिन वे अभी भी कंटेनरों को प्रदान की जा सकती हैं।
ध्यान दें कि आप जो कर रहे हैं वह आपको छवि का नाम सेट करने की अनुमति नहीं देता है
env फ़ाइल उदाहरण के लिए।

सूर्य पर, 17 मई, 2020, 06:08 raphyphy [email protected] ने लिखा:

[छवि: छवि]
https://user-images.githubusercontent.com/30310576/82135555-a1e4be00-9836-11ea-9df4-a1b82e014b0e.png
सभी को नमस्कार, इससे मुझे अपने डॉकटर-कंपोज़ में env_file डालने में मदद मिली:

env_file: /path/to/env/file
नहीं

env_file:

• /पथ/से/env/फ़ाइल

मैंने इसे किसी अन्य पोस्ट से देखा है और मैं केवल अनुमान लगा सकता हूं कि यह क्यों काम करता है
(आपकी अटकलों के समान) लेकिन हमें इस बात की पुष्टि की आवश्यकता है कि ऐसा क्यों है
डॉकर के रूप में काम करते हुए स्पष्ट रूप से दस्तावेज़ में उल्लेख किया गया है कि env_file नहीं करता है
काम।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने टिप्पणी की थी।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/moby/moby/issues/29133#issuecomment-629740002 , या
सदस्यता समाप्त
https://github.com/notifications/unsubscribe-auth/ABHLQMCARDQGJQIBWCQKAYLRR5PMHANCNFSM4CYRHCTA
.

ऊपर उल्लिखित डॉकर-कंपोज़ समाधान:

docker stack deploy -c <(docker-compose config) stack-name-here

इसका नुकसान है (मेरे लिए) कि .env फाइलें और विशेष रूप से, docker-compose.override.yml फाइलें आम तौर पर मेरे विकास पर्यावरण का अधिक हिस्सा हैं। मैं वास्तव में उन लोगों को नहीं चाहता जो उत्पादन में तैनात करते समय लाए।

मेरे पास एक अलग docker-compose-production.yml था जिसमें मैंने चीजों को सावधानीपूर्वक नियंत्रित किया, भले ही इसमें कुछ दोहराव शामिल हो।

मुझे नहीं लगता कि सीएलआई कभी भी .env समर्थन जोड़ने वाला है। docker stack deploy कमांड मूल रूप से डिस्ट्रीब्यूटेड एप्लिकेशन बंडल फाइलों को ध्यान में रखकर बनाया गया था (इसलिए --bundle-file विकल्प)। डीएबी फाइलें डॉकर कंपोज द्वारा docker-compose bundle कमांड के साथ जेनरेट की गई थीं। .env और अन्य लिखें सुविधाओं को docker-compose द्वारा नियंत्रित किया जाएगा, docker stack deploy को पास किए जाने से पहले। docker stack deploy में कंपोज़ फ़ाइलों के लिए प्रत्यक्ष समर्थन हमेशा एक समझौता था।

डीएबी फाइलों का मूल वादा अब डॉकर ऐप में रहता है, जो .env को भी संसाधित नहीं करता है।

मेरे पास मेरे डेवलपर्स docker-compose config का उपयोग डॉकर कंपोज़ प्रोजेक्ट्स को docker stack deploy पर पास करने से पहले प्री-प्रोसेस करने के लिए करते हैं। आप इसे एक पंक्ति में कर सकते हैं:

docker stack deploy -c <(docker-compose config) stack-name-here

इस तरह, .env प्रोसेसिंग सहित सभी डॉकर कंपोज़ सुविधाएँ पूरी तरह से लागू होती हैं।

यह एक आकर्षण की तरह काम करता है, ध्यान रखें कि अगर आपकी कंपोज़ फ़ाइल में "docker-compose.yml" नाम नहीं है, तो आपके कमांड में वास्तविक कंपोज़ फ़ाइल नाम शामिल होना चाहिए।

डॉकर स्टैक परिनियोजन-सी <(डॉकर-लिखें-एफ कस्टम-कंपोज़-FILENAME.yml कॉन्फ़िगरेशन) कस्टम-स्टैक

<(docker-compose -f CUSTOM-COMPOSE-FILENAME.yml config हैक से सावधान !!! docker-compose config और docker-compose -f myfile.yml config का आउटपुट जरूरी नहीं कि वही हो! उत्तरार्द्ध कभी-कभी अतिरिक्त उद्धरणों में env चर लपेटता है, इसलिए आउटपुट गलत होगा!

उदाहरण:

environment:
  SERVER_URL: '"xxx"'

के बजाए

environment:
  SERVER_URL: xxx

क्या इस मुद्दे को पहले से कहीं ट्रैक किया गया है?