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

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

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

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

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

ניהול התקנת מערכת ההפעלה

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

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

המשימה ה"מקסימלית" עבור מערכת ניהול ההתקנה היא להגדיר באופן אוטומטי שרתים מרמת ה-BIOS/קושחה למערכת ההפעלה. הרבה כאן תלוי בציוד ובמשימות ההגדרה. עבור ציוד הטרוגני, אתה יכול לשקול REDFISH API. אם כל החומרה היא של ספק אחד, אז לרוב נוח יותר להשתמש בכלי ניהול מוכנים (לדוגמה, HP ILO Amplifier, DELL OpenManage וכו').

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

יצרנו שרתים וירטואליים המבוססים על תבניות שהוכנו באמצעות HashiСorp Packer. הסיבה הייתה זהה: למנוע טעויות אנוש אפשריות בעת התקנת מערכת ההפעלה. אבל, בניגוד לשרתים פיזיים, Packer מבטל את הצורך ב-PXE, אתחול רשת ושינויי VLAN. זה עשה את זה קל ופשוט יותר ליצור שרתים וירטואליים.

אורז. 1. ניהול התקנת מערכות הפעלה.

ניהול סודות

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

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

• ישירות בקוד בקרת התצורה או בקבצים במאגר;
• בכלי ניהול תצורה מיוחדים (לדוגמה, Ansible Vault);
• במערכות CI/CD (Jenkins/TeamCity/GitLab/וכו') או במערכות ניהול תצורה (Ansible Tower/Ansible AWX);
• ניתן להעביר סודות גם "ידנית". לדוגמה, הם מונחים במיקום מוגדר, ולאחר מכן הם משמשים על ידי מערכות ניהול תצורה;
• שילובים שונים של האמור לעיל.

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

השתמשנו באחסון הסודי המרכזי HashiCorp Vault. זה איפשר לנו:

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

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

אנו מוסיפים רמה נוספת למערכת שלנו: ניהול סודות ואימות/הרשאה מרכזיים:

אורז. 2. ניהול סודות.

ניהול תצורה

הגענו לליבה - מערכת ה-CMS. במקרה שלנו, מדובר בשילוב של Ansible ו-Red Hat Ansible AWX.

במקום Ansible, ניתן להשתמש בשף, בובה, ב-SaltStack. בחרנו ב-Ansible על סמך מספר קריטריונים.

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

אבל Ansible לבד בסביבת הפקה לא הספיקה לנו. אחרת, יתעוררו בעיות רבות עם הגבלת הגישה וביקורת פעולות של מנהלי מערכת. איך להגביל גישה? אחרי הכל, היה צורך לכל מחלקה לנהל (קרא: להפעיל את ספר המשחקים של Ansible) את מערך השרתים "שלה". כיצד לאפשר רק לעובדים מסוימים להפעיל ספרי משחק ספציפיים של Ansible? או איך לעקוב אחר מי השיק את ה-Playbook מבלי להגדיר הרבה ידע מקומי על שרתים וציוד המריצים את Ansible?

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

ועוד נגיעה אחת לדיוקן של מערכת ה-CMS שלנו. יש לאחסן את ספר המשחקים Ansible במערכות ניהול מאגר קודים. יש לנו את זה GitLab CE.

אז, התצורות עצמן מנוהלות על ידי שילוב של Ansible/Ansible AWX/GitLab (ראה איור 3). כמובן, AWX/GitLab משולבת עם מערכת אימות יחידה, ו-Ansible playbook משולב עם HashiCorp Vault. תצורות נכנסות לסביבת הייצור רק דרך Ansible AWX, בה מצוינים כל "כללי המשחק": מי יכול להגדיר מה, היכן להשיג את קוד ניהול התצורה ל-CMS וכו'.

אורז. 3. ניהול תצורה.

ניהול מבחנים

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

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

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

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

בכל פעם שיש שינוי בקוד ניהול התצורה, GitLab CI/CD קורא למולקולה:

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

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

אורז. 4. בדיקה אוטומטית של תפקידים ב- GitLab CI/CD.

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

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

לכן, בנוסף לבדיקות מתמשכות, אנו בודקים בסביבות ייצור אי-התאמות בתצורה. בחרנו באפשרות הפשוטה ביותר: הפעלת קוד תצורת ה-CMS במצב "ריצה יבשה", כלומר ללא החלת שינויים, אלא עם הודעה על כל הפערים בין התצורה המתוכננת לתצורה בפועל. יישמנו זאת על ידי הפעלת כל ספרי ההשמעה של Ansible עם אפשרות "-check" על שרתי הייצור. כמו תמיד, Ansible AWX אחראית להשיק ולשמור את ספר המשחקים מעודכן (ראה איור 5):

אורז. 5. בודק אי התאמות בתצורה ב-Ansible AWX.

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

כעת יש לנו שכבת בדיקה חשובה המורכבת מ-Ansible AWX/GitLab/Molecule (איור 6).

אורז. 6. ניהול מבחנים.

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

אין היום "ידע סודי" בהגדרות של שרתים וסביבות. כל התכונות הדרושות משתקפות בספר המשחקים. לא עוד יצירתיות והוראות מעורפלות: "התקן אותו כמו Oracle רגיל, אבל אתה צריך לציין כמה הגדרות sysctl ולהוסיף משתמשים עם ה-UID הנדרש. תשאלו את החבר'ה במבצע, הם יודעים".

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

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

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

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

מחבר: סרגיי ארטמוב, אדריכל המחלקה פתרונות DevOps "מערכות מידע סילון"

מקור: www.habr.com