परिचय

कंटेनर चलाने और docker-compose.yml लिखने के बारे में कई लेख हैं। लेकिन मेरे लिए लंबे समय तक यह सवाल स्पष्ट नहीं था कि कुछ कंटेनर को सही ढंग से कैसे आगे बढ़ना है अगर कुछ कंटेनर को तब तक शुरू नहीं करना चाहिए जब तक कि एक कंटेनर अपने अनुरोधों को संसाधित करने या कुछ मात्रा में काम पूरा करने के लिए तैयार न हो।

व्यक्तिगत डॉकरों को लॉन्च करने के बजाय, हम डॉकटर-कंपोज का सक्रिय रूप से उपयोग करने के बाद यह प्रश्न प्रासंगिक हो गए।

इसके लिए क्या है?

दरअसल, कंटेनर ए में एप्लिकेशन कंटेनर ए में सेवा की उपलब्धता पर निर्भर करता है और स्टार्टअप पर, कंटेनर बी में आवेदन इस सेवा को प्राप्त नहीं करता है। इसे क्या करना चाहिए?

दो विकल्प हैं:

• पहला मरना है (अधिमानतः एक त्रुटि कोड के साथ)
• दूसरा इंतजार करना है, और फिर वैसे भी मरना है, अगर कंटेनर बी में आवेदन आवंटित समय के लिए प्रतिक्रिया नहीं देता है

कंटेनर B की मृत्यु हो जाने के बाद, docker-compose (पाठ्यक्रम के विन्यास के आधार पर) इसे पुनः आरंभ करेगा और कंटेनर B में अनुप्रयोग फिर से कंटेनर A में सेवा तक पहुँचने का प्रयास करेगा।

यह तब तक जारी रहेगा जब तक कंटेनर ए में सेवा अनुरोधों का जवाब देने के लिए तैयार नहीं होती, या जब तक हम ध्यान नहीं देते कि कंटेनर लगातार ओवरलोड हो रहा है।
और वास्तव में, मल्टी-कंटेनर आर्किटेक्चर के लिए यह सामान्य तरीका है।

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

मुझे लगता है कि आप अभी भी कुछ उपयोग के मामले दे सकते हैं। लेकिन सबसे महत्वपूर्ण बात, आपको यह समझने की आवश्यकता है कि आप ऐसा क्यों कर रहे हैं। अन्यथा, मानक डॉकटर-कंपोज टूल का उपयोग करना बेहतर है।

थोड़ी विचारधारा

यदि आप ध्यान से प्रलेखन को पढ़ते हैं, तो वहां सब कुछ लिखा जाता है। अर्थात्, प्रत्येक
इकाई स्वतंत्र है और सभी सेवाओं के साथ देखभाल करनी चाहिए
जिसके साथ वह काम करने जा रहा है, उसके लिए उपलब्ध हैं।

इसलिए, प्रश्न कंटेनर को शुरू करने या न करने के लिए नहीं है, लेकिन करने के लिए है
कंटेनर के अंदर, सभी आवश्यक सेवाओं की तत्परता की जाँच करें और केवल
तब कंटेनर एप्लिकेशन पर नियंत्रण स्थानांतरित करें।

इसे कैसे लागू किया जाता है

इस समस्या को हल करने के लिए, डॉकटर-कम्पोज़िट विवरण ने मुझे बहुत मदद की, इसका यह हिस्सा है
और प्रविष्टि और cmd के समुचित उपयोग के बारे में एक लेख ।

तो हमें क्या प्राप्त करने की आवश्यकता है:

• एक परिशिष्ट A है जिसे हमने कंटेनर A में लपेटा है
• यह शुरू होता है और पोर्ट 8000 पर ओके का जवाब देना शुरू करता है
• और इसके अलावा, आवेदन बी है, जिसे हम कंटेनर बी से शुरू करते हैं, लेकिन यह काम करना शुरू कर देना चाहिए आवेदन ए की तुलना में पहले ए पोर्ट 8000 पर अनुरोधों का जवाब देना शुरू कर देगा

आधिकारिक दस्तावेज इस समस्या को हल करने के दो तरीके प्रदान करता है।

पहला कंटेनर में अपना खुद का प्रवेश बिंदु लिखना है, जो सभी जांच करेगा, और फिर काम करने वाले आवेदन को शुरू करेगा।

दूसरा है पहले से लिखे हुए बैच फ़ाइल wa-for-it.sh का उपयोग करना।
हमने दोनों तरह से कोशिश की।

अपनी खुद की प्रविष्टि लिखना

एंट्रीपॉइंट क्या है?

यह केवल निष्पादन योग्य फ़ाइल है जिसे आप ENTRYPOINT फ़ील्ड में डॉकरीफ़ाइल में कंटेनर बनाते समय निर्दिष्ट करते हैं। यह फ़ाइल, जैसा कि पहले ही उल्लेख किया गया है, चेक करती है, और फिर कंटेनर का मुख्य अनुप्रयोग लॉन्च करती है।

तो हमें क्या मिलता है:

एक एंट्रीपॉइंट फ़ोल्डर बनाएँ।

इसके दो सबफोल्डर्स हैं- कंटेनर_ए और कंटेनर_ । हम उनमें अपने कंटेनर बनाएंगे।

कंटेनर ए के लिए, आइए अजगर पर एक सरल http सर्वर लें। वह, शुरू करने के बाद, पोर्ट 8000 पर अनुरोध प्राप्त करने के लिए प्रतिक्रिया करना शुरू कर देता है।

हमारे प्रयोग को अधिक स्पष्ट बनाने के लिए, हमने सर्वर शुरू करने से पहले 15 सेकंड की देरी निर्धारित की।

यह कंटेनर ए के लिए निम्नलिखित डॉकटर फ़ाइल को चालू करता है:

FROM python:3 EXPOSE 8000 CMD sleep 15 && python3 -m http.server --cgi 

कंटेनर B के लिए, कंटेनर B के लिए निम्न डॉकटर फ़ाइल बनाएं:

 FROM ubuntu:18.04 RUN apt-get update RUN apt-get install -y curl COPY ./entrypoint.sh /usr/bin/entrypoint.sh ENTRYPOINT [ "entrypoint.sh" ] CMD ["echo", "!!!!!!!! Container_A is available now !!!!!!!!"] 

और एक ही फ़ोल्डर में हमारे entrypoint.sh निष्पादन योग्य डाल दिया। हमारे पास ऐसा होगा

 #!/bin/bash set -e host="conteiner_a" port="8000" cmd="$@" >&2 echo "!!!!!!!! Check conteiner_a for available !!!!!!!!" until curl http://"$host":"$port"; do >&2 echo "Conteiner_A is unavailable - sleeping" sleep 1 done >&2 echo "Conteiner_A is up - executing command" exec $cmd 

कंटेनर B में क्या चल रहा है:

• जब यह शुरू होता है, तो यह ENTRYPOINT शुरू होता है, अर्थात एंट्री पॉइंट
• entrypoint.sh , कर्ल का उपयोग करते हुए, कंटेनर ए के लिए मतदान 8000 पोर्ट शुरू करता है। यह तब तक करता है जब तक कि उसे 200 प्रतिक्रिया नहीं मिलती (यानी इस मामले में कर्ल एक शून्य परिणाम के साथ समाप्त हो जाएगा और लूप समाप्त हो जाएगा)
• जब 200 प्राप्त होता है, तो लूप समाप्त होता है और $ cmd चर में निर्दिष्ट कमांड पर नियंत्रण गुजरता है। और यह इंगित करता है कि हमने सीएमडी क्षेत्र में डॉक फ़ाइल में क्या संकेत दिया था, अर्थात्। इको "!!! कंटेनर_ए अब उपलब्ध है !!!!!!!!" ऐसा क्यों है, उपरोक्त लेख में वर्णित है
• हम छापते हैं - !!! कंटेनर_ए अब उपलब्ध है !!! और समापन।

हम डॉकटर-कंपोज के साथ सब कुछ शुरू करेंगे।

docker-compose.yml यहाँ हमारे पास यह है:

 version: '3' networks: waiting_for_conteiner: services: conteiner_a: build: ./conteiner_A container_name: conteiner_a image: conteiner_a restart: unless-stopped networks: - waiting_for_conteiner ports: - 8000:8000 conteiner_b: build: ./conteiner_B container_name: conteiner_b image: waiting_for_conteiner.entrypoint.conteiner_b restart: "no" networks: - waiting_for_conteiner 

यहाँ, conteiner_a में, बंदरगाहों को निर्दिष्ट करना आवश्यक नहीं है : 8000: 8000 । यह बाहर से चल रहे http सर्वर के संचालन को सत्यापित करने में सक्षम होने के लिए किया गया था।

इसके अलावा, कंटेनर बी बंद होने के बाद पुनरारंभ नहीं होता है।

हम लॉन्च करते हैं:

 docker-compose up —-build 

हम देखते हैं कि 15 सेकंड के लिए कंटेनर ए की अनुपलब्धता के बारे में एक संदेश है, और फिर

 conteiner_b | Conteiner_A is unavailable - sleeping conteiner_b | % Total % Received % Xferd Average Speed Time Time Time Current conteiner_b | Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> conteiner_b | <html> conteiner_b | <head> conteiner_b | <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> conteiner_b | <title>Directory listing for /</title> conteiner_b | </head> conteiner_b | <body> conteiner_b | <h1>Directory listing for /</h1> conteiner_b | <hr> conteiner_b | <ul> conteiner_b | <li><a href=".dockerenv">.dockerenv</a></li> conteiner_b | <li><a href="bin/">bin/</a></li> conteiner_b | <li><a href="boot/">boot/</a></li> conteiner_b | <li><a href="dev/">dev/</a></li> conteiner_b | <li><a href="etc/">etc/</a></li> conteiner_b | <li><a href="home/">home/</a></li> conteiner_b | <li><a href="lib/">lib/</a></li> conteiner_b | <li><a href="lib64/">lib64/</a></li> conteiner_b | <li><a href="media/">media/</a></li> conteiner_b | <li><a href="mnt/">mnt/</a></li> conteiner_b | <li><a href="opt/">opt/</a></li> conteiner_b | <li><a href="proc/">proc/</a></li> conteiner_b | <li><a href="root/">root/</a></li> conteiner_b | <li><a href="run/">run/</a></li> conteiner_b | <li><a href="sbin/">sbin/</a></li> conteiner_b | <li><a href="srv/">srv/</a></li> conteiner_b | <li><a href="sys/">sys/</a></li> conteiner_b | <li><a href="tmp/">tmp/</a></li> conteiner_b | <li><a href="usr/">usr/</a></li> conteiner_b | <li><a href="var/">var/</a></li> conteiner_b | </ul> conteiner_b | <hr> conteiner_b | </body> conteiner_b | </html> 100 987 100 987 0 0 98700 0 --:--:-- --:--:-- --:--:-- 107k conteiner_b | Conteiner_A is up - executing command conteiner_b | !!!!!!!! Container_A is available now !!!!!!!! 

हमें आपके अनुरोध का जवाब मिल गया है, प्रिंट करें !!! कंटेनर_ए अब उपलब्ध है !!!!!!!! और समापन।

प्रतीक्षा का उपयोग करते हुए

यह कहने लायक है कि यह रास्ता हमारे लिए काम नहीं आया जैसा कि प्रलेखन में वर्णित है।
अर्थात्, यह ज्ञात है कि अगर ENTRYPOINT और CMD को डॉकफाइल में लिखा जाता है, तो जब कंटेनर शुरू होता है, तो ENTRYPOINT से कमांड निष्पादित किया जाएगा, और CMD की सामग्री को इस पैरामीटर पर पास किया जाएगा।

यह भी ज्ञात है कि डॉकरीफाइल में निर्दिष्ट ENTRYPOINT और CMD को docker -compose.yml में पुनः परिभाषित किया जा सकता है।

प्रतीक्षा- for-it.sh स्टार्टअप प्रारूप इस प्रकार है:

 wait-for-it.sh __ -- ___ 

फिर, जैसा कि लेख में संकेत दिया गया है, हम docker -compose.yml में एक नए ENTRYPOINT को परिभाषित कर सकते हैं, और CMD को डॉकरफाइल से प्रतिस्थापित किया जाएगा ।

तो, हम प्राप्त करते हैं:

कंटेनर A के लिए डॉकटर फ़ाइल अपरिवर्तित रहती है:

 FROM python:3 EXPOSE 8000 CMD sleep 15 && python3 -m http.server --cgi 

कंटेनर बी के लिए डॉकर फ़ाइल

 FROM ubuntu:18.04 COPY ./wait-for-it.sh /usr/bin/wait-for-it.sh CMD ["echo", "!!!!!!!! Container_A is available now !!!!!!!!"] 

इस तरह दिखता है

 version: '3' networks: waiting_for_conteiner: services: conteiner_a: build: ./conteiner_A container_name: conteiner_a image: conteiner_a restart: unless-stopped networks: - waiting_for_conteiner ports: - 8000:8000 conteiner_b: build: ./conteiner_B container_name: conteiner_b image: waiting_for_conteiner.wait_for_it.conteiner_b restart: "no" networks: - waiting_for_conteiner entrypoint: ["wait-for-it.sh", "-s" , "-t", "20", "conteiner_a:8000", "--"] 

हम वेट-फॉर-इट कमांड चलाते हैं, इसे 20 सेकंड तक प्रतीक्षा करने के लिए कहें जब तक कंटेनर A जीवन में नहीं आता है, और एक और पैरामीटर "-" निर्दिष्ट करें, जो कि प्रतीक्षा-के-लिए मापदंडों को उस प्रोग्राम से अलग करना चाहिए जो इसके पूरा होने के बाद लॉन्च होगा।

हम कोशिश करते हैं!
और दुर्भाग्य से, हमें कुछ नहीं मिलता है।

अगर हम यह देखते हैं कि हम किस तर्क के लिए प्रतीक्षा करते हैं, तो हम देखेंगे कि केवल हमने जो प्रविष्टि बिंदु में निर्दिष्ट किया है, वह उसमें पारित हो गया है , कंटेनर से सीएमडी संलग्न नहीं है।

काम करने का विकल्प

फिर, केवल एक विकल्प है। डॉकरफाइल में हमने सीएमडी में क्या निर्दिष्ट किया है, हमें कमांड को docker-compose.yml में स्थानांतरित करना होगा।

फिर, कंटेनर B के डॉकरीफाइल को अपरिवर्तित छोड़ दें , और docker-compose.yml इस तरह दिखेगा:

 version: '3' networks: waiting_for_conteiner: services: conteiner_a: build: ./conteiner_A container_name: conteiner_a image: conteiner_a restart: unless-stopped networks: - waiting_for_conteiner ports: - 8000:8000 conteiner_b: build: ./conteiner_B container_name: conteiner_b image: waiting_for_conteiner.wait_for_it.conteiner_b restart: "no" networks: - waiting_for_conteiner entrypoint: ["wait-for-it.sh", "-s" ,"-t", "20", "conteiner_a:8000", "--"] command: ["echo", "!!!!!!!! Container_A is available now !!!!!!!!"] 

और इस संस्करण में, यह काम करता है।

निष्कर्ष में, यह कहा जाना चाहिए कि हमारी राय में, सही तरीका पहला है। यह सबसे बहुमुखी है और आपको किसी भी तरह से तत्परता की जांच करने की अनुमति देता है। प्रतीक्षा-के लिए यह सिर्फ एक उपयोगी उपयोगिता है जिसे आप या तो अलग से या अपने प्रविष्टि बिंदु पर एम्बेड करके उपयोग कर सकते हैं।