उचित वेबसाइट कैसे बनाएं?

Question

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

1. वेबसाइट कोड भंडार में वास्तव में है (पाद लेख में है कि छोटी SVN संशोधन बनाता है मेरी nerdy भावनाओं झुनझुनी);
2. स्टेटिक फ़ाइलें (सीएसएस, जावास्क्रिप्ट, छवियां) एक अलग डोमेन पर संग्रहीत हैं;

ठीक है, ये मेरे अवलोकन थे। अब मेरे प्रश्नों के लिए:

1. जावास्क्रिप्ट और सीएसएस फ़ाइलों के साथ आप क्या करते हैं? क्या आप उन्हें संस्करण नियंत्रण में नहीं रखते हैं? वह बेवकूफ प्रतीत होता है। क्या आप उनके लिए एक अलग भंडार बनाते हैं?
2. आप भंडार कैसे सेट अप करते हैं? क्या आप सिर्फ वेब सर्वर की जड़ में एक बनाते हैं? या आप कुछ प्रकार के पोस्ट-ट्रिगर ट्रिगर बनाते हैं जो नवीनतम फाइलों को उनके उचित स्थलों पर प्रतिलिपि बनाता है?
3. क्या होता है यदि आपके पास वेबसाइट चलाने वाली कई मशीनें हैं और उन सभी में कुछ बदलाव करना चाहते हैं?
4. इस तरह की प्रत्येक परियोजना में कॉन्फ़िगरेशन फ़ाइलें होनी चाहिए। ये स्थानीय भंडार से रिमोट में भिन्न होते हैं। उदाहरण के लिए, मेरे विकास मशीन पर मेरे पास कोई MySQL रूट पासवर्ड नहीं है, जबकि उत्पादन सर्वर पर मेरे पास निश्चित रूप से एक पासवर्ड है। यह पासवर्ड कॉन्फ़िगरेशन फ़ाइल में अन्य ऐसी चीजों के साथ संग्रहीत किया जाएगा, जो मेरी मशीन और सर्वर पर पूरी तरह अलग होगा। हो सकता है कि वे उत्पादन मशीनों के बीच भी अलग हों (जैसा कि मैंने पहले कहा था, शायद वेबसाइट लोड संतुलन के लिए कई मशीनों पर चलती है)। मैं इसे कैसे संभाल सकता हूं?

मैं का उपयोग कर एक नया वेब परियोजना शुरू करने के लिए देख रहा हूँ: + modwsgi

MySQL

मर्क्युरियल

• अजगर + SQLAlchemy + WERKZEUG + Jinja2
• अपाचे httpd

  उपरोक्त उपकरण और उत्तर का उपयोग करने पर मुझे कुछ बेहतरीन अभ्यास सलाह चाहिए ऊपर मेरे प्रश्नों के लिए है।

Answer 1

आप सही हैं, स्केलेबल वेबसाइट को तैनात करने की कोशिश करते समय चीजें जटिल हो सकती हैं। (: मैं एक रेल इंजीनियर हूं अस्वीकरण): यहाँ क्या मैं कुछ अच्छा दिशा निर्देशों होने के लिए प्राप्त होते हैं

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

2. मैं संस्करण में सबकुछ नियंत्रित करता हूं जो आकार में बहुत महत्वपूर्ण नहीं है। वीसी के साथ मिली एकमात्र समस्या यह है कि जब आपका रेपो बड़ा हो जाता है। इसके अलावा मैंने पिछले कोड के संस्करण को रखने से कभी खेद नहीं किया है।

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

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

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

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

उम्मीद है कि मदद करता है!

Answer 2

जबकि मेरे पास आपके द्वारा उल्लेखित टूल के साथ काम करने का थोड़ा सा अनुभव है, MySQL को छोड़कर, मैं आपको आपके द्वारा पोस्ट किए गए प्रश्नों के लिए कुछ मानक जवाब दे सकता हूं।

1) विवरण पर निर्भर करता है, लेकिन अक्सर आप उन्हें एक ही भंडार में रखते हैं लेकिन एक अलग फ़ोल्डर में रखते हैं।

2) सिर्फ इसलिए कि भंडार में कुछ किया जाता है इसका मतलब यह नहीं है कि यह लाइव जाने के लिए तैयार है - यह अक्सर एक मध्यस्थ निर्माण होता है जिसे बग के साथ जोड़ा जा सकता है। भंडार से निर्यात के साथ, एक प्रकाशन मैन्युअल रूप से किया जाता है। एक एसवीएन चेकआउट के रूप में एक ही फ़ोल्डर में वेबसर्वर सेट करना एक बहुत ही गैर है क्योंकि .svn फ़ोल्डर में संवेदनशील जानकारी की थोड़ी सी जानकारी होती है, जैसे कि svn सर्वर में परिवर्तन कैसे धक्का देना है।

3) आप किसी प्रकार के NAS या SAN समाधान का उपयोग करते हैं, या बस सर्वरों में से किसी एक नेटवर्क शेयर का उपयोग करते हैं, और वहां से अपना सभी डेटा पढ़ते हैं। इस तरह, जब आप एक ही स्थान पर जानकारी दबाते हैं, तो यह सभी सर्वरों द्वारा सुलभ होता है। यदि आपका नेटवर्क धीमा है, तो आप स्क्रिप्ट सेट अप करते हैं जो फ़ाइलों को स्वचालित रूप से एक ही स्थान से सभी सर्वरों पर धक्का देता है। यदि आप ASP.NET में बहु-सर्वर वातावरण का उपयोग करते हैं, तो कॉन्फ़िगरेशन फ़ाइलों में मशीन कुंजी को अपडेट करना न भूलें या आपके साझा एन्क्रिप्टेड कैश, जैसे व्यूस्टेट, सर्वर पर काम नहीं करेंगे। डेटाबेस में सत्र स्टोर रखना भी एक अच्छा विचार है।

4) मेरे पास एक पोस्ट बिल्ड चरण है जो केवल प्रकाशन पर ट्रिगर करता है जो मेरे डेटाबेस कनेक्शनस्ट्रिंग को उत्पादन वाले लोगों के साथ बदल देता है, और प्रकाशित वेब.config/app.config में मेरे उत्पादन ऐप कॉन्फ़िगरेशन मान को झूठी से सच में बदल देता है फ़ाइलें। मैं किसी भी मामले को नहीं देख सकता जहां आप एक ही सामग्री की सेवा करने वाले विभिन्न सर्वरों के लिए अलग-अलग कॉन्फ़िगरेशन फाइल चाहते हैं।

अगर कुछ अस्पष्ट है, तो बस टिप्पणी करें और मैं स्पष्टीकरण देने की कोशिश करूंगा।

शुभकामनाएं! // एरिक जोहानसन

Answer 3

मुझे लगता है कि आप 2 अलग-अलग पहलुओं, स्रोत नियंत्रण और तैनाती को मिश्रित कर रहे हैं। सिर्फ इसलिए कि आपके पास एक ही भंडार में आपकी सभी फाइलें हैं, इसका मतलब यह नहीं है कि उन्हें इस तरह से तैनात किया जाना है। यह भी तर्कसंगत है कि क्या आपको सीधे स्रोत नियंत्रण का उपयोग करके तैनात किया जाना चाहिए या इसके बजाय बिल्ड/तैनाती स्क्रिप्ट का उपयोग करना चाहिए जो किसी भी कॉन्फ़िगरेशन को संभाल सकता है।

एक अलग डोमेन पर स्थिर फ़ाइलों को होस्ट करना केवल उच्च ट्रैफ़िक वेबसाइटों पर वास्तव में उपयोगी हो जाता है। क्या आप वाकई समय से अनुकूलन नहीं कर रहे हैं?