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

Question

मैं एक परियोजना पर काम कर रहा हूं जिसे अमेज़ॅन वेब सेवाओं पर होस्ट किया जा रहा है। सर्वर सेटअप में दो ईसी 2 इंस्टेंस, एक लोचदार लोड बैलेंसर और एक अतिरिक्त लोचदार ब्लॉक स्टोर होता है जिस पर वेब एप्लिकेशन रहता है। प्रोजेक्ट है जो उपयोगकर्ताओं को अपलोड की गई फ़ाइलों के संग्रहण के लिए S3 का उपयोग करने के लिए माना जाता है। इस सवाल के लिए, मैं S3 बाल्टी 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/) फोन करता हूँ। s3fs फाइल सिस्टम को माउंट करेगा लेकिन मुझे बाल्टी को लिखने नहीं देगा (मैंने इस सवाल को SO पर पूछा: मैं FUSE का उपयोग करके उचित अनुमतियों के साथ S3 वॉल्यूम कैसे माउंट कर सकता हूं)। RioFS फाइल सिस्टम को माउंट करेगा और मुझे खोल से बाल्टी को लिखने देगा, लेकिन PHP का उपयोग करके सहेजी गई फाइलें बाल्टी में दिखाई नहीं देती हैं (मैंने गिटहब पर प्रोजेक्ट के साथ एक मुद्दा खोला है)। s3ql बाल्टी को घुमाएगा, लेकिन फाइलों में पहले से ही बाल्टी में मौजूद फाइलों में से कोई भी फाइल सिस्टम में दिखाई नहीं दे रहा है।

ये माउंट आदेश मैं प्रयोग किया जाता हैं: https://github.com/tpyo/amazon-s3-php-class/ और इस FuelPHP विशिष्ट S3 पैकेज: https://github.com/tomschlick/fuel-s3

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 

मैं भी इस S3 वर्ग का उपयोग कर की कोशिश की है। मैं उपलब्ध बाल्टी और फ़ाइलों को सूचीबद्ध करने के लिए FuelPHP पैकेज प्राप्त करने में सक्षम था, लेकिन बाल्टी में फ़ाइलों को सहेजना विफल रहा (लेकिन त्रुटि नहीं हुई)।

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

संपादित मैं सूचित किया गया है कि इस मुद्दे को मैं GitHub पर RioFS के साथ खोला हल किया गया है। हालांकि मैंने वॉल्यूम के रूप में बाल्टी को घुमाने की कोशिश करने के बजाय S3 REST API का उपयोग करने का निर्णय लिया, ऐसा लगता है कि RioFS इन दिनों एक व्यवहार्य विकल्प हो सकता है।

Answer 1

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

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

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

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

दो यादृच्छिक PHP पुस्तकालयों:

https://github.com/KnpLabs/Gaufrette

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

Answer 2

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

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

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

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

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