🥇डकर रचना: विकास देखि उत्पादन सम्म

पाठ्यक्रमको सुरुवातको प्रत्याशामा तयार गरिएको पोडकास्ट ट्रान्सक्रिप्शनको अनुवाद "लिनक्स प्रशासक"

डकर कम्पोज कार्य सिर्जना गर्नको लागि एक अद्भुत उपकरण हो
तपाईंको अनुप्रयोगमा प्रयोग गरिएको स्ट्याकको लागि वातावरण। यसले तपाईंलाई परिभाषित गर्न अनुमति दिन्छ
तपाईको एप्लिकेसनको प्रत्येक कम्पोनेन्टमा स्पष्ट र सरल सिन्ट्याक्स पछ्याउँदै YAML-
फाइलहरू.

को आगमन संगै डकर रचना v3 यी YAML फाइलहरू सीधा उत्पादन वातावरणमा प्रयोग गर्न सकिन्छ जब काम गर्दा
क्लस्टर डकर झुण्ड.

तर के यसको मतलब तपाईले उही डकर-कम्पोज फाइल प्रयोग गर्न सक्नुहुन्छ
विकास प्रक्रिया र उत्पादन वातावरणमा? वा उही फाइल को लागी प्रयोग गर्नुहोस्
मञ्चन? ठीक छ, सामान्यतया, हो, तर यस प्रकार्यको लागि हामीलाई निम्न आवश्यक छ:

चर इन्टरपोलेसन: केहिको लागि वातावरण चर प्रयोग गर्दै
प्रत्येक परिवेशमा परिवर्तन हुने मानहरू।
कन्फिगरेसन ओभरराइड: सेकेन्ड परिभाषित गर्ने क्षमता (वा कुनै पनि
अर्को अर्को) डकर-कम्पोज फाइल जुन सम्बन्धमा केहि परिवर्तन हुनेछ
पहिलो, र डकर कम्पोजले दुबै फाइलहरू मर्ज गर्ने ख्याल राख्नेछ।

विकास र उत्पादन फाइलहरू बीचको भिन्नता

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

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

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

कन्फिगरेसन ओभरराइड

भिन्नताहरू दिईएको छ र तपाईंको निर्भरताहरू परिदृश्यहरूमा फरक हुन सक्छ
विकास र उत्पादन, यो स्पष्ट छ कि हामीलाई विभिन्न कन्फिगरेसन फाइलहरू चाहिन्छ।

डकर कम्पोजले विभिन्न कम्पोज फाइलहरूलाई मर्ज गर्न समर्थन गर्दछ
अन्तिम कन्फिगरेसन प्राप्त गर्नुहोस्। यो कसरी काम गर्दछ उदाहरणमा देख्न सकिन्छ:

$ 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 मानहरू ओभरराइड गर्न docker-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_VERSION, मान प्रयोग गरिनेछ नवीनतमतर यदि तपाइँ सेट गर्नुहुन्छ
निर्माण अघि वातावरण चर को मान, यो निर्माण वा धकेल्दा प्रयोग गरिनेछ
दर्ता गर्न private.registry.mine.

मेरा सिद्धान्तहरू

मेरो लागि काम गर्ने दृष्टिकोणहरू तपाईंको लागि पनि काम गर्न सक्छ। म यी पालना गर्छु
सरल नियम:

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

एउटा साधारण उदाहरण हेरौं।

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

म उत्पादनमा यी समान फाइलहरू प्रयोग गर्न सक्छु! र म निश्चित रूपमा प्रयोग गर्न सक्छु
एउटै फाइल docker-compose.yml मञ्चको लागि। यसलाई विस्तार गर्न
उत्पादन, मैले केवल पूर्वनिर्धारित ट्यागको साथ छवि निर्माण र पठाउन आवश्यक छ
CI चरणमा:

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

डकर कम्पोज: विकास देखि उत्पादन सम्म

विकास र उत्पादन फाइलहरू बीचको भिन्नता

कन्फिगरेसन ओभरराइड

चर को इन्टरपोलेसन

मेरा सिद्धान्तहरू

एक टिप्पणी थप्न Отменить ответ