‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

פריסת אשכולות בקצה הרשת

שילוב של תוכנת Distributed Cloud ל-bare metal בלבד עם סנכרון תצורות מאפשר לפרוס ולנהל אשכולות Kubernetes בקצה (edge) בקנה מידה נרחב ממיקום מרכזי. סנכרון תצורות שולף באופן דינמי הגדרות מ-GitHub ומחיל את כללי המדיניות האלה באופן אוטומטי על כל האשכולות. במדריך הזה, שמיועד למפעילי פלטפורמות ולמפתחים, תשתמשו במכונות וירטואליות (VM) של Compute Engine כדי לדמות צומתי קצה שמריצים עומס עבודה לדוגמה של נקודת מכירה.

לפני שמתחילים, חשוב להכיר את Google Cloud פרויקטים, gcloud ו-kubectl ממשקי CLI, אתגרים בפריסה בקצה, Ansible playbooks, ופריסה של אפליקציות אינטרנט בקונטיינרים.

ארכיטקטורת פריסה בקצה (edge)

פריסה של קצה (edge) קמעונאי היא דרך טובה להמחיש את הארכיטקטורה שמשמשת בפריסה אופיינית של אשכול Bare Metal.

חנות קמעונאית פיזית היא נקודת האינטראקציה הקרובה ביותר בין היחידה העסקית של הארגון לבין הצרכן. מערכות התוכנה בתוך החנויות צריכות להריץ את עומסי העבודה שלהן, לקבל עדכונים בזמן ולדווח על מדדים קריטיים בנפרד ממערכת הניהול המרכזית של הארגון. בנוסף, צריך לתכנן את מערכות התוכנה האלה כך שיהיה אפשר להרחיב אותן למיקומים נוספים של חנויות בעתיד. כל פריסה של אשכול Bare Metal עונה על כל הדרישות האלה למערכות תוכנה של חנויות, אבל פרופיל הקצה מאפשר תרחיש שימוש חשוב: פריסות בסביבות עם משאבי חומרה מוגבלים, כמו חזית של חנות קמעונאית.

בתרשים הבא מוצגת פריסה של אשכול Bare Metal שמשתמש בפרופיל הקצה בחנות קמעונאית:

פריסה שמשתמשת בפרופיל Edge בחנות קמעונאית

התרשים שלמעלה מציג חנות פיזית אופיינית. בחנות יש מכשירים חכמים כמו קוראי כרטיסים, מכונות בנקודות מכירה, מצלמות ומדפסות. בחנות יש גם שלושה מכשירים פיזיים של חומרת מחשוב (שמסומנים בתוויות Node 1, Node 2 ו-Node 3). כל המכשירים האלה מחוברים למתג רשת מרכזי. כך, שלושת מכשירי המחשוב מחוברים זה לזה דרך רשת Layer 2. מכשירי המחשוב שמחוברים יחד ברשת מרכיבים את התשתית של השרת הפיזי. תוכנת Google Distributed Cloud פועלת בכל אחד משלושת מכשירי המחשוב. למכשירים האלה יש גם אחסון בדיסק משלהם, והם מוגדרים לשכפול נתונים ביניהם כדי ליצור זמינות גבוהה.

בתרשים מוצגים גם הרכיבים העיקריים הבאים, שהם חלק מפריסת אשכול Bare Metal:

הרכיב שמסומן כ-MetalLB הוא מאזן העומסים בחבילה.
הרכיב "סנכרון תצורות" מאפשר לסנכרן את מצב האשכול עם מאגרי המקור. זהו תוסף אופציונלי מומלץ מאוד שדורש התקנה והגדרה נפרדות. מידע נוסף על הגדרת סנכרון ההגדרות ועל המינוחים השונים מופיע במסמכי התיעוד של סנכרון ההגדרות.
מאגר הבסיס ומאגר מרחב השמות שמוצגים בחלק העליון של הדיאגרמה מחוץ לתוסף המפה מייצגים שני מאגרי מקור.

השינויים באשכול נשלחים למאגרי המקור המרכזיים האלה. פריסות של אשכולות במיקומים שונים בקצה הרשת שולפות עדכונים ממאגרי המקור. ההתנהגות הזו מיוצגת על ידי החיצים שמחברים בין שני המאגרים בתרשים לבין רכיבי Config Sync בתוך האשכול שפועל במכשירים.
רכיב חשוב נוסף שמוצג כחלק מהאשכול הוא VM Runtime on GDC. סביבת זמן הריצה של VM ב-GDC מאפשרת להריץ עומסי עבודה קיימים שמבוססים על VM בתוך האשכול, בלי צורך בקונטיינריזציה. במסמכי התיעוד של סביבת זמן הריצה של VM ב-GDC מוסבר איך להפעיל אותה ולפרוס את עומסי העבודה של המכונות הווירטואליות באשכול.
הרכיב שמסומן כ-Application מייצג תוכנה שנפרסה באשכול על ידי החנות הקמעונאית. דוגמה לאפליקציה כזו היא אפליקציה של נקודת מכירה שמוצגת בקיוסקים של חנות קמעונאית.

התיבות בתחתית הדיאגרמה מייצגות את המכשירים הרבים (כמו קיוסקים, טאבלטים או מצלמות) בתוך חנות קמעונאית, שכולם מחוברים למתג רשת מרכזי. הרשת המקומית בתוך החנות מאפשרת לאפליקציות שפועלות בתוך האשכול להגיע למכשירים האלה.

בקטע הבא מוצגת הדמיה של פריסת החנות הקמעונאית ב-Google Cloud באמצעות מכונות וירטואליות של Compute Engine. ההדמיה הזו היא מה שמשמש אתכם במדריך הבא כדי להתנסות באשכול Bare Metal.

פריסת קצה (edge) מדומה ב- Google Cloud

בתרשים הבא מוצג כל מה שמגדירים ב-Google Cloud במדריך הזה. התרשים הזה תואם לתרשים של החנות הקמעונאית מהקטע הקודם. הפריסה הזו מייצגת מיקום קצה מדומה שבו נפרסת אפליקציית נקודת המכירה. בארכיטקטורה מוצג גם עומס עבודה של אפליקציה לדוגמה של נקודת מכירה, שבה תשתמשו במדריך הזה. אתם ניגשים לאפליקציית נקודת המכירה בתוך האשכול באמצעות דפדפן אינטרנט כקיוסק.

הארכיטקטורה של אפליקציית נקודת המכירה והפריסה שלה בתוך אשכול שפועל במכונות וירטואליות של Compute Engine

שלוש המכונות הווירטואליות (VM) של Compute Engine בתרשים שלמעלה מייצגות את החומרה הפיזית (או הצמתים) במיקום קצה אופייני. החומרה הזו תחובר יחד עם מתגי רשת כדי ליצור את תשתית ה-bare metal. בסביבה המדומה שלנו ב- Google Cloud, המכונות הווירטואליות האלה מחוברות זו לזו דרך רשת ברירת המחדל של הענן הווירטואלי הפרטי (VPC) בפרויקט ב- Google Cloud .

בהתקנה אופיינית של אשכול Bare Metal, אתם יכולים להגדיר מאזני עומסים משלכם. עם זאת, במדריך הזה לא מגדירים מאזן עומסים חיצוני. במקום זאת, אתם משתמשים במאזן העומסים המצורף של MetalLB. מגדיר העומסים המצורף MetalLB דורש קישוריות רשת של שכבה 2 בין הצמתים. לכן, הקישוריות של שכבה 2 בין המכונות הווירטואליות של Compute Engine מופעלת על ידי יצירת רשת שכבת-על (overlay) של VxLAN מעל רשת ברירת המחדל של הענן הווירטואלי הפרטי (VPC).

בתוך המלבן שמסומן בתווית "L2 overlay network (VxLAN)" מוצגים רכיבי התוכנה שפועלים בתוך שלוש המכונות הווירטואליות של Compute Engine. המלבן של VxLAN כולל את פריסת האשכול, שמכילה מרחב שמות של Kubernetes בתוך האשכול. כל הרכיבים במרחב השמות הזה של Kubernetes מרכיבים את אפליקציית נקודת המכירה שנפרסה באשכול. לאפליקציה של נקודת המכירה יש שלושה מיקרו-שירותים: שרת API, מלאי ותשלומים. כל הרכיבים האלה ביחד מייצגים "אפליקציה" אחת שמוצגת בתרשים הארכיטקטורה הקודם של פריסת Edge.

אי אפשר להגיע ישירות למאזן העומסים המובנה MetalLB של האשכול מחוץ למכונות הווירטואליות. בתרשים מוצג שרת proxy הפוך של NGINX שמוגדר לפעול בתוך המכונות הווירטואליות, כדי לנתב את התנועה שנכנסת למכונות הווירטואליות של Compute Engine אל מאזן העומסים. זהו רק פתרון עקיף למטרות של המדריך הזה, שבו צומתי הקצה מדומים באמצעות מכונות וירטואליות של Google CloudCompute Engine. במיקום קצה אמיתי, אפשר לעשות את זה באמצעות הגדרת רשת מתאימה.

מטרות

שימוש במכונות וירטואליות של Compute Engine כדי לדמות תשתית Bare Metal שפועלת במיקום קצה.
משתמשים ב-Google Distributed Cloud כדי ליצור אשכול בתשתית המדומה של הקצה.
מחברים את האשכול ורושמים אותו ב- Google Cloud.
פורסים באשכול עומס עבודה לדוגמה של אפליקציית נקודת מכירה.
משתמשים במסוף Google Cloud כדי לאמת ולנטר את אפליקציית נקודת המכירה שפועלת במיקום הקצה.
משתמשים בסנכרון תצורות כדי לעדכן את אפליקציית נקודת המכירה שפועלת באשכול.

לפני שמתחילים

בדף לבחירת הפרויקט במסוף Google Cloud , בוחרים פרויקט ב- Google Cloud או יוצרים אותו.

הערה: אם אתם לא מתכננים לשמור את המשאבים שתיצרו בתהליך הזה, תוכלו ליצור פרויקט חדש במקום לבחור באחד מהפרויקטים הקיימים. בסיום התהליך תוכלו למחוק את הפרויקט ולהסיר את כל המשאבים שקשורים אליו.

כניסה לדף לבחירת הפרויקט
הקפידו לוודא שהחיוב מופעל בפרויקט שלכם ב-Cloud. כך בודקים אם החיוב מופעל בפרויקט
מתקינים ומפעילים את Google Cloud CLI.

פיצול ושכפול של המאגר anthos-samples

כל הסקריפטים שבהם משתמשים במדריך הזה מאוחסנים במאגר anthos-samples. מבנה התיקיות ב-/anthos-bm-edge-deployment/acm-config-sink מאורגן לפי מה שנדרש לסנכרון ההגדרות. לפני שממשיכים לשלבים הבאים, צריך לשכפל את המאגר הזה לחשבון GitHub שלכם.

אם עדיין אין לכם חשבון, אתם צריכים ליצור חשבון ב-GitHub.
יוצרים אסימון גישה אישי לשימוש בהגדרות של סנכרון תצורות. הפעולה הזו נדרשת כדי שרכיבי סנכרון ההגדרות באשכול יאמתו את חשבון GitHub כשמנסים לסנכרן שינויים חדשים.
1. בוחרים רק את ההיקף public_repo.
2. שומרים את טוקן הגישה שיצרתם במקום בטוח לשימוש מאוחר יותר.
מפצלים את המאגר anthos-samples לחשבון GitHub שלכם:
1. נכנסים למאגר anthos-samples.
2. לוחצים על הסמל Fork בפינה הימנית העליונה של הדף.
3. לוחצים על חשבון המשתמש ב-GitHub שאליו רוצים להעתיק את המאגר. המערכת תפנה אתכם אוטומטית לדף עם הגרסה המחוברת של המאגר anthos-samples.
פותחים טרמינל בסביבה המקומית.
משכפלים את המאגר שחובר באמצעות הפקודה הבאה, כאשר GITHUB_USERNAME הוא שם המשתמש של חשבון GitHub שלכם:
```
git clone https://github.com/GITHUB_USERNAME/anthos-samples
cd anthos-samples/anthos-bm-edge-deployment
```
הערה: גם מאגר המקור של הפתרון הזה וגם ה-fork שלכם של המאגר הזה הם מאגרים ציבוריים. במסמך הזה מוסבר איך להשתמש בטוקן גישה כדי לדמות תרחיש לדוגמה בפועל עם מאגר פרטי.

הגדרת סביבת העבודה

כדי להשלים את הפריסה בקצה שמתוארת במאמר הזה, צריך תחנת עבודה אחת עם גישה לאינטרנט, שמותקנים בה הכלים הבאים:

Docker
כלי ממשק שורת הפקודה 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.

# ...
EXISTS=$(gcloud iam service-accounts list \
  --filter="email=${GSA_EMAIL}" \
  --format="value(name, disabled)" \
  --project="${PROJECT_ID}")

if [[ -z "${EXISTS}" ]]; then
  echo "GSA [${GSA_EMAIL}]does not exist, creating it"

  # GSA does NOT exist, create
  gcloud iam service-accounts create ${GSA_NAME} \
    --description="GSA used on each Target machine to make gcloud commands" \
    --display-name="target-machine-gsa" \
    --project "${PROJECT_ID}"
else
  if [[ "${EXISTS}" =~ .*"disabled".* ]]; then
    # Found GSA is disabled, enable
    gcloud iam service-accounts enable "${GSA_EMAIL}" --project "${PROJECT_ID}"
  fi
  # otherwise, no need to do anything
fi
# ...

הקצאת המכונות של Compute Engine

בקטע הזה, יוצרים את המכונות הווירטואליות ב-Compute Engine שבהן תותקן רק התוכנה של 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. שימו לב שהשורות שעודכנו מודגשות:

# GSA Key used for provisioning (result of running ./scripts/create-primary-gsa.sh)
LOCAL_GSA_FILE=$(pwd)/build-artifacts/consumer-edge-gsa.json
export LOCAL_GSA_FILE
# GCP Project ID
export PROJECT_ID="abm-edge-project"
# Bucket to store cluster snapshot information
export SNAPSHOT_GCS="abm-edge-project-cluster-snapshots"

# GCP Project Region (Adjust as desired)
export REGION="us-central1"
# GCP Project Zone (Adjust as desired)
export ZONE="us-central1-a"

# Gitlab Personal Access Token credentials (generated in Quick Start step 2)
export SCM_TOKEN_USER="LarryPage"
export SCM_TOKEN_TOKEN="oo901Sp-FHuzmz__dgl0393atkf69c8L"

# Default Root Repo setup for multiple locations
export ROOT_REPO_URL="https://github.com/LarryPage/anthos-samples"
export ROOT_REPO_BRANCH="main"
export ROOT_REPO_DIR="/anthos-bm-edge-deployment/acm-config-sink"

# OIDC Configuration (off by default)
export OIDC_CLIENT_ID="" # Optional, requires GCP API setup work
export OIDC_CLIENT_SECRET="" # Optional
export OIDC_USER="" # Optional
export OIDC_ENABLED="false" # Flip to true IF implementing OIDC on cluster

יצירת מכונות של Compute Engine:

./scripts/cloud/create-cloud-gce-baseline.sh -c "$GCE_COUNT" | \
    tee ./build-artifacts/gce-info

התקנת אשכול בשרת פיזי באמצעות Ansible

הסקריפט שמשמש במדריך הזה יוצר אשכולות בקבוצות של שלוש מכונות וירטואליות ב-Compute Engine. מספר האשכולות שנוצרים נשלט על ידי משתנה הסביבה GCE_COUNT. לדוגמה, אתם מגדירים את משתנה הסביבה GCE_COUNT ל-6 כדי ליצור שני אשכולות עם 3 מכונות וירטואליות בכל אחד. כברירת מחדל, משתנה הסביבה GCE_COUNT מוגדר לערך 3. לכן, במדריך הזה ניצור אשכול אחד עם 3 מכונות של Compute Engine. השמות של המכונות הווירטואליות מתחילים בתחילית cnuc- ואחריה מספר. המכונה הווירטואלית הראשונה בכל אשכול משמשת כתחנת עבודה של אדמין, שממנה מופעלת ההתקנה. לאשכול ניתן גם שם זהה לזה של ה-VM של תחנת העבודה של האדמין (לדוגמה, cnuc-1, ‏ cnuc-4, ‏ cnuc-7).

ה-playbook של Ansible מבצע את הפעולות הבאות:

מגדיר את המכונות של 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, מריצים את Ansible playbook כדי להתקין אשכול 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 .

אחרי שה-Ansible playbook יסיים לפעול, יותקן אשכול עצמאי בתוך המכונות הווירטואליות של Compute Engine. האשכול הזה רשום גם ב-Google Cloudבאמצעות Connect Agent. עם זאת, כדי לראות פרטים על האשכול הזה, צריך להתחבר לאשכול ממסוף Google Cloud .

כדי להתחבר לאשכול:

מעתיקים את האסימון מהפלט של Ansible playbook מהקטע הקודם.

הערה: אם אין לכם יותר גישה לפלט של המסוף, תוכלו לבדוק את קובץ היומן ב-./build-artifacts/ansible-run.log כדי לקבל את הטוקן. אפשר גם להריץ את מדריך Ansible הבא כדי לאחזר שוב את האסימון: ansible-playbook all-get-login-tokens.yaml -i inventory
במסוף Google Cloud , נכנסים לדף Kubernetes clusters ומשתמשים בטוקן שהועתק כדי להיכנס לאשכול cnuc-1.

כניסה לדף Kubernetes clusters
1. ברשימת האשכולות, לוחצים על Actions ליד האשכול cnuc-1 ואז על Log in.
2. בוחרים באפשרות Token (אסימון) ומדביקים את האסימון שהועתק.
3. לוחצים על Login (התחברות).
במסוף Google Cloud , נכנסים לדף Config בקטע Features.

מעבר להגדרות

בכרטיסייה חבילות, בודקים את העמודה סטטוס הסנכרון בטבלת האשכולות. מוודאים שהסטטוס הוא Synced (מסונכרן). הסטטוס 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 הוא active (running):

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.
```
containers:
- name: api-server
  image: us-docker.pkg.dev/anthos-dpe-abm-edge-pos/abm-edge-pos-images/api-server:v1
```

מוסיפים, שומרים ודוחפים את השינויים למאגר המפוצל:

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. מוודאים שהסטטוס הוא Synced (מסונכרן).

כניסה לדף Config Sync
במסוף Google Cloud , נכנסים לדף Kubernetes Engine Workloads כדי לוודא שה-Deployment עודכן.

כניסה לדף Kubernetes Engine Workloads
כשהסטטוס של Deployment הוא 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 .

זהירות: כשמוחקים פרויקט:

התוכן של הפרויקט נמחק כולו. אם השתמשתם בפרויקט קיים כדי לתרגל את המשימות במדריך הזה, כשתמחקו אותו תימחק גם כל העבודה שביצעתם באותו פרויקט.
מאבדים את מזהה הפרויקט בהתאמה אישית. כשיצרתם את הפרויקט, יכולתם לבחור לו מזהה פרויקט בהתאמה אישית כדי להשתמש בו בעתיד. כדי לשמור על כתובות ה-URL שמשתמשות במזהה הפרויקט, כמו appspot.com, צריך למחוק את המשאבים שנבחרו בפרויקט אבל לא את הפרויקט כולו.

אם אתם מתכננים להיעזר בכמה ארכיטקטורות, מדריכים או מדריכים למתחילים, מומלץ להשתמש שוב באותו פרויקט כדי לא לחרוג ממכסות הפרויקטים.

במסוף Google Cloud , נכנסים לדף Manage resources.

כניסה לדף Manage resources

ברשימת הפרויקטים, בוחרים את הפרויקט שרוצים למחוק ולוחצים על Delete.

כדי למחוק את הפרויקט, כותבים את מזהה הפרויקט בתיבת הדו-שיח ולוחצים על Shut down.

גלילה ידנית

אם השתמשתם בפרויקט קיים, בצעו את הפעולות הבאות:

ביטול הרישום של כל אשכולות 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.