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

זה תמליל שלי הופעות על DevopsConf 2019-05-28.

שקופיות וסרטונים

גרסה אנגלית
גרסה רוסית
ריצה יבשה 2019-04-24 SpbLUG
וידאו(RU) מ-DevopsConf 2019-05-28
וידאו(RU) מ-DINS DevOps EVENING 2019-06-20
שקופיות

תשתיות כהיסטוריה של בושה

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

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

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

מה לעשות?

תשתית כקוד

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

יָבֵשׁ.

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

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

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

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

מוצק. עבור CFM

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

עקרון האחריות הבלעדית

כל כיתה מבצעת משימה אחת בלבד.

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

העיקרון הפתוח הסגור

עקרון פתוח/סגור.

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

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

עקרון החלפת ליסקוב

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

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

במקרה שלנו, יש הסכמה בתוך צוות התשתית שאם התקנו את התפקיד imbjava או oraclejava, אז יש לנו קובץ הפעלה בינארי של java. זה הכרחי כי תפקידים במעלה הזרם תלויים בהתנהגות זו; הם מצפים לג'אווה. יחד עם זאת, זה מאפשר לנו להחליף מימוש/גרסה אחת של java באחרת מבלי לשנות את לוגיקה של פריסת האפליקציה.

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

עקרון הפרדת הממשק

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

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

עקרון היפוך התלות

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

כאן הדוגמה תתבסס על אנטי-תבנית.

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

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

פעולת גומלין

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

גורם אוטובוס

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

זוג Devopsing

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

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

ביקורת קוד

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

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

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

קוד סגנון

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

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

Green Build Master

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

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

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

בדיקת IaC

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

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

פירמידת בדיקות IaC

בדיקת IaC: ניתוח סטטי

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

בש הוא מסובך

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

for i in * ; do 
    cp $i /some/path/$i.bak
done

מה אם יש רווח בשם הקובץ? ובכן, בסדר, אנחנו חכמים, אנחנו יודעים איך להשתמש במרכאות:

for i in * ; do cp "$i" "/some/path/$i.bak" ; done

כל הכבוד? לא! מה אם אין שום דבר בספרייה, כלומר. גלובינג לא יעבוד.

find . -type f -exec mv -v {} dst/{}.bak ;

כל הכבוד עכשיו? לא... שכחתי מה יכול להיות בשם הקובץ n.

touch x
mv x  "$(printf "foonbar")"
find . -type f -print0 | xargs -0 mv -t /path/to/target-dir

כלי ניתוח סטטי

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

שפה
כלי

לחבוט
בדיקת מעטפת

אוֹדֶם
רובוקופ

פִּיתוֹן
פלינט

ansible
Ansible Lint

בדיקת IaC: בדיקות יחידה

כפי שראינו מהדוגמה הקודמת, linters אינם כל יכולים ואינם יכולים להצביע על כל האזורים הבעייתיים. יתרה מכך, באנלוגיה לבדיקות בפיתוח תוכנה, אנו יכולים להיזכר בבדיקות יחידות. מה שעולה מיד בראש הוא shnit, צומת, rspec, pytest. אבל מה לעשות עם אנסיבל, שף, מלח ואחרים כמוהם?

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

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

בדיקת IaC: כלי בדיקת יחידות

שאלה, מה הם מבחנים ל-CFM? אתה יכול פשוט להריץ את הסקריפט, או שאתה יכול להשתמש בפתרונות מוכנים לכך:

CFM
כלי

בלתי אפשרי
Testinfra

שֶׁף
בדוק

שֶׁף
מפרט שרתים

ערימת מלח
גוס

דוגמה ל-testinfra, בדיקת המשתמשים test1, test2 קיימים ונמצאים בקבוצה sshusers:

def test_default_users(host):
    users = ['test1', 'test2' ]
    for login in users:
        assert host.user(login).exists
        assert 'sshusers' in host.user(login).groups

מה לבחור? השאלה מורכבת ומעורפלת, הנה דוגמה לשינויים בפרויקטים ב-github ל-2018-2019:

מסגרות בדיקות IaC

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

CFM
כלי

בלתי אפשרי
מולקולה

שֶׁף
מטבח מבחן

Terraform
Terratest

דוגמה לשינויים בפרויקטים ב-github עבור 2018-2019:

מולקולה לעומת מטבח בדיקה

בתחילה אנחנו ניסיתי להשתמש ב- testkitchen:

צור VM במקביל.
החל תפקידים Ansible.
הפעל בדיקה.

במשך 25-35 תפקידים זה עבד 40-70 דקות, וזה היה ארוך.

השלב הבא היה המעבר לג'נקינס/דוקר/אנסיבל/מולקולה. אידיאולוגית הכל אותו דבר

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

מוך עבור 40 תפקידים ומבחנים עבור תריסר החלו לקחת כ-15 דקות.

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

בדיקות IaC: מבחני אינטגרציה

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

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

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

בדיקות IaC: בדיקות מקצה לקצה

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

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

תוכנית זו עבדה במשך זמן רב למדי, עד בתוך המסגרת מחקר לא ניסינו להעביר את זה ל-Openshift. הקונטיינרים נשארו זהים, אבל סביבת ההשקה השתנתה (שלום D.R.Y שוב).

הרעיון המחקרי הרחיק לכת, וב-openshift הם מצאו דבר כזה כמו APB (Ansible Playbook Bundle), המאפשר לארוז ידע כיצד לפרוס תשתית לתוך קונטיינר. הָהֵן. ישנה נקודת ידע שניתנת לבדיקה על אופן פריסת התשתית.

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

סיכום

תשתית כפי שהקוד הוא

קוד במאגר.
אינטראקציה אנושית.
בדיקת תשתית.

קישורים

מקור: www.habr.com

מה שלמדתי מבדיקת 200 שורות של קוד תשתית