הגדרת GCP Cloud Run: פריסת מכולות עם CI/CD ו-VPC

הגדרת Cloud Run: היכן נכשל פריסת הקונטיינרים

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

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

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

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

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

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

מה נותן הפעלה מנוהלת של קונטיינרים

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

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

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

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

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

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

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

אפשרויות פריסה: שירות, משימה, מכונות וירטואליות

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

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

כיצד אנו בוחרים בפועל

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

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

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

שלבי הגדרה: מביקורת ועד מסירה לתמיכה

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

1. ביקורת תשתית. מנתחים את הסכמה הנוכחית: כיצד נבנות תמונות, היכן נמצא המאגר, מהן ההרשאות של חשבונות שירות, מה כבר עובד בייצור. בפלט — מפת תלויות ורשימת צווארי בקבוק.
2. סכמת סביבות. מתכננים הפרדה של dev, stage ו-prod: פרויקטים נפרדים, חשבונות שירות משלהם, תצורה דרך משתני סביבה ומנהל סודות במקום ערכים בתוך התמונה. מפתח בדיקה אחרי זה לא ייסע לייצור.
3. בנייה ושחרור. בונים קונטיינר, מפרסמים במאגר, מגדירים צינור: בדיקות לכל ענף, אישור ידני לפני ייצור, שחרור גרסה חדשה של Cloud Run עם העברה הדרגתית של תעבורה.
4. מתאר רשת. מחברים את השירות לרשת פרטית: מחבר, כללי תעבורה יוצאת, גישה למסד נתונים רק לפי כתובות פנימיות — מסד הנתונים מפסיק להיות גלוי מבחוץ.
5. תרחישי בדיקה. מריצים התחלה קרה, כשל של גרסה, חזרה לגרסה קודמת, סבב סודות וחוסר נגישות של תלות חיצונית. כל תרחיש נשאר בדיקה ניתנת לשחזור, ולא בדיקה ידנית חד-פעמית.
6. מסירה לתפעול. מוסרים לצוות את סכמת הסביבות, מדיניות גישה, מדדים והתראות, סדר חזרה. את הלמידה מנהלים על שחרור חי — המהנדסים עוברים את המחזור בעצמם.

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

ערכת מסירה: תצורות, סכמות, תקנות

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

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

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

מקרה בוחן: הסרנו השבתות בעת עדכון שירות

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

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

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

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

תוצאה במספרים

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

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

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

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

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

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

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

ספקות טכניים: גישה, קנה מידה, חזרה

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

כיצד מוגבלת תעבורה פנימית בין שירותים?

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

כיצד מבוצעת חזרה מגרסה כושלת?

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

האם חשבונות הסביבות מופרדים?

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

מה קורה בעת עדכון שירות פעיל?

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

נדון במשימה: נבנה סכמה ותוכנית הטמעה

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

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

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