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

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

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

ארכיטקטורת פריסה של 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 הוא מאזן העומסים שכלול בחבילה.

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

  • מאגר הבסיס ומאגר מרחב השמות שמוצגים בחלק העליון של הדיאגרמה מחוץ למיקום החנות מייצגים שני מאגרי מקור.

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

  • רכיב מפתח נוסף שמוצג כחלק מהאשכול הוא VM Runtime ב-GDC. ‫VM Runtime ב-GDC מאפשר להריץ עומסי עבודה קיימים שמבוססים על מכונות וירטואליות בתוך האשכול, בלי צורך ביצירת קונטיינרים. במסמכי התיעוד של VM Runtime ב-GDC מוסבר איך להפעיל אותו ולפרוס את עומסי העבודה של המכונות הווירטואליות באשכול.

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

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

בקטע הבא מוצגת הדמיה של פריסת חנות קמעונאית כזו ב-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 שמצורף לחבילה דורש קישוריות לרשת Layer 2 בין הצמתים. לכן, הקישוריות בשכבה 2 בין המכונות הווירטואליות של Compute Engine מופעלת על ידי יצירת רשת שכבת-על של VxLAN על גבי רשת ברירת המחדל של הענן הווירטואלי הפרטי (VPC).

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

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

מטרות

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

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

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

    כניסה לדף לבחירת הפרויקט

  2. הקפידו לוודא שהחיוב מופעל בפרויקט שלכם ב-Cloud. כך בודקים אם החיוב מופעל בפרויקט

  3. מתקינים ומפעילים את Google Cloud CLI.

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

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

  1. אם עדיין אין לכם חשבון, אתם צריכים ליצור חשבון ב-GitHub.

  2. יוצרים אסימון גישה אישית לשימוש בהגדרת סנכרון תצורות. האימות הזה נדרש כדי שרכיבי סנכרון תצורות באשכול יוכלו לעבור אימות בחשבון GitHub שלכם כשמנסים לסנכרן שינויים חדשים.

    1. בוחרים רק את ההיקף public_repo.
    2. שומרים את אסימון הגישה שנוצר במקום בטוח לשימוש מאוחר יותר.

  3. יוצרים Fork של מאגר anthos-samples לחשבון GitHub שלכם:

    1. עוברים אל מאגר anthos-samples.
    2. לוחצים על סמל הפיצול בפינה השמאלית העליונה של הדף.
    3. לוחצים על חשבון המשתמש ב-GitHub שאליו רוצים ליצור Fork של המאגר. אתם מופנים אוטומטית לדף עם הגרסה המחוברת של מאגר anthos-samples.

  4. פותחים טרמינל בסביבה המקומית.

  5. משכפלים את המאגר שחובר על ידי הרצת הפקודה הבאה, כש-GITHUB_USERNAME הוא שם המשתמש בחשבון GitHub שלכם:

    git clone https://github.com/GITHUB_USERNAME/anthos-samples
cd anthos-samples/anthos-bm-edge-deployment

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

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

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

  1. בתחנת העבודה, מאתחלים את משתני הסביבה במופע חדש של מעטפת:

    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.

    משאירים את ערכי ברירת המחדל של שאר משתני הסביבה. הן מוסברות בקטעים הבאים.

  2. בתחנת העבודה שלכם, מפעילים את 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}"

  3. בתחנת העבודה, יוצרים את 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).

    # ...
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

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

  1. בתחנת העבודה, יוצרים מפתחות SSH שמשמשים לתקשורת בין מכונות Compute Engine:

    ssh-keygen -f ./build-artifacts/consumer-edge-machine

  2. הצפנה של המפתח הפרטי של 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

  3. יוצרים את קובץ תצורת הסביבה .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

  4. יצירת מכונות של 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).

קובץ ה-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 לאשכול.

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

  1. בתחנת העבודה שלכם, יוצרים את קובץ האימג' של 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

  2. יוצרים את קובץ המלאי של Ansible מתבנית:

    envsubst < templates/inventory-cloud-example.yaml > inventory/gcp.yaml

  3. מריצים את סקריפט ההתקנה שמתחיל קונטיינר 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)

  4. מתוך קונטיינר 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"}

  5. מתוך קונטיינר 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

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

כדי להיכנס לאשכול, מבצעים את השלבים הבאים:

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

  2. במסוף Google Cloud , עוברים לדף Kubernetes clusters ומשתמשים באסימון שהועתק כדי להיכנס לאשכול cnuc-1.

    כניסה לדף Kubernetes clusters

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

    מעבר אל Config

    4. בכרטיסייה חבילות, בודקים את העמודה סטטוס הסנכרון בטבלת האשכול. מוודאים שהסטטוס הוא מסונכרן. הסטטוס Synced (מסונכרן) מציין ש-סנכרון תצורות סינכרן בהצלחה את ההגדרות שלכם ב-GitHub עם האשכול שפרסתם, cnuc-1.

s

הגדרת שרת proxy לתנועה חיצונית

האשכול שהותקן בשלבים הקודמים משתמש במאזן עומסים כלול שנקרא MetalLB. אפשר לגשת לשירות מאזן העומסים הזה רק דרך כתובת IP של ענן וירטואלי פרטי (VPC). כדי לנתב תנועה שמגיעה דרך כתובת ה-IP החיצונית שלה למאזן העומסים בחבילה, צריך להגדיר שירות proxy הפוך במארח האדמין (cnuc-1). שירות ה-proxy ההפוך הזה מאפשר להגיע לשרת ה-API של אפליקציית נקודת המכירה דרך כתובת ה-IP החיצונית של מארח האדמין (cnuc-1).

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

  1. בתחנת העבודה, משתמשים ב-SSH כדי להיכנס לתחנת העבודה של האדמין:

    ssh -F ./build-artifacts/ssh-config abm-admin@cnuc-1

  2. מתוך תחנת העבודה של האדמין, מגדירים שרת proxy הפוך של NGINX כדי לנתב תנועה לשירות מאזן העומסים של שרת ה-API. קבלת כתובת ה-IP של שירות Kubernetes מסוג מאזן עומסים:

    ABM_INTERNAL_IP=$(kubectl get services api-server-lb -n pos | awk '{print $4}' | tail -n 1)

  3. מעדכנים את קובץ התצורה של התבנית עם כתובת ה-IP שאוחזרה:

    sudo sh -c "sed 's/<K8_LB_IP>/${ABM_INTERNAL_IP}/g' \
    /etc/nginx/nginx.conf.template > /etc/nginx/nginx.conf"

  4. מפעילים מחדש את NGINX כדי לוודא שההגדרה החדשה הופעלה:

    sudo systemctl restart nginx

  5. בודקים ומאמתים את הסטטוס של שרת 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: ....
            ...
            ...

  6. כדי לצאת מהסשן של SSH אל תחנת העבודה של האדמין:

    exit

  7. יוצאים מסשן ה-Shell אל קונטיינר Docker. אחרי שיוצאים ממופע האדמין, עדיין נמצאים בתוך קובץ האימג' של Docker שמשמש להתקנה:

    exit

גישה לאפליקציה של נקודת המכירה

ההגדרה של שרת proxy חיצוני מאפשרת לכם לגשת לאפליקציה שפועלת בתוך האשכול. כדי לגשת לאפליקציה לדוגמה של נקודת מכירה, מבצעים את השלבים הבאים.

  1. בתחנת העבודה, בודקים מהי כתובת ה-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

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

    גרסה 1 של אפליקציית נקודת המכירה (POS) שנפרסה

שימוש ב-Config Sync לעדכון שרת ה-API

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

  1. בתחנת העבודה, מעדכנים את השדה 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

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

    git add acm-config-sink/namespaces/pos/api-server.yaml
git commit -m "chore: updated api-server version to v2"
git push

  3. במסוף Google Cloud , נכנסים לדף סנכרון תצורות כדי לבדוק את Config spec status. מוודאים שהסטטוס הוא מסונכרן.

    מעבר לדף סנכרון תצורות

  4. במסוף Google Cloud , עוברים לדף Kubernetes Engine Workloads כדי לוודא שהפריסה עודכנה.

    מעבר לדף Kubernetes Engine Workloads

  5. כשהסטטוס של הפריסה הוא OK, מצביעים בדפדפן על כתובת ה-IP מהקטע הקודם כדי לראות את אפליקציית הקופה. שימו לב שבגרסה בכותרת מופיע V2, שמציין שהשינוי באפליקציה נפרס, כמו שמוצג בצילום המסך הבא:

    גרסה 2 של אפליקציית נקודת המכירה שנפרסה

    יכול להיות שתצטרכו לבצע רענון מלא של כרטיסיית הדפדפן כדי לראות את השינויים.

הסרת המשאבים

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

תחנת עבודה מקומית

צריך לעדכן את הקבצים הבאים כדי לבטל את השינויים שבוצעו על ידי סקריפטים של התקנה.

  • מסירים את כתובות ה-IP של המכונות הווירטואליות ב-Compute Engine שהוספו לקובץ /etc/hosts.
  • מסירים את הגדרת ה-SSH של cnuc-* בקובץ ~/.ssh/config.
  • מסירים את טביעות האצבע של המכונה הווירטואלית ב-Compute Engine מהקובץ ~/.ssh/known_hosts.

מחיקת הפרויקט

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

  • In the Google Cloud console, go to the Manage resources page.

    Go to Manage resources

  • In the project list, select the project that you want to delete, and then click Delete.
  • In the dialog, type the project ID, and then click Shut down to delete the project.

    • גלילה ידנית

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

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