نشر مستمر في Google Kubernetes Engine (GKE) باستخدام Cloud Build

1. نظرة عامة

في هذا الدرس التطبيقي، ستتعلّم كيفية إعداد مسار تسليم متواصل في GKE باستخدام Cloud Build. يوضّح هذا التمرين العملي كيفية تشغيل مهام Cloud Build لأحداث git المختلفة، بالإضافة إلى نمط بسيط لإصدارات Canary التلقائية في GKE.

ستُكمل الخطوات التالية:

  • إنشاء تطبيق GKE
  • أتمتة عمليات النشر لفروع git
  • أتمتة عمليات النشر للفرع الرئيسي في Git
  • أتمتة عمليات النشر لعلامات git

2. قبل البدء

لاستخدام دليل المرجع هذا، يجب أن يكون لديك مشروع على Google Cloud. يمكنك إنشاء مشروع جديد أو اختيار مشروع سبق أن أنشأته:

  1. اختَر مشروعًا على السحابة الإلكترونية أو أنشِئ مشروعًا.

الانتقال إلى صفحة اختيار المشروع

  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. فعِّل واجهات برمجة التطبيقات التالية:
    • Resource Manager
    • 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. استنسِخ رمز المصدر الخاص بالعيّنة وانتقِل إلى دليل المختبر:
    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 وProduction:أنشئ عمليات النشر والخدمات في بيئتَي الإنتاج و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
    
    ستوجّه الخدمة التي تم نشرها هنا الزيارات إلى كلّ من عمليات نشر الإصدار التجريبي وعمليات نشر الإصدار المتاح للجميع.
  3. مراجعة عدد وحدات Pod قيد التشغيل: تأكَّد من أنّ لديك أربع وحدات Pod قيد التشغيل للواجهة الأمامية، بما في ذلك ثلاث وحدات للزيارات الفعلية ووحدة واحدة لإصدارات Canary. وهذا يعني أنّ التغييرات التي يتم إجراؤها على الإصدار التجريبي ستؤثر فقط في مستخدم واحد من أصل 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 عند إرسال أي فرع آخر غير main. سيؤدي ملف Cloud Build المستخدَم هنا إلى إنشاء مساحة اسم وعملية نشر تلقائيًا لأي فروع حالية أو جديدة، ما يتيح للمطوّرين معاينة الرمز قبل دمجه مع الفرع الرئيسي.

  1. إعداد المشغّل:المكوّن الأساسي لهذا المشغّل هو استخدام المَعلمة branchName لمطابقة main والمَعلمة invertRegex التي تم ضبطها على "صحيح" وتغيّر نمط branchName لمطابقة أي شيء ليس main. يمكنك الرجوع إلى الأسطر التالية في build/branch-trigger.json.
      "branchName": "main",
      "invertRegex": true
    
    بالإضافة إلى ذلك، تنشئ الأسطر القليلة الأخيرة من ملف Cloud Build المستخدَم مع مشغّل هذا التطبيق مساحة اسم تحمل اسم الفرع الذي شغّل المهمة، ثم تنشر التطبيق والخدمة ضمن مساحة الاسم الجديدة. للعلم، يمكنك العثور على الأسطر التالية في 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. إنشاء فرع جديد:
    git checkout -b new-feature-1
    
  4. عدِّل الرمز للإشارة إلى v1.1Edit 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

قبل طرح الرمز في مرحلة الإصدار العلني، من الشائع طرح الرمز على مجموعة فرعية صغيرة من الزيارات المباشرة قبل نقل جميع الزيارات إلى قاعدة الرموز الجديدة.

في هذا القسم، ستنفّذ مشغّلاً يتم تفعيله عند إرسال الرمز إلى الفرع الرئيسي. يؤدي المشغّل إلى نشر الإصدار التجريبي الذي يتلقّى% 25 من كل زيارات الموقع المباشرة إلى المراجعة الجديدة.

  1. إعداد المشغّل للفرع الرئيسي:
    gcloud beta builds triggers create cloud-source-repositories \
      --trigger-config build/main-trigger.json
    
  2. لمراجعة المشغّل الجديد، انتقِل إلى صفحة "المشغّلات" في Cloud Build في "وحدة التحكّم".الانتقال إلى "المشغّلات"
  3. ادمج الفرع مع الخط الرئيسي وادفع إلى المستودع البعيد:
    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

بعد التحقّق من صحة عملية النشر التجريبي باستخدام مجموعة فرعية صغيرة من الزيارات، يمكنك نشر عملية النشر لبقية الزيارات المباشرة.

في هذا القسم، يمكنك إعداد مشغّل يتم تفعيله عند إنشاء علامة في المستودع. تضع المشغّلات العلامة المناسبة على الصورة ثم تنشر التعديلات في بيئة الإنتاج، ما يضمن وصول% 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. مراجعة ردود متعدّدة من الخادمتشغيل الأمر التالي وملاحظة أنّ% 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. في مربّع الحوار، اكتب رقم تعريف المشروع، ثم انقر على إيقاف لحذف المشروع.