इंटरनल एचटीटीपी या लोड बैलेंसर के साथ, Private Service Connect और हाइब्रिड NEG का इस्तेमाल करके, हाइब्रिड नेटवर्किंग की मदद से कंपनी की सेवाओं से कनेक्ट करें

1. परिचय

क्लाउड लोड बैलेंसिंग की सुविधा, Google Cloud से बाहर के एंडपॉइंट पर भी लोड बैलेंसिंग वाले ट्रैफ़िक के साथ काम करती है. जैसे, कंपनी की इमारत में मौजूद डेटा सेंटर और अन्य सार्वजनिक क्लाउड. इन कनेक्शन तक पहुंचने के लिए हाइब्रिड कनेक्टिविटी का इस्तेमाल किया जा सकता है.

हाइब्रिड रणनीति, बाज़ार की बदलती मांगों के हिसाब से एक व्यावहारिक समाधान है. इसकी मदद से, अपने ऐप्लिकेशन को बेहतर तरीके से इस्तेमाल किया जा सकता है. यह अस्थायी हाइब्रिड डिप्लॉयमेंट हो सकता है. इसकी मदद से, डेटा को आधुनिक क्लाउड-आधारित समाधान पर माइग्रेट किया जा सकता है. इसके अलावा, आपके संगठन के आईटी इन्फ़्रास्ट्रक्चर का स्थायी समाधान भी हो सकता है.

हाइब्रिड लोड बैलेंसिंग की सुविधा सेट अप करके, क्लाउड लोड बैलेंसिंग की नेटवर्किंग क्षमताओं का फ़ायदा Google Cloud के अलावा अपने मौजूदा इन्फ़्रास्ट्रक्चर पर चल रही सेवाओं के लिए भी लिया जा सकता है.

अगर आपको अन्य VPC नेटवर्क में हाइब्रिड सेवा उपलब्ध करानी है, तो सेवा को पब्लिश करने के लिए, Private Service Connect का इस्तेमाल किया जा सकता है. अपने इंटरनल रीजनल एचटीटीपी(एचटीटीपी) लोड बैलेंसर के सामने सर्विस अटैचमेंट जोड़कर,अन्य VPC नेटवर्क के क्लाइंट को कंपनी की इमारत या किसी अन्य क्लाउड प्लैटफ़ॉर्म में चल रही हाइब्रिड सेवाओं तक पहुंचने की अनुमति दी जा सकती है.

आपको क्या बनाना होगा

इस कोडलैब में, नेटवर्क एंडपॉइंट ग्रुप का इस्तेमाल करके, हाइब्रिड कनेक्टिविटी वाला इंटरनल एचटीटीपी(एस) लोड बैलेंसर, कंपनी के ऑफ़िस में इस्तेमाल होने वाली सेवा में बनाया जा सकता है. कंज़्यूमर VPC, पोर्ट 80 और पोर्ट 443 का इस्तेमाल करके, कंपनी की इमारत में मौजूद सेवा से संपर्क कर पाएंगे. कोडलैब, कोडलैब के दायरे में नहीं आता.

4ad647fa51b3473e.png

आपको इनके बारे में जानकारी मिलेगी

  • हाइब्रिड NEG बैकएंड के साथ इंटरनल एचटीटीपी या एचटीटीपीएस लोड बैलेंसर बनाने का तरीका
  • Private Service Connect प्रोड्यूसर (सर्विस अटैचमेंट) और उपभोक्ता (फ़ॉरवर्डिंग नियम) को बनाने का तरीका

आपको इन चीज़ों की ज़रूरत होगी

  • पहले से मौजूद हाइब्रिड नेटवर्किंग, जैसे कि HA VPN, इंटरकनेक्ट, SW-WAN
  • Google Cloud प्रोजेक्ट

हाइब्रिड कनेक्टिविटी बनाएं

यह ज़रूरी है कि आपका Google Cloud और कंपनी की इमारत या अन्य क्लाउड प्लैटफ़ॉर्म, हाइब्रिड कनेक्टिविटी की मदद से कनेक्ट हों. इसके लिए, Cloud Interconnect VLAN अटैचमेंट या Cloud राऊटर के साथ Cloud VPN टनल का इस्तेमाल करना होगा. हमारा सुझाव है कि आप ऐसे कनेक्शन का इस्तेमाल करें जिसकी उपलब्धता ज़्यादा हो.

ग्लोबल डाइनैमिक रूटिंग की मदद से चालू किया गया क्लाउड राऊटर, BGP से मिले खास एंडपॉइंट के बारे में जानकारी लेता है. इसके बाद, यह राऊटर उसे आपके Google Cloud VPC नेटवर्क में प्रोग्राम कर देता है. रीजनल डाइनैमिक रूटिंग काम नहीं करती है. स्टैटिक रूट भी काम नहीं करते.

Cloud इंटरकनेक्ट या Cloud VPN में से किसी एक को कॉन्फ़िगर करने के लिए इस्तेमाल किया जाने वाला Google Cloud VPC नेटवर्क, वही नेटवर्क है जिसका इस्तेमाल हाइब्रिड लोड बैलेंसिंग डिप्लॉयमेंट को कॉन्फ़िगर करने के लिए किया जाता है. पक्का करें कि आपके VPC नेटवर्क की सबनेट सीआईडीआर रेंज, आपके रिमोट सीआईडीआर रेंज से मेल न खाती हों. जब आईपी पते ओवरलैप होते हैं, तो सबनेट रूट को रिमोट कनेक्टिविटी पर प्राथमिकता दी जाती है.

निर्देशों के लिए, इन्हें देखें:

कस्टम रूट विज्ञापन

नीचे दिए गए सबनेट को क्लाउड राऊटर से कंपनी की इमारत में नेटवर्क तक पसंद के मुताबिक विज्ञापन दिखाने की ज़रूरत है. इससे यह पक्का किया जा सकता है कि कंपनी की इमारत में मौजूद फ़ायरवॉल के नियम अपडेट हों.

सबनेट

ब्यौरा

172.16.0.0/23

प्रॉक्सी सबनेट का इस्तेमाल, कंपनी की इमारत में मौजूद सेवा से सीधे संपर्क करने के लिए किया जाता है

130.211.0.0/22, 35.191.0.0/16

Google Cloud Health की जांच

2. शुरू करने से पहले

कोडलैब के साथ काम करने के लिए प्रोजेक्ट अपडेट करना

यह कोडलैब, Cloud Shell में gcloud कॉन्फ़िगरेशन लागू करने में मदद करने के लिए $variables का इस्तेमाल करता है.

Cloud Shell के अंदर यह काम करें

gcloud config list project
gcloud config set project [YOUR-PROJECT-NAME]
psclab=YOUR-PROJECT-NAME
echo $psclab

3. प्रोड्यूसर सेटअप

प्रोड्यूसर के लिए VPC बनाना

Cloud Shell के अंदर यह काम करें

gcloud compute networks create producer-vpc --project=$psclab --subnet-mode=custom

प्रोड्यूसर सबनेट बनाना

Cloud Shell के अंदर यह काम करें

gcloud compute networks subnets create subnet-201 --project=$psclab --range=10.10.1.0/24 --network=producer-vpc --region=us-central1
gcloud compute networks subnets create subnet-202 --project=$psclab --range=10.20.1.0/24 --network=producer-vpc --region=us-central1

इंटरनल लोड बैलेंसर के लिए आईपी पता बुक करना

Cloud Shell के अंदर यह काम किया जा सकता है. Private Service Connect के साथ SHARED_VIP का इस्तेमाल नहीं किया जा सकता. इसके बजाय, GCE_ENDPOINT का इस्तेमाल करें

gcloud compute addresses create lb-ip \
    --region=us-central1 \
    --subnet=subnet-202 \
    --purpose=GCE_ENDPOINT

दिए गए आईपी पते को देखने के लिए, कंप्यूट पतों का ब्यौरा देने वाले कमांड का इस्तेमाल करें

gcloud compute addresses describe lb-ip  --region=us-central1 | grep address:

रीजनल प्रॉक्सी सबनेट बनाना

प्रॉक्सी ऐलोकेशन, VPC लेवल पर होता है, न कि लोड बैलेंसर के लेवल पर. आपको किसी वर्चुअल नेटवर्क (VPC) के हर उस इलाके में प्रॉक्सी-ओनली सबनेट बनाना होगा जिसमें आप Envoy पर आधारित लोड बैलेंसर का इस्तेमाल करते हैं. अगर एक ही क्षेत्र और एक ही VPC नेटवर्क में कई लोड बैलेंसर डिप्लॉय किए जाते हैं, तो लोड बैलेंसिंग के लिए वे एक ही प्रॉक्सी-ओनली सबनेट इस्तेमाल करेंगे.

  1. क्लाइंट, लोड बैलेंसर के फ़ॉरवर्ड करने के नियम के आईपी पते और पोर्ट से कनेक्शन बनाता है.
  2. हर प्रॉक्सी, लोड बैलेंसर के फ़ॉरवर्ड करने के नियम के मुताबिक तय किए गए आईपी पते और पोर्ट के हिसाब से काम करती है. प्रॉक्सी में से एक, क्लाइंट के नेटवर्क कनेक्शन को पाता है और उसे खत्म कर देता है.
  3. प्रॉक्सी सर्वर, सही बैकएंड वीएम या NEG में एंडपॉइंट से कनेक्शन बनाता है. यह कनेक्शन, लोड बैलेंसर के यूआरएल मैप और बैकएंड सेवाओं के हिसाब से तय होता है.

आपको प्रॉक्सी-ओनली सबनेट बनाने होंगे, चाहे आपका नेटवर्क ऑटो-मोड हो या कस्टम. सिर्फ़ प्रॉक्सी वाले सबनेट में 64 या उससे ज़्यादा आईपी पते होने चाहिए. यह /26 या इससे कम की लंबाई के प्रीफ़िक्स से मेल खाता है. हमारा सुझाव है कि सबनेट का साइज़ /23 (सिर्फ़ प्रॉक्सी वाले 512 पते) है.

Cloud Shell के अंदर यह काम करें

gcloud compute networks subnets create proxy-subnet-us-central \
  --purpose=REGIONAL_MANAGED_PROXY \
  --role=ACTIVE \
  --region=us-central1 \
  --network=producer-vpc \
  --range=172.16.0.0/23

Private Service Connect NAT सबनेट को बनाना

Private Service Connect के साथ इस्तेमाल करने के लिए, एक या इससे ज़्यादा खास सबनेट बनाएं. अगर किसी सेवा को पब्लिश करने के लिए Google Cloud Console का इस्तेमाल किया जा रहा है, तो उस प्रोसेस के दौरान सबनेट बनाए जा सकते हैं. सबनेट उसी क्षेत्र में बनाएं जिसमें सेवा का लोड बैलेंसर है. किसी सामान्य सबनेट को Private Service Connect सबनेट में नहीं बदला जा सकता.

Cloud Shell के अंदर यह काम करें

gcloud compute networks subnets create psc-nat-subnet --network=producer-vpc --region=us-central1 --range=100.100.10.0/24 --purpose=private-service-connect

प्रोड्यूसर फ़ायरवॉल के नियम बनाना

Private Service Connect के एंडपॉइंट और सेवा अटैचमेंट के बीच ट्रैफ़िक को अनुमति देने के लिए, फ़ायरवॉल के नियम कॉन्फ़िगर करें. कोडलैब में, इन्ग्रेस डेटा ट्रैफ़िक का नियम बनाया गया है. इस नियम के तहत, NAT सबनेट को 100.100.10.0/24 को Private Service Connect सर्विस अटैचमेंट (इंटरनल लोड बैलेंसर) के ऐक्सेस की अनुमति दी गई है.

Cloud Shell के अंदर यह काम करें

gcloud compute --project=$psclab firewall-rules create allow-to-ingress-nat-subnet --direction=INGRESS --priority=1000 --network=producer-vpc --action=ALLOW --rules=all --source-ranges=100.100.10.0/24

क्लाउड शेल के अंदर, 'स्वास्थ्य की जांच की अनुमति दें' नियम बनाएं, ताकि Google Cloud की, टीसीपी पोर्ट 80 पर मौजूद सेवा (बैकएंड सेवा) तक पहुंचने के लिए Google Cloud की परफ़ॉर्मेंस की जांच की जा सके

gcloud compute firewall-rules create fw-allow-health-check \
    --network=producer-vpc \
    --action=allow \
    --direction=ingress \
    --source-ranges=130.211.0.0/22,35.191.0.0/16 \
    --rules=tcp:80

इन्ग्रेस डेटा ट्रैफ़िक अनुमति दें

gcloud compute firewall-rules create fw-allow-proxy-only-subnet \
    --network=producer-vpc \
    --action=allow \
    --direction=ingress \
    --source-ranges=172.16.0.0/23 \
    --rules=tcp:80

हाइब्रिड कनेक्टिविटी वाला NEG सेट अप करें

NEG बनाते समय,ऐसे ज़ोन का इस्तेमाल करें जो Google Cloud और कंपनी की इमारत या किसी अन्य क्लाउड प्लैटफ़ॉर्म के बीच की भौगोलिक दूरी को कम करता हो. उदाहरण के लिए, अगर जर्मनी के फ़्रैंकफ़र्ट में कंपनी की इमारत में कोई सेवा होस्ट की जा रही है, तो NEG बनाते समय europe-west3-a Google Cloud ज़ोन तय किया जा सकता है.

इसके अलावा, अगर Cloud Interconnect का इस्तेमाल किया जा रहा है, तो NEG बनाने के लिए इस्तेमाल किया जाने वाला ZONE भी उसी क्षेत्र में होना चाहिए जहां Cloud Interconnect अटैचमेंट को कॉन्फ़िगर किया गया था.

उपलब्ध क्षेत्रों और ज़ोन के लिए, Compute Engine से जुड़े दस्तावेज़: उपलब्ध क्षेत्र और ज़ोन देखें.

Cloud Shell के अंदर, gcloud Copy network-endpoint-groups create कमांड का इस्तेमाल करके हाइब्रिड कनेक्टिविटी वाला NEG बनाएं

gcloud compute network-endpoint-groups create on-prem-service-neg \
    --network-endpoint-type=NON_GCP_PRIVATE_IP_PORT \
    --zone=us-central1-a \
    --network=producer-vpc

Cloud Shell के अंदर, हाइब्रिड NEG में कंपनी की इमारत में आईपी:पोर्ट एंडपॉइंट जोड़ें.

gcloud compute network-endpoint-groups update on-prem-service-neg \
    --zone=us-central1-a \
    --add-endpoint="ip=192.168.1.5,port=80"

लोड बैलेंसर को कॉन्फ़िगर करना

नीचे दिए गए चरणों में, लोड बैलेंसर (फ़ॉरवर्डिंग का नियम) को कॉन्फ़िगर करें और नेटवर्क एंडपॉइंट ग्रुप के साथ असोसिएट करें

Cloud Shell के अंदर, स्थानीय सेवा देने वाली कंपनी को भेजी गई स्वास्थ्य जांच की सुविधा बनाएं

gcloud compute health-checks create http http-health-check \
    --region=us-central1 \
    --use-serving-port

Cloud Shell के अंदर, हाइब्रिड NEG का इस्तेमाल करके ऑन-प्रिमाइस बैकएंड के लिए बैकएंड सेवा बनाएं

 gcloud compute backend-services create on-premise-service-backend \
      --load-balancing-scheme=INTERNAL_MANAGED \
      --protocol=HTTP \
      --health-checks=http-health-check \
      --health-checks-region=us-central1 \
      --region=us-central1

Cloud Shell के अंदर, बैकएंड सेवा में हाइब्रिड NEG बैकएंड जोड़ें. RATE के लिए वह अधिकतम RATE डालें जो बैकएंड को संभालनी चाहिए.

gcloud compute backend-services add-backend on-premise-service-backend \
    --region=us-central1 \
    --balancing-mode=RATE \
    --max-rate-per-endpoint=100 \
    --network-endpoint-group=on-prem-service-neg \
    --network-endpoint-group-zone=us-central1-a

Cloud Shell के अंदर, आने वाले अनुरोधों को बैकएंड सेवा पर भेजने के लिए यूआरएल मैप बनाएं

gcloud compute url-maps create on-prem-svc-url-map \
    --default-service on-premise-service-backend \
    --region=us-central1

एचटीटीपी टारगेट प्रॉक्सी बनाएं

gcloud compute target-http-proxies create proxy-subnet-us-central\
    --url-map=on-prem-svc-url-map \
    --url-map-region=us-central1 \
    --region=us-central1

आने वाले अनुरोधों को प्रॉक्सी पर रूट करने के लिए, फ़ॉरवर्ड करने का नियम बनाएं. फ़ॉरवर्ड करने का नियम बनाने के लिए, सिर्फ़ प्रॉक्सी के लिए इस्तेमाल होने वाला सबनेट इस्तेमाल न करें.

 gcloud compute forwarding-rules create http-hybrid-neg-fwd-rule \
      --load-balancing-scheme=INTERNAL_MANAGED \
      --network=producer-vpc \
      --subnet=subnet-202 \
      --address=lb-ip \
      --ports=80 \
      --region=us-central1 \
      --target-http-proxy=proxy-subnet-us-central \
      --target-http-proxy-region=us-central1

4. लोड बैलेंसर की पुष्टि करें

Cloud Console से नेटवर्क सेवाएं → लोड बैलेंसिंग → लोड बैलेंसर पर जाएं. ध्यान दें कि 1 NEG 'ग्रीन' है यह बताता है कि ऑफ़िस में काम करने वाली कंपनी के लिए, स्वास्थ्य की जांच सही तरीके से की गई है या नहीं

bb5d117dee3b8b04.png

‘on-premise-svc-url-map' को चुनने से फ़्रंट एंड आईपी पता मिलता है और बैकएंड सेवा की पहचान होती है

128a7e85e8069097.png

5. ऑन-प्रिमाइस से सीखे गए रास्ते देखें

VPC नेटवर्क → रास्ते पर जाएं. ध्यान दें, मान्यता प्राप्त ऑन-प्रिमाइस सर्विस सबनेट 192.168.1.0/27

d1ab51b79aeea9d8.png

6. कंपनी की इमारत से कनेक्ट होने की पुष्टि करना

प्रोड्यूसर के VPC से, हम ऑन-प्रिमाइस सेवा से कनेक्टिविटी की जांच करने के लिए एक वीएम बनाएंगे. इसके बाद, सेवा अटैचमेंट अगला कॉन्फ़िगरेशन होगा.

Cloud Shell के अंदर, प्रोड्यूसर vpc में टेस्ट इंस्टेंस बनाएं

gcloud compute instances create test-box-us-central1 \
    --zone=us-central1-a \
    --image-family=debian-10 \
    --image-project=debian-cloud \
    --subnet=subnet-201 \
    --no-address

आईएपी को अपने वीएम इंस्टेंस से कनेक्ट करने की अनुमति देने के लिए, फ़ायरवॉल का नियम बनाएं:

  • यह उन सभी वीएम इंस्टेंस पर लागू होता है जिन्हें आपको आईएपी का इस्तेमाल करके ऐक्सेस करना है.
  • आईपी रेंज 35.235.240.0/20 से, इन्ग्रेस डेटा ट्रैफ़िक की अनुमति देता है. इस रेंज में वे सभी आईपी पते शामिल होते हैं जिनका इस्तेमाल आईएपी, टीसीपी फ़ॉरवर्ड करने के लिए करता है.

Cloud Shell के अंदर, प्रोड्यूसर vpc में टेस्ट इंस्टेंस बनाएं

gcloud compute firewall-rules create ssh-iap \
    --network producer-vpc \
    --allow tcp:22 \
    --source-ranges=35.235.240.0/20

क्लाउड शेल में IAP का इस्तेमाल करके टेस्ट-box-us-central1 में लॉग इन करें. इससे, लोड बैलेंस वाले आईपी पते की मदद से कर्ल चलाकर, कंपनी की इमारत से कनेक्ट होने की पुष्टि की जा सकेगी. अगर समय खत्म हो जाए, तो फिर से कोशिश करें.

gcloud compute ssh test-box-us-central1 --project=$psclab --zone=us-central1-a --tunnel-through-iap

कंपनी की इमारत में, कर्ल करने के लिए कनेक्टिविटी करें. वर्चुअल मशीन के Cloud Shell प्रॉम्प्ट पर लौटने की पुष्टि होने के बाद. चौथे चरण में दिए गए आउटपुट के आधार पर, इंटरनल लोड बैलेंसर आईपी पते को बदलें.

user@test-box-us-central1:~$ curl -v 10.20.1.2
* Expire in 0 ms for 6 (transfer 0x55b7725c10f0)
*   Trying 10.20.1.2...
* TCP_NODELAY set
* Expire in 200 ms for 4 (transfer 0x55b7725c10f0)
* Connected to 10.20.1.2 (10.20.1.2) port 80 (#0)
> GET / HTTP/1.1
> Host: 10.20.1.2
> User-Agent: curl/7.64.0
> Accept: */*
> 
< HTTP/1.1 200 OK
< content-type: text/html; charset=utf-8
< accept-ranges: bytes
< etag: "3380914763"
< last-modified: Mon, 05 Dec 2022 15:10:56 GMT
< expires: Mon, 12 Dec 2022 03:17:20 GMT
< cache-control: max-age=0
< content-length: 37
< date: Mon, 12 Dec 2022 03:17:20 GMT
< server: lighttpd/1.4.53
< via: 1.1 google
< 
Welcome to my on-premise service!!

7. Private Service Connect सेवा का अटैचमेंट बनाएं

नीचे दिए गए चरणों में, हम सेवा अटैचमेंट बनाएंगे. ऐसा करने के बाद, कंपनी की इमारत में मौजूद सेवा के लिए, उपभोक्ता एंडपॉइंट ऐक्सेस के साथ जुड़ने के बाद, VPC पीयरिंग की ज़रूरत नहीं होगी.

सेवा अटैचमेंट बनाएं

Cloud Shell के अंदर सेवा अटैचमेंट बनाएं

gcloud compute service-attachments create service-1 --region=us-central1 --producer-forwarding-rule=http-hybrid-neg-fwd-rule --connection-preference=ACCEPT_AUTOMATIC --nat-subnets=psc-nat-subnet

ज़रूरी नहीं: शेयर किए गए VPC का इस्तेमाल करने पर, सेवा प्रोजेक्ट में सेवा अटैचमेंट बनाएं

gcloud compute service-attachments create service-1 --region=us-central1 --producer-forwarding-rule=http-hybrid-neg-fwd-rule --connection-preference=ACCEPT_AUTOMATIC --nat-subnets=projects/<hostproject>/regions/<region>/subnetworks/<natsubnet>

टीसीपी सेवा अटैचमेंट की पुष्टि करें

gcloud compute service-attachments describe service-1 --region us-central1

ज़रूरी नहीं: नए सर्विस अटैचमेंट को देखने के लिए, नेटवर्क सेवाएं → Private Service Connect पर जाएं

2f84578c9f2cc361.png

Service-1 को चुनने पर, इससे जुड़ी ज़्यादा जानकारी मिलती है. इसमें सेवा अटैचमेंट यूआरआई के बारे में भी शामिल है, जिसका इस्तेमाल उपभोक्ता निजी सेवा कनेक्शन बनाने के लिए करता है. यूआरआई को नोट कर लें क्योंकि इसका इस्तेमाल बाद के चरण में किया जाएगा.

41639cb160231275.png

सेवा अटैचमेंट की जानकारी: एक्सप्लोर करें

8. उपभोक्ता सेटअप

उपभोक्ता के लिए VPC बनाना

Cloud Shell के अंदर यह काम करें

gcloud compute networks create consumer-vpc --project=$psclab --subnet-mode=custom

उपभोक्ता सबनेट बनाना

Cloud Shell के अंदर GCE सबनेट बनाएं

gcloud compute networks subnets create subnet-101 --project=$psclab --range=10.100.1.0/24 --network=consumer-vpc --region=us-central1

Cloud Shell के अंदर उपभोक्ता एंडपॉइंट सबनेट बनाएं

gcloud compute networks subnets create subnet-102 --project=$psclab --range=10.100.2.0/24 --network=consumer-vpc --region=us-central1

कंज़्यूमर एंडपॉइंट (फ़ॉरवर्डिंग के लिए नियम) बनाना

Cloud Shell के अंदर स्टैटिक आईपी पता बनाया जाता है. इसका इस्तेमाल कंज़्यूमर एंडपॉइंट के तौर पर किया जाएगा

gcloud compute addresses create psc-consumer-ip-1 --region=us-central1 --subnet=subnet-102 --addresses 10.100.2.10

इसकी मदद से, उपभोक्ता एंडपॉइंट बनाने के लिए, पहले जनरेट किए गए सर्विस अटैचमेंट यूआरआई का इस्तेमाल किया जा सकता है

Cloud Shell के अंदर उपभोक्ता एंडपॉइंट बनाएं

gcloud compute forwarding-rules create psc-consumer-1 --region=us-central1 --network=consumer-vpc --address=psc-consumer-ip-1 --target-service-attachment=projects/$psclab/regions/us-central1/serviceAttachments/service-1

9. उपभोक्ता निजी सेवा कनेक्ट की पुष्टि करना - उपभोक्ता VPC

उपभोक्ता VPC की मदद से, नेटवर्क सेवाएं → Private Service Connect→ कनेक्ट किए गए एंडपॉइंट पर जाकर, सही निजी सेवा कनेक्शन की पुष्टि करें. पहले से बनाया गया psc-consumer-1 कनेक्शन और उससे जुड़ा आईपी पता नोट करें.

b91ee5d5c854e60b.png

psc-consumer-1 को चुनते समय, सेवा अटैचमेंट यूआरआई के साथ-साथ जानकारी भी दी जाती है

1dbc63217819dcd5.png

10. उपभोक्ता निजी सेवा कनेक्ट की पुष्टि करना - प्रोड्यूसर VPC

प्रोड्यूसर VPC से, नेटवर्क सेवाएं → Private Service Connect→पब्लिश की गई सेवा पर जाकर, काम करने वाले निजी सेवा कनेक्शन की पुष्टि करें. ध्यान दें कि पब्लिश किया गया सर्विस-1 कनेक्शन अब एक फ़ॉरवर्ड करने का नियम (कनेक्शन एंडपॉइंट) दिखाता है.

951090b812a8d119.png

11. निजी डीएनएस ज़ोन बनाना और A रिकॉर्ड

PSC कनेक्शन एंडपॉइंट के साथ मैप किया गया निजी डीएनएस ज़ोन बनाएं. इससे VPC में, किसी भी होस्ट से प्रोड्यूसर को आसानी से ऐक्सेस किया जा सकता है.

Cloud Shell से

gcloud dns --project=$psclab managed-zones create codelab-zone --description="" --dns-name="codelab.net." --visibility="private" --networks="consumer-vpc"

gcloud dns --project=$psclab record-sets create service1.codelab.net. --zone="codelab-zone" --type="A" --ttl="300" --rrdatas="10.100.2.10"

12. वीएम का इस्तेमाल करके प्रोड्यूसर सेवा के लिए उपभोक्ता के ऐक्सेस की पुष्टि करना

उपभोक्ताओं के VPC से, हम ग्राहक एंडपॉइंट service1.codelabs.net को ऐक्सेस करके, ऑन-प्रिमाइस सेवा से कनेक्टिविटी की जांच करने के लिए एक वीएम बनाएंगे

Cloud Shell के अंदर उपभोक्ता vpc में टेस्ट इंस्टेंस बनाएं

gcloud compute instances create consumer-vm \
    --zone=us-central1-a \
    --image-family=debian-10 \
    --image-project=debian-cloud \
    --subnet=subnet-101 \
    --no-address

आईएपी को अपने वीएम इंस्टेंस से कनेक्ट करने की अनुमति देने के लिए, फ़ायरवॉल का नियम बनाएं:

  • यह उन सभी वीएम इंस्टेंस पर लागू होता है जिन्हें आपको आईएपी का इस्तेमाल करके ऐक्सेस करना है.
  • आईपी रेंज 35.235.240.0/20 से, इन्ग्रेस डेटा ट्रैफ़िक की अनुमति देता है. इस रेंज में वे सभी आईपी पते शामिल होते हैं जिनका इस्तेमाल आईएपी, टीसीपी फ़ॉरवर्ड करने के लिए करता है.

Cloud Shell के अंदर उपभोक्ता vpc में टेस्ट इंस्टेंस बनाएं

gcloud compute firewall-rules create ssh-iap-consumer \
    --network consumer-vpc \
    --allow tcp:22 \
    --source-ranges=35.235.240.0/20

Cloud Shell में आईएपी का इस्तेमाल करके उपभोक्ता-वीएम में लॉग इन करें. इससे डीएनएस FQDN service1.codelab.net में कर्ल परफ़ॉर्म करके, ऑफ़िस से जुड़ी सेवा से कनेक्टिविटी की पुष्टि की जा सकती है. अगर टाइम आउट हो जाए, तो फिर से कोशिश करें.

gcloud compute ssh consumer-vm --project=$psclab --zone=us-central1-a --tunnel-through-iap

कंपनी की इमारत में, कर्लिंग की पुष्टि करें. वर्चुअल मशीन (वीएम) के बाहर निकलने की पुष्टि करने के बाद, Cloud Shell प्रॉम्प्ट पर वापस जाना

क्लाउड शेल के अंदर कर्ल करता है

$ curl -v service1.codelab.net
*   Trying 10.100.2.10...
* TCP_NODELAY set
* Expire in 200 ms for 4 (transfer 0x5650fc3390f0)
* Connected to service1.codelab.net (10.100.2.10) port 80 (#0)
> GET / HTTP/1.1
> Host: service1.codelab.net
> User-Agent: curl/7.64.0
> Accept: */*
> 
< HTTP/1.1 200 OK
< Content-Type: text/html; charset=utf-8
< Accept-Ranges: bytes
< ETag: "3380914763"
< Last-Modified: Mon, 05 Dec 2022 15:10:56 GMT
< Expires: Mon, 05 Dec 2022 15:15:41 GMT
< Cache-Control: max-age=0
< Content-Length: 37
< Date: Mon, 05 Dec 2022 15:15:41 GMT
< Server: lighttpd/1.4.53
< 
Welcome to my on-premise service!!

यहां ऑन-प्रिमाइसेस सेवा से कैप्चर किया गया एक उदाहरण दिया गया है, ध्यान दें कि सोर्स आईपी पता 172.16.0.13, प्रॉक्सी सबनेट रेंज 172.16.0.0/23 से है

30802152f51ff751.png

13. प्रोड्यूसर क्लीन अप

प्रोड्यूसर के कॉम्पोनेंट मिटाना

क्लाउड शेल के अंदर, प्रोड्यूसर VPC में टेस्ट इंस्टेंस मिटा दें

gcloud compute instances delete test-box-us-central1 --zone=us-central1-a --quiet

gcloud compute service-attachments delete service-1 --region=us-central1 --quiet 

gcloud compute forwarding-rules delete http-hybrid-neg-fwd-rule --region=us-central1 --quiet

gcloud compute target-http-proxies delete proxy-subnet-us-central --region=us-central1 --quiet

gcloud compute url-maps delete on-prem-svc-url-map --region=us-central1 --quiet

gcloud compute backend-services delete on-premise-service-backend --region=us-central1 --quiet

gcloud compute network-endpoint-groups delete on-prem-service-neg --zone=us-central1-a --quiet

gcloud compute addresses delete lb-ip --region=us-central1 --quiet

gcloud compute networks subnets delete psc-nat-subnet subnet-201 subnet-202 proxy-subnet-us-central --region=us-central1 --quiet

gcloud compute firewall-rules delete ssh-iap fw-allow-proxy-only-subnet allow-to-ingress-nat-subnet fw-allow-health-check --quiet

gcloud compute health-checks delete http-health-check --region=us-central1 --quiet

gcloud compute networks delete producer-vpc --quiet

14. उपभोक्ता के लिए स्टोरेज

उपभोक्ता कॉम्पोनेंट मिटाना

Cloud शेल के अंदर, उपभोक्ता VPC में टेस्ट इंस्टेंस मिटा दें

gcloud compute instances delete consumer-vm --zone=us-central1-a --quiet

gcloud compute forwarding-rules delete psc-consumer-1 --region=us-central1 --quiet

gcloud compute addresses delete psc-consumer-ip-1 --region=us-central1 --quiet

gcloud compute networks subnets delete subnet-101 subnet-102 --region=us-central1 --quiet

gcloud compute firewall-rules delete ssh-iap-consumer --quiet

gcloud dns record-sets delete service1.codelab.net --type=A --zone=codelab-zone --quiet

gcloud dns managed-zones delete codelab-zone --quiet 

gcloud compute networks delete consumer-vpc --quiet 

15. बधाई हो

बधाई हो, आपने इंटरनल एचटीटीपी या एचटीटीपीएस लोड बैलेंसर के साथ Private Service Connect की पुष्टि कर ली है.

आपने प्रोड्यूसर इन्फ़्रास्ट्रक्चर बनाया है और प्रोड्यूसर VPC में, कंपनी के मालिकाना हक वाली सेवा पर ले जाने वाला सेवा अटैचमेंट जोड़ा है. आपने ऑन-प्रिमाइस सेवा से कनेक्टिविटी की अनुमति देने वाले उपभोक्ता VPC में, उपभोक्ता एंडपॉइंट बनाने का तरीका सीखा.

आगे क्या होगा?

इनमें से कुछ कोडलैब देखें...

आगे पढ़ें और वीडियो

पहचान फ़ाइलें