הגדרת צינור CI/CD באמצעות Spacelift: אוטומציה של תשתית כקוד

הגדרת Spacelift: מדוע עריכות ידניות שוברות את השחרור

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

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

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

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

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

מה משתנה כאשר התשתית מתוארת בקוד

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

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

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

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

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

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

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

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

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

מה לשקול בעת הבחירה

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

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

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

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

מה נשאר אצלכם: תצורה, סכימות, נהלים

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

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

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

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

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

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

מדידות לפני ואחרי

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

מה לעשות אם התשתית כבר פרוסה ידנית

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

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

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

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

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

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

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

כיצד מתמודדים עם סודות והרשאות?

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

כיצד מחזירים לאחור שינוי שהוחל?

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

האם כמה צוותים במאגר אחד לא מפריעים זה לזה?

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

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

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

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

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

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

תארו את המשימה — נחזור עם הערכה ותוכנית.