ארכיטקטורה של Cloud Workstations

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

התרשים הבא ממחיש את הארכיטקטורה של Cloud Workstations.

איור 1. ארכיטקטורה של Cloud Workstations

אשכול של תחנות עבודה

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

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

  הבקריים משתמשים ב-Compute Engine API כדי לנהל את מחזור החיים של המשאבים, ונעזרים ב-Private Service Connect כדי לנתב את התעבורה למכונות הווירטואליות של תחנות העבודה.

• שער: מקבל תנועה מלקוחות שמיועדת לתחנות עבודה מסוימות, ומעביר את התנועה למכונה וירטואלית מתאימה. לכל אשכול של תחנות עבודה יש שם דומיין ייחודי, וניתן להגיע לכל תחנת עבודה בתת-דומיין של הדומיין של אשכול תחנות העבודה – לדוגמה, $WORKSTATION_ID.$CLUSTER_ID.cloudworkstations.dev.

אלה תכונות נוספות של אשכולות תחנות עבודה:

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

• אשכולות של תחנות עבודה לא קשורים לאשכולות של Google Kubernetes Engine‏ (GKE).

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

• לכל אזור בענן צריך להיות לפחות אשכול תחנות עבודה אחד.

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

רשת VPC

כשיוצרים אשכול של תחנות עבודה, מציינים פרויקט ורשת VPC לאירוח המשאבים. לאחר מכן, Cloud Workstations מקצה את המשאבים הבאים בפרויקט:

• ‫Private Service Connect: יוצר חיבור בין בקר Cloud Workstations לבין ה-VPC שלכם, ומאפשר ליצור משאבים בתוך הפרויקט.

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

  • ‫VM Gateway: מושך את תעבורת הלקוח משער האשכול של תחנת העבודה, מאמת ומאשר אותה ומעביר אותה אל הקונטיינר.

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

    ‫Cloud Workstations מספקת מספר תמונות בסיסיות שהוגדרו מראש עם סביבות פיתוח משולבות (IDE) וכלים פופולריים לשפות תכנות. בנוסף, אדמינים וצוותי פלטפורמה יכולים להתאים אישית את הסביבות שלהם על ידי יצירה וציון של קובצי אימג' בקונטיינר בהתאמה אישית שמכילים את הכלים הדרושים כדי לענות על הצרכים של המפתחים שלהם. קובצי האימג' האלה של הקונטיינרים יכולים להרחיב את קובץ האימג' הבסיסי של Cloud Workstations, או להיות קובצי אימג' חדשים של קונטיינרים מותאמים אישית של Linux שנוצרו על ידי צוות הפלטפורמה.

• דיסק אחסון מתמיד (persistent disk): דיסק אחסון מתמיד שמצורף למכונה וירטואלית של תחנת העבודה מחובר לתיקייה /home, ומאפשר אחסון של נתונים וקבצים אחרי שהסשן מסתיים.

מחזור החיים של משאב

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

כשמפעילים תחנת עבודה, Cloud Workstations מבצע את הפעולות הבאות:

1. יוצר מכונה וירטואלית.
2. שליפת קובץ אימג' של קונטיינר של תחנת העבודה אל מכונת ה-VM.
3. בפעם הראשונה שמפעילים את תחנת העבודה, נוצר דיסק קשיח קבוע שמשמש כספרייה /home של תחנת העבודה.
4. מחברים את דיסק האחסון המתמיד (persistent disk) ל-VM.
5. המערכת מפעילה את הקונטיינר במכונה הווירטואלית ומעלה את דיסק האחסון המתמיד (persistent disk) לספרייה /home בקונטיינר.

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

איגום משאבים

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

כשהאיגום מופעל, Cloud Workstations מבצע את הפעולות הבאות כשמפעילים תחנת עבודה:

1. מערכת Cloud Run בוחרת מכונת VM מהמאגר שבה קובץ אימג' של קונטיינר כבר נמשך.
2. בפעם הראשונה שמפעילים את תחנת העבודה, נבחר דיסק מתמשך מהמאגר.
3. מחברים את דיסק האחסון המתמיד (persistent disk) ל-VM.
4. מפעיל את קובץ האימג' של הקונטיינר במכונה הווירטואלית וטוען את הדיסק הקבוע לספרייה /home בקובץ האימג' של הקונטיינר.
5. המערכת ממלאת מחדש את המאגר על ידי יצירת מכונה וירטואלית חדשה ודיסק קשיח קבוע במקום אלה שהוקצו.

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

עדכונים של קובץ אימג' של קונטיינר

מכיוון שקובץ האימג' של קונטיינר תחנת העבודה נמשך מראש אל מכונות ה-VM המשותפות, עדכונים לקובץ האימג' של הקונטיינר שבוצעו במאגר האימג' המרוחק עם אותו תג אימג' לא נקלטים עד שכל מכונות ה-VM המשותפות הוקצו או נמחקו אחרי 12 שעות. בשלב הזה, נוצרות מכונות וירטואליות חדשות כדי לחדש את המאגר ולמשוך את קובץ האימג' של הקונטיינר המעודכן.

כדי לכפות רענון של המאגר כדי שהעדכונים של קובץ האימג' של הקונטיינר יתעדכנו באופן מיידי, האדמינים יכולים להגדיר את pool_size ל-0, ואז להגדיר אותו בחזרה ל-pool_size המועדף. ב Google Cloud מסוף, משביתים את התכונה Quick start workstations (הפעלה מהירה של תחנות עבודה) בהגדרות תחנת העבודה, שומרים את ההגדרות, מחזירים את ההגדרות למספר המועדף ושומרים שוב.

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

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

‫Cloud Workstations תומך בסטרימינג של קובצי אימג', שמקצר את זמן ההפעלה של תחנת העבודה על ידי קיצור הזמן של שליפת קובץ האימג' של קונטיינר תחנת העבודה.

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

דרישות

כדי להשתמש בהזרמת תמונות ב-Cloud Workstations, אתם צריכים לעמוד בדרישות הבאות:

• צריך להפעיל את Container File System API בפרויקט המארח של תחנות העבודה.

  הפעלת Container File System API

  לחלופין, אפשר להריץ את פקודת gcloud CLI הבאה כדי להפעיל את Container File System API בפרויקט המארח של תחנות העבודה:

  gcloud services enable containerfilesystem.googleapis.com
  

• תמונות הקונטיינרים צריכות להיות מאוחסנות ב-Artifact Registry.

• צריך לציין חשבון שירות לשימוש בהגדרת תחנת העבודה.

  טיפ: אפשר להשתמש בחשבון השירות של Compute Engine שמוגדר כברירת מחדל בפורמט:
  $[e-mail]

  אזהרה: אי אפשר להשתמש בחשבון השירות שמוגדר כברירת מחדל למכונות וירטואליות של תחנות עבודה. הפורמט של חשבון השירות הזה הוא:
  service-$[e-mail]

• אם האשכול שלכם נמצא בתוך גבולות גזרה של VPC Service Controls, אתם צריכים להוסיף כלל יציאה שמאפשר לחשבון השירות שלכם לגשת ל-Container File System API בפרויקט שמארח את קובץ אימג' של קונטיינר. אם אתם משתמשים בסביבת פיתוח משולבת שהוגדרה מראש, אתם צריכים להוסיף את פרויקט cloud-workstations-images (מספר הפרויקט 662288601415) לרשימת ההיתרים.

מגבלות

• יכול להיות שלא תבחינו ביתרונות של סטרימינג של תמונות במהלך השליפה הראשונה של תמונה שעומדת בדרישות. עם זאת, אחרי שהתמונה נשמרת במטמון של Image streaming, משיכות תמונה עתידיות בתחנת עבודה נהנות מ-Image streaming.

• חלות הגבלות נוספות על סטרימינג של תמונות GKE.

זמנים קצובים לתפוגה של חוסר פעילות

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

אם מפעילים תהליך ברקע שפועל לאורך זמן ומפסיקים את האינטראקציה עם תחנת העבודה, יכול להיות שתגיעו לסף הזמן הקצוב לתפוגה של חוסר פעילות. כתוצאה מכך, תחנת העבודה נסגרת. אם צריך להשאיר את תחנת העבודה פעילה, אפשר להשתמש בסקריפט /google/scripts/keep_alive.sh שמופיע בתמונות של תחנת העבודה הבסיסית כדי למנוע מצב של חוסר פעילות שמוביל לתפוגת זמן קצוב. לחלופין, אפשר להפעיל את קריאת ה-API של workstation.Start בתהליך הרקע כדי למנוע את ההשבתה של מצב חוסר הפעילות. לדוגמה, אם אתם משתמשים ב-Google Cloud CLI, אתם יכולים להריץ את הפקודה gcloud workstations start.