network_mode: service:vpn और गुम हुआ db होस्टनाम

आप ऐप में network_mode: service:vpn जोड़ते हैं, स्टैक को रीस्टार्ट करते हैं, और ऐप मर जाता है क्योंकि db अब रिज़ॉल्व नहीं होता। compose फ़ाइल में किसी का नाम नहीं बदला गया, इसलिए स्पष्ट संदिग्ध DNS और डेटाबेस हैं। असली बदलाव छोटा और अजीब है: ऐप उस Compose नेटवर्क का सदस्य होना बंद कर चुका है जहाँ वह नाम मौजूद है। जब तक आप तय नहीं करते कि डेटाबेस को किस नेमस्पेस से जवाब देना चाहिए, हर होस्टनाम सुधार एक अनुमान है।

db होस्टनाम रिज़ॉल्व होना क्यों बंद हुआ

network_mode इस्तेमाल करने वाली सेवा का Compose नेटवर्क पर अपना कोई पता नहीं होता; वह नामित सेवा का नेमस्पेस उधार लेती है। वह नेमस्पेस अपने इंटरफ़ेस, रूट, पोर्ट स्पेस और रिज़ॉल्वर लेकर आता है, और वह ऐप के backend नेटवर्क से जुड़ाव को बदल देता है। db नाम कभी अमूर्त नहीं था: वह उसी नेटवर्क पर रहता था और उसके अंतर्निहित DNS से रिज़ॉल्व होता था। जुड़ाव हटा दें और नाम के पास रिज़ॉल्व होने की कोई जगह नहीं बचती।

इसे होस्ट से नहीं, कंटेनरों के भीतर से पुष्ट करें। ऐसा लुकअप जो ऐप में विफल हो पर डेटाबेस कंटेनर में सफल हो, इसका अर्थ है कि नाम ठीक है और सदस्यता नहीं। वह परिणाम सुधार को ऐप की रिज़ॉल्वर सेटिंग्स के बजाय compose टोपोलॉजी में रखता है।

फ़ाइल संपादित करने से पहले तीन सवाल

इनका क्रम से जवाब दें, क्योंकि हर एक टोपोलॉजी को सँकरा करता है। डेटाबेस किस पर जवाब दे: उस होस्टनाम पर जो दूसरे कंटेनर इस्तेमाल करते हैं, या केवल loopback पर ऐप को? क्या ऐप को होस्ट पर पोर्ट प्रकाशित करना चाहिए, और कौन सी सेवा उसका मालिक होगी? क्या डेटाबेस होस्ट या किसी दूसरी मशीन से पहुँचने योग्य होना चाहिए, या केवल टनल के भीतर से?

अगर डेटाबेस को अपना नाम चाहिए और ऐप कुछ भी प्रकाशित नहीं करता, तो उन्हें अलग जुड़ावों पर रखें। अगर ऐप को पोर्ट प्रकाशित करना है और सब कुछ टनल से गुज़रता है, तो डेटाबेस को VPN नेमस्पेस में रखें और loopback इस्तेमाल करें। दोनों मिलाने से ऐसा स्टैक बनता है जो साफ़ शुरू होता है और कनेक्ट के समय विफल हो जाता है।

डेटाबेस को वहीं रहने दें जहाँ वह है

छोटा बदलाव नेमस्पेस के मालिक को उस नेटवर्क से जोड़ता है जिसमें पहले से डेटाबेस है। ऐप उस जुड़ाव को विरासत में पाता है क्योंकि वह vpn स्टैक साझा करता है, और db ठीक पहले की तरह रिज़ॉल्व होता है।

services:
  vpn:
    networks:
      - backend
  app:
    network_mode: service:vpn
  db:
    networks:
      - backend
networks:
  backend:

ऐप में networks भी न जोड़ें। Compose उसी सेवा में network_mode के साथ उस गुण को अस्वीकार करता है, और त्रुटि जोड़ी की नहीं, फ़ाइल की ओर इशारा करती है। अगर VPN क्लाइंट अपने नेमस्पेस के भीतर backend गंतव्य को फ़िल्टर करता है, तो उसकी समर्थित स्थानीय-नेटवर्क नीति भी समायोजित करें; साझा जुड़ाव रास्ता देता है पर उस फ़िल्टर को रद्द नहीं करता।

डेटाबेस को नेमस्पेस में ले जाएँ

बड़ा बदलाव डेटाबेस को उसी नेमस्पेस में रखता है और ऐप को असली पोर्ट के साथ 127.0.0.1 की ओर इंगित करता है। दो प्रोसेस केवल इसलिए कि वे अलग कंटेनरों में शुरू हुए, एक ही पता और पोर्ट दोनों बाइंड नहीं कर सकते, इसलिए जो डेटाबेस wildcard पते पर भी सुनता है वह ऐसा करने वाले किसी भी अन्य के साथ टकराएगा। हटाने से पहले श्रोता की जाँच करें।

प्रकाशित पोर्ट नेमस्पेस रखने वाली सेवा के हैं। ऐप में ports जोड़ना network_mode के साथ अस्वीकार किया जाता है, और अलग ऐप पता गढ़ना ऐसा इंटरफ़ेस बताता है जो मौजूद नहीं है।

तैयारी, ब्लॉकिंग और रिज़ॉल्वर

depends_on कंटेनर शुरू होने का क्रम तय करता है; यह टनल चालू होने का प्रमाण नहीं है, और टनल गिरने पर यह ट्रैफ़िक नहीं रोकता। पहुँच, टनल की तैयारी और विफलता-ब्लॉकिंग को तीन अलग आवश्यकताएँ मानें। जो स्टैक केवल पहली पूरी करता है वह अच्छे दिन हाथ से किए परीक्षण में पास होता है और बुरे दिन लीक करता है। तीनों जवाब compose फ़ाइल के पास लिखें, जहाँ अगला व्यक्ति देखेगा।

नेमस्पेस साझा करने का अर्थ यह भी है कि ऐप VPN कंटेनर का रिज़ॉल्वर विरासत में पाता है, जो तब मदद करता है जब टनल DNS सर्वर थोपता है और तब भ्रमित करता है जब नहीं। यह मानने के बजाय कि होस्ट का रिज़ॉल्वर लागू होता है, जाँचें कि नेमस्पेस में वास्तव में क्या है। Compose सेवा संदर्भ एक ही जगह network_mode, ports और निर्भरता व्यवहार का दस्तावेज़ीकरण करता है, जिसमें यह भी शामिल है कि network_mode सेवा का अपना पता क्यों नहीं है।