نشر حمل عمل سير عمل يستند إلى أحداث AWS (EDW) إلى Azure

في هذه المقالة، ستقوم بنشر حمل عمل AWS EDW إلى Azure.

سجل الدخول إلى Azure باستخدام az login الأمر .
```
az login
```
إذا كان حساب Azure الخاص بك يحتوي على اشتراكات متعددة، فتأكد من تحديد الاشتراك الصحيح. سرد أسماء ومعرفات اشتراكاتك باستخدام az account list الأمر .
```
az account list --query "[].{id: id, name:name }" --output table
```
حدد اشتراكا معينا باستخدام az account set الأمر .
```
az account set --subscription $subscriptionId
```

البرنامج النصي لتوزيع حمل العمل EDW

راجع متغيرات البيئة في الملف deployment/environmentVariables.sh ثم يمكنك استخدام deploy.sh البرنامج النصي في deployment/infra/ دليل مستودع GitHub لنشر التطبيق إلى Azure.

يتحقق البرنامج النصي أولا من تثبيت جميع أدوات المتطلبات الأساسية. إذا لم يكن الأمر كما هو، فسينتهي البرنامج النصي ويعرض رسالة خطأ تخبرك بالمتطلبات الأساسية المفقودة. إذا حدث ذلك، فراجع المتطلبات الأساسية، وقم بتثبيت أي أدوات مفقودة، ثم قم بتشغيل البرنامج النصي مرة أخرى. يجب تسجيل التزويد التلقائي للعقدة (NAP) لعلامة ميزة AKS على اشتراك Azure الخاص بك. إذا لم يكن مسجلا بالفعل، ينفذ البرنامج النصي أمر Azure CLI لتسجيل علامة الميزة.

يسجل البرنامج النصي حالة النشر في ملف يسمى deploy.state، الموجود في deployment الدليل. يمكنك استخدام هذا الملف لتعيين متغيرات البيئة عند نشر التطبيق.

بينما ينفذ البرنامج النصي الأوامر لتكوين البنية الأساسية لسير العمل، فإنه يتحقق من تنفيذ كل أمر بنجاح. إذا حدثت أي مشكلات، يتم عرض رسالة خطأ، ويتوقف التنفيذ.

يعرض البرنامج النصي سجلا أثناء تشغيله. يمكنك الاحتفاظ بالسجل عن طريق إعادة توجيه إخراج معلومات السجل وحفظه في install.log الملف في logs الدليل باستخدام الأوامر التالية:

mkdir ./logs
./deployment/infra/deploy.sh | tee ./logs/install.log

لمزيد من المعلومات، راجع ./deployment/infra/deploy.sh البرنامج النصي في مستودع GitHub الخاص بنا.

موارد حمل العمل

يقوم البرنامج النصي للتوزيع بإنشاء موارد Azure التالية:

مجموعة موارد Azure: مجموعة موارد Azure التي تخزن الموارد التي تم إنشاؤها بواسطة البرنامج النصي للتوزيع.
حساب تخزين Azure: حساب Azure Storage الذي يحتوي على قائمة الانتظار حيث يتم إرسال الرسائل بواسطة تطبيق المنتج وقراءتها بواسطة تطبيق المستهلك، والجدول حيث يخزن تطبيق المستهلك الرسائل المعالجة.
سجل حاوية Azure: يوفر سجل الحاوية مستودعا للحاوية التي تنشر التعليمات البرمجية لتطبيق المستهلك المعاد بناء التعليمات البرمجية له.
نظام مجموعة Azure Kubernetes Service (AKS): يوفر نظام مجموعة AKS تنسيق Kubernetes لحاوية تطبيق المستهلك ولديه الميزات التالية ممكنة:
- التزويد التلقائي للعقدة (NAP): تنفيذ مقياس عقدة Karpenter التلقائي على AKS.
- التحجيم التلقائي (KEDA) المستند إلى الحدث Kubernetes: يتيح KEDA تحجيم الجراب استنادا إلى الأحداث، مثل تجاوز حد عمق قائمة الانتظار المحدد.
- هوية حمل العمل: تسمح لك بإرفاق نهج الوصول المستندة إلى الدور بهويات الجراب لتحسين الأمان.
- سجل حاوية Azure المرفق: تسمح هذه الميزة لمجموعة AKS بسحب الصور من المستودعات على مثيل ACR المحدد.
تجمع عقدة التطبيق والنظام: يقوم البرنامج النصي أيضا بإنشاء تجمع عقدة تطبيق ونظام في نظام مجموعة AKS الذي يحتوي على تلوث لمنع جدولة pods التطبيق في تجمع عقدة النظام.
الهوية المدارة لمجموعة AKS: يعين acrPull البرنامج النصي الدور لهذه الهوية المدارة، ما يسهل الوصول إلى سجل حاويات Azure المرفق لسحب الصور.
هوية حمل العمل: يعين البرنامج النصي أدوار مساهم بيانات قائمة انتظار التخزين والمساهم في بيانات جدول التخزين لتوفير الوصول إلى التحكم في الوصول استنادا إلى الدور (RBAC) إلى هذه الهوية المدارة، والتي ترتبط بحساب خدمة Kubernetes المستخدم كهوية للحاويات التي يتم نشر حاويات تطبيق المستهلك عليها.
اثنين من بيانات الاعتماد الموحدة: تمكن بيانات الاعتماد واحدة الهوية المدارة من تنفيذ هوية الجراب، ويتم استخدام بيانات الاعتماد الأخرى لحساب خدمة عامل تشغيل KEDA لتوفير الوصول إلى مقياس KEDA لجمع المقاييس اللازمة للتحكم في التحجيم التلقائي للجراب.

التحقق من صحة النشر وتشغيل حمل العمل

بمجرد اكتمال البرنامج النصي للتوزيع، يمكنك نشر حمل العمل على نظام مجموعة AKS.

تعيين المصدر لجمع وتحديث متغيرات ./deployment/environmentVariables.sh البيئة لاستخدام الأمر التالي:
```
source ./deployment/environmentVariables.sh
```
تحتاج إلى المعلومات الموجودة في ./deployment/deploy.state الملف لتعيين متغيرات البيئة لأسماء الموارد التي تم إنشاؤها في النشر. عرض محتويات الملف باستخدام الأمر التالي cat :
```
cat ./deployment/deploy.state
```
يجب أن يظهر الإخراج المتغيرات التالية:
```
SUFFIX=
RESOURCE_GROUP=
AZURE_STORAGE_ACCOUNT_NAME=
AZURE_QUEUE_NAME=
AZURE_COSMOSDB_TABLE=
AZURE_CONTAINER_REGISTRY_NAME=
AKS_MANAGED_IDENTITY_NAME=
AKS_CLUSTER_NAME=
WORKLOAD_MANAGED_IDENTITY_NAME=
SERVICE_ACCOUNT=
FEDERATED_IDENTITY_CREDENTIAL_NAME=
KEDA_SERVICE_ACCT_CRED_NAME=
```
اقرأ الملف وأنشئ متغيرات البيئة لأسماء موارد Azure التي تم إنشاؤها بواسطة البرنامج النصي للتوزيع باستخدام الأوامر التالية:
```
while IFS= read -r; line do \
echo "export $line" \
export $line; \
done < ./deployment/deploy.state
```
احصل على بيانات اعتماد نظام مجموعة AKS باستخدام az aks get-credentials الأمر .
```
az aks get-credentials --resource-group $RESOURCE_GROUP --name $AKS_CLUSTER_NAME
```
تحقق من تشغيل جرابات عامل تشغيل KEDA في kube-system مساحة الاسم على نظام مجموعة AKS باستخدام kubectl get الأمر .
```
kubectl get pods --namespace kube-system | grep keda
```
يجب أن يبدو الإخراج مشابها لإخراج المثال التالي:

إنشاء تحميل محاكاة

الآن، يمكنك إنشاء تحميل محاكاة باستخدام تطبيق المنتج لملء قائمة الانتظار بالرسائل.

في نافذة طرفية منفصلة، انتقل إلى دليل المشروع.
تعيين متغيرات البيئة باستخدام الخطوات الواردة في القسم السابق. 1. قم بتشغيل تطبيق المنتج باستخدام الأمر التالي:
```
python3 ./app/keda/aqs-producer.py
```
بمجرد أن يبدأ التطبيق في إرسال الرسائل، قم بالتبديل مرة أخرى إلى نافذة المحطة الطرفية الأخرى.

انشر حاوية تطبيق المستهلك على نظام مجموعة AKS باستخدام الأوامر التالية:

chmod +x ./deployment/keda/deploy-keda-app-workload-id.sh
./deployment/keda/deploy-keda-app-workload-id.sh

ينفذ البرنامج النصي للتوزيع (deploy-keda-app-workload-id.sh) قالب على مواصفات بيان التطبيق YAML لتمرير متغيرات البيئة إلى pod. راجع المقتطف التالي من هذا البرنامج النصي:

cat <<EOF | kubectl apply -f -
apiVersion: apps/v1
kind: Deployment
metadata:
  name: $AQS_TARGET_DEPLOYMENT
  namespace: $AQS_TARGET_NAMESPACE
spec:
  replicas: 1
  selector:
    matchLabels:
      app: aqs-reader
  template:
    metadata:
      labels:
        app: aqs-reader
        azure.workload.identity/use: "true"
    spec:
      serviceAccountName: $SERVICE_ACCOUNT
      containers:
      - name: keda-queue-reader
        image: ${AZURE_CONTAINER_REGISTRY_NAME}.azurecr.io/aws2azure/aqs-consumer
        imagePullPolicy: Always
        env:
        - name: AZURE_QUEUE_NAME
          value: $AZURE_QUEUE_NAME
        - name: AZURE_STORAGE_ACCOUNT_NAME
          value: $AZURE_STORAGE_ACCOUNT_NAME
        - name: AZURE_TABLE_NAME
          value: $AZURE_TABLE_NAME
        resources:
          requests:
            memory: "64Mi"
            cpu: "250m"
          limits:
            memory: "128Mi"
            cpu: "500m"
EOF

التسمية azure.workload.identity/use في spec/template القسم هي قالب pod للنشر. تعيين التسمية إلى true يحدد أنك تستخدم هوية حمل العمل. serviceAccountName في مواصفات pod تحدد حساب خدمة Kubernetes لإقرانه بهوية حمل العمل. بينما تحتوي مواصفات الجراب على مرجع لصورة في مستودع خاص، لا يوجد أي imagePullSecret تحديد.

تحقق من تشغيل البرنامج النصي بنجاح باستخدام kubectl get الأمر .
```
kubectl get pods --namespace $AQS_TARGET_NAMESPACE
```
يجب أن تشاهد جراب واحد في الإخراج.
تحقق من إنشاء تجمع عقدة Karpenter. قم بذلك باستخدام kubectl get nodepool الأمر . ستبدو استجابة الأمر كما يلي:

تحقق من أن تجمع العقدة الافتراضي هو تجمع عقدة Karpenter باستخدام kubectl describe nodepool الأمر . في استجابة الأمر، يمكنك التحقق من أن تجمع العقدة هو تجمع عقدة Karpenter. ستشاهد ما يشبه ما يلي:

مراقبة توسيع النطاق للقرون والعقد باستخدام k9s

يمكنك استخدام أدوات مختلفة للتحقق من تشغيل التطبيقات المنشورة على AKS، بما في ذلك مدخل Azure وk9s. لمزيد من المعلومات حول k9s، راجع نظرة عامة على k9s.

قم بتثبيت k9s على نظام مجموعة AKS باستخدام الإرشادات المناسبة للبيئة الخاصة بك في نظرة عامة على تثبيت k9s.
إنشاء نافذتين، واحدة مع عرض pods والأخرى مع عرض العقد في مساحة الاسم التي حددتها في AQS_TARGET_NAMESPACE متغير البيئة (القيمة الافتراضية هي aqs-demo) وبدء k9s في كل نافذة.

ينبغي أن ترى شيئًا مشابهًا لما يلي:
بعد التأكد من تثبيت حاوية تطبيق المستهلك وتشغيلها على نظام مجموعة AKS، قم بتثبيت ScaledObject وتشغيل المصادقة المستخدمة من قبل KEDA للتحجيم التلقائي للحجيرة عن طريق تشغيل البرنامج النصي لتثبيت الكائن المتدرج (keda-scaleobject-workload-id.sh). باستخدام الأوامر التالية:
```
chmod +x ./deployment/keda/keda-scaleobject-workload-id.sh
./deployment/keda/keda-scaleobject-workload-id.sh
```
يقوم البرنامج النصي أيضا بإجراء القوالب لإدخال متغيرات البيئة عند الحاجة. راجع المقتطف التالي من هذا البرنامج النصي:
```
cat <<EOF | kubectl apply -f -
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: aws2az-queue-scaleobj
  namespace: ${AQS_TARGET_NAMESPACE}
spec:
  scaleTargetRef:
    name: ${AQS_TARGET_DEPLOYMENT}     #K8s deployement to target
  minReplicaCount: 0  # We don't want pods if the queue is empty nginx-deployment
  maxReplicaCount: 15 # We don't want to have more than 15 replicas
  pollingInterval: 30 # How frequently we should go for metrics (in seconds)
  cooldownPeriod:  10 # How many seconds should we wait for downscale
  triggers:
  - type: azure-queue
    authenticationRef:
      name: keda-az-credentials
    metadata:
      queueName: ${AZURE_QUEUE_NAME}
      accountName: ${AZURE_STORAGE_ACCOUNT_NAME}
      queueLength: '5'
      activationQueueLength: '20' # threshold for when the scaler is active
      cloud: AzurePublicCloud
---
apiVersion: keda.sh/v1alpha1
kind: TriggerAuthentication
metadata:
  name: keda-az-credentials
  namespace: $AQS_TARGET_NAMESPACE
spec:
  podIdentity:
    provider: azure-workload
    identityId: '${workloadManagedIdentityClientId}'
EOF
```
يصف البيان موردين: TriggerAuthentication

عندما يتم تثبيت الكائن الذي تم تغيير حجمه بشكل صحيح ويكتشف KEDA تجاوز حد التحجيم، فإنه يبدأ في جدولة الحجيرات. إذا كنت تستخدم k9s، يجب أن ترى شيئا مثل هذا:

إذا سمحت للمنتج بملء قائمة الانتظار برسائل كافية، فقد يحتاج KEDA إلى جدولة المزيد من الجرابات أكثر من العقد التي يجب تقديمها. لاستيعاب هذا، سوف يبدأ Karpenter في العقد ويبدأ في جدولتها. إذا كنت تستخدم k9s، يجب أن ترى شيئا مثل هذا:

في هاتين الصورتين، لاحظ كيف زاد عدد العقد التي تحتوي أسماؤها على aks-default عقدة واحدة إلى ثلاث عقد. إذا أوقفت تطبيق المنتج من وضع الرسائل في قائمة الانتظار، فسيقلل المستهلكون في النهاية من عمق قائمة الانتظار دون الحد الأدنى، وسيتوسع كل من KEDA وKarpenter. إذا كنت تستخدم k9s، يجب أن ترى شيئا مثل هذا:
وأخيرا، يمكنك عرض نشاط التحجيم التلقائي ل Karpenter باستخدام kubectl get events الأمر كما هو موضح هنا: