कंटेनर छवियों की "स्मार्ट" सफाई की समस्या और वेयरफ़ में इसका समाधान

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

परिचय

एक कंटेनर रजिस्ट्री में छवियों की संख्या तेजी से बढ़ सकती है, अधिक भंडारण स्थान ले सकती है और इस प्रकार इसकी लागत में काफी वृद्धि हो सकती है। रजिस्ट्री में व्याप्त स्थान की स्वीकार्य वृद्धि को नियंत्रित करने, सीमित करने या बनाए रखने के लिए, इसे स्वीकार किया जाता है:

1. छवियों के लिए निश्चित संख्या में टैग का उपयोग करें;
2. किसी तरह छवियों को साफ़ करें.

पहली सीमा कभी-कभी छोटी टीमों के लिए स्वीकार्य होती है। यदि डेवलपर्स के पास पर्याप्त स्थायी टैग हैं (latest, main, test, boris आदि), रजिस्ट्री का आकार नहीं बढ़ेगा और लंबे समय तक आपको इसे साफ करने के बारे में बिल्कुल भी नहीं सोचना पड़ेगा। आखिरकार, सभी अप्रासंगिक छवियां मिटा दी जाती हैं, और सफाई के लिए कोई काम नहीं बचा है (सब कुछ एक नियमित कचरा संग्रहकर्ता द्वारा किया जाता है)।

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

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

लेकिन आप यह कैसे निर्धारित करते हैं कि कोई छवि प्रासंगिक है या नहीं?

छवि की प्रासंगिकता के लिए मानदंड

अधिकांश मामलों में, मुख्य मानदंड होंगे:

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

2. दूसरा (कम स्पष्ट, लेकिन बहुत महत्वपूर्ण और फिर से शोषण से संबंधित) - छवियां गंभीर समस्याओं का पता चलने पर रोलबैक के लिए आवश्यक वर्तमान संस्करण में. उदाहरण के लिए, हेल्म के मामले में, ये वे छवियां हैं जिनका उपयोग रिलीज़ के सहेजे गए संस्करणों में किया जाता है। (वैसे, हेल्म में डिफ़ॉल्ट रूप से सीमा 256 संशोधन है, लेकिन इसकी संभावना नहीं है कि किसी को वास्तव में बचत करने की आवश्यकता है जैसे बड़ी संख्या में संस्करण?..) आखिरकार, हम, विशेष रूप से, संस्करणों को संग्रहीत करते हैं ताकि हम उन्हें बाद में उपयोग कर सकें, यानी। यदि आवश्यक हो तो उन्हें "वापस रोल करें"।

3. तीसरा- डेवलपर की जरूरत है: सभी छवियाँ जो उनके वर्तमान कार्य से संबंधित हैं। उदाहरण के लिए, यदि हम पीआर पर विचार कर रहे हैं, तो अंतिम प्रतिबद्धता के अनुरूप एक छवि छोड़ना समझ में आता है और कहें, पिछली प्रतिबद्धता: इस तरह डेवलपर किसी भी कार्य पर तुरंत वापस आ सकता है और नवीनतम परिवर्तनों के साथ काम कर सकता है।

4. चौथा - छवियाँ वह हमारे एप्लिकेशन के संस्करणों के अनुरूप, अर्थात। अंतिम उत्पाद हैं: v1.0.0, 20.04.01/XNUMX/XNUMX, सिएरा, आदि।

ध्यान दें: यहां परिभाषित मानदंड विभिन्न कंपनियों की दर्जनों विकास टीमों के साथ बातचीत के अनुभव के आधार पर तैयार किए गए थे। हालाँकि, निश्चित रूप से, विकास प्रक्रियाओं की बारीकियों और उपयोग किए गए बुनियादी ढांचे (उदाहरण के लिए, कुबेरनेट्स का उपयोग नहीं किया जाता है) के आधार पर, ये मानदंड भिन्न हो सकते हैं।

पात्रता और मौजूदा समाधान

कंटेनर रजिस्ट्री वाली लोकप्रिय सेवाएँ, एक नियम के रूप में, अपनी स्वयं की छवि सफाई नीतियों की पेशकश करती हैं: उनमें आप उन शर्तों को परिभाषित कर सकते हैं जिनके तहत रजिस्ट्री से एक टैग हटा दिया जाता है। हालाँकि, ये स्थितियाँ नाम, निर्माण समय और टैग की संख्या* जैसे मापदंडों द्वारा सीमित हैं।

* विशिष्ट कंटेनर रजिस्ट्री कार्यान्वयन पर निर्भर करता है। हमने निम्नलिखित समाधानों की संभावनाओं पर विचार किया: एज़्योर सीआर, डॉकर हब, ईसीआर, जीसीआर, गिटहब पैकेज, गिटलैब कंटेनर रजिस्ट्री, हार्बर रजिस्ट्री, जेफ्रॉग आर्टिफैक्टरी, क्वे.आईओ - सितंबर'2020 तक।

मापदंडों का यह सेट चौथे मानदंड को पूरा करने के लिए काफी है - यानी, संस्करणों के अनुरूप छवियों का चयन करने के लिए। हालाँकि, अन्य सभी मानदंडों के लिए, किसी को किसी प्रकार का समझौता समाधान (एक कठिन या, इसके विपरीत, अधिक उदार नीति) चुनना होगा - जो अपेक्षाओं और वित्तीय क्षमताओं पर निर्भर करता है।

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

पहले दो मानदंडों के साथ स्थिति समान है: वे बाहरी सिस्टम से डेटा प्राप्त किए बिना संतुष्ट नहीं हो सकते - वह जहां एप्लिकेशन तैनात किए जाते हैं (हमारे मामले में, कुबेरनेट्स)।

Git में वर्कफ़्लो का चित्रण

मान लीजिए कि आप Git में कुछ इस तरह काम कर रहे हैं:

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

यदि सफ़ाई नीतियाँ केवल छवियों को बनाए रखने (हटाए जाने की नहीं) की अनुमति देती हैं तो क्या होगा दिए गए टैग नामों से?

जाहिर है, ऐसा परिदृश्य किसी को भी खुश नहीं करेगा।

यदि नीतियां छवियों को न हटाने की अनुमति देती हैं तो क्या परिवर्तन होगा? किसी दिए गए समय अंतराल/अंतिम प्रतिबद्धताओं की संख्या के अनुसार?

परिणाम काफी बेहतर हुआ है, लेकिन अभी भी आदर्श से कोसों दूर है। आख़िरकार, हमारे पास अभी भी ऐसे डेवलपर हैं जिन्हें बग डीबग करने के लिए रजिस्ट्री में छवियों की आवश्यकता है (या यहां तक ​​कि K8s में तैनात भी)...

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

हालाँकि, हम एक सार्वभौमिक समाधान की तलाश में थे जो विभिन्न रजिस्ट्री का उपयोग करके विभिन्न टीमों के लिए छवि सफाई को स्वचालित करेगा...

सार्वभौमिक छवि सफाई के लिए हमारा मार्ग

यह आवश्यकता कहां से आती है? तथ्य यह है कि हम डेवलपर्स का एक अलग समूह नहीं हैं, बल्कि एक टीम है जो सीआई/सीडी मुद्दों को व्यापक रूप से हल करने में मदद करते हुए उनमें से कई को एक साथ सेवा प्रदान करती है। और इसके लिए मुख्य तकनीकी उपकरण ओपन सोर्स उपयोगिता है Werf. इसकी ख़ासियत यह है कि यह एक भी कार्य नहीं करता है, बल्कि सभी चरणों में निरंतर वितरण प्रक्रियाओं में शामिल होता है: असेंबली से तैनाती तक।

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

* हालाँकि रजिस्ट्रियाँ स्वयं भिन्न हो सकती हैं (डॉकर रजिस्ट्री, गिटलैब कंटेनर रजिस्ट्री, हार्बर, आदि), उनके उपयोगकर्ताओं को समान समस्याओं का सामना करना पड़ता है। हमारे मामले में सार्वभौमिक समाधान रजिस्ट्री के कार्यान्वयन पर निर्भर नहीं करता है, क्योंकि स्वयं रजिस्ट्रियों के बाहर चलता है और सभी के लिए समान व्यवहार प्रदान करता है।

यद्यपि हम एक उदाहरण कार्यान्वयन के रूप में वेयरफ़ का उपयोग कर रहे हैं, हमें उम्मीद है कि उपयोग किए गए दृष्टिकोण समान कठिनाइयों का सामना करने वाली अन्य टीमों के लिए उपयोगी होंगे।

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

इस तुच्छ समाधान ने सबसे गंभीर समस्या (मानदंड संख्या 1) को हल कर दिया, लेकिन सफाई तंत्र में सुधार के लिए यह हमारी यात्रा की शुरुआत मात्र थी। अगला - और बहुत अधिक दिलचस्प - कदम निर्णय था प्रकाशित छवियों को Git इतिहास के साथ संबद्ध करें.

योजनाओं को टैग करना

आरंभ करने के लिए, हमने एक दृष्टिकोण चुना जिसमें अंतिम छवि को सफाई के लिए आवश्यक जानकारी संग्रहीत करनी चाहिए, और टैगिंग योजनाओं पर प्रक्रिया का निर्माण किया। एक छवि प्रकाशित करते समय, उपयोगकर्ता ने एक विशिष्ट टैगिंग विकल्प चुना (git-branch, git-commit या git-tag) और संबंधित मान का उपयोग किया। सीआई प्रणालियों में, ये मान पर्यावरण चर के आधार पर स्वचालित रूप से सेट किए गए थे। वास्तव में अंतिम छवि एक विशिष्ट Git आदिम से जुड़ी थी, लेबल में सफाई के लिए आवश्यक डेटा संग्रहीत करना।

इस दृष्टिकोण के परिणामस्वरूप नीतियों का एक सेट तैयार हुआ जिसने Git को सत्य के एकल स्रोत के रूप में उपयोग करने की अनुमति दी:

• Git में किसी शाखा/टैग को हटाते समय, रजिस्ट्री में संबंधित छवियां स्वचालित रूप से हटा दी गईं।
• Git टैग और कमिट से जुड़ी छवियों की संख्या को चयनित स्कीमा में उपयोग किए गए टैग की संख्या और संबंधित कमिट बनाए जाने के समय द्वारा नियंत्रित किया जा सकता है।

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

नया एल्गोरिदम

क्यों? सामग्री-आधारित टैगिंग के साथ, प्रत्येक टैग Git में एकाधिक प्रतिबद्धताओं को पूरा कर सकता है। छवियों को साफ़ करते समय, आप अब कल्पना नहीं कर सकते केवल उस कमिट से जहां रजिस्ट्री में नया टैग जोड़ा गया था।

नए सफाई एल्गोरिदम के लिए, टैगिंग योजनाओं से दूर जाने और निर्माण करने का निर्णय लिया गया मेटा-इमेज प्रक्रिया, जिनमें से प्रत्येक एक गुच्छा संग्रहीत करता है:

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

दूसरे शब्दों में, यह प्रदान किया गया था प्रकाशित टैग को Git में कमिट के साथ जोड़ना.

अंतिम विन्यास और सामान्य एल्गोरिदम

सफ़ाई कॉन्फ़िगर करते समय, उपयोगकर्ताओं के पास अब उन नीतियों तक पहुंच होती है जो वर्तमान छवियों का चयन करती हैं। ऐसी प्रत्येक नीति परिभाषित है:

• कई सन्दर्भ, अर्थात् Git टैग या Git शाखाएँ जिनका उपयोग स्कैनिंग के दौरान किया जाता है;
• और सेट से प्रत्येक संदर्भ के लिए खोजी गई छवियों की सीमा।

स्पष्ट करने के लिए, डिफ़ॉल्ट नीति कॉन्फ़िगरेशन इस तरह दिखना शुरू हुआ:

cleanup:
  keepPolicies:
  - references:
      tag: /.*/
      limit:
        last: 10
  - references:
      branch: /.*/
      limit:
        last: 10
        in: 168h
        operator: And
    imagesPerReference:
      last: 2
      in: 168h
      operator: And
  - references:  
      branch: /^(main|staging|production)$/
    imagesPerReference:
      last: 10

इस कॉन्फ़िगरेशन में तीन नीतियां शामिल हैं जो निम्नलिखित नियमों का अनुपालन करती हैं:

1. पिछले 10 Git टैग के लिए छवि सहेजें (टैग निर्माण तिथि के अनुसार)।
2. पिछले सप्ताह में प्रकाशित 2 से अधिक छवियों को सेव न करें और पिछले सप्ताह की गतिविधि वाले 10 थ्रेड से अधिक न रखें।
3. शाखाओं के लिए 10 छवियाँ सहेजें main, staging и production.

अंतिम एल्गोरिदम निम्नलिखित चरणों पर आधारित है:

• कंटेनर रजिस्ट्री से मैनिफ़ेस्ट पुनर्प्राप्त किया जा रहा है।
• कुबेरनेट्स में प्रयुक्त छवियों को छोड़कर, क्योंकि हमने K8s API पर मतदान करके उन्हें पहले से ही चयनित कर लिया है।
• Git इतिहास को स्कैन करना और निर्दिष्ट नीतियों के आधार पर छवियों को बाहर करना।
• शेष छवियाँ हटा रहा हूँ.

अपने चित्रण पर लौटते हुए, वेयरफ़ के साथ यही होता है:

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

निष्कर्ष

• देर-सबेर अधिकांश टीमों को रजिस्ट्री ओवरफ़्लो की समस्या का सामना करना पड़ता है।
• समाधान खोजते समय, सबसे पहले छवि की प्रासंगिकता के मानदंड निर्धारित करना आवश्यक है।
• लोकप्रिय कंटेनर रजिस्ट्री सेवाओं द्वारा पेश किए गए उपकरण आपको एक बहुत ही सरल सफाई को व्यवस्थित करने की अनुमति देते हैं जो "बाहरी दुनिया" को ध्यान में नहीं रखता है: कुबेरनेट्स में उपयोग की जाने वाली छवियां और टीम के वर्कफ़्लो की ख़ासियतें।
• एक लचीले और कुशल एल्गोरिदम को सीआई/सीडी प्रक्रियाओं की समझ होनी चाहिए और न केवल डॉकर छवि डेटा के साथ काम करना चाहिए।

पुनश्च

हमारे ब्लॉग पर भी पढ़ें:

• «वेयरफ़ बिल्डर में सामग्री-आधारित टैगिंग: यह क्यों और कैसे काम करती है?";
• «वेयरफ़ में 3-तरफ़ा विलय: "स्टेरॉयड पर" हेल्म के साथ कुबेरनेट्स में तैनाती";
• «Werf में मोनोरेपो और मल्टीरेपो के लिए समर्थन और डॉकर रजिस्ट्री का इससे क्या लेना-देना है";
• «वेयरफ़ 1.1 रिलीज़: बिल्डर में आज सुधार और भविष्य के लिए योजनाएँ'.

स्रोत: www.habr.com