ההטמעה שלנו ב-Continuous Deployment על הפלטפורמה של הלקוח

אנו ב-True Engineering הקמנו תהליך לאספקה ​​רציפה של עדכונים לשרתים של לקוחות ורוצים לחלוק את החוויה הזו.

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

במאמר זה נדבר על כל שלבי תהליך ה-Continuous Deployment (CD) או משלוח עדכונים לפלטפורמת הלקוח:

1. איך מתחיל התהליך הזה?
2. סנכרון עם מאגר Git של הלקוח,
3. הרכבה של backend ו-frontend,
4. פריסה אוטומטית של יישומים בסביבת בדיקה,
5. פריסה אוטומטית ל-Prod.

נשתף את פרטי ההגדרה לאורך הדרך.

1. התחל תקליטור

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

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

ארגנו עבודה דרך מאגר אחד מכמה סיבות:

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

2. סנכרון עם מאגר Git של קוד המקור של הלקוח

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

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

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

3. הרכבת הקצה האחורי והחזיתי

בניית ה-backend וה-frontend הן שתי משימות מקבילות המבוצעות במערכת GitLab Runner. תצורת ההרכבה המקורית שלו ממוקמת באותו מאגר.

הדרכה לכתיבת סקריפט YAML לבנייה ב-GitLab.

GitLab Runner לוקח את הקוד מהמאגר הנדרש, מרכיב אותו עם פקודת הבנייה של יישום Java ושולח אותו ל-Docker Registry. כאן אנו מרכיבים את ה-backend וה-frontend, משיגים תמונות Docker, אותן הכנסנו למאגר בצד הלקוח. כדי לנהל תמונות Docker שאנו משתמשים בהן תוסף Gradle.

אנו מסנכרנים את גרסאות התמונות שלנו עם גרסת השחרור שתפורסם ב-Docker. להפעלה חלקה ביצענו מספר התאמות:

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

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

אנו מקבלים את גרסת היישום מתוצאות ביצוע הפקודה
git describe --tags --abbrev=7.

4. פריסה אוטומטית של כל השינויים בסביבת הבדיקה (UAT)

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

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

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

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

5. פריסה אוטומטית של כל השינויים ב-Prod

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

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

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

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

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

APP_EXTERNAL_DOMAIN: {{ (pluck .Values.global.env .Values.app.properties.app_external_domain | first) }}

.Values.global.env – משתנה זה מאחסן את שם הסביבה (פרוד, שלב, UAT).
.Values.app.properties.app_external_domain – במשתנה זה אנו מגדירים את התחום הרצוי בקובץ .Values.yaml

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

לאחרונה יחסית, תמיכה ב-K8S הופיעה ב-Spring Cloud, כולל עבודה עם configMaps: אביב ענן Kubernetes. בעוד שהפרויקט מתפתח ומשתנה באופן קיצוני, אנחנו לא יכולים להשתמש בו בייצור. אבל אנחנו עוקבים באופן פעיל אחר מצבו ומשתמשים בו בתצורות DEV. ברגע שהוא יתייצב, נעבור משימוש במשתני סביבה אליו.

בסך הכל

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

תוכניות עתידיות: הגירה אוטומטית של מסדי נתונים

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

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

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

אנו מתכננים להפוך את העברת מסדי הנתונים לאוטומטיים באמצעות עבודת K8S, ולשלב אותו בתהליך התקליטור. ובהחלט נשתף את החוויה הזו ב-Habré.

מקור: www.habr.com