HI
RU
EN
ES
ZH
FR
DE
PT
AR
Zero-downtime डिप्लॉय: आपकी JavaScript सेवा के लिए यह क्यों ज़रूरी है?
\n\nकल्पना करें: शुक्रवार की शाम, आप Node.js पर एक नई सुविधा डिप्लॉय कर रहे हैं — और एक मिनट बाद सपोर्ट चैट में घबराए हुए संदेश आने लगते हैं: "साइट डाउन है!", "500 एरर!", "डेटा गायब हो गया!"। परिचित लगता है? अगर आपकी JavaScript सेवा अपडेट के दौरान जवाब देना बंद कर देती है — तो आप न केवल उपयोगकर्ता खोते हैं, बल्कि पैसा और प्रतिष्ठा भी खोते हैं।
\n\nZero-downtime डिप्लॉय (बिना रुकावट के तैनाती) एक ऐसा तरीका है जिसमें कोड अपडेट उपयोगकर्ता को बिना पता चले होता है। सभी अनुरोध संसाधित होते हैं, कनेक्शन नहीं टूटते, और नया कोड आसानी से काम करना शुरू करता है। Node.js के लिए, जहां सब कुछ एसिंक्रोनसिटी और इवेंट्स पर निर्भर करता है, यह विशेष रूप से महत्वपूर्ण है: एक अचानक रुकावट मेमोरी लीक या अनहैंडल्ड प्रॉमिसेस का कारण बन सकती है।
\n\nइस लेख में, मैं दिखाऊंगा कि कैसे बिना रुकावट के JavaScript सेवाओं का डिप्लॉय व्यवहार में सेट करें। हम तीन काम करने वाली रणनीतियों — Rolling Update, Blue-Green Deployment और Graceful Shutdown — को वास्तविक कोड उदाहरणों के साथ समझेंगे। चलिए शुरू करते हैं!
\n\nरणनीति 1: Rolling Update — बिना रुकावट के अपडेट
\n\nRolling update (क्रमिक अपडेट) Node.js की दुनिया में सबसे लोकप्रिय तकनीक है। सार सरल है: आपके पास एप्लिकेशन के कई इंस्टेंस चल रहे हैं, और आप उन्हें एक-एक करके अपडेट करते हैं। जब एक रीस्टार्ट हो रहा होता है, बाकी ट्रैफिक लेते रहते हैं।
\n\nयह व्यवहार में कैसे काम करता है
\nमान लीजिए, आपके पास PM2 (एक लोकप्रिय प्रोसेस मैनेजर) के माध्यम से चल रहे 4 Node.js प्रोसेस हैं। कमांड pm2 reload app स्वचालित रूप से rolling restart करता है: एक-एक करके प्रोसेस को खत्म करता है और नया कोड शुरू करता है। लेकिन इसे बिना त्रुटियों के काम करने के लिए, आपको graceful shutdown (नीचे देखें) को सही ढंग से कॉन्फ़िगर करना होगा।
Zero-downtime के लिए PM2 सेटअप का उदाहरण
\nप्रोजेक्ट की रूट में ecosystem.config.js फ़ाइल बनाएं:
module.exports = {\n apps: [{\n name: 'my-javascript-service',\n script: './server.js',\n instances: 4, // 4 इंस्टेंस\n exec_mode: 'cluster', // क्लस्टर मोड\n wait_ready: true, // ready सिग्नल की प्रतीक्षा करें\n listen_timeout: 5000, // तैयार होने का टाइमआउट\n kill_timeout: 5000, // खत्म करने का टाइमआउट\n max_restarts: 10,\n env: {\n NODE_ENV: 'production'\n }\n }]\n};\nऔर सर्वर कोड (server.js) में सिग्नल हैंडलिंग जोड़ें:
const http = require('http');\nconst app = require('./app'); // आपका Express/Koa एप्लिकेशन\n\nconst server = http.createServer(app);\nconst PORT = process.env.PORT || 3000;\n\nserver.listen(PORT, () => {\n console.log(`सर्वर पोर्ट ${PORT} पर शुरू हुआ`);\n // PM2 को सिग्नल भेजें कि प्रोसेस तैयार है\n if (process.send) {\n process.send('ready');\n }\n});\n\n// Graceful shutdown\nprocess.on('SIGINT', () => {\n console.log('SIGINT प्राप्त हुआ, graceful shutdown शुरू...');\n server.close(() => {\n console.log('HTTP सर्वर बंद हुआ');\n process.exit(0);\n });\n});\n\nprocess.on('SIGTERM', () => {\n console.log('SIGTERM प्राप्त हुआ, काम खत्म कर रहे हैं...');\n server.close(() => {\n console.log('HTTP सर्वर बंद हुआ');\n process.exit(0);\n });\n});\nअब जब आप pm2 reload ecosystem.config.js चलाते हैं, तो PM2 बारी-बारी से इंस्टेंस को रोकेगा और शुरू करेगा, ready सिग्नल की प्रतीक्षा करेगा। उपयोगकर्ताओं को स्विचिंग का पता नहीं चलेगा।
Rolling Update के फायदे और नुकसान
\n- \n
- + अतिरिक्त सर्वर या प्रॉक्सी की आवश्यकता नहीं है। \n
- + PM2 या Kubernetes के माध्यम से आसानी से कॉन्फ़िगर किया जा सकता है। \n
- - अगर नए कोड में कोई गंभीर बग है, तो "खराब" इंस्टेंस कुछ अनुरोधों को संसाधित कर सकता है। \n
- - स्थिति (डेटाबेस, कैश) के सावधानीपूर्वक प्रबंधन की आवश्यकता है। \n
रणनीति 2: Blue-Green Deployment — बिना जोखिम के दो वातावरण
\n\n
ब्लॉग
पुस्तक अनुशंसाएँ
यह भी पढ़ें
