यो रनबुकले कार्यभार प्रोफाइल भएको 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, निजी प्रवेश ठेगाना र रिजोल्भरको मालिक। ती पाँचले सम्पूर्ण पहुँच करार वर्णन गर्छन्, र यसलाई डिबग गर्ने अर्को व्यक्तिले ठ्याक्कै ती नै माग्नेछ।

सम्बन्धित लेखहरू