तपाईं अब नियमित डकरफाइल प्रयोग गरेर डकर छविहरू werf मा निर्माण गर्न सक्नुहुन्छ

कहिल्यै भन्दा ढिलो राम्रो। वा कसरी हामीले एप्लिकेसन छविहरू निर्माण गर्न नियमित डकरफाइलहरूको लागि समर्थन नगरेर लगभग गम्भीर गल्ती गर्यौं।

हामी बारेमा कुरा गर्नेछौं वाफ - GitOps उपयोगिता जुन कुनै पनि CI/CD प्रणालीसँग एकीकृत हुन्छ र सम्पूर्ण अनुप्रयोग जीवनचक्रको व्यवस्थापन प्रदान गर्दछ, अनुमति दिन्छ:

• चित्रहरू सङ्कलन र प्रकाशित,
• Kubernetes मा अनुप्रयोगहरू तैनाती गर्नुहोस्,
• विशेष नीतिहरू प्रयोग गरी प्रयोग नगरिएका छविहरू मेटाउनुहोस्।

परियोजनाको दर्शन भनेको एकल एकीकृत प्रणालीमा निम्न-स्तरका उपकरणहरू सङ्कलन गर्नु हो जसले DevOps इन्जिनियरहरूलाई अनुप्रयोगहरूमा नियन्त्रण दिन्छ। यदि सम्भव छ भने, अवस्थित उपयोगिताहरू (जस्तै हेल्म र डकर) प्रयोग गर्नुपर्छ। यदि त्यहाँ समस्याको समाधान छैन भने, हामी यसको लागि आवश्यक सबै कुरा सिर्जना र समर्थन गर्न सक्छौं।

पृष्ठभूमि: तपाईंको आफ्नै छवि कलेक्टर

यो werf मा छवि कलेक्टर संग के भयो: सामान्य Dockerfile हाम्रो लागि पर्याप्त थिएन। यदि तपाईंले परियोजनाको इतिहासमा द्रुत रूपमा हेर्नुभयो भने, यो समस्या पहिले नै werf को पहिलो संस्करणहरूमा देखा पर्‍यो (त्यसपछि अझै पनि dapp को रूपमा चिनिन्छ).

डकर छविहरूमा एप्लिकेसनहरू निर्माण गर्न उपकरण सिर्जना गर्दा, हामीले चाँडै महसुस गर्यौं कि डकरफाइल हाम्रो लागि केही विशेष कार्यहरूको लागि उपयुक्त थिएन:

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

आज हाम्रो कलेक्टरसँग अन्य धेरै सम्भावनाहरू छन्, तर यी प्रारम्भिक इच्छा र आग्रहहरू थिए।

सामान्यतया, दुई पटक सोचे बिना, हामीले प्रयोग गरेको प्रोग्रामिङ भाषाको साथ हामी आफैलाई सशस्त्र बनाउँछौं (तल हेर) र कार्यान्वयन गर्न बाटो हिर्काए आफ्नै DSL! उद्देश्यहरू अनुसार, यो चरणहरूमा विधानसभा प्रक्रिया वर्णन गर्न र फाइलहरूमा यी चरणहरूको निर्भरता निर्धारण गर्ने उद्देश्य थियो। र पूरक बनायो आफ्नै कलेक्टर, जसले DSL लाई अन्तिम गोलमा परिणत गर्‍यो - एक एकत्रित छवि। सुरुमा DSL रुबीमा थियो, तर जस्तै Golang मा संक्रमण - हाम्रो कलेक्टरको कन्फिगरेसन YAML फाइलमा वर्णन गर्न सुरु भयो।

रुबीमा ड्यापको लागि पुरानो कन्फिगरेसन

YAML मा werf को लागि हालको कन्फिगरेसन

समयसँगै कलेक्टरको संयन्त्र पनि परिवर्तन भयो । सुरुमा, हामीले हाम्रो कन्फिगरेसनबाट फ्लाइमा अस्थायी डकरफाइल उत्पन्न गर्यौं, र त्यसपछि हामीले अस्थायी कन्टेनरहरूमा असेंबली निर्देशनहरू चलाउन थाल्यौं र कमिट गर्यौं।

NB: यस समयमा, हाम्रो कलेक्टर, जसले आफ्नै कन्फिगरेसन (YAML मा) सँग काम गर्दछ र स्टेपल कलेक्टर भनिन्छ, पहिले नै एकदम शक्तिशाली उपकरणमा विकसित भएको छ। यसको विस्तृत विवरण छुट्टै लेखको योग्य छ, र आधारभूत विवरणहरू फेला पार्न सकिन्छ कागजात.

समस्याको चेतना

तर हामीले महसुस गर्यौं, र तुरुन्तै होइन, हामीले एउटा गल्ती गरेका थियौं: हामीले क्षमता थपेका छैनौं मानक Dockerfile मार्फत छविहरू निर्माण गर्नुहोस् र तिनीहरूलाई एउटै अन्त-देखि-अन्त अनुप्रयोग व्यवस्थापन पूर्वाधारमा एकीकृत गर्नुहोस् (अर्थात छविहरू सङ्कलन गर्नुहोस्, तिनीहरूलाई डिप्लोय गर्नुहोस् र सफा गर्नुहोस्)। Kubernetes मा तैनाती को लागी एक उपकरण बनाउन र Dockerfile समर्थन लागू नगर्ने कसरी सम्भव छ, अर्थात्। धेरैजसो परियोजनाहरूको लागि छविहरू वर्णन गर्ने मानक तरिका? ..

यो प्रश्नको जवाफ दिनुको सट्टा, हामी समाधान प्रस्ताव गर्दछौं। यदि तपाईंसँग पहिले नै डकरफाइल (वा डकरफाइलहरूको सेट) छ र 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 कन्फिगरेसन मार्फत। Dockerfile छवि कन्फिगरेसन को पूर्ण विवरण मा उपलब्ध छ कागजात पृष्ठ.

यसले कसरी काम गर्छ?

निर्माण प्रक्रियाको क्रममा, डकर प्रकार्यहरूमा स्थानीय तहहरूको मानक क्यास। यद्यपि, के महत्त्वपूर्ण छ त्यो werf पनि हो डकरफाइल कन्फिगरेसनलाई यसको पूर्वाधारमा एकीकृत गर्दछ। यसको मतलब के हो?

1. डकरफाइलबाट बनेको प्रत्येक छविमा एउटा चरण भनिन्छ dockerfile (Werf मा कुन चरणहरू छन् भन्ने बारे थप पढ्न सक्नुहुन्छ यहाँ).
2. स्टेजको लागि dockerfile werf ले हस्ताक्षर गणना गर्दछ जुन डकरफाइल कन्फिगरेसनको सामग्रीमा निर्भर गर्दछ। जब Dockerfile कन्फिगरेसन परिवर्तन हुन्छ, चरण हस्ताक्षर परिवर्तन हुन्छ dockerfile र werf ले नयाँ Dockerfile कन्फिगरेसनको साथ यस चरणको पुन: निर्माण प्रारम्भ गर्दछ। यदि हस्ताक्षर परिवर्तन भएन भने, werf ले क्यासबाट छवि लिन्छ (werf मा हस्ताक्षर को प्रयोग बारे थप विवरण मा वर्णन गरिएको थियो यो रिपोर्ट).
3. अर्को, संकलित छविहरू आदेशको साथ प्रकाशित गर्न सकिन्छ werf publish (वा werf build-and-publish) र Kubernetes मा तैनाती को लागी प्रयोग गर्नुहोस्। डकर रजिस्ट्रीमा प्रकाशित छविहरू मानक werf सफाई उपकरणहरू प्रयोग गरी सफा गरिनेछ, अर्थात्। पुराना तस्बिरहरू (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 प्रयोग गरेर निर्माणहरू (अर्थात्, कानिकोमा गरिएको जस्तै Kubernetes भित्र धावकहरूमा निर्माणहरू) को लागि हाम्रो अनुकूलन स्टेपल बिल्डरसँग डकरफाइल समर्थन विकास गर्ने योजना छ।

त्यसोभए, यदि तपाईंसँग अचानक केही डकरफाइलहरू वरिपरि छन् ... प्रयास गर्नुहोस् वाफ!

PS विषय मा कागजात को सूची

• द्रुत सुरुवातको लागि गाइडहरू;
• डकरफाइल बिल्डर कन्फिगरेसनहरू;
• स्टेज उपकरण werf मा;
• छवि प्रकाशन प्रक्रिया;
• Kubernetes तैनाती प्रक्रिया संग एकीकरण;
• सफाई प्रक्रिया;
• Dockerfile को एक विकल्प को रूप मा Stapel बिल्डर.

हाम्रो ब्लगमा पनि पढ्नुहोस्: "werf - Kubernetes मा CI / CD को लागि हाम्रो उपकरण (अवलोकन र भिडियो रिपोर्ट)"।

स्रोत: www.habr.com