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

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

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

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

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

स्रोत

2010-09-27 Phil

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

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

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

/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" करने के लिए शामिल किया जाएगा)।

स्रोत

2010-09-27 16:16:42 ChrisM

यह एक आशाजनक और सरल समाधान की तरह लगता है ... यदि केवल मुझे पता था कि सिम्लिंक क्या थे :) स्पष्टीकरण के लिए ... मैं इसका शोध करूंगा। मैं एक प्रशिक्षित प्रोग्रामर नहीं हूं और केवल वेब languanges पता है: PHP, जेएस, mysql, एचटीएमएल, फ़्लैश। बिल्कुल sysadmin सामान नहीं। – Phil

एक सिम्लिंक एक प्रतीकात्मक लिंक है (http://en.wikipedia.org/wiki/Symbolic_link), जो सिर्फ सर्वर को बताता है कि उसे कहीं और जानकारी की तलाश करनी चाहिए। यदि आप सर्वर पर लिनक्स/यूनिक्स का उपयोग कर रहे हैं, तो आप symlink को ln -s [स्रोत] [target] के साथ सेट कर सकते हैं। – ChrisM

मैं 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), इस साइट के आधार द्वारा एक साइट पर अधिक लचीलापन देता है (भले ही पर आपूर्ति की है कोड के दूसरे टुकड़ा द्वारा किया जाता है आप खुद को अभी तक इसकी आवश्यकता नहीं है)। एक दुष्प्रभाव के रूप में आप एक बहु-स्तरीय आवेदन के रास्ते पर हैं।

स्रोत

2010-09-27 16:17:32 Rudu

व्यक्तिगत रूप से, मेरे पास डेटाबेस पर एक क्लाइंट टेबल है जो उस कोड का वर्तमान संस्करण संख्या रखती है जो वे चल रहे हैं। जब कोई उपयोगकर्ता लॉग इन करता है, तो वह उस क्लाइंट के लिए कोड संस्करण को इंगित करने वाले कोडवर्सन नामक एक कुकी सेट करता है (उदा। "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 [email protected] 
    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 फ़ाइलें हो सकती हैं।

स्रोत

2010-09-27 16:24:47

+1 मुझे यह कुंग-फु पसंद है, अच्छा विचार। – Rudu

क्या उपयोगकर्ता कुकी बनाता है अगर इससे समस्याएं पैदा होती हैं? मुझे लगता है कि यहां तक कि कुछ प्रकार की सुरक्षा समस्या है जब तक आप बेहद सावधान नहीं हैं – rmeador

कोड के भीतर अतिरिक्त चेक हैं, इसलिए एक पकी हुई कुकी उस कुकी को हटा देगी और उपयोगकर्ता को लॉग आउट कर देगी। –

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

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

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

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

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

स्रोत

2010-09-27 16:25:13 Geekster

दिलचस्प दृष्टिकोण ... क्या होगा अगर ग्राहकों के पास कोई एफ़टीपी या डेटाबेस एक्सेस न हो? वे पूरी तरह से अपने स्वयं के व्यवस्थापक क्षेत्र के माध्यम से सर्वर को अपनी निर्देशिका में एक्सेस करते हैं। – Phil

@ फिल - मैं सहमत हूं। मैंने सेक्सी कॉन्फ़िगरेशन फ़ाइलों के पथ को भी भटक दिया है और जब बिंदु आता है कि एक ग्राहक कुछ ऐसा चाहता है जिसके लिए केवल कुछ सेटिंग्स की आवश्यकता होती है (और यह आ जाएगा) यह बहुत गन्दा हो सकता है। मुझे एहसास हुआ कि मैं वास्तव में यूनिट परीक्षणों में निर्मित कई साइटों पर अद्यतन कोडबेस को तैनात करने का एक तरीका था। यहां मेरा समान प्रश्न देखें http://stackoverflow.com/questions/3386529/deploy-to-multiple-instances – Macros

क्षमा करें, मतलब @ गीकेस्टर मैं सहमत हूं। एक केंद्रीय कोडेबेस को बनाए रखने की कोशिश करने से बहुत गन्दा हो सकता है – Macros

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

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

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

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

स्रोत

2010-09-27 16:28:57 mario

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

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

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

स्रोत

2010-09-27 16:34:49 Spudley

उस दृष्टिकोण के लिए धन्यवाद। मैं स्क्रैच से बने सादे पुराने PHP और MySQL का उपयोग कर रहा हूं। क्या आप इसके लिए एक तैनाती प्रबंधन समाधान का सुझाव दे सकते हैं? – Phil

आप एक संस्करण नियंत्रण और रोलआउट सिस्टम में माइग्रेट करना चाहते हैं। यह अर्ध स्वचालित अद्यतन संभव बनाता है। फिर भी यदि कुछ गलत हो जाता है, तो आप प्रति सिस्टम की जांच कर सकते हैं। – mario

@ मारियो के साथ सहमत - एक संस्करण नियंत्रण प्रणाली (एसवीएन, गिट, इत्यादि) चीजों को बहुत आसान बना देगा क्योंकि आप किसी भी समय किसी भी संस्करण को रिपॉजिटरी से ले जा सकते हैं, इसलिए कुछ बदलाव होने पर बदलाव को वापस करना आसान है गलत। मैं संस्करण नियंत्रण का उपयोग करने के लिए इतना उपयोग किया जाता है मैं इसे भी उल्लेख करने के लिए भूल गया; मैं इसे किसी भी सॉफ्टवेयर डेवलपर के लिए एक महत्वपूर्ण टूल मानता हूं, लेकिन विशेष रूप से एक जहां आपको कई इंस्टॉलेशन प्रबंधित करने की आवश्यकता होती है। – Spudley

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

स्रोत

2010-09-27 17:56:22 rmeador

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

स्रोत

2010-09-27 17:59:12 InsanityNet

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

स्रोत

2010-09-27 18:09:46 SorcyCat

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

उत्तर

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