תשתיות כקוד (IAC) בצינורות ה-DevOps

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

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

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

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

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

תשתיות כקוד (IaC): באמצעות דוגמה

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

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

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

התבנית

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

{
	"VM": {
        "Name": "MYVM",
        "Disk": {
            "Size": "100GB"
        },
        "Networking": {
            "IPAddress" : "10.0.0.1"
        }
    }
}

תבנית זו מגדירה את המכונה הווירטואלית ואת כל התכונות הקשורות אליה. יש לה סכימה מסוימת שקובעת לכותבי התבנית איך ייראה המכונה הווירטואלית. שניים ניתן לשמור את התבנית הזו בקובץ בשם myvm.json.

בקרת גרסאות

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

הכלי

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

> [some command line tool] -File myvm.json

עסק טוב, נכון? אבל זה לא הכל.

מאבק נגד סיוף התצורה

עכשיו נניח שאתה צריך לשנות את כתובת ה-IP הסטטית שמוקצה לממשק הרשת של המכונה הווירטואלית הזו. ניתן להתחבר באמצעות RDP למכונה הווירטואלית ולשנות את ה-IP, אבל אתה לא רוצה לעשות זאת. למה?

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

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

פתח את myvm.json, שנה את תכונת IPAddress, ייחד את השינוי בקובץ ניהול הקוד המקורי והפעל את הכלי שוב. וזהו.

{
	"VM": {
        "Name": "MYVM",
        "Disk": {
            "Size": "100GB"
        },
        "Networking": {
            "IPAddress" : "10.0.0.2"
        }
    }
}

> [some command line tool] -File myvm.json

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

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

אבל חכה, יש עוד.

ההתחלה של מסירה רצופה

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

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

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

סיכום

IaC הוא מתודולוגיה של DevOps שמאפשרת לפעולות ללכת לקחת מהמדריך של מפתח התוכנה. IaC מביאה עם יתרונות רבים שמפתח תוכנה ניהל לאורך שנים ומעבירה אותם לידי המנהלי מערכת.