במדריך הזה מוצג פתרון מוכן לשימוש שמבוסס על Google Distributed Cloud (תוכנה בלבד) ב-bare metal ועל סנכרון תצורות כדי לפרוס אשכולות Kubernetes בפריסה רחבה בקצה הרשת. המדריך הזה מיועד למפתחים ולמפעילים של פלטפורמות. לפני שקוראים את המסמך הזה, חשוב להכיר את הטכנולוגיות והמושגים הבאים:
- Ansible playbooks.
- פריסות Edge והאתגרים שלהן.
- איך עובדים עם Google Cloud פרויקט.
- פריסת אפליקציית אינטרנט בקונטיינר.
- ממשקי שורת הפקודה (CLI)
gcloudו-kubectl.
במדריך הזה משתמשים במכונות וירטואליות (VM) של Compute Engine כדי לדמות צמתים שנפרסו בפריפריה, ובאפליקציה לדוגמה של נקודת מכירה בתור עומס העבודה בפריפריה. תוכנת Google Distributed Cloud בלבד ו-Config Sync מספקות ניהול ושליטה מרכזיים באשכול הקצה. סנכרון תצורות שולף באופן דינמי הגדרות חדשות מ-GitHub ומחיל את כללי המדיניות וההגדרות האלה על האשכולות.
ארכיטקטורת פריסה של Edge
פריסת Edge בתחום הקמעונאות היא דרך טובה להמחיש את הארכיטקטורה שמשמשת בפריסה טיפוסית של אשכול bare metal.
חנות קמעונאית פיזית היא נקודת האינטראקציה הקרובה ביותר בין יחידה עסקית של ארגון לבין הצרכן. מערכות התוכנה בתוך החנויות צריכות להריץ את עומסי העבודה שלהן, לקבל עדכונים בזמן ולדווח על מדדים קריטיים בבידוד ממערכת הניהול המרכזית של הארגון. בנוסף, צריך לתכנן את מערכות התוכנה האלה כך שיהיה אפשר להרחיב אותן לעוד מיקומי חנויות בעתיד. כל פריסה של אשכול bare metal עומדת בכל הדרישות האלה למערכות תוכנה בחנויות, אבל פרופיל ה-edge מאפשר תרחיש שימוש חשוב: פריסות בסביבות עם משאבי חומרה מוגבלים, כמו חנות קמעונאית.
בתרשים הבא מוצג פריסת אשכול Bare Metal שמשתמש בפרופיל Edge בחנות קמעונאית:
בתרשים שלמעלה מוצגת חנות קמעונאית פיזית טיפוסית. בחנות יש מכשירים חכמים כמו קוראי כרטיסים, מכונות קופה, מצלמות ומדפסות. בנוסף, בחנות יש שלושה מכשירי חומרה פיזיים למחשוב (מסומנים בתוויות Node 1, Node 2 ו-Node 3). כל המכשירים האלה מחוברים למפסק רשת מרכזי. לכן, שלושת המכשירים הממוחשבים מחוברים זה לזה דרך רשת Layer 2. מכשירי המחשוב שמחוברים לרשת יוצרים את תשתית ה-Bare Metal. תוכנת Google Distributed Cloud פועלת בכל אחד משלושת מכשירי המחשוב. למכשירים האלה יש גם אחסון דיסקים משלהם, והם מוגדרים לשכפול נתונים ביניהם כדי ליצור זמינות גבוהה.
בתרשים מוצגים גם הרכיבים העיקריים הבאים שכלולים בפריסת אשכולות Bare Metal:
הרכיב שמסומן כ-MetalLB הוא מאזן העומסים שכלול בחבילה.
רכיב סנכרון תצורות מאפשר לסנכרן את מצב האשכול עם מאגרי קוד מקור. זהו תוסף אופציונלי מומלץ מאוד שנדרשת התקנה והגדרה נפרדות כדי להשתמש בו. מידע נוסף על הגדרת סנכרון תצורות ועל המינוח השונה מופיע במסמכי העזרה של סנכרון תצורות.
מאגר הבסיס ומאגר מרחב השמות שמוצגים בחלק העליון של הדיאגרמה מחוץ למיקום החנות מייצגים שני מאגרי מקור.
השינויים באשכול נדחפים למאגרי המקור המרכזיים האלה. פריסות של אשכולות במיקומי קצה שונים שולפות עדכונים ממאגרי המקור. ההתנהגות הזו מיוצגת על ידי החיצים שמקשרים בין שני המאגרים בתרשים לבין רכיבי Config Sync בתוך האשכול שפועל במכשירים.
רכיב מרכזי נוסף שמוצג כחלק מהאשכול הוא VM Runtime ב-GDC. VM Runtime on GDC מאפשר להריץ עומסי עבודה קיימים שמבוססים על מכונות וירטואליות בתוך האשכול, בלי צורך במיכלור. במסמכי התיעוד של VM Runtime ב-GDC מוסבר איך להפעיל אותו ולפרוס את עומסי העבודה של המכונות הווירטואליות באשכול.
הרכיב שמסומן כאפליקציה מציין תוכנה שנפרסה באשכול על ידי החנות הקמעונאית. דוגמה לאפליקציה כזו היא אפליקציית נקודת המכירה שמוצגת בקיוסקים בחנות קמעונאית.
התיבות בחלק התחתון של הדיאגרמה מייצגות את המכשירים הרבים (כמו קיוסקים, טאבלטים או מצלמות) שנמצאים בחנות קמעונאית, שכולם מחוברים למפסק רשת מרכזי. הרשת המקומית בתוך החנות מאפשרת לאפליקציות שפועלות בתוך האשכול להגיע למכשירים האלה.
בקטע הבא מוצגת הדמיה של פריסת חנות קמעונאית כזו ב-Google Cloud באמצעות מכונות וירטואליות של Compute Engine. ההדמיה הזו היא מה שתשתמשו בה במדריך הבא כדי להתנסות באשכול Bare Metal.
פריסה מדומה של Edge ב- Google Cloud
בתרשים הבא מוצג כל מה שמגדירים ב-Google Cloud במדריך הזה. התרשים הזה מקביל לתרשים של חנות קמעונאית מהקטע הקודם. הפריסה הזו מייצגת מיקום קצה מדומה שבו אפליקציית נקודת המכירה נפרסת. הארכיטקטורה כוללת גם עומס עבודה של אפליקציה לדוגמה לנקודת מכירה, שבה תשתמשו במדריך הזה. אתם ניגשים לאפליקציית נקודת המכירה בתוך האשכול באמצעות דפדפן אינטרנט בתור קיוסק.
שלוש המכונות הווירטואליות (VM) של Compute Engine בתרשים שלמעלה מייצגות את החומרה הפיזית (או הצמתים) במיקום קצה טיפוסי. הציוד הזה יחובר באמצעות מתגי רשת כדי ליצור את תשתית ה-Bare Metal. בסביבה המדומה שלנו ב- Google Cloud, המכונות הווירטואליות האלה מחוברות זו לזו דרך רשת ענן וירטואלי פרטי (VPC) שמוגדרת כברירת מחדל בפרויקט Google Cloud .
בהתקנה טיפוסית של אשכול bare metal, אפשר להגדיר מאזני עומסים משלכם. עם זאת, במדריך הזה לא מגדירים מאזן עומסים חיצוני. במקום זאת, משתמשים במאזן העומסים MetalLB שמצורף. מאזן העומסים MetalLB שכלול בחבילה דורש קישוריות לרשת Layer 2 בין הצמתים. לכן, הקישוריות בשכבה 2 בין המכונות הווירטואליות של Compute Engine מופעלת על ידי יצירת רשת שכבת-על של VxLAN על גבי רשת ברירת המחדל של הענן הווירטואלי הפרטי (VPC).
בתוך המלבן עם התווית "רשת שכבת-על L2 (VxLAN)" מוצגים רכיבי התוכנה שפועלים בתוך שלוש המכונות הווירטואליות של Compute Engine. המלבן הזה של VxLAN כולל את פריסת האשכול, שמכילה מרחב שמות של Kubernetes בתוך האשכול. כל הרכיבים במרחב השמות הזה של Kubernetes מרכיבים את אפליקציית הקופה שפריסה באשכול. לאפליקציית הקופה יש שלושה מיקרו-שירותים: שרת API, מלאי ותשלומים. כל הרכיבים האלה ביחד מייצגים "אפליקציה" אחת שמוצגת בדיאגרמת ארכיטקטורה של פריסת Edge שמופיעה למעלה.
לא ניתן להגיע ישירות למאזן העומסים של MetalLB בחבילה של האשכול מחוץ למכונות הווירטואליות. בתרשים מוצג שרת proxy הפוך של NGINX שמוגדר לפעול בתוך המכונות הווירטואליות כדי לנתב את התעבורה שנכנסת למכונות הווירטואליות של Compute Engine למאזן העומסים. זהו רק פתרון עקיף למטרות המדריך הזה, שבו צמתי הקצה מודמים באמצעות מכונות וירטואליות של Compute Engine. Google Cloudבמיקום קצה אמיתי, אפשר לעשות את זה באמצעות הגדרת רשת מתאימה.
מטרות
- שימוש במכונות וירטואליות של Compute Engine כדי לבצע אמולציה של תשתית Bare Metal שפועלת במיקום קצה.
- איך משתמשים ב-Google Distributed Cloud כדי ליצור אשכול בתשתית הקצה המדומה.
- מתחברים לאשכול ורושמים אותו ב- Google Cloud.
- פורסים עומס עבודה של אפליקציה לדוגמה לנקודת מכירה באשכול.
- משתמשים במסוף Google Cloud כדי לאמת ולנטר את אפליקציית נקודת המכירה שפועלת במיקום הקצה.
- משתמשים ב-סנכרון תצורות כדי לעדכן את אפליקציית נקודת המכירה שפועלת באשכול.
לפני שמתחילים
בדף לבחירת הפרויקט במסוף Google Cloud , בוחרים פרויקט ב- Google Cloud או יוצרים אותו.
הקפידו לוודא שהחיוב מופעל בפרויקט שלכם ב-Cloud. כך בודקים אם החיוב מופעל בפרויקט
שכפול של מאגר anthos-samples
כל הסקריפטים שמשמשים במדריך הזה מאוחסנים במאגר anthos-samples. מבנה התיקיות בנתיב /anthos-bm-edge-deployment/acm-config-sink מאורגן בהתאם למה שמצופה מ-סנכרון תצורות.
לפני שממשיכים לשלבים הבאים, צריך לשכפל את המאגר הזה לחשבון GitHub שלכם.
אם עדיין אין לכם חשבון, אתם צריכים ליצור חשבון ב-GitHub.
יוצרים אסימון גישה אישית לשימוש בהגדרת סנכרון תצורות. האימות הזה נדרש כדי שרכיבי סנכרון תצורות באשכול יוכלו לעבור אימות בחשבון GitHub שלכם כשהם מנסים לסנכרן שינויים חדשים.
- בוחרים רק את ההיקף
public_repo. - שומרים את אסימון הגישה שיצרתם במקום בטוח לשימוש מאוחר יותר.
- בוחרים רק את ההיקף
יוצרים Fork של מאגר
anthos-samplesלחשבון GitHub שלכם:- עוברים אל מאגר anthos-samples.
- לוחצים על סמל הפיצול בפינה השמאלית העליונה של הדף.
- לוחצים על חשבון המשתמש ב-GitHub שאליו רוצים ליצור Fork של המאגר. המערכת מפנה אתכם אוטומטית לדף עם הגרסה המחוברת של מאגר
anthos-samples.
פותחים טרמינל בסביבה המקומית.
משכפלים את המאגר שחובר על ידי הרצת הפקודה הבאה, כאשר GITHUB_USERNAME הוא שם המשתמש בחשבון GitHub שלכם:
git clone https://github.com/GITHUB_USERNAME/anthos-samples cd anthos-samples/anthos-bm-edge-deployment
הגדרת סביבת תחנת העבודה
כדי להשלים את הפריסה ב-Edge שמתוארת במאמר הזה, צריך תחנת עבודה אחת עם גישה לאינטרנט והכלים הבאים שמותקנים בה:
- Docker
- כלי ממשק שורת הפקודה (CLI) של envsubst (בדרך כלל מותקן מראש ב-Linux ובמערכות הפעלה אחרות דמויות Unix)
מריצים את כל הפקודות במדריך בתחנת העבודה שמגדירים בקטע הזה.
בתחנת העבודה, מאתחלים את משתני הסביבה במופע חדש של המעטפת:
export PROJECT_ID="PROJECT_ID" export REGION="us-central1" export ZONE="us-central1-a" # port on the admin Compute Engine instance you use to set up an nginx proxy # this allows to reach the workloads inside the cluster via the VM IP export PROXY_PORT="8082" # should be a multiple of 3 since N/3 clusters are created with each having 3 nodes export GCE_COUNT="3" # url to the fork of: https://github.com/GoogleCloudPlatform/anthos-samples export ROOT_REPO_URL="https://github.com/GITHUB_USERNAME/anthos-samples" # this is the username used to authenticate to your fork of this repository export SCM_TOKEN_USER="GITHUB_USERNAME" # access token created in the earlier step export SCM_TOKEN_TOKEN="ACCESS_TOKEN"מחליפים את הערכים הבאים:
- PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
- GITHUB_USERNAME: שם המשתמש שלכם ב-GitHub.
- ACCESS_TOKEN: אסימון הגישה האישי שיצרתם למאגר GitHub.
משאירים את ערכי ברירת המחדל בשאר משתני הסביבה. הן מוסברות בקטעים הבאים.
במחשב שלכם, מפעילים את Google Cloud CLI:
gcloud config set project "${PROJECT_ID}" gcloud services enable compute.googleapis.com gcloud config set compute/region "${REGION}" gcloud config set compute/zone "${ZONE}"בתחנת העבודה, יוצרים את Google Cloud חשבון השירות למכונות של Compute Engine. הסקריפט הזה יוצר את קובץ מפתח ה-JSON עבור חשבון השירות החדש בנתיב
<REPO_ROOT>/anthos-bm-edge-deployment/build-artifacts/consumer-edge-gsa.json. בנוסף, הוא מגדיר את אוסף המפתחות והמפתח של Cloud Key Management Service להצפנה של מפתח פרטי SSH../scripts/create-primary-gsa.shהדוגמה הבאה היא רק חלק מהסקריפט. כדי לראות את התסריט המלא, לוחצים על View on GitHub (צפייה ב-GitHub).
הקצאת מכונות Compute Engine
בקטע הזה, יוצרים את מכונות ה-VM ב-Compute Engine שבהן תותקן תוכנת Google Distributed Cloud בלבד. כמו כן, צריך לוודא שיש קישוריות למכונות הווירטואליות האלה לפני שממשיכים לקטע ההתקנה.
בתחנת העבודה, יוצרים מפתחות SSH שמשמשים לתקשורת בין מכונות Compute Engine:
ssh-keygen -f ./build-artifacts/consumer-edge-machineהצפנה של המפתח הפרטי של SSH באמצעות Cloud Key Management Service:
gcloud kms encrypt \ --key gdc-ssh-key \ --keyring gdc-ce-keyring \ --location global \ --plaintext-file build-artifacts/consumer-edge-machine \ --ciphertext-file build-artifacts/consumer-edge-machine.encryptedיוצרים את קובץ הגדרות הסביבה
.envrcומגדירים אותו כמקור. אחרי שיוצרים את הקובץ.envrc, בודקים אותו כדי לוודא שמשתני הסביבה הוחלפו בערכים הנכונים.envsubst < templates/envrc-template.sh > .envrc source .envrcהקובץ הבא הוא קובץ
.envrcלדוגמה שנוצר על ידי החלפת משתני הסביבה בקובץtemplates/envrc-template.sh. שימו לב שהשורות שעודכנו מודגשות:יצירת מכונות של Compute Engine:
./scripts/cloud/create-cloud-gce-baseline.sh -c "$GCE_COUNT" | \ tee ./build-artifacts/gce-info
התקנת אשכול bare metal באמצעות Ansible
הסקריפט שבו נעשה שימוש במדריך הזה יוצר אשכולות בקבוצות של שלוש מכונות ב-Compute Engine. מספר האשכולות שנוצרו נקבע על ידי משתנה הסביבה GCE_COUNT. לדוגמה, מגדירים את משתנה הסביבה GCE_COUNT לערך 6 כדי ליצור שני אשכולות עם 3 מופעים של מכונות וירטואליות בכל אחד מהם.
כברירת מחדל, משתנה הסביבה GCE_COUNT מוגדר לערך 3. לכן, במדריך הזה ייצור אשכול אחד עם 3 מכונות Compute Engine. למכונות הווירטואליות יש קידומת cnuc- ואחריה מספר. המכונה הווירטואלית הראשונה בכל אשכול משמשת כתחנת עבודה של האדמין שממנה מופעלת ההתקנה. האשכול מקבל גם את אותו שם כמו מכונת ה-VM של תחנת העבודה לאדמין (לדוגמה, cnuc-1, cnuc-4, cnuc-7).
ה-Ansible playbook מבצע את הפעולות הבאות:
- מגדיר את המכונות ב-Compute Engine עם הכלים הנדרשים, כמו
docker,bmctl,gcloudו-nomos. - הכלי מתקין אשכול Bare Metal במכונות של Compute Engine שהוגדרו.
- יוצרת אשכול עצמאי בשם
cnuc-1. - המערכת רושמת את אשכול
cnuc-1ב- Google Cloud. - סנכרון תצורות מותקן באשכול
cnuc-1. - מגדיר את סנכרון תצורות לסנכרון עם הגדרות האשכול שנמצאות בכתובת
anthos-bm-edge-deployment/acm-config-sinkבמאגר המזלג. - המערכת יוצרת את
Login tokenלאשכול.
כדי להגדיר את תהליך ההתקנה ולהתחיל אותו:
בתחנת העבודה, יוצרים את קובץ האימג' של Docker שמשמש להתקנה. בתמונה הזו מופיעים כל הכלים שנדרשים לתהליך ההתקנה, כמו Ansible, Python ו-Google Cloud CLI.
gcloud builds submit --config docker-build/cloudbuild.yaml docker-build/כשמריצים את ה-build בהצלחה, נוצר פלט כמו זה:
... latest: digest: sha256:99ded20d221a0b2bcd8edf3372c8b1f85d6c1737988b240dd28ea1291f8b151a size: 4498 DONE ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- ID CREATE_TIME DURATION SOURCE IMAGES STATUS 2238baa2-1f41-440e-a157-c65900b7666b 2022-08-17T19:28:57+00:00 6M53S gs://my_project_cloudbuild/source/1660764535.808019-69238d8c870044f0b4b2bde77a16111d.tgz gcr.io/my_project/consumer-edge-install (+1 more) SUCCESSיוצרים את קובץ המלאי של Ansible מתבנית:
envsubst < templates/inventory-cloud-example.yaml > inventory/gcp.yamlמריצים את סקריפט ההתקנה שמתחיל קונטיינר Docker מהתמונה שנוצרה קודם. הסקריפט משתמש באופן פנימי ב-Docker כדי ליצור את הקונטיינר עם טעינת נפח לספריית העבודה הנוכחית. אחרי שהסקריפט יסתיים בהצלחה, תצטרכו להיות בתוך קובץ ה-Docker שנוצר. מפעילים את ההתקנה של Ansible מתוך הקונטיינר הזה.
./install.shאם הסקריפט פועל בהצלחה, הוא יוצר פלט שדומה לזה:
... Check the values above and if correct, do you want to proceed? (y/N): y Starting the installation Pulling docker install image... ============================== Starting the docker container. You will need to run the following 2 commands (cut-copy-paste) ============================== 1: ./scripts/health-check.sh 2: ansible-playbook all-full-install.yaml -i inventory 3: Type 'exit' to exit the Docker shell after installation ============================== Thank you for using the quick helper script! (you are now inside the Docker shell)מתוך קונטיינר Docker, מאמתים את הגישה למכונות של Compute Engine:
./scripts/health-check.shאם הסקריפט פועל בהצלחה, הוא יוצר פלט שדומה לזה:
... cnuc-2 | SUCCESS => {"ansible_facts": {"discovered_interpreter_python": "/usr/bin/python3"},"changed": false,"ping": "pong"} cnuc-3 | SUCCESS => {"ansible_facts": {"discovered_interpreter_python": "/usr/bin/python3"},"changed": false,"ping": "pong"} cnuc-1 | SUCCESS => {"ansible_facts": {"discovered_interpreter_python": "/usr/bin/python3"},"changed": false,"ping": "pong"}מתוך קונטיינר Docker, מריצים את קובץ ה-playbook של Ansible כדי להתקין אשכול Bare Metal במכונות ב-Compute Engine:
בסיום, יופיע על המסך הקוד
Login Tokenשל האשכול.ansible-playbook all-full-install.yaml -i inventory | tee ./build-artifacts/ansible-run.logאם ההתקנה מסתיימת בהצלחה, נוצר פלט שדומה לזה:
... TASK [abm-login-token : Display login token] ************************************************************************** ok: [cnuc-1] => { "msg": "eyJhbGciOiJSUzI1NiIsImtpZCI6Imk2X3duZ3BzckQyWmszb09sZHFMN0FoWU9mV1kzOWNGZzMyb0x2WlMyalkifQ.eymljZS1hY2NvdW iZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZWNyZXQubmFtZSI6ImVkZ2Etc2EtdG9rZW4tc2R4MmQiLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2Nvd 4CwanGlof6s-fbu8" } skipping: [cnuc-2] skipping: [cnuc-3] PLAY RECAP *********************************************************************************************************** cnuc-1 : ok=205 changed=156 unreachable=0 failed=0 skipped=48 rescued=0 ignored=12 cnuc-2 : ok=128 changed=99 unreachable=0 failed=0 skipped=108 rescued=0 ignored=2 cnuc-3 : ok=128 changed=99 unreachable=0 failed=0 skipped=108 rescued=0 ignored=2
כניסה לאשכול במסוף Google Cloud
אחרי שקובץ ה-playbook של Ansible מופעל עד הסוף, מותקן אשכול עצמאי במכונות הווירטואליות של Compute Engine. האשכול הזה רשום גם ב-Google Cloudבאמצעות Connect Agent. עם זאת, כדי לראות פרטים על האשכול הזה, צריך להיכנס לאשכול מהמסוף Google Cloud .
כדי להתחבר לאשכול, מבצעים את השלבים הבאים:
מעתיקים את הטוקן מהפלט של Ansible playbook בקטע הקודם.
במסוף Google Cloud , עוברים לדף Kubernetes clusters ומשתמשים באסימון שהועתק כדי להיכנס לאשכול
cnuc-1.- ברשימת האשכולות, לוחצים על Actions (פעולות) לצד האשכול
cnuc-1ואז על Log in (כניסה). - בוחרים באפשרות Token (אסימון) ומדביקים את האסימון שהועתק.
- לוחצים על התחברות.
- ברשימת האשכולות, לוחצים על Actions (פעולות) לצד האשכול
- נכנסים לדף Config במסוף Google Cloud , בקטע Features.
בכרטיסייה חבילות, בודקים את העמודה סטטוס הסנכרון בטבלת האשכול.
מוודאים שהסטטוס הוא מסונכרן. הסטטוס Synced מציין ש-סנכרון תצורות סינכרן בהצלחה את ההגדרות של GitHub עם האשכול שפרסתם, cnuc-1.
הגדרת שרת proxy לתנועה חיצונית
האשכול שהותקן בשלבים הקודמים משתמש במאזן עומסים כלול שנקרא MetalLB. אפשר לגשת לשירות מאזן העומסים הזה רק דרך כתובת IP של ענן וירטואלי פרטי (VPC). כדי לנתב תנועה שמגיעה דרך כתובת ה-IP החיצונית שלה למאזן העומסים הכלול, צריך להגדיר שירות proxy הפוך במארח הניהול (cnuc-1). שירות ה-proxy ההפוך הזה מאפשר להגיע לשרת ה-API של אפליקציית נקודת המכירה דרך כתובת ה-IP החיצונית של מארח הניהול (cnuc-1).
סקריפטים ההתקנה בשלבים הקודמים התקינו את NGINX במארחי האדמין יחד עם קובץ תצורה לדוגמה. מעדכנים את הקובץ הזה כך שישתמש בכתובת ה-IP של שירות מאזן העומסים ומפעילים מחדש את NGINX.
בתחנת העבודה, משתמשים ב-SSH כדי להיכנס לתחנת העבודה של האדמין:
ssh -F ./build-artifacts/ssh-config abm-admin@cnuc-1מתוך תחנת העבודה של האדמין, מגדירים שרת proxy הפוך של NGINX כדי לנתב תנועה לשירות מאזן העומסים של שרת ה-API. קבלת כתובת ה-IP של שירות Kubernetes מסוג מאזן עומסים:
ABM_INTERNAL_IP=$(kubectl get services api-server-lb -n pos | awk '{print $4}' | tail -n 1)מעדכנים את קובץ ההגדרות של התבנית עם כתובת ה-IP שאוחזרה:
sudo sh -c "sed 's/<K8_LB_IP>/${ABM_INTERNAL_IP}/g' \ /etc/nginx/nginx.conf.template > /etc/nginx/nginx.conf"מפעילים מחדש את NGINX כדי לוודא שההגדרה החדשה הופעלה:
sudo systemctl restart nginxבודקים ומאמתים את הסטטוס של שרת NGINX בדוחות 'פעיל' (פועל):
sudo systemctl status nginxאם NGINX פועל בצורה תקינה, הוא יפיק פלט שדומה לדוגמה הבאה:
● nginx.service - A high performance web server and a reverse proxy server Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled) Active: active (running) since Fri 2021-09-17 02:41:01 UTC; 2s ago Docs: man:nginx(8) Process: 92571 ExecStartPre=/usr/sbin/nginx -t -q -g daemon on; master_process on; (code=exited, status=0/SUCCESS) Process: 92572 ExecStart=/usr/sbin/nginx -g daemon on; master_process on; (code=exited, status=0/SUCCESS) Main PID: 92573 (nginx) Tasks: 17 (limit: 72331) Memory: 13.2M CGroup: /system.slice/nginx.service ├─92573 nginx: master process /usr/sbin/nginx -g daemon on; master_process on; ├─92574 nginx: worker process ├─92575 nginx: worker process ├─92577 nginx: .... ... ...יוצאים מהסשן של SSH אל תחנת העבודה של האדמין:
exitיוצאים מסשן המעטפת אל קונטיינר Docker. אחרי שיוצאים ממופע האדמין, עדיין נמצאים בתוך קובץ ה-Docker שמשמש להתקנה:
exit
גישה לאפליקציה של נקודת המכירה
ההגדרה של שרת proxy חיצוני מאפשרת לכם לגשת לאפליקציה שפועלת בתוך האשכול. כדי לגשת לאפליקציה לדוגמה של נקודת מכירה, מבצעים את השלבים הבאים.
בתחנת העבודה, בודקים מהי כתובת ה-IP החיצונית של מופע Compute Engine של האדמין וניגשים לממשק המשתמש של אפליקציית הקופה:
EXTERNAL_IP=$(gcloud compute instances list \ --project ${PROJECT_ID} \ --filter="name:cnuc-1" \ --format="get(networkInterfaces[0].accessConfigs[0].natIP)") echo "Point the browser to: ${EXTERNAL_IP}:${PROXY_PORT}"אם הסקריפטים יפעלו בהצלחה, הם יפיקו פלט כמו זה:
Point the browser to: 34.134.194.84:8082פותחים את דפדפן האינטרנט ועוברים לכתובת ה-IP שמוצגת בפלט של הפקודה הקודמת. אפשר לגשת לאפליקציה לדוגמה של נקודת מכירה ולבדוק אותה, כמו שמוצג בצילום המסך הבא:
שימוש ב-Config Sync לעדכון שרת ה-API
כדי לשדרג את האפליקציה לדוגמה לגרסה חדשה יותר, צריך לעדכן את קובצי ההגדרות במאגר השורש. סנכרון תצורות מזהה את העדכונים ומבצע את השינויים באשכול באופן אוטומטי. בדוגמה הזו, מאגר הבסיס הוא מאגר anthos-samples ששיבטתם בתחילת המדריך הזה. כדי לראות איך אפליקציה לדוגמה לנקודת מכירה יכולה לעבור פריסת שדרוג לגרסה חדשה יותר, צריך לבצע את השלבים הבאים.
בתחנת העבודה, מעדכנים את השדה
imageכדי לשנות את גרסת שרת ה-API מ-v1ל-v2. הגדרת ה-YAML לפריסה נמצאת בקובץ בנתיבanthos-bm-edge-deployment/acm-config-sink/namespaces/pos/api-server.yaml.מוסיפים, שומרים ודוחפים את השינויים למאגר המפוצל:
git add acm-config-sink/namespaces/pos/api-server.yaml git commit -m "chore: updated api-server version to v2" git pushבמסוף Google Cloud , נכנסים לדף סנכרון תצורות כדי לבדוק את Config spec status. מוודאים שהסטטוס הוא מסונכרן.
במסוף Google Cloud , עוברים לדף Kubernetes Engine Workloads כדי לוודא שהפריסה עודכנה.
כשהסטטוס של הפריסה הוא OK, פותחים את כתובת ה-IP מהקטע הקודם בדפדפן כדי לראות את אפליקציית נקודת המכירה. שימו לב שבגרסה בכותרת מופיע V2, שמציין שהשינוי באפליקציה נפרס, כמו שמוצג בצילום המסך הבא:
יכול להיות שתצטרכו לבצע רענון מלא של כרטיסיית הדפדפן כדי לראות את השינויים.
הסרת המשאבים
כדי להימנע מחיובים מיותרים, מומלץ למחוק את המשאבים שבהם השתמשתם במדריך הזה אחרי שתסיימו לעבוד איתו. Google Cloud אפשר למחוק את המשאבים האלה באופן ידני, או למחוק את הפרויקט ב- Google Cloud , וכך למחוק את כל המשאבים. בנוסף, כדאי גם לנקות את השינויים שבוצעו בתחנת העבודה המקומית:
תחנת עבודה מקומית
צריך לעדכן את הקבצים הבאים כדי לבטל את השינויים שבוצעו על ידי סקריפטים להתקנה.
- מסירים את כתובות ה-IP של המכונות הווירטואליות ב-Compute Engine שהוספתם לקובץ
/etc/hosts. - מסירים את הגדרת ה-SSH של
cnuc-*בקובץ~/.ssh/config. - מסירים את טביעות האצבע של המכונה הווירטואלית ב-Compute Engine מהקובץ
~/.ssh/known_hosts.
מחיקת הפרויקט
אם יצרתם פרויקט ייעודי בשביל התהליך הזה, צריך למחוק את הפרויקט מהמסוף.
Google Cloud Google Cloud
גלילה ידנית
אם השתמשתם בפרויקט קיים כדי לבצע את התהליך הזה, תצטרכו לבצע את הפעולות הבאות:
- ביטול הרישום של כל אשכולות Kubernetes עם שם שמתחיל ב-
cnuc-. - מחיקה של כל המכונות הווירטואליות ב-Compute Engine ששמן מתחיל בקידומת
cnuc-. - מוחקים את הקטגוריה של Cloud Storage עם שם שמתחיל בקידומת
abm-edge-boot. - מוחקים את כללי חומת האש
allow-pod-ingressו-allow-pod-egress. - מחיקת הסוד
install-pub-keyב-Secret Manager.
מה השלב הבא?
אפשר להרחיב את המדריך הזה על ידי הוספה של מיקום קצה נוסף. הגדרת משתנה הסביבה GCE_COUNT לערך 6 והרצה מחדש של אותם השלבים מהקטעים הקודמים יוצרת שלוש מכונות Compute Engine חדשות (cnuc-4, cnuc-5, cnuc-6) ואשכול חדש ועצמאי בשם cnuc-4.
אפשר גם לנסות לעדכן את ההגדרות של האשכולות במאגר המזלג כדי להחיל באופן סלקטיבי גרסאות שונות של אפליקציית נקודת המכירה על שני האשכולות, cnuc-1 ו-cnuc-4, באמצעות ClusterSelectors.
פרטים על השלבים השונים במדריך הזה ועל הסקריפטים שמשתתפים בתהליך זמינים במאגר anthos-samples.