פיתוח Terraform provider: היכן נשברת האוטומציה
כל עוד שירותים פנימיים מתוארים ידנית — בוויקי, בטבלה או בהערה ליד הקוד — התשתית חיה בנפרד מהתיאור הזה. שינוי מבוצע על ידי מהנדס דרך לוח בקרה, ובמסמך הוא מופיע אחרי שבוע או לא מופיע כלל.
כבר אחרי שניים-שלושה ריליסים איש לא יכול לומר בביטחון איזו תצורה נמצאת כעת בסביבת הייצור ולמה היא בדיוק כזו.
אי-התאמה בין התצורה למציאות נחשפת ברגע הכי לא נוח: בשחזור, בהעברה לסביבה אחרת, בחקירת תקרית. סקריפט ש"תמיד עבד" נשען על תיקון ידני מלפני חצי שנה, ששוכח אפילו מי שכתב אותו. השחזור הופך לארכיאולוגיה, והרמת סביבת ייצור מאפס מתבררת כארוכה יותר מתיאום חלון השבתה.
פיתוח Terraform provider סוגר את זה אחרת: שירותים פנימיים מתוארים באופן הצהרתי, באותה דרך שבה מתארים משאבי ענן, ונכנסים למקור אמת אחד של התשתית. כל סטייה של התוכנית מהמצב בפועל נראית לפני ההחלה, ולא אחריה. תיקון ידני מפסיק להיות אנונימי — הוא או נכנס לתיאור, או מתבטל בהחלה הבאה.
בהמשך נפרט איך זה בנוי: אילו ישויות כדאי להוציא למשאבים ולמקורות נתונים, איך לבנות אוטומציה לניהול תשתית בלי תיקונים ידניים, ומה לעשות עם פער שכבר הצטבר.
מה נותן שכבה אחודה לניהול שירותים פנימיים
provider משלכם הופך שירותים פנימיים למשאב הצהרתי בדיוק כמו משאבי ענן: שכבה אחודה לניהול, שבה תיאור השירות חי במאגר הקוד, מוחל דרך Terraform ועובר בדיקת קוד. בהמשך — השלכות מדידות, שנראות כבר בשבוע הראשון.
תיאור אחוד במקום תיקונים ידניים
מקור האמת אחד: סביבות השירות, הרשאות, סודות ונקודות ניטור מתוארים בקובץ אחד. כל שינוי עובר תוכנית ההחלה, ופער בין התיאור למצב בפועל נראה לפני פריסה, ולא אחרי תקלה.
שירות חדש מיוצר לפי תבנית: הכנת סביבה אורכת החלה אחת במקום ימים של פעולות ידניות, וסוג שלם של כשלים — "תיקנו ידנית ושכחנו לתעד" — נעלם.
הפרדת הרשאות וסביבות כברירת מחדל
תפקידים, גבולות של סביבות ורמות גישה מוטמעים בתוך ה-provider עצמו, ולא בהוראה בוויקי. מפתח מתאר שירות, אבל לא יכול להעניק לעצמו הרשאות מיותרות או לפגוע בסביבה של אחר — הניסיון נחסם בשלב התוכנית.
שחזור אחרי תקלה הופך להחלה של תיאור מוכר: הסביבה מתרוממת מהתצורה בדקות, ולא נבנית מהזיכרון של התורן, והתוצאה תואמת למקור.
שינויים צפויים בסביבות, פחות פעולות ידניות, הוצאת שירות חדש מהירה יותר ושחזור — אלו אפקטים של שכבה אחת, ולא של סט סקריפטים מפוזרים.
השוואת גישות: סקריפטים, תבניות, עטיפה או שכבה משלכם
מה לבחור קובע לא הטעם, אלא מספר השירותים הפנימיים שצריך לתאר באופן הצהרתי, ומי יתחזק את התיאורים האלה בעוד חצי שנה. להלן — חלופות אמיתיות שצוותים בוחרות ביניהן, עם המגבלות שלהן.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| סקריפטים והוראות ידניים | מתחם חד-פעמי, שירות אחד או שניים | המצב לא מנוטר, סביבות נפרדות זו מזו, שחזור ידני |
| תבניות תצורה | שירותים טיפוסיים עם הבדלים נדירים | עותקים נערכים ידנית, תוכנית השינויים לא נבדקת |
| עטיפה מעל כלי קיים | כניסה אחודה מעל ליבה קיימת | לא מנהלת מחזור חיים של משאב, חלק מהפרמטרים לא נגישים |
| שכבת אוטומציה משלכם מאפס | מודל המשאבים ייחודי, כלים מוכנים לא מתאימים | מצב, ייבוא ושחזור נעשים בכוחות עצמכם |
| הרחבה של פתרון קוד פתוח | המודל קרוב למוכן, חסרים חלק מהיכולות | תלות בקוד חיצוני, תיקונים מועברים בעדכונים |
מתי מספיקות תבניות וסקריפטים
כל עוד יש מעט שירותים, שתי סביבות, והתצורה משתנה פעם ברבעון, הצירוף "תבנית והוראה" עולה פחות ונקרא מהר יותר. הגבול מגיע כשמספר העותקים גדול ממספר האנשים: פערים בין סביבות מחפשים ידנית, ושחזור מתחם אחרי תקלה הופך למשימה נפרדת.
מתי בלי שכבה משלכם אי אפשר
אם לשירות יש מחזור חיים עצמאי, תלויות בין אובייקטים וכללים שאין בכלים מוכנים, לא תבנית ולא עטיפה יחזיקו אותם. אז מתחיל פיתוח Terraform provider: מתארים משאבים, בדיקות לפני החלה וייבוא של אובייקטים קיימים, כדי ששינויים יעברו בצורה צפויה והמצב לא ייפרד מהמציאות.
שלבי העבודה: מביקורת תשתית ועד מסירת קוד
את העבודה מובילים באיטרציות קצרות: קודם מתעדים את מה שנעשה כעת ידנית, אחר כך מעבירים אותו ל-provider ובודקים בסביבת בדיקות. סדר כזה מאפשר לשנות תשתית בלי לעצור שירותים ולא משאיר את הצוות לבד עם קוד לא מובן.
מה מתעדים בכניסה
מפרקים את רשימת השירותים, הסביבות ותפקידי הגישה: מה נוצר ידנית, מה כבר אוטומטי, ואיפה התיאורים סוטים מהמצב בפועל. בנפרד אוספים אילוצים — כללי אבטחה, סדר אישור שינויים, דרישות ביקורת. בפלט מקבלים מפת משאבים ורשימת פערים בהרשאות, ולא תיאור כללי של "איך הכול בנוי".
- ביקורת תשתית והרשאות: ספירת שירותים והרשאות, השוואת המצב בפועל לתיאורים.
- סכימת התיאור הרצוי: אילו ישויות הופכות למשאבים ולמקורות נתונים, ואיך הן קשורות זו לזו.
- פיתוח והגדרה של ה-provider: מימוש משאבים, ייבוא אובייקטים קיימים, טיפול נכון בשינויים ובמחיקה.
- בדיקה בסביבת בדיקות: יצירה, שינוי ושחזור על עותק של הסביבה, השוואת התוכנית לתוצאה הצפויה.
- הפעלה ניסיונית: הצוות עובד דרך הכלי החדש באזור מוגבל, ואנחנו מלווים ומתקנים לפי הערות.
- מסירה והדרכת הצוות: מעבר על הקוד, סדר הפריסה והעדכון, ונוהל חקירת תקלות.
איך בודקים תוצאה לפני מסירה
מוסרים לא "סקריפט שעובד", אלא מחזור משוחזר: תוכנית השינויים תואמת למצופה, הרצה חוזרת לא מייצרת פעולות מיותרות, ושחזור מחזיר את התצורה למצבה הקודם. קריטריון מוכנות נפרד — צוות הלקוח מבצע בעצמו שינוי טיפוסי בלי רמז מאיתנו.
ארטיפקטים במאגר: קוד, סכימות, נהלים, הרשאות
מוסרים לא רק קוד שעובד, אלא את כל המסגרת שמאפשרת לצוות שלכם לחיות איתו בלעדינו: מתיאור השירותים ועד הוראות למשמרת תורנית. להלן — מה בדיוק נשאר במאגר לאחר סיום העבודה.
קוד ותיאור תשתית
- קוד המקור של Terraform provider עם תיאור של כל משאב ומקור נתונים: אילו פרמטרים חובה, אילו מחושבים, ואיך מטפלים בקונפליקטים בשינוי.
- תצורות סביבות — סטים נפרדים של פרמטרים ומצבים מבודדים, כדי שבדיקה לא תוכל לפגוע בסביבת הייצור.
- מודולים מוכנים לשירותים טיפוסיים: חיבור שירות חדש מצטמצם לכמה שורות במקום העתקה של קובץ של אחר בשלמותו.
- סט בדיקות ודוגמאות שימוש — ארגז חול שבו רואים איך המשאב מתנהג ביצירה, בשינוי ובמחיקה.
סכימות ונהלים לצוות
- סכימות קשרים בין שירותים, סביבות ומערכות חיצוניות: בעמוד אחד רואים מה תלוי במה ומה ישפיע על שינוי.
- מדיניות גישה ותפקידים — מי קורא מצב, מי משנה, מי מחיל שינויים בסביבת הייצור; ההפרדה מוטמעת בקוד ונבדקת אוטומטית.
- נוהל שינויים: סדר הוצאה של גרסה חדשה, כללי תאימות לאחור ונוהל שחזור.
- הוראות למשמרת תורנית: כשלים טיפוסיים, איך להבדיל אותם מתקלת תשתית ומה לעשות שלב אחר שלב.
מקרה בוחן: 40 שירותים תחת ניהול Terraform במקום תיקונים ידניים
אלינו הגיע צוות שבו 40 שירותים פנימיים חיו בכמה סביבות, וכל סביבה נבנתה ידנית. העברנו הכול לתיאור תשתית אחוד ב-Terraform ופיתחנו provider לשירותים פנימיים — עבור אותן ישויות שלא היו עבורן משאבים מוכנים.
מה היה לפני
הוצאת שירות חדש ארכה שניים-שלושה ימים: מהנדס הקים רשת, מאזן עומסים, בסיסי נתונים, תורים והרשאות לפי הוראה בת 30 שלבים. בריליס היו 15-20 תיקונים ידניים, וחלקם סתרו את מה שכבר עבד בייצור — הסביבות בהדרגה נפרדו זו מזו.
שחזור אחרי תקלה נתקע בכך שאיש לא ידע בדיוק את התצורה העדכנית: היא נבנתה מלוגים ומסקרים של שירותים. בערך מחצית התקריות נבעו לא משגיאה בקוד, אלא מפער בהגדרות.
מה היה אחרי
השירות מתואר בקובץ במאגר משותף, וה-provider מביא את התשתית למצב הרצוי. הוצאת שירות חדש הצטמצמה ל-40 דקות, תיקונים ידניים בריליס ירדו ליחידים במקום 15-20, וכולם עוברים בדיקה כמו קוד.
שחזור סביבה ושחזור לאחור נעשים מהתיאור, ולא מהזיכרון של המהנדס: תצורה תקולה מחזירים בדקות במקום שעות. סוג הכשלים "התצורה התפצלה בין סביבות" נעלם — פערים נראים בשלב בדיקת התוכנית לפני ההחלה, ולא בייצור.
מה לעשות אם התשתית כבר מתוארת ידנית?
אין צורך לכתוב הכול מחדש בבת אחת — בדיוק על זה פרויקטים כאלה נעצרים. סביבות שכבר הוגדרו ידנית ממשיכות לעבוד, והתיאור מוכנס לצידן: קודם הוא רק קורא את המצב הנוכחי ובונה תוכנית שינויים, בלי להחיל דבר. כל עוד התוכנית מראה פערים, הניהול נשאר בידי האנשים.
השלב הראשון — ייבוא משאבים קיימים: כל אובייקט נקשר לתיאור ונכנס לקובץ המצב, אבל התצורה עצמה לא משתנה. מטרת השלב — תוכנית ריקה: כלומר, התיאור תואם בדיוק למציאות וההרצה הבאה לא תמחק סביבה עובדת. פערים מפרקים אחד-אחד — בדרך כלל אלו מאפיינים שהוגדרו ידנית ונשכחו.
סדר ההעברה כפוף לרדיוס הפגיעה. ראשונים עוברים שירותים בלי מצב ותעבורה חיצונית — תורים, מטמונים, מתחמי בדיקה: שם שגיאה עולה הפעלה מחדש, ולא השבתה. אחר כך רשתות, איזון עומסים והרשאות גישה, ואחר כך אחסון עם נתונים. מה שמחזיק תעבורה עובר אחרון ואחד-אחד — אז השחזור מוגבל לרכיב אחד.
ההפעלה ההדרגתית נראית כך: השירות מתואר, מיובא, התוכנית ריקה — ורק אז הניהול עובר לתיאור, והתיקונים הידניים דרך הממשק נסגרים. בין השלבים מתעדים תוצאה: כמה אובייקטים בניהול, אילו פערים נעלמו, כמה שירותים עברו השוואה עם תוכנית ריקה. כך המעבר נעשה בלי עצירה ובלי מתג גדול אחד, שאחריו בדרך כלל קורות תקלות.
ספקות טכניים: מצב, הרשאות, שחזור, תמיכה
הספקות שעולים לפני פיתוח Terraform provider הם בדרך כלל אותם ספקות: איפה חי המצב, מי רשאי להחיל שינויים, איך משחזרים ומה יקרה אחרי מסירת הקוד. להלן — תשובות קצרות; פרטים נפרק בשיחה לפי המשימה שלכם.
איפה נשמר המצב ומי נועל שינויים?
המצב יושב באחסון מרוחק עם נעילה בזמן ההחלה: סביבה אחת משנה רק מהנדס אחד. הסביבות מופרדות בסטים נפרדים ובגישה דרך חשבונות שירות, והיסטוריית גרסאות המצב נשמרת.
מי רשאי לשנות תשתית?
תוכנית בונה כל מהנדס בצוות, ההחלה זמינה רק לתפקיד עם אישור, וסביבת הייצור מופרדת מהבדיקות. כל החלה משאירה רשומה: מי, מתי ומה שינה.
איך בנוי שחזור של שינוי בסביבה?
לפני ההחלה התוכנית מציגה את כל השינויים, כולל מחיקת משאבים. השחזור נשען על גרסת provider מתועדת ותמונת מצב; משאבים עם נתונים לא נוצרים מחדש בתהליך.
מה יקרה כשממשקי השירותים משתנים?
גרסה חדשה יוצאת לצד הישנה, ולכן תצורות פעילות ממשיכות לעבוד. שדות מיושנים מסומנים באזהרה בזמן בניית התוכנית, והמעבר נעשה בייבוא משאבים בלי מחיקה ויצירה מחדש.
מי מתחזק את הקוד אחרי המסירה?
מוסרים מאגר, בדיקות לסכימה ולהתנהגות, תיעוד למשאבים וסדר הוצאת גרסה. מהנדסי הלקוח מתרגלים את התהליך על המשימות שלהם, וליווי והרחבות נסגרים בהסכם נפרד.
נדבר על המשימה: ננתח את התשתית ונחזור עם תוכנית
הערכה מדויקת של לוחות זמנים והיקף עבודה ל-provider מותאם אישית אפשרית רק אחרי ניתוח המצב הנוכחי של התשתית. תארו את המשימה — אילו שירותים פנימיים צריך להעביר לניהול הצהרתי, בגבולות אילו סביבות הם חיים ואילו אילוצי זמנים כבר קיימים.
מצדנו ננתח תצורות, הפרדת מצבים ותפקידי גישה, ואז נחזור עם תוכנית עבודה ופריסת שלבים לפי לוחות זמנים.
מה עוזר לנו לבנות הערכה נכונה:
- רשימת שירותים פנימיים והממשקים שלהם — מה כבר מספק קריאות ניהול, ומה יהיה צריך לעטוף;
- גבולות הסביבות: כמה סביבות, איך נבדלים הפרמטרים, ואיפה עובר הגבול בין סביבת בדיקות לסביבת ייצור;
- אחסון המצב הנוכחי: איפה נמצא קובץ המצב, למי יש גישה אליו, והאם יש נעילות לשינויים במקביל;
- דרישות להרשאות: אילו חשבונות ותפקידים ניתנים ל-provider, מי אחראי על רוטציית הרשאות, ואילו פעולות דורשות אישור;
- אילוצים ולוחות זמנים: תאריכים קשיחים, הקפאות שינויים, חלונות תחזוקה, דרישות לשחזור;
- הרכב המאשרים: מי בצד הלקוח מאשר את סכימת המודולים ואת קביעת המוכנות.
אחרי הניתוח נחזור עם תוכנית: רצף השלבים, הרכב הצוות, נקודות שבהן תוכלו לבדוק תוצאה ביניים במתחם שלכם, וסדר מסירת המאגר והתיעוד למהנדסים שלכם. אם חלק מהשירותים עדיין לא מוכנים לניהול מהקוד, נאמר זאת ישירות ונציע מאיפה להתחיל כדי לא לחסום את השאר.
מוכנים להתחיל בשיחה קצרה לעניין: תארו את משימת האוטומציה — נחזור עם הערכה ותוכנית.