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 सेवासँग आफ्नै ठेगाना किन छैन भन्ने पनि सहित।