Table of Contents

क्यों उत्पादन तैनाती के लिए डोकर के साथ व्यवस्थित

आधुनिक बुनियादी ढांचे की मांग है कि कंटेनरीकृत सेवाएं अप्रत्याशित रिबूट, हार्डवेयर विफलताओं या पैकेज अद्यतनों से बची हैं। जबकि डोकर पुनः आरंभ नीतियों (]) प्रदान करता है, ये नीतियां केवल तभी तक काम करती हैं जब तक डोकर डेमन चल रहा है। व्यवस्थित - उबंटू, डेबियन, फेडोरा, सेंटोस और अधिकांश आधुनिक लिनक्स वितरणों द्वारा उपयोग की जाने वाली इनिट प्रणाली में शामिल हैं - इसे आगे डोकर डेमन के जीवन चक्र के प्रबंधन से ले जाता है और डोकर सॉकेट उपलब्ध होने से पहले भी कंटेनर शुरू कर सकता है। सिस्टम्ड का उपयोग करने के लाभ में शामिल हैं:

  • निर्भरता निर्देशों के माध्यम से गारंटीकृत स्टार्टअप आदेश (जैसे, नेटवर्क के बाद। लक्ष्य, docker.service के बाद)
  • एकीकृत लॉगिंग के माध्यम से , सीधे डीबगिंग करना
  • सिस्टम यूनिट निर्देश का उपयोग करके संसाधन सीमाओं (सीपीयू, मेमोरी, आई / ओ) पर ठीक-ग्रेन नियंत्रण
  • विन्यास योग्य देरी और फट सीमाओं के साथ विफलता पर स्वचालित पुनरारंभ
  • सॉकेट सक्रियण और समयबद्ध स्टार्टअप के लिए समर्थन

प्रत्येक डॉकर कंटेनर को एक व्यवस्थित सेवा फ़ाइल में लपेटकर, ऑपरेशन टीमों को कंटेनरों को शुरू करने, रोकने और निगरानी करने के लिए एक सुसंगत इंटरफ़ेस प्राप्त होता है, जो ऐड-हॉक स्क्रिप्ट और मैनुअल हस्तक्षेप पर निर्भरता को कम करता है।

एक एकल डोकर कंटेनर के लिए एक व्यवस्थित सेवा बनाना

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

स्टेप 1: सर्विस यूनिट फ़ाइल को राइट करें

]] नामक एक फ़ाइल बनाएं। एक प्रारंभिक बिंदु के रूप में निम्नलिखित टेम्पलेट का उपयोग करें:

[Unit]
Description=My Application Container
After=network-online.target docker.service
Wants=network-online.target
Requires=docker.service

[Service]
Restart=always
RestartSec=10
StartLimitBurst=3
ExecStartPre=-/usr/bin/docker kill myapp
ExecStartPre=-/usr/bin/docker rm myapp
ExecStart=/usr/bin/docker run --rm --name myapp \
 -e DB_HOST=10.0.1.50 \
 -e DB_PORT=5432 \
 -v /data/myapp:/app/data \
 -p 8080:8080 \
 myregistry/myapp:latest
ExecStop=/usr/bin/docker stop -t 10 myapp
ExecStopPost=-/usr/bin/docker rm myapp

[Install]
WantedBy=multi-user.target

]]]]

  • ]]]]]]]]]]]] - कंटेनर शुरू करने से पहले डोकर डेमन को चल रहा है सुनिश्चित करता है।
  • ]]]]]][][[[[]]]][[]]]]]]]]]]]]]]][[]]]]]]]]]]]][[[[[[[[[[[[[[[[[[FLT:]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]
  • ] ]] ] - पिछले रन से किसी भी बचे हुए कंटेनर को साफ़ करता है (]]] का मतलब है यहां असफलता गैर-वसा है।
  • ] ]]] ] का उपयोग करता है जब यह बंद हो जाता है तो कंटेनर को स्वचालित रूप से हटाने के लिए।
  • ]]]]]]]]]]] - सुंदर ढंग से एक समय के साथ कंटेनर को बंद (10 सेकंड)।
  • ]]]]]]]]]]]]]] - निकास कोड की परवाह किए बिना कंटेनर को पुनः आरंभ करें।
  • ]]]]]]]]]]]] – पुनः आरंभ करने से पहले 10 सेकंड का इंतजार।
  • ] ]]] - पुनः आरंभ करने के लिए प्रति अंतराल (डिफ़ॉल्ट 10 सेकंड) के 3 प्रयास को दोहराते हैं।

स्टेप 2: सक्षम करें और सर्विस शुरू करें

sudo systemctl daemon-reload
sudo systemctl enable myapp.service
sudo systemctl start myapp.service

]: ]] सेवा फ़ाइलों को फिर से पढ़ने के लिए व्यवस्थित बताता है। तो सेवा बूट पर शुरू होता है तो सिम्पलिंक बनाता है।

मानक व्यवस्थित कमांड के साथ सेवा का प्रबंधन

जब सेवा चल रही है, तो आप इसे किसी अन्य सिस्टम सेवा की तरह नियंत्रित करते हैं:

  • Start:] ]]
  • ]Stop: ]]]
  • Restart:] ]]]
  • Status:] ]]
  • Logs:] ( लाइव लॉग का पालन करें)

उन्नत विन्यास पैटर्न

उत्पादन तैनाती को अक्सर एक साधारण से अधिक की आवश्यकता होती है । नीचे आम वृद्धि आप अपनी व्यवस्थित सेवा फ़ाइलों में जोड़ सकते हैं।

पर्यावरण चर

हार्ड कोडिंग रहस्य या सर्विस फाइल में विन्यास की सिफारिश नहीं की जाती है। इसके बजाय, एक अलग वातावरण फ़ाइल का उपयोग करें:

[Service]
EnvironmentFile=-/etc/myapp/env.conf
ExecStart=/usr/bin/docker run --rm --name myapp \
 --env-file /etc/myapp/env.conf \
 myregistry/myapp:latest

] पथ से पहले उपसर्ग का मतलब है कि यह सेवा शुरू हो जाएगी, भले ही फ़ाइल मौजूद न हो (प्रारंभिक सेटअप के दौरान उपयोगी)।

नेटवर्किंग और पोर्ट बाइंडिंग

उन कंटेनरों के लिए जिन्हें एक दूसरे के साथ उसी होस्ट पर संवाद करने की आवश्यकता है, या उपयोगकर्ता-निर्धारित पुल नेटवर्क का उपयोग करने पर विचार करें। उदाहरण:

ExecStart=/usr/bin/docker run --rm --name web \
 --network=my-net \
 -p 443:443 \
 -v /etc/ssl/certs:/etc/ssl/certs:ro \
 myregistry/web:latest

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

ExecStartPre=/usr/bin/docker network create my-net

अंतर-निर्माता निर्भरता

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

[Unit]
Description=Web App Container
After=network-online.target docker.service mydb.service
BindsTo=mydb.service

]] वेब ऐप के डेटाबेस कंटेनर के लिए जीवन चक्र के संबंध में - यदि डेटाबेस बंद हो जाता है, तो वेब ऐप भी बंद हो जाता है।

स्वास्थ्य जांच और तत्परता

समय से पहले सेवा उपलब्धता को रोकने के लिए डॉकर स्वास्थ्य जांच को व्यवस्थित किया जा सकता है।

ExecStartPost=/usr/local/bin/wait-for-health.sh http://localhost:8080/health 30

जब कंटेनर स्वस्थ होता है तो स्क्रिप्ट 0 से बाहर निकलनी चाहिए। यदि यह विफल हो जाता है, तो सिस्टम यूनिट को विफल होने के रूप में चिह्नित करता है।

सिस्टम के माध्यम से संसाधन सीमाएं

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

[Service]
MemoryMax=512M
CPUQuota=50%

ये सेटिंग्स एक कठिन सीमा बनाती हैं जो स्वतंत्र रूप से डोकर को लागू करती हैं।

एकाधिक कंटेनरों का प्रबंधन: व्यवस्थित बनाम डोकर रचना

छोटी संख्या में कंटेनरों (जैसे, 2-5) के लिए, व्यक्तिगत व्यवस्थित सेवा फाइलें सरल और रखरखाव योग्य हैं। हालांकि, जब एक परियोजना में कई अंतर-कनेक्टेड सेवाएं शामिल हैं, तो डोकर कॉम्पोज़ अधिक सुविधाजनक हो जाता है। आप अभी भी एक सेवा इकाई बनाने के द्वारा पूरे डोकर कॉम्पोज़ स्टैक को ऑर्केस्ट्रेट करने के लिए व्यवस्थित उपयोग कर सकते हैं जो ] कहते हैं। उदाहरण:

[Unit]
Description=My Application Stack
After=network-online.target docker.service
Requires=docker.service

[Service]
Type=oneshot
RemainAfterExit=yes
WorkingDirectory=/opt/myapp
ExecStart=/usr/local/bin/docker-compose up -d
ExecStop=/usr/local/bin/docker-compose down

[Install]
WantedBy=multi-user.target

यह दृष्टिकोण आपको सिस्टम के जीवनचक्र प्रबंधन के साथ संयुक्त सेवाओं को परिभाषित करने के लिए रचना की सादगी देता है। ध्यान दें कि का उपयोग किया जाता है क्योंकि ] तुरंत बाहर निकलता है। ] इकाई को एक "सक्रिय" राज्य में रखता है जब तक कहा जाता है।

आपको कौन सी विधि चुननी चाहिए?

  • ]Individual systemd Services – विरासत अनुप्रयोगों के लिए सबसे अच्छा, सख्त स्टार्टअप आदेश के साथ सेवाओं, या जब आप प्रति कंटेनर संसाधन सीमा की जरूरत है।
  • ]Dock systemd[ के साथ रचना - माइक्रोसर्विस स्टैक के लिए आदर्श जहां निर्भरता को आंतरिक रूप से रचना द्वारा संभाला जाता है, और आप पूरे समूह को प्रबंधित करने के लिए एक इकाई चाहते हैं।

समस्या निवारण आम मुद्दे

यहां तक कि सावधानीपूर्वक सेटअप के साथ, आप समस्याओं का सामना कर सकते हैं। नीचे लगातार गिरना और उनके समाधान हैं।

"डॉकर डेमन से कनेक्ट नहीं कर सकते" के साथ सेवा विफल

इसका मतलब यह है कि डोकर सॉकेट तैयार होने से पहले सेवा शुरू होती है। सुनिश्चित करें कि आपकी इकाई में और ]]]]] शामिल हैं। इसके अलावा चेक करें कि डोकर डेमन सक्षम है: ]

एक लूप में कंटेनर Restart

यदि कंटेनर तुरंत बाहर निकलता है, तो इसे ] और ] के अनुसार पुनरारंभ करना होगा। ] के साथ कंटेनर लॉग की जाँच करें। (जैसे, 30 सेकंड) और सेट एक व्यस्त लूप को रोकने के लिए।

सेवा स्वच्छ नहीं है

एक गलत तरीके से कॉन्फ़िगर किया गया कंटेनर को चलाने के लिए छोड़ सकता है। सत्यापित करें कि सही कंटेनर नाम का उपयोग करता है। ] का उपयोग करके कंटेनर को मजबूत करने के लिए अगर स्टॉप विफल हो जाता है।

पर्यावरण चर भारित नहीं

यदि आप ] का उपयोग करते हैं, तो फ़ाइल मौजूद है की पुष्टि करें और रूट द्वारा पठनीय है। उद्धरण के मुद्दों से बचें - परिवर्तनीय मूल्यों से व्यवस्थित स्ट्रिप्स उद्धरण। गुप्त इंजेक्शन के लिए, सिस्टमेड क्रेडेंशियल या एक समर्पित गुप्त प्रबंधक का उपयोग करके विचार करें।

सुरक्षा विचार

सिस्टम के माध्यम से डोकर कंटेनरों को चलाने से कुछ सुरक्षा बिंदु बढ़ जाती है:

  • हमेशा संभव हो तो सिस्टम सेवा को एक गैर-मूल उपयोगकर्ता के रूप में चलाएं (Us ] और ] निर्देश, लेकिन यह सुनिश्चित करें कि उपयोगकर्ता को डॉकर सॉकेट तक पहुंच प्राप्त हो या रूटलेस मोड में चल रहा हो)।
  • ] का उपयोग करके सिस्टम इकाइयों में पूरी तरह से आवश्यक नहीं होने तक बचें।
  • जब भी कंटेनर को मेजबान को लिखने की आवश्यकता नहीं होती है, तो पढ़ने वाले केवल बाइंडिंग माउंट (]]) का उपयोग करें।
  • लीवरेज सिस्टम (FLT: 56) और [[FLT: 57]]]] को भागने के खिलाफ इकाई को सख्त करने के लिए।
[Service]
ProtectSystem=strict
ReadWritePaths=/var/log/myapp
PrivateTmp=true
User=myappuser

बाह्य संसाधन

आगे पढ़ने के लिए, इन आधिकारिक संदर्भों का परामर्श करें:

निष्कर्ष

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

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