הסרת ענף תכונה מיושן באשכול Kubernetes

היי! סניף תכונה (aka deploy preview, review app) - זה כאשר לא רק הענף הראשי נפרס, אלא גם כל בקשת משיכה לכתובת URL ייחודית. אתה יכול לבדוק אם הקוד עובד בסביבת ייצור; ניתן להציג את התכונה למתכנתים אחרים או למומחי מוצר. בזמן שאתה עובד בבקשת משיכה, כל פריסה נוכחית חדשה של commit עבור הקוד הישן נמחקת, והפריסה החדשה עבור הקוד החדש מופעלת. שאלות עשויות להתעורר כאשר מיזוג בקשת משיכה לתוך ענף המאסטר. אתה כבר לא צריך את ענף התכונות, אבל משאבי Kubernetes עדיין נמצאים באשכול.

עוד על ענפי תכונה

גישה אחת ליצירת ענפי תכונה ב-Kubernetes היא להשתמש במרחבי שמות. בקיצור, תצורת הייצור נראית כך:

kind: Namespace
apiVersion: v1
metadata:
  name: habr-back-end
...

kind: Deployment
apiVersion: apps/v1
metadata:
  namespace: habr-back-end
spec:
  replicas: 3
...

עבור ענף תכונה, נוצר מרחב שמות עם המזהה שלו (לדוגמה, מספר בקשת המשיכה) וסוג כלשהו של קידומת/פוסט-תיקון (לדוגמה, -יחסי ציבור-):

kind: Namespace
apiVersion: v1
metadata:
  name: habr-back-end-pr-17
...

kind: Deployment
apiVersion: apps/v1
metadata:
  namespace: habr-back-end-pr-17
spec:
  replicas: 1
...

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

$ kubectl get pods --all-namespaces | grep -e "-pr-"
NAMESPACE            ... AGE
habr-back-end-pr-264 ... 4d8h
habr-back-end-pr-265 ... 5d7h

אתה יכול לקרוא כיצד ליישם ענפי תכונות באשכול כאן и כאן.

מוטיבציה

בואו נסתכל על מחזור חיים טיפוסי של בקשת משיכה עם אינטגרציה מתמשכת (continuous integration):

1. אנו דוחפים התחייבות חדשה לסניף.
2. על המבנה מופעלים linters ו/או בדיקות.
3. תצורות בקשת המשיכה של Kubernetes נוצרות תוך כדי תנועה (לדוגמה, המספר שלה מוכנס לתבנית המוגמרת).
4. באמצעות kubectl application, תצורות מתווספות לאשכול (פריסה).
5. בקשת המשיכה מתמזגת לסניף הראשי.

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

כיצד להשתמש

התקן את הפרויקט עם הפקודה למטה:

$ kubectl apply -f https://raw.githubusercontent.com/dmytrostriletskyi/stale-feature-branch-operator/master/configs/production.yml

צור קובץ עם התוכן הבא והתקן באמצעות kubectl apply -f:

apiVersion: feature-branch.dmytrostriletskyi.com/v1
kind: StaleFeatureBranch
metadata:
  name: stale-feature-branch
spec:
  namespaceSubstring: -pr-
  afterDaysWithoutDeploy: 3

פרמטר מחרוזת משנה של מרחב שמות נדרש לסנן מרחבי שמות עבור בקשות משיכה ממרחבי שמות אחרים. לדוגמה, אם לאשכול יש את מרחבי השמות הבאים: habr-back-end, habr-front-end, habr-back-end-pr-17, habr-back-end-pr-33, אז המועמדים למחיקה יהיו habr-back-end-pr-17, habr-back-end-pr-33.

פרמטר afterDaysWithoutDeploy נדרש כדי למחוק מרחבי שמות ישנים. לדוגמה, אם נוצר מרחב שמות 3 дня 1 час חזרה, והפרמטר מציין 3 дня, מרחב השמות הזה יימחק. זה עובד גם בכיוון ההפוך אם נוצר מרחב השמות 2 дня 23 часа חזרה, והפרמטר מציין 3 дня, מרחב השמות הזה לא יימחק.

יש עוד פרמטר אחד, הוא אחראי על התדירות לסרוק את כל מרחבי השמות ולבדוק ימים ללא פריסה - checkEveryMinutes. כברירת מחדל זה שווה 30 минутам.

אֵיך מַפעִילִים אֶת זֶה

בפועל, תצטרך:

1. סַוָר לעבודה בסביבה מבודדת.
2. מיניקוב יגדל אשכול Kubernetes באופן מקומי.
3. קובקטל - ממשק שורת פקודה לניהול אשכולות.

אנו מגייסים אשכול Kubernetes באופן מקומי:

$ minikube start --vm-driver=docker
minikube v1.11.0 on Darwin 10.15.5
Using the docker driver based on existing profile.
Starting control plane node minikube in cluster minikube.

אנו מציינים kubectl השתמש באשכול מקומי כברירת מחדל:

$ kubectl config use-context minikube
Switched to context "minikube".

הורדת תצורות עבור סביבת הייצור:

$ curl https://raw.githubusercontent.com/dmytrostriletskyi/stale-feature-branch-operator/master/configs/production.yml > stale-feature-branch-production-configs.yml

מכיוון שתצורות הייצור מוגדרות לבדוק מרחבי שמות ישנים, והאשכול החדש שלנו אינו מכיל אותם, נחליף את משתנה הסביבה IS_DEBUG על true. עם הערך הזה הפרמטר afterDaysWithoutDeploy לא נלקח בחשבון ומרחבי שמות אינם נבדקים במשך ימים ללא פריסה, רק עבור התרחשות המחרוזת המשנה (-pr-).

אם אתה על Linux:

$ sed -i 's|false|true|g' stale-feature-branch-production-configs.yml

אם אתה על macOS:

$ sed -i "" 's|false|true|g' stale-feature-branch-production-configs.yml

התקנת הפרויקט:

$ kubectl apply -f stale-feature-branch-production-configs.yml

בדיקה שהופיע משאב באשכול StaleFeatureBranch:

$ kubectl api-resources | grep stalefeaturebranches
NAME                 ... APIGROUP                             ... KIND
stalefeaturebranches ... feature-branch.dmytrostriletskyi.com ... StaleFeatureBranch

אנו בודקים שאופרטור הופיע באשכול:

$ kubectl get pods --namespace stale-feature-branch-operator
NAME                                           ... STATUS  ... AGE
stale-feature-branch-operator-6bfbfd4df8-m7sch ... Running ... 38s

אם אתה מסתכל על היומנים שלו, הוא מוכן לעבד משאבים StaleFeatureBranch:

$ kubectl logs stale-feature-branch-operator-6bfbfd4df8-m7sch -n stale-feature-branch-operator
... "msg":"Operator Version: 0.0.1"}
...
... "msg":"Starting EventSource", ... , "source":"kind source: /, Kind="}
... "msg":"Starting Controller", ...}
... "msg":"Starting workers", ..., "worker count":1}

אנו מתקינים מוכנים fixtures (תצורות מוכנות ליצירת מודלים של משאבי אשכול) עבור משאב StaleFeatureBranch:

$ kubectl apply -f https://raw.githubusercontent.com/dmytrostriletskyi/stale-feature-branch-operator/master/fixtures/stale-feature-branch.yml

התצורות מציינות לחפש מרחבי שמות עם מחרוזת משנה -pr- פעם ב 1 минуту.:

apiVersion: feature-branch.dmytrostriletskyi.com/v1
kind: StaleFeatureBranch
metadata:
  name: stale-feature-branch
spec:
  namespaceSubstring: -pr-
  afterDaysWithoutDeploy: 1 
  checkEveryMinutes: 1

המפעיל הגיב ומוכן לבדוק מרחבי שמות:

$ kubectl logs stale-feature-branch-operator-6bfbfd4df8-m7sch -n stale-feature-branch-operator
... "msg":"Stale feature branch is being processing.","namespaceSubstring":"-pr-","afterDaysWithoutDeploy":1,"checkEveryMinutes":1,"isDebug":"true"}

להתקין fixtures, המכיל שני מרחבי שמות (project-pr-1, project-pr-2) והם deployments, services, ingress, וכולי:

$ kubectl apply -f https://raw.githubusercontent.com/dmytrostriletskyi/stale-feature-branch-operator/master/fixtures/first-feature-branch.yml -f https://raw.githubusercontent.com/dmytrostriletskyi/stale-feature-branch-operator/master/fixtures/second-feature-branch.yml
...
namespace/project-pr-1 created
deployment.apps/project-pr-1 created
service/project-pr-1 created
horizontalpodautoscaler.autoscaling/project-pr-1 created
secret/project-pr-1 created
configmap/project-pr-1 created
ingress.extensions/project-pr-1 created
namespace/project-pr-2 created
deployment.apps/project-pr-2 created
service/project-pr-2 created
horizontalpodautoscaler.autoscaling/project-pr-2 created
secret/project-pr-2 created
configmap/project-pr-2 created
ingress.extensions/project-pr-2 created

אנו בודקים שכל המשאבים לעיל נוצרו בהצלחה:

$ kubectl get namespace,pods,deployment,service,horizontalpodautoscaler,configmap,ingress -n project-pr-1 && kubectl get namespace,pods,deployment,service,horizontalpodautoscaler,configmap,ingress -n project-pr-2
...
NAME                              ... READY ... STATUS  ... AGE
pod/project-pr-1-848d5fdff6-rpmzw ... 1/1   ... Running ... 67s

NAME                         ... READY ... AVAILABLE ... AGE
deployment.apps/project-pr-1 ... 1/1   ... 1         ... 67s
...

מאז שכללנו debug, מרחבי שמות project-pr-1 и project-pr-2, לכן כל שאר המשאבים יצטרכו להימחק באופן מיידי מבלי לקחת בחשבון את הפרמטר afterDaysWithoutDeploy. ניתן לראות זאת ביומני המפעיל:

$ kubectl logs stale-feature-branch-operator-6bfbfd4df8-m7sch -n stale-feature-branch-operator
... "msg":"Namespace should be deleted due to debug mode is enabled.","namespaceName":"project-pr-1"}
... "msg":"Namespace is being processing.","namespaceName":"project-pr-1","namespaceCreationTimestamp":"2020-06-16 18:43:58 +0300 EEST"}
... "msg":"Namespace has been deleted.","namespaceName":"project-pr-1"}
... "msg":"Namespace should be deleted due to debug mode is enabled.","namespaceName":"project-pr-2"}
... "msg":"Namespace is being processing.","namespaceName":"project-pr-2","namespaceCreationTimestamp":"2020-06-16 18:43:58 +0300 EEST"}
... "msg":"Namespace has been deleted.","namespaceName":"project-pr-2"}

אם תבדוק את זמינות המשאבים, הם יהיו בסטטוס Terminating (תהליך מחיקה) או שכבר נמחק (פלט הפקודה ריק).

$ kubectl get namespace,pods,deployment,service,horizontalpodautoscaler,configmap,ingress -n project-pr-1 && kubectl get namespace,pods,deployment,service,horizontalpodautoscaler,configmap,ingress -n project-pr-2
...

אתה יכול לחזור על תהליך היצירה fixtures מספר פעמים וודא שהם יוסרו תוך דקה.

אלטרנטיבות

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

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

   • כדי לעשות זאת, עליך לדעת איזו בקשת משיכה מתייחסת ל-commit שנבנה. מכיוון שמרחב השמות של ענף הפיצ'רים מכיל את מזהה בקשת ה-pull - המספר שלו, או שם הענף, המזהה תמיד יצטרך להיות מוגדר ב-commit.
   • בניית ענפי מאסטר נכשלים. לדוגמה, יש לך את השלבים הבאים: הורדת הפרויקט, הרץ בדיקות, בניית הפרויקט, ביצוע שחרור, שליחת הודעות, נקה את ענף הפיצ'רים של בקשת המשיכה האחרונה. אם הבנייה נכשלת בעת שליחת הודעה, תצטרך למחוק את כל המשאבים באשכול באופן ידני.
   • ללא הקשר מתאים, מחיקת ענפי תכונה ב-Master build אינה ברורה מאליה.

2. שימוש ב-webhooks (דוגמה).

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

3. כתוב Cronjob ולהוסיף אשכול Kubernetes.

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

תודה על תשומת הלב שלך למאמר. קישור לפרויקט ב-Github.

מקור: www.habr.com