1. บทนำ
เหตุผลที่ต้องย้ายข้อมูลจากแอปพลิเคชันแบบโมโนลิธไปยังสถาปัตยกรรม Microservice การแบ่งแอปพลิเคชันออกเป็น Microservice มีข้อดีดังนี้ ส่วนใหญ่แล้วเกิดจากการที่ Microservice เชื่อมต่อกันแบบหลวม
- Microservice สามารถทดสอบและทำให้ใช้งานได้แบบอิสระ ยิ่งหน่วยการติดตั้งใช้งานน้อย การทำให้ใช้งานได้จะง่ายขึ้น
- นำไปติดตั้งใช้งานในภาษาและกรอบงานต่างๆ ได้ สำหรับ Microservice แต่ละรายการ คุณสามารถเลือกเทคโนโลยีที่ดีที่สุดสำหรับกรณีการใช้งานนั้นๆ ได้
- ทีมต่างๆ สามารถจัดการได้ การมีพรมแดนระหว่าง Microservice ทำให้สามารถจัดสรรทีมให้กับ Microservice อย่างน้อย 1 อย่างได้ง่ายขึ้น
- การเปลี่ยนไปใช้ Microservice จะช่วยให้คุณลดการพึ่งพาระหว่างทีมได้ แต่ละทีมต้องสนใจเฉพาะ API ของ Microservice ที่แต่ละทีมใช้อยู่ ทีมไม่จำเป็นต้องคำนึงถึงวิธีใช้ Microservice เกี่ยวกับรอบการเผยแพร่ และอีกมากมาย
- คุณสามารถออกแบบให้ไม่สำเร็จได้ง่ายขึ้น การมีขอบเขตที่ชัดเจนระหว่างบริการต่างๆ จะช่วยให้พิจารณาได้ง่ายขึ้นว่าจะทำอย่างไรหากบริการหยุดชะงัก
ข้อเสียบางอย่างเมื่อเปรียบเทียบกับโมโนลิธมีดังต่อไปนี้
- เนื่องจากแอปที่ใช้ Microservice เป็นเครือข่ายของบริการต่างๆ ที่มักมีปฏิสัมพันธ์ในลักษณะที่ไม่ชัดเจน ระบบจึงมีแนวโน้มที่จะเพิ่มความซับซ้อนโดยรวมของระบบ
- Microservice สื่อสารผ่านเครือข่าย ซึ่งต่างจากโครงสร้างภายในของโมโนลิธ ในบางสถานการณ์ นี่อาจเป็นข้อกังวลด้านความปลอดภัย Istio แก้ปัญหานี้ด้วยการเข้ารหัสการรับส่งข้อมูลระหว่าง Microservice โดยอัตโนมัติ
- การที่จะได้ประสิทธิภาพในระดับเดียวกันกับวิธีการแบบโมโนลิธนั้นอาจทำได้ยากเนื่องจากเวลาในการตอบสนองระหว่างบริการต่างๆ
- การทำงานของระบบไม่ได้เกิดจากบริการเดียว แต่เกิดจากหลายบริการและการโต้ตอบกัน ด้วยเหตุนี้ การทำความเข้าใจเกี่ยวกับลักษณะการทำงานของระบบในเวอร์ชันที่ใช้งานจริง (ความสามารถในการสังเกต) จึงเป็นเรื่องยาก Istio ก็เป็นวิธีแก้ปัญหานี้เช่นกัน
ในห้องทดลองนี้ เราจะเรียกใช้ Microservice ใน Google Kubernetes Engine (GKE) Kubernetes เป็นแพลตฟอร์มสำหรับจัดการ โฮสต์ ปรับขนาด และทำให้คอนเทนเนอร์ใช้งานได้ คอนเทนเนอร์คือวิธีแบบพกพาในการจัดแพ็กเกจและการเรียกใช้โค้ด โดยเหมาะกับรูปแบบ Microservice ซึ่งแต่ละ Microservice สามารถทำงานในคอนเทนเนอร์ของตัวเอง
สำหรับห้องทดลองนี้ เราจะทำให้แอปพลิเคชันแบบโมโนลิธที่มีอยู่ใช้งานได้กับคลัสเตอร์ Google Kubernetes Engine จากนั้นจึงแตกรายละเอียดเป็น Microservice
แผนภาพสถาปัตยกรรมของ Microservice
เราจะเริ่มต้นด้วยการแบ่งโมโนลิธออกเป็น 3 Microservice ทีละรายการ Microservice ได้แก่ คำสั่งซื้อ ผลิตภัณฑ์ และฟรอนท์เอนด์ เราสร้างอิมเมจ Docker สำหรับ Microservice แต่ละรายการโดยใช้ Cloud Build ซึ่งเราทริกเกอร์จากภายใน Cloud Shell จากนั้นเราจะทำให้ Microservice ใช้งานได้และแสดง Microservice บน Google Kubernetes Engine (GKE) ด้วยบริการ Kubernetes ประเภท LoadBalancer เราจะทำเช่นนี้สำหรับแต่ละบริการ ในขณะเดียวกันก็เปลี่ยนโครงสร้างภายในโค้ดจากโมโนลิธของเรา ในระหว่างขั้นตอนนี้ เราจะมีทั้งโมโนลิธและ Microservice ที่ทำงานอยู่จนถึงตอนท้ายสุดเมื่อเราสามารถลบโมโนลิธของเราได้
สิ่งที่คุณจะได้เรียนรู้
- วิธีแตกโมโนลิธให้เป็น Microservice
- วิธีสร้างคลัสเตอร์ Google Kubernetes Engine
- วิธีสร้างอิมเมจ Docker
- วิธีทำให้อิมเมจ Docker ใช้งานได้กับ Kubernetes
ข้อกำหนดเบื้องต้น
- บัญชี Google Cloud Platform ที่มีสิทธิ์การเข้าถึงระดับผู้ดูแลระบบเพื่อสร้างโปรเจ็กต์หรือโปรเจ็กต์ที่มีบทบาทเจ้าของโปรเจ็กต์
- ความเข้าใจพื้นฐานของ Docker และ Kubernetes
2. การตั้งค่าสภาพแวดล้อม
การตั้งค่าสภาพแวดล้อมตามเวลาที่สะดวก
หากยังไม่มีบัญชี Google (Gmail หรือ Google Apps) คุณต้องสร้างบัญชีก่อน ลงชื่อเข้าใช้คอนโซล Google Cloud Platform ( console.cloud.google.com) และสร้างโปรเจ็กต์ใหม่
โปรดจดจำรหัสโปรเจ็กต์ ซึ่งเป็นชื่อที่ไม่ซ้ำกันในโปรเจ็กต์ Google Cloud ทั้งหมด (ชื่อด้านบนมีคนใช้แล้ว และจะใช้ไม่ได้ ขออภัย) และจะมีการอ้างอิงใน Codelab ว่า PROJECT_ID ในภายหลัง
ถัดไป คุณจะต้องเปิดใช้การเรียกเก็บเงินใน Developers Console เพื่อใช้ทรัพยากร Google Cloud และเปิดใช้ Container Engine API
การใช้งาน Codelab นี้น่าจะมีค่าใช้จ่ายไม่เกิน 2-3 ดอลลาร์ แต่อาจมากกว่านี้หากคุณตัดสินใจใช้ทรัพยากรเพิ่มหรือปล่อยให้ทำงาน (ดูส่วน "ล้างข้อมูล" ในตอนท้ายของเอกสารนี้) ดูราคาของ Google Kubernetes Engine ได้ที่นี่
ผู้ใช้ใหม่ของ Google Cloud Platform มีสิทธิ์รับช่วงทดลองใช้ฟรี$300
Google Cloud Shell
แม้ว่า Google Cloud และ Kubernetes จะทำงานจากระยะไกลได้จากแล็ปท็อป แต่ใน Codelab นี้ เราจะใช้ Google Cloud Shell ซึ่งเป็นสภาพแวดล้อมบรรทัดคำสั่งที่ทำงานในระบบคลาวด์
เครื่องเสมือนแบบ Debian นี้เต็มไปด้วยเครื่องมือการพัฒนาทั้งหมดที่คุณต้องการ โดยมีไดเรกทอรีหลักขนาด 5 GB ที่ทำงานอย่างต่อเนื่องใน Google Cloud ซึ่งจะช่วยเพิ่มประสิทธิภาพของเครือข่ายและการตรวจสอบสิทธิ์ได้อย่างมาก ซึ่งหมายความว่าสิ่งที่คุณต้องมีสำหรับ Codelab นี้คือเบราว์เซอร์ (ใช่แล้ว ทั้งหมดนี้ทำงานได้บน Chromebook)
- หากต้องการเปิดใช้งาน Cloud Shell จาก Cloud Console เพียงคลิกเปิดใช้งาน Cloud Shell
(จะใช้เวลาเพียงไม่นานในการจัดสรรและเชื่อมต่อกับสภาพแวดล้อม)
เมื่อเชื่อมต่อกับ Cloud Shell คุณควรเห็นว่าตนเองผ่านการตรวจสอบสิทธิ์แล้วและโปรเจ็กต์ได้รับการตั้งค่าเป็น PROJECT_ID แล้ว
gcloud auth list
เอาต์พุตจากคำสั่ง
Credentialed accounts: - <myaccount>@<mydomain>.com (active)
gcloud config list project
เอาต์พุตจากคำสั่ง
[core] project = <PROJECT_ID>
หากโปรเจ็กต์ไม่ได้ตั้งค่าไว้ด้วยเหตุผลบางประการ ให้ใช้คำสั่งต่อไปนี้
gcloud config set project <PROJECT_ID>
กำลังมองหา PROJECT_ID ของคุณอยู่ใช่ไหม ตรวจสอบรหัสที่คุณใช้ในขั้นตอนการตั้งค่าหรือดูในแดชบอร์ด Cloud Console
Cloud Shell ยังตั้งค่าตัวแปรสภาพแวดล้อมโดยค่าเริ่มต้นด้วย ซึ่งอาจเป็นประโยชน์เมื่อคุณเรียกใช้คำสั่งในอนาคต
echo $GOOGLE_CLOUD_PROJECT
เอาต์พุตจากคำสั่ง
<PROJECT_ID>
- สุดท้าย ให้ตั้งค่าโซนและการกำหนดค่าโปรเจ็กต์เริ่มต้น
gcloud config set compute/zone us-central1-f
คุณเลือกโซนต่างๆ ได้หลากหลาย ดูข้อมูลเพิ่มเติมได้ที่ภูมิภาคและ โซน
3. โคลนที่เก็บซอร์ส
เราใช้แอปพลิเคชันโมโนลิธที่มีอยู่ของเว็บไซต์อีคอมเมิร์ซในจินตนาการที่มีหน้ายินดีต้อนรับแบบง่ายๆ หน้าผลิตภัณฑ์ และหน้าประวัติการสั่งซื้อ เราเพียงต้องโคลนแหล่งที่มาจากที่เก็บ Git เพื่อมุ่งเน้นที่การแบ่งทรัพยากรออกเป็น Microservice และการทำให้ใช้งานได้กับ Google Kubernetes Engine (GKE)
เรียกใช้คำสั่งต่อไปนี้เพื่อโคลนที่เก็บ Git ไปยังอินสแตนซ์ Cloud Shell แล้วเปลี่ยนเป็นไดเรกทอรีที่เหมาะสม นอกจากนี้ เราจะติดตั้งทรัพยากร Dependency ของ NodeJS ด้วย เพื่อที่เราจะได้ทดสอบโมโนลิธก่อนนำไปใช้งาน อาจใช้เวลา 2-3 นาทีสคริปต์นี้จึงจะทำงาน
cd ~ git clone https://github.com/googlecodelabs/monolith-to-microservices.git cd ~/monolith-to-microservices ./setup.sh
การดำเนินการนี้จะโคลนที่เก็บ GitHub ของเรา เปลี่ยนเป็นไดเรกทอรี และติดตั้งทรัพยากร Dependency ที่จำเป็นในการเรียกใช้แอปพลิเคชันในเครื่อง อาจใช้เวลา 2-3 นาทีสคริปต์นี้จึงจะทำงาน
4. สร้างคลัสเตอร์ GKE
เมื่อคุณมีสภาพแวดล้อมสำหรับนักพัฒนาซอฟต์แวร์ที่ทำงานอยู่แล้ว เราจำเป็นต้องมีคลัสเตอร์ Kubernetes เพื่อติดตั้งใช้งาน Monolith และ Microservice ในที่สุด ก่อนที่เราจะสร้างคลัสเตอร์ได้ เราต้องตรวจสอบว่าได้เปิดใช้ API ที่ถูกต้องแล้ว เรียกใช้คำสั่งต่อไปนี้เพื่อเปิดใช้ Container API เพื่อให้เราใช้ Google Kubernetes Engine ได้
gcloud services enable container.googleapis.com
ตอนนี้เราพร้อมแล้วที่จะสร้างคลัสเตอร์ของเรา เรียกใช้คำสั่งด้านล่างเพื่อสร้างคลัสเตอร์ GKE ที่ชื่อ fancy-cluster ด้วย 3 โหนด
gcloud container clusters create fancy-cluster --num-nodes 3
การสร้างคลัสเตอร์อาจใช้เวลาหลายนาที เมื่อคำสั่งเสร็จสมบูรณ์แล้ว ให้เรียกใช้คำสั่งต่อไปนี้และดูอินสแตนซ์ VM ของผู้ปฏิบัติงาน 3 รายการของคลัสเตอร์
gcloud compute instances list
เอาต์พุต:
NAME ZONE MACHINE_TYPE PREEMPTIBLE INTERNAL_IP EXTERNAL_IP STATUS gke-fancy-cluster-default-pool-ad92506d-1ng3 us-east4-a n1-standard-1 10.150.0.7 XX.XX.XX.XX RUNNING gke-fancy-cluster-default-pool-ad92506d-4fvq us-east4-a n1-standard-1 10.150.0.5 XX.XX.XX.XX RUNNING gke-fancy-cluster-default-pool-ad92506d-4zs3 us-east4-a n1-standard-1 10.150.0.6 XX.XX.XX.XX RUNNING
คุณยังดูคลัสเตอร์ Kubernetes และข้อมูลที่เกี่ยวข้องในคอนโซล Google Cloud ได้ด้วย คลิกปุ่มเมนูที่ด้านซ้ายบน เลื่อนลงไปที่ Kubernetes Engine แล้วคลิกคลัสเตอร์ คุณควรเห็นคลัสเตอร์ที่ชื่อ fancy-cluster
ยินดีด้วย คุณเพิ่งสร้างคลัสเตอร์ Kubernetes แรก
5. ทำให้ Monolith ที่มีอยู่ใช้งานได้
เนื่องจากจุดมุ่งเน้นของห้องทดลองนี้คือการแนะนำการแตกโมโนลิ่มให้เป็น Microservice เราจึงต้องเตรียมแอปพลิเคชันโมโนลิธให้พร้อมใช้งาน เรียกใช้สคริปต์ต่อไปนี้เพื่อทำให้แอปพลิเคชันแบบโมโนลิธใช้งานได้ในคลัสเตอร์ GKE ของเรา ตามวัตถุประสงค์ของห้องทดลองนี้
cd ~/monolith-to-microservices ./deploy-monolith.sh
การเข้าถึง The Monolith
หากต้องการค้นหาที่อยู่ IP ภายนอกสำหรับแอปพลิเคชัน Monolith ให้เรียกใช้คำสั่งต่อไปนี้
kubectl get service monolith
คุณควรเห็นผลลัพธ์ที่คล้ายกับข้อความต่อไปนี้
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE monolith 10.3.251.122 203.0.113.0 80:30877/TCP 3d
หมายเหตุ: ต้องมีการจัดสรรตัวจัดสรรภาระงานและ IP ภายนอก จึงต้องใช้เวลาในการดำเนินการ หากเอาต์พุตแสดง IP ภายนอกเป็น
<pending> ให้เวลาสักครู่แล้วลองอีกครั้ง
เมื่อคุณได้ระบุที่อยู่ IP ภายนอกสำหรับโมโนลิธแล้ว ให้คัดลอกที่อยู่ IP เปิดเบราว์เซอร์และไปที่ URL นี้ (เช่น http://203.0.113.0) เพื่อตรวจสอบว่าโมโนลิธของคุณเข้าถึงได้หรือไม่
คุณควรจะเห็นหน้ายินดีต้อนรับสำหรับเว็บไซต์แบบโมโนลิธเช่นเดียวกับภาพด้านบน หน้ายินดีต้อนรับเป็นหน้าแบบคงที่ที่จะแสดงโดย Frontend Microservice ในภายหลัง ตอนนี้คุณมีโมโนลิธที่ทำงานบน Kubernetes ได้อย่างสมบูรณ์แล้ว
6. ย้ายข้อมูลคำสั่งซื้อไปยัง Microservice
ตอนนี้เรามีเว็บไซต์แบบโมโนลิธที่กำลังทำงานอยู่บน GKE แล้ว เราก็สามารถเริ่มแยกบริการแต่ละรายการออกเป็น Microservice ได้ โดยปกติแล้ว การวางแผนควรมีบริการต่างๆ ที่จะแบ่งย่อยออกเป็นส่วนย่อยๆ ซึ่งมักจะครอบคลุมเฉพาะบางส่วนของแอปพลิเคชัน เช่น โดเมนธุรกิจ สำหรับการสาธิต เราได้สร้างตัวอย่างเล็กๆ น้อยๆ และแยกบริการแต่ละอย่างที่เกี่ยวข้องกับโดเมนธุรกิจ คำสั่งซื้อ ผลิตภัณฑ์ และฟรอนท์เอนด์ เราได้ย้ายข้อมูลโค้ดแล้ว และเราจะมุ่งเน้นที่การสร้างและทำให้บริการใช้งานได้ใน Google Kubernetes Engine (GKE)
สร้าง Microservice คำสั่งซื้อใหม่
บริการแรกที่เราจะแยกออกเป็นบริการสั่งซื้อ เราจะใช้ Codebase แยกต่างหากที่มีให้และสร้างคอนเทนเนอร์ Docker แยกต่างหากสำหรับบริการนี้
สร้างคอนเทนเนอร์ Docker ด้วย Google Cloud Build
เนื่องจากเราได้ย้ายข้อมูล Codebase ให้คุณแล้ว ขั้นตอนแรกที่เราต้องทำคือสร้างคอนเทนเนอร์ Docker ของบริการสั่งซื้อโดยใช้ Google Cloud Build
ตามปกติแล้ว คุณจะต้องใช้แนวทาง 2 ขั้นตอน ซึ่งได้แก่ การสร้างคอนเทนเนอร์ Docker และพุชไปยังรีจิสทรีเพื่อจัดเก็บอิมเมจที่ GKE จะดึงข้อมูล แต่เราทำให้ชีวิตง่ายขึ้นได้ โดยใช้ Google Cloud Build เพื่อสร้างคอนเทนเนอร์ Docker และนำอิมเมจลงใน Google Cloud Container Registry ด้วยคำสั่งเดียว การดำเนินการนี้ช่วยให้เราออกคำสั่งเดียวเพื่อสร้างและย้ายอิมเมจไปยังคอนเทนเนอร์รีจิสทรีได้ หากต้องการดูขั้นตอนการสร้างไฟล์ Docker ด้วยตนเองและพุชไฟล์ ให้ไปที่ที่นี่
Google Cloud Build จะบีบอัดไฟล์จากไดเรกทอรีและย้ายไฟล์เหล่านั้นไปยังที่เก็บข้อมูล Google Cloud Storage กระบวนการบิลด์จะนำไฟล์ทั้งหมดจากที่เก็บข้อมูลและใช้ Dockerfile เพื่อเรียกใช้กระบวนการบิลด์ของ Docker เนื่องจากเราระบุ Flag --tag กับโฮสต์เป็น gcr.io สำหรับอิมเมจ Docker แล้วระบบจะพุชอิมเมจ Docker ที่ได้ไปยัง Google Cloud Container Registry
เรียกใช้คำสั่งต่อไปนี้เพื่อสร้างคอนเทนเนอร์ Docker และพุชไปยัง Google Container Registry
cd ~/monolith-to-microservices/microservices/src/orders
gcloud builds submit --tag gcr.io/${GOOGLE_CLOUD_PROJECT}/orders:1.0.0 .
กระบวนการนี้จะใช้เวลาสักครู่ แต่หลังจากที่ดำเนินการเสร็จสมบูรณ์แล้ว จะมีเอาต์พุตในเทอร์มินัลซึ่งมีลักษณะคล้ายกับด้านล่างนี้
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- ID CREATE_TIME DURATION SOURCE IMAGES STATUS 1ae295d9-63cb-482c-959b-bc52e9644d53 2019-08-29T01:56:35+00:00 33S gs://<PROJECT_ID>_cloudbuild/source/1567043793.94-abfd382011724422bf49af1558b894aa.tgz gcr.io/<PROJECT_ID>/orders:1.0.0 SUCCESS
หากต้องการดูประวัติบิลด์หรือดูกระบวนการแบบเรียลไทม์ ให้ไปที่คอนโซล Google Cloud คลิกปุ่มเมนูที่ด้านบนซ้ายและเลื่อนลงไปที่ "เครื่องมือ" → Cloud Build แล้วคลิก "ประวัติ" ในส่วนนี้คุณจะเห็นรายการงานสร้างก่อนหน้าทั้งหมดของคุณ ควรมีเพียง 1 งานที่คุณเพิ่งสร้างขึ้น
หากคลิกรหัสบิลด์ คุณจะเห็นรายละเอียดทั้งหมดสำหรับบิลด์นั้น รวมถึงเอาต์พุตบันทึก
จากหน้ารายละเอียดบิลด์ คุณจะดูอิมเมจคอนเทนเนอร์ที่สร้างขึ้นได้โดยคลิกชื่ออิมเมจในส่วนข้อมูลบิลด์
ทำให้คอนเทนเนอร์ใช้งานได้กับ GKE
ตอนนี้เราได้สร้างคอนเทนเนอร์เว็บไซต์และพุชคอนเทนเนอร์ไปยัง Google Container Registry แล้ว ตอนนี้ก็ถึงเวลาทำให้ใช้งานได้กับ Kubernetes
Kubernetes จะแสดงแอปพลิเคชันเป็น Pod ซึ่งเป็นหน่วยที่แสดงถึงคอนเทนเนอร์ (หรือกลุ่มคอนเทนเนอร์ที่มีการเชื่อมต่อแบบแน่น) พ็อดเป็นหน่วยที่นำไปใช้ได้ที่มีขนาดเล็กที่สุดใน Kubernetes ในบทแนะนำนี้ พ็อดแต่ละรายการจะมีเฉพาะคอนเทนเนอร์ microservices
หากต้องการทำให้แอปพลิเคชันใช้งานได้และจัดการบนคลัสเตอร์ GKE คุณต้องสื่อสารกับระบบการจัดการคลัสเตอร์ Kubernetes โดยทั่วไปคุณสามารถทำได้โดยใช้เครื่องมือบรรทัดคำสั่ง kubectl จากภายใน Cloud Shell
ก่อนอื่น เราจะสร้างทรัพยากรการทำให้ใช้งานได้ การทำให้ใช้งานได้จะจัดการสำเนาแอปพลิเคชันของคุณหลายรายการ ซึ่งเรียกว่าตัวจำลอง และกำหนดเวลาให้ทำงานในแต่ละโหนดในคลัสเตอร์ ในกรณีนี้ การทำให้ใช้งานได้จะเรียกใช้แอปพลิเคชันเพียงพ็อดเดียวเท่านั้น การทำให้ใช้งานได้จะช่วยแก้ปัญหานี้โดยการสร้าง ReplicaSet ReplicaSet มีหน้าที่ในการตรวจสอบว่าจำนวนของตัวจำลองที่ระบุทำงานอยู่เสมอ
คำสั่ง kubectl create deployment ด้านล่างจะทำให้ Kubernetes สร้างการทำให้ใช้งานได้ที่มีชื่อว่า orders บนคลัสเตอร์ของคุณด้วยตัวจำลอง 1
เรียกใช้คำสั่งต่อไปนี้เพื่อทำให้แอปพลิเคชันของคุณใช้งานได้
kubectl create deployment orders --image=gcr.io/${GOOGLE_CLOUD_PROJECT}/orders:1.0.0
ยืนยันการทำให้ใช้งานได้
หากต้องการยืนยันว่าสร้างการทำให้ใช้งานได้เรียบร้อยแล้ว ให้เรียกใช้คำสั่งต่อไปนี้ โดยอาจใช้เวลาสักครู่เพื่อให้สถานะพ็อดทำงาน
kubectl get all
เอาต์พุต:
NAME READY STATUS RESTARTS AGE pod/monolith-779c8d95f5-dxnzl 1/1 Running 0 15h pod/orders-5bc6969d76-kdxkk 1/1 Running 0 21s NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/kubernetes ClusterIP 10.39.240.1 <none> 443/TCP 19d service/monolith LoadBalancer 10.39.241.130 34.74.209.57 80:30412/TCP 15h NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/monolith 1/1 1 1 15h deployment.apps/orders 1/1 1 1 21s NAME DESIRED CURRENT READY AGE replicaset.apps/monolith-779c8d95f5 1 1 1 15h replicaset.apps/orders-5bc6969d76 1 1 1 21s
ผลลัพธ์นี้แสดงให้เราเห็นหลายๆ อย่าง เราจะสามารถดูการติดตั้งใช้งานในปัจจุบัน, ReplicaSet ของเราซึ่งมีจำนวนพ็อดที่ต้องการเป็น 1 และพ็อดของเราทำงานอยู่ ดูเหมือนว่าทุกอย่างสร้างเสร็จเรียบร้อยแล้ว
แสดงคอนเทนเนอร์ GKE
เราได้ทำให้แอปพลิเคชันใช้งานได้บน GKE แล้ว แต่ไม่มีวิธีเข้าถึงแอปพลิเคชันภายนอกคลัสเตอร์ โดยค่าเริ่มต้น คอนเทนเนอร์ที่คุณเรียกใช้บน GKE จะเข้าถึงจากอินเทอร์เน็ตไม่ได้ เนื่องจากไม่มีที่อยู่ IP ภายนอก คุณต้องเปิดเผยแอปพลิเคชันต่อการเข้าชมจากอินเทอร์เน็ตผ่านทรัพยากรบริการอย่างชัดแจ้ง บริการให้การสนับสนุนเครือข่ายและ IP แก่พ็อดของแอปพลิเคชัน GKE สร้าง IP ภายนอกและตัวจัดสรรภาระงาน ( ขึ้นอยู่กับการเรียกเก็บเงิน) สำหรับแอปพลิเคชัน
เมื่อเราทำให้บริการ Orders ใช้งานได้ เราได้เปิดเผยบริการนี้บนพอร์ต 8081 เป็นการภายในผ่านการติดตั้งใช้งาน Kubernetes ในการเผยแพร่บริการนี้สู่ภายนอก เราจำเป็นต้องสร้างบริการ Kubernetes ประเภท LoadBalancer เพื่อกำหนดเส้นทางการรับส่งข้อมูลจากพอร์ต 80 ไปยังพอร์ตภายใน 8081 สำหรับบริการคำสั่งซื้อ เรียกใช้คำสั่งต่อไปนี้เพื่อแสดงเว็บไซต์ของคุณในอินเทอร์เน็ต
kubectl expose deployment orders --type=LoadBalancer --port 80 --target-port 8081
การเข้าถึงบริการ
GKE จะกำหนดที่อยู่ IP ภายนอกให้กับทรัพยากรบริการ ไม่ใช่การทำให้ใช้งานได้ หากต้องการค้นหา IP ภายนอกที่ GKE จัดสรรให้กับแอปพลิเคชัน คุณสามารถตรวจสอบบริการด้วยคำสั่ง kubectl get service ได้ดังนี้
kubectl get service orders
เอาต์พุต:
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE orders 10.3.251.122 203.0.113.0 80:30877/TCP 3d
เมื่อคุณระบุที่อยู่ IP ภายนอกสำหรับแอปพลิเคชันแล้ว ให้คัดลอกที่อยู่ IP บันทึกเก็บไว้สำหรับขั้นตอนถัดไปเมื่อเราเปลี่ยนโมโนลิธให้ชี้ไปที่บริการ "คำสั่งซื้อ" ใหม่ของเรา
กำหนดค่า Monolith ใหม่
เนื่องจากเรานำบริการ Orders ออกจาก Monolith เราจะต้องแก้ไข Monolith ให้ชี้ไปที่ Microservice ภายนอกใหม่
เมื่อจะแจกแจงโมโนลิธ เราจะนำชิ้นส่วนของโค้ดออกจากฐานของโค้ดหนึ่งให้เป็นหลายโค้ดและนำไปปรับใช้แยกกัน เนื่องจาก Microservice ทำงานบนเซิร์ฟเวอร์อื่น เราจึงไม่สามารถอ้างอิง URL บริการของเราเป็นเส้นทางสัมบูรณ์ได้อีกต่อไป เราจึงต้องกำหนดเส้นทางไปยังที่อยู่เซิร์ฟเวอร์ใหม่ของ Order Microservice โปรดทราบว่าการดำเนินการนี้จะต้องพักการให้บริการโมโนลิธเพื่ออัปเดต URL สำหรับแต่ละบริการที่จะมีการแยกย่อย ควรคำนึงถึงเรื่องนี้เมื่อวางแผนย้าย Microservice และ Monolith ไปยังเวอร์ชันที่ใช้งานจริงในกระบวนการย้ายข้อมูล Microservice
เราจำเป็นต้องอัปเดตไฟล์การกำหนดค่าในโมโนลิธให้ชี้ไปยังที่อยู่ IP ของ Orders microservices ใหม่ ใช้ตัวแก้ไขนาโนเพื่อแทนที่ URL ในเครื่องด้วยที่อยู่ IP ของ Orders Microservice ใหม่ของเรา เรียกใช้คำสั่งต่อไปนี้เพื่อแก้ไข
cd ~/monolith-to-microservices/react-app nano .env.monolith
เมื่อตัวแก้ไขเปิดขึ้น ไฟล์ของคุณควรมีลักษณะดังนี้
REACT_APP_ORDERS_URL=/service/orders REACT_APP_PRODUCTS_URL=/service/products
แทนที่ REACT_APP_ORDERS_URL เป็นรูปแบบใหม่ขณะแทนที่ด้วยที่อยู่ IP ของ Orders Microservice ให้ตรงกับด้านล่าง
REACT_APP_ORDERS_URL=http://<ORDERS_IP_ADDRESS>/api/orders REACT_APP_PRODUCTS_URL=/service/products
กด CTRL+O กด ENTER แล้วกด CTRL+X เพื่อบันทึกไฟล์ในโปรแกรมแก้ไขนาโน
คุณสามารถทดสอบ Microservice ใหม่ได้โดยไปที่ URL ที่คุณเพิ่งตั้งค่าในไฟล์นี้ หน้าเว็บควรส่งคืนการตอบกลับ JSON จาก Orders Microservice ของเรา
ถัดไป เราจะต้องสร้างฟรอนท์เอนด์แบบโมโนลิธใหม่และทำซ้ำกระบวนการบิลด์เพื่อสร้างคอนเทนเนอร์สำหรับโมโนลิธและทำให้คลัสเตอร์ GKE ใช้งานได้อีกครั้ง เรียกใช้คำสั่งต่อไปนี้โดยดำเนินการตามขั้นตอนเหล่านี้
สร้างไฟล์การกำหนดค่าแบบโมโนลิธอีกครั้ง
npm run build:monolith
สร้างคอนเทนเนอร์ Docker ด้วย Google Cloud Build
cd ~/monolith-to-microservices/monolith
gcloud builds submit --tag gcr.io/${GOOGLE_CLOUD_PROJECT}/monolith:2.0.0 .
ทำให้คอนเทนเนอร์ใช้งานได้กับ GKE
kubectl set image deployment/monolith monolith=gcr.io/${GOOGLE_CLOUD_PROJECT}/monolith:2.0.0
คุณสามารถยืนยันว่าขณะนี้แอปพลิเคชันของคุณเข้าถึง Microservice ของคำสั่งซื้อใหม่ได้โดยไปที่แอปพลิเคชันโมโนลิธในเบราว์เซอร์ของคุณ และไปที่หน้าคำสั่งซื้อ รหัสคำสั่งซื้อทั้งหมดควรลงท้ายด้วยคำต่อท้าย -MICROSERVICE ดังที่แสดงด้านล่าง
7. ย้ายข้อมูลผลิตภัณฑ์ไปยัง Microservice
สร้าง Microservice สำหรับผลิตภัณฑ์ใหม่
เรายังสามารถแบ่งย่อยบริการของเราต่อไปได้ด้วยการย้ายบริการผลิตภัณฑ์ในครั้งถัดไป เราจะทำตามกระบวนการเดียวกับขั้นตอนก่อนหน้า เรียกใช้คำสั่งต่อไปนี้เพื่อสร้างคอนเทนเนอร์ Docker, ทำให้คอนเทนเนอร์ใช้งานได้และเปิดเผยคอนเทนเนอร์ผ่านบริการ Kubernetes
สร้างคอนเทนเนอร์ Docker ด้วย Google Cloud Build
cd ~/monolith-to-microservices/microservices/src/products
gcloud builds submit --tag gcr.io/${GOOGLE_CLOUD_PROJECT}/products:1.0.0 .
ทำให้คอนเทนเนอร์ใช้งานได้กับ GKE
kubectl create deployment products --image=gcr.io/${GOOGLE_CLOUD_PROJECT}/products:1.0.0
แสดงคอนเทนเนอร์ GKE
kubectl expose deployment products --type=LoadBalancer --port 80 --target-port 8082
ค้นหา IP สาธารณะของบริการผลิตภัณฑ์ในลักษณะเดียวกับที่ทำกับบริการคำสั่งซื้อด้วยคำสั่งต่อไปนี้
kubectl get service products
เอาต์พุต:
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE products 10.3.251.122 203.0.113.0 80:30877/TCP 3d
บันทึกที่อยู่ IP ไว้ใช้ในขั้นตอนถัดไปเมื่อเรากำหนดค่าโมโนลิธใหม่ให้ชี้ไปยังบริการย่อยของผลิตภัณฑ์ใหม่
กำหนดค่า Monolith ใหม่
ใช้ตัวแก้ไขนาโนเพื่อแทนที่ URL ในเครื่องด้วยที่อยู่ IP ของ Microservice สำหรับผลิตภัณฑ์ใหม่ของเรา
cd ~/monolith-to-microservices/react-app nano .env.monolith
เมื่อตัวแก้ไขเปิดขึ้น ไฟล์ของคุณควรมีลักษณะดังนี้
REACT_APP_ORDERS_URL=http://<ORDERS_IP_ADDRESS>/api/orders REACT_APP_PRODUCTS_URL=/service/products
แทนที่ REACT_APP_PRODUCTS_URL เป็นรูปแบบใหม่ขณะแทนที่ด้วยที่อยู่ IP ของ Product Microservice เพื่อให้ตรงกับด้านล่าง
REACT_APP_ORDERS_URL=http://<ORDERS_IP_ADDRESS>/api/orders REACT_APP_PRODUCTS_URL=http://<PRODUCTS_IP_ADDRESS>/api/products
กด CTRL+O กด ENTER แล้วกด CTRL+X เพื่อบันทึกไฟล์ในโปรแกรมแก้ไขนาโน
คุณสามารถทดสอบ Microservice ใหม่ได้โดยไปที่ URL ที่คุณเพิ่งตั้งค่าในไฟล์นี้ หน้าเว็บควรส่งคืนการตอบกลับ JSON จาก Microservice ของผลิตภัณฑ์
ถัดไป เราจะต้องสร้างฟรอนท์เอนด์แบบโมโนลิธใหม่และทำซ้ำกระบวนการบิลด์เพื่อสร้างคอนเทนเนอร์สำหรับโมโนลิธและทำให้คลัสเตอร์ GKE ใช้งานได้อีกครั้ง เรียกใช้คำสั่งต่อไปนี้โดยดำเนินการตามขั้นตอนเหล่านี้
สร้างไฟล์การกำหนดค่าแบบโมโนลิธอีกครั้ง
npm run build:monolith
สร้างคอนเทนเนอร์ Docker ด้วย Google Cloud Build
cd ~/monolith-to-microservices/monolith
gcloud builds submit --tag gcr.io/${GOOGLE_CLOUD_PROJECT}/monolith:3.0.0 .
ทำให้คอนเทนเนอร์ใช้งานได้กับ GKE
kubectl set image deployment/monolith monolith=gcr.io/${GOOGLE_CLOUD_PROJECT}/monolith:3.0.0
คุณสามารถยืนยันว่าขณะนี้แอปพลิเคชันของคุณเข้าถึง Microservice ของผลิตภัณฑ์ใหม่ได้โดยไปที่แอปพลิเคชัน Monolith ในเบราว์เซอร์และไปที่หน้าผลิตภัณฑ์ ชื่อผลิตภัณฑ์ทั้งหมดควรขึ้นต้นด้วย MS- ดังที่แสดงด้านล่าง
8. ย้ายข้อมูลฟรอนท์เอนด์ไปยัง Microservice
ขั้นตอนสุดท้ายในกระบวนการย้ายข้อมูลคือการย้ายโค้ดฟรอนท์เอนด์ไปยัง Microservice และปิดโมโนลิธ หลังจากขั้นตอนนี้เสร็จเรียบร้อยแล้ว เราจะย้ายโมโนลิธของเราไปยังสถาปัตยกรรม Microservice ได้สำเร็จ
สร้าง Microservice ฟรอนท์เอนด์ใหม่
ลองทำตามขั้นตอนเดียวกับ 2 ขั้นตอนสุดท้ายเพื่อสร้าง Microservice ฟรอนท์เอนด์ใหม่
ก่อนหน้านี้ตอนที่สร้างโมโนลิ่มใหม่ เราอัปเดตการกำหนดค่าให้ชี้ไปยังโมโนลิธของเรา แต่ตอนนี้เราต้องใช้การกำหนดค่าเดียวกันสำหรับ Microservice ฟรอนท์เอนด์ เรียกใช้คำสั่งต่อไปนี้เพื่อคัดลอกไฟล์การกำหนดค่า URL ของ microservices ไปยังโค้ดเบสของ Frontend Microservice
cd ~/monolith-to-microservices/react-app cp .env.monolith .env npm run build
เมื่อเสร็จเรียบร้อยแล้ว เราจะดำเนินการตามขั้นตอนเดียวกับขั้นตอนก่อนหน้านี้ เรียกใช้คำสั่งต่อไปนี้เพื่อสร้างคอนเทนเนอร์ Docker, ทำให้คอนเทนเนอร์ใช้งานได้และเปิดเผยคอนเทนเนอร์ผ่านบริการ Kubernetes
สร้างคอนเทนเนอร์ Docker ด้วย Google Cloud Build
cd ~/monolith-to-microservices/microservices/src/frontend
gcloud builds submit --tag gcr.io/${GOOGLE_CLOUD_PROJECT}/frontend:1.0.0 .
ทำให้คอนเทนเนอร์ใช้งานได้กับ GKE
kubectl create deployment frontend --image=gcr.io/${GOOGLE_CLOUD_PROJECT}/frontend:1.0.0
แสดงคอนเทนเนอร์ GKE
kubectl expose deployment frontend --type=LoadBalancer --port 80 --target-port 8080
ลบ The Monolith
เมื่อบริการทั้งหมดของเราทำงานเป็น Microservice เราสามารถลบแอปพลิเคชัน Monolith ของเราได้ โปรดทราบว่าในการย้ายข้อมูลจริง การดำเนินการนี้จะส่งผลให้เกิดการเปลี่ยนแปลง DNS ฯลฯ ด้วยเพื่อให้ชื่อโดเมนที่มีอยู่ของเราชี้ไปที่ Microservice ฟรอนท์เอนด์ใหม่สำหรับแอปพลิเคชันของเรา เรียกใช้คำสั่งต่อไปนี้เพื่อลบโมโนลิธ
kubectl delete deployment monolith kubectl delete service monolith
ทดสอบงานของคุณ
เพื่อยืนยันว่าทุกอย่างใช้งานได้ ที่อยู่ IP เก่าจากบริการ Monolith จะไม่ทำงาน และที่อยู่ IP ใหม่จากบริการฟรอนท์เอนด์ควรโฮสต์แอปพลิเคชันใหม่ หากต้องการดูรายการของบริการและที่อยู่ IP ทั้งหมด ให้ใช้คำสั่งต่อไปนี้
kubectl get services
ผลลัพธ์ของคุณควรมีลักษณะคล้ายกับด้านล่างนี้
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE frontend LoadBalancer 10.39.246.135 35.227.21.154 80:32663/TCP 12m kubernetes ClusterIP 10.39.240.1 <none> 443/TCP 18d orders LoadBalancer 10.39.243.42 35.243.173.255 80:32714/TCP 31m products LoadBalancer 10.39.250.16 35.243.180.23 80:32335/TCP 21m
เมื่อคุณระบุที่อยู่ IP ภายนอกสำหรับ Frontend Microservice แล้ว ให้คัดลอกที่อยู่ IP เปิดเบราว์เซอร์และไปที่ URL นี้ (เช่น http://203.0.113.0) เพื่อตรวจสอบว่าระบบเข้าถึงฟรอนท์เอนด์ได้หรือไม่ เว็บไซต์ของคุณควรจะมีลักษณะเหมือนเดิมก่อนที่เราจะเจาะโมโนลิ่มให้กลายเป็น Microservice
9. ล้างข้อมูล
เมื่อพร้อมแล้ว วิธีที่ง่ายที่สุดในการล้างกิจกรรมทั้งหมดที่ทำคือการลบโปรเจ็กต์ การลบโปรเจ็กต์จะลบทรัพยากรทั้งหมดที่สร้างขึ้นภายใน Codelab นี้เพื่อให้ไม่มีการเรียกเก็บเงินซ้ำที่ไม่คาดคิดเกิดขึ้น ดำเนินการต่อไปนี้ภายใน Cloud Shell โดยที่ PROJECT_ID คือรหัสโปรเจ็กต์แบบเต็ม ไม่ใช่เฉพาะชื่อโปรเจ็กต์
gcloud projects delete [PROJECT_ID]
ยืนยันการลบโดยป้อน "Y" เมื่อมีข้อความแจ้ง
10. ยินดีด้วย
คุณแจกแจงแอปพลิเคชันโมโนลิธเป็น Microservice และทำให้ใช้งานได้ใน Google Kubernetes Engine เรียบร้อยแล้ว
ขั้นตอนถัดไป
ดู Codelab ต่อไปนี้เพื่อดูข้อมูลเพิ่มเติมเกี่ยวกับ Kubernetes
- ทำให้ใช้งานได้ ปรับขนาด และอัปเดตเว็บไซต์บน Google Kubernetes Engine
- สร้างบ็อต Slack ด้วย Node.js บน Kubernetes
- การส่งมอบอย่างต่อเนื่องไปยัง Kubernetes โดยใช้ Spinnaker
- ทำให้แอปพลิเคชัน Java ใช้งานได้กับ Kubernetes บน Google Kubernetes Engine
แหล่งข้อมูลเพิ่มเติม
- Docker - https://docs.docker.com/
- Kubernetes - https://kubernetes.io/docs/home/
- Google Kubernetes Engine (GKE) - https://cloud.google.com/kubernetes-engine/docs/
- Google Cloud Build - https://cloud.google.com/cloud-build/docs/
- Google Container Registry - https://cloud.google.com/container-registry/docs/
- การย้ายข้อมูลโมโนลิธไปยัง Microservice - https://cloud.google.com/solutions/migrating-a-monolithic-app-to-microservices-gke