2016-07-08 6 views
5

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

तैनाती के बारे में कुछ आवश्यकताओं:

  • धक्का सॉफ्टवेयर सर्वर -> डिवाइस
  • डिवाइस का एक प्रतिशत जो समय के साथ बढ़ जाती है के लिए चरणबद्ध रोलआउट, रोलआउट
  • रोलबैक सॉफ्टवेयर
  • डिवाइस प्रावधान
  • कोई कंटेनर प्रौद्योगिकी

इसे प्राप्त करने के लिए कुछ अच्छे दृष्टिकोण क्या हैं?

उत्तर

3

(अस्वीकरण: resin.io पर डेवलपर इंजीलवादी यहाँ)।

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

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

यह कंटेनर तकनीक के बारे में आप को समझाने के लिए नहीं है, बस पर प्रकाश डाला है कि क्या है या नहीं अपने खुद के आवेदन कंटेनरीकृत है (सबसे अधिक संभावना यह नहीं है और ऐसे ही रहना होगा!), सेवाओं है कि कि तकनीक के रूप में उपयोग के खिलाफ का चयन नहीं करते उनके ढेर का हिस्सा। प्रत्येक सेवा आवश्यकतानुसार आपको आवश्यक कार्यक्षमता प्रदान करने का प्रयास करती है।

सापेक्ष अपना चेकलिस्ट के रूप में resin.io रहे हैं:

  • धक्का सॉफ्टवेयर सर्वर -> डिवाइस: डिवाइस का एक प्रतिशत के लिए जाँच, git push resin master और अपने कोड तैनात हो रही है
  • चरणबद्ध रोलआउट, रोलआउट जो के साथ बढ़ता है: सामान्य सुविधा सेट का हिस्सा नहीं है, लेकिन resin supervisor API का उपयोग करके इसे कार्यान्वित करना आसान है: उदाहरण के लिए सभी उपकरणों के लिए लॉक अपडेट, और आप चुन सकते हैं कि कौन से डिवाइस अनलॉक और अपडेट हो जाएंगे। सामान्य सुविधा सेट (अभी तक) का हिस्सा नहीं है, लेकिन Git के साथ यह पिछले संस्करणों फिर से पुश करने के लिए आसान है: यह सब एक एपीआई के माध्यम से है, इसलिए इसमें अपना पसंदीदा तैनाती रणनीति
  • रोलबैक सॉफ्टवेयर फिट करने के लिए अनुकूलन है। आपके सेटअप में पुस्तकालयों के संस्करणों को पिन करने के लिए कुछ देखभाल करने की आवश्यकता है जिसके परिणामस्वरूप पुनरुत्पादन सेटअप हो सकता है, लेकिन अभ्यास में किया जा सकता है।
  • डिवाइस प्रावधान: स्वचालित डिवाइस सेटअप, या एक API/एसडीके के माध्यम से प्रावधानीकरण/CLI उपलब्ध है
  • कोई कंटेनर प्रौद्योगिकी: जैसा कि ऊपर उल्लेख, व्यवहार में आप बहुत ज्यादा परवाह करने की जरूरत नहीं होना चाहिए कि सेवा रास्ता आपके सॉफ़्टवेयर को वितरित करता है, क्योंकि इससे अधिकांश मामलों में यह प्रभावित नहीं होता है कि आपका एप्लिकेशन कैसा व्यवहार करता है।

इसके अलावा, आप एडब्ल्यूएस IoT उल्लेख किया है, वहाँ एडब्ल्यूएस साथ resin.io को एकीकृत, एक डिवाइस में एडब्ल्यूएस IoT साथ resin.io उपकरणों के स्वचालित उपकरण प्रावधान कर (प्लग एक उदाहरण परियोजना सहित पर some documentation है, और यह स्वचालित रूप से साख हो जाता है एडब्ल्यूएस आईओटी के लिए)। यह कुछ ऐसा हो सकता है जो आपकी रूचि रखता हो।

संबंधित मुद्दे