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 सेवेला स्वतःचा पत्ता का नाही यासह।