🥇Ansible: העברה של תצורת 120 VM מ-CoreOS ל-CentOS תוך 18 חודשים

זהו תמלול הנאום DevopsConf 2019-10-01 и SPbLUG 2019-09-25.

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

יום מס' -ХХХ: לפני ההתחלה

בתחילה, התשתית כללה מארחים נפרדים רבים המריצים Hyper-V. יצירת מכונה וירטואלית דרשה שלבים רבים: הצבת הדיסקים במקום הנכון, רישום DNS, שמירת DHCP, הכנסת תצורת ה-VM למאגר git. תהליך זה היה ממוכן חלקית, אך לדוגמה, VMs הופצו בין מארחים ביד. אבל, למשל, מפתחים יכולים לתקן את תצורת ה-VM ב-git ולהחיל אותה על ידי אתחול מחדש של ה-VM.

פתרון ניהול תצורה מותאם אישית

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

MAC סטטי נתפס עבור ה-VM.
ל-VM חוברו ISO עם CoreOS ודיסק אתחול.
CoreOS משיקה את סקריפט ההתאמה האישית על ידי הורדתו משרת ה-WEB בהתבסס על ה-IP שלו.
הסקריפט מוריד את תצורת ה-VM דרך SCP בהתבסס על כתובת ה-IP.
משטח הרגל של קבצי יחידת systemd ומטלית הרגל של תסריטי bash מושקים.

לפתרון הזה היו הרבה בעיות ברורות:

CoreOS ISO הוצא משימוש.
הרבה פעולות אוטומטיות מורכבות וקסם בעת הגירה/יצירת VMs.
קושי בעדכון וכאשר יש צורך בגרסה מסוימת של תוכנה. אפילו יותר כיף עם מודולי ליבה.
VMs לא הושגו כך ללא נתונים, כלומר. מחשבי VM הופיעו עם דיסק עם נתוני משתמש נוספים.
מישהו דפק כל הזמן את התלות של יחידות המערכת ו-CoreOS תקפא בעת אתחול מחדש. היה קשה לתפוס את זה באמצעות הכלים הזמינים ב- CoreOS.
ניהול סודות.
לא היה CM. היו תצורות bash ו-YML עבור CoreOS.

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

יום מס' 0: זיהה את הבעיה

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

CentOS כהפצה בסיסית, כי זוהי ההפצה הקרובה ביותר לסביבות ייצור.
בלתי אפשרי לניהול תצורה, מכיוון הייתה בדיקה מקיפה על זה.
ג'נקינס כמסגרת לאוטומציה של תהליכים קיימים, כי כבר נעשה בו שימוש פעיל לתהליכי פיתוח
Hyper-V כפלטפורמת וירטואליזציה. ישנן מספר סיבות החורגות מתחום הסיפור, אבל בקיצור – אנחנו לא יכולים להשתמש בעננים, אנחנו חייבים להשתמש בחומרה שלנו.

יום מס' 30: תיקון הסכמים קיימים - הסכמים כקוד

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

1. הגדר מכשירי VM

Ansible עושה עבודה מצוינת בזה. עם מינימום תנועות גוף אתה יכול להשתלט על תצורות VM:

צור מאגר git.
שמנו את רשימת ה-VMs במלאי, תצורות בספרי משחק ותפקידים.
אנחנו מקימים עבד ג'נקינס מיוחד שממנו אתה יכול להפעיל את Ansible.
אנחנו יוצרים עבודה ומגדירים את ג'נקינס.

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

2. צור VM חדש

הכל כאן לא היה נוח במיוחד. זה לא מאוד נוח ליצור VMs על Hyper-V מ-Linux. אחד הניסיונות למכן תהליך זה היה:

Ansbile מתחבר דרך WinRM למארח Windows.
Ansible מריץ סקריפט Powershell.
סקריפט Powershell יוצר VM חדש.
באמצעות Hyper-V/ScVMM, בעת יצירת VM במערכת ההפעלה האורח, שם המארח מוגדר.
בעת עדכון חוזה החכירה של DHCP, ה-VM שולח את שם המארח שלו.
שילוב ddns ו-dhcp סטנדרטי בצד בקר התחום מגדיר את רשומת ה-DNS.
אתה יכול להוסיף VM למלאי שלך ולהגדיר אותו עם Ansible.

3. צור תבנית VM

הם לא המציאו כאן שום דבר - הם לקחו אורז.

הוסף את ה-packer, kickstart config למאגר git.
הקמת עבד ג'נקינס מיוחד עם hyper-v ו-Packer.
אנחנו יוצרים עבודה ומגדירים את ג'נקינס.

איך הקישור הזה עובד:

Packer יוצר VM ריק ואוסף את ה-ISO.
ה-VM מאתחל, Packer מכניס את הפקודה ל-bootloader כדי להשתמש בקובץ הקיק-start שלנו מתקליטון או http.
Anaconda מושקת עם התצורה שלנו, ותצורת מערכת ההפעלה הראשונית מתבצעת.
Packer מחכה שה-VM יהפוך זמין.
Packer בתוך ה-VM פועל באופן סביר במצב מקומי.
Ansible משתמש בדיוק באותם תפקידים שהם פועלים בשלב מס' 1.
Packer מייצא את תבנית ה-VM.

יום מס' 75: שחזר את ההסכם מבלי להפר = מבחן אנסible + Testkitchen

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

יום מס' 130: אולי אין צורך ב-CentOS+ansible? אולי הילוך פתוח?

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

יום מס' 170: Openshift לא מתאים, בואו ניקח סיכון עם Windows Azure Pack?

Hyper-V אינו ידידותי במיוחד, SCVMM לא עושה את זה הרבה יותר טוב. אבל יש דבר כזה Windows Azure Pack, שהוא תוסף ל-SCVMM ומחקה את Azure. אבל במציאות, המוצר נראה נטוש: לתיעוד יש קישורים שבורים והוא דליל מאוד. אבל כחלק מהמחקר של אפשרויות לפישוט חיי הענן שלנו, הם בחנו גם את זה.

יום מס' 250: חבילת Windows Azure לא טובה במיוחד. אנחנו נשארים ב-SCVMM

Windows Azure Pack נראתה מבטיחה, אבל הוחלט לא להכניס את WAP עם המורכבות שלו למערכת למען תכונות מיותרות ונשאר עם SCVMM.

יום מס' 360: אכילת הפיל חתיכה אחר חתיכה

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

יום מס' 450: איזה סוג של מערכת קיבלת?

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

יום מס' 540: גמר

מה קרה ב-18 חודשים?

ההסכמים הפכו לקוד.
עבודה ידנית -> מיכון -> אוטומציה.

קישורים

מקור: www.habr.com

Ansible: העברה של תצורת 120 VM מ-CoreOS ל-CentOS תוך 18 חודשים