GitOps: השוואה של שיטות משיכה ודחיפה

הערה. תרגום: בקהילת Kubernetes, טרנד בשם GitOps צובר פופולריות ברורה, כפי שראינו באופן אישי, מבקר KubeCon Europe 2019. המונח הזה היה יחסית חדש בדוי על ידי ראש Weaveworks - אלכסיס ריצ'רדסון - והכוונה היא לשימוש בכלים המוכרים למפתחים (בעיקר Git, ומכאן השם) כדי לפתור בעיות תפעוליות. בפרט, אנחנו מדברים על הפעולה של Kubernetes על ידי אחסון התצורות שלה ב-Git והפצה אוטומטית של שינויים לאשכול. Matthias Jg מדבר על שתי גישות להפצה זו במאמר זה.

בשנה שעברה, (למעשה, רשמית זה קרה באוגוסט 2017 - בערך תרגום) ישנה גישה חדשה לפריסת יישומים ב-Kubernetes. זה נקרא GitOps, והוא מבוסס על הרעיון הבסיסי לפיו גרסאות פריסה עוקבות בסביבה המאובטחת של מאגר Git.

היתרונות העיקריים של גישה זו הם כדלקמן::

1. ניהול גרסאות של פריסה והיסטוריית שינויים. המצב של האשכול כולו מאוחסן במאגר Git, והפריסה מתעדכנת רק באמצעות commits. בנוסף, ניתן לעקוב אחר כל השינויים באמצעות היסטוריית ההתחייבויות.
2. ביטולים באמצעות פקודות Git מוכרות... מישור git reset מאפשר לך לאפס שינויים בפריסות; מדינות עבר זמינות תמיד.
3. בקרת גישה מוכנה. בדרך כלל, מערכת Git מכילה הרבה נתונים רגישים, ולכן רוב החברות מקדישות תשומת לב מיוחדת להגנה עליה. בהתאם, הגנה זו חלה גם על פעולות עם פריסות.
4. מדיניות לפריסות. רוב מערכות Git תומכות באופן מקורי במדיניות סניף אחר סניף - לדוגמה, רק בקשות משיכה יכולות לעדכן את המאסטר, ושינויים חייבים להיבדק ולקבל על ידי חבר צוות אחר. כמו בקרת גישה, אותה מדיניות חלה על עדכוני פריסה.

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

שיטות פריסה

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

1. מבוסס על תבניות Kubernetes/Customize מקוריות. זוהי הדרך הקלה ביותר לפרוס יישומים ב-Kubernetes. המפתח יוצר את קבצי ה-YAML הבסיסיים ומחיל אותם. כדי להיפטר משכתוב כל הזמן של אותן תבניות, פותחה Kustomize (היא הופכת תבניות Kubernetes למודולים). הערה. תרגום: Kustomize שולבה ב-kubectl עם שחרור של Kubernetes 1.14.
2. תרשימים של הגה. תרשימי הגה מאפשרים לך ליצור סטים של תבניות, מיכלי איניט, צדדיות וכו', המשמשות לפריסת יישומים עם אפשרויות התאמה אישית גמישות יותר מאשר בגישה מבוססת תבניות. שיטה זו מבוססת על קבצי YAML בתבנית. Helm ממלא אותם בפרמטרים שונים ולאחר מכן שולח אותם לטילר, רכיב אשכול שפורס אותם לאשכול ומאפשר עדכונים והחזרות. הדבר החשוב הוא שהלם בעצם רק מכניס את הערכים הרצויים לתבניות ואז מיישם אותם באותו אופן כפי שנעשה בגישה המסורתית (קרא עוד על איך הכל עובד וכיצד אתה יכול להשתמש בו ב- שלנו מאמר מאת Helm - משוער. תרגום). יש מגוון רחב של תרשימי Helm מוכנים המכסים מגוון רחב של משימות.
3. כלים חלופיים. ישנם כלים אלטרנטיביים רבים. המשותף לכולם הוא שהם הופכים כמה קובצי תבניות לקובצי YAML הניתנים לקריאה של Kubernetes ואז משתמשים בהם.

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

משוך דחוף

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

NB! כל היתרונות של שימוש ב-GitOps נשארים זהים עבור שתי הגישות.

גישה מבוססת משיכה

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

יתרונות:

1. לאף לקוח חיצוני אין זכויות לבצע שינויים באשכול; כל העדכונים מתפרסמים מבפנים.
2. חלק מהכלים גם מאפשרים לך לסנכרן עדכוני תרשים Helm ולקשר אותם לאשכול.
3. ניתן לסרוק את Docker Registry לאיתור גרסאות חדשות. אם תמונה חדשה זמינה, מאגר Git והפריסה מתעדכנים לגרסה החדשה.
4. ניתן להפיץ כלי משיכה על פני מרחבי שמות שונים עם מאגרים והרשאות שונות של Git. הודות לכך, ניתן להשתמש במודל ריבוי דיירים. לדוגמה, צוות A עשוי להשתמש במרחב שמות A, צוות B עשוי להשתמש במרחב שמות B, וצוות התשתית עשוי להשתמש במרחב גלובלי.
5. ככלל, הכלים קלים מאוד.
6. בשילוב עם כלים כגון מפעיל סודות חתומים של ביטנאמי, ניתן לאחסן סודות מוצפנים במאגר Git ולאחזר בתוך האשכול.
7. אין חיבור ל-CD pipelines מכיוון שהפריסה מתרחשת בתוך האשכול.

חסרונות:

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

גישה מבוססת דחיפה

בגישת הדחיפה, מערכת חיצונית (בעיקר CD pipelines) משיקה פריסות לאשכול לאחר התחייבות למאגר Git או אם צינור ה-CI הקודם הצליח. בגישה זו, למערכת יש גישה לאשכול.

Pros:

1. האבטחה נקבעת על ידי מאגר Git וצינור הבנייה.
2. פריסת תרשימי Helm קלה יותר ותומכת בתוספים של Helm.
3. קל יותר לנהל סודות מכיוון שניתן להשתמש בסודות בצינורות וניתן גם לאחסן אותם מוצפנים ב-Git (בהתאם להעדפות המשתמש).
4. אין קשר לכלי ספציפי, מכיוון שניתן להשתמש בכל סוג.
5. ניתן ליזום עדכוני גרסת מיכל באמצעות צינור הבנייה.

חסרונות:

1. נתוני הגישה לאשכול נמצאים בתוך מערכת הבנייה.
2. עדכון מיכלי פריסה עדיין קל יותר עם תהליך משיכה.
3. תלות כבדה במערכת ה-CD, מכיוון שהצינורות שאנו צריכים אולי נכתבו במקור עבור Gitlab Runners, ואז הצוות מחליט לעבור ל-Azure DevOps או Jenkins... ויצטרך להעביר מספר רב של צינורות לבנות.

תוצאות: דחיפה או משיכה?

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

לאחר מחשבה, הגעתי למסקנה בלתי צפויה שזה לא כך. אם נדבר על רכיבים שדורשים הגנה מקסימלית, רשימה זו תכלול אחסון סודי, מערכות CI/CD ומאגרי Git. המידע בתוכם מאוד פגיע וזקוק להגנה מרבית. בנוסף, אם מישהו נכנס למאגר Git שלך ויכול לדחוף לשם קוד, הוא יכול לפרוס מה שהוא רוצה (בין אם זה pull או push) ולחדור למערכות של האשכול. לפיכך, הרכיבים החשובים ביותר שצריכים להיות מוגנים הם מאגר Git ומערכות CI/CD, לא אישורי האשכול. אם יש לך מדיניות ובקרות אבטחה מוגדרות היטב עבור סוגים אלה של מערכות, ואישורי אשכול נשלפים רק לצינורות כסודות, ייתכן שהאבטחה הנוספת של גישת משיכה לא תהיה בעלת ערך כפי שחשבו במקור.

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

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

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

נ.ב הערה מהמתרגם

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

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

ניסינו את שני הדגמים והגענו לאותן מסקנות כמו מחבר המאמר:

1. מודל המשיכה מתאים לנו לארגן עדכונים של רכיבי מערכת במספר רב של אשכולות (ראה. מאמר על מפעיל תוסף).
2. מודל הדחיפה המבוסס על GitLab CI מתאים היטב להפעלת יישומים באמצעות תרשימי Helm. במקביל, פריסת הפריסות בתוך צינורות מנוטרת באמצעות הכלי werf. אגב, בהקשר של הפרויקט הזה שלנו, שמענו את ה-"GitOps" הקבוע כשדנו בבעיות הדוחקות של מהנדסי DevOps בדוכן שלנו ב-KubeCon Europe'19.

PPS מהמתרגם

קרא גם בבלוג שלנו:

• «עצות וטריקים של Kubernetes: העברת משאבים הפועלים באשכול לניהול Helm 2";
• «הכירו את kubedog, ספרייה למעקב אחר משאבי Kubernetes";
• «הרחבת והשלמה של Kubernetes (סקירה כללית ודוח וידאו)";
• «טיפים ליצירת זרימות עבודה מותאמות אישית ב- GitLab CI".

רק משתמשים רשומים יכולים להשתתף בסקר. להתחברבבקשה.

האם אתה משתמש ב-GitOps?

• כן, גישה למשוך

• כן, לדחוף

• כן, משיכה + דחיפה

• כן, משהו אחר

• לא

30 משתמשים הצביעו. 10 משתמשים נמנעו.

מקור: www.habr.com