सर्वर पर एप्लिकेशन तैनात करते समय, आमतौर पर एप्लिकेशन के साथ क्या बंडल होता है और यह प्लेटफॉर्म (ऑपरेटिंग सिस्टम और इंस्टॉल किए गए पैकेज) से क्या उम्मीद करता है, इसके बीच एक अलगाव होता है । इसका एक बिंदु यह है कि प्लेटफ़ॉर्म को एप्लिकेशन से स्वतंत्र रूप से अपडेट किया जा सकता है । यह उदाहरण के लिए उपयोगी है जब सुरक्षा अपडेट को पूरे एप्लिकेशन के पुनर्निर्माण के बिना प्लेटफॉर्म द्वारा प्रदान किए गए पैकेजों पर तत्काल लागू करने की आवश्यकता होती है ।
परंपरागत रूप से सुरक्षा अपडेट केवल ऑपरेटिंग सिस्टम पर पैकेज के अपडेट किए गए संस्करणों को स्थापित करने के लिए पैकेज मैनेजर कमांड को निष्पादित करके लागू किया गया है (उदाहरण के लिए आरएचईएल पर "यम अपडेट") । लेकिन कंटेनर तकनीक जैसे डॉकर के आगमन के साथ जहां कंटेनर छवियां अनिवार्य रूप से दोनों एप्लिकेशन को बंडल करती हैं और प्लेटफ़ॉर्म, कंटेनरों के साथ सिस्टम को अद्यतित रखने का विहित तरीका क्या है? होस्ट और कंटेनर दोनों के पास अपने स्वयं के, स्वतंत्र, पैकेजों के सेट होते हैं जिन्हें होस्ट पर अपडेट करने और अपडेट करने की आवश्यकता होती है, कंटेनरों के अंदर किसी भी पैकेज को अपडेट नहीं करेंगे । आरएचईएल 7 की रिलीज के साथ जहां डॉकर कंटेनरों को विशेष रूप से चित्रित किया गया है, यह सुनना दिलचस्प होगा कि कंटेनरों के सुरक्षा अपडेट को संभालने के लिए रेडहैट का अनुशंसित तरीका क्या है ।
कुछ विकल्पों पर विचार:
होस्ट पर पैकेज मैनेजर अपडेट पैकेज देने से कंटेनर के अंदर पैकेज अपडेट नहीं होंगे ।
अपडेट लागू करने के लिए सभी कंटेनर छवियों को पुन: उत्पन्न करने के लिए एप्लिकेशन और प्लेटफ़ॉर्म के बीच अलगाव को तोड़ने लगता है (प्लेटफ़ॉर्म को अपडेट करने के लिए एप्लिकेशन बिल्ड प्रक्रिया तक पहुंच की आवश्यकता होती है जो डॉकर छवियों को उत्पन्न करती है) ।
प्रत्येक चल रहे कंटेनर के अंदर मैन्युअल कमांड चलाना बोझिल लगता है और अगली बार कंटेनर को एप्लिकेशन रिलीज़ कलाकृतियों से अपडेट किए जाने पर परिवर्तनों को अधिलेखित होने का खतरा होता है ।
इसलिए इनमें से कोई भी दृष्टिकोण संतोषजनक नहीं लगता है ।
कंटेनरों को हल्का और विनिमेय माना जाता है । यदि आपके कंटेनर में सुरक्षा समस्या है, तो आप पैच किए गए कंटेनर के एक संस्करण का पुनर्निर्माण करते हैं और नए कंटेनर को तैनात करते हैं । (कई कंटेनर एक मानक आधार छवि का उपयोग करते हैं जो मानक पैकेज प्रबंधन उपकरण का उपयोग करता है जैसे कि उनकी निर्भरता को स्थापित करने के लिए, पुनर्निर्माण रिपॉजिटरी से अपडेट खींच लेगा)
जब आप कंटेनरों के अंदर पैच कर सकते हैं, तो यह अच्छी तरह से स्केल नहीं होगा ।
सबसे पहले, आपके कई अपडेट जो आपने पारंपरिक रूप से अतीत में चलाए थे, वे कंटेनर के अंदर ही नहीं होंगे । कंटेनर पूर्ण फ़ाइल सिस्टम का काफी हल्का और छोटा सबसेट होना चाहिए जो अतीत में देखने के आदी हो । आपको जिन पैकेजों को अपडेट करना चाहिए, वे वे होंगे जो आपके डॉकरफाइल का हिस्सा हैं, और चूंकि आपके पास डॉकरफाइल है, इसलिए आपको उन पैकेजों और कंटेनर आईडी का ट्रैक रखने में सक्षम होना चाहिए जिन्हें अपडेट की आवश्यकता है । Cloudstein के यूआई है कि जल्द ही जारी किया जाएगा का ट्रैक रखता है इन DockerFile सामग्री के लिए आप इतना है कि एक का निर्माण कर सकते हैं अद्यतन की योजना है कि सबसे अच्छा फिट बैठता है के लिए अपने कंटेनर. आशा है कि यह मदद करता है
वाल्को, आप किस वर्कफ़्लो के साथ समाप्त हुए? मैं दीर्घकालिक कंटेनर चला रहा हूं(उदाहरण के लिए पीएचपी-सीजीआई की मेजबानी) और मैंने अब तक जो पाया है वह है: छवि को अपडेट करने के लिए डॉकर पुल डेबियन/जेसी, फिर मेरी मौजूदा छवि (ओं) का पुनर्निर्माण करें, फिर कंटेनरों को रोकें और उन्हें फिर से चलाएं (नई छवि के साथ) । मेरे द्वारा बनाई गई छवियों का नाम पिछले वाले के समान है, इसलिए शुरुआत स्क्रिप्ट के माध्यम से की जाती है । मैं फिर “अनाम” छवियों को हटा देता हूं । मैं निश्चित रूप से एक बेहतर वर्कफ़्लो की सराहना करूंगा ।
दिलचस्प सवाल। मुझे खुद इसके बारे में आश्चर्य है । यदि आपके पास एक डॉकर होस्ट पर 20 एप्लिकेशन चल रहे हैं, तो आपको आधार छवियों को अपग्रेड करना होगा, पुनर्निर्माण करना होगा और पुनरारंभ करना होगा! 20 एप्लिकेशन और आप यह भी नहीं जानते हैं कि सुरक्षा अद्यतन ने उन सभी को प्रभावित किया है, या उनमें से सिर्फ एक । आपको अपाचे कहने के लिए छवि का पुनर्निर्माण करना होगा जब सुरक्षा अद्यतन उदाहरण के लिए केवल परिवाद को प्रभावित करता है । तो आप अनावश्यक पुनर्निर्माण और पुनरारंभ के साथ समाप्त होते हैं । …
मिहा: यह वैसा ही लगता है जैसा मैंने किया है । मूल रूप से नई रिलीज़ करने के हिस्से के रूप में सभी छवियों को लगातार अपडेट और पुनर्निर्माण करना । और नई छवियों का उपयोग करके कंटेनरों को पुनरारंभ करना ।