1. บทนำ
เหตุใดจึงควรย้ายข้อมูลจากแอปพลิเคชันแบบโมโนลิธไปยังสถาปัตยกรรม Microservice การแบ่งแอปพลิเคชันออกเป็น Microservice มีข้อดีดังนี้ ซึ่งส่วนใหญ่เกิดจากข้อเท็จจริงที่ว่า Microservice มีการเชื่อมต่อแบบหลวม
- คุณทดสอบและติดตั้งใช้งาน Microservice ได้อย่างอิสระ ยิ่งหน่วยการติดตั้งใช้งานมีขนาดเล็กเท่าใด การติดตั้งใช้งานก็จะยิ่งง่ายขึ้นเท่านั้น
- คุณนำแบนเนอร์ดังกล่าวไปใช้ได้ในภาษาและเฟรมเวิร์กต่างๆ คุณสามารถเลือกเทคโนโลยีที่ดีที่สุดสำหรับ Use Case ที่เฉพาะเจาะจงของแต่ละไมโครเซอร์วิสได้อย่างอิสระ
- โดยทีมต่างๆ จะจัดการได้ ขอบเขตระหว่าง Microservice ทำให้การมอบหมายทีมให้ดูแล Microservice อย่างน้อย 1 รายการง่ายขึ้น
- การเปลี่ยนไปใช้ Microservice จะช่วยลดการพึ่งพากันระหว่างทีม แต่ละทีมต้องดูแลเฉพาะ API ของไมโครเซอร์วิสที่ทีมใช้เท่านั้น ทีมไม่จำเป็นต้องคิดถึงวิธีติดตั้งใช้งานไมโครเซอร์วิสเหล่านั้น รอบการเผยแพร่ และอื่นๆ
- คุณออกแบบเพื่อรองรับความล้มเหลวได้ง่ายขึ้น การกำหนดขอบเขตที่ชัดเจนระหว่างบริการต่างๆ จะช่วยให้คุณระบุได้ง่ายขึ้นว่าจะต้องทำอย่างไรหากบริการใดบริการหนึ่งหยุดทำงาน
ข้อเสียบางประการเมื่อเทียบกับ Monolith มีดังนี้
- เนื่องจากแอปที่ใช้ไมโครเซอร์วิสเป็นเครือข่ายของบริการต่างๆ ที่มักโต้ตอบกันในลักษณะที่ไม่ชัดเจน ความซับซ้อนโดยรวมของระบบจึงมีแนวโน้มที่จะเพิ่มขึ้น
- Microservice สื่อสารผ่านเครือข่าย ซึ่งแตกต่างจากส่วนภายในของโมโนลิธ ในบางกรณี การดำเนินการนี้อาจถือเป็นข้อกังวลด้านความปลอดภัย Istio แก้ปัญหานี้ด้วยการเข้ารหัสการรับส่งข้อมูลระหว่างไมโครเซอร์วิสโดยอัตโนมัติ
- การบรรลุประสิทธิภาพในระดับเดียวกับแนวทางแบบ Monolithic อาจเป็นเรื่องยากเนื่องจากเวลาในการตอบสนองระหว่างบริการ
- ลักษณะการทำงานของระบบไม่ได้เกิดจากบริการเดียว แต่เกิดจากบริการหลายอย่างและการโต้ตอบของบริการเหล่านั้น ด้วยเหตุนี้ การทำความเข้าใจลักษณะการทำงานของระบบในเวอร์ชันที่ใช้งานจริง (ความสามารถในการสังเกตการณ์) จึงยากขึ้น Istio เป็นโซลูชันสำหรับปัญหานี้เช่นกัน
ใน Lab นี้ เราจะเรียกใช้ Microservice ใน Google Kubernetes Engine (GKE) Kubernetes เป็นแพลตฟอร์มสำหรับจัดการ โฮสต์ ปรับขนาด และติดตั้งใช้งานคอนเทนเนอร์ คอนเทนเนอร์เป็นวิธีที่พกพาสะดวกในการแพ็กเกจและเรียกใช้โค้ด ซึ่งเหมาะกับรูปแบบของ Microservice ที่แต่ละ Microservice สามารถทำงานในคอนเทนเนอร์ของตัวเองได้
สำหรับแล็บนี้ เราจะทำให้แอปพลิเคชัน Monolithic ที่มีอยู่ใช้งานได้ในคลัสเตอร์ Google Kubernetes Engine จากนั้นจะแยกแอปพลิเคชันออกเป็น Microservice
แผนภาพสถาปัตยกรรมของ Microservice
เราจะเริ่มด้วยการแบ่งโมโนลิธออกเป็น 3 Microservice ทีละรายการ ซึ่งประกอบด้วย Orders, Products และ Frontend เราสร้างอิมเมจ Docker สำหรับแต่ละไมโครเซอร์วิสโดยใช้ Cloud Build ซึ่งเราทริกเกอร์จากภายใน Cloud Shell จากนั้นเราจะทำให้ Microservice ใช้งานได้และแสดง Microservice บน Google Kubernetes Engine (GKE) ด้วยประเภทบริการ LoadBalancer ของ Kubernetes เราจะดำเนินการนี้กับแต่ละบริการพร้อมกับปรับโครงสร้างบริการเหล่านั้นออกจาก Monolith ในระหว่างกระบวนการนี้ เราจะเรียกใช้ทั้ง Monolith และ Microservice จนกว่าจะถึงจุดสิ้นสุดเมื่อเราลบ Monolith ได้
สิ่งที่คุณจะได้เรียนรู้
- วิธีแยกโมโนลิธออกเป็น 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 ทั้งหมด (ชื่อด้านบนมีผู้ใช้แล้วและจะใช้ไม่ได้ ขออภัย) ซึ่งจะเรียกว่า PROJECT_ID ในภายหลังใน Codelab นี้
จากนั้น คุณจะต้องเปิดใช้การเรียกเก็บเงินใน 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 ซึ่งช่วยเพิ่มประสิทธิภาพเครือข่ายและการตรวจสอบสิทธิ์ได้อย่างมาก ซึ่งหมายความว่าคุณจะต้องมีเพียงเบราว์เซอร์เท่านั้นสำหรับโค้ดแล็บนี้ (ใช่แล้ว ใช้ได้ใน 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. โคลนที่เก็บซอร์ส
เราใช้แอปพลิเคชันแบบ Monolithic ที่มีอยู่ของเว็บไซต์อีคอมเมิร์ซสมมติ โดยมีหน้าต้อนรับ หน้าผลิตภัณฑ์ และหน้าประวัติการสั่งซื้อที่เรียบง่าย เราเพียงแค่ต้องโคลนแหล่งที่มาจากที่เก็บ Git เพื่อให้เรามุ่งเน้นที่การแบ่งออกเป็น Microservice และการติดตั้งใช้งานใน Google Kubernetes Engine (GKE) ได้
เรียกใช้คำสั่งต่อไปนี้เพื่อโคลนที่เก็บ Git ไปยังอินสแตนซ์ Cloud Shell และเปลี่ยนไปยังไดเรกทอรีที่เหมาะสม นอกจากนี้ เราจะติดตั้งการอ้างอิง NodeJS เพื่อให้ทดสอบ Monolith ก่อนที่จะทำการติดตั้งใช้งานได้ สคริปต์นี้อาจใช้เวลา 2-3 นาทีในการเรียกใช้
cd ~ git clone https://github.com/googlecodelabs/monolith-to-microservices.git cd ~/monolith-to-microservices ./setup.sh
การดำเนินการนี้จะโคลนที่เก็บ Github ของเรา เปลี่ยนเป็นไดเรกทอรี และติดตั้งการอ้างอิงที่จำเป็นต่อการเรียกใช้แอปพลิเคชันในเครื่อง สคริปต์นี้อาจใช้เวลา 2-3 นาทีในการเรียกใช้
4. สร้างคลัสเตอร์ GKE
ตอนนี้คุณมีสภาพแวดล้อมการพัฒนาที่ใช้งานได้แล้ว เราจึงต้องมีคลัสเตอร์ Kubernetes เพื่อนำ Monolith และในที่สุดก็คือ Microservices ไปใช้งาน ก่อนที่จะสร้างคลัสเตอร์ได้ เราต้องตรวจสอบว่าได้เปิดใช้ API ที่เหมาะสมแล้ว เรียกใช้คำสั่งต่อไปนี้เพื่อเปิดใช้ Containers API เพื่อให้เราใช้ Google Kubernetes Engine ได้
gcloud services enable container.googleapis.com
ตอนนี้เราก็พร้อมที่จะสร้างคลัสเตอร์แล้ว เรียกใช้คำสั่งด้านล่างเพื่อสร้างคลัสเตอร์ GKE ชื่อ fancy-cluster ที่มีโหนด 3 โหนด
gcloud container clusters create fancy-cluster --num-nodes 3
การสร้างคลัสเตอร์อาจใช้เวลาหลายนาที เมื่อคำสั่งเสร็จสมบูรณ์แล้ว ให้เรียกใช้คำสั่งต่อไปนี้และดูอินสแตนซ์ VM ของ Worker ทั้ง 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. ทำให้โมโนลิธที่มีอยู่ใช้งานได้
เนื่องจากจุดมุ่งหมายของ Lab นี้คือการแนะนำวิธีการแยกโมโนลิธออกเป็น Microservice เราจึงต้องทำให้แอปพลิเคชันโมโนลิธทำงานได้ เรียกใช้สคริปต์ต่อไปนี้เพื่อทำให้แอปพลิเคชันแบบ Monolith ใช้งานได้ในคลัสเตอร์ GKE ของเราเพื่อวัตถุประสงค์ของแล็บนี้
cd ~/monolith-to-microservices ./deploy-monolith.sh
การเข้าถึงโมโนลิธ
หากต้องการค้นหาที่อยู่ 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 ภายนอกสำหรับ Monolith แล้ว ให้คัดลอกที่อยู่ IP ชี้เบราว์เซอร์ไปที่ URL นี้ (เช่น http://203.0.113.0) เพื่อตรวจสอบว่าเข้าถึง Monolith ได้หรือไม่
คุณควรเห็นหน้าต้อนรับสำหรับเว็บไซต์แบบ Monolithic เหมือนกับรูปภาพด้านบน หน้ายินดีต้อนรับเป็นหน้าแบบคงที่ซึ่งจะแสดงโดยไมโครเซอร์วิสส่วนหน้าในภายหลัง ตอนนี้คุณมี Monolith ที่ทำงานบน Kubernetes อย่างเต็มรูปแบบแล้ว
6. ย้ายข้อมูลคำสั่งซื้อไปยัง Microservice
ตอนนี้เรามีเว็บไซต์แบบ Monolith ที่ทำงานบน GKE แล้ว จึงเริ่มแยกแต่ละบริการออกเป็น Microservice ได้ โดยปกติแล้ว การวางแผนควรพิจารณาว่าบริการใดที่ควรแบ่งออกเป็นส่วนย่อยๆ โดยมักจะพิจารณาจากส่วนที่เฉพาะเจาะจงของแอปพลิเคชัน เช่น โดเมนธุรกิจ เพื่อวัตถุประสงค์ในการสาธิต เราได้สร้างตัวอย่างที่ไม่ซับซ้อนและแยกแต่ละบริการตามโดเมนธุรกิจ ได้แก่ คำสั่งซื้อ ผลิตภัณฑ์ และส่วนหน้า เราได้ย้ายข้อมูลโค้ดแล้ว และจะมุ่งเน้นที่การสร้างและติดตั้งใช้งานบริการใน Google Kubernetes Engine (GKE)
สร้างไมโครเซอร์วิสคำสั่งซื้อใหม่
บริการแรกที่เราจะแยกออกมาคือบริการคำสั่งซื้อ เราจะใช้โค้ดเบสแยกต่างหากที่ได้รับและสร้างคอนเทนเนอร์ Docker แยกต่างหากสำหรับบริการนี้
สร้างคอนเทนเนอร์ Docker ด้วย Google Cloud Build
เนื่องจากเราได้ย้ายข้อมูลโค้ดเบสให้คุณแล้ว ขั้นตอนแรกของเราคือการสร้างคอนเทนเนอร์ Docker ของบริการ Order โดยใช้ Google Cloud Build
โดยปกติแล้ว คุณจะต้องใช้แนวทาง 2 ขั้นตอน ซึ่งเกี่ยวข้องกับการสร้างคอนเทนเนอร์ Docker และการพุชไปยังรีจิสทรีเพื่อจัดเก็บอิมเมจสำหรับ GKE เพื่อดึงข้อมูลจากรีจิสทรี แต่เราสามารถทำให้ชีวิตง่ายขึ้นได้ โดยใช้ Google Cloud Build เพื่อสร้างคอนเทนเนอร์ Docker และใส่อิมเมจใน Google Cloud Container Registry ด้วยคำสั่งเดียว ซึ่งช่วยให้เราออกคำสั่งเดียวเพื่อสร้างและย้ายอิมเมจไปยัง Container Registry ได้ หากต้องการดูขั้นตอนการสร้างไฟล์ Docker และการพุชด้วยตนเอง ให้ไปที่นี่
Google Cloud Build จะบีบอัดไฟล์จากไดเรกทอรีและย้ายไปยัง Bucket ของ Google Cloud Storage จากนั้นกระบวนการบิลด์จะนำไฟล์ทั้งหมดจากที่เก็บข้อมูลและใช้ Dockerfile เพื่อเรียกใช้กระบวนการบิลด์ Docker เนื่องจากเราได้ระบุแฟล็ก --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 Console คลิกปุ่มเมนูที่ด้านซ้ายบน แล้วเลื่อนลงไปที่เครื่องมือ → Cloud Build แล้วคลิกประวัติ ในส่วนนี้ คุณจะเห็นรายการบิลด์ก่อนหน้าทั้งหมด ซึ่งควรมีเพียง 1 รายการที่คุณเพิ่งสร้าง
หากคลิกรหัสบิลด์ คุณจะเห็นรายละเอียดทั้งหมดของบิลด์นั้น รวมถึงเอาต์พุตบันทึก
จากหน้ารายละเอียดการสร้าง คุณจะดูอิมเมจคอนเทนเนอร์ที่สร้างขึ้นได้โดยคลิกชื่ออิมเมจในส่วนข้อมูลการสร้าง
ทำให้คอนเทนเนอร์ใช้งานได้ใน GKE
ตอนนี้เราได้ใส่คอนเทนเนอร์เว็บไซต์และพุชคอนเทนเนอร์ไปยัง Google Container Registry แล้ว ก็ถึงเวลาที่จะทําให้ใช้งานได้ใน Kubernetes
Kubernetes แสดงแอปพลิเคชันเป็น Pod ซึ่งเป็นหน่วยที่แสดงคอนเทนเนอร์ (หรือกลุ่มคอนเทนเนอร์ที่เชื่อมโยงกันอย่างใกล้ชิด) Pod เป็นหน่วยที่เล็กที่สุดที่สามารถทำให้ใช้งานได้ใน Kubernetes ในบทแนะนำนี้ พ็อดแต่ละรายการจะมีเฉพาะคอนเทนเนอร์ของไมโครเซอร์วิสเท่านั้น
หากต้องการติดตั้งใช้งานและจัดการแอปพลิเคชันในคลัสเตอร์ 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 ภายนอก คุณต้องเปิดเผยแอปพลิเคชันต่อการเข้าชมจากอินเทอร์เน็ตอย่างชัดเจนผ่านทรัพยากร Service บริการจะมอบเครือข่ายและการสนับสนุน IP แก่พ็อดของแอปพลิเคชัน GKE จะสร้าง IP ภายนอกและตัวจัดสรรภาระงาน ( ขึ้นอยู่กับการเรียกเก็บเงิน) สำหรับแอปพลิเคชันของคุณ
เมื่อเราทำให้บริการคำสั่งซื้อใช้งานได้ เราได้เปิดเผยบริการดังกล่าวบนพอร์ต 8081 ภายในผ่านการติดตั้งใช้งาน Kubernetes หากต้องการแสดงบริการนี้ภายนอก เราต้องสร้างบริการ Kubernetes ประเภท LoadBalancer เพื่อกำหนดเส้นทางการรับส่งข้อมูลจากพอร์ต 80 ภายนอกไปยังพอร์ต 8081 ภายในสำหรับบริการ Orders เรียกใช้คำสั่งต่อไปนี้เพื่อแสดงเว็บไซต์ต่ออินเทอร์เน็ต
kubectl expose deployment orders --type=LoadBalancer --port 80 --target-port 8081
การเข้าถึงบริการ
GKE จะกำหนดที่อยู่ IP ภายนอกให้กับทรัพยากร Service ไม่ใช่ Deployment หากต้องการดู 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 ให้ชี้ไปยังบริการคำสั่งซื้อใหม่
กำหนดค่าโมโนลิธใหม่
เนื่องจากเรานำบริการคำสั่งซื้อออกจากโมโนลิธแล้ว เราจึงต้องแก้ไขโมโนลิธให้ชี้ไปยัง Microservice คำสั่งซื้อภายนอกใหม่
เมื่อแยกส่วนโมโนลิธ เราจะนำโค้ดบางส่วนออกจากโค้ดเบสเดียวไปยังโค้ดเบสหลายรายการและทำให้ใช้งานได้แยกกัน เนื่องจากไมโครเซอร์วิสทำงานบนเซิร์ฟเวอร์อื่น เราจึงอ้างอิง URL ของบริการเป็นเส้นทางแบบสัมบูรณ์ไม่ได้อีกต่อไป แต่ต้องกำหนดเส้นทางไปยังที่อยู่เซิร์ฟเวอร์ใหม่ของไมโครเซอร์วิสคำสั่งซื้อ โปรดทราบว่าการดำเนินการนี้จะต้องใช้เวลาหยุดทำงานของบริการ Monolith เพื่ออัปเดต URL สำหรับแต่ละบริการที่แยกออกมา คุณควรคำนึงถึงเรื่องนี้เมื่อวางแผนที่จะย้าย Microservice และ Monolith ไปยังเวอร์ชันที่ใช้งานจริงในระหว่างกระบวนการย้ายข้อมูล Microservice
เราต้องอัปเดตไฟล์การกำหนดค่าใน Monolith เพื่อชี้ไปยังที่อยู่ IP ของไมโครเซอร์วิสคำสั่งซื้อใหม่ ใช้โปรแกรมแก้ไข nano เพื่อแทนที่ URL ในเครื่องด้วยที่อยู่ IP ของไมโครเซอร์วิสคำสั่งซื้อใหม่ของเรา เรียกใช้คำสั่งต่อไปนี้เพื่อแก้ไข
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 ของไมโครเซอร์วิสคำสั่งซื้อเพื่อให้ตรงกับที่อยู่ด้านล่าง
REACT_APP_ORDERS_URL=http://<ORDERS_IP_ADDRESS>/api/orders REACT_APP_PRODUCTS_URL=/service/products
กด CTRL+O กด ENTER แล้วกด CTRL+X เพื่อบันทึกไฟล์ในโปรแกรมแก้ไข nano
คุณทดสอบไมโครเซอร์วิสใหม่ได้โดยไปที่ URL ที่เพิ่งตั้งค่าในไฟล์นี้ หน้าเว็บควรแสดงผลการตอบกลับเป็น JSON จากไมโครเซอร์วิสคำสั่งซื้อของเรา
จากนั้นเราจะต้องสร้างส่วนหน้าแบบ Monolith ใหม่และทำซ้ำกระบวนการสร้างเพื่อสร้างคอนเทนเนอร์สำหรับ Monolith และนำไปใช้ซ้ำในคลัสเตอร์ GKE เรียกใช้คำสั่งต่อไปนี้เพื่อทำตามขั้นตอนเหล่านี้ให้เสร็จสมบูรณ์
สร้างไฟล์การกำหนดค่า Monolith อีกครั้ง
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
คุณสามารถยืนยันว่าแอปพลิเคชันของคุณใช้ไมโครเซอร์วิสคำสั่งซื้อใหม่แล้วได้โดยไปที่แอปพลิเคชัน Monolith ในเบราว์เซอร์และไปที่หน้าคำสั่งซื้อ รหัสคำสั่งซื้อทั้งหมดควรลงท้ายด้วยคำต่อท้าย -MICROSERVICE ดังที่แสดงด้านล่าง
7. ย้ายข้อมูลผลิตภัณฑ์ไปยัง 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 ใหม่ให้ชี้ไปยัง Microservice ของผลิตภัณฑ์ใหม่
กำหนดค่าโมโนลิธใหม่
ใช้โปรแกรมแก้ไข nano เพื่อแทนที่ URL ในเครื่องด้วยที่อยู่ IP ของไมโครเซอร์วิสผลิตภัณฑ์ใหม่ของเรา
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 ของไมโครเซอร์วิสผลิตภัณฑ์เพื่อให้ตรงกับด้านล่าง
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 เพื่อบันทึกไฟล์ในโปรแกรมแก้ไข nano
คุณทดสอบไมโครเซอร์วิสใหม่ได้โดยไปที่ URL ที่เพิ่งตั้งค่าในไฟล์นี้ หน้าเว็บควรแสดงผลการตอบกลับเป็น JSON จาก Microservice ของผลิตภัณฑ์
จากนั้นเราจะต้องสร้างส่วนหน้าแบบ Monolith ใหม่และทำซ้ำกระบวนการสร้างเพื่อสร้างคอนเทนเนอร์สำหรับ Monolith และนำไปใช้ซ้ำในคลัสเตอร์ GKE เรียกใช้คำสั่งต่อไปนี้เพื่อทำตามขั้นตอนเหล่านี้ให้เสร็จสมบูรณ์
สร้างไฟล์การกำหนดค่า Monolith อีกครั้ง
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
คุณสามารถยืนยันว่าแอปพลิเคชันของคุณกำลังเข้าถึงไมโครเซอร์วิสผลิตภัณฑ์ใหม่ได้โดยไปที่แอปพลิเคชัน Monolith ในเบราว์เซอร์แล้วไปที่หน้าผลิตภัณฑ์ ชื่อผลิตภัณฑ์ทั้งหมดควรมีคำนำหน้าเป็น MS- ดังที่แสดงด้านล่าง
8. ย้ายข้อมูลส่วนหน้าไปยัง Microservice
ขั้นตอนสุดท้ายในกระบวนการย้ายข้อมูลคือการย้ายโค้ดส่วนหน้าไปยังไมโครเซอร์วิสและปิดโมโนลิธ หลังจากทำตามขั้นตอนนี้เสร็จแล้ว เราจะย้ายข้อมูล Monolith ไปยังสถาปัตยกรรมแบบไมโครเซอร์วิสได้สำเร็จ
สร้าง Microservice ส่วนหน้าใหม่
มาทำตามขั้นตอนเดียวกันกับ 2 ขั้นตอนสุดท้ายเพื่อสร้างไมโครเซอร์วิสส่วนหน้าใหม่กัน
ก่อนหน้านี้เมื่อเราสร้าง Monolith ใหม่ เราได้อัปเดตการกำหนดค่าให้ชี้ไปยัง Monolith แต่ตอนนี้เราต้องใช้การกำหนดค่าเดียวกันสำหรับ Microservice ของส่วนหน้า เรียกใช้คำสั่งต่อไปนี้เพื่อคัดลอกไฟล์กำหนดค่า URL ของ Microservice ไปยังโค้ดเบสของ 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
ลบโมโนลิธ
ตอนนี้บริการทั้งหมดของเราทำงานเป็น Microservice แล้ว เราจึงลบแอปพลิเคชัน Monolith ได้ โปรดทราบว่าในการย้ายข้อมูลจริง การดำเนินการนี้จะเกี่ยวข้องกับการเปลี่ยนแปลง DNS และอื่นๆ ด้วย เพื่อให้ชื่อโดเมนที่มีอยู่ชี้ไปยังไมโครเซอร์วิสส่วนหน้าใหม่สำหรับแอปพลิเคชันของเรา เรียกใช้คำสั่งต่อไปนี้เพื่อลบ Monolith
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 ภายนอกสำหรับไมโครเซอร์วิสส่วนหน้าแล้ว ให้คัดลอกที่อยู่ IP ชี้เบราว์เซอร์ไปที่ URL นี้ (เช่น http://203.0.113.0) เพื่อตรวจสอบว่าเข้าถึงส่วนหน้าได้หรือไม่ เว็บไซต์ของคุณควรจะเหมือนกับก่อนที่เราจะแยก Monolith ออกเป็น Microservice
9. ล้างข้อมูล
เมื่อพร้อมแล้ว วิธีที่ง่ายที่สุดในการล้างกิจกรรมทั้งหมดที่ดำเนินการคือการลบโปรเจ็กต์ การลบโปรเจ็กต์จะเป็นการลบทรัพยากรทั้งหมดที่สร้างขึ้นภายใน Codelab นี้เพื่อให้มั่นใจว่าจะไม่มีการเรียกเก็บเงินที่เกิดซ้ำโดยไม่คาดคิด เรียกใช้คำสั่งต่อไปนี้ภายใน Cloud Shell โดยที่ PROJECT_ID คือรหัสโปรเจ็กต์แบบเต็ม ไม่ใช่แค่ชื่อโปรเจ็กต์
gcloud projects delete [PROJECT_ID]
ยืนยันการลบโดยป้อน "Y" เมื่อได้รับข้อความแจ้ง
10. ยินดีด้วย
คุณแยกแอปพลิเคชันแบบ Monolithic ออกเป็น Microservice และทำให้ใช้งานได้ใน Google Kubernetes Engine เรียบร้อยแล้ว
ขั้นตอนถัดไป
ดูข้อมูลเพิ่มเติมเกี่ยวกับ Kubernetes ได้จาก Codelab ต่อไปนี้
- ทําให้เว็บไซต์ใช้งานได้ ปรับขนาด และอัปเดตเว็บไซต์ใน Google Kubernetes Engine
- สร้าง Slack Bot ด้วย 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