2010-04-14 13 views
9

मैं एक 'आदर्श' लैंप विकास ढेर बनाना चाहता हूं।आदर्श मल्टी-डेवलपर लैंप स्टैक?

  • दोहरी सर्वर (virtualised, ESX)
    • अपाचे/एक, डेटाबेस (MySQL, PgSQL, आदि) पर पीएचपी दूसरे पर।
  • उपयोगकर्ता (डेवलपर) प्रबंधित मिनी वातावरण, या उदाहरण।
    • प्रत्येक डेवलपर उदाहरण शीर्ष स्तर config (उपलब्ध मॉड्यूल और डिफ़ॉल्ट config आदि)
    • एक डेवलपर के शेयरों प्रत्येक परियोजना के लिए अपने अपाचे और php संस्करण पर नियंत्रण होना चाहिए।
    • एक डेवलपर छोटी सेटिंग्स को बदलने में सक्षम हो सकता है, यानी विरासत कोड के लिए जादूगर।
    • प्रत्येक परियोजना अपने कोड में अपने डेटाबेस प्रदाता निर्धारित करेंगे

विचार यह एक व्यवस्थापक करने योग्य सर्वर है कि मैं नियंत्रित कर सकते हैं, और एपीसी, Memcached, XDebug आदि की तरह दुनिया भर में कॉन्फ़िगर किया गया चीजें प्रदान करते है फिर प्रत्येक प्रोजेक्ट के लिए सबसेट में जाकर, मैं अपने उपयोगकर्ताओं को विभिन्न परियोजनाओं के लिए अपने वातावरण को त्वरित रूप से नियंत्रित करने की अनुमति दे सकता हूं।

अनिवार्य रूप से मैं अपने स्वयं के मशीन पर अपने स्वयं के ढेर को चलाने वाले डेवलपर की विशिष्ट प्रणाली का प्रस्ताव दे रहा हूं, लेकिन केंद्रीकृत। इस तरह से मैं क्रॉस ओएस कोड की समस्याओं, डेटाबेस असंगतताओं, बग आदि के उत्पादन में थोड़ा अलग स्थापित करने से बचने की उम्मीद करता हूं

मुझे स्रोत से कस्टम बिल्ड में इसका प्रबंधन करने में खुशी है, लेकिन यदि संभव हो तो यह होगा इसका एक बड़ा हिस्सा बहुत अच्छा पैकेज प्रबंधन के साथ प्रबंधित करने के लिए बहुत अच्छा हो। हम आम तौर पर CentOS का उपयोग करते हैं, तो यम?

क्या किसी ने कभी इस तरह कुछ बनाया है? क्या कोई टर्नकी है जो मैंने वर्णन की है? क्या इस तरह कुछ बनाने के लिए मुझे कोई उपयोगी गाइड पढ़ना चाहिए?

+0

सुपरसियर प्रश्न की तरह ध्वनि। –

+0

मेरे पास समाधान नहीं है लेकिन ऐसा लगता है कि आप इसे अधिकतर .htaccess फ़ाइलों के साथ करने में सक्षम होना चाहिए। Httpd.conf को प्रतिबंधित करने में सक्षम होना चाहिए जो ओवरड किया जा सकता है और फिर डेवलपर्स htaccess फ़ाइल में वातावरण का विस्तार कर सकते हैं। –

+0

ब्रेंट, आप इस उदाहरण में htaccess फ़ाइल पर भरोसा नहीं कर सकते हैं, क्योंकि प्रत्येक प्रोजेक्ट में चल रहे अनुप्रयोगों की अपनी खुद की htaccess फ़ाइलें होंगी, और – jhogendorn

उत्तर

0

मुद्दे पर मेरे ले, मुझे नहीं लगता कि यह आपके सभी आवश्यकताओं को शामिल किया गया है, लेकिन यह बहुत करीब है:

  • दीप ढेर के साथ एक CentOS सर्वर (वाह स्थापित apache2 mysql php आदि) है - या 2 सर्वर एक httpd और एक mysqld
  • एन डेवलपर्स के पास एन वर्चुअल होस्ट www.developer-n.com के साथ एन फ़ोल्डर्स हैं जो अपाचे सर्वर
  • चलाते हैं प्रत्येक डेवलपर इसका सर्वर फ़ोल्डर माउंट करता है (//192.168 कहें स्थानीय मशीन पर CIFS के माध्यम से स्थानीय मशीन पर /0/घर/डेवलपर-एन/www) स्थानीय स्टेशन/etc/fstab में स्थानीय फाइलों को संपादित करता है मशीन अभी तक (अद्वितीय) सर्वर
  • पर उन्हें चलाता है प्रत्येक डेवलपर मिनी पर्यावरण .htaccess के माध्यम से बदलाव किया गया है
+0

आप वर्तमान में कार्यान्वित किए गए कार्यों के बारे में बात कर रहे हैं, इसलिए वास्तव में उत्तर नहीं है :) प्लस मैंने ऊपर स्थापित किया है कि .htaccess के माध्यम से कॉन्फ़िगरेशन tweaking अनुचित है। – jhogendorn

+0

क्या "उन्हें उलझाना अनुचित होगा" मतलब क्या है? – clyfe

3

ठीक है, जिस तरह से हम अपने पिछले काम चल रहे थे विकास दीप सेटअप, इस तरह था। एक सर्वर जो MySQL और अपाचे दोनों चला रहा है।प्रत्येक डेवलपर को सर्वर पर एक आईपी पता सौंपा जाता है (मशीन एक ही इंटरफ़ेस पर एकाधिक आईपी चला रही है, सभी आईपी एक ही सबनेट पर हैं), इसलिए प्रत्येक डेवलपर में कम से कम एक आईपी-आधारित वर्चुअल होस्ट हो सकता है और जितने नाम हैं वे चाहते हैं (हमारी वेबसाइट एसएसएल का इस्तेमाल करती है, इसलिए हमें अलग-अलग आईपी की आवश्यकता होती है, एसएसएल wigthout, आप एक आईपी और नाम आधारित vhosts से दूर हो सकते हैं)। हमारे पास वाइल्डकार्ड की सेवा करने वाला स्थानीय DNS सर्वर था प्रत्येक डेवलपर के लिए एक रिकॉर्ड * .john.dev.company में एक 10.1.1.123, जहां 10.1.1.123 जॉन को सौंपा गया आईपी पता था। इस तरह जॉन जितना चाहें उतने नाम आधारित vhosts को परिभाषित कर सकता था और जब तक वे सभी john.dev.company (project1.john.dev.company) में समाप्त हुए, तब तक वे सभी ठीक से हल हो जाएंगे। प्रत्येक डेवलपर की अपनी अपाचे कॉन्फ़िगरेशन फ़ाइल में उनके वर्चुअल होस्ट्स के साथ था और हमने इन सभी फ़ाइलों को मुख्य अपाचे कॉन्फ़िगरेशन में खींचने के लिए निर्देश शामिल किया था। अनुमतियां सेट की गई थीं, इसलिए ये कॉन्फ़िगरेशन फ़ाइलें संबंधित डेवलपर्स द्वारा संपादन योग्य होंगी और प्रत्येक डेवलपर के पास उनकी होम निर्देशिका में उनकी कॉन्फ़िगरेशन का सॉफ्ट लिंक होगा। इसके अलावा, प्रत्येक डेवलपर को अपाचे को पुनरारंभ करने के लिए सुडो का उपयोग करने की अनुमति थी। इस सेटअप का नकारात्मक पक्ष यह था कि एक समय में एक विशेष देव अपनी कॉन्फ़िगरेशन फ़ाइल को खराब करके पूरे सर्वर को क्रैश कर देगा। हमने सामान्य डेटाबेस का उपयोग किया, क्योंकि हर कोई एक ही परियोजना पर काम कर रहा था, लेकिन कई अलग-अलग डेटाबेस सेट करना मुश्किल नहीं होना चाहिए।

संबंधित मुद्दे