🥇डॉकर रचना: विकासापासून उत्पादनापर्यंत

अभ्यासक्रम सुरू होण्याच्या अपेक्षेने तयार केलेल्या पॉडकास्ट ट्रान्सक्रिप्शनचे भाषांतर "लिनक्स प्रशासक"

डॉकर कंपोज हे कार्य तयार करण्यासाठी एक अद्भुत साधन आहे
तुमच्या ऍप्लिकेशनमध्ये वापरलेल्या स्टॅकसाठी वातावरण. हे आपल्याला परिभाषित करण्यास अनुमती देते
मध्ये स्पष्ट आणि सोप्या वाक्यरचनाचे अनुसरण करून, आपल्या अनुप्रयोगाचा प्रत्येक घटक 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.
पर्यावरण परिवर्तने प्रतिमा टॅग किंवा इतर परिभाषित करण्यासाठी वापरली जातात
वेरियेबल्स जे पर्यावरणानुसार बदलू शकतात (स्टेजिंग, इंटिग्रेशन,
उत्पादन).
उत्पादन व्हेरिएबल्सची मूल्ये मूल्ये म्हणून वापरली जातात
डीफॉल्टनुसार, स्टॅक शिवाय उत्पादनात लॉन्च केल्यास हे धोके कमी करते
पर्यावरण व्हेरिएबल सेट करा.
उत्पादन वातावरणात सेवा सुरू करण्यासाठी, कमांड वापरा डॉकर स्टॅक डिप्लॉय - compose-file 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
...

मी वापरू शकतो डॉकर-कंपोज (डॉकर-कंपोज अप)मध्ये स्टॅक चालविण्यासाठी
मध्ये आरोहित स्त्रोत कोडसह विकास मोड /project/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

डॉकर कंपोझ: विकासापासून उत्पादनापर्यंत

विकास आणि उत्पादन फाइल्समधील फरक

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

चलांचे इंटरपोलेशन

माझी तत्त्वे

एक टिप्पणी जोडा Отменить ответ