Compose: चलाने के बाद एक कमांड निष्पादित करें

मुझे लगता है कि ये डॉकरफाइल में कदम होना चाहिए

FROM mongo:3.0.2
ADD data/mongodb/dumps/latest /data/mongodb/dumps/latest
RUN mongorestore -d database /data/mongodb/dumps/latest/database

इस तरह से जब आप पुनर्निर्माण करते हैं तो आप इसे कैश भी करवाते हैं।

साभार @dnephin
बेशक मैं एक डॉकफ़िल बना सकता हूं और इसे चित्रों के बजाय बिल्ड में उपयोग कर सकता हूं, या मैं डॉक निष्पादित का उपयोग कर सकता हूं।
MongoDB सिर्फ एक उदाहरण है, आप इस उदाहरण को mysql और खाता निर्माण के साथ, या rabbitmq और कतार आदि के साथ देख सकते हैं।

onrun ऑर्केस्ट्रेशन पर लचीलेपन की अनुमति देगा, कंपोज़ ऑनरून सूची को पढ़ेगा और प्रत्येक आइटम पर docker exec ।

मुद्दा यह है कि docker exec docker-compose.yml में कमांड्स डालना अनावश्यक है जब आप या तो डॉकफ़िले में या कंटेनर के स्टार्टअप स्क्रिप्ट में कर सकते हैं, ये दोनों आपके कंटेनर को और भी उपयोगी बना देंगे जब नोट नहीं होगा कम्पोज के साथ चलाया जा रहा है।

वैकल्पिक रूप से, अपने ऐप को शेल स्क्रिप्ट या मेकफाइल के साथ शुरू करें जो उपयुक्त docker और docker-compose कमांड चलाता है।

जब तक यह उन दोनों में से कोई भी महत्वपूर्ण कार्य नहीं करेगा, तब तक कार्यक्षमता को जोड़ने के लायक नहीं है, और मुझे नहीं लगता कि यह आपके द्वारा उपयोग किए जाने वाले मामलों के लिए है।

इसलिए, मेरे डॉकटर को प्रबंधित करने के लिए, आप मुझे स्क्रिप्ट या मेकफाइल का उपयोग करने का सुझाव देंगे। तो कम्पोज क्यों बनाया गया
? हम स्क्रिप्ट के साथ कंटेनर, स्केल आदि का प्रबंधन कर सकते हैं || कामचोर

ठीक है, मैं इस उदाहरण को लेता हूं, यह वही है जो मैंने सीआई प्रक्रिया में अपने आवेदन परीक्षण वातावरण को तैनात करने के लिए उपयोग किया था।

rabbitmq:
    image: rabbitmq:3.5.1-management
    environment:
        RABBITMQ_NODENAME: rabbit
    hostname: rabbitmq
    domainname: domain.lan
    volumes:
        - /data/rabbitmq/db:/var/lib/rabbitmq
    ports:
        - "5672:5672" 
        - "15672:15672"
        - "25672:25672"
        - "4369:4369"

mongodb:
    image: mongo:3.0.2
    hostname: mongo
    domainname: domain.lan
    volumes:
        - /data/mongodb:/data
    ports:
        - "27017:27017" 

appmaster:
    image: appmaster
    hostname: master
    domainname: domain.lan
    environment:
        ...
    ports:
        - "80:80" 
        - "8080:8080"
    links:
        - mongodb
        - rabbitmq

celery:
    image: celery
    hostname: celery
    domainname: domain.lan
    environment:
        ...
    links:
        - rabbitmq

कंटेनर शुरू होने के बाद, मुझे मनगोडब का प्रावधान करना चाहिए, खरगोशों में कतार और खाते का प्रबंधन करना चाहिए

आज मैं जो कर रहा हूं वह एक स्क्रिप्ट है:

#!/bin/bash
PROJECT=appmaster
docker-compose -f appmaster.yml -p appmaster up -d
docker exec appmaster_rabbitmq_1 rabbitmqctl add_user user password
docker exec appmaster_rabbitmq_1 rabbitmqctl add_vhost rabbitmq.domain.lan
docker exec appmaster_rabbitmq_1 rabbitmqctl set_permissions -p rabbitmq.domain.lan password ".*" ".*" ".*"
docker exec appmaster_mongodb_1 mongodump --host mongo-prd.domain.lan --port 27017 --out /data/mongodb/dumps/latest
docker exec appmaster_mongodb_1 mongorestore -d database /data/mongodb/dumps/latest/database

onrun निर्देश के साथ मैं सीधे docker-compose -f appmaster.yml -p appmaster up -d बना सकता हूं
और yml फ़ाइल अधिक पठनीय हो जाती है

rabbitmq:
    ...
    onrun:
        - rabbitmqctl add_user user password
        - rabbitmqctl add_vhost rabbitmq.domain.lan
        - rabbitmqctl set_permissions -p rabbitmq.domain.lan password ".*" ".*" ".*"

mongodb:
    ...
    onrun:
        - mongodump --host mongo-prd.domain.lan --port 27017 --out /data/mongodb/dumps/latest
        - mongorestore -d database /data/mongodb/dumps/latest/database

यह बल्कि उपयोगी होगा और एक उपयोग के मामले को हल करता है।

: +1:

यह एक सीडी पाइपलाइन के हिस्से के रूप में gated परीक्षणों के लिए docker-compose अधिक व्यवहार्य बना देगा

: +1:

यह # 877, # 1341, # 468 (और कुछ अन्य) की नकल है।

मुझे लगता है कि इसका समर्थन करने का सही तरीका # 1510 है और जब आप जिस इवेंट को चाहते हैं उसे हिट करने के लिए बाहरी उपकरणों को संचालन करने की अनुमति देते हैं।

नकल के रूप में बंद करना

यह बहुत उपयोगी होगा। मुझे समझ में नहीं आता कि "ओह आप इसे एक बैश स्क्रिप्ट के साथ कर सकते हैं"। बेशक हम इसे बैश स्क्रिप्ट के साथ कर सकते थे। मैं वह सब कुछ भी कर सकता था जो डॉकर-रचना बैश स्क्रिप्ट के साथ करता है। लेकिन मुद्दा यह है कि एक एकल YAML फाइल है जो आपके परीक्षण वातावरण को नियंत्रित करती है और इसे एक सरल docker-compose up कमांड के साथ मिलाया जा सकता है।

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

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

@आनंद निष्पक्ष होने के लिए, एक docker exec निष्पादित करने में सक्षम होने के नाते एक्स-प्लेट अपूर्णता को स्वचालित रूप से लागू नहीं करता है।

माफी - मैंने होस्ट मशीन पर कमांड निष्पादित करने के बारे में इस मुद्दे को गलत बताया है। फिर भी, मेरा पहला बिंदु खड़ा है।

मुझे आपकी बात समझ में आती है @aanand यह मेरे लिए गुंजाइश से बाहर नहीं लगता है, क्योंकि पहले से ही docker-compose बहुत कुछ ऐसा ही करता है जो नियमित docker इंजन पहले से ही करता है, जैसे command , expose , ports , build , आदि exec कार्यक्षमता को जोड़ने से docker-compose अधिक शक्ति जुड़ जाएगी, जिससे यह सेटिंग के लिए एक सही स्टॉप शॉप बन जाएगी। देव वातावरण।

@ देवानंद कई

तो आप बस कुछ निष्पादन चलाने के लिए एक मेकफिल या बैशस्क्रिप्ट का सुझाव देते हैं https://github.com/docker/compose/issues/1809#issuecomment -128073224

जो मैं मूल रूप से सुझाता हूं वह onrun (या oncreate) होता है जो आलस्य रखता है। बस पहली शुरुआत में दौड़ें। यदि कंटेनर को रोका या रोका गया है, तो नई शुरुआत onrun (या oncreate) नहीं चलेगी

अंत में, मेरे गिट रिपॉजिटरी में मेरे पास एक कंपोज़ फाइल, एक डॉकफाइल और एक मेम्फाइल इम्पोटेन्सी मैनेजमेंट होगा (मेकफाइल स्टेटफाइल बना सकता है)। प्रतिभाशाली!

command , expose , आदि और exec बीच एक बड़ा अंतर है। पहले समूह में कंटेनर विकल्प हैं, exec एक कमांड / एपीआई समापन बिंदु है। यह एक अलग फ़ंक्शन है, कंटेनर फ़ंक्शन बनाने के लिए विकल्प नहीं।

कम्पोज़ (https://github.com/docker/compose/issues/1809#issuecomment-128059030) के साथ इसे पूरा करने के लिए पहले से ही कुछ तरीके हैं। onrun पहले से मौजूद है। यह command ।

डेटाबेस से डेटा डंपिंग या लोड करने की विशिष्ट समस्या के बारे में, वे अधिक "वर्कफ़्लो" या "बिल्ड ऑटोमेशन" प्रकार के कार्य हैं, जो आम तौर पर मेकफाइल में किए जाते हैं। मैं वास्तव में उन उपयोग के मामलों के लिए एक टूल का प्रोटोटाइप बना रहा हूं जिसे डोबी कहा जाता है, जो कंटेनरों में सभी कार्यों को चलाता है। यह कंपोज़ के साथ भी बहुत अच्छी तरह से एकीकृत करता है। यदि आप Makefiles से खुश नहीं हैं, तो आप इसे आज़माने में दिलचस्पी ले सकते हैं। मैं एक डेटाबेस init / load use केस के उदाहरण पर काम कर रहा हूँ।

@dnephin onrun एक साधारण command क्योंकि आप सिर्फ बेकार याद करते हैं।

आइए कल्पना करते हैं। कंटेनर निर्माण पर create और फिर कभी निष्पादित नहीं किया जाएगा (डंप और पुनर्स्थापित करें)।

exec:
    create:
        - echo baby
    destroy:
        - echo keny
    start:
        - echo start
    stop:
        - echo bye

यदि आपको और उदाहरणों की आवश्यकता है:

• इस मुद्दे के साथ एक cmd फ़ाइल बनाएं https://github.com/LarryEitel/phpdock/blob/master/dc.cmd -> juste compose up + exec
• यह व्यक्ति इस https://stackoverflow.com/questions/29303904/docker-compose-initialize-vs-run को हल करने के लिए एक 'ट्रॉवेल' का उपयोग करेगा

डॉबी के लिए धन्यवाद, लेकिन अगर आपको रचना को बढ़ाने के लिए एक उपकरण बनाने की आवश्यकता है, तो रचना खराब है और अधिक शक्तिशाली टूल का उपयोग करना बेहतर है।

लेकिन अगर आपको रचना को बढ़ाने के लिए एक उपकरण बनाने की आवश्यकता है, तो रचना खराब है और अधिक शक्तिशाली उपकरण का उपयोग करना बेहतर है।

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

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

वाह मुझे लगता है कि हम सबसे खराब विश्वास पर पहुंच गए।

• तो कोड और क्यूई संदर्भ में निष्पादन क्यों है? https://docs.docker.com/compose/reference/exec/ ?
• मुझे लगता है कि यह एक लंबा समय है कि doix यूनिक्स दर्शन का सम्मान नहीं करता है https://coreos.com/blog/rocket

दुर्भाग्य से, एक सरल पुन: प्रयोज्य घटक यह नहीं है कि चीजें कैसे खेल रही हैं। डॉकर अब क्लाउड सर्वर लॉन्च करने के लिए उपकरण बना रहा है, क्लस्टरिंग के लिए सिस्टम, और कार्यों की एक विस्तृत श्रृंखला: छवियां बनाना, छवियां चलाना, अपलोड करना, डाउनलोड करना, और अंततः ओवरले नेटवर्किंग, सभी आपके सर्वर पर मूल रूप से चल रहे एक अखंड द्विआधारी में संकलित हैं। । मानक कंटेनर घोषणापत्र को हटा दिया गया था। हमें डॉकटर कंटेनरों के बारे में बात करना बंद कर देना चाहिए, और डॉकर प्लेटफॉर्म के बारे में बात करना शुरू कर देना चाहिए। यह सरल रचना योग्य बिल्डिंग ब्लॉक नहीं बन रहा है, जिसकी हमने कल्पना की थी।

इसलिए आप इस बात की गारंटी दे सकते हैं कि हम यूनिक्स के दर्शन को बनाए रखने के लिए गो डॉक में लिखे गए "डूकर कंपोज़" को कभी अंदर नहीं देखेंगे? https://www.orchardup.com/blog/orchard-is-joining-docker

उस मूल लक्ष्य की ओर बढ़ते रहने के लिए, हम डॉकर से जुड़ रहे हैं। अन्य बातों के अलावा, हम Docker को आपके द्वारा देखे गए सर्वश्रेष्ठ विकास अनुभव बनाने के लिए काम करते रहेंगे - दोनों Fig के साथ, और अंजीर के सर्वश्रेष्ठ भागों को Docker में ही शामिल करके।

तो संक्षेप में कंपोज के साथ जुड़नार लोड करने जैसी चीजें करने का कोई तरीका नहीं है ..? मुझे कहना है कि मैं हैरान हूँ ..
आधिकारिक तरीका यह है कि मेरे उत्पादन कंटेनर में फ़िक्चर लोडिंग को जोड़ा जाए? या मेरी रचना फ़ाइल के चारों ओर एक शेल स्क्रिप्ट लिखने के लिए? बाद के मामले में मैं भी 'डॉक रन' को अंजाम दे सकता था जैसा मैंने पहले किया था।

@ डिडॉर्डियनफ़िश , यदि, किसी तरह, कोई इस तथ्य को

आखिर निर्माण के समय क्या किया जाना चाहिए, यह रनटाइम के समय की जरूरत से अलग हो सकता है, और रनटाइम के दौरान इसकी जरूरत अक्सर तैनाती के माहौल से भिन्न होती है ...

यह मेरी बाहरी लिपियों को बनाने के लिए कष्टप्रद काम है कि क्या कोई कंटेनर बनाने या शुरू करने जा रहा है ...

और वे चीजें हैं जो कुछ जीवन चक्र हुक + आदेश + पर्यावरण चर के साथ मदद कर सकती हैं।

आप इसे सेवा प्रबंधन ढांचे और अन्य ऑर्केस्ट्रेशन टूल में देखते हैं ... डॉकटर-कंपोज में क्यों नहीं?

आपको https://github.com/dnephin/dobi में दिलचस्पी हो सकती है, जो एक ऐसा उपकरण है जिस पर मैं काम कर रहा हूं जो उन वर्कफ़्लोज़ के लिए डिज़ाइन किया गया था।

@dnephin अपने टूल्स के साथ इस मुद्दे को स्पैम

आपकी रचनात्मक टिप्पणी के लिए धन्यवाद। मुझे एहसास नहीं था कि मैंने इस धागे पर 8 महीने पहले ही डोबी का उल्लेख किया था।

यदि आप Makefile / bash से खुश हैं तो यह बहुत अच्छा है! मुझे खुशी है कि आपकी समस्या हल हो गई है।

इस विषय से संबंधित एक टिप्पणी यहाँ जोड़े: https://github.com/docker/compose/issues/1341#issuecomment -295300246

इसके लिए

इसलिए दुखद है कि विकास के लिए कुछ अपवर्तकता के कारण इस मुद्दे को बंद कर दिया गया है: निराश:

डॉक कंपोज़ होने का सबसे बड़ा मूल्य मानकीकरण है

यही तो बात है। अगर हम "।" फ़ाइल को .sh फ़ाइल या जो भी काम कर सकते हैं बिना डॉकर कम्पोज़ के उपयोग के लिख सकते हैं, तो डॉकर कंपोज़ क्यों मौजूद है? : भ्रमित:

हम समझ सकते हैं कि यह एक बड़ा काम है, जैसा कि @ शिन ने कहा:

यह दुर्भाग्य से परियोजना के उस स्तर पर समर्थन के लिए बहुत अधिक बोझ है

:दिल:

लेकिन आप यह नहीं कह सकते कि "एक स्क्रिप्ट बनाएं" का अर्थ है "अरे, यह बहुत कठिन है, हम इसे बनाने नहीं जा रहे हैं"।

यदि ऐसा करना कठिन है, तो बस कहें "आपका विचार दिलचस्प है, और यह कुछ जरूरतों को पूरा करता है, लेकिन ऐसा करना वास्तव में मुश्किल है और हमारे पास इस समय ऐसा करने के लिए संसाधन नहीं हैं ... शायद आप इसे विकसित कर सकते हैं और पूछ सकते हैं। पुल अनुरोध "या ऐसा कुछ: बल्ब:

# 1341 में, मैं "केवल" docker-compose.yml कमांड में लिखने का एक तरीका देखता हूं जैसे nmp install जो कुछ घटनाओं (जैसे कंटेनर निर्माण) से पहले या बाद में चलाया जाएगा, जैसे आप docker exec <container id> npm install साथ करेंगे। उदाहरण के लिए

उदाहरण

मैं एक कस्टम NodeJS छवि है और मैं चलाना चाहते हैं npm install एक साथ यह से बनाए गए, कंटेनर में docker-compose up --build ।

मेरी समस्या यह है: कंटेनर में एप्लिकेशन कोड नहीं जोड़ा गया है, यह docker-compose.yml में परिभाषित वॉल्यूम के साथ इसमें लगाया गया है:

custom-node:
    build: ../my_app-node/
    tty: true
    #command: bash -c "npm install && node"
    volumes:
     - /var/www/my_app:/usr/share/nginx/html/my_app

इसलिए मैं Dockerfile में npm install नहीं चला सकता क्योंकि इसे निर्भरता की जांच करने के लिए एप्लिकेशन कोड की आवश्यकता होती है। मैंने यहाँ व्यवहार का वर्णन किया: http://stackoverflow.com/questions/43498098/what-is-the-order-of-events-in-docker-compose

npm install चलाने के लिए, मुझे वर्कअराउंड, command स्टेटमेंट का उपयोग करना होगा:

command: bash -c "npm install && node"

जो वास्तव में साफ नहीं है: निराश: और जो मैं अल्पाइन संस्करणों पर नहीं चला सकता (उनके पास इसमें बैश स्थापित नहीं है)।

मैंने सोचा था कि डॉकटर कंपोज कंटेनर, ईजी पर निष्पादन कमांड चलाने का एक तरीका प्रदान करेगा:

custom-node:
    build: ../my_app-node/
    tty: true
    command: node
    volumes:
     - /var/www/my_app:/usr/share/nginx/html/my_app
    exec:
     - npm install

लेकिन यह नहीं है, और मुझे लगता है कि यह वास्तव में गायब है!

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

@ आकर्षक-चिपचिपा आप अल्पाइन में sh -c का उपयोग कर सकते हैं।

ऐसा लगता है कि आप जो चाहते हैं वह "बिल्ड ऑटोमेशन" है जो डॉकटर-कंपोज़ की भूमिका नहीं है। क्या आपने डोबी को देखा है?

दो सवाल:

• यह डॉकटर रचना की भूमिका क्यों नहीं है?
• यदि बिंदु के पास उन सभी पर शासन करने के लिए केवल एक उपकरण है, तो मैं एक अन्य उपकरण का उपयोग किसी कार्य को पूरा करने के लिए क्यों करूंगा जो डॉकर कम्पोज करने में सक्षम नहीं है?

इस सुविधा की अत्यधिक आवश्यकता है!

@ ल्युसिल चिपचिपा

यह डॉकटर रचना की भूमिका क्यों नहीं है?

क्योंकि कम्पोज़ की भूमिका स्पष्ट रूप से परिभाषित है और इसमें उन कार्यों को शामिल नहीं किया गया है।

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

यदि बिंदु के पास उन सभी पर शासन करने के लिए केवल एक उपकरण है, तो मैं एक अन्य उपकरण का उपयोग किसी कार्य को पूरा करने के लिए क्यों करूंगा जो डॉकर कम्पोज करने में सक्षम नहीं है?

हम उन सभी पर शासन करने के लिए एक उपकरण नहीं बनना चाहते हैं। हम UNIX दर्शन का अनुसरण करते हैं और "mak [ing] में विश्वास करते हैं कि प्रत्येक कार्यक्रम एक काम अच्छी तरह से करता है। एक नया काम करने के लिए, नई सुविधाओं को जोड़कर पुराने कार्यक्रमों को जटिल करने के बजाय नए सिरे से निर्माण करें।"
उस दर्शन से असहमत होना ठीक है, लेकिन यही कि हम डॉकर में सॉफ्टवेयर विकसित करते हैं।

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

@ नली

ऑर्केस्ट्रेशन टूल में आप "बिल्ड" और "प्रावधान" को अलग नहीं कर सकते।

उदाहरण के लिए, क्या आप उनमें से एक को जान सकते हैं:

• क्लाउडफॉर्म: http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-init.html
• गर्मी: https://docs.openstack.org/developer/heat/template_guide/software_deployment#configuring -with-script
• terraform: https://www.terraform.io/intro/getting-started/provision.html

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

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

यूनिक्स दर्शन? मुझे हंसने दो। मैं आपको उसी उत्तर की ओर इंगित करता हूं जो मैंने इस अंक में किया था https://github.com/docker/compose/issues/1809#issuecomment -237195021।
आइए देखें कि यूनिक्स दर्शन में "गतिशीलता" कैसे विकसित होगी।

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

आइए रचना के लिए अवलोकन पर वापस जाएं

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

अंत में, docker- रचना docker छवियों से निर्मित कंटेनरों के आधार पर सेवाओं के समूह के प्रबंधन के लिए एक ऑर्केस्ट्रेशन उपकरण है। डॉकटर-कंपोज.आईएमएल फाइल में परिभाषित सेवाओं को 'क्रिएट', 'स्टार्ट', 'स्टॉप', 'स्केल' और 'रिमूव' करना प्राथमिक कार्य हैं।

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

अधिकांश ऑर्केस्ट्रेशन टूल के लिए राज्य संक्रमण पर कार्रवाई करना आवश्यक है। आपको यह AWS के टूल, Google के टूल, फोरमैन, शेफ आदि में मिलेगा। अधिकांश चीजें जो इस ऑर्केस्ट्रेशन स्पेस में रहती हैं, उनमें कुछ प्रकार के जीवनचक्र हुक होते हैं।

मुझे लगता है कि यह मज़बूती से डॉकटर-कंपोज़ के दायरे में है, यह एक ऑर्केस्ट्रेशन टूल है और यह राज्य के बदलावों से अवगत है। मुझे नहीं लगता कि घटनाओं या बाहरी लिपियों का उपयोग मामले में फिट बैठता है। वे बेकार नहीं हैं, घटनाओं का पालन करने के लिए रचना करने के लिए एक 'दूसरी' सेवा शुरू करना बहुत कठिन है। कंटेनर के अंदर या कंटेनर के बाहर चलने वाले हुक एक कार्यान्वयन विवरण है।

दिन के अंत में एक वास्तविक आवश्यकता है जो docker - @aanand , @dnephin , @

इस प्रकार की कार्यक्षमता वर्तमान में मेरे परीक्षण और उत्पादन उत्पादन की तैनाती में डॉकटर के मेरे गोद लेने को रोक रही है। मैं वास्तव में इसे खारिज करने के बजाय कुछ फैशन में संबोधित करना चाहूंगा।

मुझे लगता है कि यह बहुत उपयोगी होगा!

मेरे लिए समस्या यह है कि जब कोई ऐप कंटेनर A रनिंग सर्विस 'a' db कंटेनर B रनिंग सर्विस b पर निर्भर करता है। तब A कंटेनर विफल हो जाता है जब तक कि उसका b सेटअप न हो।
मैं अपने खुद के डॉकरफाइल्स को फिर से लिखने के बजाय डॉक हब छवियों का उपयोग करना पसंद करूंगा। लेकिन इसका मतलब है कि A विफल रहता है और कोई कंटेनर नहीं बनाया जाता है। केवल विकल्प अन्यथा है

1. आधार छवि के रूप में बी का उपयोग करें और अपनी खुद की डॉकरफाइल बनाएं।
2. A को विफल करें और स्क्रिप्ट में b को कॉन्फ़िगर करें और A को पुनरारंभ करें।

मैं विशेष रूप से @ ल्यूसी-चिपचिपा के रूप में एक ही उपयोग के मामले में हूं।

@lekhnath मेरे मामले के लिए, मैं इसे संपादित करके हल command मेरी में विकल्प docker-compose.yml :

command: bash -c "npm install && node"

लेकिन यह soooo बदसूरत टीटी है

@ आकर्षक-चिपचिपा यह ध्यान दिया जाना चाहिए कि यह कंटेनर के Dockerfile में निर्धारित किसी भी आदेश को पलट देता है। मैंने volumes का उपयोग करके एक कस्टम शेल स्क्रिप्ट को आगे बढ़ाते हुए काम किया, command को अपनी Docker Compose फ़ाइल में उस स्क्रिप्ट को चलाने के लिए, और इसमें मूल CMD Dockerfile ।

यह मुद्दा क्यों बंद है? _ bash script_ या _use इस टूल को मैंने लिखा था_ इस मुद्दे को बंद करने का एक वैध कारण नहीं है।

यह एक बहुत ही उपयोगी और महत्वपूर्ण विशेषता है जिसका उपयोग बहुत सारे मामले में किया जाता है जहां रचना का उपयोग किया जाता है।

@dnephin क्या आपको लगता है कि init स्क्रिप्ट चलाना कंटेनर आधारित एप्लिकेशन परिनियोजन के दायरे से बाहर है? सब के बाद, रचना "डॉकर के साथ मल्टी-कंटेनर अनुप्रयोगों को परिभाषित और चलाने" के बारे में है।

क्या किसी ने डोबी को देखा है यदि आप कृपया यहाँ ऐसा नहीं करते हैं तो :)

इसके साथ कभी कुछ नहीं हुआ। मैं docker-compose फ़ाइल के भीतर कुछ प्रकार की कार्यक्षमता देखना पसंद करूंगा, जहां हम यह लिख सकते हैं कि जब कमांड को निष्पादित किया जाना चाहिए जैसे कि @ ahmet2mir ने दिया था।

इस सुविधा के लागू न होने से बहुत दुखी हैं।

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

यह अविश्वसनीय है कि इस सुविधा को अभी तक लागू नहीं किया गया है!

यह बहुत खराब फॉर्म है @dnephin। आपने इस तरह की अति मांग के कार्यान्वयन पर रोक लगा दी है, जो कि ज्यादातर आत्म संवर्धन लगता है, और आप बातचीत जारी रखने के लिए भी तैयार नहीं हैं।

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

ओह, चलो इसे unix-way बनाते हैं।
_Just_ (मल्टीप्लेक्स तब) प्रत्येक कंटेनर के लिए docker-compose up स्टड पाइप CMD ?
ताकि ऐसी यमल फ़ाइल

services:
  node:
    command: sh -

यह काम करेगा: cat provision.sh | docker-compose up
कंटेनर कार्यकारी uting बातों के लिए, मैं साथ आदेशों गुजर से stdin का बेहतर इस्तेमाल नहीं दिख रहा है कर रहे हैं।

एक विकल्प हो सकता है:

services:
  node:
    localscript: provision.sh

हालांकि एक बिट शेल-सेंट्रिक जो 99% प्रावधान उपयोग के मामलों को हल करेगा।

भले ही वैध उपयोग के मामले हैं, और इस पर बहुत सारे ... यह अभी भी स्पष्ट रूप से इनकार कर दिया गया है। मुझे शर्म आती है, यहाँ कई अन्य लोगों की तरह, यह बेहद उपयोगी होगा।

मेरे +1 को मौजूदा + के बड़े ढेर में जोड़ रहा है

... एक और +1 यहाँ!

मुझे लगता है कि अगर इस सुविधा के लिए ऐसा कोई अनुरोध है तो इसे लागू किया जाना चाहिए, उपकरण हमारे उद्देश्यों तक पहुंचने में हमारी सहायता करने के लिए यहां हैं और हमें उन्हें अपने जीवन को कठिन नहीं बनाने में मदद करने के लिए ढालना चाहिए।
मैं उस दर्शन को समझता हूं जिसका कोई पालन करता है लेकिन किसी प्रकार के "हुक कमांड" को जोड़ना समस्या नहीं होनी चाहिए।

+1 +1

जब मैं इस सुविधा की प्रतीक्षा करता हूं, तो मैं एक समान कार्य करने के लिए निम्न स्क्रिप्ट का उपयोग करता हूं:

docker-start.sh

#!/usr/bin/env bash

set -e
set -x

docker-compose up -d
sleep 5

# #Fix1: Fix "iptable service restart" error

echo 'Fix "iptable service restart" error'
echo 'https://github.com/moby/moby/issues/16137#issuecomment-160505686'

for container_id in $(docker ps --filter='ancestor=reduardo7/my-image' -q)
  do
    docker exec $container_id sh -c 'iptables-save > /etc/sysconfig/iptables'
  done

# End #Fix1

echo Done

@ reduardo7 तब आप

@ आप सही हैं! यह एक समान कार्य करने के लिए एक समाधान है, क्षमा करें!

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

मैं समझता हूं कि @dnephin का स्टैंड, यहां बताए गए कार्यों को पर्याप्त रूप से विभिन्न विशेषताओं के साथ बदला जा सकता है।

हालांकि, अगर इस तरह के पैटर्न का अक्सर उपयोग किया जाता है, तो कैसे एक गाइड (या कुछ परीक्षण) प्रस्तुत करने के बारे में ताकि दूसरों को आसानी से इसका उपयोग कर सकें?

कोई असहमति नहीं लगती है कि इस पैटर्न का अक्सर उपयोग किया जा सकता है।

@MaybeS केवल असहमति यह है कि @dnephin अपने

@ सच में हाँ।

onrun का कुछ रूप करने के लिए रचना करने का एक तरीका चाहने का आज का उदाहरण

version: "3.3"
services:
  gitlab:
    image: 'gitlab/gitlab-ce:latest'
    restart: always
    hostname: 'gitlab'
    environment:
      GITLAB_OMNIBUS_CONFIG: |
        # NOTE: this URL needs to be right both for users, and for the runner to be able to resolve :() - as its the repo URL that is used for the ci-job, and the pull url for users.
        external_url 'http://gitlab:9090'
        gitlab_rails['gitlab_shell_ssh_port'] = 2224
    ports:
      - '9090:9090'
      - '2224:22'
  gitlab-runner:
    image: gitlab/gitlab-runner:latest
    volumes:
    - /var/run/docker.sock:/var/run/docker.sock

और निश्चित रूप से, धावक पंजीकृत नहीं है - और ऐसा करने के लिए, हमें करने की आवश्यकता है

1. Gitlab में डेटाबेस से टोकन बाहर खींचें
2. रन कंटेनर में रजिस्टर

इसलिए केवल डॉक-कम्पोज़ में अपने मल्टी-कंटेनर एप्लिकेशन की तैनाती को परिभाषित करने के बजाय, मुझे कुछ माध्यमिक साधनों का उपयोग करने की आवश्यकता है - इस मामले में ... डॉक्स?

export GL_TOKEN=$(docker-compose exec -u gitlab-psql gitlab sh -c 'psql -h /var/opt/gitlab/postgresql/ -d gitlabhq_production -t -A -c "SELECT runners_registration_token FROM application_settings ORDER BY id DESC LIMIT 1"')
docker-compose exec gitlab-runner gitlab-runner register -n \
  --url http://gitlab:9090/ \
  --registration-token ${GL_TOKEN} \
  --executor docker \
  --description "Docker Runner" \
  --docker-image "docker:latest" \
  --docker-volumes /var/run/docker.sock:/var/run/docker.sock \
  --docker-network-mode  "network-based-on-dirname-ew_default"

एमएमएम, मैं कुछ हैक करने में सक्षम हो सकता हूं, जिसके साथ मेरे पास एक और कंटेनर है जिसमें डॉक सॉकेट है, और docker exec's

क्या शर्त है एक रास्ता है ...।

उदाहरण के लिए, मैं जोड़ सकता हूं:

  gitlab-initializer:
    image: docker/compose:1.18.0
    restart: "no"
    volumes:
    - /var/run/docker.sock:/var/run/docker.sock
    - ./gitlab-compose.yml:/docker-compose.yml
    entrypoint: bash
    command: -c "sleep 200 && export GL_TOKEN=$(docker-compose -p sima-austral-deployment exec -T -u gitlab-psql gitlab sh -c 'psql -h /var/opt/gitlab/postgresql/ -d gitlabhq_production -t -A -c \"SELECT runners_registration_token FROM application_settings ORDER BY id DESC LIMIT 1\"') && docker-compose exec gitlab-runner gitlab-runner register -n --url http://gitlab:9090/ --registration-token ${GL_TOKEN} --executor docker --description \"Docker Runner\" --docker-image \"docker:latest\" --docker-volumes /var/run/docker.sock:/var/run/docker.sock --docker-network-mode  \"simaaustraldeployment_default\""

मेरी रचना फ़ाइल के लिए - हालांकि मुझे किसी प्रकार के लूप / प्रतीक्षा की आवश्यकता है, क्योंकि गिटलैब सीधे तैयार नहीं है - sleep 200 पर्याप्त नहीं हो सकता है।

तो - आप __can__ कुछ इस तरह के पैटर्न को सीधे docker-compose.yml हैक कर सकते हैं - लेकिन व्यक्तिगत रूप से, मैं इसके बजाय कुछ क्लीनर समर्थन चाहता हूँ :)

@SvenDowideit onrun पहले से मौजूद है, यह entrypoint या cmd ।

इस छवि के लिए प्रविष्टि बिंदु स्क्रिप्ट आपके लिए एक हुक भी प्रदान करती है। $GITLAB_POST_RECONFIGURE_SCRIPT को एक स्क्रिप्ट के पथ पर सेट किया जा सकता है जो सभी सेटअप पूरा होने के बाद चलेगा (छवि में /assets/wrapper )। अपनी स्क्रिप्ट के पथ पर env चर सेट करें जो psql + रजिस्टर करता है और आप सभी सेट हैं।

यहां तक ​​कि अगर छवि इस हुक प्रदान नहीं किया, यह कुछ ऐसा है जो छवि को बढ़ाकर आसानी से जोड़ा जा सकता है।

हालांकि मुझे किसी प्रकार के लूप / प्रतीक्षा की आवश्यकता है, क्योंकि गिटलैब सीधे तैयार नहीं है - नींद 200 पर्याप्त नहीं हो सकती है।

यह "निष्पादन के बाद शुरू" विकल्प के साथ भी आवश्यक होगा। चूंकि एंट्रीपॉइंट स्क्रिप्ट वास्तव में एक हुक प्रदान करती है, मुझे लगता है कि यह संभवतः उस समाधान के साथ आवश्यक नहीं है।

नहीं, मुझे लगता है कि आपने जो समस्या दिखाई है, उसका एक हिस्सा आपको याद हो गया है:

मेरे मामले में, मुझे दोनों कंटेनरों में प्रवेश की आवश्यकता है, न कि केवल एक - तो एंट्रीपॉइंट / कमांड _not_ मुझे यह देता है।

GL_TOKEN gitlab कंटेनर से आता है, और फिर रजिस्टर करने के लिए gitlab-runner कंटेनर में उपयोग किया जाता है।

इसलिए जो हैक मैं कर रहा हूं, वह तीसरे कंटेनर को जोड़ने के लिए docker/compose छवि का उपयोग कर रहा है - यह ऐसा कुछ नहीं है जिसके लिए आप एक कंटेनर के कॉन्फ़िगरेशन / प्रविष्टि / सेटिंग्स को संशोधित कर सकते हैं, और पूरी तरह से एक (तुच्छ) उदाहरण है बहु-कंटेनर समन्वय जिसमें अधिक आवश्यकता होती है।

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

TBH, मुझे लगने लगा है कि स्क्रिप्ट का उपयोग करते हुए, एक init-container चल रहा है जो खुद कंपोज़ फ़ाइल का उपयोग करता है और docker / कंपोज़ इमेज, _is_ इस तरह की जटिलता को छिपाने का सही तरीका है - नॉन-प्रोडक्शन के लिए "कोशिश" मुझे बाहर, और यह सिर्फ इस तरह की स्थितियों "काम करेंगे"।

_IF_ मैं मदद करने के लिए कुछ अजीब वाक्यात्मक चीनी पर विचार करने के लिए था, शायद मैं कुछ इस तरह से जाऊंगा:

gitlab-initializer:
    image: docker/compose:1.18.0
    restart: "no"
    volumes:
    - /var/run/docker.sock:/var/run/docker.sock
    - ./gitlab-compose.yml:/docker-compose.yml
    entrypoint: ['/bin/sh']
    command: ['/init-gitlab.sh']
    file:
      path: /init-gitlab.sh
      content: |
            for i in $(seq 1 10); do
                export GL_TOKEN=$(docker-compose -f gitlab-compose.yml -p sima-austral-deployment exec -T -u gitlab-psql gitlab sh -c 'psql -h /var/opt/gitlab/postgresql/ -d gitlabhq_production -t -A -c "SELECT runners_registration_token FROM application_settings ORDER BY id DESC LIMIT 1"')
                echo "$i: token($?) == $GL_TOKEN"
                ERR=$?

                if [[ "${#GL_TOKEN}" == "20" ]]; then
                    break
                fi
                sleep 10
            done
            echo "GOT IT: token($ERR) == $GL_TOKEN"

            for i in $(seq 1 10); do
                if  docker-compose -f gitlab-compose.yml  -p sima-austral-deployment exec -T gitlab-runner \
                    gitlab-runner register -n \
                    --url http://gitlab:9090/ \
                    --registration-token ${GL_TOKEN} \
                    --executor docker \
                    --description "Docker Runner" \
                    --docker-image "docker:latest" \
                    --docker-volumes '/var/run/docker.sock:/var/run/docker.sock' \
                    --docker-network-mode  "simaaustraldeployment_default" ; then
                        echo "YAY"
                        break
                fi
                sleep 10
            done

यानी, जैसे क्लाउड-इनिट: http://cloudinit.readthedocs.io/en/latest/topics/examples.html#writing -out-मनमानी-फाइलें

लेकिन जब यह नीचे आता है - हम _have_ एक डॉकटर-कम्पोज-वाईएमएल के अंदर से जटिल मल्टी-कंटेनर चीजों का समन्वय करने का एक समाधान है।

यदि आप पूर्वनिर्धारित टोकन सेट करने में सक्षम हैं, तो आप इसे gitlab-runner एंट्रीपॉइंट स्क्रिप्ट से कर सकते हैं। क्या उस समय के प्रमुख को स्थापित करने का कोई तरीका नहीं है?

@dnephin जिस क्षण आप स्क्रिप्ट का उल्लेख करते हैं, आप एक प्रकाश वर्ष और फिर कुछ के निशान से दूर होते हैं।

onrun entrypoint या cmd ।

entrypoint / cmd निष्पादन योग्य को कॉन्फ़िगर करने के लिए है जो कंटेनर init / PID 1 के रूप में चलेगा।

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

यह @dnephin शायद अधिक उपयोगी है अगर आप, सामान्य समस्या को सेट पर ध्यान केंद्रित नहीं बल्कि एक विशेष कंटेनर सेट के मुद्दों को हल करने के लिए कोशिश कर रहा से होगी।

हालांकि मैंने क्या देखा है, नहीं, इसका एक उत्पन्न रहस्य - लेकिन वास्तव में, यह केवल मल्टी-कंटेनर समन्वय की आवश्यकता नहीं है, यहां तक ​​कि इस छोटे से प्ले सिस्टम में भी होने की संभावना है - यह मेरे लिए सबसे तेज़ है जनता में प्रोटोटाइप।

यह कैसे संभव है कि हम v1 (https://docs.docker.com/compose/compose-comile/compose-file) के बाद से एक कंपोज़ फ़ाइल में entrypoint और command को ओवरराइड करने में सक्षम हैं -v1 / # एंट्रीपॉइंट) और अभी भी एक निर्देश नहीं है जैसे कि कंटेनर चलाने पर onrun कमांड चलाने के लिए?

TBH, मुझे नहीं लगता कि onrun प्रशंसनीय है - डॉकर, या ऑर्केस्ट्रेटर को यह नहीं पता कि "कंटेनर सभी ऊपर हैं" का अर्थ है - मेरे मामलों में, जब तक मैं ऐसा नहीं करता, तब तक विफल रहेगा। कुछ अतिरिक्त "सामान" जहां मुझे एक कंटेनर से जानकारी मिलती है, और इसका उपयोग अन्य कंटेनरों में कुछ अन्य चीजों को किक करने के लिए किया जाता है।

और _if_ मैंने सही किया, इसका मतलब है कि मुझे मूल रूप से एक ऑपरेटर कंटेनर की आवश्यकता है, जिसमें कोड शामिल है जो पता लगाता है कि मल्टी-कंटेनर सिस्टम के कुछ हिस्से इसके लिए पर्याप्त रूप से तैयार हैं, कुछ काम करने के लिए, (कुल्ला और दोहराएं), जब तक कि यह या तो अपनी नौकरी पूरी कर लेता है और बाहर निकल जाता है, या शायद चीजों पर नज़र रखता है और उन्हें ठीक करता है।

और यह मेरे लिए एक नौकरी की तरह लगता है जो कोड के साथ डॉकटर-कंपोज कंटेनर द्वारा सबसे अच्छा हल किया जाता है।

मैं शायद इस संचालक के साथ खेलने जा रहा हूं, फिर इस ऑपरेटर को किसी ऐसी चीज में परिवर्तित कर सकता हूं जो डॉकटर झुंड के ढेर (परियोजना की अन्य जरूरतों के कारण) से निपट सकती है।

मुझे पूरी तरह से यकीन नहीं है कि बहुत अधिक मात्रा में चीनी है जो डॉकटर-कम्पोज़ में जोड़ा जा सकता है, जब तक कि इसके कंटेनर को "यह एक ऑपरेटर है, इसे जादू की क्षमता दें" जैसे कुछ चिह्नित करें।

यह स्पष्ट रूप से देखा गया है कि डेवलपर्स उपयोगकर्ताओं को सुनना नहीं चाहते हैं .. मैं किसी अन्य टूल को देखूंगा ... डॉक-कम्पोज़ एक बड़ा दर्द है .. मुझे समझ नहीं आता कि आप यह क्यों नहीं समझ सकते कि केवल उपयोगी चीज जो आती है डॉक-कम्पोजर एक बिल्ड टूल है ... मैंने सक्रिय उपयोगकर्ता को एक कंटेनर के अंदर अनुमतियों को जोड़ने के लिए कितना समय बिताया है कि कैसे मैं SIMPLE कमांड चला सकता हूं।

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

मैं भी कुछ ऐसा चाहता हूं जो मेरी रचना फ़ाइल में onrun हो

__BUT__, न तो कंटेनर, और न ही यह जानने का तरीका है कि onrun मतलब है। यही कारण है कि ऑपरेटर पैटर्न मौजूद है, और मैंने https://github.com/docker/compose/issues/1809#issuecomment -362126930 में उदाहरण क्यों बनाए

यह __is__ आज तक करना संभव है - संक्षेप में, आप एक onrun सेवा जोड़ते हैं जो तब तक प्रतीक्षा करती है जब तक कि अन्य सेवाएं वास्तव में (गीतालाब के मामले में, जो कि थोड़ा समय लगता है) के साथ बातचीत करने के लिए तैयार हैं, और फिर करें चीजों को समेटने के लिए आपको जो कुछ भी करना होगा।

अगर वहाँ _is_ कुछ ऐसा है जो उसके साथ काम नहीं करता है, तो कृपया हमें बताएं, और हम देखेंगे कि क्या हम कुछ पता लगा सकते हैं!

मैं भी कुछ ऐसा चाहता हूं जो मेरे कंपोज की गई फाइल को आगे बढ़ाए

लेकिन, न तो कंटेनर, और न ही रचना के पास यह जानने का एक तरीका है कि ऑनरून का मतलब क्या है।

जैसा कि मैं इसे देखता हूं, onrun प्रति सेवा, इसका मतलब है कि जब पहले कंटेनर प्रक्रिया शुरू होती है। बड़ी संख्या में मामलों में, कंटेनर केवल एक ही प्रक्रिया चला रहा है, क्योंकि यह कंटेनर चलाने का अनुशंसित तरीका है।

क्रॉस-प्लेटफ़ॉर्म समर्थन का मुद्दा पहले हल किया गया था, क्योंकि कमांड docker exec माध्यम से पूरी तरह से ओएस अज्ञेयवादी हो सकता है, उसी तरह जैसे कि RUN का मतलब डॉकफेराइल में एक लिनक्स कमांड से नहीं है।
https://docs.microsoft.com/en-us/virtualization/windowscontainers/manage-docker/manage-windows-dockerfile

अभी भी onrun सुविधा की प्रतीक्षा है

मुझे इस onrun सुविधाओं की भी आवश्यकता है, मैंने सोचा कि यह इस उपकरण में था। इस अभाव की विशेषता के कारण अब मुझे 2 स्क्रिप्ट मैन बनाए रखने की आवश्यकता है।

दोस्तों, अगर मैं इस docker-compose आसपास एक रैपर बनाऊं और इस onrun सुविधा की अनुमति दूं? क्या आप लोग इसका इस्तेमाल करेंगे?

@wongjiahau कुछ इस तरह हो सकता है? https://github.com/docker/compose/issues/1809#issuecomment -348497289

@ reduardo7 हां, मैंने इसे docker-composei नामक एक स्क्रिप्ट के अंदर लपेटने के बारे में सोचा, और docker-composei.yml जिसमें onrun विशेषता शामिल है।
Btw, docker-composei अर्थ docker-compose improved ।

असली समाधान संभवतः एक 'ऑर्केस्ट्रेटर' छवि का निर्माण करना है जो आंतरिक रूप से 'ऐप इमेजेस' (संभवतः डॉकरों का उपयोग करके) को चलाती है (बैश स्क्रिप्ट के माध्यम से) और चलती है। अन्यथा हम हमेशा एक उपकरण के लिए और अधिक सुविधाओं के लिए पूछेंगे जो "ऐसा करने के लिए नहीं है जो हम इसे करना चाहते हैं"।

तो हमें भी डोकर के भीतर डॉकटर पर विचार करना चाहिए ...

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

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

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

अनुरक्षकों को एक सामान्य सलाह के रूप में, कृपया सिद्ध संचालन सिद्धांतों पर ध्यान केंद्रित करें न कि व्यक्तिगत प्राथमिकताएं।

इसलिए समाधान (इस सारे धागे को पढ़ने के बाद) काम करने के लिए एक बैश स्क्रिप्ट का उपयोग करना है ... उस स्थिति में मैं docker- रचना को हटा दूंगा (हम docker cmd के साथ सब कुछ कर सकते हैं ...)

उन लोगों की बात सुनने के लिए देव जो आपकी चीजों का उपयोग कर रहे हैं :)

तर्कों और प्रतिवादों वाले संदेशों की मात्रा को देखते हुए सरल प्रस्तावों (जैसे कि एक घटना होने के नाते ) से

कृपया, ओपन सोर्स को सही मायने में _open_ बनाते हैं।

इस सुविधा पर कोई अद्यतन? समस्या क्या है?

@ v0lume मुझे लगता है कि आप वास्तव में इस लेख में प्रतिक्रियाओं को पढ़ने के लिए परेशान नहीं थे

वहाँ अभी भी एक समाधान नहीं लगता ... मैं एक hacky workaround साझा करना चाहते हैं, हालांकि।
Docker-compose.yml में संस्करण "2.1" को निर्दिष्ट करके आप इमेज के अंदर अतिरिक्त कोड को चलाने के लिए स्वास्थ्य परीक्षण का दुरुपयोग कर सकते हैं जब इसे शुरू किया जाता है। यहाँ एक उदाहरण है:

version: '2.1'
services:
    elasticsearch:
        image: docker.elastic.co/elasticsearch/elasticsearch:5.4.3
        healthcheck:
            test: |
                curl -X PUT elasticsearch:9200/scheduled_actions -H "ContentType: application/json" -d '{"settings":{"index":{"number_of_shards":'1',"number_of_replicas":'0'}}}' &&
                curl --silent --fail localhost:9200/_cat/health ||
                exit 1
            interval: 11s 
            timeout: 10s 
            retries: 3
        environment:
            - discovery.type=single-node
            - ES_JAVA_OPTS=-Xms1g -Xmx1g
            - xpack.security.enabled=false
    main:
        image: alpine
        depends_on:
            elasticsearch:
                condition: service_healthy

यदि आप जो स्वास्थ्य परीक्षण परीक्षण स्क्रिप्ट लिखते हैं, वह कोड> = 1 से बाहर निकलता है, तो इसे कई बार निष्पादित किया जा सकता है।
किसी सेवा का स्वास्थ्य परीक्षण केवल तभी निष्पादित किया जाएगा जब कोई अन्य सेवा उस पर निर्भर करती है और उदाहरण में देखी गई service_healthy स्थिति को निर्दिष्ट करती है।

मुझे @ टी-वीके दृष्टिकोण पसंद है और पहले भी इसका इस्तेमाल किया है। लेकिन मैं एक और साझा करना चाहूंगा ... हैक:

# Run Docker container here

until echo | nc --send-only 127.0.0.1 <PORT_EXPOSED_BY_DOCKER>; do
  echo "Waiting for <YOUR_DOCKER> to start..."
  sleep 1
done

# Do your docker exec stuff here

+1
मैं इस पर पूरी तरह सहमत हूं क्योंकि इस सुविधा की आवश्यकता है और यह कुबेरनेट जैसे अन्य डॉकटर ऑर्केस्ट्रेटर द्वारा पहले से ही लागू है। यह पहले से ही कंटेनरों के लिए जीवन चक्र हुक है और यहां प्रलेखित

लेकिन मुझे एक उपयोग के मामले में योगदान करने दें जो आप डॉकफाइल्स के साथ हल नहीं कर सकते।

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

निश्चित रूप से मुझे इसे हल करने के लिए एक वर्कअराउंड मिला और एक से अधिक है। दूसरी तरफ हुक मुझे लचीलापन और बेहतर तरीके से चीजों को हैक करने और डॉकरफाइल को बदलने के आग्रह के बिना बदलाव करने के लिए देंगे।

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

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

शुभकामनाएं।

यदि आप इस सुविधा को कार्यान्वित करते हैं, तो मैं आपको जो कुछ भी चाहता हूं, उसे देने में सक्षम हूं।

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

यह अच्छा होगा।

इसे जोड़ने के लिए, निम्नलिखित दिए गए हैं:

services:
    web:
        image: node:8-alpine
        depends_on:
            - db
    db:
        image: postgres:alpine
        onrun: "echo hi"

क्रॉस-ईवेंट स्क्रैप को जोड़ना बहुत अधिक होगा?

    web:
        events:
            db_onrun: "connectAndMigrate.sh"

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

• अलग-अलग कंटेनरों का उपयोग करना - हर किसी को पता होना चाहिए कि उन्हें उन्हें चलाना चाहिए।
• कस्टम डॉकरीफाइल लिखें - हमारे पास लगभग 20 सेवाएं हैं और प्रत्येक सेवा के लिए मुझे कुछ कमांड चलाने के लिए डॉकरफाइल को ओवरराइड करना चाहिए।

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

एक और उपयोग मामला जोड़ना:

एक WordPress उदाहरण की जरूरत है। मेरा डॉकटर-कंपोज़ लिखा। docker-compose up - उफ़! प्लगइन्स निर्देशिका की फ़ाइल अनुमतियाँ सेट करने की आवश्यकता है ... इसे काम करने का कोई अन्य तरीका नहीं मिल सकता है, कंटेनर के चलने के बाद अनुमतियाँ सेट करें क्योंकि मैं होस्ट से कुछ फ़ाइलें बाइंड कर रहा हूं और यह एकमात्र तरीका लगता है कंटेनर के अंदर से chown -Rf www-data.www-data /var/www/wp-content करने के लिए fs अनुमतियों को ठीक करना है। मेरा अपना डॉकरीफाइल लिखें और निर्माण करें, बस इसके लिए? जो मुझे बेवकूफी लगती है।

सौभाग्य से मेरे लिए, ऊपर दिए गए healthcheck हैक ने मुझे इसे लागू करने की अनुमति दी। मैं वेब पर अन्य पृष्ठों को डॉकटर वॉल्यूम पर सेटिंग्स अनुमतियों के मुद्दे पर बात करते हुए देखता हूं, लेकिन सुझाए गए समाधान काम नहीं करते।

खुशी है कि ये गेटकीपर, @dnephin , @aanand , @
01) शशिशोव
०२) फासोबार
03) बलुआ 11
०४) वेब-टेड
05) v0lume
06) वेबपॉलिस
07) Skull0ne
08) उपयोगकर्ता सेवा
09) वोंगजिहाऊ
10) एमएफक्यू
11) योसेफ्रो
१२) बगेरम
13) दकसम
14) ओम्िड
१५) दंतेरबरा
16) विलींग
17) शार्पडेममार्शल
18) खो-वाहक
19) भूत
20) रॉडरिगोरोड्रिग्सकोस्टा
21) डेटाटाइपवॉइड
२२) डेक्सट्रम्ब
२३) लखनाथ
24) आकर्षक-चिपचिपा
२५) रव 84४
26) डोप्री
27) अहममेट 2मीर
28) मोनटेर 82
29) डिसॉर्डियनफ़िश
30) जसोन्हरस
३१) फ़फ़रारिस
32) हाइपरगिग
33) सूर्यास्त
34) sthulb

और संख्या जिन्होंने कहा नहीं? एक 3:
01) dnephin
०२) आनंद
03) पिंडली-

हम्मम ... 34 से 3 ...

@ rm-rf-etc अच्छी एनालिटिक्स ... मुझे नहीं लगता कि @dnephin या @aand अब डॉकटर - कंपोज पर काम कर रहे हैं। भाग्य के साथ, डोकर ढेर के पक्ष में रचना को चित्रित करने की योजना बना रहा है और शिकायत करने के लिए यहां कोई टीम नहीं बचेगी और हम फिर से उत्पाद पर आगे की प्रगति देखना शुरू करेंगे।

एक और उपयोग मामला जोड़ना:

एक WordPress उदाहरण की जरूरत है। मेरा डॉकटर-कंपोज़ लिखा। docker-compose up - उफ़! प्लगइन्स निर्देशिका की फ़ाइल अनुमतियाँ सेट करने की आवश्यकता है ... इसे काम करने का कोई अन्य तरीका नहीं मिल सकता है, कंटेनर के चलने के बाद अनुमतियाँ सेट करें क्योंकि मैं होस्ट से कुछ फ़ाइलें बाइंड कर रहा हूं और यह एकमात्र तरीका लगता है कंटेनर के अंदर से chown -Rf www-data.www-data /var/www/wp-content करने के लिए fs अनुमतियों को ठीक करना है।

इस स्थिति में, आप अपनी रचना फ़ाइल में user संपत्ति भी

मेरा अपना डॉकरीफाइल लिखें और निर्माण करें, बस इसके लिए? जो मुझे बेवकूफी लगती है।

लगता है जैसे आपने एक मजबूत राय बनाई है; लेकिन वास्तविक रूप से, अपनी आवश्यकताओं को पूरा करने के लिए एक आधार छवि को संशोधित करने के लिए डॉकफाइल लिखने के बारे में "बेवकूफ" कुछ भी नहीं होगा। सभी आधार चित्रों का मूल आशय यही है।

सौभाग्य से मेरे लिए, ऊपर दिए गए healthcheck हैक ने मुझे इसे लागू करने की अनुमति दी। मैं वेब पर अन्य पृष्ठों को डॉकटर वॉल्यूम पर सेटिंग्स अनुमतियों के मुद्दे पर बात करते हुए देखता हूं, लेकिन सुझाए गए समाधान काम नहीं करते।

खुशी है कि ये गेटकीपर, @dnephin , @aanand , @

हाँ, अच्छा रवैया दोस्त। : डी

@ rm-rf-etc अच्छी एनालिटिक्स ... मुझे नहीं लगता कि @dnephin या @aand अब डॉकटर - कंपोज पर काम कर रहे हैं।

हाँ, अब कुछ साल हो गए हैं - उन्हें पुराने मुद्दों पर ध्यान देने की ज़रूरत नहीं है।

भाग्य के साथ, डोकर ढेर के पक्ष में रचना को चित्रित करने की योजना बना रहा है और शिकायत करने के लिए यहां कोई टीम नहीं बचेगी और हम फिर से उत्पाद पर आगे की प्रगति देखना शुरू करेंगे।

🙄

@ पिंडली- लेकिन आपने इसे उस प्रतिक्रिया के साथ पिंग किया

मैं हाल ही में फिर से इस मुद्दे पर भागा और भले ही इसे मेरे वर्कअराउंड में देखा जा सकता है, यह केवल तभी काम करता है जब आप 2.1 को निर्दिष्ट करते हैं, जो imo को बदबू देता है।

यह मेरे लिए केवल मनमौजी है कि आधिकारिक रुख से ऐसा लगता है कि आपको हर चीज़ के लिए अपनी खुद की डॉकटर छवियां बनानी चाहिए।
मेरे लिए यह शाब्दिक रूप से यह कहना है कि "यदि आप किसी प्रोग्राम में सेटिंग बदलना चाहते हैं, तो आपको स्रोत कोड को संशोधित करना होगा और उसे पुनः प्राप्त करना होगा।"
हर बार जब आप कोई नई सेवा जोड़ते हैं या आप नए संस्करण में अपग्रेड करना चाहते हैं .. उदाहरण के लिए MongoDB या MySQL डॉकर की छवि, तो आपको एक नई डॉकफाइल बनाना होगा, इसका निर्माण करना होगा और संभवतः इसे अपनी रजिस्ट्री में धकेलना होगा।
यह समय और संसाधनों की बड़े पैमाने पर बर्बादी है, अगर आप सिर्फ image: mongo:3.0.2 image: mongo:3.0.3 अपने docker-compose.yml में बदल सकते हैं, तो इसकी तुलना में यह बेकार है।
मैं लंबे समय के निर्माण के बारे में नहीं कह रहा हूं, मैं इस तथ्य के बारे में कह रहा हूं कि आपको डॉकरफाइल्स और docker build साथ परेशान करना होगा जब आप चाहते हैं कि किसी सेवा के पैरामीटर को अपडेट या बदलना है जो संभवतः भी नहीं है एक आधार छवि के रूप में इस्तेमाल किया जा सकता है।

और तर्क यह है कि हर एप्लिकेशन को एक काम करना चाहिए और केवल एक चीज, वास्तव में भी बदबू आ रही है। यह पूरी तरह से नई सुविधा को लागू करने के बारे में भी नहीं है यह सिर्फ docker माध्यम से एक और पैरामीटर पारित करने के बारे में है। यह भी सवाल है कि क्यों docker run , docker build , docker exec , docker pull आदि सभी एक ही अनुप्रयोग का हिस्सा हैं। तर्क अब पाखंडी की तरह लग रहा है, है ना?

@ shin-, मैंने आपके लिंक का अनुसरण किया और मैं यह नहीं देखता कि उपयोगकर्ता की संपत्ति बाइंड माउंटेड डायरेक्टरी के मालिक के लिए कैसे प्रासंगिक है। बंदरगाहों से संबंधित माना जाता है।

पुन: रवैया: ऐसा लगता है कि लोग मुझसे सहमत हैं, इसलिए इसे मजबूत प्रतिक्रिया के रूप में लें। क्षमा करें यदि आपको यह पसंद नहीं है कि मैं इसे कैसे व्यक्त कर रहा हूं, लेकिन यह वास्तव में ऐसा लगता है कि उपयोगकर्ता की मांगों को अनदेखा किया जा रहा है, तो आप और क्या उम्मीद करते हैं?

मैं इस तरह की कार्यक्षमता के लिए उम्मीद कर रहा था जैसे कि onrun: सुझाव दिया जा रहा है क्योंकि मैं कंपोज़ का उपयोग करने में केवल दो दिन का हूं और मेरे लिए इस तरह का एक उपकरण होना चाहिए।

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

लानत है, मैंने जवाब "ठीक है दोस्तों, खोजने के लिए पूरे धागे की होपिंग पढ़ी, हमने आखिरकार महसूस किया कि यह अच्छा है और हम इसे लागू करेंगे"। यह देखकर दुखी होकर आगे नहीं बढ़े।
+1 करने के लिए!

@fabiomolinar , समाधान का एक प्रकार है, कि हम अपने उत्पादन swarms में बड़े पैमाने पर उपयोग करते हैं, लेकिन यह एक घटना के रूप में काफी अच्छा नहीं है।

हम निम्नलिखित एंकर का उपयोग करते हैं

#### configure a service to run only a single instance until success
x-task: &task
  # for docker stack (not supported by compose)
  deploy:
    restart_policy:
      condition: on-failure
    replicas: 1
  # for compose (not supported by stack)
  restart: on-failure

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

जो सेवा कार्य पर निर्भर करती है उसे कॉन्फ़िगरेशन कार्य पूरा न होने पर कुछ इनायत करने की आवश्यकता है। अधिकांश मामलों में जब तक आप उपयोगकर्ताओं को समाप्त करने के लिए कुछ गलतियाँ करते हैं, तब तक यह ठीक है, इससे आपको एक अंतिम स्थिरता मिलती है जो अधिकांश वातावरणों में अच्छा काम करेगी।

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

@fabiomolinar , यहाँ एक उदाहरण है कि हम अपनी

#### configure a service to run only a single instance until success
x-task: &task
  # for docker stack (not supported by compose)
  deploy:
    restart_policy:
      condition: on-failure
    replicas: 1
  # for compose (not supported by stack)
  restart: on-failure

#### configure a service to always restart
x-service: &service
  # for docker stack (not supported by compose)
  deploy:
    restart_policy:
      condition: any
  # for compose (not supported by stack)
  restart: always

services: 
  accounts: &accounts
    <<: *service
    image: internal/django
    ports:
      - "9000"
    networks:
      - service
    environment:
      DATABASE_URL: "postgres://postgres-master:5432/accounts"
      REDIS_URL: "hiredis://redis:6379/"

  accounts-migrate:
    <<: *accounts
    <<: *task
    command: ./manage.py migrate --noinput

@Dopry को इंगित करने के लिए धन्यवाद। लेकिन मेरा मामला कुछ सरल था। मुझे अपने सर्वर को चालू करने की आवश्यकता थी और उसके बाद, केवल ऊपर और चलने के बाद, मुझे कुछ परिनियोजन कार्य करने की आवश्यकता थी। आज मुझे ऐसा करने का एक तरीका मिला, जो कि एक एकल CMD लाइन के भीतर कुछ छोटी प्रक्रिया प्रबंधन कर रहा था। कल्पना कीजिए कि सर्वर और तैनाती प्रक्रियाओं को क्रमशः server और deploy जाता है। मैंने तब उपयोग किया:

CMD set -m; server $ deploy && fg server

ऊपर दी गई लाइन पर बॉश का मॉनीटर मोड सेट होता है, फिर यह बैकग्राउंड पर server प्रक्रिया शुरू करता है, फिर यह deploy प्रक्रिया चलाता है और अंत में यह server प्रक्रिया लाता है। अग्रभूमि फिर से Docker कंटेनर को मारने से बचने के लिए।

जब हम इस पर चर्चा करते हैं, तो किसी के पास docker-compose up चलाने पर कंटेनर या होस्ट पर कमांड चलाने का कोई टिप है?

मैं समझता हूं कि मेजबान पर किसी भी कमांड को चलाने से सुरक्षा की परतें समझौता हो जाएंगी, लेकिन मैं सिर्फ एक कंटेनर से पहले rm एक डायरेक्टरी या स्टार्टअप के दौरान लेना चाहूंगा। निर्देशिका मेजबान और कंटेनर दोनों पर सुलभ है। मैं एक कस्टम डॉकर छवि नहीं बनाना चाहता हूं या एक स्क्रिप्ट है जो पहले rm और फिर docker-compose चले।

धन्यवाद!

@fabiomolinar , आपके प्रस्ताव का दृष्टिकोण कुछ 12 कारक ऐप प्रिंसिपलों का उल्लंघन करता है। यदि आप अपने बुनियादी ढाँचे को बेहतर बना रहे हैं, तो मैं दृढ़ता से उनके साथ पालन करने की सलाह दूंगा।

• https://12factor.net/processes
• https://12factor.net/concurrency
• https://12factor.net/disposability
• https://12factor.net/admin-processes

कुछ समस्याएं जो आपके दृष्टिकोण से उत्पन्न हो सकती हैं

1. धीमी गति से कंटेनर स्टार्ट-अप।
2. जब कंटेनर के साथ किसी सेवा को स्केल किया जाता है, तो तैनाती हर बार एक बार चलेगी, संभवतः कुछ दिलचस्प संगामिति समस्याओं के लिए अग्रणी होगी।
3. प्रबंधन और डीबगिंग के लिए 'कार्य' और सेवा से लॉग को सॉर्ट करना कठिन है।

मुझे लगता है कि मैं पहली बार में काउंटर-सहज ज्ञान की सिफारिश कर रहा हूं। यह हमारे स्थानीय विकास के वातावरण में प्रैक्टिस में अच्छी तरह से काम करता है जैसे डॉक-कंपोज़, डॉकर्स स्वार्म्स और मेसोस / मैराथन क्लस्टर। यह प्रभावी रूप से 'ऑनरन' की कमी के आसपास भी काम करता है।

मैंने जिस दृष्टिकोण का उपयोग किया है वह वास्तव में बहुत बदसूरत है। मैंने इसे अपने देव वातावरण को चलाने के लिए थोड़ी देर के लिए इस्तेमाल किया। लेकिन मैंने बदल दिया है कि सर्वर के उठने और चलने के बाद स्क्रिप्ट चलाने के लिए पहले से ही एंट्रीपॉइंट स्क्रिप्ट्स और at कमांड का उपयोग करना है। अब मेरा कंटेनर PID 1 के रूप में सही प्रक्रिया के साथ चल रहा है और सभी संकेतों का ठीक से जवाब दे रहा है।

हमें अभी भी इसकी जरूरत है। मुझे ऐसा कोई रास्ता नहीं मिल रहा है, कि कैसे मैं अपने डेटाबेस रोलअप को सफलतापूर्वक मेकफाइल्स के झुंड में बनाए बिना कंटेनर शुरू करने के बाद निष्पादित कर सकता हूं।

@ विजेता-पेरोव रोल-अप कार्य के लिए एक और कंटेनर बनाते हैं और इसे अलग सेवा के रूप में निष्पादित करते हैं

डेटाबेस माइग्रेशन को चलाने के लिए कार्य सेवा दिखाने के लिए हमारी कुछ परियोजनाओं में से कुछ स्निपेट यहाँ दिए गए हैं।

x-task: &task
  # run once deploy policy for tasks
  deploy:
    restart_policy: 
      condition: none
    replicas: 1

service:
  automata-auth-migrate:
    <<: *automata-auth
    <<: *task
    # without the sleep it can't lookup the host postgres.  maybe the command is ran before the network set is complete.
    command: sleep 5 && python /code/manage.py migrate --noinput

खैर, यह चौथा वर्ष है जिस पर चर्चा हुई है। तो मुझे onrun आवश्यकता के इस उपयोग के मामले में अपना +1 जोड़ने दें। पुनश्च: मुझे पूरे धागे के लिए पॉपकॉर्न खरीदना चाहिए था।

मैं भी onrun या समतुल्य (पोस्ट-रन?) एक सोचूंगा। एक आवरण लिपि जोड़ना और कंटेनर में डॉक निष्पादित करना सिर्फ ... बदसूरत है।

IMO docker कंपोज़ ने लोगों को यह समझाने के लिए एक महान कंटेनर ऑर्केस्ट्रेशन MVP था कि कंटेनरों का प्रबंधन करना आसान हो सकता है। हो सकता है कि हम, समुदाय, इसे "रखरखाव मोड" के रूप में विचार करें क्योंकि उत्पादन-तैयार ऑर्केस्ट्रेशन समाधान (यानी कुबेरनेट्स) का प्रसार हुआ है। जब आपके पास कंटेनर निर्भरता जैसी उन्नत विशेषताएं होती हैं, तो "कंटेनर के ऊपर होने के बाद इस बात को निष्पादित करें" जैसी अनुपस्थित सुविधाओं के साथ संयुक्त, यह कथा को फिट करने के लिए लगता है कि विकास की गति में केवल गिरावट आई है। बहुत कम से कम, यह स्पष्ट नहीं है कि इस सुविधा _should be_ को दायरे से बाहर माना जाता है।

आप Dockerfile के साथ सब कुछ आसानी से नहीं कर सकते। मान लीजिए कि आप एक कंटेनर में अपनी स्क्रिप्ट जोड़ना चाहते हैं।
उदाहरण के लिए mysql कंटेनर लें और किसी घटना के मामले में API को कॉल करने के लिए एक सरल स्क्रिप्ट जोड़ने का प्रयास करें।
आप इसे या तो कर सकते हैं:

• Mysql के Dockerfile को बदलना और प्रविष्टि से पहले कंटेनर में अपनी खुद की स्क्रिप्ट जोड़ना। आप एक नहीं जोड़ सकते हैं CMD में Dockerfile , क्योंकि यह करने के लिए एक तर्क हो सकता है ENTRYPOINT ।
• आप कंटेनर चला सकते हैं और फिर अपनी स्क्रिप्ट को चल रहे कंटेनर में कॉपी कर सकते हैं और इसे [ docker cp , docker exec ] चला सकते हैं।

इसलिए मुझे भी लगता है कि डॉकरफाइल को बदलने के लिए onrun जैसी सुविधा फायदेमंद है क्योंकि यह हमेशा पर्याप्त नहीं होता है।

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

@somebi को लगा जैसे

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

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

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

FROM wordpress:php7.1
RUN a2enmod ssl

एक और उपाय यह होगा कि वर्डप्रेस डॉकरफाइल को डाउनलोड किया जाए और उसमें मॉड्यूल एक्टिवेशन को जोड़ा जाए। फिर डॉक बिल्ड का उपयोग करके अपने लिए एक नई छवि बनाएं। उदाहरण के लिए यह php 7.1 के साथ वर्डप्रेस 5.2 के लिए डॉकरीफाइल है:

वर्डप्रेस dockerfile

आप लाइन 63 में अधिक मॉड्यूल सक्षम कर सकते हैं या ssl genaration चला सकते हैं।

यह सब मामला ऐसा नहीं है कि मुझे लगता है कि हम यहां चर्चा कर रहे हैं। समस्या कंटेनर जीवन चक्र में गतिशील हुक बना रही है जैसे कि यह कब शुरू होता है आदि।

यह डॉकटर-कम्पोज़ के लिए एक अच्छा जोड़ होगा!

इस थ्रेड पर उत्तर देने वाले ऐसे कारण हैं कि कुबेरनेट्स "सारा" पैसा रख रहे हैं (डॉकर) उत्पादन कर रहा है, और यह बुरी बात नहीं है कि उम्मीद है कि कोई जल्द ही डॉकर (कंपनी) को खरीद लेगा और समुदाय के प्रस्तावों के अनुरोध को बदल देगा। / विश्लेषण किया ...

इस धागे पर उत्तर देने वाले कारण हैं कि कुबेरनेट्स _ "सभी" _ मोनी डोकर (तकनीक) का उत्पादन कर रहे हैं, और यह कोई बुरी बात नहीं है कि उम्मीद है कि कोई जल्द ही डॉकर (कंपनी) को खरीद लेगा और रास्ते के प्रस्तावों / अनुरोधों को बदल देगा। स्वागत है / विश्लेषण किया ...

मैंने बिना किसी आपत्तिजनक बयान के एक समान आलोचक लिखा, (यह _open स्रोत परियोजनाओं की तर्ज पर था, जो पूरी तरह से खुले स्रोत नहीं हैं, जिनके अनुरक्षक किसी भी अन्य तर्क के बिना तर्क को अनदेखा करते हैं, यह दिखाने के बजाय कि उनके पास कितना तकनीकी आर्गन है_), इसका बहुत समर्थन है , और संदेश हटा दिया गया था।

इससे पता चलता है कि इसके पीछे किस तरह के अभिमानी व्यक्ति हैं।

जब आपका समुदाय 4 साल के लिए कुछ मांगता है और आप (डोकर) अपनी आँखें बंद कर लेते हैं, तो यह दर्शाता है कि आप उन्हें उसी दिशा में नहीं देख रहे हैं:

और अब डॉकटर ने बेच दिया और बेच दिया।
क्योंकि वे सुन नहीं सकते थे ... वे हार गए।

शर्म - लेकिन हे हो।

यह एक वास्तविक शर्म की बात है कि ऐसा कुछ मौजूद नहीं है। मुझे लगता है कि onFailure हुक बनाने के लिए प्यार करता था, जो तब हो सकता है जब स्वास्थ्य की जाँच विफल हो जाती है।

अर्थात

services:
  app:
    image: myapp:latest
    hooks:
      onFailure:
        - # Call a monitoring service (from the host machine) to tell it that the service is offline.

यह ऐसे समय के लिए उपयोगी होगा जहां एप्लिकेशन सॉकेट / पोर्ट से नहीं जुड़ा हो। कुबेरनेट्स शायद यहाँ जाने का रास्ता है, लेकिन यह एक बहुत बड़ा बुनियादी ढाँचा है और बहुत छोटे पर्यावरण के लिए ओवरकिल है।

संपादित करें:
इसके चारों ओर जाने के लिए, मैंने अपने कंटेनर के एंट्रीपॉइंट को मॉनिटरिंग कार्यक्षमता को "रैप" करने के लिए अपडेट किया। अर्थात

# /app/bin/run_with_monitor
#!/bin/bash
set -eE

updateMonitoringSystem() {
 # do something here... This is run from the container, though, unfortunately.
 if [[ $? -eq 1 ]]; then
  # Failed!
 else
  # All is good!
 fi
}

trap 'updateMonitoringSystem' EXIT

$@

# Dockerfile
....
CMD ["/app/bin/run_with_monitor", "./my-app"

फिर भी, छवि को संशोधित करने के लिए यह _without_ करना अच्छा होगा।

: man_shrugging: इस बुनियादी कार्यक्षमता की तलाश में आया, कि प्रतियोगी (कुबेरनेट्स) के पास है, और इसके बजाय मुझे एक डंपस्टर आग मिली।

यह एक वास्तविक शर्म की बात है, अब मुझे स्थानीय रूप से परीक्षण के लिए अलग-अलग डॉकरों की छवियों को बनाए रखना है।

नया साल मुबारक हो: roll_eyes:

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

कार्यक्रमों की एक महत्वपूर्ण राशि स्टार्टअप पर मौजूद कुछ सेवाओं पर निर्भर करती है। उदाहरण के लिए एक MySQL या MongoDB डेटाबेस।

इसलिए इन मामलों में docker-compose का उपयोग करने का कोई समझदार तरीका नहीं है।

इसके बजाय उपयोगकर्ताओं से अपेक्षा की जाती है:

• Dockerfiles (और प्रोग्रामिंग) लिखना सीखें
• Docker images का निर्माण करना सीखें
• कंटेनर को मूल छवियों से विरासत में मिलाते हुए Dockerfiles बनाएं, यह सुनिश्चित करने के लिए कोड जोड़ते हुए कि कंटेनर एक दूसरे की प्रतीक्षा करते हैं
• आधार छवियों की सुरक्षा अपडेट के लिए नियमित रूप से जांच करें
• अद्यतनों को लागू करने के लिए Dockerfiles को नियमित रूप से संशोधित करें
• उन Dockerfiles से नियमित रूप से Docker images निर्माण करें

और यह बेकार है क्योंकि:

• आप समय की भारी मात्रा में सामान की बर्बादी करते हैं जो आपको अन्यथा आवश्यकता भी नहीं हो सकती है
• आप नियमित रूप से Docker images और यहां तक ​​कि अपलोड करने / डाउनलोड करने (खींचने / धक्का देने) पर हार्डवेयर संसाधनों को बर्बाद कर रहे हैं।
• आप नियमित रूप से उन Dockerfiles लिखने पर समय बर्बाद करते हैं, उनका निर्माण करते हैं, उनका परीक्षण करते हैं, उन्हें ठीक करते हैं ... आदि।
• आप संभावित रूप से अपनी छवियों की सुरक्षा से समझौता करते हैं क्योंकि आप नहीं जानते कि आप क्या कर रहे हैं
• आप केवल आधिकारिक रूप से सत्यापित / हस्ताक्षरित Docker images चलाने की क्षमता खो देते हैं

अगर हमारे पास एक स्टार्टअप की जाँच होती है, तो यह सब आवश्यक नहीं होगा और हम जब चाहें image: mysql:8.0.18 से image: mysql:8.0.19 सकते हैं और किया जा सकता है!

वास्तविक रूप से यह वही है जो वर्तमान में वास्तविक दुनिया में हो रहा है:

• लोग अपने स्वयं के Dockerfiles परिवर्तन कर रहे हैं ताकि वे docker-compose साथ काम करें
• वे एक बार अपनी छवियों का निर्माण करते हैं
• और उन्हें नियमित रूप से पैच न करें
• हैकर खुश हो जाते हैं

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

@ binman-डोकर @crosbymichael @dmcgowan @ebriney @ehazlett @eunomie @guillaumerose @jeanlaurent @justincormack @lorenrh @manishtomar @olegburov @routelastresort @spencerhcheng @StefanScherer @thaJeztah @tonistiigi @ulyssessouza @aiordache @ क्रिस-बुढ़ीया @ndeloof
कृपया इस सुविधा पर पुनर्विचार करें या कम से कम इस बारे में उचित चर्चा करें।

task service तकनीक मेरे लिए इस मोड़ पर बहुत अच्छी तरह से काम करती है, लेकिन क्या यह आइडिओसिंकरेक्टिस है। हमने बड़े पैमाने पर माइग्रेशन और एप्लिकेशन इनिशियलाइज़ेशन के लिए अपनी कंपोज़ फ़ाइल्स में पैटर्न लागू किया है। लेकिन मैं एक बेहतर 'depend_on' सहमत हूं जो एक सफल हेल्थचेक या सफल निकास / कार्य पूरा होने पर इंतजार करता है जिससे कई कार्य आसान और अधिक विश्वसनीय हो जाएंगे।

यह वास्तव में एक सहायक जोड़ होगा।

मुझे लगता है कि यह जोर देने लायक है कि कुबेरनेट्स के पास जीवन चक्र पोस्टस्टार्ट के माध्यम से यह कार्यक्षमता है।

k8s! = docker-compose। गलत चैनल

स्पष्ट नहीं होने के लिए खेद है, लेकिन मेरी बात थी: कुबेरनेट्स इसका समर्थन करता है, और क्योंकि कुबेरनेट्स और डोकर कंपोज के उपयोग के कई मामले / उद्देश्य हैं, जो इसे कंपोज करने के लिए एक तर्क होगा। क्षमा करें यदि मैं अस्पष्ट था।

खुशखबरी!!

मुझे लगता है कि डॉकटर ने हमें सुना है, (इस मुद्दे पर और कुछ अन्य लोगों पर)। https://www.docker.com/blog/announcing-the-compose-specification/

आइए समुदाय की जरूरतों को पूरा करने के लिए वहां के विनिर्देश पर काम करने की कोशिश करें। हम इस पुनरारंभ के साथ इसे एक खुला और मैत्रीपूर्ण समुदाय बनाने की कोशिश कर सकते हैं।

खुशखबरी!!

मुझे लगता है कि डॉकटर ने हमें सुना है, (इस मुद्दे पर और कुछ अन्य लोगों पर)। https://www.docker.com/blog/announcing-the-compose-specification/

आइए समुदाय की जरूरतों को पूरा करने के लिए वहां के विनिर्देश पर काम करने की कोशिश करें। हम इस पुनरारंभ के साथ इसे एक खुला और मैत्रीपूर्ण समुदाय बनाने की कोशिश कर सकते हैं।

क्या किसी ने इस बदलाव का सुझाव दिया है? मेलिंग सूची अभी तक उपलब्ध नहीं है, इसलिए मुझे लगता है कि अगली सबसे अच्छी जगह यहाँ है: https://github.com/compose-spec/compose-pec

मुझे कोई समस्या नहीं दिखती जो इस समस्या का वर्णन करती है लेकिन निश्चित नहीं है कि यह सही जगह है ...

संपादित करें: मैंने https://github.com/compose-spec/compose-spec/issues/84 पर एक मुद्दा खोला

आप उदाहरण के लिए कुछ और करने के लिए HEALTHCHECK का उपयोग कर सकते हैं:

कोड

Dockerfile

FROM ubuntu

COPY healthcheck.sh /healthcheck.sh
RUN chmod a+x /healthcheck.sh

HEALTHCHECK --interval=5s CMD /healthcheck.sh

CMD bash -c 'set -x; set +e; while true; do cat /test.txt; sleep 3; done'

healthcheck.sh

#/usr/bin/env bash

set -e

FIRST_READY_STATUS_FLAG='/tmp/.FIRST_READY_STATUS_FLAG'

# Health check

echo 'Run command to validate the container status HERE'

# On success
if [ ! -f "${FIRST_READY_STATUS_FLAG}" ]; then
  # On first success...
  touch "${FIRST_READY_STATUS_FLAG}"

  # Run ON_RUN on first health check ok
  if [ ! -z "${DOCKER_ON_RUN}" ]; then
    eval "${DOCKER_ON_RUN}"
  fi
fi

1. _Health check_ चलाएं।
   
   
   
   • यदि यह विफल रहता है, तो एक्ज़िट कोड 1 साथ स्क्रिप्ट से बाहर निकलता है।
   
   
   • यदि _health check_ ठीक है, तो स्क्रिप्ट जारी रहेगी।
   
   
2. यदि यह पहला _health चेक है OK_ और यदि DOCKER_ON_RUN पर्यावरण चर मौजूद है, तो इसे निष्पादित करें।

उदाहरण

docker-compose.yml

version: "3.7"

services:
  test:
    build:
      context: .
    image: test/on-run
    environment:
      DOCKER_ON_RUN: echo x >> /test.txt

चलाने के बाद निष्पादित करने के लिए एक कस्टम कमांड पास करने के लिए आप DOCKER_ON_RUN पर्यावरण चर का उपयोग कर सकते हैं।

निष्पादन परिणाम

docker-compose build
docker-compose up

आउटपुट:

Creating network "tmp_default" with the default driver
Creating tmp_test_1 ... done
Attaching to tmp_test_1
test_1  | + set +e
test_1  | + true
test_1  | + cat /test.txt
test_1  | cat: /test.txt: No such file or directory
test_1  | + sleep 3
test_1  | + true
test_1  | + cat /test.txt
test_1  | cat: /test.txt: No such file or directory
test_1  | + sleep 3
test_1  | + true
test_1  | + cat /test.txt
test_1  | x
test_1  | + sleep 3
test_1  | + true
test_1  | + cat /test.txt
test_1  | x
test_1  | + sleep 3
test_1  | + true
test_1  | + cat /test.txt
test_1  | x
test_1  | + sleep 3

• आप _health check_ तैयार होने तक cat: /test.txt: No such file or directory त्रुटि देख सकते हैं।
• आप चलाने के बाद /test.txt अंदर केवल एक x देख सकते हैं।

आशा है कि यह किसी की मदद कर सकता है।

संपादित करें 1

यदि आपको _health check_ की आवश्यकता नहीं है, तो आप बाकी स्क्रिप्ट का उपयोग कर सकते हैं।

@ reduardo7
आपके समाधान के लिए धन्यवाद।
बस जोड़ना चाहते हैं, यदि आपकी कमांड को चलाने की आवश्यकता है, जैसे कि उपयोगकर्ता निर्माण या आदि के लिए, तो आप touch "${FIRST_READY_STATUS_FLAG}" लिए वॉल्यूम माउंट कर सकते हैं

इस समस्या के कई समाधान वैध वर्कअराउंड हैं। उदाहरण के लिए एक एंट्रीपॉइंट स्क्रिप्ट बनाने से यह भी हल हो सकता है:
ENTRYPOINT ["./entrypoint.sh"]

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

• बनाने से पहले
• शुरू करने से पहले
• आरंभ करके
• नष्ट करने से पहले
• नष्ट करने के बाद भी
• आदि ...

मुझे पता है कि उपरोक्त सभी सार्थक नहीं हैं, लेकिन मुझे उम्मीद है कि आपको चित्र मिल जाएगा क्योंकि यह बात है।
इसे docker-compose में एक निर्देश के साथ भी शामिल किया जा सकता है:

lifecycle:
    before_start: "./beforeStartHook.sh"
    after_destroy: "./afterDestroyHook.sh"

या यहां तक ​​कि जैसे:

hooks:
    before_destroy: "./beforeDestroyHook.sh"
    before_create: "./fixFsRights.sh"

हम उस फ़ाइल को अधिलेखित करने में असमर्थ हैं जिसे हुक स्क्रिप्ट या बूटस्ट्रैप स्क्रिप्ट दृष्टिकोण का उपयोग करके रूट अनुमति की आवश्यकता होती है, क्योंकि हम कंटेनर को गैर रूट उपयोगकर्ता के रूप में शुरू करते हैं

वाह, ऐसी बुनियादी कार्यक्षमता और अभी भी लागू नहीं हुई है।