פריסת עדכון מתגלגל ללא זמן השבתה

עדכון מתגלגל (Rolling Update) עם אפס זמן השבתה

בעת עדכון אפליקציית אינטרנט בסביבת ייצור, משתמשים לעיתים קרובות מאבדים גישה או מקבלים שגיאות 503. דמיינו: אתם משחררים גרסה חדשה, וחצי מהבקשות נכשלות עם פסק זמן—מסד הנתונים לא הצליח לעבור בזמן. הגישה הסטנדרטית של "עצור → החלף → הפעל" אינה עובדת עבור שירותים עם דרישות SLA של 99.9%. אנו מגדירים עדכון מתגלגל—אסטרטגיה שמבטלת זמן השבתה עם תקורה מינימלית של משאבים. הניסיון שלנו: 10+ שנים ב-DevOps, הטמעות של עדכון מתגלגל לפלטפורמות פינטק ומסחר אלקטרוני עם מיליוני משתמשים.

למה עדכון מתגלגל הוא הבחירה הטובה ביותר לפריסה עם אפס זמן השבתה

עדכון מתגלגל מחליף מופעים בהדרגה: תחילה מתעדכנים 1–2 פודים, תקינותם נבדקת, ואז הבאים. בניגוד ל-Blue-Green, הוא אינו דורש משאבים כפולים, ובניגוד ל-Recreate, הוא אינו עוצר את כל הפודים בבת אחת. זה מספק איזון בין עלות לסבילות לתקלות. עדכון מתגלגל מהיר פי 2 מ-Blue-Green בזמן פריסה, ועם תצורה נכונה, זמן ההשבתה מבוטל לחלוטין.

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

איך להגדיר עדכון מתגלגל ב-Kubernetes

---
# deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
spec:
  replicas: 6
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 2
      maxUnavailable: 1
  minReadySeconds: 30
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
        - name: myapp
          image: registry.example.com/myapp:v1.1.0
          readinessProbe:
            httpGet:
              path: /health/ready
              port: 8080
            initialDelaySeconds: 10
            periodSeconds: 5
            failureThreshold: 3
          livenessProbe:
            httpGet:
              path: /health/live
              port: 8080
            initialDelaySeconds: 30
            periodSeconds: 10
          terminationGracePeriodSeconds: 60

kubectl set image deployment/myapp myapp=registry.example.com/myapp:v1.2.0
kubectl rollout status deployment/myapp
kubectl rollout history deployment/myapp
kubectl rollout undo deployment/myapp
kubectl rollout undo deployment/myapp --to-revision=3

מה זה כיבוי הדרגתי (Graceful Shutdown) ולמה הוא נחוץ?

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

// Node.js/Express — корректное завершение при SIGTERM
process.on('SIGTERM', async () => {
  console.log('SIGTERM received, shutting down gracefully');
  server.close(() => {
    console.log('HTTP server closed');
  });
  await new Promise(resolve => setTimeout(resolve, 30_000));
  await db.destroy();
  process.exit(0);
});

איך לוודא מוכנות האפליקציה?

בדיקת המוכנות (readiness probe) צריכה לבדוק שירותים תלויים: מסד נתונים, מטמון, תור. דוגמה ב-Laravel:

// Laravel — health check routes
Route::get('/health/live', function () {
    return response()->json(['status' => 'ok']);
});

Route::get('/health/ready', function () {
    try {
        DB::connection()->getPdo();
        Cache::store()->get('health-check');
    } catch (\Exception $e) {
        return response()->json(['status' => 'not ready', 'error' => $e->getMessage()], 503);
    }
    return response()->json(['status' => 'ready']);
});

איך להבטיח תאימות מסד נתונים במהלך עדכון מתגלגל?

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

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

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

טעות נפוצה אחת היא הגדרת # deployment.yaml apiVersion: apps/v1 kind: Deployment metadata: name: myapp spec: replicas: 6 strategy: type: RollingUpdate rollingUpdate: maxSurge: 2 maxUnavailable: 1 minReadySeconds: 30 selector: matchLabels: { app: myapp } template: metadata: labels: { app: myapp } spec: containers: - name: myapp image: registry.example.com/myapp:v1.1.0 readinessProbe: httpGet: path: /health/ready port: 8080 initialDelaySeconds: 10 periodSeconds: 5 failureThreshold: 3 livenessProbe: httpGet: path: /health/live port: 8080 initialDelaySeconds: 30 periodSeconds: 10 terminationGracePeriodSeconds: 60 או kubectl set image deployment/myapp myapp=registry.example.com/myapp:v1.2.0 kubectl rollout status deployment/myapp kubectl rollout history deployment/myapp kubectl rollout undo deployment/myapp kubectl rollout undo deployment/myapp --to-revision=3 קטנים מדי, מה שמאריך את הפריסה. לדוגמה, אם // Node.js/Express — корректное завершение при SIGTERM process.on('SIGTERM', async () => { console.log('SIGTERM received, shutting down gracefully'); server.close(() => { console.log('HTTP server closed'); }); await new Promise(resolve => setTimeout(resolve, 30_000)); await db.destroy(); process.exit(0); }); ו-replicas=10, העדכון לוקח 10 סבבים. בחרו פרמטרים אלה בהתבסס על המספר הכולל של הרפליקות ומהירות הפריסה המקובלת. בעיה נוספת היא בדיקות מוכנות לא נכונות: הן חייבות לבדוק מוכנות אמיתית של האפליקציה, לא רק להחזיר 200. אם הבדיקה אינה כוללת בדיקת מסד נתונים, פוד חדש עלול להתחיל לקבל תעבורה לפני שמסד הנתונים אותחל, מה שגורם לשגיאות 500. כמו כן, לעיתים קרובות שוכחים את // Laravel — health check routes Route::get('/health/live', function () { return response()->json(['status' => 'ok']); }); Route::get('/health/ready', function () { try { DB::connection()->getPdo(); Cache::store()->get('health-check'); } catch (\Exception $e) { return response()->json(['status' => 'not ready', 'error' => $e->getMessage()], 503); } return response()->json(['status' => 'ready']); }); : אם האפליקציה לא יכולה לכבות לפני SIGKILL, בקשות פעילות אובדות. הגדירו אותו לפחות ל-30 שניות.

מה כלול בהגדרת עדכון מתגלגל?

• ניתוח התשתית הנוכחית וארכיטקטורת האפליקציה
• תצורה של Kubernetes Deployment או שירות Docker Swarm
• כתיבת בדיקות מוכנות ותקינות נכונות
• הטמעת כיבוי הדרגתי (SIGTERM, ניקוז בקשות)
• פיתוח אסטרטגיית מיגרציה תואמת לאחור
• בדיקות בסביבת staging עם עומס
• תיעוד הגדרות ונהלים
• הדרכת צוות על עבודה עם עדכון מתגלגל

תהליך

1. ניתוח: סקירת המחסנית הנוכחית, תשתית, תהליכי פריסה
2. עיצוב: בחירת פרמטרים של עדכון מתגלגל, בדיקות תקינות
3. הטמעה: הגדרת האורקסטרטור, כתיבת בדיקות, כיבוי הדרגתי
4. בדיקות: אימות בסביבת staging עם בדיקות עומס
5. פריסה: מעבר לייצור, ניטור 24 השעות הראשונות

ציר זמן

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

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