תשתית כקוד (IaC) באמצעות Azure Bicep

Azure Bicep: היכן הגדרה ידנית של תשתית נכשלת

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

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

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

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

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

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

מה משתנה לאחר המעבר לתיאורי תשתית

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

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

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

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

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

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

Azure Bicep וגישות חלופיות: השוואה

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

מה זה נותן בפועל

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

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

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

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

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

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

תצורות, סכמות ותקנות שתקבלו

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

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

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

מקרה בוחן: העברת סביבות לתיאורי תשתית

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

את סיבת התקלה חיפשו באפליקציה, בעוד שהסביבה היא שנשברה, ולהקמת מעמד חדש נדרשו 2-3 ימים של פעולות ידניות.

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

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

• הקמת מעמד חדש: היה 2-3 ימים של פעולות ידניות עם המתנה לאישורים — הפך ל-40-50 דקות מההרצה.
• אירועים בגלל תצורה: כ-5-6 ברבעון — אף אחד חדש בחצי שנה; סטיות מתגלות על ידי בדיקת התיאורים לפני היישום.
• חזרה למצב הקודם: היה שחזור מגיבוי ובדיקה ידנית במשך כמה שעות — הפך להחלה חוזרת של התיאור הקודם תוך 10-15 דקות.

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

במה תיאור דקלרטיבי שונה מסקריפטים ידניים?

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

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

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

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

ספקות טכניים נפוצים לפני תחילת הפרויקט

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

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

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

איך לוודא ששינוי לא ישבור דבר?

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

מה קורה לאחר מסירת הפרויקט?

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

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

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

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

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