תוכנית לימודים: שינוי אפליקציה מונוליטית לאפליקציית GKE – יצירת קונטיינר לאפליקציה המודולרית

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

תוכנית הלימודים כוללת את המדריכים הבאים:

  1. סקירה כללית
  2. הסבר על המונולית
  3. הפיכת המונוליט למודולרי
  4. הכנת האפליקציה המודולרית להעברה לקונטיינר
  5. העברת האפליקציה המודולרית לקונטיינר (המדריך הזה)
  6. פריסת האפליקציה באשכול GKE

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

עלויות

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

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

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

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

מגדירים את הסביבה

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

  1. בחירה או יצירה של Google Cloud פרויקט
  2. הפעלת ממשקי ה-API הנדרשים
  3. חיבור Cloud Shell ל Google Cloud פרויקט
  4. הגדרת משתני הסביבה שמוגדרים כברירת מחדל
  5. יצירת מאגר ב-Artifact Registry
  6. הגדרת Docker ל-Artifact Registry
  7. קבלת קוד המדריך

בוחרים או יוצרים Google Cloud פרויקט

  1. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Roles required to select or create a project

    • Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
    • Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

    Go to project selector

  2. Verify that billing is enabled for your Google Cloud project.

הפעלת ממשקי ה-API הנדרשים

כדי לעבוד עם קובצי אימג' של קונטיינרים ועם Kubernetes בפרויקט Google Cloud , צריך להפעיל את ממשקי ה-API הבאים:

  • ‫Artifact Registry API: ממשק ה-API הזה מפעיל את Artifact Registry, שירות לאחסון ולניהול של קובצי אימג' של קונטיינרים.
  • ‫Kubernetes Engine API: ה-API הזה מספק גישה ל-GKE.

כדי להפעיל את ממשקי ה-API האלה, צריך לעבור אל הפעלת ממשקי ה-API במסוף Google Cloud .

חיבור Cloud Shell ל Google Cloud פרויקט

אחרי שמגדירים את הפרויקט ב- Google Cloud , צריך להפעיל מופע של Cloud Shell ולקשר אותו לפרויקט ב- Google Cloud. ‫Cloud Shell הוא כלי שורת פקודה שמאפשר ליצור ולנהל משאבים של פרויקט ישירות מהדפדפן. ב-Cloud Shell מותקנים מראש שני כלים חשובים: ה-CLI של gcloud ו-kubectl CLI. במדריך הזה משתמשים ב-CLI של gcloud כדי ליצור אינטראקציה עם Google Cloud , ובמדריך הבא משתמשים ב-CLI של kubectl כדי לנהל את אפליקציית Cymbal Books שפועלת ב-GKE.

כדי לקשר מופע של Cloud Shell ל Google Cloud פרויקט, פועלים לפי השלבים הבאים:

  1. נכנסים למסוף Google Cloud :

    ‫Google Cloud console

  2. במסוף, לוחצים על הלחצן Activate Cloud Shell: הפעלת Cloud Shell

    בחלק התחתון של המסוף ייפתח סשן של Cloud Shell בתוך מסגרת.

  3. מגדירים את פרויקט ברירת המחדל ב-Google Cloud CLI באמצעות הפקודה הבאה:

    gcloud config set project PROJECT_ID

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

הגדרת משתני הסביבה שמוגדרים כברירת מחדל

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

כדי להגדיר את הסביבה באמצעות Cloud Shell:

export PROJECT_ID=$(gcloud config get project)
export REPOSITORY_REGION=REPOSITORY_REGION
export REPOSITORY_NAME=REPOSITORY_NAME
export REPOSITORY_DESCRIPTION="REPOSITORY_DESCRIPTION"
export TAG=TAG

מחליפים את מה שכתוב בשדות הבאים:

  • ‫REPOSITORY_REGION: האזור שבו רוצים שהמאגר של Artifact Registry יתארח. לדוגמה, us-central1 (איווה), us-west1 (אורגון) או europe-west1 (בלגיה). כאן אפשר לראות רשימה מלאה של אזורים.
  • ‫REPOSITORY_NAME: שם המאגר. לדוגמה, book-review-service-repo.
  • ‫REPOSITORY_DESCRIPTION: תיאור קצר של מטרת המאגר. לדוגמה, "Repository for storing Docker images for the book review service".
  • ‫TAG: התג שרוצים להוסיף לתמונה. תג הוא תווית שאפשר לצרף לגרסה ספציפית של תמונת מאגר. אפשר להשתמש במוסכמות למתן שמות לתגים כמו אלה כדי לציין בבירור גרסאות שונות של תמונה:
    • v1
    • v1.2.3
    • תג תיאורי, כמו feature-x-dev
    • תג שמציין את הסביבה, כמו test

יצירת מאגר ב-Artifact Registry

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

כדי ליצור מאגר ב-Artifact Registry, מריצים את הפקודה הבאה:

gcloud artifacts repositories create ${REPOSITORY_NAME} \
    --repository-format=docker \
    --location=${REPOSITORY_REGION} \
    --description="${REPOSITORY_DESCRIPTION}"

פלט מוצלח מהפקודה ייראה כך:

Waiting for operation [...] to complete...done.
Created repository [book-review-service-repo].

הגדרת Docker ל-Artifact Registry

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

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

כדי להגדיר את Docker לאימות ב-Artifact Registry, מריצים את הפקודה הבאה:

gcloud auth configure-docker ${REPOSITORY_REGION}-docker.pkg.dev

קבלת קוד המדריך

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

אפשר להשלים את המדריך הזה במחשב המקומי, אבל תצטרכו להתקין ולהגדיר באופן ידני כמה כלים כמו Docker,‏ kubectl ו-CLI של gcloud. קל יותר להשתמש ב-Cloud Shell כי הוא מוגדר מראש עם כל הכלים האלה.

במופע של Cloud Shell, מריצים את הפקודה הבאה כדי לשכפל את מאגר GitHub:

git clone https://github.com/GoogleCloudPlatform/kubernetes-engine-samples.git

הבסיס ליצירת קונטיינרים: קובצי אימג' של קונטיינרים, קונטיינרים ו-Dockerfiles

אחרי שהגדרתם את הסביבה והורדתם את הקוד של הקונטיינר, אתם יכולים להפוך את האפליקציה לקונטיינר. כדי לעשות את זה, צריך להשתמש ב-קובץ Docker כדי לארוז כל מודול של Cymbal Books (דף הבית, פרטי הספר, תמונות וביקורות על הספר) ב-קובץ אימג' של קונטיינר. כשהאפליקציה נפרסת באשכול GKE, ‏ Kubernetes משתמש בתמונות הקונטיינר האלה כדי ליצור קונטיינרים פועלים באשכול.

בקטעים הבאים מוסבר על המושגים האלה בפירוט.

מהי קונטיינריזציה?

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

מהם קובצי אימג' של קונטיינרים?

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

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

מה זה מאגר תגים?

קונטיינר הוא סביבה מבודדת שבה קוד מקובץ אימג' של קונטיינר מורץ. יש שתי דרכים ליצור קונטיינרים: באמצעות הפקודה docker run לבדיקה במהלך הפיתוח, או באמצעות פריסת קובצי אימג' של קונטיינרים באשכול Kubernetes.

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

  • הקומפוננטה של דף הבית מפעילה את המודול של דף הבית ומטפלת בבקשות אל /.
  • מאגר התגים book details מפעיל את המודול book details ומציג נתונים לנקודות קצה כמו /book/1 או /book/3.
  • הקונטיינר book reviews מריץ את המודול book reviews ומנהל בקשות לנקודות קצה כמו /book/2/reviews.
  • קונטיינר התמונות מריץ את מודול התמונות ומציג תמונות של כריכות ספרים לנקודות קצה כמו /images/fungi_frontier.jpg.

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

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

מהם קובצי Docker?

קובץ Dockerfile הוא סקריפט שמגדיר איך לארוז מודול בתמונת קונטיינר. במדריך הזה לא צריך ליצור קובצי Dockerfile – הם כבר מסופקים במאגר GitHub ששיכפלתם קודם. הספרייה של כל מודול בעותק המקומי של kubernetes-engine-samples/quickstarts/monolith-to-microservices/containerized/ מכילה Dockerfile משלה.

לדוגמה, אפשר למצוא את קובץ Docker של מודול home_app במופע Cloud Shell בכתובת kubernetes-engine-samples/quickstarts/monolith-to-microservices/containerized/home_app/Dockerfile. קובץ ה-Dockerfile נראה כך:

# Dockerfile for home_app
FROM python:3.9-slim #line 1
WORKDIR /app #line 2
COPY requirements.txt . #line 3
RUN pip install --no-cache-dir -r requirements.txt #line 4
COPY home_app.py . #line 5
COPY templates/ ./templates/ #line 6
COPY static/ ./static/ #line 7
CMD ["python", "home_app.py"] #line 8

קובץ ה-Docker הזה מבצע את השלבים הבאים כדי ליצור את קובץ האימג' של הקונטיינר עבור מודול home_app:

  • שורה 1: הפקודה FROM python:3.9-slim מורידה רכיב תרגום של Python 3.9 ואת הקבצים הנדרשים שלו לקובץ אימג' של קונטיינר. הקבצים האלה מאפשרים להפעיל את המודול.
  • שורה 2: הפקודה WORKDIR /app יוצרת ספרייה בשם /app בתוך הקונטיינר ומגדירה את הספרייה הזו כספריית העבודה הנוכחית. כל הפקודות שמופעלות בתוך הקונטיינר יופעלו מתוך הספרייה הזו.
  • שורות 3 ו-4: הפקודה COPY requirements.txt . מעתיקה את הקובץ requirements.txt מהמחשב המקומי לתיקייה /app של קובץ האימג' של הקונטיינר. בקובץ requirements.txt מפורטות כל ספריות Python שנדרשות ל-home_app.py. השורה RUN pip install מתקינה את הספריות האלה בקובץ האימג' של הקונטיינר.
  • שורות 5 עד 7: הפקודות COPY שמופיעות בשורות האלה מעתיקות את הקוד של המודול (home_app.py) ואת קובצי התמיכה שלו (תבניות ונכסים סטטיים) לספרייה /app בתוך קובץ אימג' של קונטיינר.
  • שורה 8: CMD מציינת את פקודת ברירת המחדל ש-Docker מריץ כשהקונטיינר מתחיל לפעול. בקובץ Dockerfile הזה, הפקודה CMD ["python", "home_app.py"] אומרת ל-Docker להשתמש במפרש של Python כדי להריץ את המודול home_app.py באופן אוטומטי כשהקונטיינר מופעל.

איך שימוש בקונטיינרים יכול לאכוף בידוד נתונים מחמיר יותר

שורות 5 עד 7 בקובץ Dockerfile, שתוארו בקטע הקודם, מראות איך אפשר להשתמש במיכלים כדי לאכוף בידוד נתונים מחמיר יותר מאשר בגרסה המודולרית של האפליקציה. במדריך הקודם, בקטע Give each module access to only the data it needs, למדתם שהגרסה המודולרית של האפליקציה ארגנה את הנתונים בספריות נפרדות, אבל המודולים עדיין שיתפו את אותה מערכת קבצים ויכלו לגשת לנתונים של מודולים אחרים.

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

בקטע הבא מוסבר איך הפקודה docker build מקבלת קובץ Docker כקלט, ופועלת לפי ההוראות בקובץ Docker כדי ליצור תמונת קונטיינר.

יצירת קובצי אימג' של קונטיינרים באמצעות Docker

בקטע הזה, תיצרו קובצי אימג' של קונטיינרים של Docker לכל אחד מהמודולים של ביקורת הספרים ותעבירו אותם למאגר שלכם ב-Artifact Registry. תשתמשו בתמונות של הקונטיינר במדריך הבא כדי לפרוס ולהריץ את אפליקציית הדוגמה Cymbal Books ב-Kubernetes.

  1. מנווטים לספריית הבסיס של האפליקציה בקונטיינרים:

    cd kubernetes-engine-samples/quickstarts/monolith-to-microservices/containerized/

  2. יוצרים את תמונות הקונטיינרים באמצעות הפקודה docker build:

    docker build -t ${REPOSITORY_REGION}-docker.pkg.dev/${PROJECT_ID}/${REPOSITORY_NAME}/home-app:${TAG} ./home_app
docker build -t ${REPOSITORY_REGION}-docker.pkg.dev/${PROJECT_ID}/${REPOSITORY_NAME}/book-details-app:${TAG} ./book_details_app
docker build -t ${REPOSITORY_REGION}-docker.pkg.dev/${PROJECT_ID}/${REPOSITORY_NAME}/book-reviews-app:${TAG} ./book_reviews_app
docker build -t ${REPOSITORY_REGION}-docker.pkg.dev/${PROJECT_ID}/${REPOSITORY_NAME}/images-app:${TAG} ./images_app

  3. כדי לראות את קובצי האימג' של הקונטיינרים שנוצרו במופע Cloud Shell:

    docker images

    בודקים שהתמונות הבאות מופיעות ברשימה:

    • home-app
    • book-details-app
    • book-reviews-app
    • images-app

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

בדיקת קונטיינרים ב-Cloud Shell

כדי לוודא שתמונות המאגר נוצרו בצורה נכונה, אפשר להריץ אותן כמאגרי תמונות ולבדוק את נקודות הקצה שלהן ב-Cloud Shell.

אפשר לבדוק את מאגרי התגים book_details_app, book_reviews_app ו-images_app בנפרד כי הם לא צריכים לתקשר אחד עם השני. עם זאת, קשה לבדוק את קונטיינר home_app באמצעות Docker כי הוא מוגדר לחפש את הקונטיינרים האחרים שמשתמשים בשמות שירות כמו http://book-details-service:8081.home_app

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

כדי לבדוק את מאגרי התגים:

  1. מפעילים את הקונטיינרים book_details_app,‏ book_reviews_app ו-images_app:

    docker run -d -p 8081:8080 ${REPOSITORY_REGION}-docker.pkg.dev/${PROJECT_ID}/${REPOSITORY_NAME}/book-details-app:${TAG}
docker run -d -p 8082:8080 ${REPOSITORY_REGION}-docker.pkg.dev/${PROJECT_ID}/${REPOSITORY_NAME}/book-reviews-app:${TAG}
docker run -d -p 8083:8080 ${REPOSITORY_REGION}-docker.pkg.dev/${PROJECT_ID}/${REPOSITORY_NAME}/images-app:${TAG}

  2. כדי לבדוק שהמאגרים פועלים, מציגים רשימה של כל המאגרים הפעילים:

    docker ps

    הפלט מהפקודה הזו צריך להציג שלושה קונטיינרים שפועלים, עם הסטטוס Up:

    CONTAINER ID   IMAGE                PORTS                        STATUS
a1b2c3d4e5f6   REGION/.../details   0.0.0.0:8081->8080/tcp       Up
g7h8i9j0k1l2   REGION/.../reviews   0.0.0.0:8082->8080/tcp       Up
m3n4o5p6q7r8   REGION/.../images    0.0.0.0:8083->8080/tcp       Up

  3. כדי לבדוק את נקודות הקצה של קונטיינר book_details_app, משתמשים בפקודות curl הבאות:

    curl http://localhost:8081/books
curl http://localhost:8081/book/1
curl http://localhost:8081/book/2
curl http://localhost:8081/book/3

    כל אחת מהפקודות האלה מחזירה נתונים בפורמט JSON. לדוגמה, הפלט של הפקודה curl http://localhost:8081/book/1 נראה כך:

    {"author":"Aria Clockwork","description":"In a world where time is a tangible substance, a young clockmaker discovers she can manipulate the fabric of time itself, leading to unforeseen consequences in her steampunk-inspired city.","id":1,"image_url":"zephyrs_timepiece.jpg","title":"Zephyr's Timepiece","year":2023}

  4. כדי לאחזר ביקורות על ספרים מהמאגר book_reviews_app, משתמשים בפקודה curl:

    curl http://localhost:8082/book/1/reviews

    הפקודה הזו מחזירה רשימה של 20 ביקורות על ספר 1 בפורמט JSON. דוגמה לביקורת אחת מהרשימה:

    {
"content": "The concept of time as a tangible substance is brilliantly explored in 'Zephyr's Timepiece'.",
"rating": 5
}

  5. בודקים את מאגר התגים images_app:

    1. לוחצים על הלחצן **Web Preview**. כפתור לתצוגה מקדימה של אתר

    2. בוחרים באפשרות שינוי היציאה ומזינים 8083. ייפתח חלון בדפדפן עם כתובת URL שדומה לכתובת הזו:

      https://8083-your-instance-id.cs-your-region.cloudshell.dev/?authuser=0

    3. מסירים את התו ?authuser=0 בסוף כתובת ה-URL ומוסיפים את הנתיב לקובץ תמונה, כמו ?authuser=0./images/fungi_frontier.jpg לדוגמה:

      https://8083-your-instance-id.cs-your-region.cloudshell.dev/images/fungi_frontier.jpg

      תמונת הכריכה של הספר Fungi Frontier תוצג בדפדפן.

  6. אחרי הבדיקה, מפסיקים את השימוש במאגרי התגים כדי לפנות משאבים:

    1. מציגים את הקונטיינרים הפועלים ומחפשים את מזהי הקונטיינרים שלהם:

      docker ps

    2. עוצרים כל קונטיינר:

      docker stop CONTAINER_ID

      מחליפים את CONTAINER_ID במזהה של הקונטיינר שרוצים להפסיק.

העברת תמונות הקונטיינרים אל Artifact Registry

כדי לפרוס את האפליקציה באשכול Kubernetes, צריך לאחסן את תמונות הקונטיינרים במיקום שאליו יש לאשכול גישה. בשלב הזה, מעבירים את קובצי האימג' למאגר Artifact Registry שיצרתם קודם. במדריך הבא, תפרסו את התמונות האלה ממאגר Artifact Registry לאשכול GKE:

  1. כדי להעלות את קובצי האימג' של הקונטיינר ל-Artifact Registry, מריצים את הפקודות הבאות:

    docker push ${REPOSITORY_REGION}-docker.pkg.dev/${PROJECT_ID}/${REPOSITORY_NAME}/home-app:${TAG}
docker push ${REPOSITORY_REGION}-docker.pkg.dev/${PROJECT_ID}/${REPOSITORY_NAME}/book-details-app:${TAG}
docker push ${REPOSITORY_REGION}-docker.pkg.dev/${PROJECT_ID}/${REPOSITORY_NAME}/book-reviews-app:${TAG}
docker push ${REPOSITORY_REGION}-docker.pkg.dev/${PROJECT_ID}/${REPOSITORY_NAME}/images-app:${TAG}

  2. אחרי שמעבירים את התמונות, מוודאים שהן הועלו בהצלחה על ידי הצגת רשימה שלהן:

    gcloud artifacts docker images list ${REPOSITORY_REGION}-docker.pkg.dev/${PROJECT_ID}/${REPOSITORY_NAME}

    הפלט אמור להיראות כך:

    Listing items under project ${PROJECT_ID}, location ${REPOSITORY_REGION}, repository ${REPOSITORY_NAME}.

IMAGE: ${REPOSITORY_REGION}-docker.pkg.dev/${PROJECT_ID}/${REPOSITORY_NAME}/book-details-app
DIGEST: sha256:f7b78f44d70f2eedf7f7d4dc72c36070e7c0dd05daa5f473e1ebcfd1d44b95b1
CREATE_TIME: 2024-11-14T00:38:53
UPDATE_TIME: 2024-11-14T00:38:53
SIZE: 52260143

IMAGE: ${REPOSITORY_REGION}-docker.pkg.dev/${PROJECT_ID}/${REPOSITORY_NAME}/book-reviews-app
DIGEST: sha256:875ac8d94ef54db2ff637e49ad2d1c50291087623718b854a34ad657748fac86
CREATE_TIME: 2024-11-14T00:39:04
UPDATE_TIME: 2024-11-14T00:39:04
SIZE: 52262041

IMAGE: ${REPOSITORY_REGION}-docker.pkg.dev/${PROJECT_ID}/${REPOSITORY_NAME}/home-app
DIGEST: sha256:70ddc54ffd683e2525d87ee0451804d273868c7143d0c2a75ce423502c10638a
CREATE_TIME: 2024-11-14T00:33:56
UPDATE_TIME: 2024-11-14T00:33:56
SIZE: 52262412

IMAGE: ${REPOSITORY_REGION}-docker.pkg.dev/${PROJECT_ID}/${REPOSITORY_NAME}/images-app
DIGEST: sha256:790f0d8c2f83b09dc3b431c4c04d7dc68254fecc76c48f00a83babc2a5dc0484
CREATE_TIME: 2024-11-14T00:39:15
UPDATE_TIME: 2024-11-14T00:39:15
SIZE: 53020815

    הפלט כולל את הפרטים הבאים לגבי כל תמונה:

    • ‫IMAGE: נתיב המאגר ושם התמונה.
    • ‫DIGEST: מזהה ייחודי של התמונה.
    • ‫CREATE_TIME או UPDATE_TIME: מתי התמונה נוצרה או מתי היא שונתה לאחרונה.
    • ‫SIZE: גודל התמונה בבייטים.

עדכון מניפסט Kubernetes עם נתיבים לקובצי אימג' של קונטיינרים

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

  • המודולים של האפליקציה (לדוגמה,home-app, book-details-app)
  • נתיבים לקובצי אימג' של קונטיינרים
  • פרטי ההגדרה, כמו מגבלות על משאבים
  • הגדרות שירות לניתוב בקשות בין מודולים

בקטע הזה, מעדכנים את אותו קובץ מניפסט שנבדק במדריך הקודם. הקובץ הוא kubernetes-manifest.yaml והוא מכיל ערכים של פלייסולדרים לנתיבי התמונות. צריך להחליף את ה-placeholders בנתיבים בפועל לקובצי האימג' בקונטיינר שהעברתם למאגר ב-Artifact Registry בקטע הקודם.

כדי לעדכן את קובץ המניפסט של kubernetes-manifest.yaml Kubernetes, פועלים לפי השלבים הבאים:

  1. ב-Cloud Shell, עוברים אל הספרייה containerized/, שמכילה את קובץ המניפסט של Kubernetes‏ kubernetes-manifest.yaml:

    cd kubernetes-engine-samples/quickstarts/monolith-to-microservices/containerized/

  2. פותחים את הקובץ kubernetes-manifest.yaml בכלי לעריכת טקסט:

    vim kubernetes-manifest.yaml

  3. מאתרים את השדות image שמכילים placeholders כמו זה:

    image: REPOSITORY_REGION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/home-app:TAG

    מחליפים כל פלייסהולדר בנתיבים בפועל לתמונות הקונטיינר שהעליתם ל-Artifact Registry:

    כך יכולה להיראות דרך אל ההמרה אחרי שמבצעים את ההחלפות האלה:

    image:us-west1-docker.pkg.dev/your-project-id/book-review-service-repo/home-app:v1

  4. מעדכנים את הנתיבים של כל קובצי האימג' של הקונטיינרים:

    • home-app
    • book-details-app
    • book-reviews-app
    • images-app

  5. אחרי שמעדכנים את הנתיבים, שומרים את קובץ המניפסט וסוגרים את העורך. לדוגמה, אם אתם משתמשים ב-vim, מקישים על Esc כדי להיכנס למצב פקודה, מקלידים wq ומקישים על Enter כדי לשמור ולצאת.

קובץ המניפסט של Kubernetes מוגדר עכשיו לפריסת קובצי האימג' בקונטיינר ממאגר Artifact Registry לאשכול Kubernetes.

סיכום

במדריך הזה הכנתם את אפליקציית Cymbal Books המודולרית לפריסה באשכול Kubernetes, על ידי ביצוע המשימות הבאות:

  1. מגדירים פרויקט ומגדירים את Cloud Shell לסביבה שלכם. Google Cloud
  2. בדקתי את קובצי ה-Dockerfiles שסופקו לכל מודול של אפליקציה.
  3. יצירת קובצי אימג' של קונטיינרים למודולים של האפליקציה באמצעות Docker.
  4. בדקתי קונטיינרים ב-Cloud Shell כדי לוודא שהם פועלים כמו שצריך.
  5. העברת תמונות הקונטיינרים ל-Artifact Registry לצורך אחסון.
  6. עדכנו את המניפסט של Kubernetes כך שישתמש בנתיבי קובצי האימג' הנכונים של הקונטיינרים מ-Artifact Registry.

המאמרים הבאים

במדריך הבא, פריסת האפליקציה לאשכול GKE, תלמדו איך לפרוס את האפליקציה שמוכלת בקונטיינר לאשכול GKE.