मैं उसी सर्वर पर एक ही कोड बेस के साथ PHP में एकाधिक वेबसाइट कैसे चला सकता हूं?

Question

मैंने इस पर कई ग्राहकों के साथ एक कस्टम, विशेष सीएमएस बनाया है, प्रत्येक के अपने डोमेन नाम, वेबसाइट, व्यवस्थापक क्षेत्र और डेटाबेस के साथ, लेकिन सभी एक ही सर्वर पर रहते हैं।

जब भी मुझे कोई नया क्लाइंट मिलता है, तो मैं बस सभी कोड कॉपी करता हूं, कॉन्फ़िगरेशन फ़ाइल में 3 लाइनों को बदलता हूं, और फिर उनकी सभी शैलियों/डेटा डेटाबेस से या अपलोड किए गए अपलोड से सर्वर से बाहर ले जाया जाता है अपने स्वयं के व्यवस्थापक क्षेत्र से।

अभी तक बहुत अच्छा लगता है?

खैर जब मैं हाल ही में ग्राहकों को सभी साइटों के अद्यतन करने के लिए फैसला किया है, यह एक बड़ी दर्द बन गया। जाहिर है मुझे प्रत्येक इंस्टॉलेशन पर कोड बदलना पड़ा। एक बड़े अपडेट के लिए यह ठीक है, लेकिन लगातार बदलाव या पसंद के लिए, अपलोड करने के प्रयास को डुप्लिकेट करना बहुत परेशान हो जाता है .... मुझे उम्मीद है कि किसी दिन दर्जन या सैकड़ों ग्राहक होंगे, इसलिए कोड को अंततः केंद्रीकृत किया जाना चाहिए ताकि इसे एक स्थान पर बदलकर इसे हर जगह अपडेट किया जाता है ... कोई ऐसा कैसे करता है?

Answer 1

एक आसान उपाय स्रोत कोड एक उपनिर्देशिका में, फ़ाइलें, जो प्रत्येक ग्राहक के लिए बदल दिया जाना चाहिए को छोड़कर (उदाहरण के लिए, कॉन्फ़िग फ़ाइल) डाल करने के लिए किया जाएगा।

फिर आप इस स्रोत कोड निर्देशिका कहीं बाहर रख सकते हैं और बस यह करने के लिए सिमलिंक पैदा करते हैं।

उदाहरण के लिए, अपने निर्देशिका संरचना दिखाई देंगे:

/var/www/src/index.php 
/var/www/src/more_source.php 
/var/www/clients/client_a/settings.php 
/var/www/clients/client_a/src -> ../../src/ 
/var/www/clients/client_b/settings.php 
/var/www/clients/client_b/src -> ../../src/ 

आप इस संरचना चुनते हैं, तो केवल एक चीज आप को बदलने की जरूरत होगी, settings.php (जैसे require "settings.php" से require "../settings.php" करने के लिए शामिल किया जाएगा)।

Answer 2

मैं library (आपका कामकाजी कोड) और config (प्रत्येक उपयोगकर्ता के लिए तीन पंक्तियां, शायद डेटाबेस कनेक्शन और इसी तरह) में विभाजित होगा।

library को सार्वभौमिक स्थान जैसे /home/library (* nix में) विभाजित करें और अन्य उपयोगकर्ता खातों को पढ़ने की विशेषता दें।

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

जैसे config: (साइट प्रति एक)

<?php 
require_once('/home/library/include.php'); 
//Line 1 config 
//Line 2 config 
//Line 3 config 
?> 

कोड के अपने पुस्तकालय भी सामग्री प्रस्तुत करने के लिए प्रयोग किया जाता है (index.php आदि) तो आप दो विकल्प हैं: (1) बनाने symlinks प्रत्येक साइट के वेब फ़ोल्डर्स और library स्रोत के बीच, या (2) अपने कोड को कोर कार्यक्षमता और प्रतिपादन कोड में अलग करें।

एक सिमलिंक ड्राइव पर दो अंक के बीच एक प्रणाली लिंक (यह एक सूचक की तरह है) पैदा करता है। एक ठीक से बनाए गए लिंक आप एक अलग नाम से एक फ़ोल्डर का उपयोग करने की है ताकि आप /home/user1/library, /home/user2/library/home/user3/library बना सकते हैं अनुमति देता है, और वे सभी बिंदु और /home/library वाली सामग्री होती है (वे डेटा की प्रतियां नहीं हैं)।

मुझे # 2 के साथ जाने के लिए शामिल किया जाएगा हालांकि यह आगे और अधिक काम करेगा।आपका library काम करता है, लेकिन साइट प्रतिपादन जो एक प्रति साइट अड्डों (सहित संभावना आगे उल्लिखित config), इस साइट के आधार द्वारा एक साइट पर अधिक लचीलापन देता है (भले ही पर आपूर्ति की है कोड के दूसरे टुकड़ा द्वारा किया जाता है आप खुद को अभी तक इसकी आवश्यकता नहीं है)। एक दुष्प्रभाव के रूप में आप एक बहु-स्तरीय आवेदन के रास्ते पर हैं।

Answer 3

व्यक्तिगत रूप से, मेरे पास डेटाबेस पर एक क्लाइंट टेबल है जो उस कोड का वर्तमान संस्करण संख्या रखती है जो वे चल रहे हैं। जब कोई उपयोगकर्ता लॉग इन करता है, तो वह उस क्लाइंट के लिए कोड संस्करण को इंगित करने वाले कोडवर्सन नामक एक कुकी सेट करता है (उदा। "V5-09-00")। Apache .htaccess में, मेरे पास है:

RewriteEngine on 

RewriteCond %{HTTP_COOKIE} CodeVersion=([^;]+) [NC] 
RewriteRule ^(.*)$ http://v%1.%{HTTP_HOST}/${escape:$1} [R=302,P,L] 

और स्थानीय मेजबान फ़ाइल के भीतर, मेरे पास है:

127.0.0.1 myservername  myservername.myserverdomain.com 

127.0.0.1 v5-08-00.myservername v5-08-00.myservername.myserverdomain.com 
127.0.0.1 v5-09-00.myservername v5-09-00.myservername.myserverdomain.com 
127.0.0.1 v5-10-00.myservername v5-10-00.myservername.myserverdomain.com 

जो vhosts

vhosts में एक प्रविष्टि के लिए अपाचे के भीतर स्थानीय पुनर्निर्देशन संभालती फ़ाइल कोड के प्रत्येक संस्करण के वातावरण सेट:

<VirtualHost *:80> 
    ServerAdmin mark.baker@myserverdomain.com 
    DocumentRoot /usr/local/apache/htdocs_5-09-00 
    ServerName v5-09-00.myservername.myserverdomain.com 
    ServerAlias v5-09-00.myservername 
    ErrorLog logs/myservername-error_log_5-09-00 
    CustomLog logs/myservername-access_log_5-09-00 common 
    php_value include_path ".:/php/includes:/usr/local/include/5-09-00/API:/usr/local/include/5-09-00/library:/usr/local/include/5-09-00/businesslogic:/usr/local/include/5-09-00/configuration:/usr/local/include/5-09-00/library/PHPExcel/Classes" 
</VirtualHost> 

<Directory "/usr/local/apache/htdocs_5-09-00"> 
    Options Indexes FollowSymLinks ExecCGI 
    AllowOverride All 
    Order allow,deny 
    Allow from all 
</Directory> 

प्रत्यक्ष के प्रत्येक सेट के भीतर ऑरिज, मेरे पास सामान्य कोड की ओर इशारा करते हुए प्रतीकात्मक लिंक हो सकते हैं, और क्लाइंट-विशिष्ट कोड या कॉन्फ़िगरेशन के लिए वास्तविक php/ini फ़ाइलें हो सकती हैं।

Answer 4

जैसा कि आप जानते मैंने पहले इस समस्या को मिला है यह बताने के लिए। यदि आप इस माध्यम से कॉन्फ़िगर करने का निर्णय लेते हैं तो कुछ प्रेत द्वारा पकड़ा जाना आसान है। Htaccess अनियमितताओं या अन्य ग्राहकों तक खुले शोषण।

मैं ग्राहकों के बीच सब कुछ अलग रखने की सलाह देता हूं।

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

आप अपडेट करने के लिए अपने मुख्य कोडबेस को एक अलग परीक्षण सर्वर पर चला सकते हैं और फिर बस अपने ग्राहक एफ़टीपी फाइलों और डेटाबेस एसक्यूएल को पैच कर सकते हैं।

लेकिन यह सरल और अलग रखें!

Answer 5

एक वैकल्पिक दृष्टिकोण स्टब्स उपयोग कर रहा है। बस एक साझा निर्देशिका में लाइब्रेरी की तरह साझा कोड को ले जाएं।

// file: index.php 
    include(".../shared/index.php"); 

आप को दोहराने के लिए कि प्रत्येक आवेदन प्रवेश बिंदु के लिए किया था जाएगा: तब प्रत्येक व्यक्ति साइट के लिए, खोखले .php स्क्रिप्ट जो सिर्फ साझा कोड शामिल पैदा करते हैं। तो आपके पास प्रत्येक साइट में लगभग खाली स्क्रिप्ट हैं, और साझा कोडबेस में सभी परिवर्तन स्वचालित रूप से सभी सेटअप पर लागू होते हैं। बस install.php स्थापनाओं के बीच भिन्न होने दें।

स्थैतिक फ़ाइलों (छवियों, सीएसएस, आदि) के लिए मैं एक सिम्लिंक दृष्टिकोण या एक रिवाइटरूल का भी उपयोग करता हूं।

Answer 6

सबसे पहले, आपको साइटों के बीच कोड साझा करने के नुकसान के सावधान रहने की जरूरत है। कई साइटों को एक बार में अपडेट करना आपके अपडेट के खतरे को एक समस्या का कारण बनता है - यदि साझा कोड में एक बग है, तो एक बार में एक से अधिक बार एक साइट पर खोजना बेहतर होता है!

एक तैनाती प्रबंधन समाधान सीधे कोड साझा करने की तुलना में बेहतर हो सकता है।(यदि आप ड्रूपल का उपयोग कर रहे हैं, उदाहरण के लिए, आप अपनी सभी साइट परिनियोजन और अपडेट प्रबंधित करने के लिए एगेर का उपयोग कर सकते हैं)

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

Answer 7

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

Answer 8

एक ही कोड का उपयोग करने वाले किसी चीज़ के बारे में, लेकिन प्रत्येक के पास mysql है।
पसंद है, http://mycms.com/myuser/ टेबल पर prefix myuser_ लाता है, इस प्रकार, 1 src संरचना, और एकाधिक साइट को अनुमति देता है। आपको .htaccess की आवश्यकता होगी हालांकि

Answer 9

यदि आप अपना कोड संस्करण नियंत्रण में रखते हैं, तो प्रत्येक ग्राहक वेबसाइट एक अलग चेकआउट हो सकती है। आप अपने परिवर्तनों में जांच कर सकते हैं, और रूट पर संस्करण नियंत्रण अद्यतन (या निर्यात का उपयोग कर) करके प्रत्येक क्लाइंट (या परीक्षण साइट) में उन्हें रोल कर सकते हैं। फिर आप पैच को सही तरीके से लागू करने के लिए एक समय में प्रत्येक क्लाइंट को अपडेट और परीक्षण कर सकते हैं।