הגדרת PM2 לסביבת ייצור של Node.js: קלאסטר, אפס זמן השבתה, הפעלה אוטומטית

ניהול תהליכי Node.js עם PM2: הגדרה מוכנה לייצור

תהליך ה-Node.js שלך קרס באמצע הלילה, וגילית על כך רק מהלקוחות — סיפור מוכר? ללא מנהל תהליכים, הייצור הופך להימור. בשרת ייצור המריץ Node.js, היעדר PM2 הופך כל קריסה לאירוע חירום. תחת עומס של 10k RPS, היעדר מנהל תהליכים מבטיח השבתה. אנו מגדירים את PM2 מאפס ועד מוכנות לייצור: קלאסטרינג, טעינה מחדש ללא השבתה, הפעלה אוטומטית, ניטור ו-logrotate. התוצאה: פעילות יציבה 24/7 עם זמינות של 99.95% ומאמץ תפעולי מינימלי. הצוות שלנו ביצע למעלה מ-50 התקנות PM2 מוצלחות לפרויקטים המטפלים בין 1000 ל-100k RPS. חיסכון בעלויות תשתית מגיע ל-30% באמצעות ניצול משאבים יעיל. עלות הגדרת יישום בודד נקבעת לאחר ניתוח — צור קשר לבדיקת תשתית.

בעיות שאנו פותרים

• קריסות תהליך אקראיות — PM2 מפעיל מחדש עובד שנכשל תוך שניות. סטטיסטיקות מראות שזמינות עם שחזור אוטומטי מגיעה ל-99.95%.
• צורך בעדכונים ללא השבתה — טעינה מחדש ללא השבתה מאפשרת עדכוני קוד ללא הפרעה בשירות, וחוסכת עד 40% מזמן הפריסה (לפי תיעוד PM2).
• חוסר ניטור — מדדי CPU/RAM מובנים והתראות כאשר חריגים מהמגבלות. אנו משתלבים עם Prometheus לניטור מרכזי.
• הפעלה אוטומטית שנשכחה — לאחר אתחול שרת, תהליכים לא מתחילים, ומאלצים התערבות ידנית. הגדרת יחידת systemd הופכת זאת לאוטומטי.

כיצד אנו מגדירים PM2: מקרה אמיתי

קחו פרויקט של לקוח: שרת API מסוג Express ועובד רקע לעיבוד משימות. אנו משתמשים ב-ecosystem.config.js — הגישה המוכנה לייצור.

// ecosystem.config.js
module.exports = {
  apps: [
    {
      name: 'api-server',
      script: './src/server.js',
      instances: 'max',
      exec_mode: 'cluster',
      watch: false,
      max_memory_restart: '512M',
      env: {
        NODE_ENV: 'development',
        PORT: 3000,
      },
      env_production: {
        NODE_ENV: 'production',
        PORT: 3000,
      },
      log_date_format: 'YYYY-MM-DD HH:mm:ss Z',
      error_file: '/var/log/pm2/api-error.log',
      out_file: '/var/log/pm2/api-out.log',
      merge_logs: true,
    },
    {
      name: 'worker',
      script: './src/worker.js',
      instances: 2,
      exec_mode: 'fork',
      cron_restart: '0 3 * * *',
      max_memory_restart: '256M',
    }
  ]
};

התחילו עם: // ecosystem.config.js module.exports = { apps: [ { name: 'api-server', script: './src/server.js', instances: 'max', exec_mode: 'cluster', watch: false, max_memory_restart: '512M', env: { NODE_ENV: 'development', PORT: 3000, }, env_production: { NODE_ENV: 'production', PORT: 3000, }, log_date_format: 'YYYY-MM-DD HH:mm:ss Z', error_file: '/var/log/pm2/api-error.log', out_file: '/var/log/pm2/api-out.log', merge_logs: true, }, { name: 'worker', script: './src/worker.js', instances: 2, exec_mode: 'fork', cron_restart: '0 3 * * *', max_memory_restart: '256M', } ] }; .

pm2 start ecosystem.config.js --env production יוצר עובד אחד לכל ליבת CPU. במצב קלאסטר, PM2 פועל כמאזן עומסים — הוא מחלק בקשות נכנסות בין העובדים. חשוב: היישום חייב להיות חסר מצב. אם אתם משתמשים בסשנים, אחסנו אותם ב-Redis או במסד נתונים.

instances: 'max' משמש כמגבלה הגיונית: התהליך מופעל מחדש כאשר RSS חורג מהסף. זה לא תרופה לדליפות זיכרון, אבל זה קונה זמן למציאת שורש הבעיה ללא OOM killer. הלקוח הפחית את עלויות תשתית השרת ב-30% באמצעות ניצול משאבים יעיל.

טעינה מחדש ללא השבתה

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

// После успешного старта HTTP-сервера process.send('ready'); 

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

הפעלה אוטומטית לאחר אתחול

pm2 start ecosystem.config.js --env production pm2 save pm2 startup # выполнить сгенерированную команду с sudo 

PM2 יוצר יחידת systemd שמפעילה את כל התהליכים השמורים בעת אתחול המערכת. נבדק על Ubuntu, CentOS ו-Debian.

השוואה: Fork לעומת Cluster

השוואה: systemd לעומת PM2 להפעלה אוטומטית

PM2 עם systemd מהיר פי 3 בזמן פריסה.

התהליך שלנו

אנו ניגשים להגדרה בשלבים:

1. ניתוח — סקירת ארכיטקטורת היישום, העומס והדרישות.
2. עיצוב — קביעת מספר עובדים, מגבלות זיכרון, הגדרות לוג.
3. יישום — יצירת ecosystem.config.js, הגדרת הפעלה אוטומטית ו-logrotate.
4. בדיקות — אימות טעינה מחדש ללא השבתה, failover וניטור.
5. פריסה — פריסה לסטייג'ינג, ולאחר מכן לייצור.

לוחות זמנים ועלות

הגדרת PM2 ליישום אחד אורכת בין 2 ל-5 ימים תלוי במורכבות. העלות המדויקת מחושבת לאחר בדיקת התשתית שלך. צור קשר להערכת פרויקט.

מה כלול

• פריסת PM2 עם ecosystem.config.js
• מצב קלאסטר עם מספר עובדים אופטימלי
• טעינה מחדש ללא השבתה עם אות מוכנות
• הפעלה אוטומטית דרך systemd
• הגדרת logrotate לסיבוב לוגים
• ניטור בסיסי (pm2 monit, מדדי Prometheus)
• תיעוד תפעולי
• שעתיים של תמיכה טכנית לאחר המסירה

למה להשתמש במצב קלאסטר?

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

כיצד להגדיר logrotate עבור PM2?

ללא סיבוב, הלוגים ממלאים את הדיסק תוך שבוע. הוסיפו קובץ pm2 reload api-server:

/var/log/pm2/*.log { daily rotate 7 compress delaycompress missingok notifempty copytruncate } 

זה חוסך עד 80% משטח הדיסק.