תגית: containers

קוברנטיס (Kubernetes) עומד להיות הענן-בתוך-הענן של רובנו

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

מדוע אני כותב את הפוסט דווקא עכשיו? שום דבר לא קרה בשבוע האחרון. רק יצא יום כיפור (אין קשר), אמנם הכריזו על ליין חדש של אייפונס, ויש גם את ארכיטקטורת Turing החדשה של nvidia – אבל לא באמת היה השבוע משהו גדול ורועש בגזרת ה Containers ו/או Container Orchestration Framework (בקיצור עבור הפוסט: COF).
בכל זאת, לפני כשנה כתבתי פוסט שעסק ב COFs והשווה קצת בין מזוס, ECS, קוברנטיס, Swarm ו Nomad – ובאותה עת נראה היה שהתחרות בין כמה מה COFs שהוזכרו עדיין פתוחה.
כשאני מסתכל על ההתרחשויות של השנה האחרונה – נראה שהעניין נסגר. אם “קולות החיילים” לא יבצעו מהפך של הרגע האחרון – Kubernetes הוכרזה בחודשים האחרונים כ COF שתכתיב את הטון בעתיד הנראה לעין.
תזכורת קצרה:
  • קוברנטיס (לעתים נכתב בקיצור K8s) היא פריימוורק ששוחרר כפרויקט קוד פתוח ע״י גוגל באמצע שנת 2014 לניהול Orchestrations של Containers. בסה”כ בת ארבע שנים.
    • לגוגל היה ניסיון קודם בפרויקטים פנימיים דומים: הראשון בשם Borg והמחליף שלו – Omegaֿ, להרצת קונטיינרים. הם לא הריצו Docker או Rkt – אלא קונטיינרים פרי פיתוח מוקדם של גוגל. הניסיון הזה הוכיח את עצמו.
  • קוברנטיס (בדומה ל COFs אחרים) מספקת יכולות Load Balancing, Discovery ו Auto-Scaling ובעצם מהווה סוג של ״מיני-ענן״ בו יחידת ה compute היא Container. האיום הזה לא נחבא מעיניהם של ספקי-הענן הגדולים, והם ניסו לפתח COFs מקבילים שישמרו את ה Lock-In לענן שלהם.
  • אמזון יצאה עם ECS, ומייקרוסופט עם ACS (שתי החברות שאולי היה להן הכי הרבה להפסיד) – פתרון הרצת ו Orchestrations של Containers שתפור לענן שלהן. והן הטילו את כובד משקלן בכדי לשכנע שזו אלטרנטיבה ראויה (וטובה יותר) לקוברנטיס – אלטרנטיבה שרק צריכה עוד זמן להבשיל.
  • השוק לא הגיב יפה להצעות הללו – ופנה ל manual installation של קוברנטיס על גבי EC2.
  • מייקורוסופט הוציאה את AKS (קרי Azure Kubernetes Service) ואמזון את EKS (קרי Elastic Kubernetes Service) כ Kubernetes מנוהל. בהתחלה נראה היה ש EKS ו AKS הולכים להיות offering משני על מנת לשמר לקוחות ולא להישאר יותר מדי מאחור, אבל מהר מאוד התברר שהשירותים הללו תופסים את תשומת-לב הלקוחות, ומשם השתנו הדברים והם התחילו לקבל גם את מירב ההשקעה מצד ספקי הענן. ECS/ACS הופכים להיות פתרונות נישה, בעיקר עבור לקוחות שכבר נרתמו לחזון שהוצג ב 2015, והשקיעו בו, או אולי יצליחו לשלב אותם גם בעולם של קוברנטיס (עבור ה worker nodes – על זה בהמשך).
  • גם פתרונות ענן כגון Pivotal Container Service ו Cloud Foundary – הגיעו למסקנה דומה, ופנו לכיוון קוברנטיס.
  • אפילו החברה מאחורי Docker שניסתה להציג חזון משלה בדמות Swarm (לאחר שהבינה שב COFs יש פוטנציאל עסקי גדול יותר מתמיכה ב Docker בלבד) הכריזה לפני כשנה על תמיכה ״גם״ בקוברנטיס – מה שבפועל ״הוציא את העוקץ״ מ Swarm שמותג כ”פתרון הרשמי של דוקר”.
  • Mesosphere DC/OS – הגרסה המסחרית של Mesos, מציעה גם היא תמיכה בקוברנטיס.
בקיצור: מלחמת ה COFs הסתיימה. Long live Kubernetes!
חשוב לציין שלמרות שקוברנטיס הוא ה COF שהפך לברירת-המחדל, יש עדיין תהליכים שלא ברור כיצד יסתיימו:
  • מייקרוסופט שחררה את ACI (קרי Azure Container Instances) ואמזון את AWS Fargate כשירותים בהם ניתן להריץ container on-demand ולשלם ע״פ השימוש הנקודתי. השירותים מזכירים מאוד את AWS Lambda או Azure functions כאשר הרזולוציה היא Container ולא פונקציה, על אף שמנסים לשווק אותם כ”תחליף ל EC2″.
    • השימוש העיקרי הוא בהפעלה של containers המבצעים batch של עבודה – ולא בהרכבה של containers מסוגים שונים המתקשרים זה עם זה. האלמנט של Orchestration לא ממש קיים בשירותים הללו.
    • גם קוברנטיס תומכת בהפעלת containers באופן on-demand, מה שעשוי לרמז שהלקוחות העיקריים של ACI ו Fargate הם לקוחות שלא מריצים קובנרטיס או כאלו שיש להם Workload מאסיבי שאינם רוצים להפעיל על ה Kubernetes cluster הרגיל שלהם (למשל: משימות AI כבדות).
  • קוברנטיס עצמה נפתחה לספקי הענן, למשל: החל מגרסה 1.9 קוברנטיס תומכת באופן טבעי ב AWS NLB (קרי Network Load Balancer). מיותר לציין שיש הרבה Kubernetes-plugins שמסייעים לבצע את החיבורים לעננים ספציפיים בצורה טבעית יותר.
  • ישנה השקעה בהרצה של Kubernetes בכדי להפעיל VMs ולא רק Containers. המוטיבציה היא לשלב גם שרתים שאינם לינוקס (למשל Windows או אפליקציות Unikernel) ו/או בידוד גבוה יותר – בעיקר משיקולי אבטחה.
  • קוברנטיס מאפשרת יכולות ניהול משאבים טובות ברמת התשתית, אבל ניהול של מאות מיקרו-שירותים הוא עדיין דבר קשה מאוד בקוברנטיס. יש פרויקטים (למשל: lstio הנתמך ע״י Lyft, IBM וגוגל) המנסים לספק שכבת ניהול ברמה יותר ״אפליקטיבית״ שתקל על ניהול שכזה. פרויקטים כאלו יכולים להשתלב עם קוברנטיס כ plug-in ו/או להחליף כמה מיכולות הליבה שלה (למשל: Service Discovery או Load Balancing).

Managed Kubernetes

כמה שאנו אוהבים לשמוע כמה אוטומטית ו״חכמה״ היא קוברנטיס בניהול ה Containers Cluster, הפעלה של קוברנטיס היא עדיין משימה מורכבת:

  • יש שורה של בחירות שיש לבצע בהתקנה של קוברנטיס. האם אתם מעדיפים א או ב, ג או ד? דוגמה טובה היא תקשורת בין Containers: האם Kubenet (ברירת-המחדל) מספיק לכם? אולי אתם צריכים scale, ביצועים, ו/או יכולות שליטה מתקדמות יותר ברמת הרשת וכדאי להשתמש ב Weave? אולי בעצם ב Calico? ואם אתם בוחרים ב Calico – אתם מעדיפים אותו עם Flannel (כלומר: Canal) או בלעדיו?
  • קוברנטיס מטפל בשורה של מקרי-קצה מורכבים להבנה, שללא ניסיון ניכר – קשה להבין אותם ולוודא שהם עובדים בצורה תקינה.
    • High Availability – איך להבטיח ש pods ימשיכו לתפקד ככל האפשר. לדוגמה: האם ה masters הם באמת highly available? האם אתם יכולים ליצור master חדש עם קונפיגורציה שלמה בצורה אוטומטית?
    • אבטחה – האם אתם מודעים כיצד להקשיח התקנה של קוברנטיס, ויש לכם את המנגנון להתקין עדכונים בכל השכבות?
  • חיבור של קוברנטיס לספק הענן הספציפי היא עוד משוכה שיש לעבור. למשל: על EC2 לא תוכלו ליצור cluster גדול מ 50 nodes ללא החלפה של ה CNI Network plugin. כנראה שתרצו כמה מה nodes שירוצו על spots. כדאי מאוד להתחבר ל IAM בצורה נכונה, לקנפג את Route53 כך שה master ימצא את כל הרכיבים שלו ואם יש כמה clusters – הם יהיו זקוקים ל subdomains, וכו׳.
הפתרון הטבעי, בדומה מאוד לבחירה בספק ענן (ולא הפעלה של Data Center של החברה) – הוא שימוש ב Managed Kubernetes. זו הבחירה הטבעית עבור הרוב הגדול של משתמשי Kubernetes, במיוחד אלו שלא הולכים להריץ אלפי שרתים ב Cluster של קוברנטיס (ולכן סביר יותר שיהיה לכם את האינטרנס והמשאבים לעבוד עם קונפיגורציה מאוד ספציפית (“לא מקובלת”) לצרכים שלכם).

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

  • גוגל – בתור היוצרים של Kubernetes והמאמצים הראשונים שלו כשירות Managed בענן, אין הפתעה בכך ש GKE (להלן Google Kubernetes Engine) הוא המוצר הבשל ביותר.
    • האינטגרציה הטובה ביותר, UI מלוטש לניהול, והפעלה מהירה של Cluster מאשר של המתחרות.
    • הבעיה היחידה: רוב החברות (בכלל, אך בישראל בפרט) לא פועלות על הענן של גוגל, והם לא יעבירו אותן לשם בשביל “Managed Kubernetes טוב יותר”. זה עשוי להשתנות בעתיד – אבל כרגע לא נראה שזה המצב.
    • בניגוד ל BigQuery שהוא שירות שלקוח של AWS עשוי להשתמש בו על אף שהוא שוכן בענן אחר – קוברנטיס מריצה את לב המערכת שלנו. להשתמש בקוברנטיס בענן אחר, משמע להתחיל לעבור לענן אחר.
  • אמזון מציעה את EKS, שהיה עד לא מזמן plan B – שהתממש.
    • EKS תנהל עבורכם את ה Control plane מבחינת scalability ו high-availability על גבי AZs שונים. לא תהיה לכם גישה ברמת Admin אליו (בדומה ל RDS), אבל אתם ממשיכים לעבוד עם kubectl כרגיל.
    • לEKS יש אינטגרציה עם שירותי אמזון בראשם IAM, אבל גם ELB, VPC ו CloudTrail.
    • את ה Worker nodes עדיין עליכם לנהל לבד – ויש עוד קונפיגורציה ועבודה שעליכם לעשות על גבי EKS. יש תוכניות לבצע אינטגרציה בין EKS ל ECS כך ש ECS ינהל את ה worker nodes. מכיוון שהוא לא נבנה מלכתחילה לצורת העבודה הזו – צריך לראות כמה טוב זה יעבוד. רעיון דומה מתוכנן לאינטגרציה בין EKS ל Fargate להרצה של Containers שהם task-oriented.
    • לאחרונה שוחררה גרסאת eks.2 של EKS – ויהיו עוד רבות. כרגע ל EKS יש סיכוי טוב להיות פתרון ה Managed Kubernetes הפופולארי ביותר (גם אם לא בהכרח יהיה המתקדם ביותר).
  • מייקורוספט מציעה על גבי Azure את שירות AKS המנוהל, שדומה ביכולות ל EKS.
    • אולי בגלל קהילה קטנה יותר ופעילה פחות, AKS נראה כשירות קצת פחות פופולארי. אפשר לנחש שהלקוחות הקלאסיים של מייקרוסופט הם ברובם לא early adapters של טכנולוגיות חדשות.
  • גם OpenShift ויבמ BlueMix – מציעות פתרונות Kubernetes שנחשבים מפותחים, אך הם מתאימים בפועל בעיקר למי שכבר פעיל על תשתיות הענן הללו.
  • Stackpoint מציעה פתרון של managed control plane על ידה, כאשר את ה worker nodes תתקינו על ענן לבחירתכם. הפתרון אטרקטיבי בעיקר למי שמריץ את ה workload בענן שבו אין offering סביר של managed kubernetes.
השוואה שנעשתה בין שלושת פתרונות ה Managed Kubernetes הנפוצים. מקור

גם מי שמתקין קוברנטיס לבד (על הענן או On-Premises) לרוב לא עושה זה בדרך הארוכה והקשה.
kubernetes-the-hard-way הוא שם של מדריך פופולארי ונחשב להתקנת קוברנטיס מ scratch, שבעיקר משמש בכדי ללמוד את הפרטים השונים שקיימים בהתקנת קוברנטיס, ואת השיקולים שנלקחים בכזו התקנה.

בפועל, מי שמתקין קוברנטיס, יעשה זאת כמעט תמיד עם “installer” המיועד לכך:

  • Kops הוא המקובל ביותר. הוא חלק מפרויקט קוברנטיס והיה במשך תקופה כלי להתקנת קוברנטיס על גבי AWS בלבד. הוא יודע לייצר קבצי Terraform, יודע לבנות תצורות high-availability (כמובן), ותומך ב-7 אפשרויות שונות ל CNI (כלומר: plugin לתקשורת פנימית. אחת הבחירות עם הווריאציות המגוונות יותר בהתקנת קוברנטיס).
  • Kubespray (לשעבר Kargo), תת-פרויקט של קוברנטיס הוא כלי להתקנת קוברנטיס בהתבסס על Ansible, כלי ה configuration management שנחשב לפופולארי ולמתקדם – עד להופעת ה COFs שהולכים ומייתרים אותו. Kubespray נחשב יותר גמיש מ Kops ומציע מגוון רחב יותר של אפשרויות התקנה. יש לו גם תמיכה ספציפית ב AWS, Azure, Google Cloud, Digital Ocean ו Open Stack.
  • TK8 הוא עוד כלי פופולרי, שהדגש שלו הוא עבודה צמודה עם Terraform והוא זוכה לכמה נקודות פופולריות בזכות זה שהוא כתוב ב Go (אזהרת באזז). TK8 כולל גם אפשרות התקנה של כמה אפליקציות פופולריות בהמשך ל Kubernetes Cluster כמו Zipkin+Jagger, Prometheus ועוד.
  • עוד שמות שאפשר לציין הם RKE (להתקנה של ה Cluster בלבד, לאחר שהכנתם את המכונות באופן מסוים), מודול שקיים ומתוחזק ב Puppet להתקנה של Kubernetes, או Kubeinformation שהוא כלי online שעוזר לייצר templates של קונפיגורציות ע”פ סט בחירות שתתנו לו. Kubeinformation עשוי להיות מקור מעניין להתרשם בזריזות מתהליך ההתקנה, אבל בעת כתיבת פוסט זה הוא עדיין לא תומך ב EKS (זו הפריט הבא ב roadmap שלו).

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

כלים להתקנת קוברנטיס יכלו בקלות להפוך לסוג של Distros כמו Linux Distros אך מכיוון שנראה היום שרוב העולם ילך לכיוון של managed Kubernetes – להם תישאר נישה קטנה יחסית, של משתמשים מתקדמים שרוצים לשלוט בהתקנת ה Kubernetes שלהם בעצם.

סיכום

העולם הטכנולוגי מתקדם בחזית רחבה לכיוון קוברנטיס (גם בצורה עיוורת לפעמים – סממן חזק להפיכתו ל”באזז”). קוברנטיס היא תשתית מרשימה, אבל גם לא-פשוטה לניהול. התסריט הסביר ביותר הוא שפתרונות של Managed Kubernetes ישמשו את רוב השחקנים בשוק, בעיקר הקטנים והבינוניים (תמיד יכולה להיות שחקנית שתדמה ל Netflix ע”ג AWS, כלומר: שתחליט להריץ גם מאות-אלפי worker nodes על גבי פתרון Managed).

Enterprises שרצים On-Premises, או מריצים ענן משלהם, או סתם חברות שמריצות Workload גדול במיוחד – כנראה ימשיכו לנהל את ה Kubernetes Cluster מא’ עד ת’ – אבל זו התמחות שהן יכולות להרשות לעצמן לפתח ולתחזק.

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

EKS נראה כרגע כאופציה בעלת נקודת הפתיחה הטובה ביותר להיות הפופולרית ביותר (פופולריות שנגזרת באופן ישיר מ AWS ומגוון השירותים הטובים שהיא מציעה) – אבל הכל עוד יכול לקרות. למשל: אם הקוברנטיס יהפוך לחשוב יותר משאר שירותי הענן – אזי ל GKE (קרי Google Kubernetes Engine) יש את היתרון הברור.

בגדול, עובדות בפניכם כרגע האפשרויות הבאות:

  • להתקין קוברנטיס לבד – על בסיס Installers כמובן, ולא בדרך הקשה והארוכה. יש לפניכם השקעה משמעותית בלמידה והתמחות של Infrastructure חדש ונוסף.
  • להשתמש בפתרון Managed Kubernetes, תוך שאתם משלמים “מחיר התבגרות” בשנה-שנתיים הבאות עד שהפתרון שבחרתם יתבגר.
  • לדחות בשנה-שנתיים את אימוץ קוברנטיס עד שהוא יהיה קל מאוד לצריכה בצורה Managed.
    • אם אתם לא יודעים לומר מה Kubernetes יתרום לכם ברגע זה – זו הבחירה הנבונה (אם כי לא הכי-מגניבה)
  • להחליט שאתם בוחרים לא להשתמש בקוברנטיס כעיקרון, מה שיכול לזרוק אתכם לאחת משתי נקודות קיצון חברתיות בעולם התוכנה: “סופר מיושנים” או “סופר מגניבים וחתרניים”.
  • להחליט שאתם מתחילים עם קוברנטיס היום, לדבר על זה הרבה, להשקיע ב POCs ולמידה – אבל בעצם להתברבר עם זה עוד שנה-שנתיים עד שנקודה שבה אימוץ Kubernetes יהיה דבר קל – מה שבעצם שם אתכם עם ה Majority של התעשייה.

שיהיה בהצלחה!

—

לינקים רלוונטיים: 

השוואה בין GKE, EKS וAKS (מקור: Kubdex)

על כלי ניהול תצורה / Provisioning – מבראשית ועד ימי ה Docker

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

ישנם מגוון כלים לניהול תצורה (Configuration Management בקיצור CM), המאפשרים לנהל מספר גדול של שרתים (מאות, אולי אלפים) בצורה אוטומטית ומסודרת. כלים אלו לרוב מספקים את היכולות הבאות:

  • Change Management – ניהול הגדרות ה”מצב הרצוי” בתצורת השרתים, בצורה מסודרת וניתנת לשליטה. למשל: שינוי הגדרות של nginx בשרתים מסוג x או הוספת תיקיה חדשה במערכת הקבצים של שרתים מסוג y.
    • חשוב שיהיה קל להבין ולהגדיר מהם “שרתים מסוג x”. לעתים אגב, אלו יכולים להיות שרתים עם מערכות הפעלה שונות, ושמריצים תוכנות שונות.
  • Provisioning – זהו בעצם התהליך של העברת שרת ממצב נתון כלשהו – למצב הרצוי.
    • זה יכול להיות התקנה של שרת מאפס, או בדיקת המצב בשרת קיים – וביצוע השינויים הנדרשים על מנת להגיע למצב הרצוי.
    • לרוב שינוי ההגדרה יכלול ביצוע שינוי בשרתים שכבר “באוויר”, וגם הכללת השינוי החדש בשרתים הבאים שיקומו.
    • כאשר מבצעים שינויים, ישנן תקלות (פעולות רצויות שנכשלו) – תקלות שיש לנהל.
  • Orchestration – תיאום הפעולות בין כמה שרתים. למשל:
    • ביצוע שינוי מסוים באותו הזמן על מספר שרתים. אולי כדאי קודם לבצע בדיקה שמאשרת (כמיטב היכולת) שאכן כל השרתים מסוגלים לעבור את השינוי.
    • אם אחוז גבוה מהשרתים לא מצליח לעבור שינוי – אולי כדאי לעצור את השינוי המתגלגל, ולהתחיל פעולה של rollback (חזרה למצב הקודם)?
    • יש שינויים שצריכים להיעשות בצורה מדורגת כלשהי: קודם ביצוע שינוי בשרתי x ורק אח”כ אפשר לבצע את השינוי בשרתי y.

הכל כמובן – בצורה אוטומטית.

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

“דור ראשון”

CFEngine

את הכלי הזה יכירו בעיקר הוותיקים שבינינו. הוא התחיל לפעול ב93′ (כלומר: שנת 1993- למי שלא הבין) והיווה מהפכה תפיסתית בעולם ניהול-השרתים. הוא התחיל כפרויקט קוד פתוח, אך ב 2008 נוספה לו גרסה “מסחרית” עם תמיכה – ומאז הוא משתמש בעיקר תצורות מסובכות של ארגונים גדולים.

CFEngine ממומש בשפת C, והוא ידוע במהירות הגבוהה שלו. מצד שני – הוא דורש ידע מלא בתכנות בשפת C על מנת לתפעל אותו, מה שמגביל מאוד את קהל היעד.

כלי זה, כמו הכלים הבאים אחריו עובדים ע”פ עקרון דומה:

  • שרת מרכזי מחזיק את התצורה הרצויה לסוגי השרתים השונים (ע”פ ארגון של קבוצות או כללים).
  • על כל שרת מותקן Agent שמתשאל מדי פעם את השרת המרכזי, וברגע שהוא מבין שיש לבצע שינוי תצורה (קרי: עדכון תוכנה, שינוי הגדרות, וכו’) – הוא מבצע אותו.
    • כששרת מופעל בפעם הראשונה (לפעמים הוא כולל מערכת הפעלה ו Agent בלבד) – הוא יבצע את כל שינויי התצורה לפני שיתחבר ל Load Balancer (קרי: יהיה זמין לשאר ה Landscape).
איך CFEngine עובד. מקור: CFEngine.com

“דור שני”

Puppet

הכלי הבא שהופיע והשאיר חותם הוא Puppet, עם המטפורה המפורסמת של ה “Puppet Master” – השרת המרכזי שלו שהוא כמו “מפעיל בובות”. גם Puppet החל בשנת 2005 כ Open Source ורק מאוחר יותר הופיעה גרסה מסחרית (Enterprise).
החידוש המשמעותי של Puppet היה שהוא לא דרש ידע מעמיק בתכנות, אלא כתיבת DSL (כלומר: Domain Specific Language) המבוססת על שפת רובי – דבר שצוות ה Operations של הארגון היה מסוגל לתפעל בצורה מלאה.

קוד Puppet לדוגמה

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

השפה של Puppet (או כלי CM אחרים) היא DSL שמותאמת לצרכים המאוד ספציפיים של ניהול תצורה, ועוזרת לשרת את קריאות הקוד (הקוד הרבה יותר נוח לקריאה מ bash) ולצמצם טעויות אפשריות. עוד ייתרון הוא היכולת להגדיר תצורה שתפעל על מערכות הפעלה שונות (דיסטרוס שונים של לינוקס, או אפילו לינוקס ו”חלונות”).

השפה של Puppet מספקת שורה של פרמיטיבים (File, User, Package, Service, וכו’) שניתן להרכיב למודולים (הניתנים לשימוש חוזר) או פשוט להוריד מוכנים מ PuppetForge[א]. היכולת לשתף מודולים ברמת הקהילה מסייעת לקיצור זמני-פיתוח והגברת אמינות ניהול התצורה – כל עוד מדובר במודולים איכותיים. יש לציין שלא כולם כאלו, וחשוב מאוד לברור את מקור המודולים בהם אתם משתמשים.

בזכות קלות השימוש – Puppet לקח מ CFEngine את הבכורה.

Chef

לא הרבה מאוחר יותר, בשנת 2008, הופיע כלי חשוב נוסף בשם Chef. גם הוא, אגב, כלל סדרת מטפורות בלתי-נשכחות (“Knife”, “Kitchen”, “Cookbook”, ו “Recipe”, וכו’). Chef שיפר כמה מהדברים שהציקו ב Puppet וזכה לפופולריות גדולה בעצמו. גם הוא – מבוסס על שפת רובי.
בשלב הזה Chef ו Puppet החלו בתחרות “ראש בראש”, כאשר הם משלימים כל הזמן את הפיצ’רים החדשים אחד של השני. במהלך התחרות הזו נוספו לכל אחד מהם יכולות וכלים, מה שגרם להם בעצם להפוך מכלים פשוטים יחסית – לכלים מורכבים לשימוש, הדורשים מהמשתמשים למידה משמעותית.

בגדול, Chef נחשב יותר “ידידותי למפתח” (כזה שרגיל לכתוב בדיקות יחידה, ו/או לעבוד בכלי פיתוח)  בעוד Puppet מעט יותר ידידותי לאיש ה Operations (שאינו מתכנת).
יש אומרים ש Puppet נוח יותר לניהול תחנות עבודה של משתמשים, וש Chef – נוח יותר לניהול חוות שרתים (אולי בגלל ה output המפורט שלו שמסייע לאתר הבעיה – כאשר יש תקלות). בסופו של דבר, שני הכלים קרובים זה לזה ביכולות, ובבגרות. ל Puppet יש קהילה גדולה יותר, וב Chef מורכב יותר להתמקצע.

לא לזכותם של הכלים הללו ניתן לומר שהם כיום מורכבים למדי לשימוש, עבור רוב המשימות הנפוצות, וה Learning Curve שלהם הוא תלול ממה שארגונים רבים היו רוצים.

עוד נקודה מעניינת היא ששלושת הכלים שהזכרתי עד רגע זה (Chef, Puppet, ו CFEngine) תוכננו ונבנו בתקופה בה התפיסה הייתה לעדכן שרתים קיימים, ולאורך זמן.

אני אסביר: כאשר יש לכם שרתים פיסיים (“ברזלים”), התקנה מלאה של שרת עשויה לקחת עשרות דקות – ואפילו מספר שעות. לבצע את ההליך הזה אפילו פעם אחת בחודש – זו בעיה רצינית.
כלים כמו הכלים הנ”ל התמקצעו בנושא של עדכון הדרגתי של שרתים, מה שגם נקרא Convergence, קרי: א. בדוק באיזה מצב השרת, ב. עדכן את תצורת השרת, רק במה שצריך – לתצורה הרצויה (deltas). עדכונים כאלו יכלו להיות כל כמה ימים.

גישת ה Convergence אפשרה לבצע עדכונים תכופים בתצורת השרתים, מבלי לגזול זמן רב / לשלם ב downtime.
המחיר של גישה זו היא שניהול deltas לאורך זמן הוא מסוכן ולא יציב – ודברים יכולים (ואכן) נוטים להשתבש. למשל: מפתח התחבר ב SSH לשרת ושינה הרשאה של איזו תיקיה. עדכון נכשל והשאיר אחריו מצב בלתי רצוי שאינו מתוקן ע”י הגדרות התצורה של הכלי, וכו’.
הפתרון היה להחזיר שרת ל “baseline” – ברגע שדברים מסתבכים. לשלם את המחיר ההתקנה מחדש – בכדי לחזור למצב של סדר ושליטה.
הבעיה: בזמן שחלף עד שהבנו שהשרת הוא בתצורה בעייתית – התצורה הבעייתית יוצרת “רעש”, ועוד רעש בפרודקשיין!

התפיסה השלטת היום היא תפיסה של Immutable Servers (או “כמעט Immutable Servers”), כאשר כל שינוי תצורה (או: כמעט כל שינוי תצורה) – משמעו ליצור Image חדש, נקי ומסודר של שרת, ולעדכן את המכונות הרצויות.
היכולת הזו מתאפשרת בעקבות טכנולוגיות הוירטואליזציה והענן שהפכו לנפוצות כ”כ, ומתקדמות צעד אחד נוסף קדימה בעקבות טכנולוגיה כמו Containers.

כלומר: כל פעם שאנו רוצים לבצע שינוי בשרתים (נניח להוסיף לשרת agent של logstash) – ניצור Image חדש ונקי, ונריץ את כלי שלבי ה provisioning מאפס עד לקבלת שרת בתצורה הרצויה (כולל השלב החדש של התקנת ה logstash agent). כעת נייצר מהשרת הזה Image ואת ה Image הזה – נתקין על המכונות הפיסיות בפרודקשיין.

גישת ה Immutable Server נחשבת אמינה ופשוטה יותר לשליטה – ולכן עדיפה. החיסרון: שינויים קטנים עדיין דורשים בנייה של Image – תהליך שיכול לארוך זמן רב (עשרות דקות עד שעות).
אם כל השינוי הנדרש בשרת הוא העתקה של קובץ בודד, שינוי הרשאות על תיקיה, או שינוי הגדרה – רבים מאיתנו יעדיפו שיהיה על השרת גם כלי CM בעזרתו יוכלו לבצע את השינוי בזריזות. הזריזות הזו חשובה מאוד כאשר יש להגיב לתקלות בפרודקשיין. במקביל, ניתן לבצע את השינוי בצורה מסודרת על ה Image ו”ליישר קו” ב deployment הבא.
גישה זו, היא גישת ה “כמעט Immutable Servers” – המשלבת בעצם בין שתי הגישות.

שינוי הגישה מניהול תצורה בעזרת deltas שמתמשכים למשך חודשים, לצורה של “Immutable Servers” או “כמעט Immutable Servers” (לא ידוע לי על מונח מוסכם) פתח הזדמנות לכלים פשוטים משמעותית, שלא צריכים להתמודד עם המורכבות הרבה של ניהול deltas בתצורת השרת – להצטרף לזירה.

אפשר לציין ש Chef ו Puppet הם עדיין הכלים הנפוצים. הם שולטים בזירת ה CM כבר זמן רב, והשפיעו עליה ועל עולם התוכנה רבות.

“דור שלישי”



Ansible

בשנת 2012, הופיעו כלי CM חדש בשם Ansible ששינה הרבה מצורת העבודה של Chef ו Puppet:

  • ניהול העדכונים: במקום שיהיה שרת מרכזי (או כמה לצרכי HA ו Scale) אליו כל ה Agent פונים ב pull, הגישה היא לבצע push: אתם פונים לשרתים השונים ואומרים להם לבצע את השינוי.
    • יתרונות: הסרת שרת הקונפיגורציה מה landscape. הבדיקות של תצורות חדשות נעשות ב cycles קצרים יותר, ב push העדכונים מגיעים לשרתים מהר יותר. קל לשימוש בסביבת פיתוח, בה ניתן לפתוח laptop ולעדכן שרת – בלי להתקין ולתחזק “שרת מרכזי”.
    • חסרונות: כאשר מדובר ב scale גדול (מאות ואלפי שרתים) – עדכון השרתים ב push ייקח יותר זמן. אם בדיוק עלה שרת חדש לפני שיש image מעודכן – הוא עשוי לפספס את העדכון.
  • שפת התכנות: במקום DSL ומיומנויות של semi-תכנות, ההגדרה של התצורה נעשית בעזרת קובץ yaml פשוט.
    • יתרונות: הרבה פחות “קוד” לכתוב. זמן למידה קצר בהרבה של הכלי. אין צורך ברקע בתכנות בכלל על מנת ליצור הגדרות תצורה.
    • במקום שפת תכנות שיוצרת הפשטה מעל כל סוג של מערכת הפעלה, שכבת ההפשטה היא רזה. יש מודול לפקודות apt (נניח אובונטו) ומודול לפקודות yum (נניח Red Hat). ההפשטה הרזה לא מאפשרת “לכתוב סקריפט אחד שמתאים לכל מערכת הפעלה”, אך מפשטת מאוד את הלמידה (כי אתם יודעים כיצד apt או yum עובדים, ומקלה להבין מה קורה בפועל.
    • חסרונות: פחות גמישות: בעיות CM מורכבות יידרשו כתיבת סקריפט מיוחד (בעיקר: שימוש ב Jinja2 – שפת templates בה ניתן לכתוב מעט קוד פייטון או להפעיל קוד bash).
    • הערה: Ansible הושפעה מפייטון (השפה בה היא כתובה) בגישת ה “Batteries included”. המודולים הטובים שנכתבו / אושרו ע”י Ansible הם חלק מהכלי, ולא צריך להוריד אותם מ repository מרכזי כמו Chef או Puppet.
  • אין Agnets: אין צורך להתקין Agent (להלן Chef-Client או Puppet-Agent): על גבי השרתים. Ansible משתמש ב SSH סטנדרטי (ליתר דיוק: OpenSSH) בכדי לגשת לשרתים ולבצע בהם שינויים. עבור Windows – משתמשים ב PowerShell remoting.
    • יתרונות: אין צורך בהתקנה, עדכון, וניטור של Agents על גבי השרתים. רק צריך שרת עם SSH ו Python 2.5.
    • חסרונות: SSH הוא אטי יותר (פחות מתאים לעדכון אלפי שרתים),
Salt (מבית SaltSlack)
מעט לפני Ansible הופיעה ספרייה בשם Salt.

בכמה מובנים, Slat דומה למדי ל Ansible: הגדרות התצורה מוגדרות ב Yaml ולא בשפת תכנות, והוא פשוט בסדר גודל מ Chef או Puppet.
Salt ו Ansible שניהם כתובים בפייטון (Chef וגם Puppet כתובים בשפת רובי).

בכל זאת, הגישה של Salt להעברת העדכונים לשרתים – היא דיי דומה לזו של Chef ו Puppet.

המוטיבציה המוצהרת ליצירת Slat הייתה עדכון תצורה מהיר של קנה מידה גדול של שרתים. נראה שיצירת סביבת עבודה פשוטה יותר מ Chef/Puppet הייתה מהלך טבעי, אך משני – בתכנון של Salt.

  • השרת (הקרוי Slat Master) מבצע עדכונים ב push לתור של ZeroMQ. על השרתים מותקנים Minions (סוג של agents) שמאזינים לעדכונים על ה Queue ומבצעים מייד את העדכון. זו גישה משולבת בין ה Push של Ansible וה Pull של Chef/Puppet, שמבטיחה בד”כ זמני תגובה מהירים יותר מ Chef/Puppet (כי יש Push), ו scalability גבוה – היכולת לעדכן אלפי שרתים במקביל.
  • ניתן להגדיר ה Salt Master בהיררכיה כך שיש Centralized Master אחד שמגדיר מה לעשות, אך כמה Masters תחתיו שמפיצים את הבשורה לשרתים שונים. גישה זו יכולה לספק Scale גבוה אף יותר (נאמר: עשרות אלפי שרתים?)
בשנת 2014 Salt הציג Queue ייעודי משלו בשם RAET שהוא Scalable ואמין יותר מ ZeroMQ – לצורך הספציפי.
עידן ה Docker – “דור רביעי?”
כל כלי ה Configuration Management שותפים למורכבים מסוימת, מורכבות שנובעת מהקושי לבצע provisioning למערכת על “שרת אמיתי בפרודקשיין”. מה לעשות: אתם זקוקים לכלי מוניטורינג, אבטחה, לוגים, הגדרות, וכו’ – תצורת השרת היא מורכבת.Docker הוא כלי שמנבאים שיחולל מהפיכה לא רק בסביבת ה Production – אלא גם בעולם הגדרות התצורה.
מכיוון ש Docker “מפרק” את סביבת השרת להרבה Containers קטנים, הוא גם הופך את בעיית ניהול התצורה לסט בעיות קטנות יותר: תצורת ה Application Server ב Container A, תצורת ה Nginx ב Container B, ותצורת ה Monitoring Deamon ב Container C. על אחד מהן עשויה להיות בלתי תלויה, ופשוטה הרבה יותר מתצורה כוללת.

ה dockerfile, אם כן, הוא בערך כמו קובץ ה Yaml של Ansible או Salt, המאתר כיצד להתקין תהליך ואת התלויות שלו. טעינה מחדש של container היא כ”כ מהירה (עשרות שניות) – שניתן (אולי?) להסתפק בגישה טהורה של “Immutable Servers”.

מצד שני, לנהל אלפי containers (הנחה: על כל שרת יש 5-10 containers) – זו משימה קשה בהחלט! זו בעצם בעיית ה Orchestration ש Docker איננו מכסה. למשימה זו, נבנים כיום כלים ייעודיים, שהמוכרים ביניהם הם:

  • Kubernetes – כלי מבית גוגל, המשתמש בניסיון הקיים של גוגל בעבודה עם Linux Containers וניסיון שהצטבר עם כלי פנימי של גוגל בשם borg – האחראי על ה provisioning של השרתים הרבים מאוד ב Data Centers של גוגל. בעצם, גוגל כבר עושה היום משהו דומה.
    הניסיון הזה מתבטא למשל, בכל ש Kubernetes פתרה בעיות של Docker עצמו שהיו קיימות בגרסאות מוקדמות.
    Kubernetes מציע פתרון שלם יחסית, עם etcd ל container discovery, עם flannel לניהול הרשת בין ה containers (עניין מסובך ומתיש), ועוד.
    לסביבה העשירה הזו יש מחיר: יש לכלי CLI משלו, API משלו, וקבצי YAML משלו להגדרות התצורה – וזו סביבה שיש ללמוד להשתמש בה, בנוסף ל Docker.
  • Docker Swarm – הוא כלי אשר נוקט בגישה כמעט הפוכה: הוא תומך ב API הקיים של Docker, ובסביבת ה CLI – מה שאומר שקל מאוד להשתמש ב Docker Swarm עם ה toolchain הקיים של Docker (למשל: Docker Machine (לשעבר Krane) או Compose, וכו’).
    Docker Swarm מתוחזק ע”י קהילת ה Docker, והוא חלק מ”פתרון כולל” שנבנה בתוך קהילה זו לניהול תצורה.
    האם זו בהחלט הגישה המועדפת? קשה לומר. התאימות ל Docker API מגבילה את הכלי למגבלות של Docker עצמו ומקשה עליו לבצע חלק מהדברים שניתן יהיה לעשות ב Kubernetes.
זה לא כ”כ משנה איזה עוד כלים קיימים או ייווצרו בקהילה של Docker.
אם וכאשר Docker יהפוך לסביבת ה Deployment המקובלת ב Production – הוא עתיד לבצע Disruption גם בעולם ה CM ולשנות אותו משמעותית ממה שאנו מכירים אותו היום.

סיכום

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

הכלי הנכון ביותר לשימוש – משתנה עם הזמן, מכיוון שבחברות הצרכים משתנים: פעם יש רק לינוקס (נניח RedHat) ואז יש גם OpenSuse ו Windows. פעם ה deploy הוא תהליך חודשי – ולאחר מכן כבר מדברים על Continuous Deployment. פעם זה על שרתים של הארגון, ומעט אחרי זה – בענן. פעם על VMs וקצת אחרי זה על Containers.
הצרכים הארגוניים משתנים ככל כנראה מהר יותר ממה שניתן להסתגל לכלים השונים, ומכאן ניתן להסיק שאחוז גבוה מהארגונים משתמש בכל רגע נתון בכלי CM שאינו אופטימלי לצרכים שלו.

ישנה תקווה אמיתית שכלים חדשים ופשוטים יותר (Ansible או Swarm, למשל) יאפשרו לארגונים לבצע שינויים תכופים יותר בצורת העבודה – ולהתאים בצורה טובה יותר את מערכת ה CM לצרכים המשתנים של הארגון.

שיהיה בהצלחה!

—–
קישורים רלוונטיים
Chef vs. Ansible vs. Puppet vs. Salt בהקשר של OpenStack – אך עדיין מעניין ורלוונטי.

http://martinfowler.com/bliki/ImmutableServer.html – פוסט של מרטין פאוולר על Immutable Servers.

http://techblog.netflix.com/2013/03/ami-creation-with-aminator.html – פוסט מהבלוג של Netflix שמתאר את תהליך ה Provisioning שלהם

על Convergence מול Immutable Deployment

—–
[א] רמז לכך ש puppet נבנה בימים בהם הכלי המקובל לניהול קוד פתוח היה SourceForge? היום בוודאי היו קוראים לו PuppetHub…