פריסת 1С-Bitrix ב-Kubernetes: מדריך מלא עם מקרי בוחן

1С-Bitrix לא תוכנן עבור אורקסטרציה של קונטיינרים. סשנים בקבצים, קאש על דיסק, קבצים שהועלו ב-upload/, הליבה ב-bitrix/ — כל האלמנטים האלה עם מצב דורשים טיפול מיוחד ב-Kubernetes. עם זאת, המשימה פתירה, ואתרי Bitrix פרודקשן רצים באשכולות k8s תחת עומס כבד. פרסנו את Bitrix ב-Kubernetes עבור יותר מ-15 פרויקטים, והניסיון שלנו מראה: תוך 2-3 שבועות ניתן לקבל תשתית עמידה לתקלות עם קנה מידה אוטומטי.

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

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

למה Kubernetes עבור Bitrix הוא אתגר?

הבעיה העיקרית — Bitrix מאחסן מצב (סשנים, קאש, קבצים שהועלו) מקומית על דיסק. ב-Kubernetes, פודים הם זמניים: נתונים אובדים כאשר פוד נוצר מחדש. ללא הגדרות מיוחדות, המשתמש יאבד את הסשן בכל בקשה, והקאש יהפוך לחסר תועלת. בנוסף, רישיון Bitrix מקושר לכתובת IP או דומיין — במהלך פריסה בענן יש להבטיח כתובת IP חיצונית יציבה. מורכבות נוספת היא טיפול בקבצים שהועלו: בסכמה הקלאסית, כל קבצי ההעלאה נמצאים בתיקייה משותפת הנגישה לכל שרתי האינטרנט. אינטגרציה עם 1С דרך CommerceML דורשת קבצים זמניים שחייבים להיות זמינים לכל הפודים. Bitrix24 ניתן גם לפריסה ב-Kubernetes, אך הארכיטקטורה שלו שונה — נדרשת הגדרה נפרדת של סוכנים ואירועים. תיעוד Kubernetes ממליץ להשתמש ב-PersistentVolume עבור נתונים עם מצב. יישמנו גישה זו ב-15 פרויקטים.

איך אנחנו פותרים את בעיית הסשן והקאש?

סשנים. העברת אחסון הסשנים ל-Redis. ב-.settings.php של Bitrix, אנו מציינים:

'session' => [ 'value' => [ 'mode' => 'separated', 'handlers' => [ 'general' => [ 'type' => 'redis', 'host' => 'redis-service', 'port' => 6379, ], ], ], ], 

קאש. שינוי .settings.php ל-Memcached:

'cache' => [ 'value' => [ 'type' => ['memcache' => 'memcache'], 'memcache' => [ 'host' => 'memcached-service', 'port' => 11211, ], ], ], 

קבצים. תיקיית 'session' => [ 'value' => [ 'mode' => 'separated', 'handlers' => [ 'general' => [ 'type' => 'redis', 'host' => 'redis-service', 'port' => 6379, ], ], ], ], מותקנת דרך PersistentVolumeClaim במצב ReadWriteMany (NFS, CephFS). הקוד נאפה לתוך תמונת Docker — זה מאיץ את הפריסה ומפשט ניהול גרסאות.

איך להגדיר אחסון קבצים שהועלו?

לאחסון קבצים שהועלו, אנו משתמשים ב-PersistentVolumeClaim עם מצב גישה ReadWriteMany. אנו ממליצים על שרת NFS באשכול או אחסון קבצים בענן (לדוגמה, Yandex Object Storage דרך FUSE). חשוב: קוד האתר צריך להיות אפוי בתוך תמונת Docker, ותיקיית ההעלאה צריכה להיות מוחרגת מהתמונה דרך .dockerignore. זה מבטיח שקבצים לא יאבדו כאשר פודים נוצרים מחדש. בפועל, עבור קטלוג עם 2 מיליון מוצרים, ההעלאה תופסת 50 GB — PV מתמודד עם זה ללא בעיות.

טעויות אופייניות בקונטיינריזציה של Bitrix

למה מסד הנתונים צריך להיות ממוקם מחוץ לאשכול?

למרות שניתן להריץ MySQL ב-Kubernetes דרך StatefulSet, אנו ממליצים בחום להשתמש בפתרונות מנוהלים (AWS RDS, Yandex Managed Service for MySQL). זה מפשט גיבויים, שכפול ועדכונים. מסדי נתונים הם הרכיב הקריטי ביותר, והתחזוקה שלהם באשכול דורשת מומחיות נפרדת. לדוגמה, במקרה של תקלת etcd, שחזור מסד הנתונים יכול לקחת שעות, בעוד שפתרון מנוהל מבטיח SLA של 99.95%.

מבנה של Kubernetes Manifests

namespace: bitrix-prod ├── Deployment: bitrix-app (PHP-FPM + Nginx sidecar) ├── Service: bitrix-app-svc ├── Ingress: bitrix-ingress (с TLS) ├── StatefulSet: redis ├── StatefulSet: memcached ├── PersistentVolumeClaim: bitrix-upload (RWX) ├── ConfigMap: php-fpm-config ├── ConfigMap: nginx-config └── Secret: db-credentials 

Deployment עבור PHP-FPM עם Nginx sidecar, התקנת upload ותצורות — תבנית סטנדרטית. את מסד הנתונים (MySQL) אנו ממליצים למקם בפתרון מנוהל — זה אמין יותר וקל יותר לתחזוקה.

קנה מידה אופקי

לאחר הגדרת Redis ו-Memcached, קנה המידה הוא פקודה אחת: CACHE_TYPE=A. ניתן להוסיף HorizontalPodAutoscaler:

apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: bitrix-hpa spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: bitrix-app minReplicas: 2 maxReplicas: 10 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 70 

צינור CI/CD

אנו משתמשים ב-GitLab CI/CD: בניית תמונת Docker, דחיפה ל-registry, עדכון מתגלגל דרך kubectl. אפס זמן השבתה — פודים מוחלפים אחד אחד.

ציר זמן

סה"כ: 2-3 שבועות עבור סביבת פרודקשן. עבור dev/staging — מהר יותר.

מה כלול בעבודה

• ביקורת תצורת Bitrix הנוכחית והתשתית.
• פיתוח Dockerfile ו-Docker Compose לפיתוח מקומי.
• כתיבת Kubernetes manifests (Deployment, Service, Ingress, PVC, Secret).
• הגדרת Redis ו-Memcached עבור סשנים וקאש.
• אינטגרציה של CI/CD (GitLab/GitHub Actions) עם עדכון מתגלגל.
• בדיקות עומס ואופטימיזציה (עד 1000 RPS).
• תיעוד פריסה ותפעול.
• הדרכה לצוות שלך (1-2 מפגשים).

הניסיון שלנו

אנו עוסקים בתשתית Bitrix כבר למעלה מ-7 שנים. פרסנו יותר מ-15 פרויקטים ב-Kubernetes, כולל קטלוגים עם מיליוני מוצרים ותנועה גבוהה. אנו משתמשים רק בטכנולוגיות יציבות ובשיטות עבודה מומלצות. לקוח אחד — חנות מקוונת עם 2 מיליון מוצרים ו-50,000 מבקרים ייחודיים ביום. לאחר ההעברה, זמן ההשבתה ירד לאפס, ומהירות טעינת העמוד עלתה ב-40%.

הזמינו ביקורת על התשתית שלכם — נעריך מוכנות לקונטיינריזציה ונציע תוכנית אופטימלית. צרו קשר לייעוץ.