IaC עם Google Cloud Deployment Manager: אוטומציה של GCP

Google Cloud Deployment Manager: היכן ניהול ידני נשבר

ניהול ידני של משאבי GCP אינו מורגש עד לפער הראשון בין סביבות. מישהו הוסיף כלל חומת אש בסביבת הבדיקות, מישהו הרים ידנית מכסה או שינה את גודל הדיסק — ו-staging מפסיק להיות העתק של production. לאחר מכן השחרור עובר בבדיקות ונופל בפרודקשן, והסיבה אינה בקוד אלא בתצורה שאיש לא תיעד.

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

Google Cloud Deployment Manager פותר זאת בכך שתיאור התשתית נשמר כקוד: תצורות ותבניות נמצאות במערכת בקרת גרסאות, והפריסה משחזרת את אותה סביבה ממקור אחד.

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

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

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

מה נותן תיאור דקלרטיבי של תשתית

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

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

שחזוריות של סביבות

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

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

זמן פריסה וניהול שינויים

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

ביטול שגיאות ידניות

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

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

גישות לאוטומציה של GCP: השוואת אפשרויות

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

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

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

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

שלבי יישום האוטומציה בענן

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

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

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

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

1. ביקורת תשתית. אוספים מפת משאבים, מסמנים שינויים ידניים ופערים בין הסביבות, מתעדים תלויות.
2. תכנון תבניות. פורשים את התצורה לפי שכבות ומודולים, מגדירים פרמטרים לסביבות שונות במקום עותקים של קבצים.
3. הגדרת צינור. מחברים את התבניות למערכת בקרת גרסאות, השינויים עוברים בדיקה ומיושמים אוטומטית.
4. בדיקת תצורה. מריצים פריסה בסביבה מבודדת, משווים את התוצאה למצב הצפוי לפני היציאה לפרודקשן.
5. העברת משאבים קיימים. מעבירים את מה שכבר עובד, ללא השבתה — רכיב אחד בכל פעם עם בקרה בכל שלב.
6. העברת נהלים. מוסרים לצוות תיאור של השכבות, סדר השינויים וכללי החזרה לאחור, ומקיימים סדנת תרגול על משימה אמיתית.

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

ארטיפקטים ותיעוד לאחר ההטמעה

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

• תבניות קונפיגורציה — תיאורים מתואמים של משאבים: רשתות, תת-רשתות, כללי חומת אש, מופעים, מאזני עומסים, אחסון. סביבות (dev/stage/prod) נבדלות בקבוצת פרמטרים, ולא בעותקים של קבצים, ולכן פער בין הסביבות נמנע מבחינה מבנית.
• תרשימי תלויות — גרף הקשרים בין המשאבים: מה נוצר ראשון, מה תלוי ברשת, היכן הסדר קריטי. לפיו ניתן לראות איזה רכיב יושפע משינוי, וזה מסיר את המקור העיקרי לתקלות בעת עריכות.
• מדיניות גישה — תפקידים והרשאות לפי עקרון המינימום ההכרחי: בנפרד עבור חשבונות שירות של פריסה, בנפרד עבור מהנדסים, בנפרד עבור ביקורת. המפתחות הוצאו מהקונפיגורציות אל מאגר סודות מאובטח.
• הוראות פריסה — סדר שלב אחר שלב: הכנת הסביבה, בדיקת פרמטרים, הרצה, בדיקת התוצאה. לפיהן מהנדס חדש מקים סביבה מאפס, בלי להתעמק במבנה של כל תבנית.
• נוהל rollback — מה לעשות בפריסה כושלת: כיצד לחזור לגרסת הקונפיגורציה הקודמת, אילו משאבים נמחקים, אילו נשארים, כיצד לבדוק שלמות לאחר ה-rollback. זמן היעד לחזרה למצב עבודה — דקות, ולא שעות של עריכות ידניות.
• מפת ניטור — אילו מדדים ובדיקות משויכים למשאבים שנוצרו, לאן מגיעות התראות ומי מגיב.
• יומן שינויים — תיעוד של מה, מתי ולמה השתנה בתשתית, עם שיוך למשימות.

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

מקרה בוחן: קיצור זמן הפריסה פי שלושה

מה היה לפני

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

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

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

מה שינו

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

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

מה נהיה

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

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

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

במה שונה Deployment Manager מניהול ידני?

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

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

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

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

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

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

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

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

ספקות טכניים לפני תחילת העבודה

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

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

מה עושים עם משאבי legacy שאיש לא נגע בהם שנים?

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

לאחר מכן משאבים כאלה либо מוחלפים בהדרגה במשאבים מנוהלים, либо נשארים בבידוד עד להוצאה מתוכננת — ההחלטה מתקבלת לגבי כל אחד בנפרד, ולא בבת אחת.

אילו סיכונים נושאת האוטומציה וכיצד מכסים עליהם?

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

בנוסף, ניהול גרסאות של התצורה — כל שינוי מותיר עקבות, מי ומדוע ביצע אותו, וחזרה לגרסה קודמת אורכת דקות ולא שעות של עבודה ידנית.

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

נדון במשימה שלכם ונחזור עם תוכנית

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

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

מה תקבלו בסופו של דבר:

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

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

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