מה זה Infrastructure as Code? הסבר + משרות בישראל

תשתית כקוד היא הגישה שבה כל רכיב תשתית - שרת, רשת, מסד נתונים, הרשאה - מוגדר בקובץ טקסט שנשמר בגיט, במקום להיווצר בלחיצות בממשק הענן. הקובץ הוא מקור האמת, והמערכת מתאימה את המציאות אליו. בלוח HiTakeJob פתוחות כרגע 47 משרות שמזכירות Terraform, 123 שמזכירות AWS ו-123 שמזכירות Kubernetes.

מה הבעיה שזה פותר

בלי זה, התשתית נוצרת ידנית - וזה מייצר ארבע בעיות שכל ארגון מכיר:

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

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

איך זה עובד בפועל

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

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

איך נראה תהליך שינוי תשתית בצוות בוגר

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

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

מה זה סחיפת תצורה

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

שלוש דרכים מקובלות להתמודד:

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

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

שני סוגי כלים שמתבלבלים ביניהם

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

השורה האחרונה מסבירה שינוי בשוק: כשהאפליקציה ארוזה בקונטיינר, אין הרבה מה להגדיר בתוך המכונה. לכן הביקוש התרכז בקטגוריה הראשונה - 47 משרות מזכירות Terraform, לצד 12 שמזכירות Helm לניהול פריסות.

איך כותבים קוד תשתית שאפשר לתחזק

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

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

איפה זה נוגע גם למי שאינו איש תשתית

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

מה זה אומר למי שלומד את התחום

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

סדר הלמידה המומלץ הוא ענן תחילה, אחר כך הכלי, ואז מודולים ותהליכי עבודה. ההקשר הרחב מפורט במה זה DevOps ובמה זה Platform Engineering, ואפשר לראות משרות במשרות Terraform ובמשרות AWS.

שאלות נפוצות

מה ההבדל בין זה לבין סקריפט שמקים תשתית?

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

זה מתאים גם לארגון קטן?

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

מה עושים עם תשתית שכבר קיימת?

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

האם צריך לדעת לתכנת?

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

כמה משרות דורשות את זה בישראל?

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

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

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

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

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