1. บทนำ
Cloud Load Balancing รองรับการกระจายการรับส่งข้อมูลไปยังอุปกรณ์ปลายทางที่ขยายออกไปนอก Google Cloud เช่น ศูนย์ข้อมูลภายในองค์กรและระบบคลาวด์สาธารณะอื่นๆ ที่คุณสามารถใช้การเชื่อมต่อแบบผสมเพื่อเข้าถึง
กลยุทธ์แบบผสมเป็นโซลูชันที่ใช้ได้จริงสำหรับคุณในการปรับตัวให้เข้ากับความต้องการของตลาดที่เปลี่ยนแปลง และปรับแอปพลิเคชันให้ทันสมัยโดยค่อยเป็นค่อยไป ซึ่งอาจเป็นการติดตั้งใช้งานแบบผสมชั่วคราวเพื่อย้ายข้อมูลไปยังโซลูชันที่ทันสมัยซึ่งทำงานบนระบบคลาวด์ หรือเป็นโครงสร้างพื้นฐานไอทีขององค์กรอย่างถาวร
การตั้งค่าการกระจายภาระงานแบบผสมยังช่วยให้คุณได้รับประโยชน์จากความสามารถของเครือข่าย Cloud Load Balancing สำหรับบริการที่ทำงานบนโครงสร้างพื้นฐานที่มีอยู่นอก Google Cloud
หากต้องการทำให้บริการแบบผสมนี้ใช้ได้ในเครือข่าย VPC อื่นๆ คุณใช้ Private Service Connect เพื่อเผยแพร่บริการได้ การวางไฟล์แนบบริการไว้ด้านหน้าโหลดบาลานเซอร์ HTTP(s) ระดับภูมิภาคภายในจะช่วยให้คุณอนุญาตให้ไคลเอ็นต์ในเครือข่าย VPC อื่นๆ เข้าถึงบริการแบบผสมผสานที่ทำงานในสภาพแวดล้อมภายในองค์กรหรือระบบคลาวด์อื่นๆ ได้
สิ่งที่คุณจะสร้าง
ใน Codelab นี้ คุณจะสร้างตัวจัดสรรภาระงาน HTTP(S) ภายในที่มีการเชื่อมต่อแบบไฮบริดกับบริการภายในองค์กรโดยใช้กลุ่มปลายทางของเครือข่าย ผู้บริโภค VPC จะสื่อสารกับบริการภายในองค์กรได้โดยใช้พอร์ต 80 และพอร์ต 443 ไม่อยู่ในขอบเขตของ Codelab
สิ่งที่คุณจะได้เรียนรู้
- วิธีสร้างตัวจัดสรรภาระงาน HTTP(S) ภายในที่มีแบ็กเอนด์ NEG แบบไฮบริด
- วิธีสร้างผู้ผลิต (ไฟล์แนบบริการ) และผู้บริโภค (กฎการส่งต่อ) ของ Private Service Connect
สิ่งที่ต้องมี
- เครือข่ายแบบผสมที่ใช้งานอยู่ เช่น HA VPN, Interconnect, SW-WAN
- โปรเจ็กต์ Google Cloud
สร้างการเชื่อมต่อแบบผสม
Google Cloud และสภาพแวดล้อมในองค์กรหรือระบบคลาวด์อื่นๆ ต้องเชื่อมต่อผ่านการเชื่อมต่อแบบผสมผสานโดยใช้ไฟล์แนบ VLAN ของ Cloud Interconnect หรืออุโมงค์ Cloud VPN กับ Cloud Router เราขอแนะนำให้ใช้การเชื่อมต่อที่มีความพร้อมใช้งานสูง
Cloud Router ที่เปิดใช้การกำหนดเส้นทางแบบไดนามิกทั่วโลกจะเรียนรู้เกี่ยวกับปลายทางที่เฉพาะเจาะจงผ่าน BGP และตั้งโปรแกรมปลายทางนั้นลงในเครือข่าย VPC ของ Google Cloud ไม่รองรับการกำหนดเส้นทางระดับภูมิภาคแบบไดนามิก นอกจากนี้ ระบบยังไม่รองรับเส้นทางแบบคงที่
เครือข่าย Google Cloud VPC ที่คุณใช้เพื่อกำหนดค่า Cloud Interconnect หรือ Cloud VPN เป็นเครือข่ายเดียวกับที่คุณใช้กำหนดค่าการทำให้การจัดสรรภาระงานแบบผสมใช้งานได้ ตรวจสอบว่าช่วง CIDR ของซับเน็ตในเครือข่าย VPC ไม่ทับซ้อนกับช่วง CIDR ระยะไกล เมื่อที่อยู่ IP ทับซ้อนกัน เส้นทางซับเน็ตจะมีความสำคัญมากกว่าการเชื่อมต่อระยะไกล
โปรดดูวิธีการที่หัวข้อต่อไปนี้
โฆษณาเส้นทางที่กำหนดเอง
ซับเน็ตด้านล่างต้องมีโฆษณาที่กำหนดเองจาก Cloud Router ไปยังเครือข่ายภายในองค์กรเพื่อให้แน่ใจว่าได้อัปเดตกฎไฟร์วอลล์ภายในองค์กรแล้ว
ซับเน็ต | คำอธิบาย |
172.16.0.0/23 | ซับเน็ตของพร็อกซีที่ใช้สื่อสารกับบริการภายในองค์กรโดยตรง |
22, 35.191.0.0/16 |
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. การตั้งค่าผู้ผลิต
สร้าง VPC ของผู้ผลิต
Inside 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
จองที่อยู่ IP สำหรับตัวจัดสรรภาระงานภายใน
Inside Cloud Shell จะทำสิ่งต่อไปนี้ได้ เนื่องจาก Private Service Connect ไม่รองรับการใช้ SHARED_VIP โปรดใช้ GCE_ENDPOINT แทน
gcloud compute addresses create lb-ip \
--region=us-central1 \
--subnet=subnet-202 \
--purpose=GCE_ENDPOINT
ใช้คำสั่งอธิบายที่อยู่ประมวลผลเพื่อดูที่อยู่ IP ที่จัดสรร
gcloud compute addresses describe lb-ip --region=us-central1 | grep address:
สร้างซับเน็ตของพร็อกซีระดับภูมิภาค
การจัดสรรพร็อกซีจะอยู่ที่ระดับ VPC ไม่ใช่ระดับตัวจัดสรรภาระงาน คุณต้องสร้างซับเน็ตเฉพาะพร็อกซี 1 รายการในแต่ละภูมิภาคของเครือข่ายเสมือน (VPC) ที่คุณใช้ตัวจัดสรรภาระงานที่อิงตาม Envoy หากคุณติดตั้งใช้งานตัวจัดสรรภาระงานหลายตัวในภูมิภาคเดียวกันและเครือข่าย VPC เดียวกัน ตัวจัดสรรภาระงานเหล่านั้นจะใช้ซับเน็ตเฉพาะพร็อกซีเดียวกันสำหรับการจัดสรรภาระงาน
- ไคลเอ็นต์จะเชื่อมต่อกับที่อยู่ IP และพอร์ตของกฎการส่งต่อของตัวจัดสรรภาระงาน
- พ็อกเก็ตพร็อกซีแต่ละรายการจะรอรับฟังที่ที่อยู่ IP และพอร์ตที่ระบุโดยกฎการส่งต่อของตัวจัดสรรภาระงานที่เกี่ยวข้อง พร็อกซีตัวใดตัวหนึ่งจะรับและสิ้นสุดการเชื่อมต่อเครือข่ายของลูกค้า
- พร็อกซีจะสร้างการเชื่อมต่อกับ VM หรือปลายทางแบ็กเอนด์ที่เหมาะสมใน NEG ตามที่กำหนดโดยแผนที่ URL และบริการแบ็กเอนด์ของโปรแกรมจัดสรรภาระงาน
คุณต้องสร้างซับเน็ตเฉพาะพร็อกซี ไม่ว่าเครือข่ายของคุณจะใช้โหมดอัตโนมัติหรือที่กำหนดเองก็ตาม ซับเน็ตเฉพาะพร็อกซีต้องระบุที่อยู่ IP อย่างน้อย 64 รายการ ซึ่งสอดคล้องกับความยาวของคํานําหน้าที่ /26 หรือสั้นกว่า ขนาดซับเน็ตที่แนะนำคือ /23 (ที่อยู่เฉพาะพร็อกซี 512)
Inside 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 กับไฟล์แนบบริการ ในโค้ดแล็บ ให้สร้างกฎไฟร์วอลล์ Ingress ที่อนุญาตให้ซับเน็ต 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 เพื่ออนุญาตให้การตรวจสอบประสิทธิภาพการทำงานของ 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 ให้ใช้ ZONE ที่ลดระยะทางทางภูมิศาสตร์ระหว่าง Google Cloud กับสภาพแวดล้อมภายในองค์กรหรือสภาพแวดล้อมระบบคลาวด์อื่นให้น้อยที่สุด เช่น หากโฮสต์บริการในสภาพแวดล้อมภายในองค์กรที่แฟรงก์เฟิร์ต เยอรมนี คุณสามารถระบุโซน europe-west3-a ของ Google Cloud เมื่อสร้าง NEG
นอกจากนี้ หากคุณใช้ Cloud Interconnect ZONE ที่ใช้ในการสร้าง NEG ควรอยู่ในภูมิภาคเดียวกับที่มีการกําหนดค่าไฟล์แนบ Cloud Interconnect
ดูภูมิภาคและโซนที่ใช้ได้ในเอกสารประกอบของ Compute Engine: ภูมิภาคและโซนที่ใช้ได้
ใน Cloud Shell ให้สร้าง NEG การเชื่อมต่อแบบผสมโดยใช้คำสั่ง 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
Inside 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 ให้สร้างการแมป URL เพื่อกำหนดเส้นทางคำขอขาเข้าไปยังบริการแบ็กเอนด์
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 ให้ไปที่บริการเครือข่าย → การจัดสรรภาระงาน → ตัวจัดสรรภาระงาน โปรดทราบว่า NEG 1 รายการเป็น "สีเขียว" ซึ่งบ่งบอกว่าบริการในระบบออน prem ผ่านการตรวจสอบประสิทธิภาพการทำงาน
การเลือก ‘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
ภายใน Cloud Shell สร้างอินสแตนซ์ทดสอบใน VPN ของผู้ผลิต
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 เพื่อตรวจสอบการเชื่อมต่อกับบริการในองค์กรโดยดำเนินการ URL กับที่อยู่ IP ของยอดคงเหลือสำหรับภาระงาน โปรดลองอีกครั้งหากหมดเวลา
gcloud compute ssh test-box-us-central1 --project=$psclab --zone=us-central1-a --tunnel-through-iap
ทำการตรวจสอบการเชื่อมต่อด้วย Curl กับบริการภายในองค์กร เมื่อออกจาก VM ที่ตรวจสอบแล้วโดยกลับไปยังข้อความแจ้งของ Cloud Shell แทนที่ IP ของตัวจัดสรรภาระงานภายในตามเอาต์พุตที่ระบุไว้ในขั้นตอนที่ 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
ในขั้นตอนต่อไปนี้ เราจะสร้างไฟล์แนบบริการ เมื่อจับคู่กับปลายทางของผู้บริโภคแล้ว คุณจะเข้าถึงบริการในสถานที่ได้โดยไม่ต้องใช้การเพียร์ VPC
สร้างไฟล์แนบบริการ
Inside 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
สร้างปลายทางของผู้บริโภค (กฎการส่งต่อ)
ภายใน Cloud Shell สร้างที่อยู่ IP แบบคงที่ที่จะใช้เป็นปลายทางของผู้บริโภค
gcloud compute addresses create psc-consumer-ip-1 --region=us-central1 --subnet=subnet-102 --addresses 10.100.2.10
มาสร้างปลายทางของผู้บริโภคโดยใช้ URI ไฟล์แนบบริการที่สร้างขึ้นก่อนหน้านี้
สร้างปลายทางสำหรับผู้บริโภค Inside 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. ตรวจสอบ Consumer Private Service Connect - VPC ของผู้บริโภค
จาก VPC ของผู้บริโภค ให้ตรวจสอบการเชื่อมต่อบริการส่วนตัวที่สำเร็จโดยไปที่บริการเครือข่าย → 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 ซึ่งจะช่วยให้เข้าถึง Producer จากโฮสต์ภายใน 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 เพื่อทดสอบการเชื่อมต่อกับบริการในองค์กรโดยการเข้าถึงปลายทางของผู้บริโภค 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
ดำเนินการใน Cloud Shell ด้วย curl
$ 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
ภายใน Cloud Shell ลบอินสแตนซ์ทดสอบใน Producer 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 Shell ให้ลบอินสแตนซ์ทดสอบใน 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 ด้วยตัวจัดสรรภาระงาน HTTP(S) ภายในเรียบร้อยแล้ว
คุณได้สร้างโครงสร้างพื้นฐานของผู้ผลิต และเพิ่มไฟล์แนบบริการใน VPC ของผู้ผลิตซึ่งชี้ไปยังบริการในองค์กร คุณได้เรียนรู้วิธีสร้างปลายทางของผู้บริโภคใน VPC ของผู้บริโภคที่อนุญาตให้เชื่อมต่อกับบริการภายในองค์กรแล้ว
สิ่งที่ต้องทำต่อไป
ลองดู Codelab เหล่านี้...
- การใช้บริการส่วนตัวเพื่อเผยแพร่และใช้บริการด้วย GKE
- การใช้ Private Service Connect เพื่อเผยแพร่และใช้บริการ
- เชื่อมต่อกับบริการในองค์กรผ่านเครือข่ายแบบผสมโดยใช้ Private Service Connect และตัวจัดสรรภาระงานพร็อกซี TCP ภายใน