सभी Docker कंटेनर रोकें: चरण-दर-चरण मार्गदर्शिका

कंटेनरों को एक-एक करके रोकना आपके डेवलपमेंट वर्कफ़्लो को धीमा कर सकता है और माइक्रोसर्विसेज़ या मल्टी-कंटेनर एप्लिकेशन संभालते समय त्रुटियों का कारण बन सकता है। 

इस गाइड में, मैं कई तरीके बताऊँगा जिनसे आप सभी चल रहे कंटेनरों को समाप्त कर सकते हैं।

इस ट्यूटोरियल के अंत तक, आप सक्षम होंगे:  

• समझना कि Docker सिग्नल और ग्रेस पीरियड को कैसे संभालता है
• सरल CLI तकनीकों और फ़िल्टर का उपयोग करके सभी कंटेनर रोकना
• सुगम वर्कफ़्लो के लिए Docker Compose और कस्टम उपनामों का लाभ उठाना 

Docker कंटेनर टर्मिनेशन को समझना

कंटेनरों को बल्क में रोकने से पहले, यह समझना उपयोगी है कि Docker पर्दे के पीछे शटडाउन को कैसे ऑर्केस्ट्रेट करता है।

सिग्नल-आधारित प्रोसेस मैनेजमेंट

Docker ज़बरदस्ती टर्मिनेशन से पहले ग्रेसफुल शटडाउन का अनुरोध करने के लिए Unix सिग्नल का उपयोग करता है। docker stop कमांड का डिफ़ॉल्ट व्यवहार है: 

1. SIGTERM कंटेनर की मुख्य प्रक्रिया को भेजना।  
2. अधिकतम 10 सेकंड तक प्रतीक्षा करना (जिसे -t/--time से कॉन्फ़िगर किया जा सकता है)।  
3. यदि प्रक्रिया बंद नहीं हुई है, तो SIGKILL भेजना।

• SIGTERM: प्रक्रिया से विनम्रतापूर्वक सफाई कर बाहर निकलने का अनुरोध करता है।  
• ग्रेस पीरियड: ऐप्लिकेशनों को लॉग फ्लश करने, कनेक्शन बंद करने या स्टेट सहेजने का समय देता है।  
• SIGKILL: किसी भी अनुत्तरदायी प्रक्रिया को तुरंत समाप्त कर देता है।

कमांड-लाइन इंटरफ़ेस (CLI) के यांत्रिकी

डिफ़ॉल्ट रूप से, docker stop एक समय में एक कंटेनर संभालता है। आप शेल फीचर्स का उपयोग करके इसे कई कंटेनर रोकने तक बढ़ा सकते हैं।

# Stop a single container named my_container
docker stop my_containerसंचालित द्वारा

यह my_container को SIGTERM भेजता है और आवश्यकता होने पर SIGKILL जारी करने से पहले डिफ़ॉल्ट 10 सेकंड प्रतीक्षा करता है।

# Stop all running containers at once
docker stop $(docker ps -q)संचालित द्वारा

यहाँ, docker ps -q सभी चल रहे कंटेनरों के ID सूचीबद्ध करता है; वे ID docker stop को पास की जाती हैं, जो कंटेनरों को क्रमवार बंद करता है।

टर्मिनल का स्क्रीनशॉट जिसमें docker ps -q का आउटपुट docker stop में पाइप किया गया है

इन अवधारणाओं को और विस्तार से समझने के लिए, Containerization and Virtualization Concepts देखें।

docker stop और docker kill की तुलना

ग्रेसफुल बनाम फोर्सफुल टर्मिनेशन के बीच चयन करने से आप अनचाहे परिणामों से बचते हैं।

ग्रेसफुल बनाम तुरंत टर्मिनेशन

सिग्नल कस्टमाइज़ेशन

दोनों कमांड डिफ़ॉल्ट को ओवरराइड करने के लिए --signal फ़्लैग सपोर्ट करते हैं:

# Send SIGINT instead of SIGTERM
docker stop --signal=SIGINT my_containerसंचालित द्वारा

ऊपर दिया गया कमांड प्रक्रियाओं को कस्टम क्लीनअप के लिए SIGINT ट्रैप करने देता है।

# Kill all containers with SIGUSR1
docker kill --signal=SIGUSR1 $(docker ps -q)संचालित द्वारा

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

एडवांस्ड कंटेनर स्टॉपिंग स्ट्रैटेजीज़

फ़िल्टरिंग और ऑटोमेटिंग के जरिए कंटेनर रोकना विशेष रूप से बड़े परिवेशों में अधिक सटीक DevOps वर्कफ़्लो सक्षम करता है।  

मूल बातें समझने के बाद, आप यह फाइन-ट्यून कर सकते हैं कि किन कंटेनरों को रोकना है और प्रक्रिया को कैसे स्वचालित करना है।

फ़िल्टर्ड कंटेनर टर्मिनेशन

फ़िल्टर से आप इमेज नाम, स्टेटस, या लेबल जैसी विशेषताओं के आधार पर कंटेनरों को लक्षित कर सकते हैं:

# Stop containers running the my_image:latest image
docker stop $(docker ps --filter "ancestor=my_image:latest" -q)संचालित द्वारा

ऊपर दिया गया कमांड केवल my_image:latest पर आधारित कंटेनरों को रोकता है, जो मल्टी-सर्विस प्रोजेक्ट्स में लक्षित नियंत्रण देता है।

उपयोग परिदृश्य:  

• इमेज टैग द्वारा टेस्ट कंटेनर रोकें (--filter "ancestor=test:latest")  
• लेबल द्वारा कंटेनर रोकें (--filter "label=env=dev")

docker ps --filter के उपयोग का टर्मिनल स्क्रीनशॉट

Docker Compose के साथ स्वचालित क्लीनअप

यदि आपकी सेवाएँ docker-compose.yml फ़ाइल में परिभाषित हैं, तो एक ही कमांड सभी संबंधित कंटेनरों को रोक देता है:

docker-compose stopसंचालित द्वारा

यह एक स्वच्छ शटडाउन के लिए आपकी सर्विस डिपेंडेंसी और कॉन्फ़िगर किए गए टाइमआउट का सम्मान करता है।

और उन्नत तकनीकों के लिए, आप Intermediate Docker कोर्स पर विचार कर सकते हैं।

उपनाम-आधारित वर्कफ़्लो ऑप्टिमाइज़ेशन

दोहराए जाने वाले कार्यों के लिए, शेल उपनाम टाइपिंग और कॉन्टेक्स्ट स्विचिंग कम करते हैं:

# Add this to ~/.bashrc or ~/.zshrc
alias ds='docker stop $(docker ps -q)'संचालित द्वारा

शेल को रीलोड करने के बाद, ds चलाने से एक ही कीस्ट्रोक में सभी कंटेनर रुक जाते हैं—तेज़ क्लीनअप के लिए आदर्श।

Ubuntu WSL में सभी चल रहे कंटेनर रोकने के लिए 'ds' उपनाम का उपयोग

ऑपरेशनल सर्वोत्तम प्रथाएँ

अपने वातावरण को स्थिर और उच्च-प्रदर्शन बनाए रखने के लिए सुरक्षित शटडाउन रूटीन और नियमित क्लीनअप लागू करें।

• अपनी एप्लिकेशन कोड में सिग्नल हैंडलर लागू करें ताकि कनेक्शन बंद हों और लॉग फ्लश हों।  
• docker kill को आपातकालीन हस्तक्षेप के लिए सुरक्षित रखें; डेटा असंगतियों से बचें।  
• अपने एप्लिकेशन की क्लीनअप ज़रूरतों के आधार पर ग्रेस पीरियड (-t/--time) समायोजित करें।  
• Docker Prune: A Complete Guide with Hands-On Examples में बताए अनुसार docker system prune जैसे कमांड के साथ पोस्ट-शटडाउन क्लीनअप ऑटोमेट करें।
• टर्मिनेशन समस्याओं का निदान करने के लिए शटडाउन इवेंट (टाइमस्टैम्प और एग्जिट कोड) लॉग करें।

सामान्य समस्याओं का निवारण

सीधे-सादे कमांड भी अटक सकते हैं—इन्हें इस तरह संबोधित करें।

ज़ॉम्बी प्रक्रियाएँ और अनाथ वॉल्यूम

ज़बरदस्ती टर्मिनेशन से बासी प्रक्रियाएँ या अनाथ वॉल्यूम पीछे छूट सकते हैं, जो होस्ट संसाधन और डिस्क स्पेस खा सकते हैं। क्लीनअप के लिए:

# Remove dangling volumes
docker volume pruneसंचालित द्वारा

यह उन सभी वॉल्यूम को हटा देता है जिनका किसी कंटेनर से संदर्भ नहीं है।

शेष Docker डेमन प्रक्रियाएँ जाँचें:

ps aux | grep dockerdसंचालित द्वारा

यदि कोई आवारा dockerd चाइल्ड प्रक्रिया बनी रहती है, तो उन्हें मैन्युअली समाप्त करें।

वास्तविक उदाहरण: एक प्रोजेक्ट में, जब एक माइग्रेशन अटका तो मैंने एक डेटाबेस कंटेनर पर docker kill का उपयोग किया। अचानक किल ने DB को ट्रांज़ैक्शन लॉग फ्लश करने से रोक दिया, जिससे InnoDB टेबल करप्ट हो गए। हमें बैकअप से रिस्टोर करना और बिनलॉग रीप्ले करने पड़े, जिससे 30 मिनट से अधिक का डाउनटाइम हुआ। इससे बचने के लिए, विस्तारित टाइमआउट के साथ docker stop को प्राथमिकता दें या अपनी एप्लिकेशन में उचित SIGTERM हैंडलर जोड़ें।

Permission denied त्रुटियाँ

उचित विशेषाधिकारों के बिना Docker कमांड चलाने से अक्सर त्रुटियाँ आती हैं:

• कमांड के आगे sudo जोड़ें या docker समूह के उपयोगकर्ता के रूप में चलाएँ।  
• अपने उपयोगकर्ता को docker समूह में जोड़ें और दोबारा लॉग-इन करें:

sudo usermod -aG docker $USERसंचालित द्वारा

लॉग आउट और फिर लॉग इन करने के बाद, आप बिना sudo के Docker कमांड चला सकते हैं। CI वातावरण में, पाइपलाइन विफलताओं से बचने के लिए सुनिश्चित करें कि रनर उपयोगकर्ता Docker समूह का सदस्य है।

Windows-विशिष्ट बातें

Windows PowerShell पर, सब-कमांड को कोष्ठक में रखें और Administrator के रूप में चलाएँ:

docker stop (docker ps -q)संचालित द्वारा

उच्चाधिकारों के साथ PowerShell लॉन्च करने से फ़ायरवॉल या एक्सेस-कंट्रोल समस्याएँ रुकती हैं। यदि आपको TLS हैंडशेक त्रुटियाँ दिखें, तो सत्यापित करें कि Docker Desktop के डेमन कॉन्फ़िगरेशन आपके PowerShell वातावरण से मेल खाते हैं।

निष्कर्ष

अपने सभी Docker कंटेनर कुशलता से रोकना समय बचाता है, संसाधन बचाता है, और आपके डेवलपमेंट वर्कफ़्लो में मानवीय त्रुटि को कम करता है। Docker के सिग्नल हैंडलिंग को समझकर, CLI फ़िल्टर का लाभ उठाकर, Docker Compose का उपयोग करके, और सरल उपनाम बनाकर आप एक स्वच्छ और पूर्वानुमानित वातावरण बनाए रख सकते हैं। 

अपनी कंटेनराइज़ेशन विशेषज्ञता को गहरा करने के लिए Containerization and Virtualization with Docker and Kubernetes ट्रैक या Intermediate Docker कोर्स देखें।

हैप्पी कंटेनराइज़िंग—और स्वच्छ, कुशल Docker वर्कफ़्लो के नाम!