מבוא ל-GitOps עבור OpenShift

היום נדבר על העקרונות והמודלים של GitOps, כמו גם על האופן שבו מודלים אלו מיושמים בפלטפורמת OpenShift. מדריך אינטראקטיבי בנושא זה זמין по ссылке.

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

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

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

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

עקרונות GitOps

• הגדרות מערכת מתוארות כקוד מקור

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

• המצב והקונפיגורציה הרצויים של המערכות נקבעים ומנוסחים ב-Git

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

• ניתן להחיל שינויי תצורה באופן אוטומטי באמצעות בקשות משיכה

באמצעות בקשות משיכה של Git, אנו יכולים לשלוט בקלות כיצד שינויים מוחלים על תצורות במאגר. לדוגמה, הם יכולים להינתן לחברי צוות אחרים לבדיקה או לרוץ מבחני CI וכו'.

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

• תיקון הבעיה של סחיפה בלתי מבוקרת של תצורות

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

דגמי GitOps עבור OpenShift

מיישב משאבים על אשכול

לפי מודל זה, לאשכול יש בקר שאחראי על השוואת משאבי Kubernetes (קבצי YAML) במאגר Git עם המשאבים האמיתיים של האשכול. אם מתגלים אי התאמות, הבקר שולח הודעות ואולי נוקט בפעולה כדי לתקן את הפער. מודל GitOps זה משמש ב-Anthos Config Management ו-Weaveworks Flux.

מיישב משאבים חיצוני (דחיפה)

מודל זה יכול להיחשב כווריאציה של הקודם, כאשר יש לנו בקר אחד או יותר האחראי על סנכרון משאבים בצמדי "מאגר Git - Kubernetes cluster". ההבדל כאן הוא שלכל אשכול מנוהל אין בהכרח בקר נפרד משלו. צמדי אשכולות של Git - k8s מוגדרים לעתים קרובות כ-CRDs (הגדרות משאבים מותאמות אישית), שיכולים לתאר כיצד הבקר צריך לבצע סנכרון. בתוך מודל זה, בקרים משווים את מאגר Git שצוין ב-CRD עם משאבי האשכולות של Kubernetes, שצוינו גם ב-CRD, ומבצעים פעולות מתאימות על סמך תוצאות ההשוואה. בפרט, מודל GitOps זה משמש ב- ArgoCD.

GitOps בפלטפורמת OpenShift

ניהול תשתית Kubernetes מרובת אשכולות

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

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

במקרה זה, יש לפתור הרבה בעיות, במיוחד:

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

תצורות יישומים

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

במקרה זה, יש לפתור את המשימות הבאות:

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

מקרי שימוש ב-OpenShift GitOps

1. החלת שינויים ממאגר Git

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

2. סנכרון עם Secret Manager

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

3. שליטה בתצורות סחיפה

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

4. הודעות על סחיפה של תצורה

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

5. סנכרון ידני של תצורות בעת דריפטינג

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

6. סנכרון אוטומטי של תצורות בעת סחיפה

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

7. מספר אשכולות - מאגר אחד

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

8. היררכיה של תצורות אשכול (ירושה)

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

לדוגמה, אם מנהל מערכת מגדיר את ההיררכיה "אשכולות ייצור (פרוד) → אשכולות של מערכת X → אשכולות ייצור של מערכת X" במאגר Git, אז שילוב של ההגדרות הבאות מוחל על אשכולות הייצור של מערכת X:

• הגדרות משותפות לכל אשכולות הייצור.
• הגדרות עבור אשכול System X.
• הגדרות עבור אשכול הייצור של מערכת X.

9. תבניות ועקיפות תצורה

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

10. כלול ואי הכללה סלקטיבי עבור תצורות, תצורות יישומים

המנהל יכול להגדיר את התנאים ליישום או אי יישום של תצורות מסוימות לאשכולות עם מאפיינים מסוימים.

11. תמיכה בתבניות

מפתחים ייהנו מהיכולת לבחור כיצד יוגדרו משאבי האפליקציה (Helm Chart, Kubernetes yaml טהור וכו') על מנת להשתמש בפורמט המתאים ביותר עבור כל אפליקציה ספציפית.

כלי GitOps בפלטפורמת OpenShift

ArgoCD

ArgoCD מיישמת את מודל External Resource Reconcile ומציעה ממשק משתמש מרכזי לתזמור קשרים של אחד לרבים בין אשכולות ומאגרי Git. החסרונות של תוכנית זו כוללים את חוסר היכולת לנהל יישומים כאשר ArgoCD אינו פועל.

אתר רשמי

שטף

Flux מיישמת מודל On-Cluster Resource Reconcile וכתוצאה מכך, אין ניהול ריכוזי של מאגר ההגדרות, המהווה נקודת תורפה. מצד שני, דווקא בגלל חוסר הריכוזיות, היכולת לנהל אפליקציות נשארת גם אם אשכול אחד נכשל.

אתר רשמי

התקנת ArgoCD ב-OpenShift

ArgoCD מציע ממשק שורת פקודה מעולה ומסוף אינטרנט, כך שלא נסקור כאן את Flux וחלופות אחרות.

כדי לפרוס את ArgoCD בפלטפורמת OpenShift 4, בצע את השלבים הבאים כמנהל אשכול:

פריסת רכיבי ArgoCD בפלטפורמת OpenShift

# Create a new namespace for ArgoCD components
oc create namespace argocd
# Apply the ArgoCD Install Manifest
oc -n argocd apply -f https://raw.githubusercontent.com/argoproj/argo-cd/v1.2.2/manifests/install.yaml
# Get the ArgoCD Server password
ARGOCD_SERVER_PASSWORD=$(oc -n argocd get pod -l "app.kubernetes.io/name=argocd-server" -o jsonpath='{.items[*].metadata.name}')

שיפור של שרת ArgoCD כך שניתן יהיה לראותו על ידי OpenShift Route

# Patch ArgoCD Server so no TLS is configured on the server (--insecure)
PATCH='{"spec":{"template":{"spec":{"$setElementOrder/containers":[{"name":"argocd-server"}],"containers":[{"command":["argocd-server","--insecure","--staticassets","/shared/app"],"name":"argocd-server"}]}}}}'
oc -n argocd patch deployment argocd-server -p $PATCH
# Expose the ArgoCD Server using an Edge OpenShift Route so TLS is used for incoming connections
oc -n argocd create route edge argocd-server --service=argocd-server --port=http --insecure-policy=Redirect

פריסת כלי ArgoCD Cli

# Download the argocd binary, place it under /usr/local/bin and give it execution permissions
curl -L https://github.com/argoproj/argo-cd/releases/download/v1.2.2/argocd-linux-amd64 -o /usr/local/bin/argocd
chmod +x /usr/local/bin/argocd

שינוי סיסמת הניהול של ArgoCD Server

# Get ArgoCD Server Route Hostname
ARGOCD_ROUTE=$(oc -n argocd get route argocd-server -o jsonpath='{.spec.host}')
# Login with the current admin password
argocd --insecure --grpc-web login ${ARGOCD_ROUTE}:443 --username admin --password ${ARGOCD_SERVER_PASSWORD}
# Update admin's password
argocd --insecure --grpc-web --server ${ARGOCD_ROUTE}:443 account update-password --current-password ${ARGOCD_SERVER_PASSWORD} --new-password

לאחר השלמת שלבים אלה, תוכל לעבוד עם שרת ArgoCD דרך מסוף האינטרנט ArgoCD WebUI או כלי שורת הפקודה ArgoCD Cli.
https://blog.openshift.com/is-it-too-late-to-integrate-gitops/

GitOps - אף פעם לא מאוחר מדי

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

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

oc create -f https://raw.githubusercontent.com/openshift/federation-dev/master/labs/lab-4-assets/namespace.yaml
oc create -f https://raw.githubusercontent.com/openshift/federation-dev/master/labs/lab-4-assets/deployment.yaml
oc create -f https://raw.githubusercontent.com/openshift/federation-dev/master/labs/lab-4-assets/service.yaml
oc expose svc/httpd -n simple-app

אז יש לנו אפליקציה בעבודת יד. כעת יש להעביר אותו תחת ניהול GitOps ללא אובדן זמינות. בקיצור, זה עושה את זה:

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

כפי שכבר הוזכר בקודם статье, ב-GitOps יש מקור מידע אחד ויחיד על כל האובייקטים באשכול(י) Kubernetes - מאגר Git. לאחר מכן, אנו יוצאים מנקודת הנחה שהארגון שלך כבר משתמש במאגר Git. זה יכול להיות ציבורי או פרטי, אבל זה חייב להיות נגיש לאשכולות Kubernetes. זה יכול להיות אותו מאגר כמו עבור קוד יישומים, או מאגר נפרד שנוצר במיוחד עבור פריסות. מומלץ לקבל הרשאות קפדניות במאגר שכן שם יאוחסנו סודות, מסלולים ושאר דברים רגישים לאבטחה.

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

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

oc get namespace simple-app -o yaml --export > namespace.yaml
oc get deployment httpd -o yaml -n simple-app --export > deployment.yaml
oc get service httpd -o yaml -n simple-app --export > service.yaml
oc get route httpd -o yaml -n simple-app --export > route.yaml

כעת נערוך את הקובץ deployment.yaml כדי להסיר את השדה שארגו CD לא יכול לסנכרן.

sed -i '/sgeneration: .*/d' deployment.yaml

בנוסף, יש לשנות את המסלול. תחילה נגדיר משתנה מרובה שורות ולאחר מכן נחליף את ingress: null בתוכן של אותו משתנה.

export ROUTE="  ingress:                                                            
    - conditions:
        - status: 'True'
          type: Admitted"

sed -i "s/  ingress: null/$ROUTE/g" route.yaml

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

git commit -am ‘initial commit of objects’
git push origin master

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

argocd repo add https://github.com/cooktheryan/blogpost

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

argocd app create --project default 
--name simple-app --repo https://github.com/cooktheryan/blogpost.git 
--path . --dest-server https://kubernetes.default.svc 
--dest-namespace simple-app --revision master --sync-policy none

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

כעת נערוך ניסוי כדי לוודא שאין שגיאות בקבצים שלנו.

argocd app sync simple-app --dry-run

אם אין שגיאות, אתה יכול להמשיך לסנכרון.

argocd app sync simple-app

לאחר הפעלת הפקודה argocd get באפליקציה שלנו, עלינו לראות שסטטוס האפליקציה השתנה ל-Brea או Synced. המשמעות היא שכל המשאבים במאגר Git תואמים כעת לאותם משאבים שכבר נפרסו.

argocd app get simple-app
Name:               simple-app
Project:            default
Server:             https://kubernetes.default.svc
Namespace:          simple-app
URL:                https://argocd-server-route-argocd.apps.example.com/applications/simple-app
Repo:               https://github.com/cooktheryan/blogpost.git
Target:             master
Path:               .
Sync Policy:        <none>
Sync Status:        Synced to master (60e1678)
Health Status:      Healthy
...   

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

argocd app set simple-app --sync-policy automated --auto-prune

אז, הבאנו בהצלחה אפליקציה תחת שליטת GitOps שבתחילה לא השתמשה ב-GitOps בשום צורה.

מקור: www.habr.com