डॉकर कंपोज़: विकास से उत्पादन तक

पॉडकास्ट प्रतिलेख का अनुवाद पाठ्यक्रम के शुभारंभ की प्रत्याशा में तैयार किया गया था। "प्रशासक Linux»

Docker Compose एक कार्यशील फ़ाइल बनाने के लिए एक अद्भुत उपकरण है
आपके एप्लिकेशन में उपयोग किए जाने वाले स्टैक के लिए वातावरण। यह आपको परिभाषित करने की अनुमति देता है
आपके एप्लिकेशन के प्रत्येक घटक को स्पष्ट और सरल वाक्यविन्यास का पालन करते हुए YAML-
फ़ाइलें.

के आगमन के साथ डॉकर कम्पोज़ v3 इन YAML फ़ाइलों का उपयोग उत्पादन में सीधे काम करते समय किया जा सकता है
झुंड डोकर झुंड.

लेकिन क्या इसका मतलब यह है कि आप उसी docker-compose फ़ाइल का उपयोग कर सकते हैं?
विकास और उत्पादन वातावरण में? या एक ही फ़ाइल का उपयोग करें
स्टेजिंग? खैर, सामान्य तौर पर, हाँ, लेकिन ऐसी कार्यक्षमता के लिए हमें निम्नलिखित की आवश्यकता है:

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

विकास और उत्पादन फ़ाइलों के बीच अंतर

विकास के दौरान, आप संभवतः कोड में परिवर्तनों की जांच करना चाहेंगे
वास्तविक समय मोड। इसके लिए, स्रोत कोड वॉल्यूम आमतौर पर माउंट किया जाता है
कंटेनर जिसमें आपके एप्लिकेशन के लिए रनटाइम शामिल है। लेकिन उत्पादन वातावरण के लिए
यह विधि उपयुक्त नहीं है.

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

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

कॉन्फ़िगरेशन ओवरराइड करना

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

Docker compose विभिन्न compose फ़ाइलों को संयोजित करने का समर्थन करता है
अंतिम कॉन्फ़िगरेशन प्राप्त करना। यह कैसे काम करता है, इसे उदाहरण में देखा जा सकता है:

$ cat docker-compose.yml
version: "3.2"

services:
  whale:
    image: docker/whalesay
    command: ["cowsay", "hello!"]
$ docker-compose up
Creating network "composeconfigs_default" with the default driver
Starting composeconfigs_whale_1
Attaching to composeconfigs_whale_1
whale_1  |  ________
whale_1  | < hello! >
whale_1  |  --------
whale_1  |     
whale_1  |      
whale_1  |       
whale_1  |                     ##        .
whale_1  |               ## ## ##       ==
whale_1  |            ## ## ## ##      ===
whale_1  |        /""""""""""""""""___/ ===
whale_1  |   ~~~ {~~ ~~~~ ~~~ ~~~~ ~~ ~ /  ===- ~~~
whale_1  |        ______ o          __/
whale_1  |                     __/
whale_1  |           __________/
composeconfigs_whale_1 exited with code 0

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

$ cat docker-compose.second.yml
version: "3.2"
services:
  whale:
    command: ["cowsay", "bye!"]

$ docker-compose -f docker-compose.yml -f docker-compose.second.yml up
Creating composeconfigs_whale_1
Attaching to composeconfigs_whale_1
whale_1  |  ______
whale_1  | < bye! >
whale_1  |  ------
whale_1  |     
whale_1  |      
whale_1  |       
whale_1  |                     ##        .
whale_1  |               ## ## ##       ==
whale_1  |            ## ## ## ##      ===
whale_1  |        /""""""""""""""""___/ ===
whale_1  |   ~~~ {~~ ~~~~ ~~~ ~~~~ ~~ ~ /  ===- ~~~
whale_1  |        ______ o          __/
whale_1  |                     __/
whale_1  |           __________/
composeconfigs_whale_1 exited with code 0

यह वाक्यविन्यास विकास के दौरान बहुत सुविधाजनक नहीं है, जब कमांड
इसे कई बार करने की आवश्यकता होगी.

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

$ mv docker-compose.second.yml docker-compose.override.yml
$ docker-compose up
Starting composeconfigs_whale_1
Attaching to composeconfigs_whale_1
whale_1  |  ______
whale_1  | < bye! >
whale_1  |  ------
whale_1  |     
whale_1  |      
whale_1  |       
whale_1  |                     ##        .
whale_1  |               ## ## ##       ==
whale_1  |            ## ## ## ##      ===
whale_1  |        /""""""""""""""""___/ ===
whale_1  |   ~~~ {~~ ~~~~ ~~~ ~~~~ ~~ ~ /  ===- ~~~
whale_1  |        ______ o          __/
whale_1  |                     __/
whale_1  |           __________/
composeconfigs_whale_1 exited with code 0

ठीक है, इससे याद रखना आसान हो जाएगा।

चरों का प्रक्षेप

कॉन्फ़िगरेशन फ़ाइल समर्थन प्रक्षेप
चर और डिफ़ॉल्ट मान। यानी, आप निम्न कार्य कर सकते हैं:

services:
  my-service:
    build:
      context: .
    image: private.registry.mine/my-stack/my-service:${MY_SERVICE_VERSION:-latest}
...

और यदि आप ऐसा करते हैं docker-compose बिल्ड (या पुश) पर्यावरण चर के बिना
$MY_SERVICE_VERSION, मान का उपयोग किया जाएगा ताज़ा , लेकिन यदि आप स्थापित करते हैं
बिल्ड से पहले पर्यावरण चर का मान, इसका उपयोग बिल्ड या पुश के दौरान किया जाएगा
रजिस्टर में private.registry.mine.

मेरे सिद्धांत

जो तरीके मेरे लिए सुविधाजनक हैं, वे आपके लिए भी उपयोगी हो सकते हैं। मैं इनका पालन करता हूँ
सरल नियम:

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

आइये एक सरल उदाहरण देखें।

# docker-compose.yml
...
services:
  my-service:
    build:
      context: .
    image: private.registry.mine/my-stack/my-service:${MY_SERVICE_VERSION:-latest}
    environment:
      API_ENDPOINT: ${API_ENDPOINT:-https://production.my-api.com}
...

И

# docker-compose.override.yml
...
services:
  my-service:
    ports: # This is needed for development!
      - 80:80
    environment:
      API_ENDPOINT: https://devel.my-api.com
    volumes:
      - ./:/project/src
...

मैं उपयोग कर सकता हूं docker-compose (docker-compose अप), स्टैक शुरू करने के लिए
विकास मोड में स्रोत कोड माउंट किया गया है /प्रोजेक्ट/src.

मैं उत्पादन में इन फ़ाइलों का उपयोग कर सकता हूँ! और मैं बिल्कुल उपयोग कर सकता हूँ
वही फ़ाइल डोकर-compose.yml स्टेजिंग के लिए। इसे तैनात करने के लिए
उत्पादन, मुझे बस एक पूर्वनिर्धारित टैग के साथ एक छवि बनाने और भेजने की जरूरत है
सीआई चरण पर:

export MY_SERVICE_VERSION=1.2.3
docker-compose -f docker-compose.yml build
docker-compose -f docker-compose.yml push

उत्पादन पर, इसे निम्नलिखित कमांड के साथ चलाया जा सकता है:

export MY_SERVICE_VERSION=1.2.3
docker stack deploy my-stack --compose-file docker-compose.yml --with-registry-auth

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

export MY_SERVICE_VERSION=1.2.3
export API_ENDPOINT=http://staging.my-api.com
docker stack deploy my-stack --compose-file docker-compose.yml --with-registry-auth

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

पाठ्यक्रम के बारे में और जानें "प्रशासक Linux»

स्रोत: www.habr.com