@jmmils क्या आप अपने कंटेनर शुरू नहीं कर सकते जैसे: "डॉकर-

aanm 6 जुल॰ 2015

👎16

@aanm हां, लेकिन मुझे लगता है कि सेवा परिभाषा में कार्यक्षमता को डिफ़ॉल्ट के रूप में प्रतिबिंबित किया जाना चाहिए। हो सकता है कि मेरे पास श्रमिकों का एक न्यूनतम समूह हो जो हमेशा चालू रहना चाहिए और मैं चाहता हूं कि इसे स्पष्ट रूप से डिफ़ॉल्ट के रूप में घोषित किया जाए।

jmmills 6 जुल॰ 2015

@ @aanm क्या आप उम्मीद करते हैं कि docker-compose up को scale पैरामीटर को ध्यान में रखना चाहिए? इसके साथ एकमात्र समस्या जो मुझे दिखाई दे रही है वह यह है कि हम घोषणात्मक कॉन्फ़िगरेशन में पैरामीटर पेश कर रहे हैं जो अंतर्निहित डॉकर/डॉकर एपीआई अवधारणाओं के साथ संगत नहीं हैं लेकिन डॉकर कंपोज़ के लिए बहुत विशिष्ट हैं।

अगर हमें आगे जाकर ऐसा करना होता; मैं कुछ ऐसा सुझाव दूंगा:

#!yaml worker: build: rqworker $scale: 5 links: - redis command: rqworker -u tcp://redis

जहां $<parameter> एक डॉकर कंपोज़ विशिष्ट चीज़ को दर्शाता है।

prologic 7 जुल॰ 2015

हम आगे और पीछे चले गए हैं कि क्या scale YAML में शामिल है; इसे पहले जोड़ने के लिए एक पीआर रहा है (#630)। मेरी अभी भी राय है कि अधिकांश लोगों को अपने कॉन्फिगर में स्केल नंबर नहीं डालने चाहिए, क्योंकि यह इसे कम पोर्टेबल बनाता है, लेकिन मैं ऐसा करने के लिए उपयोग के मामलों को समझता हूं।

अब जबकि हमें extends (और उम्मीद है कि जल्द ही बेहतर होंगे - #1380, #758) के साथ कंपोज़ फ़ाइलों को बढ़ाने का एक प्राथमिक तरीका मिल गया है, तो मैंने https://github.com/docker/compose में जो चिंताएँ उठाई हैं

aanand 7 जुल॰ 2015

मैं परीक्षण से संबंधित सेवाओं के लिए अपने वाईएमएल में scale=0 सेट करना चाहता हूं जिसे मैं सामान्य रूप से शुरू नहीं करना चाहता हूं। मैं केवल उन सेवाओं को स्पष्ट रूप से docker-compose run या एक स्पष्ट scale साथ बनाना चाहता हूं।

jamshid 15 जुल॰ 2015

👍30

@jamshid मैं अक्सर चाहता था कि, एक परिभाषा जो एक वातावरण स्थापित करती है लेकिन डिफ़ॉल्ट रूप से नहीं चलती है। मुझे एक आधार छवि बनाने के लिए आरोपित किया गया है (जिसमें एक शून्य/नो-ऑप स्केल भी मदद करेगा) जिसमें मैं अपने यूनिट परीक्षण चलाता हूं (के माध्यम से docker run ), और फिर मेरी कंटेनर संरचना खपत करती है आधार छवि।

ऐसा कुछ देव विन्यास के लिए बहुत उपयोगी लगता है

myproject:
    build: .
    command: nosetests
    scale: 0
    links:
       - redis
redis:
    image: redis
apiserver:
    image: myproject
    command: plackup
    links:
       - redis
workerserver:
    image: myproject
    command: rqworker
    links:
        - redis

jmmills 19 जुल॰ 2015

👍1

@jamshid @jmmills प्रति सेवा YAML फ़ाइल में enabled पैरामीटर/कुंजी के बारे में क्या? ऐसा कि आप किसी सेवा को अक्षम/सक्षम कर सकते हैं?

prologic 20 जुल॰ 2015

@prologic ऐसा क्यों करें जब "स्केल" पैरामीटर दोनों जरूरतों को हल करेगा?
यदि आप किसी वर्ग के उदाहरण के रूप में एक चल रही प्रक्रिया/कंटेनर की कल्पना करना चाहते हैं, तो कोई इसे instances भी नाम दे सकता है

jmmills 21 जुल॰ 2015

@jmmills मैं सिर्फ आपके उपयोग के मामले में एक _solution_ खोजने की कोशिश कर रहा हूं जिसमें मौजूदा docker-compose को तोड़ना शामिल नहीं है। मुझे लगता है कि scale=0 वह उचित नहीं लगता है और मैं इस बारे में दो दिमाग में हूं कि scale=X को भी लिखें का हिस्सा होना चाहिए या नहीं।

prologic 21 जुल॰ 2015

मेरी राय में पैमाने (या प्रतियों की संख्या) एक सेवा की संरचना का हिस्सा है, इस प्रकार रचना में शामिल किया जाना चाहिए।

jmmills 25 जुल॰ 2015

वैसे मुझे लगता है कि हमारे पास या तो scale=0 या disabled कुंजी है।

prologic 25 जुल॰ 2015

:+1: एक उदाहरण के लिए डिफ़ॉल्ट scale आकार सेट करने की क्षमता होने पर। और मैं सहमत हूं, एक बार जब पैमाना आ जाता है, तो disabled कुंजी की कोई आवश्यकता नहीं होती है, क्योंकि आप बस स्केल को 0 पर सेट करेंगे।

JeanMertz 30 जुल॰ 2015

+1

Filirom1 3 अग॰ 2015

इसके अलावा, एक और उपयोग का मामला: क्या होगा यदि मैं कंटेनरों की संख्या को मापना चाहता हूं, लेकिन सभी सेवाओं की पृष्ठभूमि नहीं बनाना चाहता, या किसी अन्य टर्मिनल (या प्रक्रिया) पर कूदना है और अपने पैमाने की संख्या निर्धारित करना है ...
उदाहरण:

$ docker-compose up && docker scale thing=4

काम नहीं करता क्योंकि up बाहर नहीं निकलता है।
लेकिन अगर मेरी रचना फ़ाइल मेरे कंटेनरों का पैमाना तय करती है ...

$ docker-compose up

डीडब्ल्यूआईएम हो जाता है।

jmmills 4 अग॰ 2015

मुझे यकीन नहीं है कि मुझे वास्तव में यह पसंद है; अचानक up में दो क्षमताएं आ जाती हैं:

कोई भी कंटेनर ऊपर लाएं जिसमें scale पैरामीटर न हो।
scale=0 किसी भी कंटेनर को ऊपर लाएं।

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

स्केल कंटेनर ऊपर / नीचे
scale=0 माध्यम से कंटेनर/सेवाओं को अक्षम करें

prologic 4 अग॰ 2015

कंटेनरों को scale=0 साथ क्यों लाया जाएगा?
बिल्ड scale=0 साथ छवियों का निर्माण करेगा, इस प्रकार आधार छवि की आवश्यकता को सुविधाजनक बनाता है।

jmmills 4 अग॰ 2015

मैं _गलत हो सकता हूं_ लेकिन आपकी आखिरी टिप्पणी पढ़ने से यह इस तरह का निहित है :)

prologic 4 अग॰ 2015

मुझे विस्तृत करने दो:

base_thing:
    build: .
    scale: 0

thing:
    image: base_thing
    # scale: 1 implied by default

workers_for_thing:
    image: some_other_image
    scale: 4
    links:
      - thing

test_harness:
    image: base_thing
    command: nosetests --where=my_test_code_dir --all-modules
    scale: 0

अब, अपेक्षित व्यवहार: docker-compose build "बिल्ड" के साथ किसी भी कंटेनर का निर्माण करता है (निर्माण पर बाहरी छवियों में खींचता है? याद नहीं है), docker-compose up सकारात्मक पैमाने के साथ कुछ भी चलाएगा (डिफ़ॉल्ट है 1), docker-compose run test_harness जरूरत पड़ने पर "बेस_थिंग" का निर्माण करेगा और मेरा एक कमांड चलाएगा। जानकार? :)

संपादित करें: docker-compose up 1 "चीज़" और 4 "workers_for_thing" चलाएगा

jmmills 4 अग॰ 2015

👍7

ठीक है शुक्रिया; आपका उदाहरण scale=0 . के इरादे के बारे में थोड़ा अधिक समझ में आता है और थोड़ा स्पष्ट है

मुझे लगता है कि docker-compose up / run पर छवियों को "खींचता है"।

prologic 4 अग॰ 2015

मुझे परीक्षण, उत्पादन, क्यूए, आदि के लिए नुस्खा बनाने की आवश्यकता है, डी इंटेंस (स्केल) की संख्या इंगित करें।

Miuler 8 अग॰ 2015

scale=X लिए +1। यह बहुत मददगार होगा।
और @jmmils के लिए +1 कॉन्फ़िगरेशन विवरण और अपेक्षित परिणामों के साथ टिप्पणी करें।

mclate 11 अग॰ 2015

वाह! scale=x । कंटेनरों का एक सेट शुरू करना निश्चित रूप से क्लस्टर कॉन्फ़िगरेशन सेट करते समय संभावित दौड़ स्थितियों की पहचान करने में मदद करेगा।

verges-io 12 अग॰ 2015

के लिए +1 scale=x (सहित scale=0 प्रारंभिक के लिए अक्षम सेवाओं के लिए docker-compose up )

michaelcontento 24 अग॰ 2015

scale=x लिए +1।

gnoymmij 8 सित॰ 2015

x NaN है, मैं इसके बजाय -1 का प्रस्ताव दूंगा।

aanm 8 सित॰ 2015

😄1

स्केल = x के लिए +1।

samuelololol 17 सित॰ 2015

+1

sutyrin 4 अक्तू॰ 2015

+1

PaulPetring 5 अक्तू॰ 2015

हम +1 के साथ कैसे रुकेंगे, कृपया?

petarmaric 5 अक्तू॰ 2015

👍7

किसी सुविधा के लिए रुचि का स्तर देखने के लिए +1 करना उपयोगी होता है.

shofetim 5 अक्तू॰ 2015

@shofetim मुझे ऐसा करने का एक बेहतर तरीका पता है: प्रश्न में सुविधा को लागू करें और एक पुल अनुरोध भेजें ...

petarmaric 5 अक्तू॰ 2015

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

coconitro 5 अक्तू॰ 2015

👍1

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

jmmills 6 अक्तू॰ 2015

यहाँ "स्केल = 0" उपयोग के मामले के लिए एक कार्य है:

app:
  build: .
  environment:
    - DATABASE_URL=postgres://user:password<strong i="6">@host</strong>:5432/dbname
  command: sleep 999999999999

app_web:
  extends:
    service: app
  ports:
    - "3000:3000"
  command:
    # intentionally blank to use Dockerfile's default RUN command

app_worker:
  extends:
    service: app
  command:
    rake jobs:work

wkonkel 8 अक्तू॰ 2015

@wkonkel हाँ, मैंने अतीत में इसी तरह की चीजें की हैं।

jmmills 9 अक्तू॰ 2015

मैं वर्तमान में कंपोज़ कोडबेस के साथ खुद को परिचित करने पर काम कर रहा हूं, एक बार जब मुझे पता चल जाता है कि कंपोज के लिए सभी चीजें कहां हैं, तो मैं स्केल कॉन्फ़िगरेशन पैरामीटर के लिए पीआर को हैक कर दूंगा।
ऐसा नहीं लगता कि यह बहुत कठिन होने वाला है, एक परियोजना के लिए scale विधि है जो कि cli इंटरफ़ेस के लिए बैकएंड है, इसलिए मुझे वास्तव में केवल "स्केल" जोड़ना है फ़ील्ड स्कीमा, सुनिश्चित करें कि यदि यह कंटेनर निर्माण के बाद इसे कॉल करने के लिए मौजूद है ... तो सुनिश्चित करें कि यदि यह शून्य पर सेट है तो यह कंटेनर नहीं चलाता है।

jmmills 9 अक्तू॰ 2015

इसके लिए वास्तव में एक पुराना पीआर खुला है: #630।

समस्या यह है कि स्केल एक परिचालन संबंधी चिंता है, यह एप्लिकेशन परिभाषा का हिस्सा नहीं है, इसलिए यह वास्तव में कंपोज़ फ़ाइल के साथ फिट नहीं है।

डिफ़ॉल्ट स्केल स्तर के लिए कॉन्फ़िगरेशन का समर्थन करना अच्छा होगा, लेकिन मुझे नहीं लगता कि कंपोज़ फ़ाइल इसके लिए सही जगह है।

scale: 0 को पहले ही #1754 द्वारा संबोधित किया जाना चाहिए। एक "नो-ऑप" कंटेनर में केवल एक आदेश हो सकता है जो तुरंत बाहर निकलता है (गूंज, सत्य, आदि)। scale: 0 चाहने के मामले आमतौर पर दो में से एक होते हैं: डेटा-वॉल्यूम कंटेनर, या "एडहॉक/एडमिन कार्य"।

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

#2051 के साथ प्रशासनिक कार्यों को बेहतर ढंग से संभाला जाता है। आप admin.yml को परिभाषित कर सकते हैं जो मूल docker-compose.yml और आपको प्रत्येक की परिभाषा को खराब किए बिना अपने प्रशासनिक कार्यों को "मूल संरचना" से जोड़ने की अनुमति देता है।

ये दोनों बदलाव अभी मास्टर में हैं और 1.5.0 रिलीज में उपलब्ध होंगे (जो कि कोने के आसपास है)।

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

dnephin 9 अक्तू॰ 2015

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

jmmills 9 अक्तू॰ 2015

एप्लिकेशन चल रही सेवाओं की न्यूनतम संख्या के बारे में परवाह कर सकते हैं।

क्या आप इस मामले का उदाहरण दे सकते हैं?

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

क्या कोई कारण है कि मूल छवि को उसी निर्माण का हिस्सा होना चाहिए? जैसा कि मैं # 1455 में कहता हूं, रचना मुख्य रूप से "डॉकर बिल्ड" टूल नहीं है। इसका लक्ष्य रनटाइम पर कंटेनरों की एक संरचना प्रदान करना है। हर संभव निर्माण परिदृश्य का समर्थन करने की कोशिश करने से रचना का दायरा बहुत बढ़ जाता है और ध्यान कंटेनर संरचना से दूर हो जाता है। इन अनुरोधों में से प्रत्येक का समर्थन करने के लिए छवियों के निर्माण के लिए डिज़ाइन किए गए टूल के लिए भी यह मुश्किल होगा। मुझे लगता है कि एक बेहतर दिशा यह है कि निर्माण की अधिक से अधिक जटिलता को कंपोज़ से बाहर रखा जाए, और उपयोगकर्ताओं को docker-compose build स्थान पर उपयुक्त बिल्ड टूल में स्वैप करने दें।

dnephin 9 अक्तू॰ 2015

जिस उपयोग के मामले की मुझे परवाह है वह है स्केल = 0 (शायद सार = सत्य एक बेहतर वर्णनकर्ता होगा)। मैं विभिन्न आदेशों के बीच छवियों और पर्यावरण चर साझा करना चाहता हूं। विशेष रूप से मैं चाहता हूं कि एक वेब सर्वर चल रहा हो और एक पृष्ठभूमि जॉब सर्वर चल रहा हो, दोनों एक ही कोड के साथ और दोनों एक ही पर्यावरण चर के साथ।

wkonkel 9 अक्तू॰ 2015

@wkonkel आपके उदाहरण का उपयोग करते हुए, मुझे लगता है कि यह भी काम करेगा?

app_web:
  build: .
  ports:
    - "3000:3000"
  environment:
    - DATABASE_URL=postgres://user:password<strong i="7">@host</strong>:5432/dbname

app_worker:
  extends:
    service: app_web
  command: rake jobs:work
  ports: []

आप एक नहीं सेशन ओवरराइड वाला सार सेवा होने व्यापार command पर नो-सेशन ओवरराइड के साथ कोई अमूर्त के लिए ports । क्या यह सही लगता है?

1988 अमूर्त सेवाओं से संबंधित है।

dnephin 9 अक्तू॰ 2015

@dnephin हाँ, यह मेरे मामले में काम करता है।

wkonkel 9 अक्तू॰ 2015

असल में, मैं इसे वापस लेता हूं ... मैंने अभी इसे डॉकर-कंपोज़-1.4.2 के साथ करने की कोशिश की और ऐसा लगता है कि "बंदरगाह: []" माता-पिता को ओवरराइड नहीं करता है, इसलिए ऐप_वर्कर शुरू करने में विफल रहता है "पोर्ट पहले से ही आवंटित किया गया है ".

wkonkel 9 अक्तू॰ 2015

@dnephin धागे की शायद बेहतर व्याख्या है, लेकिन मैं इसे यहाँ स्पष्ट करने का प्रयास करूँगा।

पहली बात जो दिमाग में आती है वह है जॉब सिस्टम जहां एक ही कोड को चलाने वाले अलग-अलग कंटेनरों को माता-पिता की तरह मॉडल किया जा सकता है-> कांटा () -> चाइल्ड पूल प्रकार की सेवा जिसमें डिफ़ॉल्ट एप्लिकेशन कॉन्फ़िगरेशन समवर्ती के लिए न्यूनतम संख्या में कार्यकर्ता चाहता है।

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

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

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

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

jmmills 9 अक्तू॰ 2015

मुझे लगता है कि नो-ऑप कमांड होने से संसाधनों की बर्बादी की तरह लगता है, बस एक साझा आधार छवि को उसी तरह बनाया जाता है जैसे बाकी एप्लिकेशन स्टैक।

#1754 (अगली रिलीज में) के साथ अब और जरूरी नहीं है। एक सेवा बाहर निकल सकती है और यह बाकी सेवाओं को नहीं रोकेगी। तो आपके पास आधार बस बाहर निकल सकता है और इसके बारे में चिंता न करें।

dnephin 9 अक्तू॰ 2015

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

jmmills 9 अक्तू॰ 2015

@dnephin : मेरे पास एक सीआई धावक है जो docker compose up के बराबर करता है। मैं चाहता हूं कि मेरा परीक्षण वातावरण एक सेवा के कई संस्करणों (यानी, स्केल) के साथ चले। मैं पूरे कॉन्फ़िगरेशन ब्लॉक को कॉपी कर सकता था लेकिन इसमें खुद को दोहराना शामिल होगा। इस मामले में, यह "सिर्फ एक परिचालन संबंधी चिंता" नहीं है, यह एक ऐसी चीज है जिसकी मुझे अपने विकास के माहौल में जरूरत है, जबकि मैं एक क्लस्टर एप्लिकेशन विकसित करता हूं, जिसे वर्तमान में पूरी तरह से एक कंपोज फाइल का वर्णन किया गया है। फिलहाल मुझे कुछ आउट-ऑफ-बैंड स्केल कॉन्फ़िगरेशन करना होगा और फिर किसी तरह docker-compose scale आह्वान करना होगा, मुझे लगता है, लेकिन यह आदर्श नहीं लगता है और विफलता और रेसिंग के लिए और अवसर पेश करता है।

pwaller 31 अक्तू॰ 2015

उत्पादन के मामलों में आप अपनी सेवाओं को न्यूनतम पैमाने के साथ तारांकित करना चाह सकते हैं। उदाहरण के लिए मान लें कि आप एक क्लस्टर से दूसरे क्लस्टर में माइग्रेट कर रहे हैं, और माइग्रेशन के कुछ कठिन हिस्सों को उदाहरण की सादगी के लिए कॉपी डेटा के रूप में रखने देता है; और आपको वास्तव में शुरुआत से कुछ ट्रैफिक से निपटना शुरू करना होगा, इसलिए आपको कुछ सेवा के कम से कम (एन) उदाहरणों को डॉकर-कंपोज़ अप के साथ तैनात करने की आवश्यकता है, web.

कॉन्फ़िगरेशन फ़ाइल पर सेवा के तहत स्केल होने से वास्तव में इसे संभाल लिया जाएगा। यह एक उपयोगिता उपयोग का मामला भी है क्योंकि यदि उपयोग का मामला वास्तव में कुछ सेवा के कम से कम (एन) उदाहरण होने की आवश्यकता को उजागर करता है और न केवल प्रारंभ बिंदु पर।

मेरे दृष्टिकोण से पैमाना वास्तव में एक टोपोलॉजी और कंपोज़िंग का एक परिभाषित पैरामीटर है।

bitgandtter 20 नव॰ 2015

@dnephin

क्या आप इस मामले का उदाहरण दे सकते हैं?

कॉन्सल, मारियाडीबी मास्टर-मास्टर या झुंड पर किसी अन्य वितरित ऐप को वास्तव में विश्वसनीय होने के लिए क्लस्टर में कम से कम 3 नोड्स की आवश्यकता होती है। कॉन्फ़िगरेशन फ़ाइल में उपलब्ध सेवाओं की संख्या के लिए निश्चित रूप से उपयोग के मामले हैं, मुझे समझ में नहीं आता कि आप इसके खिलाफ क्यों हैं। बड़ा:+1: मुझसे यहाँ।

nazar-pc 1 दिस॰ 2015

मैं स्केल को कॉन्फ़िगर करने के तरीके के खिलाफ नहीं हूं, मुझे नहीं लगता कि यह कंपोज़ फ़ाइल में है क्योंकि यह राज्य है जो कंपोज़ फ़ाइल से स्वतंत्र रूप से बदलता है।

इस उदाहरण को लें जो मानता है कि हम कंपोज़ फ़ाइल में कुछ स्केल कॉन्फिगर जोड़ते हैं:

मैंने एक सेवा के लिए 3 का प्रारंभिक पैमाना निर्धारित किया है
मैं docker-compose up -d चलाता हूं, मेरी सेवा का पैमाना 3 . है
मैं docker-compose scale service=4 चलाता हूं
मैं कुछ बदलाव करता हूं और docker-compose up -d साथ पुन: नियोजित करता हूं .. क्या होता है? क्या यह फिर से डाउन-स्केल 3 हो गया है? क्या यह अब पूरी तरह से पैमाने की उपेक्षा करता है?

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

अगर इसे कंपोज़ फ़ाइल में जोड़ा जाना था, तो मुझे लगता है कि हम scale कमांड को हटाना चाहेंगे, ताकि वे विरोध न कर सकें।

आप जो उदाहरण देते हैं वह एक परिचालन आवश्यकता का एक उदाहरण है। एप्लिकेशन को चलाने के लिए आपको कई मास्टर्स की आवश्यकता नहीं है, आपको सेवा की विश्वसनीयता (संचालन) के लिए इसकी आवश्यकता है। और आप इसे अभी भी scale db=x साथ पूरा कर सकते हैं।

dnephin 1 दिस॰ 2015

@dnephin द्वारा ऊपर दिए गए उदाहरण का उपयोग करना:

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

@dnephin द्वारा उठाए गए प्रश्न का उत्तर यह है कि मैं उम्मीद करता हूं कि संशोधन से पहले जितनी सेवाएं/कंटेनर चलेंगे।

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

व्यक्तिगत रूप से मुझे लगता है कि कंपोज़ को विकसित करना बेहतर होगा क्योंकि यह एक बेहतरीन टूल है और हम सभी के लिए जाना जाता है।

bitgandtter 1 दिस॰ 2015

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

nazar-pc 1 दिस॰ 2015

मैंने स्केल कमांड को हटाने और इसे स्केल विकल्प (उपरोक्त पद से) के साथ बदलने के अपने प्रस्ताव के लिए # 2496 बनाया है। इस प्रस्ताव पर प्रतिक्रिया बहुत अच्छी होगी।

dnephin 4 दिस॰ 2015

@dnephin # 2496 कंपोज़ फ़ाइल को फिर से कॉन्फ़िगर करने की आवश्यकता होगी और फिर

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

नए प्रस्ताव में आप जिस परिदृश्य का उल्लेख करते हैं, उसे एक राज्य-पूर्ण सेवा/उपकरण नई-लिखें द्वारा आसानी से हल किया जाएगा।

bitgandtter 4 दिस॰ 2015

+1

npetzall 18 दिस॰ 2015

+1

AdamAJeng 18 दिस॰ 2015

+1

kubaracek 13 जन॰ 2016

@dnephin यदि आप ऐसा करते हैं तो व्यवहार समान नहीं होगा:

$ docker-compose up -d && docker-compose scale node=4 && docker-compose up -d

क्या यह कोई समस्या नहीं है कि कंपोज़ आंतरिक रूप से कैसे बड़े पैमाने पर बना रहता है।

jmmills 14 जन॰ 2016

यही बात है, "एप्लिकेशन लिखें" स्टेटलेस है। एकमात्र राज्य 1 में है) लिखें फ़ाइल, और 2) इंजन द्वारा प्रबंधित डॉकटर कंटेनर लेबल।

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

डॉकर इंजन को पैमाने के बारे में पता नहीं है, इसलिए वह उस स्थिति को स्टोर नहीं कर सकता है। यह बहुत बड़े वास्तु परिवर्तनों के साथ संभव है, लेकिन यह कुछ हद तक इस मुद्दे के दायरे से बाहर है।

अभी के लिए हमारे विकल्प मूल रूप से या तो केवल कमांड लाइन विकल्पों के रूप में स्केल रखने के लिए हैं, या इसे कंपोज़ फ़ाइल में ले जाएं, लेकिन जैसा कि मैंने # 2496 में वर्णन किया है, मुझे लगता है कि दोनों भ्रमित हैं और गलत व्यवहार की ओर ले जाते हैं।

up && scale && up वास्तव में अब सही काम करता है। up सभी कंटेनरों को फिर से बनाएगा, और चूंकि कॉन्फ़िगरेशन में कोई स्केल वैल्यू नहीं है, इसलिए वांछित स्केल क्या होना चाहिए, इस बारे में कोई भ्रम नहीं है। यह पहले से ही स्केल कमांड द्वारा निर्धारित किया गया था, और कंटेनर लेबल द्वारा ट्रैक किया गया था।

dnephin 14 जन॰ 2016

@dnephin मुझे लगता है कि आप जो कह रहे हैं उससे मैं सहमत हूं, [मैं इस धारणा में गलत हो सकता हूं] कि आप वास्तव में क्या सवाल कर रहे हैं _if_ एक घटक के उदाहरणों की संख्या वास्तव में एक सेवा की संरचना (कंटेनरों का एक समूह) की चिंता है विभिन्न घटक कंटेनर चलाना)। मैं कहूंगा कि यह वर्तमान में उस चिंता को संबोधित कर रहा है, बस क्ली और कंपोजिशन डेफिनिशन (यमल) के बीच कमी समानता की चेतावनी के साथ।

यदि जिम्मेदारी का दायरा निर्धारित किया जाता है कि स्केल संरचना की चिंता नहीं है, तो स्केल को एक क्ली विकल्प के रूप में हटा दिया जाना चाहिए (शायद बहुत सारे उपयोगकर्ताओं को नाराज करना), या यदि यह निर्धारित किया जाता है कि स्केल किसी सेवा की संरचना की चिंता है एन + 1 की आवश्यकता वाले क्लस्टर उदाहरणों के लिए खाते में न्यूनतम उदाहरणों के अतिरिक्त समर्थन के साथ क्ली और यमल के बीच समानता होनी चाहिए।

jmmills 14 जन॰ 2016

@jmmills से सहमत हैं विशेष रूप से डेटा कंटेनरों के क्लस्टर चलाते समय, जब उपलब्धता और प्रतिकृति साथ-साथ scale आवेदन का हिस्सा है: उचित पैमाने के बिना, यह काम भी नहीं कर सकता है

ffissore 28 जन॰ 2016

👍3

+1

Jasperswaagman 5 फ़र॰ 2016

+1

lutskanu 6 फ़र॰ 2016

+1

bugcy013 7 फ़र॰ 2016

वर्तमान में मुझे इस तरह की चीजों को घोषित करने की जरूरत है:

सेलेनियम-क्रोम1:
...
सेलेनियम-क्रोम2:
...

यह अच्छा होगा:
सेलेनियम-क्रोम:
स्केल: 2

+1

caioquirino 10 फ़र॰ 2016

👍3

ठीक वैसा ही @caioquirino ने कहा। +1

docker-compose up को अन्य काम की आवश्यकता के बिना काम करने का माहौल लाना चाहिए। सेवाओं को लाने का एकमात्र तरीका है जिसमें एकाधिक नोड्स की आवश्यकता होती है @caioquirino उल्लेख पैटर्न का उपयोग करना है। यहां डीआरवाई उल्लंघनों को नजरअंदाज करते हुए, पैटर्न में गलत गंध आती है जब आप एक और नोड जोड़ने के लिए स्केल कमांड का उपयोग करने का प्रयास करते हैं क्योंकि यह स्पष्ट नहीं है कि किस 'सेवा' को बढ़ाया जाना चाहिए।

Yml फ़ाइल में स्केल इसे ठीक करता है।

BrianAdams 11 फ़र॰ 2016

बड़ा +1, मैं इसका उपयोग उन सेवाओं को परिभाषित करने के लिए भी करना चाहूंगा जिनका स्केल प्रारंभ में 0 पर सेट है।

इस के समान...

consul_bootstrap:
  build: ./consul
consul_master:
  build: ./consul_master
  scale: 0

विचार यह है कि आप एक ही docker-compose.yml का उपयोग कर सकते हैं और विकास के माहौल से उत्पादन में मूल रूप से संक्रमण कर सकते हैं। Consul_master इंस्टेंस स्वचालित रूप से राफ्ट में शामिल हो जाएगा और docker-compose scale consul_master=3 करके कोरम स्थापित करेगा। ये काफी अच्छा होगा.

affixalex 11 फ़र॰ 2016

👍1

@dnephin को जवाब देने के लिए...

इस उदाहरण को लें जो मानता है कि हम कंपोज़ फ़ाइल में कुछ स्केल कॉन्फिगर जोड़ते हैं:
मैंने एक सेवा के लिए 3 का प्रारंभिक पैमाना निर्धारित किया है
मैं docker-compose up -d चलाता हूं, मेरी सर्विस स्केल 3
मैं docker-compose scale service=4 . चलाता हूं
मैं कुछ बदलाव करता हूं और docker-compose up -d.. के साथ पुन: नियोजित करता हूं। क्या होता है? क्या यह फिर से डाउन-स्केल 3 हो गया है? क्या यह अब पूरी तरह से पैमाने की उपेक्षा करता है?
इसे प्यार करना
ठीक है
मैं अभी भी तुम्हारे साथ हूँ
मुझे लगता है कि मौजूदा परिनियोजन और नए परिनियोजन के बीच कुछ अंतर होना चाहिए ताकि मौजूदा परिनियोजन के लिए पैमाने की निरंतरता को बनाए रखा जा सके जो चल रहे अद्यतन प्राप्त कर रहे हैं। एक व्यक्तिगत परिनियोजन में DOCKER_HOST env आदि शामिल होंगे, साथ ही प्रत्येक घटक के पैमाने, छवि आईडी और पुनर्नियोजन का इतिहास भी शामिल होगा। निरंतर तैनाती या नीले हरे रंग की तैनाती जैसे अपस्टैक तंत्र में शामिल होने के लिए यह एक अच्छी जगह हो सकती है? मैं थोड़ा और उत्पादन के लिए तैयार वर्कफ़्लो की कल्पना कर रहा हूं, ताकि आप बस एक अलग DOCKER_HOST से जुड़ सकें और docker-compose up -d सकें और फिर हुक प्रदान कर सकें ताकि अपस्टैक टूल सीआई और ब्लू/ग्रीन रोलआउट जैसी चीजों को प्रबंधित कर सकें। शायद DOCKER_COMPOSE_ENV={"testing" जैसा कुछ जोड़ें || "प्रोडक्शन" || "देव"}?

affixalex 11 फ़र॰ 2016

आईएमएचओ, "हार्डकोडेड" scale , 3 से कहें, इसे 3 कंटेनरों से शुरू करना चाहिए

ffissore 11 फ़र॰ 2016

मुझे लगता है कि "स्केल" पैरामीटर बनाम "स्केल" कमांड के बारे में बहुत भ्रम को वाईएएमएल पैरामीटर "प्रारंभिक_स्केल" या "डिफ़ॉल्ट_स्केल" नाम देकर कम किया जाएगा। इससे यह स्पष्ट हो जाता है कि यह केवल एक मान है जिसका उपयोग तब किया जाएगा जब किसी प्रकार का ओवरराइड न हो। यह भी (IMHO कम से कम) उचित लगता है कि यह "initial_scale" पैरामीटर केवल तभी संदर्भित किया जाएगा जब docker-compose पहली बार सेवा लाता है, न कि docker-compose up चलाने पर सेवा के कुछ उदाहरणों के साथ फिर से चल रहा है।

ceejatec 19 फ़र॰ 2016

👍11

+1 "initial_scale" के लिए, यह भी स्पष्ट रूप से इस पैरामीटर को कंपोज़-विशिष्ट के रूप में वर्णित करेगा, क्योंकि docker के पास ऐसा पैरामीटर नहीं है।

honsiorovskyi 26 फ़र॰ 2016

एक दिलचस्प बात यह है कि ब्लॉग पोस्ट में https://blog.docker.com/2016/02/video-containers-as-a-service-caas/ वीडियो पर "48.56 से पता चलता है कि नए जारी किए गए डॉकर डेटासेंटर पर आप स्टैक निर्माण बिंदु पर वास्तव में सेटअप कर सकते हैं कि आप कितने कंटेनर चलाना चाहते हैं। इसलिए यह विचार डॉकर टीम के लिए नया नहीं है, आशा है कि इसे अगले कंपोज़ रिलीज़ में शामिल किया जाएगा

bitgandtter 26 फ़र॰ 2016

+1

migueleliasweb 26 फ़र॰ 2016

👎3 👍3

+1

jeffersonsouza 9 मार्च 2016

👎3 👍3

लाखों मुद्दे और अनुरोध स्केल/प्रारंभिक_काउंट इत्यादि .. और अभी भी योजनाबद्ध नहीं है।

अच्छा प्रोजेक्ट देखकर दुख होता है लेकिन लोग केवल बहाने ढूंढते हैं और नए और डुप्लिकेट मुद्दे बनाते हैं, मुद्दों को बंद करते हैं और "काम" करते हैं।

gochev 12 मार्च 2016

+1

melya 17 मार्च 2016

👎3

+1

EricMeallier 21 मार्च 2016

👎3

+1

AndreyUtka 21 मार्च 2016

👎3

+1

AndrianBdn 21 मार्च 2016

👎4

बंद करो!
+1 न जोड़ें!
बस मुद्दे की सदस्यता लें!

pierrre 21 मार्च 2016

+1 ( @pierrre क्षमा करें)

draev 21 मार्च 2016

👎8

+1 यह बहुत महत्वपूर्ण है ( @pierrre , क्षमा करें)

aka-toxa 21 मार्च 2016

👎7

मैं सहमत हूं, लेकिन मैं आपके "+1" के लिए 100000 सूचनाएं प्राप्त नहीं करना चाहता!

pierrre 21 मार्च 2016

👍13 😄4 ❤1

/me forks docker कंपोज़ करता है और कोडबेस सीखना शुरू करता है।

jmmills 24 मार्च 2016

selection_126

sergeyklay 24 मार्च 2016

😄5 👎1

ऊपर कई मान्य बिंदु, ऐसा लगता है कि कॉन्फ़िगरेशन फ़ाइल में default/inital scale पैरामीटर + एक scale cli कमांड दोनों को संबोधित करेगा। प्रारंभिक स्केल विकल्प के समर्थन में उपयोग के मामलों को जोड़ने के लिए, क्लस्टर सेवाओं पर विचार करें जहां एक कोरम में नोड्स की एक एक्स संख्या होती है और जो अन्यथा चालू नहीं होनी चाहिए (उदाहरण के लिए 3 से कम नहीं)। docker-compose यह है कि इस तरह के सिस्टम का पूरी तरह से निहित डिस्क्रिप्टर होना चाहिए।

aperepel 29 मार्च 2016

मेरा उपयोग मामला है:

मैंने कम दोहराव की अनुमति देने के लिए कुछ सामान्य सेटिंग्स के साथ एक सेवा का विस्तार किया है। हालांकि आधार सेवा बनाई गई है (जब सेवा नामों को स्पष्ट रूप से निर्दिष्ट किए बिना चल रहा हो) और फिर मैंने इसे मैन्युअल रूप से बंद कर दिया। मैं चाहता हूं कि आधार सेवा का प्रारंभिक पैमाना 0 हो।

jasonf20 29 मार्च 2016

मैं सामान्य सहमति में हूं। हालांकि मेरे दिमाग में, यह मुद्दा और जुड़े/संबंधित मुद्दे थोड़ी अलग समस्या के लिए उबालते हैं: up और scale अंततः एक ही कमांड बनना चाहते हैं।

वे कभी-कभी पहले से ही होते हैं:

docker-compose up service
docker-compose scale service=1 ।

और, यदि scale सभी क्ली विकल्पों (जैसे --force-recreate ) को उजागर कर दिया जो up करता है, या यदि up गिनती के बारे में जानता था, तो वे मूल रूप से होंगे।

यदि, जैसा कि यह मुद्दा प्रस्तावित करता है, docker-compose.yml एक "आरंभिक पैमाना" निर्देश जोड़ा जाता है, तो up को गिनना सीखना होगा। किस बिंदु पर, up केवल काउंटिंग सिंटैक्स का समर्थन नहीं करना चाहिए docker-compose up service=10 (जो yaml में परिभाषित किसी भी पैमाने को अधिलेखित कर सकता है)?

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

mattgiles 3 अप्रैल 2016

👍1

@mattgiles मैं सहमत हूं, यही वह जगह है जहां मैं # 2496 के साथ जा रहा था, हालांकि मैंने यह नहीं माना था कि service=count को up जोड़ा जा सकता है। मुझे लगता है कि यह स्थिति को संभाल सकता है। एकमात्र समस्या जो मुझे दिखाई दे रही है, वह यह है कि वर्तमान में up web अर्थ केवल वेब सेवा और इसकी निर्भरता को लाना है। up web=3 करने की कोशिश करने का मतलब वही बात जारी रखना होगा। जिसका अर्थ है कि up सब कुछ करने का कोई तरीका नहीं है और स्केल गिनती को एक ही बार में ओवरराइड करना है, लेकिन यह शायद ठीक है।

मैं #2496 . में प्रस्ताव को अपडेट करूंगा

dnephin 4 अप्रैल 2016

@dnephin मुझे हालिया प्रस्ताव याद

fwiw, मुझे लगता है कि यह docker-compose up web=3 लिए "वेब" सेवा के लिए तीन कंटेनर लाने के साथ-साथ किसी भी निर्भरता के लिए पूरी तरह से सहज है ... yaml में परिभाषित अनुपात में ( scale तरह कुछ प्रति)

up बाद के आह्वान जारी रह सकते हैं, जैसा कि वे अभी करते हैं, मौजूदा कंटेनरों को अकेला छोड़ने के लिए। केवल यदि वर्तमान पैमाना यमल में परिभाषित की तुलना में छोटा है, तो यह गणनाओं को प्रतिबंधित पैमाने के अनुरूप होने के लिए बदल देगा। परिभाषित कोई भी पैमाना 1 का पैमाना नहीं बना रहेगा।

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

मुझे कंटेनरों को मारने में सक्षम होने के लिए भी समझ में आता है, जैसा कि वर्तमान में scale साथ docker-compose up web=2 आदि जैसे कुछ कॉल करके कर सकते हैं।

mattgiles 5 अप्रैल 2016

👍8

+1

OferE 20 जून 2016

+1 (बस @pierrre को परेशान करने के लिए;))

foxx 24 जून 2016

😄2 👎1

+1

artemkaint 11 जुल॰ 2016

स्केल = x के लिए +1।

ramsrib 20 जुल॰ 2016

इससे संबंधित मैं सिंगलेट्स का वर्णन करने का एक तरीका पसंद करूंगा। scale=1

bfosberry 23 जुल॰ 2016

👍2

स्केल विकल्प के साथ यहां कोई भी सफलता

lavvy 9 अग॰ 2016

+1

astewart-twist 10 अग॰ 2016

मैंने अपस्ट्रीम से इस पर कुछ भी नया नहीं देखा है, व्यक्तिगत रूप से मुझे यह देखने का मौका नहीं मिला है कि क्या मैं इसके लिए एक पैच हैक कर सकता हूं।

धन्यवाद,
जेसन मिल्स

मोबाइल से भेजा हुआ।

8 अगस्त 2016 को शाम 5:19 बजे, लवी नोटिफिकेशन @github.com ने लिखा:
स्केल विकल्प के साथ यहां कोई भी सफलता
-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें, या थ्रेड को म्यूट करें।

jmmills 10 अग॰ 2016

+1

drew-r 16 अग॰ 2016

+1

pablolibo 22 अग॰ 2016

+1

alirezaDavid 24 अग॰ 2016

+1

cgarciae 31 अग॰ 2016

+1 ( @pierrre को फिर से परेशान करने के लिए)

foxx 5 सित॰ 2016

+1

darkdefender27 11 सित॰ 2016

मैं मामले को फिर से दोहराना चाहूंगा

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

पैमाना = 1
क्योंकि मुझे इनमें से एक-एक-एक - _ever_. मारियाडीबी क्लस्टर में, ऐसे मामले हैं जहां मैं केवल एक विशिष्ट स्टोरेज इंजन (जैसे स्पाइडर, कॉलमस्टोर इत्यादि) के साथ कॉन्फ़िगर किया गया एक नोड चाहता हूं।

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

alvinr 14 सित॰ 2016

👍3

मेरे लिए सही मायने रखता है @alvinr। डिफ़ॉल्ट जांच 1 होनी चाहिए।

boyvinall 14 सित॰ 2016

अस्वीकरण: मैं मैराथन या मेसोस्फीयर का प्रतिनिधि नहीं हूं

यह एक काफी सरल सुविधा अनुरोध का एक और उदाहरण है जिसे डॉक सपोर्ट टीम द्वारा एक वर्ष से अधिक समय से छोड़ दिया गया है। https://github.com/docker/docker/pull/12749 एक और उदाहरण है। कुबेरनेट्स और मैराथन के पास पिछले कुछ समय से ये विकल्प हैं ("उदाहरण": 3 मैराथन.जेसन फ़ाइल में) और यहां तक कि ऑटो स्केलिंग को भी लागू करते हैं। यह डॉकर सपोर्ट ग्रुप की अनिच्छा है जिसने मुझे कुछ समय के लिए डॉकर डेटा सेंटर और झुंड से दूर कर दिया है।

westlakem 14 सित॰ 2016

👍7

कोंटेना के पास यह instances: 3 (https://www.kontena.io/docs/references/kontena-yml) के रूप में भी है।

matti 15 सित॰ 2016

ऐसा करने का एक और तरीका है कि हम कंपोज़ फ़ाइल संस्करण 2 पर एक scale अनुभाग जोड़ें।

यह सेवाओं में उपयोग किए जाने वाले डॉकटर-ओनली विकल्पों के साथ मिश्रित नहीं होगा।

एक उदाहरण होगा:

version: "2"

services:
  worker:
    image: something
    command: work

scale:
  worker: 2

hugochinchilla 26 सित॰ 2016

👍7

यह scale: 0 निर्दिष्ट करने की क्षमता के साथ संभावित रूप से एक पत्थर से दो पक्षियों को मार देगा, दूसरा https://github.com/docker/compose/issues/1896

drew-r 26 सित॰ 2016

👍5

यह बिना दिमाग के लगता है।

मैं 3 या 4 नोडज उदाहरणों के साथ nginx+nodejs+mongodb को तैनात करना चाहता हूं। हर बार जब मैं ऐप शुरू करता हूं।

यदि आपके पास ऐसा करने के लिए कमांड लाइन विकल्प है, तो yml फ़ाइल में क्यों नहीं?

docker-compose up scale nodejs=4

करेंगे।

mschwartz 17 अक्तू॰ 2016

👍5

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

16 अक्टूबर 2016 को रात 9:36 बजे, "माइकल श्वार्ट्ज" नोटिफिकेशन @github.com
लिखा था:

यह बिना दिमाग के लगता है।
मैं 3 या 4 नोडज उदाहरणों के साथ nginx+nodejs+mongodb को तैनात करना चाहता हूं। प्रत्येक
जब मैं ऐप शुरू करता हूं।
यदि आपके पास ऐसा करने के लिए कमांड लाइन विकल्प है, तो yml फ़ाइल में क्यों नहीं?
docker-compose up scale nodejs=4
करेंगे।
-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने टिप्पणी की थी।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/docker/compose/issues/1661#issuecomment -254093296,
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/AES98nZt1uIejnIU9iajVt54QbzdlVK1ks5q0tETgaJpZM4FS8ZQ
.

westlakem 17 अक्तू॰ 2016

👍1

मैं ईमानदारी से थोड़ा चकित हूं कि इस पर _any_ पुशबैक है क्योंकि यह इतना स्पष्ट लगता है ...

jeremysmitherman 20 अक्तू॰ 2016

👍5

@westlakem आशा करता है कि

foxx 21 अक्तू॰ 2016

एक बार में अपने कार्यात्मक आकार में एक पूरा ढेर लाना अच्छा होगा। हमारे वर्तमान उपयोग के मामले में सर्विस स्टैक को ठीक से काम करने के लिए "कर्मचारियों = 16" की आवश्यकता होती है।

यह सिर्फ भयानक है:

docker-compose up -d
docker-compose scale workers=16
docker-compose down
docker-compose up --abort-on-container-exit

जिसे स्पष्ट रूप से कुछ इस तरह से बदला जा सकता है:

docker-compose up --abort-on-container-exit --scale workers=16

संपादित करें: मैं देखता हूं कि "रंचर" में सिंटैक्स की तरह एक डॉकटर-कंपोज़ है और प्रारंभिक स्केल पैरामीटर का समर्थन करता है: https://paypertrail.com/blog/tech/docker-rancher-and-laravel-easy-and-safe-scalability

hholst80 28 अक्तू॰ 2016

👍1

YAML एंकर का उपयोग करने और क्षमताओं को मर्ज करने और docker-compose फ़ाइल के भीतर सेवा को डुप्लिकेट करने के लिए एक समाधान है।

services:
  toscale: &my_service
     ... # all paramteres
  # second instance
  toscale2: 
     << : *my_service
     ports:
       - 81:80 # override port if needed

आदि ...

maxigit 15 नव॰ 2016

👍1

यह सुपर उपयोगी होगा!

hugodes 27 नव॰ 2016

👍2

यह बहुत अजीब है यह अस्तित्व में नहीं है ...

मुझे डुप्लीकेट सेवाएं बनानी पड़ सकती हैं क्योंकि मैं वह आलसी हूं।

aphillipo 6 जन॰ 2017

यह पहले से ही कंपोज़र फ़ाइल v3 https://github.com/aanand/compose-file/blob/master/schema/data/config_schema_v3.0.json पर काम कर रहा है और यह पहले से ही docker-compose v1. 10.0-आरसी1

bitgandtter 6 जन॰ 2017

👍2

उनके "सेवा" प्रसाद में अंतर्निहित पैरामीटर है। बहुत दुख की बात है कि a
इस मुद्दे के ग्राहक विकास दल से किसी ने हमें सूचित नहीं किया कि
यह सेवा उत्पाद में आ रहा था, और किसी को आरसी नोट पढ़ना था
किसी भी अंतर्दृष्टि के लिए 1.10 के लिए। डॉकर प्रतिनिधि कहां हैं?

शुक्र, 6 जनवरी, 2017 को सुबह 6:30 बजे, यासमनी क्यूबेला मदीना <
सूचनाएं@github.com> ने लिखा:

यह कंपोज़र फ़ाइल v3 https://github.com/aanand/ पर पहले से ही काम कर रहा है
कंपोज़-फाइल/ब्लॉब/मास्टर/स्कीमा/डेटा/config_schema_v3.0.json जो होगा
और यह पहले से ही docker-compose v1.10.0-rc1 . पर समर्थित है
-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/docker/compose/issues/1661#issuecomment-270886347 ,
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/AES98nOAW-h0BVaR8D9uQfLpMCQRfdyfks5rPiXEgaJpZM4FS8ZQ
.

westlakem 6 जन॰ 2017

😕1

+1

charneykaye 16 जन॰ 2017

+1

mantisbayne 23 जन॰ 2017

नमस्ते, मेरा एक संबंधित प्रश्न है।
मैं कभी सोच रहा था कि docker-compose up मेरे द्वारा निर्धारित पैमाने को याद रख सकता है।

उदाहरण के लिए, मैं docker-compose scale nodejs_web=4 फिर docker-compose down चलाता हूं,
फिर मैं फिर से docker-compose up शुरू करता हूं, यह 4 nodejs_web.

मैं जानना चाहता हूं कि scale कमांड नंबर 4 को कहां सेव करता है?

docker-compose.yml हो सकता है:

version: '2'
services:
  nodejs_web:
    image: node
    command: node

jjqq2013 25 जन॰ 2017

👍2

मैं #2496 . पर @dnephin के प्रस्ताव का समर्थन करता
कृपया हमें यह बुनियादी सुविधा दें।

alwaysastudent 20 मार्च 2017

👍1

डॉकर के नए संस्करण में सेवाएं एक 'प्रतिकृति' सुविधा प्रदान करती हैं।

सोम, 20 मार्च, 2017 दोपहर 3:28 बजे, हमेशा विद्यार्थी सूचनाएं @github.com
लिखा था:

मैं #2496 पर @dnephin https://github.com/dnephin प्रस्ताव का समर्थन करता हूं
https://github.com/docker/compose/issues/2496
कृपया हमें यह बुनियादी सुविधा दें।
-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/docker/compose/issues/1661#issuecomment-287870998 ,
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/AES98uWGenbyCFyxNSSlv7QkXy5oBek1ks5rntNBgaJpZM4FS8ZQ
.

westlakem 21 मार्च 2017

@westlakem - वह सुविधा झुंड के लिए है। यह नियमित सेवा स्केलिंग के लिए नहीं है।

alwaysastudent 21 मार्च 2017

👍1

इतने सारे पेशेवरों, कुछ विपक्ष। इस मुद्दे में क्या मामला है?

cgarciae 7 अप्रैल 2017

https://github.com/docker/compose/issues/2496 में स्केल कमांड को पूरी तरह से हटाने के बारे में एक और हालिया प्रस्ताव है

मैं वास्तव में समझ नहीं पा रहा हूं कि कंपोज़ फ़ाइल में कोई initial_scale: 3 विकल्प क्यों या क्यों नहीं है (मुझे समझ में आता है कि यह सिर्फ scale: 3 क्यों नहीं हो सकता)

matti 8 अप्रैल 2017

1.13.0 में वापस लागू किया गया। आपकी प्रतिक्रिया और धैर्य के लिए आप सभी का धन्यवाद।

shin- 18 जुल॰ 2017

🎉5

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

Ansible को सब कुछ सेट करना चाहिए ताकि Docker चल सके। डॉकर को यह परिभाषित करना चाहिए कि ऐप को सेवा के कितने उदाहरण चाहिए। अब यह डॉकर की जिम्मेदारी है कि वह सेवाओं की सूची को जान सके लेकिन डोकर को कॉल करने के लिए Ansible की जिम्मेदारी है ताकि वह जान सके कि कितने कंटेनरों को स्पिन करना है?

greenscar 24 जुल॰ 2017

@greenscar क्षमा करें, मुझे बिल्कुल यकीन नहीं है कि समस्या क्या है - क्या आप इस सुविधा को लागू करने के तरीके से नाखुश हैं? यदि हां, तो हम इसे किस प्रकार बेहतर बना सकते हैं?

shin- 24 जुल॰ 2017

यह संस्करण 3 में क्यों मौजूद नहीं है? "तैनाती.प्रतिकृति" और "ऊपर" के बाद से अत्यधिक भ्रमित करने वाले समकक्ष नहीं हैं, आप कह सकते हैं कि यह सुविधा v3 में अनुपलब्ध है।

cgarciae 3 अग॰ 2017

@cgarciae deploy.replicas उसी उद्देश्य को पूरा करता है जैसे scale । आपके विचार में वे समान क्यों नहीं हैं?

shin- 3 अग॰ 2017

@ शिन- अगर मैं झुंड नहीं बनाना चाहता और केवल docker-compose up -d उपयोग करता हूं, तो डॉकर कंपोज़ मुझे बताता है कि यह "तैनाती" सेटिंग्स को अनदेखा कर देगा।

cgarciae 3 अग॰ 2017

👍1

@cgarciae यदि आप झुंड नहीं बनाना चाहते हैं तो आप v3 फ़ाइल का उपयोग क्यों कर रहे हैं?

shin- 3 अग॰ 2017

😕1

मुझे लगता है कि डॉकर का उपयोग करने वाला हर कोई स्केल पैरामीटर को डॉकर 2 या 3 फाइलों के लिए काम करने की अपेक्षा करता है। इसके न करने का कोई कारण नहीं है और यह तैनाती के लिए डिफ़ॉल्ट मान भी सेट कर सकता है। प्रतिकृतियां भी। यदि परिनियोजन.प्रतिकृति सेट है तो यह झुंड में पैमाने को ओवरराइड करता है। इस तस्वीर में क्या गलत है, इसके अलावा हर कोई क्या होने की उम्मीद करता है (और निश्चित रूप से अगर आपको यह पसंद नहीं है तो इसे अपने docker-compose.yml में उपयोग करने की आवश्यकता नहीं है)?

aphillipo 3 अग॰ 2017

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

boscowitch 20 सित॰ 2017

👍2

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

tsloughter 3 अक्तू॰ 2017

ओह रुको, इसलिए अगर मैं अपने डॉकटर कंपोज़ कॉन्फिगर को version: "2.2" बदल दूं तो मैं scale: 2 उपयोग कर सकता हूं लेकिन अगर कोई बाद के संस्करण में जाना चाहता है तो ऐसा करने का कोई विकल्प नहीं है?

tsloughter 3 अक्तू॰ 2017

👍2

ठीक है, मुझे "संस्करण" का यह मुद्दा दिखाई दे रहा है, जिसका वास्तव में अर्थ नहीं है कि संस्करण पहले ही लाए जा चुके हैं, https://github.com/docker/compose/issues/4693

tsloughter 3 अक्तू॰ 2017

मैं v3.6 का उपयोग करता हूं क्योंकि मुझे कुछ कॉन्फ़िगरेशन चाहिए जो 2.2 में मौजूद नहीं हैं। स्थानीय विकास के लिए मैं झुंड का उपयोग नहीं करता, लेकिन मैं अपने docker-compose.overrides.yml में कुछ कंटेनरों में स्केल = 0 सेट करना चाहता हूं। क्योंकि उनमें से कुछ केवल फ्रंटएंडबिल्ड कंटेनर जैसे बिल्डप्रोसेस के लिए हैं। यह कंटेनर अन्य चल रहे कंटेनरों के साथ कुछ वॉल्यूम साझा करता है, लेकिन इन अन्य कंटेनरों के साथ docker-compose up पर शुरू नहीं होना चाहिए। तो बिल्डकंटेनर सिर्फ रन कमांड के साथ चलता है। हां, मैं डॉकर-कंपोज़ अप को कॉल करने पर - स्केल परम सेट कर सकता हूं, लेकिन मुझे लगता है कि इसे सीधे कॉन्फ़िगरेशन में लिखना बेहतर है। :)

freesh 1 जुल॰ 2018

स्केल पैरामीटर के लिए धन्यवाद। मैं इसे गैर-उत्पादन docker-compose.yml में उपयोग करने में सक्षम था ताकि कोई भी कॉन्सल और वॉल्ट के HA कॉन्फ़िगरेशन का उपयोग कर सके। स्केल पैरामीटर ने स्थानीय HA कॉन्फ़िगरेशन को आसान बना दिया है। https://github.com/samrocketman/docker-compose-ha-consul-vault-ui

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

samrocketman 12 सित॰ 2018

आप डॉकर कंपोज़ के किस संस्करण पर चल रहे हैं? चूंकि v3 इस सुविधा को छोड़ दिया गया है (ड्रॉप द्वारा, मेरा मतलब है, कभी लागू नहीं किया गया), इसलिए इसे अनदेखा कर दिया गया है। देखें https://docs.docker.com/compose/reference/scale/

jjsaunier 12 सित॰ 2018

अनुपलब्ध सुविधाओं के कारण मैं कभी भी v3 प्रारूप का उपयोग नहीं करता। मैं किन सुविधाओं का उपयोग कर रहा हूं, इसके आधार पर मैं निम्नतम 2.1 या 2.2 प्रारूप का उपयोग करता हूं।

संपादित करें: यह कहने के लिए नहीं कि मैं v3 प्रारूप से बचता हूं। बस जब मैं एक कंपोज़ फ़ाइल लिखने जाता हूं तो आमतौर पर वह गायब होता है जिसका मैं उपयोग करना चाहता हूं।

samrocketman 12 सित॰ 2018

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

jjsaunier 12 सित॰ 2018

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

samrocketman 13 सित॰ 2018

Compose: फ़ीचर अनुरोध: yml . में स्केल पैरामीटर जोड़ें

सबसे उपयोगी टिप्पणी

सभी 146 टिप्पणियाँ

1988 अमूर्त सेवाओं से संबंधित है।

संबंधित मुद्दों