यह मानते हुए कि आपके एप्लिकेशन को एप्लिकेशन डेटा तक पहुंच लिखने की आवश्यकता नहीं है (जो वास्तव में ऐसा नहीं होना चाहिए), हम निम्नलिखित करते हैं:
हम उपयोगकर्ताओं को दो वर्गों में तोड़ते हैं - node-<app>-runtimeऔर node-<app>-data। <app>आवेदन नाम है। वे दोनों एक समूह का हिस्सा हैं node-<app>। वे वास्तविक नाम नहीं हैं जिनका उपयोग हम वहाँ के लोगों के लिए करते हैं।
हम निम्नलिखित करते हैं:
1) एप्लिकेशन के निर्माण के लिए, हम हमेशा एक अलग मशीन पर निर्माण करते हैं, और फिर एक npm distस्क्रिप्ट होती है जो एप्लिकेशन को एक निर्देशिका में चलाने के लिए आवश्यक फ़ाइलों को /distरखती है और इस निर्देशिका की एक तारांकित कॉपी हमारे तैनात सर्वर को भेजती है। इसका फायदा दुगुना है - हम जानते हैं कि वास्तव में क्या चल रहा है और हम यह सुनिश्चित कर सकते हैं कि उत्पादन मशीनों में कोई भी देव-डिप node_modules, .gitडायरेक्टरी और अन्य डेटा नहीं मिला है। इसका अर्थ यह भी है कि जब GitHub / Npm / etc नीचे जाता है, यह आटोस्क्कालिंग आदि को नहीं तोड़ता है - हमारे तैनात सर्वर सिर्फ प्रीबिल्ट टारबॉल बचाता है।
2) हम एक मानक स्थान में एक लॉग डायरेक्टरी बनाने के लिए हमारे कॉन्फ़िगरेशन प्रबंधन प्रणाली का उपयोग करते हैं जिसे node-<app>-runtimeअनुमतियों के साथ 640 से लिखा जा सकता है । एक मानक पर्यावरण चर द्वारा आवेदन के लिए पथ प्रदान किया जाता है। हमारे लॉग प्रोसेसिंग डेमॉन स्वचालित रूप से इन को उठाते हैं और उन्हें एक दूरस्थ सर्वर पर भेजते हैं।
3) हमारी तैनाती प्रणाली एक विशिष्ट स्थान पर एप्लिकेशन फ़ाइलों को रखती है और उन्हें node-<app>-dataअनुमतियों के साथ 640 के स्वामित्व में सेट करती है । पथ को मानक पर्यावरण चर द्वारा आवेदन के लिए प्रदान किया जाता है।
मेरे पास केवल एक और सलाह है कि आप हमेशा यह सुनिश्चित करें कि आप सेटिंग कर रहे हैं NODE_ENV=production। कई नोड मॉड्यूल डिबगिंग प्रतीकों को बंद करने, या प्रदर्शन में सुधार ( expressमन में आता है) के लिए इस सम्मेलन का उपयोग करते हैं ।