हा रनबुक वर्कलोड प्रोफाइल असलेल्या Container Apps वातावरणाचा आणि त्याच्या अंतर्गत व्हर्च्युअल-नेटवर्क प्रवेशाचा समावेश करतो; त्यात लॅपटॉपवरून मंजूर पॉइंट-टू-साइट VPN द्वारे पोहोचले जाते, अॅपचा थेट FQDN वापरून आणि वातावरण-स्तरावर HTTP मार्गांशिवाय। वातावरणाचा प्रवेश क्लायंटकडून पोहोचण्यायोग्य आहे, अॅपची इनग्रेस व्याप्ती कॉलरला परवानगी देते, आणि होस्टनाव खाजगी प्रवेशावर रिझोल्व्ह होते। खालील प्रत्येक टप्पा पडताळण्यायोग्य निकाल आणि तुम्ही न बदललेल्या कोणत्याही गोष्टीला स्पर्श न करणारा रोलबॅक सोडतो। दिलेल्या क्रमाने ते पूर्ण करा, कारण टप्पा 1 मध्ये चुकीचा घेतलेला व्याप्ती-निर्णय पुढील कोणताही टप्पा भरून काढू शकत नाही।

DNS ला स्पर्श करण्यापूर्वी अंतर्गत हा शब्द स्पष्ट करा। या उत्पादनात तो दोन वेगवेगळ्या व्याप्तींसाठी वापरला जातो, आणि त्या अदलाबदल करणे हेच कार्यरत नाव अजूनही काहीही उपयुक्त न परतवण्याचे सर्वात सामान्य कारण आहे।

टप्पा 1: वातावरण आणि अॅपची व्याप्ती निश्चित करा

कोणताही रेकॉर्ड बदलण्यापूर्वी अॅपची इनग्रेस कॉन्फिगरेशन वाचा:

SettingBoundary
Internal environmentThe environment entry is reached through its private network arrangement
App with internal ingressCallers from the environment VNet only; a VPN laptop qualifies once it has a route into that VNet and the domain resolves privately
App with external ingress in an internal environmentThe app accepts outside traffic through the environment's private entry

अंतर्गत इनग्रेस वातावरणाच्या VNet मधील वातावरणाच्या अंतर्गत लोड बॅलन्सरवर उघड केले जाते, त्यामुळे प्रश्न लॅपटॉप दुसरे कंटेनर अॅप आहे का हा नाही, तर ते त्या VNet पर्यंत पोहोचू शकते का हा आहे। VNet मध्ये मार्ग असलेला आणि वातावरणाचे डीफॉल्ट डोमेन खाजगी झोनद्वारे रिझोल्व्ह होणारा VPN क्लायंट पात्र कॉलर आहे, आणि उर्वरित टप्पे नेमके तेच तयार करतात। सार्वजनिक प्रवेश नसलेले अंतर्गत वातावरण अंतर्गत इनग्रेस असलेल्या अॅपपेक्षा वेगळी वस्तुस्थिती आहे, आणि अॅप-स्तरावरील बाह्य इनग्रेस वातावरणाला सार्वजनिक दरवाजा देत नाही। व्याप्ती पोर्टलमध्ये आणि तिकिटातही लिहा, कारण पुढील अभियंता आधी तिकीट वाचतो।

पुढे जाण्यापूर्वी कॉन्फिगरेशन मालकासोबत ती व्याप्ती पुष्टी करा, आणि गेट अरुंद ठेवा: वातावरणाच्या VNet मध्ये मार्ग नसल्यास, किंवा वातावरणाचे डीफॉल्ट डोमेन खाजगी झोनद्वारे रिझोल्व्ह होत नसल्यास, थांबा आणि आधी तो मार्ग दुरुस्त करा। VNet पर्यंत पोहोचू न शकणाऱ्या किंवा नाव रिझोल्व्ह करू न शकणाऱ्या कॉलरची जागा पुढील कोणताही टप्पा घेऊ शकत नाही।

टप्पा 2: खरे होस्टनाव आणि प्रवेश पत्ता गोळा करा

वातावरणाचे डीफॉल्ट डोमेन, त्याचा स्थिर खाजगी प्रवेश पत्ता आणि अॅपचा कॉन्फिगर केलेला FQDN नोंदवा; ते जुन्या स्क्रीनशॉटऐवजी किंवा विकी पानावरून नाही, संसाधनातून घ्या:

az containerapp env show -n ENV -g RG \
  --query "{domain:properties.defaultDomain, ip:properties.staticIp}"
az containerapp show -n APP -g RG \
  --query "properties.configuration.ingress.fqdn"

Container Apps साठीचे खाजगी प्रवेश मार्गदर्शन अॅप्लिकेशनची होस्टनावे अभंग ठेवून वातावरणाचे डोमेन त्याच्या अंतर्गत पत्त्याशी जुळवण्याचे वर्णन करते। तुम्ही येथे हाताने नेमका तोच आकार तयार करत आहात, म्हणून नवीन नामकरण योजना शोधण्याऐवजी झोनची सामग्री त्याच्याशी संरेखित करा।

तुम्ही वाचलेले डोमेन अॅप जे FQDN नोंदवते त्याच्याशी जुळत नसल्यास, थांबा आणि आता ती जुळवा। चुकीच्या प्रत्ययावर झोन तयार केल्यास अशा होस्टनावाची निर्मिती होते जे उत्तम प्रकारे रिझोल्व्ह होते आणि तरीही चुकीच्या व्हर्च्युअल होस्टवर उतरते।

टप्पा 3: खाजगी झोन VPN च्या रिझोल्व्हर मार्गावर ठेवा

वातावरणाच्या वास्तविक डीफॉल्ट डोमेनसाठी समर्थित खाजगी DNS झोन तयार करा किंवा पुन्हा वापरा, दस्तऐवजीकृत वाइल्डकार्ड आणि पत्ता रेकॉर्ड स्थिर प्रवेशाकडे निर्देश करतात। तो झोन योग्य व्हर्च्युअल नेटवर्कशी जोडा, आणि दुवाच पुरेसा आहे असे गृहीत धरण्याऐवजी VPN च्या मंजूर रिझोल्व्हर मार्गाने खाजगी अधिकार पोहोचण्यायोग्य करा।

पॉइंट-टू-साइट क्लायंटला त्या झोनपर्यंत पोहोचण्यासाठी सामान्यतः खाजगी रिझोल्व्हरचा इनबाउंड एंडपॉइंट किंवा समर्थित DNS फॉरवर्डर आवश्यक असतो। झोन जोडल्याने Azure जोडलेल्या नेटवर्कसाठी जे रिझोल्व्ह करते ते बदलते; ते प्रत्येक बाह्य लॅपटॉपचा सार्वजनिक रिझोल्व्हर पुनर्निर्देशित करत नाही। दुसऱ्या Container Apps नेटवर्किंग मॉडेलमधून घेतलेल्या खाजगी-एंडपॉइंट DNS झोनने त्याची जागा घेऊ नका, कारण रेकॉर्ड नावे आणि झोन प्रत्यय जुळणार नाहीत।

या टप्प्याचा रोलबॅक म्हणजे तुम्ही जोडलेला झोन दुवा किंवा रेकॉर्ड काढणे। त्यापैकी कोणते होते ते नोंदवा, कारण एकच दुवा रद्द करण्यासाठी सामायिक झोन हटवणे हा दुसरे वातावरण तोडण्याचा सर्वज्ञात मार्ग आहे।

टप्पा 4: नाव तपासा, नंतर नाकारलेले प्रेक्षक

होस्टनाव आणि TLS ओळख एकत्र तपासा, केवळ पत्ता नाही। नियंत्रित नाव-मॅपिंग निदानासाठी तुम्ही होस्टनाव राखून पत्ता पिन करू शकता:

curl --resolve app.ENVIRONMENT_DOMAIN:443:10.40.0.10 \
    https://app.ENVIRONMENT_DOMAIN/

होस्टनाव अॅपच्या खऱ्या FQDN ने आणि पत्ता खऱ्या अंतर्गत प्रवेशाने बदला। हे केवळ त्या एका विनंतीवर परिणाम करते आणि DNS प्रोव्हिजनिंग नाही। ओळखीच्या अपयशाला दिसणारे उत्तीर्ण बनवण्यासाठी -k जोडू नका, कारण प्रमाणपत्राची विसंगती हीच खूण आहे की तुम्ही चुकीच्या श्रोत्याला भिडत आहात।

संख्यात्मक पत्ता थेट मागितल्यास TCP 443 उत्तर देत असतानाही चुकीचे व्हर्च्युअल होस्ट निवडले जाऊ शकते किंवा प्रमाणीकरण अयशस्वी होऊ शकते, म्हणून यशस्वी IP चाचणी नेटवर्कबद्दलचा पुरावा माना, त्याहून अधिक नाही। इच्छित लॅपटॉपवरून सामान्य रिझोल्व्हर मार्ग म्हणजे क्लायंटचा DNS फॉरवर्डर किंवा झोन होस्ट करणाऱ्या खाजगी रिझोल्व्हरचा इनबाउंड एंडपॉइंट, आणि तेथील अपयश हरवलेला रेकॉर्ड नसून रिझोल्व्हरपर्यंत पोहोचण्याची समस्या आहे। त्याच मार्गावर तीच विनंती यशस्वी होते याची पुष्टी करा, नंतर नाकारलेले प्रेक्षक अजूनही नाकारले जातात याची पुष्टी करा।

काय नोंदवायचे आणि काय रोलबॅक करायचे

कंटेनरचा लक्ष्य पोर्ट आणि क्लायंटचा HTTPS पोर्ट वेगवेगळी सेटिंग्ज आहेत। कंटेनर तेथे ऐकत असल्याने त्याचा लक्ष्य पोर्ट VPN वर प्रकाशित करू नका, आणि पोर्ट चाचणी उत्तीर्ण होण्यासाठी नेटवर्क नियम रुंदावू नका। दोन्ही बदल घटनेनंतरही टिकतात आणि नंतर त्यांचे श्रेय देणे कठीण असते।

इच्छित लॅपटॉपवरून त्याची अधिकृत ओळख आणि सामान्य DNS वापरून नवीन अॅप्लिकेशन क्रियेसह समाप्त करा, नंतर अनधिकृत कॉलर अजूनही अयशस्वी होतो याची तपासणी करा। अॅप कॉन्फिगरेशनमध्ये असताना, वातावरण-स्तरावरील HTTP मार्ग या अॅपला लक्ष्य म्हणून उघड करतो का हेही पुष्टी करा, कारण तो मार्ग इनग्रेस व्याप्ती वर्णन करत नाही असा दुसरा दरवाजा आहे।

पाच मूल्ये एकत्र नोंदवा: वातावरणाची व्याप्ती, अॅपची इनग्रेस व्याप्ती, FQDN, खाजगी प्रवेश पत्ता आणि रिझोल्व्हरचा मालक। ती पाच संपूर्ण प्रवेश करार वर्णन करतात, आणि हे डीबग करणारी पुढील व्यक्ती नेमकी तीच मागेल।

संबंधित लेख