तुम्ही आता नियमित Dockerfile वापरून werf मध्ये डॉकर प्रतिमा तयार करू शकता

कधीही न येण्यापेक्षा उशीरा चांगले. किंवा अॅप्लिकेशन प्रतिमा तयार करण्यासाठी नियमित डॉकरफायल्ससाठी समर्थन नसल्यामुळे आम्ही जवळजवळ गंभीर चूक कशी केली.

आम्ही याबद्दल बोलू werf — GitOps युटिलिटी जी कोणत्याही CI/CD सिस्टीमसह समाकलित होते आणि संपूर्ण ऍप्लिकेशन लाइफसायकलचे व्यवस्थापन प्रदान करते, परवानगी देते:

• प्रतिमा गोळा करा आणि प्रकाशित करा,
• Kubernetes मध्ये अनुप्रयोग तैनात करा,
• विशेष धोरणे वापरून न वापरलेल्या प्रतिमा हटवा.

डेव्हऑप्स अभियंत्यांना ऍप्लिकेशन्सवर नियंत्रण देणारी एकल युनिफाइड सिस्टममध्ये निम्न-स्तरीय साधने एकत्रित करणे हे प्रकल्पाचे तत्त्वज्ञान आहे. शक्य असल्यास, विद्यमान उपयुक्तता (जसे की हेल्म आणि डॉकर) वापरल्या पाहिजेत. जर एखाद्या समस्येवर उपाय नसेल, तर आम्ही यासाठी आवश्यक असलेली प्रत्येक गोष्ट तयार करू आणि समर्थन देऊ शकतो.

पार्श्वभूमी: तुमचा स्वतःचा इमेज कलेक्टर

werf मधील इमेज कलेक्टरच्या बाबतीत असेच घडले: नेहमीची डॉकरफाइल आमच्यासाठी पुरेशी नव्हती. जर आपण प्रकल्पाच्या इतिहासावर एक द्रुत कटाक्ष टाकला तर, ही समस्या आधीच werf च्या पहिल्या आवृत्त्यांमध्ये दिसून आली (मग अजूनही dapp म्हणून ओळखले जाते).

डॉकर प्रतिमांमध्ये अनुप्रयोग तयार करण्यासाठी एक साधन तयार करताना, आम्हाला त्वरीत लक्षात आले की डॉकरफाइल काही विशिष्ट कार्यांसाठी आमच्यासाठी योग्य नाही:

1. खालील मानक योजनेनुसार ठराविक लहान वेब अनुप्रयोग तयार करण्याची आवश्यकता आहे:
   • सिस्टम-व्यापी अनुप्रयोग अवलंबित्व स्थापित करा,
   • अनुप्रयोग अवलंबित्व लायब्ररींचे बंडल स्थापित करा,
   • मालमत्ता गोळा करणे,
   • आणि सर्वात महत्त्वाचे म्हणजे, इमेजमधील कोड जलद आणि कार्यक्षमतेने अपडेट करा.
2. जेव्हा प्रोजेक्ट फाइल्समध्ये बदल केले जातात, तेव्हा बिल्डरने बदललेल्या फाइल्सवर पॅच लागू करून एक नवीन स्तर त्वरित तयार केला पाहिजे.
3. जर काही फायली बदलल्या असतील, तर संबंधित अवलंबित स्टेजची पुनर्बांधणी करणे आवश्यक आहे.

आज आमच्या कलेक्टरकडे इतर अनेक शक्यता आहेत, पण या सुरुवातीच्या इच्छा आणि आग्रह होत्या.

सर्वसाधारणपणे, दोनदा विचार न करता, आम्ही वापरलेल्या प्रोग्रामिंग भाषेसह आम्ही स्वतःला सशस्त्र केले (खाली पहा) आणि अंमलबजावणी करण्यासाठी रस्ता दाबा स्वतःचे डीएसएल! उद्दिष्टांच्या अनुषंगाने, असेंब्ली प्रक्रियेचे टप्प्याटप्प्याने वर्णन करणे आणि फायलींवर या टप्प्यांचे अवलंबित्व निश्चित करणे हे होते. आणि त्याला पूरक स्वतःचे कलेक्टर, ज्याने DSL ला अंतिम लक्ष्यात बदलले - एक एकत्रित प्रतिमा. प्रथम डीएसएल रुबी मध्ये होते, पण म्हणून गोलंग मध्ये संक्रमण — आमच्या कलेक्टरचे कॉन्फिगरेशन YAML फाइलमध्ये वर्णन केले जाऊ लागले.

रुबी मध्ये dapp साठी जुनी कॉन्फिगरेशन

YAML वर werf साठी वर्तमान कॉन्फिगरेशन

काळानुसार जिल्हाधिकाऱ्यांची यंत्रणाही बदलत गेली. सुरुवातीला, आम्ही आमच्या कॉन्फिगरेशनमधून फ्लायवर तात्पुरती डॉकरफाइल व्युत्पन्न केली आणि नंतर आम्ही तात्पुरत्या कंटेनरमध्ये असेंब्ली सूचना चालवण्यास सुरुवात केली आणि कमिट केले.

NB: याक्षणी, आमचे कलेक्टर, जे स्वतःच्या कॉन्फिगरेशनसह कार्य करते (YAML मध्ये) आणि ज्याला स्टॅपल कलेक्टर म्हणतात, ते आधीच बर्‍यापैकी शक्तिशाली साधन म्हणून विकसित झाले आहे. त्याचे तपशीलवार वर्णन स्वतंत्र लेखास पात्र आहे आणि मूलभूत तपशील यामध्ये आढळू शकतात दस्तऐवजीकरण.

समस्येची जाणीव

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

या प्रश्नाचे उत्तर देण्याऐवजी, आम्ही एक उपाय ऑफर करतो. तुमच्याकडे आधीपासून डॉकरफाइल (किंवा डॉकरफाईल्सचा संच) असेल आणि तुम्हाला werf वापरायचे असेल तर?

NB: तसे, तुम्हाला werf का वापरायचे आहे? मुख्य वैशिष्ट्ये खालीलप्रमाणे उकळतात:

• प्रतिमा साफसफाईसह संपूर्ण अनुप्रयोग व्यवस्थापन चक्र;
• एकाच कॉन्फिगरेशनमधून एकाच वेळी अनेक प्रतिमांचे असेंब्ली व्यवस्थापित करण्याची क्षमता;
• हेल्म-सुसंगत चार्टसाठी सुधारित उपयोजन प्रक्रिया.

त्यांची अधिक संपूर्ण यादी येथे आढळू शकते प्रकल्प पृष्ठ.

म्हणून, जर पूर्वी आम्ही आमच्या कॉन्फिगरेशनमध्ये डॉकरफाइल पुन्हा लिहिण्याची ऑफर दिली असती, तर आता आम्ही आनंदाने म्हणू: "वेर्फला तुमची डॉकरफाइल तयार करू द्या!"

कसे वापरावे?

या वैशिष्ट्याची संपूर्ण अंमलबजावणी प्रकाशनात दिसून आली werf v1.0.3-beta.1. सामान्य तत्त्व सोपे आहे: वापरकर्ता werf कॉन्फिगरेशनमध्ये विद्यमान डॉकरफाइलचा मार्ग निर्दिष्ट करतो आणि नंतर कमांड चालवतो. werf build... आणि तेच आहे - werf प्रतिमा एकत्र करेल. एक अमूर्त उदाहरण पाहू.

पुढची घोषणा करूया Dockerfile प्रकल्प रूट मध्ये:

FROM ubuntu:18.04
RUN echo Building ...

आणि आम्ही जाहीर करू werf.yamlजे हे वापरते Dockerfile:

configVersion: 1
project: dockerfile-example
---
image: ~
dockerfile: ./Dockerfile

सर्व! बाकी चालवा werf build:

याव्यतिरिक्त, आपण खालील घोषणा करू शकता werf.yaml वेगवेगळ्या डॉकरफाईल्समधून एकाच वेळी अनेक प्रतिमा तयार करण्यासाठी:

configVersion: 1
project: dockerfile-example
---
image: backend
dockerfile: ./dockerfiles/Dockerfile-backend
---
image: frontend
dockerfile: ./dockerfiles/Dockerfile-frontend

शेवटी, ते अतिरिक्त बिल्ड पॅरामीटर्स पास करण्यास देखील समर्थन देते, जसे की --build-arg и --add-host - werf कॉन्फिगरेशनद्वारे. डॉकरफाइल इमेज कॉन्फिगरेशनचे संपूर्ण वर्णन येथे उपलब्ध आहे दस्तऐवजीकरण पृष्ठ.

ते कसे कार्य करते?

बिल्ड प्रक्रियेदरम्यान, डॉकर फंक्शनमधील स्थानिक स्तरांचे मानक कॅशे. तथापि, काय महत्वाचे आहे ते werf देखील आहे डॉकरफाइल कॉन्फिगरेशन त्याच्या पायाभूत सुविधांमध्ये समाकलित करते. याचा अर्थ काय?

1. डॉकरफाइलमधून तयार केलेल्या प्रत्येक प्रतिमेमध्ये एक टप्पा असतो ज्याला म्हणतात dockerfile (Werf मध्ये कोणते टप्पे आहेत याबद्दल आपण अधिक वाचू शकता येथे).
2. स्टेज साठी dockerfile werf स्वाक्षरीची गणना करते जी डॉकरफाइल कॉन्फिगरेशनच्या सामग्रीवर अवलंबून असते. जेव्हा डॉकरफाइल कॉन्फिगरेशन बदलते, तेव्हा स्टेज स्वाक्षरी बदलते dockerfile आणि werf नवीन डॉकरफाइल कॉन्फिगरेशनसह या स्टेजची पुनर्बांधणी सुरू करते. जर स्वाक्षरी बदलली नाही, तर werf कॅशेमधून प्रतिमा घेते (werf मध्ये स्वाक्षरी वापरण्याबद्दल अधिक तपशीलांमध्ये वर्णन केले आहे हा अहवाल).
3. पुढे, संकलित प्रतिमा कमांडसह प्रकाशित केल्या जाऊ शकतात werf publish (किंवा werf build-and-publish) आणि कुबर्नेट्समध्ये तैनात करण्यासाठी वापरा. डॉकर रेजिस्ट्रीमध्ये प्रकाशित प्रतिमा मानक वेर्फ क्लीनअप टूल्स वापरून साफ ​​केल्या जातील, उदा. जुन्या प्रतिमा (N दिवसांपेक्षा जुन्या), अस्तित्वात नसलेल्या Git शाखांशी संबंधित प्रतिमा आणि इतर धोरणे आपोआप साफ केली जातील.

येथे वर्णन केलेल्या मुद्द्यांबद्दल अधिक तपशील दस्तऐवजीकरणामध्ये आढळू शकतात:

• प्रकाशन प्रक्रिया;
• Kubernetes उपयोजन प्रक्रियेसह एकत्रीकरण;
• स्वच्छता प्रक्रिया.

नोट्स आणि खबरदारी

1. बाह्य URL ADD मध्ये समर्थित नाही

सध्या निर्देशामध्ये बाह्य URL वापरण्यास सपोर्ट नाही ADD. निर्दिष्ट URL वरील संसाधन बदलल्यावर Werf पुनर्बांधणी सुरू करणार नाही. आम्ही लवकरच हे वैशिष्ट्य जोडण्याची योजना आखत आहोत.

2. तुम्ही इमेजमध्ये .git जोडू शकत नाही

सर्वसाधारणपणे, निर्देशिका जोडणे .git प्रतिमेमध्ये - एक दुष्ट वाईट प्रथा आणि येथे का आहे:

1. तर .git अंतिम प्रतिमेत राहते, हे तत्त्वांचे उल्लंघन करते 12 घटक अॅप: अंतिम प्रतिमा एकाच कमिटशी जोडलेली असणे आवश्यक असल्याने, ते करणे शक्य नसावे git checkout अनियंत्रित वचनबद्ध.
2. .git प्रतिमेचा आकार वाढवते (मोठ्या फाइल्स एकदा त्यात जोडल्या गेल्या आणि नंतर हटवल्या गेल्यामुळे रेपॉजिटरी मोठी असू शकते). केवळ विशिष्ट कमिटशी संबंधित वर्क-ट्रीचा आकार Git मधील ऑपरेशन्सच्या इतिहासावर अवलंबून नाही. या प्रकरणात, जोडणे आणि त्यानंतरचे काढणे .git अंतिम प्रतिमेवरून कार्य करणार नाही: प्रतिमा अद्याप एक अतिरिक्त स्तर प्राप्त करेल - डॉकर अशा प्रकारे कार्य करते.
3. डॉकर अनावश्यक पुनर्बांधणी सुरू करू शकतो, जरी समान कमिट बांधले जात असले तरी, परंतु वेगवेगळ्या वर्क-ट्रीजमधून. उदाहरणार्थ, GitLab मध्ये स्वतंत्र क्लोन डिरेक्ट्री तयार करते /home/gitlab-runner/builds/HASH/[0-N]/yourproject जेव्हा समांतर असेंब्ली सक्षम केली जाते. अतिरिक्त reassembly मुळे होईल की निर्देशिका .git समान कमिट बांधले असले तरीही, समान रेपॉजिटरीच्या वेगवेगळ्या क्लोन आवृत्त्यांमध्ये भिन्न आहे.

werf वापरताना शेवटच्या बिंदूचे परिणाम देखील होतात. Werf ला काही कमांड चालवताना अंगभूत कॅशे उपस्थित असणे आवश्यक आहे (उदा. werf deploy). जेव्हा हे आदेश चालतात, तेव्हा werf मध्ये निर्दिष्ट केलेल्या प्रतिमांसाठी स्टेज स्वाक्षरीची गणना करते werf.yaml, आणि ते असेंब्ली कॅशेमध्ये असणे आवश्यक आहे - अन्यथा कमांड कार्य करणे सुरू ठेवण्यास सक्षम राहणार नाही. जर स्टेज स्वाक्षरी सामग्रीवर अवलंबून असेल .git, नंतर आम्हाला एक कॅशे मिळेल जो असंबद्ध फाइल्समधील बदलांसाठी अस्थिर आहे आणि werf अशा उपेक्षा माफ करू शकणार नाही (अधिक तपशीलांसाठी, पहा दस्तऐवजीकरण).

सर्वसाधारणपणे फक्त काही आवश्यक फाइल्स जोडणे सूचनांद्वारे ADD कोणत्याही परिस्थितीत लिखितची कार्यक्षमता आणि विश्वासार्हता वाढते Dockerfile, आणि यासाठी गोळा केलेल्या कॅशेची स्थिरता देखील सुधारते Dockerfile, Git मधील असंबद्ध बदलांसाठी.

परिणाम

विशिष्ट गरजांसाठी आमच्या स्वतःच्या बिल्डरला लिहिण्याचा आमचा प्रारंभिक मार्ग कठोर, प्रामाणिक आणि सरळ होता: मानक डॉकरफाइलच्या शीर्षस्थानी क्रॅच वापरण्याऐवजी, आम्ही सानुकूल वाक्यरचनासह आमचे निराकरण लिहिले. आणि याचे त्याचे फायदे होते: स्टेपल कलेक्टर त्याच्या कार्याचा उत्तम प्रकारे सामना करतो.

तथापि, आमचा स्वतःचा बिल्डर लिहिण्याच्या प्रक्रियेत, आम्ही विद्यमान डॉकरफाईल्ससाठी समर्थन गमावले. हा दोष आता दुरुस्त करण्यात आला आहे आणि भविष्यात आम्ही आमच्या कस्टम स्टेपल बिल्डरसोबत वितरित बिल्डसाठी आणि Kubernetes वापरून बिल्डसाठी (म्हणजे कानिकोमध्ये केल्याप्रमाणे कुबर्नेट्सच्या आत धावणाऱ्यांवर बिल्ड) डॉकरफाइल सपोर्ट विकसित करण्याची योजना आखत आहोत.

तर, जर तुमच्याकडे अचानक काही डॉकरफाईल्स पडल्या असतील तर... हे करून पहा werf!

PS विषयावरील कागदपत्रांची यादी

• जलद सुरुवात करण्यासाठी मार्गदर्शक;
• डॉकरफाइल बिल्डर कॉन्फिगरेशन;
• werf मध्ये स्टेज डिव्हाइस;
• प्रतिमा प्रकाशन प्रक्रिया;
• Kubernetes उपयोजन प्रक्रियेसह एकत्रीकरण;
• स्वच्छता प्रक्रिया;
• डॉकरफाइलला पर्याय म्हणून स्टॅपल बिल्डर.

आमच्या ब्लॉगमध्ये देखील वाचा: "werf - Kubernetes मधील CI/CD साठी आमचे साधन (विहंगावलोकन आणि व्हिडिओ अहवाल)».

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