เชื่อมต่อกับบริการภายในองค์กรผ่านเครือข่ายแบบผสมโดยใช้ Private Service Connect และ NEG แบบผสมที่มีตัวจัดสรรภาระงาน HTTP ภายใน

1. บทนำ

Cloud Load Balancing รองรับการจัดสรรภาระงานไปยังอุปกรณ์ปลายทางที่อยู่นอก Google Cloud เช่น ศูนย์ข้อมูลภายในองค์กรและระบบคลาวด์สาธารณะอื่นๆ ที่คุณใช้การเชื่อมต่อแบบไฮบริดเพื่อเข้าถึงได้

กลยุทธ์แบบไฮบริดเป็นโซลูชันที่ใช้งานได้จริงซึ่งจะช่วยให้คุณปรับตัวให้เข้ากับความต้องการของตลาดที่เปลี่ยนแปลงไป และค่อยๆ ปรับแอปพลิเคชันให้ทันสมัย ซึ่งอาจเป็นการติดตั้งใช้งานแบบไฮบริดชั่วคราวเพื่อเปิดใช้การย้ายข้อมูลไปยังโซลูชันที่ทันสมัยในระบบคลาวด์ หรือเป็นส่วนประกอบถาวรของโครงสร้างพื้นฐานด้านไอทีขององค์กร

การตั้งค่าการจัดสรรภาระงานแบบไฮบริดยังช่วยให้คุณได้รับประโยชน์จากความสามารถด้านระบบเครือข่ายของ Cloud Load Balancing สำหรับบริการที่ทำงานในโครงสร้างพื้นฐานที่มีอยู่นอก Google Cloud

หากต้องการทำให้บริการไฮบริดพร้อมใช้งานในเครือข่าย VPC อื่นๆ คุณสามารถใช้ Private Service Connect เพื่อเผยแพร่บริการได้ การวาง Service Attachment ไว้หน้า ตัวจัดสรรภาระงาน HTTP(s) ภายในระดับภูมิภาคจะช่วยให้ไคลเอ็นต์ในเครือข่าย VPC อื่นเข้าถึง บริการแบบไฮบริดที่ทำงานในสภาพแวดล้อมภายในองค์กรหรือสภาพแวดล้อมระบบคลาวด์อื่นๆ ได้

สิ่งที่คุณจะสร้าง

ใน Codelab นี้ คุณจะได้สร้างตัวจัดสรรภาระงาน HTTP(S) ภายในที่มีการเชื่อมต่อแบบไฮบริดกับบริการภายในองค์กรโดยใช้กลุ่มปลายทางเครือข่าย VPC ของผู้ใช้จะสื่อสารกับบริการภายในองค์กรได้โดยใช้พอร์ต 80 ส่วนพอร์ต 443 จะไม่อยู่ในขอบเขตของ Codelab

หมายเหตุ: Codelab มีขั้นตอนการกำหนดค่าและการตรวจสอบตามโทโพโลยีที่แสดงไว้ ให้แก้ไขขั้นตอนตามที่จำเป็นเพื่อให้เป็นไปตามข้อกำหนดขององค์กร สิทธิ์ IAM ไม่อยู่ในขอบเขตของโค้ดแล็บ

สิ่งที่คุณจะได้เรียนรู้

• วิธีสร้างตัวจัดสรรภาระงาน HTTP(S) ภายในด้วยแบ็กเอนด์ Hybrid NEG
• วิธีสร้างผู้ผลิต Private Service Connect (ไฟล์แนบบริการ) และผู้บริโภค (กฎการส่งต่อ)

หมายเหตุ: Codelab นี้มุ่งเน้นที่ตัวจัดสรรภาระงาน HTTP(S) ภายในที่ติดตั้งใช้งานกับ PSC เราไม่ได้จัดทำเอกสารการกำหนดค่าเครือข่ายแบบไฮบริด แต่มีเอกสารประกอบและภาพหน้าจอให้

สิ่งที่คุณต้องมี

• การสร้างเครือข่ายแบบไฮบริด เช่น VPN ความพร้อมใช้งานสูง, Interconnect, SW-WAN
• โปรเจ็กต์ Google Cloud

สร้างการเชื่อมต่อแบบไฮบริด

คุณต้องเชื่อมต่อสภาพแวดล้อม Google Cloud และสภาพแวดล้อมในองค์กรหรือสภาพแวดล้อมระบบคลาวด์อื่นๆ ผ่านการเชื่อมต่อแบบไฮบริด โดยใช้ไฟล์แนบ VLAN ของ Cloud Interconnect หรืออุโมงค์ Cloud VPN ที่มี Cloud Router เราขอแนะนำให้ใช้การเชื่อมต่อที่มีความพร้อมใช้งานสูง

Cloud Router ที่เปิดใช้การกำหนดเส้นทางแบบไดนามิกส่วนกลางจะเรียนรู้เกี่ยวกับปลายทางที่เฉพาะเจาะจงผ่าน BGP และตั้งโปรแกรมลงในเครือข่าย Google Cloud VPC ระบบไม่รองรับการกำหนดเส้นทางแบบไดนามิกระดับภูมิภาค นอกจากนี้ ระบบยังไม่รองรับเส้นทางแบบคงที่ด้วย

เครือข่าย Google Cloud VPC ที่คุณใช้กำหนดค่า Cloud Interconnect หรือ Cloud VPN จะเป็นเครือข่ายเดียวกันกับที่ใช้กำหนดค่าการติดตั้งใช้งานการจัดสรรภาระงานแบบไฮบริด ตรวจสอบว่าช่วง CIDR ของซับเน็ตในเครือข่าย VPC ไม่ขัดแย้งกับช่วง CIDR ระยะไกล เมื่อ IP แอดเดรสทับซ้อนกัน ระบบจะจัดลำดับความสำคัญของเส้นทางซับเน็ตเหนือการเชื่อมต่อระยะไกล

ดูวิธีการได้ที่

• เอกสารประกอบของ Cloud VPN
• เอกสารประกอบของ Cloud Interconnect

การประกาศเส้นทางที่กำหนดเอง

ซับเน็ตด้านล่างต้องมีการโฆษณาที่กำหนดเองจาก Cloud Router ไปยังเครือข่ายในองค์กรเพื่อให้มั่นใจว่ากฎไฟร์วอลล์ในองค์กรได้รับการอัปเดต

ซับเน็ต	คำอธิบาย
172.16.0.0/23	ซับเน็ตพร็อกซีที่ใช้เพื่อสื่อสารกับบริการในองค์กรโดยตรง
130.211.0.0/22, 35.191.0.0/16	การตรวจสุขภาพของ Google Cloud

2. ก่อนเริ่มต้น

อัปเดตโปรเจ็กต์เพื่อรองรับ Codelab

Codelab นี้ใช้ $variables เพื่อช่วยในการติดตั้งใช้งานการกำหนดค่า gcloud ใน Cloud Shell

ใน Cloud Shell ให้ทำดังนี้

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

3. การตั้งค่า Producer

สร้าง VPC ของผู้ผลิต

ใน Cloud Shell ให้ทำดังนี้

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

สร้างซับเน็ตของ Producer

ใน 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

จองที่อยู่ IP สำหรับตัวจัดสรรภาระงานภายใน

ใน Cloud Shell ให้ทำดังนี้ โดย Private Service Connect ไม่รองรับการใช้ SHARED_VIP ให้ใช้ GCE_ENDPOINT แทน

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

ใช้คำสั่ง compute addresses describe เพื่อดูที่อยู่ IP ที่จัดสรร

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

สร้างซับเน็ตพร็อกซีระดับภูมิภาค

การจัดสรรพร็อกซีจะอยู่ที่ระดับ VPC ไม่ใช่ระดับตัวจัดสรรภาระงาน คุณต้องสร้างซับเน็ตเฉพาะพร็อกซี 1 รายการในแต่ละภูมิภาคของเครือข่ายเสมือน (VPC) ที่คุณใช้ตัวจัดสรรภาระงานที่อิงตาม Envoy หากคุณทำให้ใช้งานได้ตัวจัดสรรภาระงานหลายตัวในภูมิภาคและเครือข่าย VPC เดียวกัน ตัวจัดสรรภาระงานเหล่านั้นจะใช้ซับเน็ตเฉพาะพร็อกซีเดียวกันสำหรับการจัดสรรภาระงาน

1. ไคลเอ็นต์สร้างการเชื่อมต่อกับที่อยู่ IP และพอร์ตของกฎการส่งต่อของตัวจัดสรรภาระงาน
2. พร็อกซีแต่ละรายการจะรับฟังที่อยู่ IP และพอร์ตที่ระบุโดยกฎการส่งต่อของตัวจัดสรรภาระงานที่เกี่ยวข้อง พร็อกซีตัวใดตัวหนึ่งจะรับและสิ้นสุดการเชื่อมต่อเครือข่ายของไคลเอ็นต์
3. พร็อกซีจะสร้างการเชื่อมต่อกับ VM หรือปลายทางแบ็กเอนด์ที่เหมาะสมใน NEG ตามที่กำหนดโดยแผนที่ URL และบริการแบ็กเอนด์ของตัวจัดสรรภาระงาน

คุณต้องสร้างซับเน็ตเฉพาะพร็อกซีไม่ว่าเครือข่ายจะเป็นโหมดอัตโนมัติหรือกำหนดเองก็ตาม ซับเน็ตเฉพาะพร็อกซีต้องระบุที่อยู่ IP อย่างน้อย 64 รายการ ซึ่งสอดคล้องกับความยาวของคำนำหน้า /26 หรือสั้นกว่า ขนาดซับเน็ตที่แนะนำคือ /23 (ที่อยู่เฉพาะพร็อกซี 512 รายการ)

หมายเหตุ: ซับเน็ตเฉพาะพร็อกซีต้องมีการโฆษณา BGP ของลูกค้าไปยังองค์กร ดังนั้นจึงกำหนดเส้นทางไปยังเครือข่ายในองค์กรได้ และจะเข้าถึงบริการได้ผ่านซับเน็ตพร็อกซีที่ระบุ

ใน 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

สร้างซับเน็ต NAT ของ Private Service Connect

สร้างซับเน็ตเฉพาะอย่างน้อย 1 รายการเพื่อใช้กับ Private Service Connect หากใช้คอนโซล Google Cloud เพื่อเผยแพร่บริการ คุณจะสร้างเครือข่ายย่อยได้ในระหว่างกระบวนการดังกล่าว สร้างซับเน็ตในภูมิภาคเดียวกับตัวจัดสรรภาระงานของบริการ คุณไม่สามารถแปลงซับเน็ตปกติเป็นซับเน็ต 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 กับไฟล์แนบบริการ ใน Codelab คุณได้สร้างกฎไฟร์วอลล์ขาเข้าที่อนุญาตให้ซับเน็ต 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

ภายใน Cloud Shell ให้สร้างกฎ fw-allow-health-check เพื่ออนุญาตให้การตรวจสอบประสิทธิภาพการทำงานของ Google Cloud เข้าถึงบริการในองค์กร (บริการแบ็กเอนด์) ในพอร์ต TCP 80

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

สร้างกฎไฟร์วอลล์ที่อนุญาตให้มีการรับส่งข้อมูลขาเข้าสำหรับซับเน็ตเฉพาะพร็อกซีเพื่อให้ตัวจัดสรรภาระงานสื่อสารกับอินสแตนซ์แบ็กเอนด์ในพอร์ต 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 กับสภาพแวดล้อมภายในองค์กรหรือสภาพแวดล้อมระบบคลาวด์อื่นๆ ให้เหลือน้อยที่สุด ตัวอย่างเช่น หากคุณโฮสต์บริการในสภาพแวดล้อมภายในองค์กรในแฟรงก์เฟิร์ต ประเทศเยอรมนี คุณสามารถระบุโซน europe-west3-a ของ Google Cloud เมื่อสร้าง NEG

นอกจากนี้ หากคุณใช้ Cloud Interconnect โซนที่ใช้สร้าง NEG ควรอยู่ในภูมิภาคเดียวกันกับที่กำหนดค่าไฟล์แนบสำหรับการเชื่อมต่อถึงกันของ Cloud Interconnect

ดูภูมิภาคและโซนที่พร้อมใช้งานได้ที่เอกสารประกอบของ Compute Engine: ภูมิภาคและโซนที่พร้อมใช้งาน

สร้าง NEG การเชื่อมต่อแบบไฮบริดภายใน Cloud Shell โดยใช้คำสั่ง gcloud compute network-endpoint-groups create

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 ให้เพิ่มปลายทาง IP:Port ในองค์กรไปยัง 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

สร้างบริการแบ็กเอนด์สำหรับแบ็กเอนด์ในองค์กรโดยใช้ Hybrid NEG ภายใน Cloud Shell

 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

สร้างแผนที่ URL ภายใน Cloud Shell เพื่อกำหนดเส้นทางคำขอขาเข้าไปยังบริการแบ็กเอนด์

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

สร้างพร็อกซี HTTP เป้าหมาย

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 มีสถานะเป็น "สีเขียว" ซึ่งบ่งชี้ว่าการตรวจสอบสถานะของบริการในองค์กรสำเร็จ

การเลือก ‘on-premise-svc-url-map' จะแสดงที่อยู่ IP ของส่วนหน้าและระบุบริการแบ็กเอนด์

5. ดูเส้นทางที่เรียนรู้จากในองค์กร

ไปที่เครือข่าย VPC → เส้นทาง โปรดทราบว่าซับเน็ตบริการในองค์กรที่เรียนรู้คือ 192.168.1.0/27

6. ตรวจสอบการเชื่อมต่อกับบริการในองค์กร

จาก VPC ของผู้ผลิต เราจะสร้าง VM เพื่อทดสอบการเชื่อมต่อกับบริการในองค์กร จากนั้นการแนบบริการจะเป็นการกำหนดค่าถัดไป

สร้างอินสแตนซ์ทดสอบใน VPC ของผู้ผลิตภายใน Cloud Shell

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

หากต้องการอนุญาตให้ IAP เชื่อมต่อกับอินสแตนซ์ VM ให้สร้างกฎไฟร์วอลล์ที่มีลักษณะดังนี้

• มีผลกับอินสแตนซ์ VM ทั้งหมดที่คุณต้องการให้เข้าถึงได้โดยใช้ IAP
• อนุญาตการรับส่งข้อมูลขาเข้าจากช่วง IP 35.235.240.0/20 ช่วงนี้มีที่อยู่ IP ทั้งหมดที่ IAP ใช้สำหรับการส่งต่อ TCP

สร้างอินสแตนซ์ทดสอบใน VPC ของผู้ผลิตภายใน Cloud Shell

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

เข้าสู่ระบบ test-box-us-central1 โดยใช้ IAP ใน Cloud Shell เพื่อตรวจสอบการเชื่อมต่อกับบริการในองค์กรโดยใช้ curl กับที่อยู่ IP ของตัวจัดสรรภาระงาน ลองอีกครั้งหากหมดเวลา

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

เรียกใช้ curl เพื่อตรวจสอบการเชื่อมต่อกับบริการในองค์กร เมื่อตรวจสอบแล้ว ให้ออกจาก VM แล้วกลับไปที่พรอมต์ของ Cloud Shell แทนที่ IP ของ Internal Load Balancer ตามเอาต์พุตที่ระบุในขั้นตอนที่ 4

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

ในขั้นตอนต่อไปนี้ เราจะสร้าง Service Attachment เมื่อจับคู่กับ Consumer Endpoint แล้ว ก็จะเข้าถึงบริการภายในองค์กรได้โดยไม่ต้องใช้การเพียร์ VPC

สร้าง Service Attachment

สร้างไฟล์แนบบริการภายใน 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>

ตรวจสอบความถูกต้องของไฟล์แนบบริการ TCP

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

ไม่บังคับ: ไปที่บริการเครือข่าย → Private Service Connect เพื่อดูไฟล์แนบบริการที่สร้างขึ้นใหม่

การเลือก Service-1 จะแสดงรายละเอียดเพิ่มเติม รวมถึง URI ของไฟล์แนบบริการที่ผู้ใช้ใช้เพื่อสร้างการเชื่อมต่อบริการส่วนตัว จด URI ไว้เนื่องจากจะต้องใช้ในขั้นตอนถัดไป

รายละเอียดการแนบบริการ: projects/<projectname>/regions/us-central1/serviceAttachments/service-1

8. การตั้งค่าสำหรับผู้บริโภค

สร้าง VPC ของผู้ใช้

ใน Cloud Shell ให้ทำดังนี้

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

สร้างซับเน็ตสำหรับผู้บริโภค

สร้างเครือข่ายย่อย GCE ภายใน Cloud Shell

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

สร้างปลายทางผู้ใช้ (กฎการส่งต่อ)

สร้างที่อยู่ IP แบบคงที่ที่จะใช้เป็นปลายทางสำหรับผู้บริโภคภายใน Cloud Shell

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

มาใช้ URI ของการเชื่อมต่อบริการที่สร้างไว้ก่อนหน้านี้เพื่อสร้างปลายทางผู้ใช้กัน

สร้างอุปกรณ์ปลายทางของผู้บริโภคภายใน 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. ตรวจสอบ Private Service Connect ของผู้บริโภค - VPC ของผู้บริโภค

จาก VPC ของผู้บริโภค ให้ตรวจสอบการเชื่อมต่อ Private Service ที่สำเร็จโดยไปที่บริการเครือข่าย → Private Service Connect → ปลายทางที่เชื่อมต่อ จดบันทึกการเชื่อมต่อ psc-consumer-1 ที่สร้างขึ้นและที่อยู่ IP ที่เกี่ยวข้องซึ่งเราสร้างไว้ก่อนหน้านี้

เมื่อเลือกรายละเอียด psc-consumer-1 ระบบจะระบุรายละเอียด รวมถึง URI ของการเชื่อมต่อบริการ

10. ตรวจสอบ Private Service Connect ของผู้บริโภค - VPC ของผู้ผลิต

จาก VPC ของผู้ผลิต ให้ตรวจสอบการเชื่อมต่อบริการส่วนตัวที่สำเร็จโดยไปที่บริการเครือข่าย → Private Service Connect → บริการที่เผยแพร่ โปรดทราบว่าการเชื่อมต่อ service-1 ที่เผยแพร่แล้วจะระบุถึงกฎการส่งต่อ 1 รายการ (ปลายทางการเชื่อมต่อ)

11. สร้างโซน DNS ส่วนตัวและระเบียน A

สร้างโซน DNS ส่วนตัวที่แมปกับปลายทางการเชื่อมต่อ PSC เพื่อให้เข้าถึงผู้ผลิตได้อย่างราบรื่นจากโฮสต์ใดก็ได้ภายใน VPC

หมายเหตุ: ระบบไม่รองรับการเข้าถึงปลายทางสำหรับผู้บริโภคผ่านการ Peering ของ 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. ตรวจสอบสิทธิ์เข้าถึงบริการของผู้ผลิตของผู้บริโภคโดยใช้ VM

จาก VPC ของผู้ใช้ เราจะสร้าง VM เพื่อทดสอบการเชื่อมต่อกับบริการภายในองค์กรโดยการเข้าถึง consumer endpoint service1.codelabs.net

สร้างอินสแตนซ์ทดสอบใน VPC ของผู้บริโภคภายใน Cloud Shell

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

หากต้องการอนุญาตให้ IAP เชื่อมต่อกับอินสแตนซ์ VM ให้สร้างกฎไฟร์วอลล์ที่มีลักษณะดังนี้

• มีผลกับอินสแตนซ์ VM ทั้งหมดที่คุณต้องการให้เข้าถึงได้โดยใช้ IAP
• อนุญาตการรับส่งข้อมูลขาเข้าจากช่วง IP 35.235.240.0/20 ช่วงนี้มีที่อยู่ IP ทั้งหมดที่ IAP ใช้สำหรับการส่งต่อ TCP

สร้างอินสแตนซ์ทดสอบใน VPC ของผู้บริโภคภายใน Cloud Shell

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

เข้าสู่ระบบ consumer-vm โดยใช้ IAP ใน Cloud Shell เพื่อตรวจสอบการเชื่อมต่อกับบริการในองค์กรโดยใช้ curl กับ dns FQDN service1.codelab.net ลองอีกครั้งหากหมดเวลา

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

เรียกใช้ curl เพื่อตรวจสอบการเชื่อมต่อกับบริการในองค์กร เมื่อตรวจสอบแล้ว ให้ออกจาก VM เพื่อกลับไปที่พรอมต์ของ Cloud Shell

เรียกใช้ curl ภายใน 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!!

ด้านล่างนี้คือตัวอย่างการจับภาพจากบริการในองค์กร โปรดทราบว่าที่อยู่ IP ต้นทาง 172.16.0.13 มาจากช่วงซับเน็ตของพร็อกซี 172.16.0.0/23

13. การล้างข้อมูล Producer

ลบคอมโพเนนต์ของ Producer

ลบอินสแตนซ์ทดสอบใน VPC ของผู้ผลิตภายใน Cloud Shell

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. การล้างข้อมูลผู้บริโภค

ลบคอมโพเนนต์ Consumer

ลบอินสแตนซ์ทดสอบใน VPC ของผู้บริโภคภายใน Cloud Shell

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 กับตัวจัดสรรภาระงาน HTTP(S) ภายในเรียบร้อยแล้ว

คุณสร้างโครงสร้างพื้นฐานของผู้ผลิต และเพิ่มไฟล์แนบบริการใน VPC ของผู้ผลิตที่ชี้ไปยังบริการในองค์กร คุณได้เรียนรู้วิธีสร้างอุปกรณ์ปลายทางของผู้ใช้ใน VPC ของผู้ใช้ที่อนุญาตการเชื่อมต่อกับบริการภายในองค์กร

สิ่งต่อไปที่ควรทำ

ลองใช้ Codelab เหล่านี้

• การใช้บริการส่วนตัวเพื่อเผยแพร่และใช้บริการกับ GKE
• การใช้ Private Service Connect เพื่อเผยแพร่และใช้บริการ
• เชื่อมต่อกับบริการภายในองค์กรผ่านระบบเครือข่ายแบบไฮบริดโดยใช้ Private Service Connect และตัวจัดสรรภาระงาน TCP Proxy ภายใน

อ่านเพิ่มเติมและวิดีโอ

• ภาพรวมของ Private Service Connect
• Private Service Connect คืออะไร
• ประเภทตัวจัดสรรภาระงานที่รองรับ

เอกสารอ้างอิง

• ภาพรวมตัวจัดสรรภาระงาน HTTP(S) ภายใน
• ภาพรวมการตรวจสุขภาพ
• วิธีเผยแพร่บริการโดยใช้ Private Service Connect