कंटेनर प्रतिमांची "स्मार्ट" साफसफाईची समस्या आणि werf मध्ये त्याचे निराकरण

लेख कुबरनेटेसला वितरित केलेल्या क्लाउड नेटिव्ह ऍप्लिकेशन्ससाठी आधुनिक CI/CD पाइपलाइनच्या वास्तविकतेमध्ये कंटेनर रजिस्ट्रीमध्ये (डॉकर रजिस्ट्री आणि त्याचे अॅनालॉग्स) जमा होणाऱ्या प्रतिमा साफ करण्याच्या समस्येशी संबंधित आहे. प्रतिमांच्या प्रासंगिकतेचे मुख्य निकष आणि स्वयंचलित साफसफाई, जागेची बचत आणि संघांच्या गरजा पूर्ण करण्यात परिणामी अडचणी दिल्या आहेत. शेवटी, विशिष्ट मुक्त स्त्रोत प्रकल्पाचे उदाहरण वापरून, आम्ही या अडचणींवर मात कशी करता येईल याचे वर्णन करू.

परिचय

कंटेनर रेजिस्ट्रीमधील प्रतिमांची संख्या झपाट्याने वाढू शकते, अधिक स्टोरेज जागा घेते आणि त्यामुळे स्टोरेज खर्चात लक्षणीय वाढ होते. रेजिस्ट्रीमध्ये व्यापलेल्या जागेची स्वीकार्य वाढ नियंत्रित करण्यासाठी, मर्यादित करण्यासाठी किंवा राखण्यासाठी, हे प्रथा आहे:

1. प्रतिमांसाठी निश्चित संख्येने टॅग वापरा;
2. कसे तरी प्रतिमा साफ करा.

पहिली मर्यादा कधीकधी लहान संघांसाठी वैध असते. विकसकांकडे पुरेसे पर्सिस्टंट टॅग असल्यास (latest, main, test, boris इ.), रेजिस्ट्री आकारात फुगणार नाही आणि बर्याच काळासाठी तुम्हाला ती साफ करण्याबद्दल अजिबात विचार करण्याची गरज नाही. तथापि, सर्व असंबद्ध प्रतिमा पुसून टाकल्या जातात आणि साफसफाईसाठी कोणतेही काम उरले नाही (सर्व काही नियमित कचरा संग्राहकाद्वारे केले जाते).

तथापि, हा दृष्टिकोन विकासास गंभीरपणे मर्यादित करतो आणि आधुनिक CI/CD प्रकल्पांना क्वचितच लागू होतो. विकासाचा अविभाज्य भाग होता ऑटोमेशन, जे तुम्हाला वापरकर्त्यांना अधिक जलद चाचणी, उपयोजित आणि नवीन कार्यक्षमता वितरित करण्यास अनुमती देते. उदाहरणार्थ, आमच्या सर्व प्रकल्पांमध्ये, प्रत्येक कमिटसह एक CI पाइपलाइन स्वयंचलितपणे तयार केली जाते. त्यामध्ये एक प्रतिमा एकत्र केली जाते, चाचणी केली जाते, डीबगिंग आणि उर्वरित तपासण्यांसाठी विविध कुबर्नेट्स सर्किट्सवर आणले जाते आणि सर्वकाही ठीक असल्यास, बदल अंतिम वापरकर्त्यापर्यंत पोहोचतात. आणि हे बर्याच काळापासून रॉकेट विज्ञान नाही, परंतु बर्‍याच लोकांसाठी सामान्य आहे - बहुधा तुमच्यासाठी, कारण तुम्ही हा लेख वाचत आहात.

दोष निराकरणे आणि नवीन वैशिष्ट्यांचा विकास समांतरपणे केला जात असल्याने, आणि रिलीझ दिवसातून अनेक वेळा केले जाऊ शकतात, हे स्पष्ट आहे की विकास प्रक्रियेमध्ये मोठ्या संख्येने कमिट असतात, याचा अर्थ - रेजिस्ट्रीमध्ये मोठ्या संख्येने प्रतिमा. परिणामी, रेजिस्ट्रीची प्रभावी साफसफाई आयोजित करण्याचा मुद्दा, म्हणजे. असंबद्ध प्रतिमा काढून टाकणे.

परंतु प्रतिमा संबंधित आहे की नाही हे कसे ठरवायचे?

प्रतिमेच्या प्रासंगिकतेसाठी निकष

बहुसंख्य प्रकरणांमध्ये, मुख्य निकष खालीलप्रमाणे असतील:

1. प्रथम (सर्वात स्पष्ट आणि सर्वात गंभीर) त्या प्रतिमा आहेत सध्या Kubernetes मध्ये वापरले जाते. या प्रतिमा हटवण्यामुळे महत्त्वपूर्ण उत्पादन डाउनटाइम खर्च होऊ शकतो (उदाहरणार्थ, प्रतिकृतीसाठी प्रतिमा आवश्यक असू शकतात) किंवा कोणत्याही लूपवर डीबग करणार्‍या टीमचे प्रयत्न रद्दबातल ठरू शकतात. (या कारणास्तव, आम्ही एक विशेष देखील केले प्रोमिथियस निर्यातक, जे कोणत्याही कुबर्नेट्स क्लस्टरमध्ये अशा प्रतिमांच्या अनुपस्थितीचा मागोवा ठेवते.)

2. दुसरी (कमी स्पष्ट, पण अतिशय महत्त्वाची आणि पुन्हा शोषणाशी संबंधित) प्रतिमा आहेत ज्या गंभीर समस्या आढळल्यास रोलबॅकसाठी आवश्यक वर्तमान आवृत्तीमध्ये. उदाहरणार्थ, हेल्मच्या बाबतीत, या प्रतिमा आहेत ज्या रिलीझच्या जतन केलेल्या आवृत्त्यांमध्ये वापरल्या जातात. (तसे, बाय डीफॉल्ट हेल्मला 256 पुनरावृत्तींची मर्यादा आहे, परंतु क्वचितच कोणालाही वाचवण्याची गरज आहे अशा मोठ्या संख्येने आवृत्त्या? आवश्यक असल्यास त्यांच्यावर "रोल बॅक" करा.

3. तिसरा - विकासकाच्या गरजा: सर्व स्किन जे त्यांच्या वर्तमान कार्याशी संबंधित आहेत. उदाहरणार्थ, जर आपण PR चा विचार करत असाल, तर शेवटच्या कमिटशी संबंधित प्रतिमा सोडण्यात अर्थ आहे आणि म्हणा, मागील कमिट: अशा प्रकारे विकसक कोणत्याही कार्यावर त्वरित परत येऊ शकतो आणि नवीनतम बदलांसह कार्य करू शकतो.

4. चौथा - प्रतिमा आमच्या अनुप्रयोगाच्या आवृत्त्यांशी जुळवा, म्हणजे अंतिम उत्पादन आहेत: v1.0.0, 20.04.01, sierra, इ.

NB: येथे परिभाषित केलेले निकष विविध कंपन्यांमधील डझनभर विकास कार्यसंघांशी संवाद साधण्याच्या अनुभवावर आधारित आहेत. तथापि, अर्थातच, विकास प्रक्रियेतील तपशील आणि वापरलेल्या पायाभूत सुविधांवर अवलंबून (उदाहरणार्थ, कुबर्नेट्सचा वापर केला जात नाही), हे निकष भिन्न असू शकतात.

पात्रता आणि विद्यमान उपाय

कंटेनर रेजिस्ट्रीसह लोकप्रिय सेवा, नियमानुसार, त्यांची स्वतःची प्रतिमा साफ करण्याची धोरणे ऑफर करतात: त्यामध्ये आपण रेजिस्ट्रीमधून टॅग काढलेल्या अटी परिभाषित करू शकता. तथापि, या अटी नावे, निर्मिती वेळ आणि टॅगची संख्या* यासारख्या पॅरामीटर्सद्वारे मर्यादित आहेत*.

* विशिष्ट कंटेनर नोंदणी अंमलबजावणीवर अवलंबून असते. आम्ही खालील उपायांच्या शक्यतांचा विचार केला: Azure CR, Docker Hub, ECR, GCR, GitHub पॅकेजेस, GitLab कंटेनर रजिस्ट्री, हार्बर रजिस्ट्री, JFrog आर्टिफॅक्टरी, Quay.io - सप्टेंबर २०२० पर्यंत.

पॅरामीटर्सचा असा संच चौथा निकष पूर्ण करण्यासाठी पुरेसा आहे - म्हणजे, आवृत्त्यांशी संबंधित प्रतिमा निवडण्यासाठी. तथापि, इतर सर्व निकषांसाठी, अपेक्षा आणि आर्थिक क्षमतांवर अवलंबून काही प्रकारचे तडजोड उपाय (एक कठोर किंवा, उलट, एक अतिरिक्त धोरण) निवडणे आवश्यक आहे.

उदाहरणार्थ, तिसरा निकष - विकासकांच्या गरजांशी संबंधित - संघांमध्ये प्रक्रिया आयोजित करून सोडवला जाऊ शकतो: प्रतिमांचे विशिष्ट नामकरण, विशेष परवानगी याद्या आणि अंतर्गत करार राखणे. परंतु शेवटी ते अद्याप स्वयंचलित करणे आवश्यक आहे. आणि जर तयार सोल्यूशन्सची शक्यता पुरेशी नसेल, तर तुम्हाला स्वतःचे काहीतरी करावे लागेल.

पहिल्या दोन निकषांसह परिस्थिती सारखीच आहे: बाह्य प्रणालीकडून डेटा प्राप्त केल्याशिवाय त्यांचे समाधान होऊ शकत नाही - जिथे अनुप्रयोग तैनात केले जातात (आमच्या बाबतीत, हे कुबर्नेट्स आहे).

Git वर्कफ्लो चित्रण

समजा तुम्ही Git मध्ये असे काम करता:

आकृतीमध्ये डोके असलेले चिन्ह कंटेनर प्रतिमा चिन्हांकित करते जे सध्या कोणत्याही वापरकर्त्यांसाठी (अंतिम वापरकर्ते, परीक्षक, व्यवस्थापक, इ.) कुबरनेटमध्ये उपयोजित आहेत किंवा विकासकांनी डीबगिंग आणि तत्सम हेतूंसाठी वापरल्या आहेत.

क्लीनअप धोरणे तुम्हाला फक्त इमेज ठेवण्याची (हटवू नका) परवानगी दिल्यास काय होईल दिलेल्या टॅग नावांनुसार?

साहजिकच, अशी परिस्थिती कोणालाही आवडणार नाही.

धोरणे प्रतिमा हटविण्यास परवानगी देत ​​नाहीत तर काय बदलेल दिलेल्या वेळेच्या अंतराने / अलीकडील कमिटच्या संख्येनुसार?

परिणाम खूप चांगला झाला आहे, परंतु अद्याप आदर्शापासून दूर आहे. शेवटी, आमच्याकडे अजूनही डेव्हलपर आहेत ज्यांना बग डीबग करण्यासाठी रेजिस्ट्रीमध्ये (किंवा K8 मध्ये तैनात केलेल्या) प्रतिमा आवश्यक आहेत ...

सध्याच्या बाजाराच्या परिस्थितीचा सारांश देण्यासाठी, कंटेनर रजिस्ट्रीमध्ये उपलब्ध कार्ये साफसफाईमध्ये पुरेशी लवचिकता देत नाहीत आणि याचे मुख्य कारण आहे बाहेरील जगाशी संवाद साधता येत नाही. असे दिसून आले की ज्या संघांना या लवचिकतेची आवश्यकता आहे त्यांना डॉकर रेजिस्ट्री API (किंवा संबंधित अंमलबजावणीचे मूळ API) वापरून "बाहेरील" प्रतिमा काढून टाकण्याची अंमलबजावणी करण्यास भाग पाडले जाते.

तथापि, आम्ही एक सार्वत्रिक उपाय शोधत होतो जो भिन्न रजिस्ट्री वापरून भिन्न संघांसाठी प्रतिमा साफ करणे स्वयंचलित करेल…

युनिव्हर्सल इमेज क्लीनअपचा आमचा मार्ग

अशी गरज कुठून येते? वस्तुस्थिती अशी आहे की आम्ही विकासकांचा एक वेगळा गट नाही, परंतु एक संघ आहे जो त्यांच्यापैकी अनेकांना एकाच वेळी सेवा देतो, CI/CD समस्यांचे सर्वसमावेशकपणे निराकरण करण्यात मदत करतो. आणि यासाठी मुख्य तांत्रिक साधन म्हणजे ओपन सोर्स युटिलिटी werf. त्याचे वैशिष्ठ्य असे आहे की ते एकच कार्य करत नाही, परंतु सर्व टप्प्यांवर सतत वितरण प्रक्रियेसह आहे: असेंब्लीपासून तैनातीपर्यंत.

रेजिस्ट्री* मध्ये प्रतिमा प्रकाशित करणे (त्या तयार झाल्यानंतर लगेच) हे अशा उपयुक्ततेचे स्पष्ट कार्य आहे. आणि प्रतिमा तेथे स्टोरेजसाठी ठेवल्या गेल्या असल्याने - जर तुमचा स्टोरेज अमर्यादित नसेल - तर तुम्हाला त्यांच्या नंतरच्या साफसफाईसाठी जबाबदार असणे आवश्यक आहे. दिलेल्या सर्व निकषांची पूर्तता करून आम्ही यामध्ये कसे यशस्वी झालो, यावर पुढे चर्चा केली जाईल.

* जरी रजिस्ट्री स्वतः भिन्न असू शकतात (डॉकर रजिस्ट्री, गिटलॅब कंटेनर रजिस्ट्री, हार्बर इ.), त्यांच्या वापरकर्त्यांना समान समस्यांचा सामना करावा लागतो. आमच्या बाबतीत सार्वत्रिक उपाय रेजिस्ट्रीच्या अंमलबजावणीवर अवलंबून नाही, कारण स्वतः रजिस्ट्रीबाहेर चालते आणि सर्वांसाठी समान वर्तन ऑफर करते.

आम्ही उदाहरण अंमलबजावणी म्हणून werf वापरत असलो तरी, आम्हाला आशा आहे की वापरलेले दृष्टिकोन समान अडचणींचा सामना करणाऱ्या इतर संघांसाठी उपयुक्त ठरतील.

त्यामुळे आम्ही व्यस्त झालो बाह्य कंटेनरच्या नोंदणीमध्ये आधीच तयार केलेल्या वैशिष्ट्यांऐवजी - प्रतिमा साफ करण्यासाठी यंत्रणेची अंमलबजावणी. पहिली पायरी म्हणजे टॅग्जची संख्या आणि ते तयार केल्‍या वेळेसाठी समान आदिम धोरणे तयार करण्‍यासाठी डॉकर रेजिस्ट्री API वापरणे (वर नमूद केलेले). त्यांना जोडले गेले उपयोजित पायाभूत सुविधांमध्ये वापरलेल्या प्रतिमांवर आधारित सूचीला अनुमती द्या, म्हणजे कुबर्नेट्स. नंतरच्यासाठी, Kubernetes API द्वारे सर्व उपयोजित संसाधनांमधून जाणे आणि मूल्यांची सूची मिळवणे पुरेसे होते. image.

अशा क्षुल्लक उपायाने सर्वात गंभीर समस्या (निकष # 1) बंद केली, परंतु साफसफाईची यंत्रणा सुधारण्यासाठी आमच्या प्रवासाची ही केवळ सुरुवात होती. पुढील - आणि बरेच मनोरंजक - पाऊल निर्णय होता Git इतिहासाशी प्रकाशित प्रतिमा लिंक करा.

टॅगिंग योजना

सुरुवातीला, आम्ही एक दृष्टीकोन निवडला ज्यामध्ये अंतिम प्रतिमेमध्ये साफसफाईसाठी आवश्यक माहिती संग्रहित केली पाहिजे आणि टॅगिंग योजनांच्या आसपास प्रक्रिया तयार केली. प्रतिमा प्रकाशित करताना, वापरकर्त्याने विशिष्ट टॅगिंग पर्याय निवडला (git-branch, git-commit किंवा git-tag) आणि योग्य मूल्य वापरले. सीआय सिस्टममध्ये, ही मूल्ये पर्यावरणीय चलांच्या आधारे स्वयंचलितपणे सेट केली गेली. खरं तर लक्ष्य प्रतिमा विशिष्ट गिट आदिमशी संबंधित होती, लेबल्समध्ये साफसफाईसाठी आवश्यक डेटा संचयित करणे.

या दृष्टिकोनाचा एक भाग म्हणून, धोरणांचा एक संच प्राप्त झाला ज्याने 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.

अंतिम अल्गोरिदम खालील चरणांवर उकळते:

• कंटेनर रेजिस्ट्रीमधून मॅनिफेस्ट मिळवणे.
• Kubernetes मध्ये वापरलेल्या प्रतिमा वगळणे, कारण आम्ही आधीच K8s API मतदान करून त्यांची पूर्व-निवड केली आहे.
• Git इतिहास स्कॅन करणे आणि निर्दिष्ट धोरणांनुसार प्रतिमा वगळणे.
• उर्वरित प्रतिमा काढून टाकत आहे.

आमच्या उदाहरणाकडे परत येताना, werf सह असे होते:

तथापि, जरी तुम्ही werf वापरत नसला तरीही, प्रगत प्रतिमा क्लीनअपसाठी एक समान दृष्टीकोन - एका अंमलबजावणीमध्ये किंवा दुसर्‍यामध्ये (इमेज टॅगिंगच्या पसंतीच्या दृष्टीकोनानुसार) - इतर सिस्टम/युटिलिटीजमध्ये लागू केला जाऊ शकतो. हे करण्यासाठी, उद्भवलेल्या समस्यांबद्दल जागरूक असणे आणि आपल्या स्टॅकमध्ये त्या संधी शोधणे पुरेसे आहे जे आपल्याला त्यांचे निराकरण सर्वात सहजतेने तयार करण्यास अनुमती देतात. आम्‍ही आशा करतो की आम्‍ही प्रवास केलेला मार्ग तुमच्‍या विशिष्‍ट केसकडे नवीन तपशील आणि विचारांसह पाहण्‍यास मदत करेल.

निष्कर्ष

• लवकरच किंवा नंतर, बहुतेक संघांना रेजिस्ट्री ओव्हरफ्लो समस्येचा सामना करावा लागतो.
• उपाय शोधताना, सर्वप्रथम, प्रतिमेच्या प्रासंगिकतेसाठी निकष निश्चित करणे आवश्यक आहे.
• लोकप्रिय कंटेनर रेजिस्ट्री सेवांद्वारे ऑफर केलेली साधने आपल्याला "बाहेरील जग" विचारात न घेणारी एक अतिशय सोपी साफसफाई आयोजित करण्याची परवानगी देतात: कुबर्नेट्समध्ये वापरल्या जाणार्‍या प्रतिमा आणि टीम वर्कफ्लोची वैशिष्ट्ये.
• लवचिक आणि कार्यक्षम अल्गोरिदममध्ये सीआय / सीडी प्रक्रियेची समज असणे आवश्यक आहे, केवळ डॉकर प्रतिमा डेटासह कार्य करत नाही.

PS

आमच्या ब्लॉगवर देखील वाचा:

• «वेर्फ बिल्डरमध्ये सामग्री-आधारित टॅगिंग: ते का आणि कसे कार्य करते?";
• «werf मध्ये 3-वे विलीनीकरण: हेल्मसह कुबर्नेट्सला “स्टिरॉइड्सवर” तैनात करा";
• «werf मधील मोनोरेपो आणि मल्टीरेपोसाठी समर्थन आणि डॉकर रजिस्ट्रीचा त्याच्याशी काय संबंध आहे";
• «werf 1.1 प्रकाशन: आज बिल्डर सुधारणा आणि भविष्यासाठी योजना».

स्त्रोत: www.habr.com