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

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

לאחר שהשארתי מספר נושאים מאחור, החלטתי להתחיל פרק חדש.

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

DevOps עבור הרשת

יצירת תצורה עם סקריפט, שימוש ב-GIT כדי לשלוט בשינויים בתשתית ה-IT, "העלאה" מרחוק - הרעיונות האלה באים קודם כל כשחושבים על היישום הטכני של גישת ה-DevOps. היתרונות ברורים. אבל, למרבה הצער, יש גם חסרונות.

כשלפני יותר מ-5 שנים המפתחים שלנו הגיעו אלינו, אנשי הרשת, עם ההצעות הללו, לא התלהבנו.

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

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

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

אני לא רוצה להגיד שכל הבעיות האלה בלתי פתירות. רק לומר "A" כנראה הגיוני לומר גם "B", ואם אתה רוצה להשתמש באותם תהליכים לבקרת שינויים כמו בפיתוח, אז אתה צריך להיות סביבות פיתוח ו-Staging בנוסף לייצור. ואז הגישה הזו נראית שלמה. אבל כמה זה יעלה?

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

פרויקט

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

עבורי באופן אישי, ישנם שני שלבים נפרדים בפרויקט הזה.

שלב ראשון

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

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

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

עכשיו יכולנו להסתכל קצת מסביב.
וזו הייתה תחילתו של השלב השני.

שלב שני

החלטתי להפוך את התהליך לאוטומטי.

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

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

לכן, בעת שימוש ב-YAML ו-Jinja2, קובץ YAML עם פרמטרים של תצורה כגון כתובות IP, מספרי BGP AS, ... ממלא בצורה מושלמת את התפקיד של NIP, בעוד שתבניות Jinja2 כוללות תחביר המתאים לעיצוב, כלומר, זה בעצם השתקפות של LLD.

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

כעת תהליך השינוי נראה כך:

• שינה את קובץ YAML
• יצר קובץ תצורה באמצעות תבנית (Jinja2)
• נשמר במאגר מרוחק
• העלה את התצורה שנוצרה לציוד
• ראיתי שגיאה
• שינה את קובץ YAML או תבנית Jinja2
• יצר קובץ תצורה באמצעות תבנית (Jinja2)
• ...

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

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

Dev and Staging

Staging למעשה משכפל לחלוטין את הייצור. Dev הוא עותק מופשט בכבדות הבנוי בעיקר על חומרה וירטואלית. מצב אידיאלי לגישה חדשה. אם אני מבודד את הזמן שביליתי מהתהליך הכולל, אז אני חושב שהעבודה ארכה לא יותר משבועיים. הזמן העיקרי הוא לחכות לצד השני ולחפש בעיות ביחד. היישום של צד שלישי נעלם כמעט מעיני אחרים. אפילו היה זמן ללמוד משהו ולכתוב כמה מאמרים על Habré :)

בואו נסכם

אז מה יש לי בשורה התחתונה?

• כל מה שאני צריך לעשות כדי לשנות את התצורה הוא לשנות קובץ YAML פשוט, בעל מבנה ברור עם פרמטרים של תצורה. אני אף פעם לא משנה את הסקריפט של python ולעיתים רחוקות מאוד (רק אם יש שגיאה) אני משנה את ה-Jinja2 heatlate
• מנקודת מבט תיעודית, זהו מצב כמעט אידיאלי. אתה משנה את התיעוד (קבצי YAML משמשים כ-NIP) ומעלה את התצורה הזו לציוד. כך התיעוד שלך תמיד מעודכן

כל זה הוביל לכך

• שיעור השגיאות ירד לכמעט 0
• 90 אחוז מהשגרה נעלמה
• מהירות היישום עלתה משמעותית

PAY, F5Y, ACY

אמרתי שדי בכמה דוגמאות כדי להבין איך זה עובד.
הנה גרסה קצרה (וכמובן שונה) של מה שנוצר במהלך עבודתי.

לשלם = פריסה PALO Alto מ Yaml = פאלו אלטו מימל
F5Y = פריסה F5 החל מ- Yaml = F5 החל מ- Yaml (בקרוב)
ACY = פריסה ACאני מ Yaml = F5 החל מ- YAml

אוסיף כמה מילים על ACY (לא להתבלבל עם ACI).

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

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

המהנדסים בפרויקט זה משתמשים ב-Excel כדי להגדיר את ACI במקום YAML לאותן מטרות בדיוק. יש כמובן יתרונות לשימוש באקסל:

• ה-NIP שלך בקובץ אחד
• שלטים יפים שנעים ללקוח להסתכל עליהם
• אתה יכול להשתמש בכלי אקסל

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

ACY הוא למעשה יישום של אותן גישות שבהן השתמשתי עבור הצד השלישי כדי להגדיר את ACI.

מקור: www.habr.com