मैं एक ईसी 2 उदाहरण में एस 3 बाल्टी कैसे माउंट कर सकता हूं और इसे PHP के साथ लिख सकता हूं?




amazon-s3 fuse (2)

मैं एक परियोजना पर काम कर रहा हूं जिसे अमेज़ॅन वेब सर्विसेज पर होस्ट किया जा रहा है। सर्वर सेटअप में दो ईसी 2 इंस्टेंस, एक लोचदार लोड बैलेंसर और एक अतिरिक्त लोचदार ब्लॉक स्टोर होता है जिस पर वेब एप्लिकेशन रहता है। प्रोजेक्ट को अपलोड करने वाली फ़ाइलों के संग्रहण के लिए S3 का उपयोग करना चाहिए । इस सवाल के लिए, मैं एस 3 बाल्टी static.example.com कॉल करूंगा

मैंने s3fs ( https://code.google.com/p/s3fs/wiki/FuseOverAmazon ), RioFS ( https://github.com/skoobe/riofs ) और s3ql ( https://code.google.com/p/s3ql/ ) का उपयोग करने का प्रयास किया है https://code.google.com/p/s3ql/ )। s3fs फाइल सिस्टम को आरोहित करेगा लेकिन मुझे बाल्टी को लिखने नहीं देगा (मैंने इस सवाल को SO पर पूछा: मैं FUSE का उपयोग करके उचित अनुमतियों के साथ S3 वॉल्यूम कैसे माउंट कर सकता हूं)। RioFS फाइल सिस्टम को माउंट करेगा और मुझे बाल्टी को खोल से लिखने देगा, लेकिन PHP का उपयोग करके सहेजी गई फाइलें बाल्टी में दिखाई नहीं देतीं (मैंने गिटहब पर प्रोजेक्ट के साथ एक मुद्दा खोला)। s3ql बाल्टी को s3ql , लेकिन फाइलों में पहले से ही बाल्टी में मौजूद फाइलों में से कोई भी फाइल सिस्टम में दिखाई नहीं दे रहा है।

ये माउंट कमांड हैं जिनका मैंने उपयोग किया था:

s3fs static.example.com -ouse_cache=/tmp,allow_other /mnt/static.example.com
riofs -o allow_other http://s3.amazonaws.com static.example.com /mnt/static.example.com
s3ql mount.s3ql s3://static.example.com /mnt/static.example.com

मैंने इस एस 3 कक्षा का उपयोग करने का भी प्रयास किया है: https://github.com/tpyo/amazon-s3-php-class/ और यह FuelPHP विशिष्ट S3 पैकेज: https://github.com/tomschlick/fuel-s3 । मैं उपलब्ध बाल्टी और फ़ाइलों को सूचीबद्ध करने के लिए FuelPHP पैकेज प्राप्त करने में सक्षम था, लेकिन बाल्टी में फ़ाइलों को सहेजना विफल रहा (लेकिन त्रुटि नहीं हुई)।

क्या आपने कभी स्थानीय लिनक्स फाइल सिस्टम पर एक एस 3 बाल्टी लगाई है और बाल्टी को फ़ाइल को सफलतापूर्वक लिखने के लिए PHP का उपयोग किया है? आपने किस टूल का उपयोग किया था? यदि आपने उपरोक्त उल्लिखित टूल में से एक का उपयोग किया है, तो आपने किस संस्करण का उपयोग किया था?

संपादित करें मुझे सूचित किया गया है कि RioFS पर RioFS साथ खोला गया मुद्दा हल हो गया है। हालांकि मैंने वॉल्यूम के रूप में बाल्टी को RioFS कोशिश करने के बजाय एस 3 आरईएसटी एपीआई का उपयोग करने का फैसला किया, ऐसा लगता है कि RioFS इन दिनों एक व्यवहार्य विकल्प हो सकता है।


क्या आपने कभी स्थानीय लिनक्स फाइल सिस्टम पर एक एस 3 बाल्टी लगाई है?

नहीं, यह परीक्षण के लिए मजेदार है, लेकिन मैं इसे एक उत्पादन प्रणाली के पास नहीं जाने दूंगा। S3 के साथ संवाद करने के लिए लाइब्रेरी का उपयोग करना बेहतर है। यहाँ पर क्यों:

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

निचली पंक्ति यह है कि एफयूएसई के तहत एस 3 एक रिसाव अमूर्त है । एस 3 में निर्देशिका (या आवश्यकता) नहीं है। फाइल सिस्टम को अरबों फाइलों के लिए नहीं बनाया गया था। उनके अनुमति मॉडल असंगत हैं। आप इसे फाइल सिस्टम में shoehorn करने की कोशिश करके एस 3 की बहुत सारी शक्ति बर्बाद कर रहे हैं।

S3 से बात करने के लिए दो यादृच्छिक PHP पुस्तकालय:

https://github.com/KnpLabs/Gaufrette

https://aws.amazon.com/sdkforphp/ - यह एक उपयोगी है यदि आप केवल एस 3 का उपयोग करने से आगे बढ़ते हैं, या यदि आपको ऊपर वर्णित फैंसी अनुरोधों में से कोई भी करने की आवश्यकता है।


अक्सर, ईबीएस वॉल्यूम में फाइलें लिखना फायदेमंद होता है, फिर क्लाउडफ्रंट सीडीएन के माध्यम से रूट करने के लिए फ़ाइल के लिए बाद के सार्वजनिक अनुरोधों को मजबूर करता है।

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

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

उपर्युक्त का एक प्राथमिक उदाहरण वर्डप्रेस होगा, जो मूल को रखने के अलावा अपलोड किए गए किसी भी ग्राफिक छवि के कई आकार / फसल संस्करण बनाता है (फ़ाइल आकार प्रतिबंधों, और / या प्लगइन परिवर्तनों के अधीन)। सीडीएन-सक्षम वर्डप्रेस प्लगइन्स जैसे कि डब्ल्यू 3 टोटल कैश सीडीएन के माध्यम से खींचने के अनुरोधों को फिर से लिखने के लिए अनुरोध करता है, इसलिए ऐप को केवल अद्वितीय प्रथम-अनुरोध पुनरावृत्तियों को बनाने की आवश्यकता होती है। ब्राउज़र कैशिंग यूआरएल वर्जनिंग ( http://domain.tld/file.php?x123 ) http://domain.tld/file.php?x123 सीडीएन कार्यक्षमता को और परिशोधित करता है।

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





s3fs