कुशलता से एक ही युद्ध (विभिन्न संदर्भ, एक ही कंटेनर) के कई उदाहरणों को कुशलतापूर्वक तैनात करें

Question

मेरे पास एक WAR (app.war) और एक कंटेनर (टोमकैट, जेट्टी, ग्लासफ़िश, जो कुछ भी है)। मेरा लक्ष्य कंटेनर पर उसी वेब एप्लिकेशन के सैकड़ों उदाहरणों पर, मांग पर तैनात करना है। इस को प्राप्त करने का

http://foo/app1 --> app.war 
http://foo/app2 --> app.war 
http://foo/app3 --> app.war 
... 
http://foo/appN --> app.war 

कुछ स्पष्ट तरीके:

• बिलाव में, प्रत्येक एप्लिकेशन (appN.xml नाम) के लिए एक context.xml फ़ाइल बनाने, सभी एक ही युद्ध की ओर इशारा करते। अन्य कंटेनरों समान तरीकों इस दृष्टिकोण के साथ
  • समस्या है: यह युद्ध N बार विस्फोट हो जाएगा,
• उपयोग सांकेतिक लिंक डिस्क स्थान का एक बहुत ऊपर ले जा रहा webapp/{APP1, APP2, appN} फ़ोल्डर बनाने के लिए app.war के एक विस्फोटित संस्करण की ओर इशारा करते हुए। यह डिस्क स्पेस विस्फोट को रोकता है, लेकिन JVM अब भी कई डुप्लिकेट JARs को स्मृति
• कुछ साझा किए गए lib फ़ोल्डर का उपयोग करें जिसमें अधिकांश जार (और पिछले दो विकल्पों का संयोजन) शामिल है।

मुझे आश्चर्य है कि ऐसा करने के लिए एक बेहतर तरीका है या नहीं। आदर्श रूप से, एक नया उदाहरण बनाना किसी और डिस्क स्थान (सीमांत कॉन्फ़िगरेशन फ़ाइलों के अलावा) नहीं लेना चाहिए और केवल थ्रेड निष्पादन स्टैक और अन्य रनटाइम आवंटन से संबंधित मेमोरी लेना चाहिए।

कोई विचार?

Answer 1

जेटी ने जो कुछ भी आप ओवरले के नाम से ढूंढ रहे हैं उसके लिए समर्थन जोड़ा।

http://wiki.eclipse.org/Jetty/Tutorial/Configuring_the_Jetty_Overlay_Deployer

विकी पेज से थोड़ा को कॉपी करना:

• आप युद्ध फ़ाइल अपरिवर्तनीय रख सकते हैं, यहां तक ​​कि हस्ताक्षर किए, इतना है कि यह स्पष्ट है कि आप किस संस्करण तैनात किया है।
• वेब एप्लिकेशन को कस्टमाइज़/कॉन्फ़िगर करने के लिए आपके द्वारा किए गए सभी संशोधनों में अलग-अलग WARs हैं, और इस प्रकार नए संस्करणों की समीक्षा और माइग्रेशन के लिए आसानी से पहचान योग्य हैं।
• आप पैरामीटरयुक्त टेम्पलेट ओवरले बना सकते हैं जिसमें सामान्य अनुकूलन और कॉन्फ़िगरेशन शामिल है जो वेब अनुप्रयोग के कई उदाहरणों पर लागू होता है (उदाहरण के लिए, बहु-किरायेदार परिनियोजन के लिए)।
• क्योंकि स्तरित परिनियोजन स्पष्ट रूप से सामान्य और आवृत्ति विशिष्ट घटकों की पहचान करता है, जेटी टेम्पलेट के लिए क्लासलोडर और स्थिर संसाधन कैश साझा करने में सक्षम है, जो कई उदाहरणों की स्मृति पदचिह्न को बहुत कम करता है।

Answer 2

आप टोमकैट पर तैनात एक ही डब्ल्यूएआर नामित वर्चुअल होस्ट को इंगित करने के लिए अपाचे को फ्रंट एंड (mod_proxy/mod_proxy_ajp) पर कॉन्फ़िगर कर सकते हैं। आपके आवेदन को सभी अनुरोधों की सेवा के लिए डिज़ाइन/लिखे जाने चाहिए - प्रति वेबसाइट नाम विशिष्ट कॉन्फ़िगरेशन किसी डेटाबेस में या आपके एप्लिकेशन के भीतर कॉन्फ़िगरेशन फ़ाइल के रूप में संग्रहीत किया जा सकता है - आपके ऐप को केवल उपयोगकर्ता के अनुरोध डोमेन नाम की जांच करने की आवश्यकता होगी सुनिश्चित करें कि सही सेटिंग्स लागू की जाती हैं (प्रति सत्र एक बार)। आम तौर पर, आप इसे एक आवेदन के साथ हल करने में सक्षम होना चाहिए। महान डेवलपर्स LAZY हैं।

Answer 3

ठीक है अगर यह एक प्रयोग के लिए है तो आपके द्वारा सूचीबद्ध किसी भी तरीके से काम कर सकते हैं।

यदि यह उत्पादन के लिए है तो मैं इसके खिलाफ अनुशंसा करता हूं। जबकि मैंने सभी कंटेनरों का परीक्षण नहीं किया है, मैंने जिन कंटेनरों का उपयोग किया है, उनका मानना ​​है कि यह कंटेनरों के साथ हेडलेस वीएम को प्रावधान करने के लिए अधिक लचीला है। लिनक्स वीएम बहुत छोटे हो सकते हैं और वीएम तकनीक के साथ आप आवश्यकतानुसार कई उदाहरण जोड़ या घटा सकते हैं।

यदि आप वास्तव में गतिशील रूप से बढ़ते समाधान चाहते हैं तो आपको विफलता के एकल बिंदुओं को खत्म करने के लिए देखना चाहिए, फिर अपनी पूरी दुनिया को एक में लाने की कोशिश करें।

यदि आपको वास्तव में "दूसरे तक" लोड विस्तार/संकुचन की आवश्यकता है तो आपको एडब्ल्यूएस या क्लाउंडफाउंड्री को देखना चाहिए।

Answer 4

यदि आप जेटी का उपयोग कर रहे हैं, तो आप प्रोग्रामेटिक रूप से संदर्भ जोड़ सकते हैं।

WebAppContext webapp = new WebAppContext(); 
webapp.setBaseResource(myBaseDirectory); 
webapp.setContextPath(myContextPath); 

बस अपने सभी संदर्भों के लिए एक लूप में ऐसा करें। यह शून्य डिस्कस्पेस ओवरहेड के करीब होना चाहिए।

शायद टोमकैट में ऐसा करने का एक समान तरीका है।

Answer 5

थोड़ा सा विषय होने के लिए क्षमा चाहते हैं, लेकिन मेरे विचार में, आपका परिदृश्य "बहु-किरायेदारी" एप्लिकेशन को चिल्लाता है, ताकि आपके पास एक ही एप्लिकेशन हो जो कई "किरायेदारों" (ग्राहकों) की सेवा करेगा।

बहु किरायेदारी व्यवस्था के संबंध में

, निम्नलिखित बातों पर विचार किया जा करने के लिए होगा:

• ग्राहकों के लिए एक दूसरे डेटा (अगर वे डेटा एक ही डेटाबेस में संग्रहीत किया जाता है, एक ही स्कीमा और का उपयोग कर उपयोग नहीं कर सकते " भेदभावकर्ता "डेटा को अलग करने के लिए फ़ील्ड)। यह Access Control Lists
• के साथ स्प्रिंग सिक्योरिटी का उपयोग करके हासिल किया जा सकता है हाइबरनेट ने संस्करण 4.0 से support for multitenancy apps बनाया है।
• इन दो अतः सवालों के साथ-साथ उपयोगी हो सकता है
  • Multiple Entity Manager issue in Spring when using more than one datasource (प्रति ग्राहक एक ही डाटाबेस) पर विभिन्न डेटा स्रोतों (विभिन्न डेटाबेस या सिर्फ अलग स्कीमा प्रयोग करने के लिए।
  • Multi tenancy support in Java EE 6

बहुतायत के लाभ:

• साझा कोड का अर्थ है कि एक ग्राहक के लिए तय एक बग सभी के लिए तय किया गया है (यह एक नुकसान भी हो सकता है यदि विभिन्न ग्राहकों के पास बग का गठन करने और फीचर का गठन करने पर अलग-अलग विचार हैं)।
• क्लस्टर्ड परिनियोजन ग्राहकों के बीच लोड साझा कर सकता है (हालांकि, यह सुनिश्चित करने की आवश्यकता है कि शीर्ष ग्राहक सभी ग्राहकों के लिए उपलब्ध है)।

Downsides:

• कोड के रूप में प्रश्नों सुनिश्चित करना है कि ग्राहकों के बीच "भेदभाव" accidentially एक दूसरे के डेटा के लिए ग्राहकों को उजागर बिना काम करता है की जरूरत है थोड़ा और अधिक जटिल होने जा रहा है।