חיתוך החוטים: הגירה מ-Puppet Enterprise ל-Ansible Tower. חלק 1

שירות המידע הלאומי ללוויין סביבתי (NESDIS) הפחית את עלויות ניהול התצורה שלו עבור Red Hat Enterprise Linux (RHEL) ב-35% על ידי הגירה מ-Puppet Enterprise ל-Ansible Tower. בסרטון "איך עשינו את זה", מהנדס המערכות מייקל ראו מסביר את המקרה להגירה זו, משתף טיפים שימושיים ולקחים שנלמדו ממעבר מ-SCM אחד לאחר.

בסרטון זה תלמדו:

• כיצד להצדיק בפני ההנהלה את כדאיות המעבר מ-Puppet Enterprise ל-Ansible Tower;
• באילו אסטרטגיות להשתמש כדי להפוך את המעבר לחלק ככל האפשר;
• טיפים לקידוד מניפסטים PE לתוך Ansible Playbook;
• המלצות להתקנה מיטבית של Ansible Tower.

שלום לכולם, שמי מייקל ראו, אני מהנדס מערכות בכיר ב-AccioNet, שעובד עבור שירות NESDIS National Oceanic and Atmospheric Administration (NOAA). היום נדבר על גזירת מיתרים - נסיוני שלי במעבר מ-Puppet Enterprise ל-Ansible Tower. הנושא של מצגת זו הוא "להסתכל על הצלקות שלי" שנותרו לאחר שביצעתי את המעבר הזה מוקדם יותר השנה. אני רוצה לשתף במה שלמדתי בתהליך הזה. אז כשאתה לוקח על עצמך משהו כזה, בעזרת הניסיון שלי, אתה יכול לעשות את המעבר ללא כל עבודה נוספת.

אתה רואה שקופיות דומות לזה בתחילת כל מצגת ב-Ansible Fest. שקף זה מתאר את ההיסטוריה של האוטומציה של החברה שלי. אני לא חדש בזה כי אני משתמש ב-Puppet/Puppet Enterprise מאז 2007. התחלתי לעבוד עם Ansible בשנת 2016, וכמו משתמשים רבים אחרים של המוצר הזה, נמשכתי לאפשרות של "טריקים" באמצעות שורת הפקודה וסקריפטים פשוטים (Playbooks). בסוף 2017 פניתי להנהלה שלי לגבי הסיבות החזקות למעבר למגדל אנסיבל. בעוד דקה אספר לכם על הסיבות שהניעו אותי לעשות את הצעד הזה. לאחר קבלת הסכמת ההנהלה, נדרשו עוד מספר חודשים להשלמת התוכנית, ואת המעבר ביצעתי בינואר-פברואר השנה. אז, נטשנו לחלוטין את Puppet לטובת Ansible, וזה דבר נהדר.

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

זהו LAN פדרלי, 7 אתרים פיזיים המחוברים באמצעות ענן MPLS, 140 שרתי RHEL, 99% מהם וירטואליים (vSphere), חומרת SuperMicro, אחסון רשת NexentaStore, סט מתגי Cisco, Arista ו- Cumulus וניהול איומים מאוחד של Fortinet UTM כלים בכל אתר.

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

ההיסטוריה שלנו עם Puppet היא כדלקמן.

ב-2007 הייתה לנו רשת קטנה של 20-25 צמתים, שבה פרסנו את Puppet. בעיקרון, הצמתים האלה היו רק "קופסאות" של RedHat. בשנת 2010, התחלנו להשתמש בממשק האינטרנט Puppet Dashboard עבור 45 צמתים. כשהרשת המשיכה להתרחב, עברנו ל-PE 2014 ב-3.3, תוך כדי מעבר מלא עם שכתוב מניפסט עבור 75 צמתים. זה היה צריך להיעשות כי Puppet אוהב לשנות את כללי המשחק, ובמקרה הזה הם שינו לחלוטין את השפה. שנה לאחר מכן, כשהתמיכה בגרסה 3 של Puppet Enterprise הסתיימה, נאלצנו לעבור ל-PE 2015.2. נאלצנו לשכתב את המניפסט שוב ​​לשרתים החדשים ולרכוש רישיון עם רזרבה של 100 צמתים, למרות שבאותו זמן היו לנו רק 85 צמתים.

עברו רק שנתיים, ושוב היינו צריכים לעשות עבודה רבה כדי לעבור לגרסה החדשה PE 2. קנינו רישיון ל-2016.4 צמתים, עם רק 300. שוב נאלצנו לבצע שינויים גדולים במניפסט כי לגרסה החדשה של השפה היה תחביר שונה מהשפה של גרסת 130. כתוצאה מכך, ה-SCM שלנו עבר מבקרת גרסאות SVN ל-Bitbucket (Git). זה היה ה"יחסים" שלנו עם בובה.

אז, הייתי צריך להסביר להנהלה מדוע עלינו לעבור ל-SCM אחר באמצעות הטיעונים הבאים. הראשון הוא המחיר הגבוה של השירות. דיברתי עם החבר'ה ב-RedHat והם אמרו שהעלות של הפעלת רשת של 300 צמתים עם Ansible Tower היא חצי מהעלות של Puppet Enterprise. אם תרכוש גם Ansible Engine, העלות תהיה בערך זהה, אבל תקבל הרבה יותר תכונות מאשר PE. מכיוון שאנו חברה בבעלות המדינה הממומנת מהתקציב הפדרלי, זהו טיעון די חזק.

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

מערכת Ansible Tower פועלת אחרת כי אין לה סוכנים, אבל יש לה מודולים התומכים במתגי סיסקו ובכל המתגים האחרים. SCM זה תומך ב-Qubes OS, Linux ו-4.NET UTM. Ansible Tower תומך גם בבקרי אחסון ברשת NexentaStore המבוססים על ליבת Illumos, מערכת הפעלה מבוססת Unix בקוד פתוח. זו מעט מאוד תמיכה, אבל Ansible Tower עושה זאת בכל מקרה.

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

למען האמת, Puppet מקשה הרבה יותר על עבודתך כמפתחים מכיוון שהיא מבוססת על שימוש ב-Puppet Master. זוהי המכונה היחידה שמותר לתקשר עם סוכני Puppet. אם ביצעת שינויים כלשהם במניפסט וברצונך לבדוק את הקוד שלך, עליך לכתוב מחדש את הקוד עבור Puppet Master, כלומר, להגדיר את הקובץ Puppet Master /etc/hosts לחיבור כל הלקוחות ולהפעיל את שירות Puppet Server. רק לאחר מכן תוכל לבדוק את פעולת ציוד הרשת על מארח אחד. זהו הליך די כואב.
הכל הרבה יותר פשוט ב-Ansible. כל מה שאתה צריך לעשות הוא לפתח קוד למכונה שיכולה לתקשר באמצעות SSH עם המארח הנבדק. זה הרבה יותר קל לעבוד.

היתרון הגדול הבא של Ansible Tower הוא היכולת למנף את מערכת התמיכה הקיימת שלך ולתחזק את תצורת החומרה הקיימת שלך. SCM זה משתמש בכל המידע הזמין על התשתית והחומרה שלך, מכונות וירטואליות, שרתים וכו' ללא כל שלבים נוספים. זה יכול לדבר עם שרתי ה-RH Satellite שלך, אם יש לך כזה, ונותן לך אינטגרציות שלעולם לא תקבל עם Puppet.

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

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

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

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

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

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

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

לאחר מכן התחל לכתוב קוד סקריפט ותפקידים שיאפשרו את המשימות שאתה מתכנן להשלים. שלב אותם לתוך Projects, אוסף הגיוני של ספרי משחק רלוונטיים. כל פרויקט יהיה שייך למאגר Git נפרד או למאגר אחר, תלוי באיזה מנהל קוד אתה משתמש. אתה יכול לנהל סקריפטים של ספרי משחק וספריות משחק על ידי הצבתם באופן ידני ב- Project Base Path בשרת ה-Tower, או על-ידי הצבת ספר המשחקים בכל מערכת ניהול קוד מקור (SCM) הנתמכת על ידי Tower, כולל Git, Subversion, Mercurial ו-Red Hat תובנות. בתוך פרויקט אחד אתה יכול למקם כמה סקריפטים שאתה רוצה. לדוגמה, יצרתי פרויקט בסיסי אחד שבו הנחתי סקריפט עבור רכיבי הליבה של RedHat, סקריפט לליבה של לינוקס וסקריפטים עבור שאר קווי הבסיס. לפיכך, בפרויקט אחד היו מגוון תפקידים ותרחישים שנוהלו ממאגר Git אחד.

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

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

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

18:00

חיתוך החוטים: הגירה מ-Puppet Enterprise ל-Ansible Tower. חלק 2

כמה מודעות 🙂

תודה שנשארת איתנו. האם אתה אוהב את המאמרים שלנו? רוצים לראות עוד תוכן מעניין? תמכו בנו על ידי ביצוע הזמנה או המלצה לחברים, Cloud VPS למפתחים החל מ-$4.99, אנלוגי ייחודי של שרתים ברמת הכניסה, שהומצא על ידינו עבורכם: כל האמת על VPS (KVM) E5-2697 v3 (6 ליבות) 10GB DDR4 480GB SSD 1Gbps החל מ-$19 או איך לשתף שרת? (זמין עם RAID1 ו-RAID10, עד 24 ליבות ועד 40GB DDR4).

Dell R730xd זול פי 2 במרכז הנתונים Equinix Tier IV באמסטרדם? רק כאן 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV החל מ-$199 בהולנד! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - החל מ-$99! לקרוא על כיצד לבנות תשתיות קורפ. מחלקה עם שימוש בשרתי Dell R730xd E5-2650 v4 בשווי 9000 יורו עבור אגורה?

מקור: www.habr.com