מה זה Ansible ולמה משתמשים בו¶
אם ניהלתם פעם יותר משרת אחד, אתם מכירים את הרגע הזה. צריך להתקין חבילה חדשה, לעדכן קובץ קונפיגורציה, או לפרוס גרסה חדשה של האפליקציה - וזה צריך לקרות לא רק על שרת אחד, אלא על עשרה, עשרים, או מאה שרתים בו זמנית. אז אתם פותחים חיבור SSH לכל שרת בנפרד, מריצים את אותן פקודות שוב ושוב, ומתפללים שלא שכחתם אחד. זה בדיוק הבעיה ש-Ansible נועד לפתור.
הבעיה שכל מי שמנהל שרתים מכיר¶
בכל ארגון שגדל מעבר לשרת בודד, מתחילה בעיה שנקראת configuration drift - שרתים שהיו אמורים להיות זהים, אבל אחרי כמה חודשים של תיקונים ידניים ושדרוגים דחופים באמצע הלילה, הם כבר לא זהים בכלל. שרת אחד עם גרסת פייתון אחת, שרת שני עם גרסה אחרת. שרת עם קובץ קונפיגורציה ששכחתם לעדכן בשאר. וכשמשהו נשבר, אתם לא יודעים אם זה בגלל הקוד או בגלל שהשרת הזה ספציפית שונה מהאחרים.
התהליך הידני הזה גם פשוט לא סקיילבילי. אפשר אולי לנהל חמישה שרתים בעבודה ידנית, אבל מאה שרתים? זה כבר לא עניין של זמן, זה עניין של בלתי אפשרי בלי שגיאות אנוש.
איך Ansible עובד בפועל¶
הרעיון המרכזי מאחורי Ansible פשוט להפליא: אתם מתארים איך אתם רוצים שהשרת ייראה, לא איך להגיע לשם. זה נקרא ניהול קונפיגורציה מוצהר, ואתם עושים את זה בקבצי YAML שנקראים playbooks.
playbook הוא בעצם רשימה של משימות - להתקין חבילה, להעתיק קובץ, להפעיל שירות, ליצור משתמש - שרצות על קבוצת שרתים שהגדרתם ב-inventory. אתם כותבים משהו כמו "וודא שחבילת nginx מותקנת ושהשירות פועל", ו-Ansible דואג לבצע את זה על כל שרת ברשימה.
מה שהופך את Ansible למיוחד הוא שהוא agentless - אין צורך להתקין שום תוכנה נוספת על השרתים שאתם מנהלים. Ansible פשוט מתחבר אליהם דרך SSH רגיל, אותו פרוטוקול שאתם כבר משתמשים בו כדי להתחבר ידנית, ומריץ שם פקודות זמניות. זה אומר שאין agent שצריך לתחזק, לעדכן, או לדאוג שהוא לא קרס. אם יש לכם גישת SSH לשרת, יש לכם גישת Ansible אליו.
אידמפוטנטיות - למה זה קריטי¶
מושג מרכזי נוסף הוא אידמפוטנטיות - idempotency. זה אומר שאפשר להריץ את אותו playbook שוב ושוב, והתוצאה תמיד תהיה זהה, בלי תופעות לוואי מצטברות. אם החבילה כבר מותקנת, Ansible לא יתקין אותה שוב, הוא פשוט ידווח שהמצב כבר תואם למה שביקשתם. אם קובץ הקונפיגורציה כבר מעודכן, שום דבר לא ישתנה.
זה שונה מהותית מסקריפט bash רגיל, שאם מריצים אותו פעמיים בטעות עלול ליצור בלגן - להוסיף אותה שורה פעמיים לקובץ, לנסות ליצור משתמש שכבר קיים ולקרוס. עם Ansible, אתם יכולים להריץ את אותו playbook כל בוקר בלי חשש, וזה בדיוק מה שמאפשר לתפוס configuration drift מוקדם - אם שרת השתנה ידנית, ההרצה הבאה תתקן אותו בחזרה למצב הרצוי.
מתי משתמשים ב-Ansible בפועל¶
השימוש הנפוץ ביותר הוא הכנת שרתים חדשים מאפס - provisioning, כלומר להתקין את כל התוכנות והתלויות שצריך על שרת נקי; שמירה על עקביות בין סביבות, כדי לוודא ששרת הפיתוח, הבדיקות והייצור מוגדרים באותה צורה; ופריסת קוד - deployment, כלומר לקחת גרסה חדשה של אפליקציה ולהעלות אותה לכל השרתים בבת אחת, בסדר מוגדר ובלי להפיל את השירות.
צוותי DevOps רבים גם משתמשים ב-Ansible לתחזוקה שוטפת - עדכוני אבטחה, ניהול משתמשים, סבב מפתחות, כל דבר שצריך לקרות על כל השרתים בו זמנית ובאופן עקבי.
Ansible מול Terraform¶
שאלה שעולה כל הזמן היא איך Ansible קשור ל-Terraform, והתשובה הקצרה היא שהם פותרים בעיות שונות לגמרי. Terraform מספק את התשתית עצמה - יוצר שרתים, רשתות ומסדי נתונים בענן. Ansible בא אחרי זה ומגדיר מה רץ בתוך התשתית הזאת - איזה תוכנות מותקנות, איך הן מוגדרות, איזה קוד רץ עליהן. במילים אחרות, Terraform בונה את הבית, ו-Ansible מרהט אותו. בהרבה פייפליינים אמיתיים תראו את שניהם עובדים יחד, כש-Terraform רץ קודם ומייצר את השרתים, ו-Ansible רץ אחריו ומגדיר אותם.
טעות נפוצה שכדאי להכיר¶
המלכודת הכי שכיחה למתחילים היא לכתוב playbooks לא-אידמפוטנטיים בטעות - למשל, משימה שמריצה פקודת shell שמוסיפה שורה לקובץ בלי לבדוק אם היא כבר שם. ברגע שמריצים את זה פעמיים, מקבלים כפילויות. הפתרון הוא להשתמש במודולים הייעודיים של Ansible - כמו lineinfile, template או copy - במקום להריץ פקודות shell גולמיות בכל מקום. המודולים האלה בנויים מלכתחילה להיות אידמפוטנטיים, וזה בדיוק מה שנותן ל-Ansible את הכוח שלו.
אם אתם רוצים להבין לעומק איך שרתים, רשתות ותשתיות עובדים ביחד, ולא רק לשנן פקודות, שווה להעיף מבט על הקורס צד שרת - שם בונים את כל התמונה הגדולה צעד אחר צעד.
בסופו של דבר, Ansible הוא הכלי שהופך ניהול שרתים מעבודה ידנית מייגעת לתהליך צפוי וחוזר על עצמו. ברגע שהתרגלתם לכתוב playbook במקום להתחבר ידנית, קשה לחזור אחורה.