مهاجرت از Compute Engine به Kubernetes Engine با مهاجرت برای Anthos

۱. مرور کلی

بازنویسی یا مهندسی مجدد برنامه‌های موجود برای کار روی Kubernetes همیشه امکان‌پذیر یا عملی نیست. Migrate for Anthos می‌تواند به مدرن‌سازی برنامه‌های موجود شما و اجرای آنها در Kubernetes کمک کند. در این آزمایشگاه کد، شما یک برنامه وب موجود که روی Compute Engine میزبانی می‌شود را با استفاده از Migrate for Anthos به Kubernetes Engine منتقل خواهید کرد.

آنچه یاد خواهید گرفت

• نحوه استقرار Migrate برای Anthos در یک کلاستر Kubernetes
• نحوه ایجاد یک کانتینر در یک مجموعه stateful از یک نمونه Compute Engine موجود
• نحوه استقرار کانتینر در Kubernetes و پیکربندی آن با یک متعادل‌کننده بار

آنچه نیاز دارید

• یک پروژه گوگل کلود با تنظیمات صورتحساب. اگر ندارید، باید یکی ایجاد کنید .

توجه: راهکارهای مستقر در این Codelab منجر به فعالیت‌های قابل پرداخت خواهد شد. قیمت‌گذاری Google Compute Engine در اینجا مستند شده است. کاربران جدید Google Cloud Platform واجد شرایط دریافت یک دوره آزمایشی رایگان با اعتبار 300 دلاری هستند.

۲. راه‌اندازی

این آزمایشگاه کد می‌تواند بدون هیچ گونه نصب یا پیکربندی محلی، به طور کامل روی پلتفرم ابری گوگل اجرا شود.

فعال کردن APIها

قبل از شروع، مطمئن شوید که API های مورد نیاز را در پروژه Google Cloud خود فعال کرده اید:

فعال کردن API موتور محاسبات (Compute Engine API) فعال کردن API موتور کوبرنتس (Kubernetes Engine API)

ایجاد یک سرور وب نمونه محاسباتی

بیایید یک نمونه محاسباتی ایجاد کنیم که برای میزبانی وب سرور اولیه nginx خود، به همراه قوانین فایروال که به ما امکان مشاهده صفحه فرود پیش‌فرض وب سرور را می‌دهد، استفاده خواهیم کرد. چند روش برای انجام این کار وجود دارد، اما برای سهولت استفاده، از Cloud Shell استفاده خواهیم کرد.

فعال کردن پوسته ابری

در Cloud Shell دستور زیر را اجرا کنید:

gcloud compute instances create webserver --zone=us-central1-a && \
gcloud compute firewall-rules create default-allow-http --allow=tcp:80 

نیمه اول این دستور یک نمونه Google Cloud در منطقه us-central1-a ایجاد می‌کند در حالی که نیمه دوم یک قانون فایروال به نام 'default-allow-http' ایجاد می‌کند که به ترافیک http اجازه ورود به شبکه ما را می‌دهد.

توجه : اگر این قانون فایروال از قبل وجود داشته باشد، خطایی مبنی بر وجود آن دریافت خواهید کرد. نگران نباشید، می‌توانید به مراحل بعدی بروید.

وقتی نمونه با موفقیت ایجاد شد، جدولی با جزئیات نمونه نمایش داده می‌شود. به IP خارجی توجه کنید - بعداً برای تأیید اجرای وب سرور به آن نیاز خواهیم داشت.

پس از راه‌اندازی و اجرای نمونه، می‌توانیم از طریق Cloud Shell به نمونه خود SSH کنیم تا nginx را نصب کرده و وب سرور را راه‌اندازی کنیم:

gcloud compute ssh --zone us-central1-a webserver

پس از ورود به نمونه محاسباتی خود، nginx را نصب کنید:

sudo apt install nginx

خروج از جلسه ssh با دستور logout

بیایید با وارد کردن IP خارجی نمونه از قبل در مرورگر خود، تأیید کنیم که وب سرور ما در حال اجرا است. شما باید صفحه خوشامدگویی پیش‌فرض nginx را ببینید:

این وب سرور به عنوان برنامه وب قدیمی که با استفاده از Migrate for Anthos به Kubernetes منتقل خواهیم کرد، عمل خواهد کرد.

۳. خوشه‌بندی Kubernetes با Migrate برای Anthos

در مرحله بعد، یک کلاستر GKE ایجاد خواهیم کرد که در نهایت سرور وب موتور محاسباتی را به آن منتقل خواهیم کرد. در کنسول ابری، دستور زیر را اجرا کنید:

gcloud container clusters create my-gke-cluster \
  --zone us-central1-a \
  --cluster-version 1.13 \
  --machine-type n1-standard-4 \
  --image-type "UBUNTU" \
  --num-nodes 1 \
  --enable-stackdriver-kubernetes

چند دقیقه به این دستور زمان بدهید تا تکمیل شود. پس از ایجاد خوشه، خروجی حاوی جزئیات آن را دریافت خواهید کرد:

سپس، برای استقرار Migrate برای Anthos به بازار GCP بروید:

بازار هدف: مهاجرت برای آنتوس

در صفحه بازار برای Migrate for Anthos، روی configure کلیک کنید و در صورت درخواست، پروژه خود را از لیست انتخاب کنید. صفحه بعدی فرمی را با مقادیر پیش‌فرض وارد شده نمایش می‌دهد. مطمئن شوید که کلاستر انتخاب شده همان کلاستری است که ما ایجاد کرده‌ایم و روی Deploy کلیک کنید:

اکنون Migrate for Anthos باید روی کلاستر kubernetes ما مستقر شده باشد. پس از اتمام استقرار، وضعیت «OK» را در صفحه Kubernetes Engine Applications مشاهده خواهید کرد:

۴. از نمونه محاسباتی تا مجموعه دارای وضعیت

ما یک کلاستر Kubernetes داریم که Migrate for Anthos را اجرا می‌کند، بنابراین اکنون می‌توانیم فرآیند مهاجرت را آغاز کنیم. برای استقرار نمونه محاسباتی خود در یک کلاستر Kubenetes، نمونه موتور محاسباتی خود را خاموش می‌کنیم تا بتوانیم از دیسک‌ها snapshot بگیریم. قبل از ادامه، شناسه نمونه را که بعداً به آن نیاز خواهیم داشت، یادداشت کنید:

gcloud compute instances describe webserver --zone us-central1-a | grep ^id

بیایید نمونه محاسباتی خود را خاموش کنیم:

gcloud compute instances stop webserver --zone us-central1-a

توجه : در عمل، بسته به الزامات تجاری، ممکن است نیاز به برنامه‌ریزی قابل توجه یا یک بازه زمانی نگهداری برنامه‌ریزی‌شده برای اطمینان از مدیریت مناسب زمان از کارافتادگی باشد.

اکنون که نمونه متوقف شده است، می‌توانیم با اجرای اسکریپت زیر، دیسک‌ها را به صورت ایمن snapshot کنیم. حتماً شناسه پروژه و شناسه نمونه خود را وارد کنید:

python3 /google/migrate/anthos/gce-to-gke/clone_vm_disks.py \
  -p <project-id>   -i <instance-id> \
  -z us-central1-a \
  -T us-central1-a \
  -A webserver-statefulset \
  -o containerized-webserver.yaml

با این پرچم‌ها، clone_vm_disks.py کارهای زیر را انجام خواهد داد:

• تأیید کنید که نمونه GCE شما خاموش است
• از هر یک از دیسک‌های نمونه خود یک اسنپ‌شات ایجاد کنید
• از هر اسنپ‌شات یک دیسک جدید ایجاد کنید
• اسنپ‌شات‌هایی که ایجاد کرده را حذف کنید
• یک فایل YAML در دایرکتوری کاری فعلی خود برای استقرار یک مجموعه stateful که میزبان وب سرور شما خواهد بود، ایجاد کنید.

فایل yaml تولید شده، مجموعه‌ای با وضعیت (stateful) را در کلاستر kubernetes ما، به همراه ادعاهای حجم دائمی مورد نیاز برای نصب دیسک‌های کپی شده در کانتینر وب سرور ما، فراهم می‌کند. می‌توانیم این تغییرات را با kubectl اعمال کنیم:

kubectl apply -f containerized-webserver.yaml

وضعیت webserver-statefulset را در صفحه Workloads بررسی کنید:

بارهای کاری Kubernetes

طبیعی است که وضعیت پس از اجرای kubectl apply برای چند دقیقه «Pods are pending» باشد. وقتی وضعیت «OK» شد، ادامه دهید.

۵. کلاستر را در معرض متعادل‌کننده بار قرار دهید

در این مرحله، کلاستر Kubenetes ما باید وب سرور ما را به عنوان یک مجموعه stateful اجرا کند، اما ما همچنین باید کانتینر آن را در معرض یک متعادل‌کننده بار قرار دهیم تا از طریق یک آدرس IP خارجی به وب سرور ما دسترسی پیدا کند. در پوسته Cloud، یک فایل جدید با نام loadbalancer.yaml با محتوای زیر ایجاد کنید:

متعادل کننده بار.yaml

apiVersion: v1
kind: Service
metadata:
  name: webserver-loadbalancer
spec:
  type: LoadBalancer
  selector:
    app: webserver-statefulset
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80

و حالا آن را با kubectl اعمال کنید:

kubectl apply -f loadbalancer.yaml

می‌توانیم از kubectl برای بازیابی آدرس IP خارجی سرویس webserver-container استفاده کنیم:

kubectl get services

اگر آدرس IP خارجی را در مرورگر خود وارد کنیم، باید همان صفحه خوشامدگویی پیش‌فرض nginx را از قبل دریافت کنیم:

ما این کار را انجام دادیم! وب سرور GCE ما اکنون روی Kubernetes میزبانی می‌شود! عالی!

۶. نظارت بر استک‌درایور

معیارها

Kubernetes Engine به عنوان یک سرویس مدیریت‌شده‌ی Kubernetes، به طور خودکار برای ثبت وقایع و نظارت با Stackdriver تجهیز شده است. بیایید برخی از معیارهایی را که Stackdriver به طور خودکار برای ما ثبت می‌کند، بررسی کنیم.

روی پیوند نظارت در منوی محصولات کلیک کنید - دسترسی به این بخش برای اولین بار از پروژه شما ممکن است چند دقیقه طول بکشد تا فضای کاری شما تنظیم شود.

نکته : می‌توانید با فشار دادن کلید '/' و تایپ کردن مورد منو، به سرعت به یک مورد از منوی محصولات و خدمات دسترسی پیدا کنید.

پس از بارگذاری، در پنل سمت چپ، ماوس را روی Resources ببرید و از منو، گزینه‌ی «Kubernetes Engine NEW» را انتخاب کنید.

هر ردیف در داشبورد ارائه شده در اینجا، نشان دهنده یک منبع Kubernetes است. می‌توانید با استفاده از لینک‌های بالای داشبورد، بین نمای زیرساخت، بار کاری یا خدمات جابجا شوید.

در نمای Workloads، 'my-gke-cluster' را باز کنید و به default > webserver-statefulset > webserver-statefulset-0 > webserver-statefulset بروید. روی کانتینر مجموعه webserver-stateful کلیک کنید. در اینجا برخی از معیارهای خارج از جعبه که توسط Stackdriver ثبت می‌شوند، از جمله میزان استفاده از حافظه و CPU را مشاهده خواهید کرد.

نمودارهایی که در این داشبورد نمایش داده می‌شوند، نمودارهایی هستند که می‌توانیم برای ایجاد یک داشبورد سفارشی از آنها استفاده کنیم.

توجه: ممکن است جمع‌آوری داده‌ها و نمایش آنها در Stackdriver کمی طول بکشد.

داشبوردهای سفارشی

Stackdriver به ما امکان می‌دهد داشبوردهای سفارشی ایجاد کنیم که می‌توانیم از آنها برای سازماندهی نمودارها و گراف‌ها برای هرگونه داده معیار موجود استفاده کنیم. بیایید یک داشبورد سفارشی ایجاد کنیم تا نگاهی اجمالی به برخی از معیارهای وب سرور خود ارائه دهیم.

در پنل سمت چپ، نشانگر ماوس را روی Dashboards نگه دارید، سپس روی Create Dashboard کلیک کنید.

حالا که داشبورد خالی خود را داریم، می‌توانیم معیارهایی را که می‌خواهیم بررسی کنیم اضافه کنیم. بیایید به داشبورد بدون عنوان خود یک نام مفید مانند «کانتینرهای وب سرور من» بدهیم و روی «افزودن نمودار» در بالا سمت راست کلیک کنیم:

معیارهای از پیش تعریف شده را به خاطر دارید؟ بیایید یک نمودار برای میزان استفاده از CPU کانتینر اضافه کنیم. در فیلد عنوان نمودار، عبارت «CPU Utilization» را وارد کنید. در کادر «Find resource type and metric»، عبارت request_utilization را تایپ کنید و CPU request usage را از لیست فیلتر شده انتخاب کنید. این انتخاب، هر دو فیلد نوع منبع و معیار را برای ما پر می‌کند.

در مرحله بعد، می‌خواهیم بر اساس project_id (اگر چندین پروژه داریم) و container_name فیلتر کنیم. در کادر Filter، project_id را تایپ کنید، آن را از لیست فیلتر شده انتخاب کنید و پروژه خود را در فیلد Value انتخاب کنید. همچنین باید بر اساس container_name فیلتر کنیم. در کادر Filter، container_name را تایپ کنید، آن را از لیست فیلتر شده انتخاب کنید و در فیلد Value، webserver-statefulset را انتخاب کنید. روی ذخیره کلیک کنید.

اکنون یک داشبورد با اولین نمودار خود داریم.

۷. سیاست بررسی و هشدار آپتایم

با Stackdriver، می‌توانیم هشدارهایی تنظیم کنیم تا وقتی هر معیار به مقادیر آستانه‌ای که ما مشخص می‌کنیم می‌رسد، به ما اطلاع دهند. به عنوان مثال، می‌توانیم از Stackdriver بخواهیم وقتی میزان استفاده از CPU در آخرین مرحله برای مدت زمان مشخصی بالاتر از یک آستانه مشخص است، به ما ایمیل بزند، که ممکن است نشان‌دهنده مشکلی در برنامه ما باشد. برای نشان دادن اینکه این هشدارها چگونه به نظر می‌رسند، بیایید یک بررسی زمان روشن بودن سیستم تنظیم کنیم و سپس یک قطعی را شبیه‌سازی کنیم.

از پنل سمت چپ، گزینه Uptime Checks و سپس Uptime Checks Overview را انتخاب کنید:

همانطور که صفحه بررسی‌های آپتایم نشان می‌دهد، بیایید اولین بررسی آپتایم خود را تنظیم کنیم. روی دکمه «افزودن بررسی آپتایم» در سمت راست بالای صفحه کلیک کنید.

در فرم بعدی، «زمان روشن بودن نقطه پایانی» را به عنوان عنوان و آدرس IP خارجی متعادل‌کننده بار خود را به عنوان نام میزبان وارد کنید.

روی ذخیره کلیک کنید و از شما خواسته می‌شود که یک سیاست هشدار همراه ایجاد کنید:

روی ایجاد خط‌مشی هشدار کلیک کنید.

بیایید نام این را «خط‌مشی زمان روشن بودن نقطه پایانی» بگذاریم. در بخش پیکربندی ، «شرط باعث می‌شود اگر» را روی «هرگونه نقض سری زمانی» تنظیم کنید و روی ذخیره کلیک کنید.

هنوز کارمان تمام نشده است. در مرحله بعد، یک کانال اعلان (Notification Channel) مشخص خواهیم کرد تا وقتی خط‌مشی هشدار ما نقض شد، به ما اطلاع داده شود. در منوی کشویی نوع کانال اعلان (Notification Channel Type)، ایمیل و به دنبال آن یک آدرس ایمیل معتبر را انتخاب کنید.

روی «افزودن کانال اعلان » کلیک کنید. در نهایت، در پایین فرم، نام سیاست را «زمان فعال بودن برنامه وب» بگذارید و روی «ذخیره» کلیک کنید.

برای دیدن اینکه یک هشدار چگونه به نظر می‌رسد، در کنسول ابری خود، یک بار دیگر پوسته ابری خود را باز کنید. دستور زیر سرویس nginx را که در غلاف وب سرور ما اجرا می‌شود، متوقف می‌کند:

kubectl exec -t webserver-statefulset-0 -- /bin/bash -c "nginx -s stop"

پس از چند دقیقه، باید ایمیلی دریافت کنید که شما را از قطعی اینترنت مطلع می‌کند:

بیایید آن را لغو کنیم. به Cloud Shell خود برگردیم و nginx را مجدداً راه‌اندازی کنیم:

kubectl exec -t webserver-statefulset-0 -- /bin/bash -c "nginx"

بعد از چند دقیقه، ایمیل دیگری از Stackdriver دریافت خواهید کرد، این بار با اخباری بهتر از قبل:

۸. پاکسازی

حالا که با Migrate for Anthos از GCE به GKE مهاجرت کرده‌ایم، بیایید پروژه‌مان را از تمام منابعی که ایجاد کرده‌ایم پاک کنیم.

حذف پروژه

اگر ترجیح می‌دهید، می‌توانید کل پروژه را حذف کنید. در کنسول GCP، به صفحه Cloud Resource Manager بروید:

مدیر منابع ابری

در لیست پروژه‌ها، پروژه‌ای را که روی آن کار می‌کردیم انتخاب کرده و روی «حذف» کلیک کنید. از شما خواسته می‌شود شناسه پروژه را وارد کنید. آن را وارد کرده و روی «خاموش کردن» کلیک کنید.

اگر ترجیح می‌دهید اجزای مختلف را یکی یکی حذف کنید، به بخش بعدی بروید.

استک‌درایور

داشبورد

از صفحه داشبورد خود، روی نماد تنظیمات کلیک کنید در بالای صفحه کلیک کنید و حذف داشبورد را انتخاب کنید.

سیاست هشدار

از صفحه سیاست‌ها ، از منوی اقدامات، حذف را انتخاب کنید. در سمت راست برای هر سیاستی که ایجاد کرده‌اید.

بررسی زمان فعال بودن دستگاه

از صفحه بررسی‌های آپتایم، از منوی اقدامات در سمت راست هر بررسی که ایجاد کرده‌اید، گزینه حذف را انتخاب کنید.

GCE و کوبرنتیز

نمونه موتور محاسباتی گوگل

gcloud compute instances delete webserver --zone=us-central1-a

خوشه Kubernetes (شامل Migrate برای Anthos، مجموعه stateful و سرویس متعادل‌کننده بار)

gcloud container clusters delete my-gke-cluster --zone=us-central1-a

دیسک‌ها

مجموعه‌ی دارای وضعیت ما از دیسکی که خودمان ایجاد کرده‌ایم استفاده می‌کند. برای بازیابی نام از دستور زیر استفاده کنید:

gcloud compute disks list --filter=webserver

با استفاده از نام دیسک خود به جای نام دیسک من، آن را با دستور زیر حذف کنید:

gcloud compute disks delete vls-690d-webserver --zone=us-central1-a

همه چی پاک شد!

۹. تبریک می‌گویم!

آفرین! شما وب سرور خود را با استفاده از Migrate for Anthos از یک نمونه GCE به یک کلاستر Kubernetes منتقل کردید.

آنچه ما پوشش داده‌ایم

• ما یک وب سرور را با استفاده از Migrate for Anthos از GCE به یک کلاستر Kubernetes منتقل کردیم.
• ما وب سرور stateful set خود را با قرار دادن آن از طریق یک سرویس متعادل‌کننده بار Kubernetes، به روی عموم باز کردیم.
• ما Stackdriver را فعال کردیم و یک داشبورد سفارشی ساختیم
• ما یک بررسی آپتایم به همراه یک سیاست هشدار پیکربندی کردیم تا به ما اطلاع دهد چه زمانی وب سرور ما از دسترس خارج می‌شود.