סאות'ברידג' בצ'ליאבינסק וביטריקס בקוברנטס

מפגשי מנהל מערכת Sysadminka מתקיימים בצ'ליאבינסק, ובפעם האחרונה נתתי דיווח על הפתרון שלנו להפעלת יישומים ב-1C-Bitrix ב-Kubernetes.

Bitrix, Kubernetes, Ceph - תערובת נהדרת?

אני אגיד לך איך הרכבנו פתרון עובד מכל זה.

בואו נלך!

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

אם תרצו להגיע אלינו עם דיווח או כמאזין - ברוכים הבאים, כתבו ל [מוגן בדוא"ל] ובטלגרם t.me/vadimisakanov.

הדיווח שלי

שקופיות

פתרון "Bitrix in Kubernetes, גרסה Southbridge 1.0"

אדבר על הפתרון שלנו בפורמט "עבור בובות ב-Kubernetes", כפי שנעשה במפגש. אבל אני מניח שאתה מכיר את המילים Bitrix, Docker, Kubernetes, Ceph לפחות ברמת המאמרים בוויקיפדיה.

מה מוכן ב-Bitrix ב-Kubernetes?

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

דיווח של אלכסנדר סרבול, 1C-Bitrix, ואנטון טוזלוקוב מ-Qsoft:

אני ממליץ להקשיב לו.

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

אה... למעשה, זה הכל.

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

אבל יש כבר הרבה תמונות Docker מוכנות להפעלת Bitrix ב-Docker: https://hub.docker.com/search?q=bitrix&type=image

האם זה מספיק כדי ליצור פתרון שלם עבור Bitrix ב-Kubernetes?
לא. יש מספר רב של בעיות שצריך לפתור.

מהן הבעיות עם Bitrix ב- Kubernetes?

ראשית, תמונות מוכנות מ- Dockerhub אינן מתאימות ל-Kubernetes

אם אנחנו רוצים לבנות ארכיטקטורת microservices (וב-Kubernetes אנחנו עושים זאת בדרך כלל), אנחנו צריכים להפריד את אפליקציית Kubernetes שלנו לקונטיינרים ולגרום לכל קונטיינר לבצע פונקציה אחת קטנה (ולעשות אותה היטב). למה רק אחד? בקיצור, כמה שיותר פשוט יותר אמין יותר.
כדי להיות יותר ספציפי, צפה במאמר ובסרטון זה, בבקשה: https://habr.com/ru/company/southbridge/blog/426637/

תמונות Docker ב- Dockerhub בנויות בעיקר על עיקרון ה-all-in-one, כך שעדיין היינו צריכים ליצור אופניים משלנו ואפילו ליצור תמונות מאפס.

שנית - קוד האתר נערך מפאנל הניהול

יצרנו מדור חדש באתר - הקוד עודכן (נוספה ספרייה עם שם המדור החדש).

אם שינית את המאפיינים של רכיב מלוח הניהול, הקוד השתנה.

Kubernetes "כברירת מחדל" לא יכול לעבוד עם זה; קונטיינרים חייבים להיות חסרי מדינה.

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

שלישית - אתה צריך לפתור את הבעיה עם הפריסה

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

רביעית - אתה צריך לפתור את הנושא של אחסון סטטי

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

מה חסר בפתרון שלנו?

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

אנחנו גם לא מאחסנים את מסד הנתונים ב-Kubernetes (עדיין הטמעתי פתרונות עם מסד נתונים ב-Kubernetes לסביבות פיתוח, אבל לא לייצור).

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

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

אדריכלות

יש הרבה פודים "עובדים" עם שרת אינטרנט (עובדים).
אחד מתחת עם משימות cron (נדרשת רק אחת).
שדרוג אחד לעריכת קוד האתר מפאנל הניהול (נדרש גם רק אחד).

אנו פותרים שאלות:

• היכן לאחסן הפעלות?
• היכן לאחסן את המטמון?
• איפה לאחסן סטטיקה, לא למקם ג'יגה-בייט של סטטיק בחבורה של מכולות?
• איך בסיס הנתונים יעבוד?

תמונת דוקר

אנו מתחילים בבניית תמונת Docker.

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

עשינו בדיוק תמונה כזו.

זה כולל nginx, apache/php-fpm (ניתן לבחור במהלך הבנייה), msmtp לשליחת דואר ו-cron.

בהרכבת התמונה, כל בסיס הקוד של האתר מועתק לספריית /app (למעט אותם חלקים שנעביר לאחסון משותף נפרד).

מיקרו שירותים, שירותים

תרמילי עובדים:

• מיכל עם nginx + מיכל apache/php-fpm + msmtp
• לא הסתדר להעביר את msmtp למיקרו-שירות נפרד, ביטריקס מתחילה להתמרמר על כך שהיא לא יכולה לשלוח דואר ישירות
• לכל מיכל יש בסיס קוד שלם.
• איסור על שינוי קוד במכולות.

cron under:

• מיכל עם apache, php, cron
• בסיס קוד מלא כלול
• איסור על שינוי קוד בקונטיינרים

שדרוג תחת:

• מיכל nginx + apache/php-fpm מיכל + msmtp
• אין מניעה לשנות קוד במכולות

אחסון הפעלות

אחסון מטמון ביטריקס

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

אחסון לסטטיקה

אתה יכול להשתמש בכל דבר: ceph, nfs (אבל אנחנו לא ממליצים על nfs לייצור), אחסון רשת מספקי ענן וכו'.

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

מסד נתונים

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

אחסון הפעלות

אנחנו משתמשים ב-memcached :)

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

$ helm install stable/memcached --name session

php.ini - כאן התמונה מכילה הגדרות לאחסון הפעלות ב-memcached

השתמשנו במשתני סביבה כדי להעביר נתונים על מארחים עם memcached https://kubernetes.io/docs/tasks/inject-data-application/define-environment-variable-container/.
זה מאפשר לך להשתמש באותו קוד בסביבות ה-dev, stage, test, prod (שמות המארח המאוחסנים ב-memcached בהם יהיו שונים, כך שעלינו להעביר שם מארח ייחודי עבור הפעלות לכל סביבה).
אחסון מטמון ביטריקס

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

אנו משתמשים גם ב-memcached.
פתרון זה מומלץ על ידי Bitrix עצמה.

$ helm install stable/memcached --name cache

bitrix/.settings_extra.php - כאן ב-Bitrix מצוין היכן מאוחסן המטמון

אנו משתמשים גם במשתני סביבה.

קרונטסקי

ישנן גישות שונות להפעלת Crontasks ב-Kubernetes.

• פריסה נפרדת עם פוד להפעלת Crontasks
• cronjob לביצוע crontasks (אם זו אפליקציית אינטרנט - עם wget https://$host$cronjobname, או kubectl exec בתוך אחד מתרמיל העובדים וכו')
• וכו '

אתה יכול להתווכח על הנכון ביותר, אבל במקרה זה בחרנו באפשרות "פריסה נפרדת עם תרמילים עבור Crontasks"

איך זה נעשה:

• הוסף משימות cron דרך ConfigMap או דרך קובץ config/addcron
• במקרה אחד אנו משיקים מיכל זהה ל-worker pod + מאפשרים ביצוע של משימות כתר בו
• נעשה שימוש באותו בסיס קוד, הודות לאיחוד, הרכבת המכולה היא פשוטה

מה טוב אנחנו מקבלים:

• יש לנו Crontasks עובדים בסביבה זהה לסביבת המפתחים (דוקר)
• Crontasks לא צריך להיות "לכתוב מחדש" עבור Kubernetes, הם עובדים באותה צורה ובאותו בסיס קוד כמו קודם
• משימות cron יכולות להתווסף על ידי כל חברי הצוות עם זכויות התחייבות לענף הייצור, לא רק מנהלים

Southbridge K8SDפרוס מודול ועריכת קוד מפאנל הניהול

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

וזה נראה כך:

זה מאפשר לך להגדיר קובץ Cookie שמזהה את מנהל האתר ומאפשר ל-Kubernetes לשלוח תנועה לפוד השדרוג.

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

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

תרשים הגה

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

זה בונה עובד, ugrade, cron pods, מגדיר כניסות, שירותים ומעביר משתנים מסודות Kubernetes ל-pods.

אנו מאחסנים את הקוד ב- Gitlab, ואנחנו גם מפעילים את Helm build מ- Gitlab.

בקיצור, זה נראה ככה

$ helm upgrade --install project .helm --set image=registrygitlab.local/k8s/bitrix -f .helm/values.yaml --wait --timeout 300 --debug --tiller-namespace=production

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

לפרוס

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

שלבים:

• build (בניית תמונת Docker חדשה)
• בדיקה (בדיקה)
• ניקוי (הסרת סביבת הבדיקה)
• push (אנחנו שולחים את זה ל-Docker Registry)
• deploy (אנו פורסים את האפליקציה ל-Kubernetes דרך Helm).

היי, זה מוכן, בואו ליישם את זה!
ובכן, או לשאול שאלות אם יש כאלה.

אז מה עשינו

מנקודת מבט טכנית:

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

מנקודת מבט עסקית:

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

מקור: www.habr.com