1 पॉइंट द्वारा chcv0313 2025-12-26 | 9 टिप्पणियां | WhatsApp पर शेयर करें

एक ऐसा सर्वर है जिसे दर्जनों लोग साझा रूप से इस्तेमाल करते हैं.

हर व्यक्ति अपने-अपने project को container के ज़रिए serve कर रहा है.

लेकिन जब server reboot जैसी कोई समस्या होती है, तो admin के लिए इन containers को संभालना मुश्किल हो जाता है.

क्या सामान्य समय में सबको अपना Docker container चलाने वाला command जमा करने के लिए कहना चाहिए, और ज़रूरत पड़ने पर वही command चलानी चाहिए,
या फिर इसे Docker Compose में बनवाकर हर project के folder में जाकर एक-एक करके compose up चलाना चाहिए, वगैरह?

एक admin के तौर पर कई containers को कैसे manage किया जाए, इस बारे में सलाह चाहिए.

9 टिप्पणियां

 
chcv0313 2025-12-31

जवाब देने वाले सभी लोगों का धन्यवाद। लगता है इस साल का लक्ष्य Kubernetes को अपनाना रखना होगा।

 
popopo 2025-12-28

कंटेनर को daemonize करके OS बूट होने पर कंटेनर भी चलने लगें, यह सबसे आसान तरीका है.

  • रीस्टार्ट से पहले उन्हें एक-एक करके सामान्य रूप से बंद भी किया जा सकता है.

अगर यह EL (Enterprise Linux, RHEL परिवार के लिए सामूहिक नाम) श्रृंखला है, तो कंटेनर को systemd service के रूप में रजिस्टर किया जा सकता है. इसे Quadlet कहा जाता है.

 
bungker 2025-12-27

सिर्फ सवाल देखें तो depend on, restart always या unless stoped से समाधान संभव लगता है, लेकिन लगता है कि सवाल में शामिल न की गई कोई मुश्किल स्थिति भी होगी। फिर भी, अगर यूज़र कुछ दर्जन तक हैं, तो आखिरकार आपको Kubernetes पर जाना ही पड़ेगा।

जैसा सवाल है, वैसा ही AI से पूछें तब भी आपको जवाब मिल जाएगा।

 
tujuc 2025-12-27
  1. आपने infrastructure कहाँ रखा है? AWS? सीधे या server hosting? Azure?
  2. क्या आप इसे अकेले manage कर रहे हैं?
  3. अभी तक आपने किस स्थिति में काम किया है, और आपको कहाँ तक जानकारी है?

ऊपर की जानकारी हो तो बात करना थोड़ा आसान होगा।

अगर सिर्फ़ आपने जो बताया है, उसी के आधार पर जवाब दूँ तो....

मुझे समझ नहीं आ रहा कि container run command की ज़रूरत क्यों है। उनसे कहिए कि एक compose file बना दें, और उसी के आधार पर सब कुछ एक ही command (compose command) से उठाया जा सके, ऐसा setup करना सबसे अच्छा रहेगा.

:) आप admin हैं, तो ऐसा बनाकर देने के लिए कहिए, दूसरे लोग कर देंगे, बस थोड़ा push कीजिए :)

मेरे हिसाब से k8s ऐसा solution है जिसका अकेले manage करने वाले environment में बोझ काफ़ी बड़ा होता है, इसलिए मैं इसे ज़्यादा recommend नहीं करता।
मेरा हमेशा मानना है कि infrastructure को जितना हो सके उतना simple रखना सबसे अच्छा है.

 
chcv0313 2025-12-27

यह on-premise सर्वर 4 हैं।
मैं यह अकेले संभालता हूँ।
सिक्योरिटी पास होने के बाद कंपनी में Docker आए अब 4 महीने हो चुके हैं, और k8s के बारे में मुझे सिर्फ़ concepts पता हैं। Docker के लिए Harbor लागू करना भी जल्द ही मुझे ही करना होगा, और Harbor लागू होने के बाद Docker Hub ब्लॉक कर दिया जाएगा। शायद सिर्फ़ मेरे लिए ही Docker Hub खुला रहेगा, और जब कोई अनुरोध आएगा तो मैं ही Docker Hub से image लाकर उसे आंतरिक
Harbor पर अपलोड करूँगा।

Compose command से सब कुछ चलाना, और हर project के लिए folder में जाकर एक-एक करके compose up करना मुझे अव्यावहारिक लगा इसलिए मैंने ऐसा नहीं किया। उसकी जगह मैंने Docker command को absolute path के साथ देने को कहा था, लेकिन हाल के दिनों में यह विचार मन से नहीं निकल रहा कि शायद यह भी गलत approach है।

 
byun1114 2025-12-27

क्या Docker restart option देना ही काफ़ी नहीं है?

 
click 2025-12-26

ऐसे मामलों में Kubernetes का इस्तेमाल करना और हर user को अलग-अलग context असाइन करना बेहतर होता है.
user-वार यह अनुमति सीमित करना भी संभव है कि वे केवल उसी context का उपयोग कर सकें.

 
cafedead 2025-12-26

k8s का उपयोग करते हैं।

 
selene 2025-12-29

मेरी सोच भी tujuc-san जैसी ही है, लेकिन मुझे लगता है कि किसी अनुभवी व्यक्ति के बिना अकेले k8s लागू करके उसे बिना किसी समस्या के स्थिर रूप से चलाना काफ़ी जोखिम भरा हो सकता है.

लेकिन आपने कहा कि 4 सर्वरों को दर्जनों लोग साझा रूप से इस्तेमाल कर रहे हैं, इसलिए स्थिति थोड़ी अस्पष्ट है,
फिर भी जुड़े हुए लोगों की संख्या के आधार पर देखने के बजाय, अगर सर्वर प्रोग्रामों की संख्या बहुत ज़्यादा है और स्थिति काफ़ी जटिल है, तो k8s सीखने पर विचार करना अच्छा रहेगा.

अगर मैं आपकी जगह होता, तो शायद नीचे दिए गए चरणों के अनुसार वातावरण को बेहतर बनाता.

  1. ऐसे उपाय करें कि सर्वर प्रोग्राम कभी भी बंद हो जाएँ तो भी समस्या न हो => इसमें graceful shutdown लागू करना, stateless तरीके से काम करने के लिए refactoring करना आदि शामिल है. (या इंजीनियरों से ऐसा करने का अनुरोध)
  2. सर्वर प्रोग्रामों का containerization और सामान्यीकरण => हर service के लिए Dockerfile और docker compose फ़ाइल लिखें, ताकि एक ही command चलाने पर वे निश्चित रूप से शुरू हों.
  3. ऐसा प्रबंधन करें कि administrator को छोड़कर किसी दूसरे engineer को सर्वर में सीधे login करने की ज़रूरत न पड़े => Jenkins/GitHub Actions/AWS CodePipeline जैसे मनचाहे CI/CD प्लेटफ़ॉर्म का उपयोग करके GitOps जैसा सेटअप बनाया जा सकता है. सिर्फ़ यह स्तर हासिल हो जाए तो bhi engineer लोग redeploy/reboot को pipeline दोबारा चलाने भर से पर्याप्त रूप से नियंत्रित कर पाएँगे.
  4. उसके बाद, जैसा अन्य लोगों ने कहा, आगे उन्नयन करें (K8s और ArgoCD आदि को अपनाना)