การติดตั้งใช้งานอย่างต่อเนื่องกับ Google Kubernetes Engine (GKE) ด้วย Cloud Build

1. ภาพรวม

ในห้องทดลองนี้ คุณจะได้เรียนรู้วิธีตั้งค่าไปป์ไลน์การนำส่งอย่างต่อเนื่องสำหรับ GKE ด้วย Cloud Build ห้องทดลองนี้ไฮไลต์วิธีทริกเกอร์งาน Cloud Build สำหรับเหตุการณ์ Git ต่างๆ รวมถึงรูปแบบง่ายๆ สำหรับรุ่น Canary อัตโนมัติใน GKE

คุณต้องดำเนินการขั้นตอนต่อไปนี้

  • สร้างแอปพลิเคชัน GKE
  • ทำให้การทำให้ใช้งานได้สำหรับสาขา Git ทำงานโดยอัตโนมัติ
  • ทำให้การติดตั้งใช้งาน Git สำหรับสาขาหลักเป็นแบบอัตโนมัติ
  • ทำให้แท็ก Git ใช้งานได้โดยอัตโนมัติ

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

คุณต้องมีโปรเจ็กต์ Google Cloud สำหรับคู่มืออ้างอิงนี้ คุณจะสร้างโปรเจ็กต์ใหม่หรือเลือกโปรเจ็กต์ที่สร้างไว้แล้วก็ได้ ดังนี้

  1. เลือกหรือสร้างโปรเจ็กต์ Google Cloud

ไปที่หน้าตัวเลือกโปรเจ็กต์

  1. เปิดใช้การเรียกเก็บเงินสำหรับโปรเจ็กต์

เปิดใช้การเรียกเก็บเงิน

3. กำลังเตรียมสภาพแวดล้อมของคุณ

  1. สร้างตัวแปรสภาพแวดล้อมที่จะใช้ตลอดบทแนะนำนี้:
    export PROJECT_ID=$(gcloud config get-value project)
export PROJECT_NUMBER=$(gcloud projects describe $PROJECT_ID --format='value(projectNumber)')

export ZONE=us-central1-b
export CLUSTER=gke-progression-cluster
export APP_NAME=myapp
  2. เปิดใช้งาน API ต่อไปนี้:
    • เครื่องมือจัดการทรัพยากร
    • GKE
    • Cloud Source Repositories
    • Cloud Build
    • Container Registry
    gcloud services enable \
    cloudresourcemanager.googleapis.com \
    container.googleapis.com \
    sourcerepo.googleapis.com \
    cloudbuild.googleapis.com \
    containerregistry.googleapis.com \
    --async
  3. โคลนแหล่งที่มาตัวอย่างและเปลี่ยนเป็นไดเรกทอรีของ Lab:
    git clone https://github.com/GoogleCloudPlatform/software-delivery-workshop.git gke-progression

cd gke-progression/labs/gke-progression
rm -rf ../../.git
  4. แทนที่ค่าตัวยึดตำแหน่งในที่เก็บตัวอย่างด้วย PROJECT_ID ของคุณในขั้นตอนนี้ คุณจะสร้างอินสแตนซ์ของไฟล์การกำหนดค่าต่างๆ เฉพาะสำหรับสภาพแวดล้อมปัจจุบันของคุณ หากต้องการดูตัวอย่างเทมเพลตที่อัปเดต ให้เรียกใช้คำสั่งต่อไปนี้
    cat k8s/deployments/dev/frontend-dev.yaml.tmpl
    ดำเนินการแทนที่ตัวแปรโดยเรียกใช้คำสั่งติดตาม
    for template in $(find . -name '*.tmpl'); do envsubst '${PROJECT_ID} ${ZONE} ${CLUSTER} ${APP_NAME}' < ${template} > ${template%.*}; done
    หากต้องการดูตัวอย่างไฟล์หลังจากการแทนที่ ให้เรียกใช้คำสั่งต่อไปนี้
    cat k8s/deployments/dev/frontend-dev.yaml
  5. หากคุณไม่เคยใช้ Git ใน Cloud Shell มาก่อน ให้ตั้งค่า user.name และ user.email ที่ต้องการใช้ดังนี้
    git config --global user.email "YOUR_EMAIL_ADDRESS"
git config --global user.name "YOUR_USERNAME"
  6. จัดเก็บโค้ดจากที่เก็บตัวอย่างใน Cloud Source Repositories:
    gcloud source repos create gke-progression
git init
git config credential.helper gcloud.sh
git remote add gcp https://source.developers.google.com/p/$PROJECT_ID/r/gke-progression
git branch -m main
git add . && git commit -m "initial commit"
git push gcp main
  7. สร้างคลัสเตอร์ GKE
    gcloud container clusters create ${CLUSTER} \
    --project=${PROJECT_ID} \
    --zone=${ZONE}
  8. ให้สิทธิ์ Cloud Build กับคลัสเตอร์ของคุณ Cloud Build จะทำให้แอปพลิเคชันใช้งานได้ในคลัสเตอร์ GKE และจะต้องมีสิทธิ์เพื่อดำเนินการดังกล่าว
    gcloud projects add-iam-policy-binding ${PROJECT_ID} \
    --member=serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com \
    --role=roles/container.developer

สภาพแวดล้อมของคุณพร้อมใช้งานแล้ว

4. การสร้างแอปพลิเคชัน GKE

ในส่วนนี้ คุณจะได้สร้างและทำให้แอปพลิเคชันเวอร์ชันที่ใช้งานจริงช่วงแรกใช้งานได้ตลอดบทแนะนำนี้

  1. สร้างแอปพลิเคชันด้วย Cloud Build:
    gcloud builds submit --tag gcr.io/$PROJECT_ID/$APP_NAME:1.0.0 src/
  2. ทำให้ใช้งานได้ด้วยตนเองกับสภาพแวดล้อมของ Canary และเวอร์ชันที่ใช้งานจริง:สร้างการติดตั้งใช้งานและบริการเวอร์ชันที่ใช้งานจริงและ Canary โดยใช้คำสั่ง kubectl apply
    kubectl create ns production
kubectl apply -f k8s/deployments/prod -n production
kubectl apply -f k8s/deployments/canary -n production
kubectl apply -f k8s/services -n production
    บริการที่ทำให้ใช้งานได้ที่นี่จะกำหนดเส้นทางการรับส่งข้อมูลไปยังทั้งการทำให้ใช้งานได้ของ Canary และเวอร์ชันที่ใช้งานจริง
  3. ตรวจสอบจำนวนพ็อดที่กำลังทำงานอยู่ ยืนยันว่าคุณมีพ็อด 4 รายการที่กำลังทำงานสำหรับฟรอนท์เอนด์ โดยมี 3 พ็อดสำหรับการเข้าชมจริง และอีก 1 พ็อดสำหรับการเผยแพร่แบบ Canary ซึ่งหมายความว่าการเปลี่ยนแปลงรุ่น Canary จะส่งผลต่อผู้ใช้เพียง 1 ใน 4 (25%) เท่านั้น
    kubectl get pods -n production -l app=$APP_NAME -l role=frontend
  4. เรียกข้อมูลที่อยู่ IP ภายนอกสำหรับบริการที่ใช้งานจริง วันที่
    kubectl get service $APP_NAME -n production
    เมื่อตัวจัดสรรภาระงานส่งคืนที่อยู่ IP แล้ว ให้ไปยังขั้นตอนถัดไป
  5. จัดเก็บ IP ภายนอกไว้ใช้ในภายหลัง
    export PRODUCTION_IP=$(kubectl get -o jsonpath="{.status.loadBalancer.ingress[0].ip}"  --namespace=production services $APP_NAME)
  6. ตรวจสอบแอปพลิเคชัน ตรวจสอบเอาต์พุตเวอร์ชันของบริการ ซึ่งควรเป็น Hello World v1.0
    curl http://$PRODUCTION_IP

ยินดีด้วย คุณทำให้แอปตัวอย่างใช้งานได้แล้ว ถัดไป คุณจะตั้งค่าทริกเกอร์เพื่อให้การเปลี่ยนแปลงใช้งานได้อย่างต่อเนื่อง

5. การทำให้การทำให้ใช้งานได้โดยอัตโนมัติสำหรับสาขา Git

ในส่วนนี้ คุณจะตั้งค่าทริกเกอร์ที่จะเรียกใช้งาน Cloudbuild บนคอมมิตของ Branch อื่นที่ไม่ใช่ main ไฟล์ Cloud Build ที่ใช้ที่นี่จะสร้างเนมสเปซและการทำให้ใช้งานได้โดยอัตโนมัติสำหรับ Branch ที่มีอยู่หรือ Branch ใหม่ ซึ่งช่วยให้นักพัฒนาแอปสามารถดูตัวอย่างโค้ดได้ก่อนที่จะผสานรวมกับ Branch หลัก

  1. ตั้งค่าทริกเกอร์:คอมโพเนนต์หลักของทริกเกอร์นี้คือการใช้พารามิเตอร์ branchName เพื่อจับคู่ main และพารามิเตอร์ invertRegex ซึ่งตั้งค่าเป็น "จริง" และปรับเปลี่ยนรูปแบบ branchName ให้จับคู่กับอะไรก็ได้ที่ไม่ใช่ main โปรดดูบรรทัดต่อไปนี้ใน build/branch-trigger.json เพื่อเป็นข้อมูลอ้างอิง
      "branchName": "main",
  "invertRegex": true
    นอกจากนี้ 2-3 บรรทัดสุดท้ายของไฟล์ Cloud Build ที่ใช้กับทริกเกอร์นี้ ให้สร้างเนมสเปซที่ตั้งชื่อตาม Branch ที่ทริกเกอร์งาน จากนั้นทำให้แอปพลิเคชันและบริการใช้งานได้ภายในเนมสเปซใหม่ โปรดดูบรรทัดต่อไปนี้ใน build/branch-cloudbuild.yaml
      kubectl get ns ${BRANCH_NAME} || kubectl create ns ${BRANCH_NAME}
  kubectl apply --namespace ${BRANCH_NAME} --recursive -f k8s/deployments/dev
  kubectl apply --namespace ${BRANCH_NAME} --recursive -f k8s/services
    เพื่อเป็นข้อมูลอ้างอิง เมื่อเข้าใจกลไกที่ใช้งานอยู่แล้ว ให้สร้างทริกเกอร์ด้วยคำสั่ง gcloud ด้านล่าง
    gcloud beta builds triggers create cloud-source-repositories \
  --trigger-config build/branch-trigger.json
  2. หากต้องการตรวจสอบทริกเกอร์ ให้ไปที่หน้าทริกเกอร์ Cloud Build ในคอนโซลไปที่ทริกเกอร์
  3. สร้าง Branch ใหม่:
    git checkout -b new-feature-1
  4. แก้ไขโค้ดเพื่อระบุ v1.1 แก้ไข src/app.py และเปลี่ยนการตอบกลับจาก 1.0 เป็น 1.1
    @app.route('/')
def hello_world():
    return 'Hello World v1.1'
  5. คอมมิตการเปลี่ยนแปลงและพุชไปยังที่เก็บระยะไกล:
    git add . && git commit -m "updated" && git push gcp new-feature-1
  6. หากต้องการตรวจสอบบิลด์ที่กำลังดำเนินการ ให้ไปที่หน้าประวัติ Cloud Build ในคอนโซลไปที่บิลด์เมื่อบิลด์เสร็จสมบูรณ์ ให้ไปยังขั้นตอนถัดไป
  7. เรียกข้อมูลที่อยู่ IP ภายนอกสำหรับบริการสาขาที่ทำให้ใช้งานได้ใหม่ วันที่
    kubectl get service $APP_NAME -n new-feature-1
    เมื่อตัวจัดสรรภาระงานส่งคืนที่อยู่ IP แล้ว ให้ไปยังขั้นตอนถัดไป
  8. จัดเก็บ IP ภายนอกไว้ใช้ในภายหลัง
    export BRANCH_IP=$(kubectl get -o jsonpath="{.status.loadBalancer.ingress[0].ip}"  --namespace=new-feature-1 services $APP_NAME)
  9. ตรวจสอบแอปพลิเคชัน ตรวจสอบเอาต์พุตเวอร์ชันของบริการ ซึ่งควรเป็น Hello World v1.0
    curl http://$BRANCH_IP

6. การทำให้ใช้งานได้โดยอัตโนมัติสำหรับสาขาหลักของ Git

ก่อนที่โค้ดจะเผยแพร่สู่เวอร์ชันที่ใช้งานจริง เป็นเรื่องปกติที่จะเผยแพร่โค้ดไปยังส่วนย่อยของการเข้าชมที่เผยแพร่อยู่ขนาดเล็ก ก่อนที่จะย้ายการเข้าชมทั้งหมดไปยังฐานของโค้ดใหม่

ในส่วนนี้ คุณจะได้ใช้ทริกเกอร์ที่เปิดใช้งานเมื่อมีการคอมมิตโค้ดกับ Branch หลัก ทริกเกอร์นี้ทำให้การติดตั้งใช้งาน Canary ได้รับการรับส่งข้อมูลแบบสด 25% ทั้งหมดไปยังการแก้ไขใหม่

  1. ตั้งค่าทริกเกอร์สำหรับ Branch หลัก ดังนี้
    gcloud beta builds triggers create cloud-source-repositories \
  --trigger-config build/main-trigger.json
  2. หากต้องการตรวจสอบทริกเกอร์ใหม่ ให้ไปที่หน้าทริกเกอร์ Cloud Build ในคอนโซลไปที่ทริกเกอร์
  3. ผสาน Branch ไปยังบรรทัดหลักและพุชไปยังที่เก็บระยะไกล:
    git checkout main
git merge new-feature-1
git push gcp main
  4. หากต้องการตรวจสอบบิลด์ที่กำลังดำเนินการ ให้ไปที่หน้าประวัติ Cloud Build ในคอนโซลไปที่บิลด์เมื่อบิลด์เสร็จสมบูรณ์ ให้ไปยังขั้นตอนถัดไป
  5. ตรวจสอบการตอบกลับหลายรายการจากเซิร์ฟเวอร์ เรียกใช้คำสั่งต่อไปนี้ และโปรดทราบว่าประมาณ 25% ของการตอบกลับจะแสดงการตอบกลับใหม่ของ Hello World v1.1
    while true; do curl -w "\n" http://$PRODUCTION_IP; sleep 1;  done
    เมื่อพร้อมดำเนินการต่อแล้ว ให้กด Ctrl+c เพื่อออกจากการวนซ้ำ

7. การทำให้แท็ก Git ใช้งานได้โดยอัตโนมัติ

หลังจากที่ตรวจสอบการติดตั้งใช้งาน Canary กับการเข้าชมกลุ่มย่อยขนาดเล็กแล้ว คุณจะปล่อยการทำให้ใช้งานได้กับการเข้าชมแบบสดที่เหลืออยู่

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

  1. ตั้งค่าทริกเกอร์แท็ก:
    gcloud beta builds triggers create cloud-source-repositories \
  --trigger-config build/tag-trigger.json
  2. หากต้องการตรวจสอบทริกเกอร์ใหม่ ให้ไปที่หน้าทริกเกอร์ Cloud Build ในคอนโซลไปที่ทริกเกอร์
  3. สร้างแท็กใหม่และพุชไปยังที่เก็บระยะไกล:
    git tag 1.1
git push gcp 1.1
  4. หากต้องการตรวจสอบบิลด์ที่กำลังดำเนินการ ให้ไปที่หน้าประวัติ Cloud Build ในคอนโซลไปที่บิลด์
  5. ตรวจสอบการตอบกลับหลายรายการจาก Server เรียกใช้คำสั่งต่อไปนี้และโปรดทราบว่าการตอบกลับทั้ง 100% แสดงการตอบกลับใหม่ของ Hello World v1.1 ซึ่งอาจใช้เวลาสักครู่เนื่องจากมีการทำให้พ็อดใหม่ใช้งานได้และตรวจสอบประสิทธิภาพการทำงานภายใน GKE แล้ว
    while true; do curl -w "\n" http://$PRODUCTION_IP; sleep 1;  done
    เมื่อพร้อมดำเนินการต่อแล้ว ให้กด Ctrl+c เพื่อออกจากลูป ยินดีด้วย! คุณได้สร้างทริกเกอร์ CI/CD ใน Cloud Build สำหรับสาขาและแท็กเพื่อทำให้แอปของคุณใช้งานได้กับ GKE

8. ล้างข้อมูล

ลบโปรเจ็กต์

  1. ใน Cloud Console ให้ไปที่หน้าจัดการทรัพยากร
  2. ในรายการโปรเจ็กต์ ให้เลือกโปรเจ็กต์ที่ต้องการลบ แล้วคลิกลบ
  3. ในกล่องโต้ตอบ ให้พิมพ์รหัสโปรเจ็กต์ แล้วคลิกปิดเครื่องเพื่อลบโปรเจ็กต์