יצירת תשתית כקוד באמצעות בינה מלאכותית: Terraform, Ansible, K8s

יצירת IaC עם AI: היכן נשברת תשתית ידנית

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

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

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

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

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

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

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

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

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

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

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

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

איך לבחור מצב

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

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

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

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

החבילה בפלט: מרשם מודולים, סכמות סביבות, נהלים

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

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

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

כיצד הצטמצמה סחיפת התצורה: תוצאות ההטמעה לפני ואחרי

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

מה שינו

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

מה נהיה

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

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

במה שונה גישת התבנית מהרכבה לפי תיאור שירות?

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

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

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

ספקות טכניים: מגבלות, אבטחה, תמיכה בסביבות

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

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

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

האם סודות ייכנסו לקוד שנוצר?

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

מי מתחזק את התצורות לאחר המסירה?

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

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

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

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

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