Helm Security

ניתן לתאר את מהות הסיפור על מנהל החבילות הפופולרי ביותר עבור Kubernetes באמצעות אימוג'י:

• הקופסה היא Helm (שזה הדבר הקרוב ביותר למהדורת האימוג'י האחרונה);
• מנעול - אבטחה;
• האיש הקטן הוא הפתרון לבעיה.

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

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

כל מה במאמר זה חל על Helm 2. גרסה זו נמצאת כעת בייצור וככל הנראה היא זו שבה אתה משתמש כעת, והיא הגרסה המכילה את סיכוני האבטחה.

על הדובר: אלכסנדר חיירוב (allexx) מפתחת כבר 10 שנים, ועוזרת בשיפור התוכן Moscow Python Conf++ והצטרפה לוועדה פסגת ההגה. כעת הוא עובד ב-Chainstack כמוביל פיתוח - זוהי הכלאה בין מנהל פיתוח לאדם שאחראי על מסירת מהדורות סופיות. כלומר, הוא ממוקם בשדה הקרב, שם מתרחש הכל מיצירת המוצר ועד להפעלתו.

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

הגה

זהו מנהל חבילות (תרשים) עבור Kubernetes. הדרך האינטואיטיבית והאוניברסלית ביותר להביא יישומים לאשכול Kubernetes.

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

Helm הוא הטוב ביותר שזמין ופופולרי כרגע.

למה הלם? בעיקר בגלל שהוא נתמך על ידי CNCF. Cloud Native הוא ארגון גדול ומהווה חברת האם לפרויקטים Kubernetes, etcd, Fluentd ואחרים.

עובדה חשובה נוספת היא שהלם הוא פרויקט פופולרי מאוד. כשהתחלתי לדבר על איך להפוך את Helm לאבטח בינואר 2019, לפרויקט היו אלף כוכבים ב-GitHub. עד מאי היו 12 אלף מהם.

אנשים רבים מתעניינים בהלם, כך שגם אם עדיין לא תשתמשו בו, תרוויחו מהידע על האבטחה שלו. בטיחות חשובה.

צוות הליבה של Helm נתמך על ידי Microsoft Azure ולכן הוא פרויקט יציב למדי, בניגוד לרבים אחרים. שחרורו של Helm 3 Alpha 2 באמצע יולי מצביע על כך שיש די הרבה אנשים שעובדים על הפרויקט, ויש להם את הרצון והאנרגיה לפתח ולשפר את Helm.

Helm פותר מספר בעיות שורש של ניהול יישומים ב-Kubernetes.

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

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

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

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

Helm מאפשר לך:

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

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

הגה מבוססת על שלושה מושגים עיקריים:

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

ארכיטקטורת הגה

התרשים מתאר קונספטואלית את הארכיטקטורה ברמה הגבוהה של Helm.

הרשו לי להזכיר לכם שהלם הוא משהו שקשור ל-Kubernetes. לכן, אנחנו לא יכולים להסתדר בלי אשכול Kubernetes (מלבן). רכיב kube-apiserver נמצא במאסטר. בלי Helm יש לנו Kubeconfig. Helm מביא בינארי אחד קטן, אם אפשר לקרוא לזה כך, עזר Helm CLI, שמותקן על מחשב, מחשב נייד, מיינפריים - על כל דבר.

אבל זה לא מספיק. להלם יש רכיב שרת בשם Tiller. זה מייצג את האינטרסים של Helm בתוך האשכול; זה יישום בתוך אשכול Kubernetes, בדיוק כמו כל יישום אחר.

הרכיב הבא של Chart Repo הוא מאגר עם תרשימים. יש מאגר רשמי, ויכול להיות שיש מאגר פרטי של חברה או פרויקט.

אינטראקציה

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

• אנחנו מדברים Helm install, גש למאגר (Chart Repo) וקבל תרשים Helm.

• כלי השירות Helm (Helm CLI) מקיים אינטראקציה עם Kubeconfig כדי להבין לאיזה אשכול לפנות. 
• לאחר קבלת המידע הזה, השירות מתייחס לטילר, שנמצא באשכול שלנו, כאפליקציה. 
• Tiller קורא ל-Kube-apiserver לבצע פעולות ב-Kubernetes, ליצור כמה אובייקטים (שירותים, פודים, העתקים, סודות וכו').

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

וקטור התקפה

נקודת התורפה הפוטנציאלית הראשונה היא API מועדף-משתמש. כחלק מהתוכנית, מדובר בהאקר שקיבל גישת מנהל ל-Helm CLI.

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

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

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

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

בואו נגדיל את הדיאגרמה, נוסיף עוד אלמנטים, אבל נשמור על כל הרכיבים הבסיסיים.

Helm CLI מתקשר עם Chart Repo, מקיים אינטראקציה עם Kubeconfig, והעבודה מועברת לאשכול לרכיב Tiller.

טילר מיוצג על ידי שני אובייקטים:

• Tiller-deploy svc, אשר חושף שירות מסוים;
• Tiller-deploy pod (בתרשים בעותק בודד בהעתק אחד), שעליו פועל כל העומס, הניגש לאשכול.

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

• המנגנון שבאמצעותו ה-Helm CLI ניגש ל-repo של התרשים: איזה פרוטוקול, האם יש אימות ומה אפשר לעשות איתו.
• הפרוטוקול שלפיו Helm CLI, באמצעות kubectl, מתקשר עם טילר. זהו שרת RPC המותקן בתוך האשכול.
• Tiller עצמו נגיש למיקרו-שירותים השוכנים באשכול ומקיימים אינטראקציה עם ה-Kube-apiserver.

בואו נדון בכל התחומים האלה לפי הסדר.

RBAC

אין טעם לדבר על אבטחה כלשהי עבור Helm או כל שירות אחר בתוך האשכול אלא אם RBAC מופעל.

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

https://rbac.dev/ - עורך דין אתר עבור RBAC. הוא מכיל כמות עצומה של חומרים מעניינים שיעזרו לכם להקים את RBAC, להראות למה הוא טוב ואיך בעצם לחיות איתו בייצור.

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

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

לרוע המזל, הלם לא יעשה זאת עבורך. אתה או מנהל אשכול Kubernetes שלך צריכים להכין קבוצה של תפקידים ו-RoleBindings עבור חשבון השירות מראש כדי לעבור את Helm.

נשאלת השאלה - מה ההבדל בין Role ל-ClusterRole? ההבדל הוא ש-ClusterRole פועל עבור כל מרחבי השמות, בניגוד לתפקידים רגילים ו-RoleBindings, שפועלים רק עבור מרחב שמות מיוחד. אתה יכול להגדיר מדיניות עבור האשכול כולו וכל מרחבי השמות, או להתאים אישית עבור כל מרחב שמות בנפרד.

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

עם זאת, יש דרך מצוינת המאפשרת לך להפעיל את Tiller מספר פעמים באשכול. אין בעיה עם זה, ניתן להפעיל את Tiller בכל מרחב שמות. לפיכך, אתה יכול להשתמש ב-RBAC, Kubeconfig כהקשר, ולהגביל את הגישה ל-Helm מיוחד.

זה ייראה כך.

לדוגמה, ישנן שתי הגדרות Kubeconfigs עם הקשר עבור צוותים שונים (שני מרחבי שמות): X Team עבור צוות הפיתוח ואשכול הניהול. לאשכול הניהול יש Tiller רחב משלו, הממוקם במרחב השמות של מערכת Kube, חשבון שירות מתקדם בהתאם. ומרחב שמות נפרד לצוות הפיתוח, הם יוכלו לפרוס את השירותים שלהם למרחב שמות מיוחד.

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

אתם מוזמנים להגדיר את Tiller בנפרד ולספק ל-Kubeconfig הקשר עבור הצוות, עבור מפתח ספציפי או עבור הסביבה: Dev, Staging, Production (ספק אם הכל יהיה על אותו אשכול, עם זאת, ניתן לעשות זאת).

בהמשך הסיפור שלנו, בואו נעבור מ-RBAC ונדבר על ConfigMaps.

ConfigMaps

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

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

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

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

עדיף להעביר את ה- Storage Helm לסודות, והם, בתורם, מאובטחים באופן מרכזי.

כמובן שזה יישאר מגבלת אחסון נתונים של 1 MB. Helm כאן משתמש ב-etcd כאחסון מבוזר עבור ConfigMaps. ושם סברו שזהו נתח נתונים מתאים לשכפול וכו'. יש דיון מעניין על זה ב- Reddit, אני ממליץ למצוא את הקריאה המצחיקה הזו לסוף השבוע או לקרוא את התמצית כאן.

Repos של תרשים

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

אתה בהחלט צריך לחשוף את Helm Repo באמצעות HTTPS - זו האפשרות הטובה ביותר והיא זולה.

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

בנוסף, Helm client תומך ב-TLS (לא במובן HTTP בצד השרת, אלא TLS הדדי). אתה יכול להשתמש במפתחות שרת ולקוח כדי לתקשר. למען האמת, אני לא משתמש במנגנון כזה כי אני לא אוהב תעודות הדדיות. בעיקרון, מוזיאון תרשים - הכלי העיקרי להגדרת Helm Repo עבור Helm 2 - תומך גם בהרשאה בסיסית. אתה יכול להשתמש באישור בסיסי אם זה נוח ושקט יותר.

יש גם תוסף helm-gcs, המאפשר לך לארח Repos של תרשים ב-Google Cloud Storage. זה די נוח, עובד נהדר והוא בטוח למדי, כי כל המנגנונים המתוארים ממוחזרים.

אם תפעילו HTTPS או TLS, תשתמשו ב-mTLS ותפעילו אימות בסיסי כדי להפחית עוד יותר סיכונים, תקבלו ערוץ תקשורת מאובטח עם Helm CLI ו-Chart Repo.

API של gRPC

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

כפי שכבר אמרתי, Tiller הוא שירות שחושף gRPC, לקוח Helm מגיע אליו דרך gRPC. כברירת מחדל, כמובן, TLS מושבת. מדוע זה נעשה היא שאלה שנויה במחלוקת, נראה לי כדי לפשט את ההגדרה בהתחלה.

להפקה ואפילו בימוי, אני ממליץ להפעיל TLS ב-gRPC.

לדעתי, בניגוד ל-mTLS לתרשימים, זה מתאים כאן ונעשה בפשטות רבה - יצירת תשתית PQI, יצירת אישור, הפעלת Tiller, העברת האישור בזמן האתחול. לאחר מכן, אתה יכול לבצע את כל פקודות Helm, להציג לעצמך את האישור שנוצר ואת המפתח הפרטי.

כך תגנו על עצמכם מכל הבקשות לטילר מחוץ לאשכול.

אז, אבטחנו את ערוץ החיבור לטילר, כבר דיברנו על RBAC והתאמנו את הזכויות של שרת ה-Kubernetes, מה שמצמצם את התחום איתו הוא יכול לקיים אינטראקציה.

הגה מוגן

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

כעת ניתן לצייר בבטחה את כל החיבורים בירוק:

• עבור Chart Repo אנו משתמשים ב-TLS או mTLS ובאישור בסיסי;
• mTLS עבור Tiller, והוא חשוף כשירות gRPC עם TLS, אנו משתמשים בתעודות;
• האשכול משתמש בחשבון שירות מיוחד עם Role and RoleBinding. 

איבטחנו את האשכול בצורה משמעותית, אבל מישהו חכם אמר:

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

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

בונוס

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

במאגר github.com/helm/charts כעת יש כ-300 תרשימים ושני זרמים: יציב וחממה. כל מי שתורם יודע היטב כמה קשה להגיע מאינקובטור לאורווה, וכמה קל לעוף מהאורווה. עם זאת, זה לא הכלי הטוב ביותר לחיפוש תרשימים עבור פרומתאוס וכל מה שתרצה, מסיבה אחת פשוטה - זה לא פורטל שבו אתה יכול לחפש בנוחות חבילות.

אבל יש שירות hub.helm.sh, מה שהופך את זה להרבה יותר נוח למצוא תרשימים. והכי חשוב, יש הרבה יותר מאגרים חיצוניים וכמעט 800 צ'ארמים זמינים. בנוסף, אתה יכול לחבר את המאגר שלך אם מסיבה כלשהי אינך רוצה לשלוח את התרשימים שלך ליציבים.

נסה את hub.helm.sh ובואו לפתח אותו ביחד. שירות זה נמצא תחת פרויקט Helm, ואתה אפילו יכול לתרום לממשק המשתמש שלו אם אתה מפתח חזיתי ורק רוצה לשפר את המראה.

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

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

אחרים, כמונו ב-Chainstack, משתמשים במסדי נתונים מנוהלים כמו MySQL או PostgreSQL עבור השרתים שלהם. לכן מסדי הנתונים שלנו ממוקמים איפשהו בענן.

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

זה מאוד פשוט. אתה יכול לבצע שאילתות, למשל, Managed MySQL ב-Azure עם שכבת בסיס (ניתן להגדיר זאת). באמצעות ה-API של Azure, בסיס הנתונים ייווצר ויהיה מוכן לשימוש. אתה לא צריך להתערב בזה, התוסף אחראי לכך. לדוגמה, OSBA (תוסף Azure) יחזיר אישורים לשירות ויעביר אותו להלם. תוכל להשתמש בוורדפרס עם MySQL בענן, לא להתמודד עם מסדי נתונים מנוהלים בכלל ולא לדאוג לגבי שירותים ממלכתיים בפנים.

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

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

ממצא נוסף שכבר הזכרתי הוא תוסף helm-gcs, המאפשר לך להשתמש ב-Google-buckets (אחסון אובייקטים) לאחסון תרשימי Helm.

אתה צריך רק ארבע פקודות כדי להתחיל להשתמש בו:

1. התקן את התוסף;
2. ליזום את זה;
3. הגדר את הנתיב לדלי, שנמצא ב-gcp;
4. לפרסם תרשימים בדרך הרגילה.

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

אלטרנטיבות

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

אלה יכולים להיות פתרונות מיוחדים, למשל, Ksonnet או Metaparticle. אתה יכול להשתמש בכלי ניהול התשתית הקלאסיים שלך (Ansible, Terraform, Chef וכו') לאותן מטרות שדיברתי עליהן.

סוף סוף יש פתרון מסגרת מפעיל, שהפופולריות שלו הולכת וגוברת.

Operator Framework היא חלופת ההגה המובילה שיש לשקול.

זה יותר יליד CNCF ו-Kubernetes, אבל מחסום הכניסה גבוה בהרבה, אתה צריך לתכנת יותר ולתאר מניפסטים פחות.

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

הנה תרשים ויזואלי של איפה הכל נמצא.

על ציר ה-x נמצאת רמת השליטה האישית שלך במתרחש, על ציר ה-Y נמצאת רמת הילידות של Kubernetes. Helm גרסה 2 נופלת איפשהו באמצע. בגרסה 3, לא בהרבה, אבל גם השליטה וגם רמת הילידות שופרו. פתרונות ברמת Ksonnet עדיין נחותים אפילו מהלם 2. עם זאת, כדאי להסתכל עליהם כדי לדעת מה עוד יש בעולם הזה. כמובן שמנהל התצורה שלך יהיה בשליטתך, אבל הוא לחלוטין לא מקורי של Kubernetes.

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

מרחיבים פשוט משפרים מעט את השליטה, משלימים את זרימת העבודה או חותכים פינות בצינורות CI/CD.

העתיד של הלם

החדשות הטובות הן ש- Helm 3 מגיע. גרסת האלפא של Helm 3.0.0-alpha.2 כבר שוחררה, אתה יכול לנסות אותה. זה די יציב, אבל הפונקציונליות עדיין מוגבלת.

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

כאשר Helm 2 נוצר, שהיה בסביבות הזמן של Kubernetes 1.8 או אפילו קודם לכן, רבים מהמושגים לא היו בשלים. לדוגמה, מושג ה-CRD מיושם כעת באופן פעיל, והלם יעשה זאת השתמש ב-CRDלאחסן מבנים. ניתן יהיה להשתמש רק בלקוח ולא לתחזק את חלק השרת. בהתאם לכך, השתמש בפקודות Kubernetes מקוריות כדי לעבוד עם מבנים ומשאבים. זהו צעד ענק קדימה.

יופיע תמיכה במאגרי OCI מקוריים (Open Container Initiative). זו יוזמה ענקית, והלם מתעניין בעיקר כדי לפרסם את התרשימים שלה. זה מגיע לנקודה, למשל, Docker Hub תומך בתקני OCI רבים. אני לא מנחש, אבל אולי ספקי מאגר Docker הקלאסיים יתחילו לתת לך את ההזדמנות לארח את תרשימי Helm שלך.

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

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

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

Helm 3 יהיה פשוט יותר, בטוח ומהנה יותר, לא בגלל שאנחנו לא אוהבים את Helm 2, אלא בגלל ש-Kubernetes הופכת למתקדמת יותר. בהתאם לכך, Helm יכול להשתמש בפיתוחים של Kubernetes וליצור מנהלים מצוינים עבור Kubernetes.

עוד חדשות טובות הן DevOpsConf אלכסנדר חיירוב יגיד לך, האם מכולות יכולות להיות מאובטחות? נזכיר לכם שהכנס בנושא שילוב תהליכי פיתוח, בדיקה ותפעול יתקיים במוסקבה 30 בספטמבר ו-1 באוקטובר. אתה עדיין יכול לעשות את זה עד 20 באוגוסט הגש דו"ח וספרו לנו על הניסיון שלכם עם הפתרון אחד מני רבים משימות של גישת DevOps.

עקוב אחר מחסומי הוועידה והחדשות ב ניוזלטר и ערוץ טלגרם.

מקור: www.habr.com