← ब्लॉग पर वापस जाएं

ब्लॉग

वर्डप्रेस के लिए डॉकर: अलग-अलग कंटेनर सब कुछ कैसे बदलते हैं

एक क्लाइंट दूसरे को क्रैश नहीं कर सकता। एक साइट दूसरे को संक्रमित नहीं कर सकती। यह PAGEnza के होस्टिंग प्लेटफ़ॉर्म के पीछे की वास्तुकला है।

पारंपरिक वर्डप्रेस होस्टिंग एक ही सर्वर पर कई साइटें रखती हैं। वे PHP साझा करते हैं, वे फ़ाइल सिस्टम एक्सेस साझा करते हैं, और अक्सर वे डेटाबेस सर्वर साझा करते हैं। यह तब ठीक है जब तक यह ठीक न हो - और जब यह ठीक न हो, तो यह एक गंभीर समस्या है।

PAGEnza हर वर्डप्रेस साइट को उसके अपने डॉकर कंटेनर में प्रावधान करता है। यह पोस्ट बताता है कि व्यवहार में इसका क्या मतलब है और यह उन एजेंसियों के लिए क्यों मायने रखता है जो कई क्लाइंट साइटों का प्रबंधन करती हैं।

साझा होस्टिंग समस्या

एक विशिष्ट साझा होस्टिंग योजना या कई वर्डप्रेस इंस्टॉलेशन वाले बुनियादी वीपीएस पर भी:

संसाधन विवाद: एक साइट पर ट्रैफ़िक स्पाइक सर्वर पर हर दूसरी साइट को धीमा कर देता है। साइट A पर एक खराब अनुकूलित प्लगइन साइट B पर प्रदर्शन को ख़राब करता है।

सुरक्षा रिसाव: यदि एक वर्डप्रेस इंस्टॉलेशन से समझौता किया जाता है - एक कमजोर प्लगइन, एक कमजोर पासवर्ड, या एक पुराने कोर संस्करण के माध्यम से - एक हमलावर जो फ़ाइल सिस्टम एक्सेस प्राप्त करता है, वह अक्सर उसी सर्वर पर अन्य साइटों की फ़ाइलों को पढ़ सकता है।

PHP संस्करण संघर्ष: साइट A को एक पुराने प्लगइन के लिए PHP 7.4 की आवश्यकता है। साइट B को एक नए के लिए PHP 8.2 की आवश्यकता है। साझा होस्टिंग पर, आप एक चुनते हैं।

डेटाबेस एक्सपोज़र: साझा डेटाबेस सर्वर का मतलब है कि एक गलत कॉन्फ़िगर किया गया उपयोगकर्ता अनुमति अन्य साइटों के डेटा को उजागर कर सकती है।

डॉकर कंटेनर इन सभी को इंफ्रास्ट्रक्चर स्तर पर हल करते हैं।

कंटेनर वास्तव में क्या है

एक डॉकर कंटेनर एक हल्का, अलग प्रक्रिया है जिसमें उसका अपना:

  • फ़ाइल सिस्टम (कंटेनर अपनी सीमाओं के बाहर की फ़ाइलों को नहीं देख सकता)

  • नेटवर्क स्टैक (उसका अपना आईपी पता, उसके अपने पोर्ट)

  • प्रक्रिया स्थान (यह अन्य कंटेनरों की प्रक्रियाओं को नहीं देख सकता)

  • संसाधन सीमाएँ (सीपीयू और मेमोरी कैप)

यह अन्य कंटेनरों के साथ होस्ट कर्नेल साझा करता है, लेकिन कर्नेल से ऊपर सब कुछ अलग होता है। यह एक पूर्ण वर्चुअल मशीन नहीं है - यह सेकंड में शुरू होता है, मिनटों में नहीं, और संसाधनों का एक अंश उपयोग करता है।

वर्डप्रेस के लिए, एक एकल कंटेनर चलता है: Nginx, PHP-FPM, और वर्डप्रेस फ़ाइलें। डेटाबेस एक अलग कंटेनर में चलता है, जो केवल उस विशिष्ट वर्डप्रेस कंटेनर से जुड़ा होता है।

PAGEnza एक साइट को कैसे प्रावधान करता है

जब आप PAGEnza में एक नई क्लाइंट साइट बनाते हैं, तो 45 सेकंड से कम समय में क्या होता है:

  1. एक बेस वर्डप्रेस इमेज से एक नया डॉकर कंटेनर शुरू किया जाता है
  2. वर्डप्रेस को साझा MariaDB इंस्टेंस पर एक ताज़ा डेटाबेस के साथ कॉन्फ़िगर किया गया है (उस कंटेनर की क्रेडेंशियल्स तक सीमित)
  3. PAGEnza प्लगइन स्वचालित रूप से स्थापित और सक्रिय हो जाता है
  4. क्लाइंट के सबडोमेन के साथ एक Nginx वर्चुअल होस्ट कॉन्फ़िगर किया गया है
  5. Let's Encrypt के माध्यम से SSL जारी किया जाता है
  6. कंटेनर को सही रूटिंग नियमों के साथ रिवर्स प्रॉक्सी में पंजीकृत किया जाता है

क्लाइंट को clientname.pagenza.com जैसा एक URL मिलता है जो "साइट बनाएँ" पर क्लिक करने के 45 सेकंड के भीतर लाइव हो जाता है। कोई मैन्युअल सर्वर कॉन्फ़िगरेशन नहीं, कोई SSH नहीं, कोई DNS प्रतीक्षा अवधि नहीं (सबडोमेन के लिए - कस्टम डोमेन DNS प्रसार अलग है)।

व्यवहार में कंटेनर अलगाव

मेमोरी सीमाएँ: प्रत्येक कंटेनर में एक कॉन्फ़िगर करने योग्य मेमोरी कैप होती है। यदि एक अनियंत्रित प्लगइन एक क्लाइंट की साइट पर मेमोरी स्पाइक का कारण बनता है, तो यह अन्य कंटेनरों को आवंटित मेमोरी का उपभोग नहीं कर सकता है। साइट धीमी हो सकती है या 503 लौटा सकती है - लेकिन यह अन्य ग्राहकों को प्रभावित नहीं करेगी।

फ़ाइल सिस्टम अलगाव: क्लाइंट A की वर्डप्रेस फ़ाइलें क्लाइंट B के कंटेनर के लिए पूरी तरह से अदृश्य हैं। क्लाइंट A की साइट पर एक समझौता किया गया प्लगइन क्लाइंट B की फ़ाइलों तक पहुँचने का कोई रास्ता नहीं है।

नेटवर्क अलगाव: कंटेनर केवल परिभाषित नेटवर्क ब्रिज के माध्यम से संवाद करते हैं। क्लाइंट A के लिए डेटाबेस कंटेनर केवल क्लाइंट A के वर्डप्रेस कंटेनर से कनेक्शन स्वीकार करता है - सिस्टम पर किसी अन्य कंटेनर से नहीं।

प्रति कंटेनर PHP: क्योंकि प्रत्येक कंटेनर अपने स्वयं के PHP-FPM इंस्टेंस को चलाता है, आप विभिन्न ग्राहकों के लिए विभिन्न PHP संस्करण चला सकते हैं। क्लाइंट A का लेगेसी प्लगइन जिसे PHP 7.4 की आवश्यकता है, वह PHP 8.2 पर क्लाइंट B के आधुनिक स्टैक के साथ ठीक चलता है।

कस्टम डोमेन

डिफ़ॉल्ट सेटअप हर क्लाइंट को *.pagenza.com सबडोमेन देता है। उन ग्राहकों के लिए जो अपना डोमेन चाहते हैं, प्रक्रिया है:

  1. क्लाइंट अपने डोमेन के ए रिकॉर्ड को PAGEnza सर्वर आईपी पर इंगित करता है
  2. PAGEnza डैशबोर्ड में, आप कस्टम डोमेन दर्ज करते हैं
  3. रिवर्स प्रॉक्सी कॉन्फ़िगरेशन स्वचालित रूप से अपडेट हो जाता है
  4. Let's Encrypt के माध्यम से कस्टम डोमेन के लिए SSL जारी किया जाता है

वर्डप्रेस siteurl और home विकल्प से मेल खाने के लिए अपडेट किए जाते हैं। क्लाइंट के दृष्टिकोण से, उनकी साइट उनके डोमेन पर बस काम करती है - कोई रीडायरेक्ट नहीं, आगंतुकों को कोई सबडोमेन दिखाई नहीं देता।

एजेंसियों के लिए इसका क्या मतलब है

कई क्लाइंट साइट चलाने वाली एजेंसियों के लिए व्यावहारिक लाभ:

ऑनबोर्डिंग गति: एक नई क्लाइंट साइट का प्रावधान एक मिनट से भी कम समय लेता है। कोई सर्वर सेटअप नहीं, कोई cPanel नहीं, कोई मैन्युअल वर्डप्रेस इंस्टॉलेशन नहीं।

क्लाइंट अलगाव: प्रत्येक क्लाइंट की साइट वास्तव में अलग है। एक क्लाइंट जो एक समस्याग्रस्त प्लगइन स्थापित करता है, वह केवल अपनी साइट को प्रभावित करता है।

स्केलेबिलिटी: एक नया क्लाइंट जोड़ने के लिए एक नया सर्वर प्रावधान करने की आवश्यकता नहीं है। कंटेनर इंफ्रास्ट्रक्चर होस्ट की क्षमता के अनुसार स्केल करता है, और अधिक क्षमता जोड़ना अधिक होस्ट नोड्स जोड़ने का मामला है।

आपदा रिकवरी: क्योंकि प्रत्येक साइट कंटेनरीकृत है, बैकअप और पुनर्स्थापना कंटेनर स्तर पर संचालित होती है। एक एकल क्लाइंट की साइट को पुनर्स्थापित करने से किसी अन्य क्लाइंट को प्रभावित नहीं होता है।

इसका नकारात्मक पक्ष यह है कि कंटेनर होस्टिंग साझा होस्टिंग की तुलना में प्रति साइट अधिक महंगी है। लेकिन उन एजेंसियों के लिए जहां साइट विश्वसनीयता और क्लाइंट अलगाव गैर-परक्राम्य हैं, अर्थशास्त्र काम करता है - खासकर जब प्रावधान समय बचत को ध्यान में रखा जाता है।