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

पाठ्यक्रम की शुरुआत की प्रत्याशा में पॉडकास्ट ट्रांसक्रिप्शन का अनुवाद तैयार किया गया "लिनक्स प्रशासक"

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

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

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

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

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

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

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

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

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

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

डॉकर कंपोज़ विभिन्न कंपोज़ फ़ाइलों को मर्ज करने का समर्थन करता है
अंतिम विन्यास प्राप्त करें. यह कैसे काम करता है इसे उदाहरण में देखा जा सकता है:

$ 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

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

सौभाग्य से, डॉकर कंपोज़ स्वचालित रूप से एक विशेष फ़ाइल की तलाश करता है जिसे कहा जाता है
docker-compose.override.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}
...

और यदि आप करते हैं डॉकर-कंपोज़ बिल्ड (या पुश) पर्यावरण चर के बिना
$MY_SERVICE_संस्करण, मान का उपयोग किया जाएगा ताज़ा लेकिन अगर आप सेट करते हैं
निर्माण से पहले पर्यावरण चर का मान, इसका उपयोग निर्माण या पुश करते समय किया जाएगा
रजिस्टर को प्राइवेट.रजिस्ट्री.मेरा.

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

जो दृष्टिकोण मेरे लिए काम करते हैं वे आपके लिए भी काम कर सकते हैं। मैं इनका पालन करता हूं
सरल नियम:

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

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

# 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
...

मैं उपयोग कर सकता हूं डॉकर-कंपोज़ (डॉकर-कंपोज़ अप)स्टैक को चलाने के लिए
स्रोत कोड के साथ विकास मोड /प्रोजेक्ट/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

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

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

स्रोत: www.habr.com