תשתית כקוד: היכרות ראשונה

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

המשך לסדרת מאמרים שנכתבו על סמך נאומים באירוע הפנימי שלנו DevForum:

1. החתול של שרדינגר ללא קופסה: בעיית הקונצנזוס במערכות מבוזרות.
2. תשתית כקוד. (אתה כאן)
3. יצירת חוזי Typescript באמצעות מודלים של C#. (בתהליך...)
4. מבוא לאלגוריתם הקונצנזוס של Raft. (בתהליך...)
...

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

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

• תאר את התשתית שלנו, שנמצאת בעיקר ב-Microsoft Azure בצורה של קוד (Terraform וכל מה שמסביב).
• למד מפתחים כיצד לעבוד עם תשתית.
• הכן מפתחים לתפקיד.

אנו מציגים את המושג Infrastructure כקוד

במודל הרגיל של העולם (מינהל קלאסי), הידע על תשתיות ממוקם בשני מקומות:

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

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

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

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

כך, תשתית כקוד (Incfastructure as Code - IaC) היא תיאור של כל התשתית הקיימת בצורת קוד, וכן כלים נלווים לעבודה איתה והטמעת תשתית אמיתית ממנה.

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

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

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

בעיות תשתית כקוד

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

קוד לדוגמה מ- Terraforma.

קוד לדוגמה מ-Ansible.

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

1. הבעיה הראשונה היא שברוב המקרים IaC הוא סוג של dsl.

ו-DSL, בתורו, הוא תיאור של המבנה. ליתר דיוק, מה צריך להיות לך: Json, Yaml, שינויים מכמה חברות גדולות שהגיעו עם dsl משלהם (HCL משמש ב-terraform).

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

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

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

זה מצב מאוד אמיתי כאשר bash עם python משיק תהליך כלשהו שלתוכו מוכנס Json. אתה מנתח את זה, ואז מחולל אחר מייצר עוד 30 קבצים. על כל זה, משתני קלט מתקבלים מ-Azure Key Vault, הנשלפים יחדיו על ידי תוסף עבור drone.io שנכתב ב-Go, ומשתנים אלו עוברים דרך yaml, שנוצרה כתוצאה מהיצירה ממנוע ה-jsonnet template. זה די קשה לקבל קוד מתואר היטב כאשר יש לך סביבה כל כך מגוונת.

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

3. הבעיה השלישית היא כוונון. אנחנו רגילים לעורכים מגניבים (Ms Visual Studio, Jetbrains Rider) שעושים הכל בשבילנו. וגם אם אנחנו טיפשים, יגידו שאנחנו טועים. זה נראה נורמלי וטבעי.

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

בזמן כתיבת שורות אלה תוסף vscode-terraform עדיין לא שוחררו לתמיכה בגרסה 0.12, למרות שהיא שוחררה כבר 3 חודשים.

הגיע הזמן לשכוח...

1. ניפוי באגים.
2. כלי לשחזור.
3. השלמה אוטומטית.
4. איתור שגיאות במהלך הקומפילציה.

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

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

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

מה עם המבחנים?

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

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

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

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

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

שיטות עבודה מומלצות תשתית כקוד

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

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

באשר לבקשת IaC: כאן אתה מנסה לאסוף מידע טיפין טיפין מדוחות עומס גבוה או HashiConf, מתיעוד רשמי ומבעיות רבות ב-Github. איך להפיץ את המודולים האלה באופן כללי, מה לעשות איתם? נראה שזו בעיה אמיתית... יש קהילה, רבותיי, שבה לכל שאלה יינתנו 10 תגובות ב-Github. אבל זה לא בדיוק.

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

לאן כל זה הולך ומה לעשות

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

באופן אישי, אני מהמר על כמה דברים:

1. ההתפתחות בתחום הזה מתרחשת מהר מאוד. להלן לוח זמנים של בקשות ל-DevOps.

   
   
   אולי הנושא הוא הייפ, אבל עצם העובדה שהתחום גדל נותן קצת תקווה.

   אם משהו גדל כל כך מהר, אז בהחלט יופיעו אנשים חכמים שיגידו לך מה לעשות ומה לא לעשות. העלייה בפופולריות מובילה לכך שאולי למישהו יהיה זמן להוסיף סוף סוף תוסף ל-jsonnet עבור vscode, שיאפשר לכם לעבור ליישום הפונקציה, במקום לחפש אותה באמצעות ctrl+shift+f. ככל שהדברים מתפתחים, מופיעים חומרים נוספים. הוצאת ספר מגוגל על ​​SRE היא דוגמה מצוינת לכך.

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

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

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

מסקנה

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

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

מקור: www.habr.com