מה זה Infrastructure as Code, ולמה תשתית צריכה להיות קוד¶
תדמיינו מצב שקורה בהרבה חברות, אפילו היום. מישהו בצוות נכנס לקונסולה של AWS, לוחץ כמה כפתורים, מקים שרת עם הגדרות מסוימות, וזהו - זה עובד. חצי שנה אחר כך, השרת נופל, וצריך להקים אותו מחדש. הבעיה? אף אחד לא זוכר בדיוק אילו הגדרות נבחרו אז. הידע נמצא רק בזיכרון של מי שלחץ על הכפתורים, וגם הוא לא זוכר הכל. Infrastructure as Code, או בקיצור IaC, נולד בדיוק כדי לפתור את הבעיה הזאת.
הבעיה עם "להקים תשתית בלחיצת כפתור"¶
הקמת תשתית דרך ממשק ניהול גרפי (מה שנקרא Click Ops בעגה מקצועית, בלגלוג) נראית נוחה בהתחלה, אבל היא נושאת כמה בעיות כואבות שמצטברות עם הזמן:
- אין תיעוד אמיתי. מה בדיוק הוגדר? למה נבחרו ההגדרות האלה? אין תשובה מלבד "תשאלו את דני, הוא זה שהקים את זה".
- אי אפשר לשחזר בקלות. אם השרת נופל או צריך להקים סביבה זהה לבדיקות, צריך לעבור שוב על כל הצעדים הידניים, וקל מאוד לפספס פרט קטן.
- אין היסטוריית שינויים. מי שינה מה ומתי? אם משהו נשבר אחרי שינוי הגדרות, קשה לדעת בדיוק מה השתנה.
- קל לטעות. אצבע רועדת, כפתור לא נכון, וטעות אנוש קטנה יכולה להוביל לחשיפת אבטחה או לתשתית שלא עובדת כמו שצריך.
הפתרון - תשתית שכתובה כקוד¶
הרעיון של Infrastructure as Code הוא פשוט להפליא: במקום ללחוץ כפתורים בממשק, כותבים קובץ טקסט שמתאר בדיוק איך התשתית אמורה להיראות - כמה שרתים, אילו הגדרות רשת, אילו הרשאות. הקובץ הזה הוא בעצם קוד, ומכאן השם. ואז מריצים כלי שקורא את הקובץ הזה, ובונה בדיוק את התשתית שהוא מתאר.
זה משנה הכל, כי פתאום התשתית מקבלת את כל היתרונות שכבר מזמן יש לקוד רגיל:
- בקרת גרסאות. הקובץ נשמר בגיט, בדיוק כמו קוד אפליקציה. רואים בדיוק מי שינה מה ומתי, ואפשר לחזור אחורה אם משהו השתבש.
- שחזור מיידי. צריך סביבת בדיקות זהה לייצור? מריצים את אותו קובץ, ומקבלים תשתית זהה תוך דקות.
- סקירת קוד. לפני שמשנים תשתית ייצור, מישהו אחר יכול לעבור על השינוי המוצע ולוודא שהוא הגיוני, בדיוק כמו שעושים עם קוד אפליקציה.
- תיעוד אוטומטי. הקובץ עצמו הוא התיעוד. אין צורך במסמך נפרד שמתיישן תוך שבועיים.
איך זה נראה בפועל¶
הכלי הכי מוכר בעולם הזה הוא Terraform, שמאפשר לתאר תשתית בשפה קריאה יחסית, ועובד עם כל ספקי הענן הגדולים. כותבים קובץ שאומר משהו כמו "אני רוצה שרת מסוג כזה, עם דיסק בגודל כזה, ברשת הזאת, עם ההרשאות האלה", ומריצים פקודה. הכלי משווה בין מה שכתוב בקובץ לבין מה שקיים בפועל, ומבצע בדיוק את השינויים הדרושים כדי שהמציאות תתאים לתיאור.
היתרון הגדול הוא שאם מחר צריך להקים סביבה זהה - למשל סביבת בדיקות שמדמה את הייצור - זה עניין של הרצת אותו קובץ שוב, ולא של זיכרון אנושי ותיעוד ישן.
למה זה כל כך חשוב בעבודה של DevOps¶
בלי IaC, כל שינוי בתשתית הוא אירוע מלחיץ שתלוי במישהו ספציפי שזוכר איך הדברים בנויים. עם IaC, השינוי עצמו הופך לתהליך רגיל ומבוקר - מישהו כותב שינוי בקוד, מישהו אחר סוקר אותו, ורק אז הוא מיושם. זה בדיוק אותו תהליך עבודה שכבר מוכר לכם מכתיבת קוד רגיל, רק שהתוצר הוא שרתים ורשתות במקום פיצ'רים באפליקציה.
זו גם הסיבה ש-IaC נחשב היום למיומנות ליבה בכל תפקיד DevOps רציני. תשתית שלא כתובה כקוד היא תשתית שקשה לסמוך עליה, קשה לתחזק, וקשה לגדול איתה.
איך מתחילים ללמוד את זה¶
כמו כל דבר בתחום הזה, הדרך הנכונה ללמוד היא לא רק לקרוא, אלא לכתוב קובץ IaC אמיתי ולהריץ אותו על חשבון ענן אמיתי, ולראות איך תשתית שלמה קמה מקובץ טקסט. זה בדיוק מה שאנחנו מלמדים בפרק ה-IaC בקורס צד-שרת שלנו - מהרעיון הבסיסי ועד להרצה אמיתית.
קורס צד-שרת מלמד את זה בעברית, בחינם, עם תרגול מעשי שלא מדלג על שום שלב.
יש לכם שאלות בדרך? הצטרפו לקהילה שלנו בדיסקורד ותקבלו עזרה מאנשים שכבר עשו את זה.
לסיכום¶
Infrastructure as Code הוא המעבר מהקמת תשתית בלחיצות כפתור ידניות, לתיאור התשתית כקובץ קוד שאפשר לגרסא, לסקור ולשחזר. זה נותן לתשתית את כל היתרונות שכבר מזמן מוכרים לכם מכתיבת קוד - שקיפות, מעקב אחרי שינויים, ויכולת לשחזר כל דבר בלחיצת כפתור אחת. אם אתם רוצים לעבוד ברצינות בתחום התשתיות והענן, זו לא מיומנות אופציונלית - זו נקודת התחלה בסיסית.