अमेजन S3 के साथ Git और मर्क्यूरियल रिपॉजिटरी का विस्तार

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

अक्सर, इससे कोई फर्क नहीं पड़ता। मुझे नहीं पता कि यह कारण या परिणाम है, लेकिन संस्करण नियंत्रण प्रणाली का उपयोग मुख्य रूप से अपेक्षाकृत छोटी पाठ फ़ाइलों को संग्रहीत करने के लिए किया जाता है। कभी-कभी कुछ चित्र या पुस्तकालय।

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

इसके बाद, हम दोनों समाधानों का लाभ उठाने और कमियों की भरपाई करने के लिए संस्करण नियंत्रण प्रणालियों और अमेज़ॅन एस 3 (क्लाउड फ़ाइल स्टोरेज) को एकीकृत करने के उदाहरण को देखेंगे।

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

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

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

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

रिपोजिटरी इंटीग्रेशन

मेटाडेटा फ़ाइल कुछ इस तरह दिखती है:

<?xml version="1.0" encoding="utf-8"?> <assets> <locations> <location>Content\Textures</location> <location>Content\Sounds</location> <location searchPattern="*.pdf">Docs</location> <location>Reference Libraries</location> </locations> <amazonS3> <accesskey>*****************</accesskey> <secretkey>****************************************</secretkey> <bucketname>mybucket</bucketname> </amazonS3> <files> <file path="Content\Textures\texture1.dds" checksum="BEF94D34F75D2190FF98746D3E73308B1A48ED241B857FFF8F9B642E7BB0322A"/> <file path="Content\Textures\texture1.psd" checksum="743391C2C73684AFE8CEB4A60B0317E634B6E54403E018385A85F048CC5925DE"/> <!--        --> </files> </assets> 

इस फ़ाइल में तीन खंड हैं: स्थान, amazonS3 और फ़ाइलें। पहले दो को बहुत शुरुआत में उपयोगकर्ता द्वारा कॉन्फ़िगर किया गया है, और अंतिम का उपयोग प्रोग्राम द्वारा स्वयं फ़ाइलों को ट्रैक करने के लिए किया जाता है।

स्थान वे मार्ग हैं जिनके द्वारा ट्रैकिंग फ़ाइलों को खोजा जाएगा। ये या तो पूर्ण पथ या पथ इस xml सेटिंग्स फ़ाइल के सापेक्ष हैं। संस्करण नियंत्रण प्रणाली की अनदेखी फ़ाइल में समान पथ जोड़े जाने चाहिए ताकि यह स्वयं उन्हें ट्रैक करने का प्रयास न करे।

AmazonS3 है, जैसा कि आप अनुमान लगा सकते हैं, क्लाउड फ़ाइल भंडारण सेटिंग्स। पहली दो चाबियाँ एक्सेस कीज़ हैं, जो किसी भी एडब्ल्यूएस उपयोगकर्ता के लिए उत्पन्न की जा सकती हैं। इनका उपयोग क्रिप्टोग्राफिक रूप से अमेज़ॅन एपीआई अनुरोधों पर हस्ताक्षर करने के लिए किया जाता है। बकेटनेम बाल्टी का नाम है, अमेज़ॅन एस 3 के भीतर एक इकाई जिसमें फाइलें और फ़ोल्डर्स हो सकते हैं और निगरानी की गई फ़ाइलों के सभी संस्करणों को संग्रहीत करने के लिए उपयोग किया जाएगा।

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

संस्करण नियंत्रण प्रणाली के साथ एकीकरण

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

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

चार अलग-अलग परिस्थितियां हो सकती हैं:

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

पांचवीं संभावित स्थिति है - फ़ाइल को संशोधित नहीं किया गया है। यह तब होता है जब पथ और हैश दोनों के साथ एक मैच होता है। और इस स्थिति में कोई कार्रवाई की आवश्यकता नहीं है।

पुल कमांड स्थानीय फ़ाइलों की सूची के साथ xml से फ़ाइलों की सूची की तुलना भी करता है और ठीक उसी तरह से काम करता है, केवल विपरीत दिशा में। उदाहरण के लिए, जब xml में एक नई फ़ाइल के बारे में एक प्रविष्टि होती है, अर्थात, पथ पर या हैश पर कोई मेल नहीं होता है, तो यह फ़ाइल S3 से डाउनलोड की जाती है और निर्दिष्ट पथ पर स्थानीय रूप से लिखी जाती है।

कॉन्फ़िगर किए गए हुक के साथ उदाहरण hgrc:

 [hooks] postupdate = \path\to\assets.exe pull \path\to\assets.config \path\to\checksum.cache prepush = \path\to\assets.exe push \path\to\assets.config \path\to\checksum.cache 

हैशिंग

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

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

संभावना को कम करने के लिए बहुत सरल है - आपको एक लंबी कुंजी के साथ हैश फ़ंक्शन का उपयोग करने की आवश्यकता है। मेरे कार्यान्वयन में, मैंने SHA256 का उपयोग किया, जो कि पर्याप्त से अधिक है। हालांकि, यह अभी भी टकराव की संभावना को बाहर नहीं करता है। कोई भी बदलाव करने से पहले आपको उन्हें परिभाषित करने में सक्षम होना चाहिए।

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

अनुकूलन

ऐसे कार्यक्रम के लिए कोई सख्त प्रदर्शन आवश्यकताएं नहीं हैं। यह एक सेकंड या पांच के लिए काम करता है - इतना महत्वपूर्ण नहीं। हालांकि, ऐसे स्पष्ट स्थान हैं जिन्हें माना जा सकता है और माना जाना चाहिए। और शायद सबसे स्पष्ट हैशिंग।

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

यदि आप देखते हैं कि रिपॉजिटरी के विशिष्ट उपयोग में पुश से पहले तुरंत सभी फाइलों को बदलना शामिल नहीं है, तो समाधान स्पष्ट हो जाता है - कैशिंग। मेरे कार्यान्वयन में, मैं एक पाइप सीमांकित फ़ाइल का उपयोग करने पर बस गया, जो कार्यक्रम के बगल में झूठ होगा और इसमें पहले से गणना की गई राख के बारे में जानकारी होगी:

   | |   

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

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

अमेज़न s3

यहां दो बिंदु स्पष्ट करने योग्य हैं। सबसे महत्वपूर्ण बात शायद इस मुद्दे की कीमत है। जैसा कि आप जानते हैं, नए उपयोगकर्ताओं के लिए उपयोग का पहला वर्ष मुफ्त है, यदि आप सीमा से परे नहीं जाते हैं। सीमाएँ इस प्रकार हैं: 5 गीगाबाइट, प्रति माह 20,000 GetObject अनुरोध और प्रति माह 2,000 PutObject अनुरोध। यदि आप पूरी कीमत चुकाते हैं, तो एक महीने का मूल्य लगभग $ 1 होगा। इसके लिए, आपको क्षेत्र के भीतर कई डेटा सेंटर और अच्छी गति के लिए आरक्षण मिलता है।

इसके अलावा, मुझे यह सुझाव देने की हिम्मत है कि पाठक शुरू से ही निम्न प्रश्न से परेशान है - ड्रॉपबॉक्स क्यों है? तथ्य यह है कि सहयोग के लिए सीधे ड्रॉपबॉक्स का उपयोग करना असंभव है - यह संघर्षों से बिल्कुल भी सामना नहीं करता है।

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

संशोधित स्रोत लिंक: bitbucket.org/openminded/assetsmanager