בדף הזה מוסברות השיטות המומלצות ליצירת פריסות באמצעות Google Cloud Deployment Manager. הדף הזה מיועד למשתמשים שמכירים את Deployment Manager. לא נסביר כאן איך להשתמש ב-Deployment Manager.
אם אתם משתמשים חדשים ב-Deployment Manager, אנחנו ממליצים לנסות את המדריך למתחילים
ניהול משאבים
|
❑
אחרי שיוצרים משאב כחלק מפריסה, אפשר להשתמש ב-Deployment Manager אם צריך לשנות את המשאב.
אם משנים משאב בלי להשתמש ב-Deployment Manager, למשל באמצעות Google Cloud המסוף או
gcloud, יכול להיות שיוצגו שגיאות אם תנסו לשנות את המשאב בפריסה המקורית.
כדי להסיר משאב מפריסה בלי למחוק אותו, פועלים לפי השלבים הבאים:
|
|
❑
אם יש לכם מכונות Compute Engine בפריסה ואתם רוצים לצרף דיסקים קשיחים למכונות, כדאי להגדיר את הדיסק בנפרד מהמכונה כדי שתוכלו לנהל אותו בקלות. לדוגמה, בפריסה שלמטה, הדיסק
example-disk מוגדר בנפרד מהמכונה example-instance. כדי לצרף את הדיסק, בהגדרה יש הפניה לדיסק:
resources: # instance - name: example-instance type: compute.v1.instance properties: disks: - type: PERSISTENT source:$(ref.example-disk.selfLink) # disk - name: example-disk type: compute.v1.disk properties: zone: us-central1-a sizeGb: 10 type: ... |
|
❑
כדי ליצור ולנהל אשכולות פרטיים של Google Kubernetes Engine (GKE) באמצעות Deployment Manager, צריך להגדיר את האפשרויות הבאות
privateClusterConfig: enablePrivateNodes: true enablePrivateEndpoint: true # Configure the IP range for the hosted master network masterIpv4CidrBlock: IP_RANGE ipAllocationPolicy: useIpAliases: true createSubnetwork: true לדרישות ולשיקולים נוספים כשיוצרים אשכול פרטי באמצעות GKE, אפשר לקרוא את המאמר הגדרת אשכול פרטי. |
הכללת פרטי כניסה בפריסה
|
❑
Deployment Manager מצנזר חלק מהשדות שקשורים לפרטי הכניסה ממאפיינים בהגדרות ה-YAML. הצנזורה הזו מתבצעת על סמך המפתח של הנכס. בדוגמה הבאה מוצגת צנזורה כזו:
# Config provided to Deployment Manager resources: - name: example-resource type: gcp-types/service-v1:sample-type-with-password properties: zone: us-central1-a username: test-user password: hunter2 # Config as surfaced by Deployment Manager resources: - name: example-resource type: gcp-types/service-v1:sample-type-with-password properties: zone: us-central1-a username: test-user password: (redacted) |
|
❑
אם כוללים את פרטי הכניסה בתבנית Jinja או Python לפריסה, פרטי הכניסה מצונזרים מקובצי הפריסה והפריסה המורחבת שנוצרים, אבל הם עדיין גלויים בקובץ הייבוא המקורי. לכן, מומלץ מאוד למקם את כל פרטי הכניסה שרוצים לשמור בסוד בהגדרת ה-YAML ברמה העליונה. אפשר להפנות אליהם משם באמצעות מאפייני תבנית.
|
|
❑
פרטי כניסה שכלולים בצמד מפתח/ערך בקובץ YAML או ברשימת פריטים לא יוסתרו, כמו בדוגמה הבאה. לכן, אנחנו ממליצים מאוד לא לספק פרטי כניסה ל-Deployment Manager כצמדי מפתח/ערך בקובצי YAML או ברשימות של פריטים.
# Not a valid instance configuration, used solely for demonstration resources: - name: example-resource type: gcp-types/compute-v1:instances properties: zone: us-central1-a disks: - autoDelete: true boot: true # Will not be redacted password: hunter2 |
תבניות של מבנים
|
❑
כדי להגדיר את התבניות במהירות, כדאי להתחיל עם תבניות לדוגמה שמוכנות לייצור מתוך פרויקט Cloud Foundation Toolkit.
|
|
❑
אם יש לכם דרישות מורכבות לגבי התשתית, למשל אם אתם צריכים ליצור כמה סביבות, כדאי לעיין במדריך ובדוגמאות בנושא שימוש ב-Deployment Manager בהיקף גדול.
|
|
❑
אפשר להשתמש ב-Python כדי ליצור תבניות.
אפשר להשתמש ב-Python או ב-Jinja2 כדי ליצור תבניות. קל יותר להתחיל עם Jinja, אבל Python גמיש יותר לפריסות מורכבות שבהן יכולים להיות הרבה משאבים שמפוצלים בין סביבות שונות.
|
|
❑
מבנה קובץ התצורה (קובץ ה-YAML) צריך לכלול רק סוג אחד, ותבנית ברמה העליונה צריכה לשמש כסוג הזה כדי להפעיל את כל התבניות האחרות. השימוש בשיטה הזו מאפשר לשנות בקלות קבוצה של תבניות ל
סוג מורכב.
|
|
❑
משתמשים בקובץ סכימה.
סכימות מגדירות קבוצת כללים שקובץ תצורה צריך לפעול לפיהם כדי להשתמש בתבנית מסוימת. הגדרת סכימה ועידוד משתמשים אחרים לבדוק את הדרישות שמוגדרות בסכימה מאפשרים למשתמשים להבין בקלות אילו מאפיינים אפשר להגדיר או שנדרשים עבור התבנית הרלוונטית. כך המשתמשים יכולים להשתמש בהגדרה בלי לבדוק את הפרטים של התבניות. לפחות צריך להגדיר קובץ סכימה לתבנית ברמה העליונה.
|
|
❑
שימוש במאפייני תבנית ובפלט.
שימוש במאפיינים ובפלט מאפשר להעביר משתנים כמו האזור, גודל המכונה, מספר המכונות או מצב האפליקציה (בדיקה, ייצור, הכנה) לתבניות ולקבל בחזרה ערכי פלט כמו כתובת ה-IP ו-
selfLink למכונה וירטואלית. המאפיינים והפלט מאפשרים לתבניות להיות גמישות, כך שאפשר לעשות בהן שימוש חוזר בלי לבצע שינויים בתבניות הבסיסיות.
|
|
❑
משתמשים בקובצי תבניות נפרדים שמייבאים לקובץ ההגדרות הראשי. כך תוכלו לנהל את ההגדרות בצורה נוחה יותר.
|
|
❑
פיצול ההגדרות ליחידות לוגיות. לדוגמה, אפשר ליצור הגדרות נפרדות לשירותים עם מצב, כמו מסדי נתונים ודליים, והגדרות לשירותים זמניים יותר, כמו מופעי frontend.
|
|
❑
משתמשים בהפניות.
צריך להשתמש בהפניות לערכים שלא מוגדרים עד ליצירת משאב, כמו
selfLink, כתובת IP או מזהה שנוצר על ידי המערכת של משאב. בלי קובצי עזר, Deployment Manager יוצר את כל המשאבים במקביל, ולכן אין ערובה לכך שמשאבים תלויים ייווצרו בסדר הנכון. שימוש בהפניות יכפה את הסדר שבו המשאבים נוצרים.
|
|
❑
תצוגה מקדימה
של הפריסות כדי להעריך איך עדכון ישפיע על הפריסה.
כשמציגים תצוגה מקדימה של הגדרה, Deployment Manager לא יוצר מופעים של משאבים בפועל, אלא מרחיב את ההגדרה המלאה ויוצר משאבי shell במקום זאת. כך תוכלו לראות את השינויים בפריסה לפני שתאשרו אותה.
|
|
❑
כדאי לבדוק את שיטות ה-API של משאב ספציפי כדי להבין את ההשלכות של ביצוע עדכון. כדי לשלוט באופן שבו Deployment Manager מחיל כל עדכון, כדאי להגדיר מדיניות עדכונים כשמעדכנים פריסה.
|
|
❑
משתמשים בתוויות למשאבים. אם המשאבים שאתם מגדירים תומכים בתוויות, כדאי להשתמש בהן כדי לתייג את המשאבים. התוויות יכולות לעזור לסווג משאבים ששייכים לפריסות שונות, והן גם מאפשרות להבחין בשלב שבו המשאבים נמצאים, למשל אם משאב תומך בסביבת ייצור או בסביבת בדיקה.
|
ניהול הגודל של הפריסות
Deployment Manager יכול לפעול על מספר גדול של משאבים, בכפוף למגבלות המכסה. אם רוצים לקצר את הזמן שנדרש ליצירה, לעדכון או למחיקה של פריסות, אפשר לצמצם את מספר המשאבים בכל פריסה בנפרד.
|
❑
אם קבוצת משאבים לא תלויה במשאבים מחוץ לקבוצה הזו,
אפשר להעביר את קבוצת המשאבים הזו לפריסה נפרדת. לדוגמה, אם הפריסה שלכם מכילה כמה תבניות, אתם יכולים לארוז כל תבנית כפריסה נפרדת.
|
|
❑
מסירים מההגדרה משאבים מיותרים. אם תצטרכו עוד משאבים בהמשך, תוכלו להוסיף אותם לפריסה.
|
|
❑
אפשר גם להגביל את הפריסות ל-1, 000 משאבים או פחות.
|
הרשאות
כברירת מחדל, Deployment Manager משתמש בפרטי הכניסה של חשבון השירות ב-Google APIs כדי לבצע אימות לממשקי API אחרים. חשבון השירות של Google APIs מיועד להפעלת תהליכים פנימיים של Google בשמכם.
כדי לתת למשתמשים אחרים גישה לפרויקט Deployment Manager, צריך להקצות למשתמש תפקיד IAM עם ההרשאות המתאימות לשימוש ב-Deployment Manager. יש מספר תפקידים מוגדרים מראש ב-IAM שבהם אפשר להשתמש כדי לקבוע את רמת הגישה של משתמש לקריאה ל-Deployment Manager.
|
❑
שימוש בתפקידי IAM כדי להגביל את ההרשאות שניתנות למשתמשים לשימוש ב-Deployment Manager.
|
|
❑
אם רוצים שהמשתמשים יוכלו לגשת למשאבים שנוצרו על ידי Deployment Manager, צריך להעניק להם את התפקידים שנדרשים לשימוש במשאבים, אבל לא להעניק להם הרשאות לפריסת משאבים באופן ישיר.
|
|
❑
הקצאת התפקיד בעלים לחשבון ראשי מאפשרת לו לשנות את מדיניות ה-IAM. לכן, כדאי להעניק את תפקיד הבעלים רק אם לחשבון המשתמש יש מטרה לגיטימית לנהל את מדיניות ה-IAM, כי המדיניות מכילה נתונים רגישים של בקרת גישה. אם רק מספר מצומצם של משתמשים ינהלו את החשבון, יהיה לכם קל יותר לבצע ביקורת.
|
|
❑
Deployment Manager משתמש בחשבון השירות של Google APIs כדי ליצור ולנהל את המשאבים שלכם. אם אתם משתמשים ב-Deployment Manager כדי לנהל משאבים קריטיים, כמו תפקידי IAM בהתאמה אישית, אתם צריכים להקצות תפקידי IAM נוספים לחשבון השירות שמוגדר כברירת מחדל ב-Google APIs. לדוגמה, אם רוצים להשתמש ב-Deployment Manager כדי ליצור ולנהל תפקידי IAM בהתאמה אישית, צריך להוסיף את התפקיד Role Administrator לחשבון השירות ב-Google APIs.
סקירה כללית על חשבון השירות של Google APIs זמינה במאמר בנושא חשבונות שירות שמנוהלים על ידי Google. במאמר הקצאת תפקידים לחשבונות שירות מוסבר איך מקצים תפקידים לחשבון שירות. |
אוטומציה
כדאי לשקול אוטומציה של יצירת פרויקטים וגם אוטומציה של יצירת משאבים שנכללים בפרויקטים. כך תוכלו לאמץ גישה של 'תשתית כקוד' (IaC) להקצאת משאבים בפרויקט. לגישה הזו יש יתרונות רבים, כמו האפשרות:
- מאפשרים אכיפה של דרישות תאגידיות כשמספקים פרויקטים לצוותים שזקוקים לגישה למשאבי Google Cloud .
- מספקת סדרה של סביבות פרויקט מוגדרות מראש שאפשר להקצות במהירות ובקלות.
- משתמשים בניהול גרסאות כדי לנהל את הגדרת פרויקט הבסיס.
- אתם יכולים להיות בטוחים שאתם פורסים הגדרות פרויקט עקביות שניתן לשחזר.
- שילוב של יצירת פרויקטים כחלק מתהליך הקצאת הרשאות אוטומטי.
|
❑
אפשר להשתמש בתבניות שזמינות ב-GitHub כנקודת התחלה כדי ליצור פרויקטים באופן אוטומטי.
|
אינטגרציה רציפה (CI) / פריסה רציפה (CD)
שימוש ב-Deployment Manager כחלק מצינור עיבוד הנתונים של CI/CD.
|
❑
אל תשתמשו בפייפליין של CI/CD כדי ליצור ולמחוק פרויקטים שלמים של בדיקות ובקרת איכות.
|
|
❑
משתמשים ב-Deployment Manager כדי ליצור את החלקים עם שמירת המצב של הפרויקט והגדרת הרשת, ומבצעים פריסה של החלקים האלה מחוץ לתהליך CI/CD כחלק מההגדרה הראשונית. אחרי שהבדיקה מסתיימת, אפשר למחוק פריסות שמכילות רק משאבים בלי שמירת מצב שנפרסו כחלק מפייפליין.
|
|
❑
כחלק מתהליך ה-CI/CD, כדאי להשתמש בהגדרה נפרדת כדי לפרוס משאבים בפרויקטים של הבדיקות ושל בקרת האיכות. אחרי שתסיימו את הבדיקה, תוכלו להשתמש ב-Deployment Manager כדי למחוק את המשאבים מפרויקטי הבדיקה והבטחת האיכות.
|
| בדיקת הפריסות. עם היכולת לשלב הקצאת משאבים כחלק מצינור CI/CD, Deployment Manager מאפשר לכם להתייחס להגדרת הפרויקט כקוד שאתם יכולים לבדוק בקלות, וליצור עותקים עקביים של סביבת הייצור הנוכחית או של הסביבה הנוכחית עם שינויים שהוחלו לבדיקה בביטחון. |
|
❑
להשתמש בניהול גרסאות. שימוש במערכת לניהול גרסאות כחלק מתהליך הפיתוח של הפריסות מאפשר לכם:
|