GitOps: पुल र पुश विधिहरूको तुलना

नोट। अनुवाद।: Kubernetes समुदायमा, GitOps भनिने चलनले स्पष्ट लोकप्रियता पाइरहेको छ, हामीले व्यक्तिगत रूपमा देख्यौं, भ्रमण गर्दै KubeCon Europe 2019। यो शब्द अपेक्षाकृत भर्खरको थियो आविष्कार गरे Weaveworks को प्रमुख द्वारा - एलेक्सिस रिचर्डसन - र यसको मतलब विकासकर्ताहरूलाई परिचित उपकरणहरूको प्रयोग (मुख्य रूपमा Git, त्यसैले नाम) परिचालन समस्याहरू समाधान गर्न। विशेष गरी, हामी Kubernetes को सञ्चालनको बारेमा कुरा गर्दैछौं यसको कन्फिगरेसनहरू Git मा भण्डारण गरेर र स्वचालित रूपमा क्लस्टरमा परिवर्तनहरू रोल आउट गरेर। Matthias Jg यस लेखमा यस रोलआउटको लागि दुई दृष्टिकोणहरूको बारेमा कुरा गर्दछ।

गत वर्ष (वास्तवमा, औपचारिक रूपमा यो अगस्त 2017 मा भयो - लगभग अनुवाद।) Kubernetes मा अनुप्रयोगहरू तैनाती गर्न नयाँ दृष्टिकोण छ। यसलाई GitOps भनिन्छ, र यो आधारभूत विचारमा आधारित छ कि डिप्लोयमेन्ट संस्करणहरू Git भण्डारको सुरक्षित वातावरणमा ट्र्याक गरिन्छ।

यस दृष्टिकोणको मुख्य फाइदाहरू निम्नानुसार छन्::

1. परिनियोजन संस्करण र परिवर्तन इतिहास। सम्पूर्ण क्लस्टरको अवस्था Git भण्डारमा भण्डार गरिएको छ, र तैनातीहरू केवल कमिटहरू मार्फत अद्यावधिक हुन्छन्। थप रूपमा, सबै परिवर्तनहरू प्रतिबद्ध इतिहास प्रयोग गरेर ट्र्याक गर्न सकिन्छ।
2. परिचित Git आदेशहरू प्रयोग गरेर रोलब्याकहरू। सरल git reset तपाईंलाई परिनियोजनमा परिवर्तनहरू रिसेट गर्न अनुमति दिन्छ; विगतका राज्यहरू सधैं उपलब्ध छन्।
3. तयार पहुँच नियन्त्रण। सामान्यतया, एक Git प्रणालीमा धेरै संवेदनशील डेटा हुन्छ, त्यसैले धेरै कम्पनीहरूले यसलाई सुरक्षित गर्न विशेष ध्यान दिन्छन्। तदनुसार, यो सुरक्षा तैनाती संग सञ्चालनमा पनि लागू हुन्छ।
4. परिनियोजनका लागि नीतिहरू। धेरै जसो Git प्रणालीहरूले नेटिभ रूपमा शाखा-द्वारा-शाखा नीतिहरूलाई समर्थन गर्दछ - उदाहरणका लागि, केवल पुल अनुरोधहरूले मास्टर अपडेट गर्न सक्छ, र परिवर्तनहरू समीक्षा गरी अर्को टोली सदस्यद्वारा स्वीकार गर्नुपर्छ। पहुँच नियन्त्रणको रूपमा, एउटै नीतिहरू तैनाती अद्यावधिकहरूमा लागू हुन्छन्।

तपाईले देख्न सक्नुहुन्छ, GitOps विधिमा धेरै फाइदाहरू छन्। गत वर्षमा, दुई दृष्टिकोणले विशेष लोकप्रियता प्राप्त गरेको छ। एउटा पुश आधारित छ, अर्को पुल आधारित छ। हामीले तिनीहरूलाई हेर्नु अघि, पहिले कुबर्नेट्स डिप्लोइमेन्टहरू कस्तो देखिन्छ भनेर हेरौं।

परिनियोजन विधिहरू

हालैका वर्षहरूमा, तैनातीका लागि विभिन्न विधिहरू र उपकरणहरू Kubernetes मा स्थापित भएका छन्:

1. नेटिभ Kubernetes/Kustomize टेम्प्लेटहरूमा आधारित। Kubernetes मा अनुप्रयोगहरू डिप्लोइ गर्ने यो सबैभन्दा सजिलो तरिका हो। विकासकर्ताले आधारभूत YAML फाइलहरू सिर्जना गर्दछ र तिनीहरूलाई लागू गर्दछ। उही टेम्प्लेटहरू लगातार पुन: लेख्नबाट छुटकारा पाउन, Kustomize विकास गरिएको थियो (यसले Kubernetes टेम्प्लेटहरूलाई मोड्युलहरूमा परिणत गर्दछ)। नोट। अनुवाद।: Kustomize को साथ kubectl मा एकीकृत गरिएको छ Kubernetes 1.14 को रिलीज.
2. हेलम चार्टहरू। हेल्म चार्टहरूले तपाईंलाई टेम्प्लेटहरू, इनिट कन्टेनरहरू, साइडकारहरू, इत्यादिको सेटहरू सिर्जना गर्न अनुमति दिन्छ, जुन टेम्प्लेट-आधारित दृष्टिकोणमा भन्दा बढी लचिलो अनुकूलन विकल्पहरूसँग अनुप्रयोगहरू प्रयोग गर्न प्रयोग गरिन्छ। यो विधि टेम्प्लेट गरिएको YAML फाइलहरूमा आधारित छ। हेल्मले तिनीहरूलाई विभिन्न प्यारामिटरहरू भर्छ र त्यसपछि टिलरमा पठाउँछ, क्लस्टर कम्पोनेन्ट जसले तिनीहरूलाई क्लस्टरमा डिप्लोय गर्छ र अद्यावधिक र रोलब्याकहरूलाई अनुमति दिन्छ। महत्त्वपूर्ण कुरा यो हो कि हेल्मले अनिवार्य रूपमा टेम्प्लेटहरूमा वांछित मानहरू सम्मिलित गर्दछ र त्यसपछि तिनीहरूलाई परम्परागत दृष्टिकोणमा गरिएझैं लागू गर्दछ। (यसले कसरी काम गर्छ र तपाइँ यसलाई हाम्रो मा कसरी प्रयोग गर्न सक्नुहुन्छ भन्ने बारे थप पढ्नुहोस् हेलम द्वारा लेख - लगभग। अनुवाद।)। त्यहाँ कार्यहरूको विस्तृत दायरा समेट्ने विभिन्न प्रकारका तयार-निर्मित हेल्म चार्टहरू छन्।
3. वैकल्पिक उपकरणहरू। त्यहाँ धेरै वैकल्पिक उपकरणहरू छन्। तिनीहरू सबैमा के समान छ कि तिनीहरूले केही टेम्प्लेट फाइलहरू Kubernetes-पढ्न योग्य YAML फाइलहरूमा बदल्छन् र त्यसपछि तिनीहरूलाई प्रयोग गर्छन्।

हाम्रो काममा, हामी महत्त्वपूर्ण उपकरणहरूको लागि निरन्तर हेल्म चार्टहरू प्रयोग गर्दछौं (किनकि तिनीहरूसँग धेरै चीजहरू पहिले नै तयार छन्, जसले जीवनलाई धेरै सजिलो बनाउँदछ) र हाम्रा आफ्नै अनुप्रयोगहरू प्रयोग गर्नका लागि "शुद्ध" Kubernetes YAML फाइलहरू।

तान्नुहोस् र धकेल्नुहोस्

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

एनबी! GitOps प्रयोग गर्ने सबै फाइदाहरू दुबै दृष्टिकोणहरूको लागि समान रहन्छ।

पुल आधारित दृष्टिकोण

पुल दृष्टिकोण यस तथ्यमा आधारित छ कि सबै परिवर्तनहरू क्लस्टर भित्रबाट लागू हुन्छन्। त्यहाँ क्लस्टर भित्र एक अपरेटर छ जसले नियमित रूपमा सम्बन्धित Git र डकर रजिस्ट्री भण्डारहरू जाँच गर्दछ। यदि तिनीहरूमा कुनै परिवर्तन हुन्छ भने, क्लस्टरको स्थिति आन्तरिक रूपमा अद्यावधिक हुन्छ। यो प्रक्रिया सामान्यतया धेरै सुरक्षित मानिन्छ, किनकि कुनै पनि बाह्य ग्राहकको क्लस्टर प्रशासक अधिकारहरूमा पहुँच छैन।

प्रो:

1. कुनै पनि बाह्य ग्राहकसँग क्लस्टरमा परिवर्तन गर्ने अधिकार छैन; सबै अद्यावधिकहरू भित्रबाट रोल आउट हुन्छन्।
2. केही उपकरणहरूले तपाईंलाई हेलम चार्ट अद्यावधिकहरू सिङ्क्रोनाइज गर्न र क्लस्टरमा लिङ्क गर्न अनुमति दिन्छ।
3. डकर रजिस्ट्री नयाँ संस्करणहरूको लागि स्क्यान गर्न सकिन्छ। यदि नयाँ छवि उपलब्ध छ भने, Git भण्डार र डिप्लोइमेन्ट नयाँ संस्करणमा अद्यावधिक गरिन्छ।
4. पुल उपकरणहरू विभिन्न Git भण्डारहरू र अनुमतिहरूसँग विभिन्न नेमस्पेसहरूमा वितरण गर्न सकिन्छ। यसका लागि धन्यवाद, बहुमुखी मोडेल प्रयोग गर्न सकिन्छ। उदाहरणका लागि, टोली A ले नेमस्पेस A प्रयोग गर्न सक्छ, टोली B ले नेमस्पेस B प्रयोग गर्न सक्छ, र पूर्वाधार टोलीले ग्लोबल स्पेस प्रयोग गर्न सक्छ।
5. नियमको रूपमा, उपकरणहरू धेरै हल्का छन्।
6. अपरेटर जस्ता उपकरणहरूसँग संयुक्त बिटनामी सील गरिएको रहस्य, गोप्यहरू एक Git भण्डारमा इन्क्रिप्टेड भण्डारण गर्न सकिन्छ र क्लस्टर भित्र पुन: प्राप्त गर्न सकिन्छ।
7. क्लस्टर भित्र डिप्लोइमेन्ट हुने भएकोले CD पाइपलाइनहरूमा कुनै जडान छैन।

Минусы:

1. हेल्म चार्टहरूबाट डिप्लोयमेन्ट गोप्यहरू प्रबन्ध गर्न नियमित व्यक्तिहरू भन्दा बढी गाह्रो छ, किनकि तिनीहरू पहिले सील गरिएको गोप्य रूपमा, त्यसपछि आन्तरिक अपरेटरद्वारा डिक्रिप्ट गरिएको, र त्यसपछि मात्र तिनीहरू पुल उपकरणमा उपलब्ध हुन्छन्। त्यसोभए तपाईले हेल्ममा रिलिज चलाउन सक्नुहुन्छ पहिले नै तैनात गोप्यहरूमा मानहरूसँग। सबै भन्दा सजिलो तरीका भनेको डिप्लोयमेन्टका लागि प्रयोग गरिएका सबै हेल्म मानहरूसँग गोप्य सिर्जना गर्नु हो, यसलाई डिक्रिप्ट गर्नुहोस् र यसलाई Git मा कमिट गर्नुहोस्।
2. जब तपाइँ एक पुल दृष्टिकोण लिनुहुन्छ, तपाइँ उपकरणहरू तान्नु हुन्छ। यसले क्लस्टरमा डिप्लोइमेन्ट प्रक्रिया अनुकूलन गर्ने क्षमतालाई सीमित गर्छ। उदाहरण को लागी, Kustomize यस तथ्य द्वारा जटिल छ कि यो अन्तिम टेम्प्लेटहरू Git मा प्रतिबद्ध हुनु अघि चल्नु पर्छ। म तपाई स्ट्यान्डअलोन उपकरणहरू प्रयोग गर्न सक्नुहुन्न भनी होइन, तर तिनीहरू तपाईंको तैनाती प्रक्रियामा एकीकृत गर्न अझ गाह्रो छन्।

पुश आधारित दृष्टिकोण

पुश दृष्टिकोणमा, बाह्य प्रणाली (मुख्यतया सीडी पाइपलाइनहरू) ले Git भण्डारमा प्रतिबद्धता वा अघिल्लो CI पाइपलाइन सफल भए पछि क्लस्टरमा डिप्लोइमेन्टहरू सुरू गर्दछ। यस दृष्टिकोणमा, प्रणालीको क्लस्टरमा पहुँच छ।

Плюсы:

1. सुरक्षा Git भण्डार र निर्माण पाइपलाइन द्वारा निर्धारण गरिन्छ।
2. हेल्म चार्टहरू प्रयोग गर्न सजिलो छ र हेल्म प्लगइनहरूलाई समर्थन गर्दछ।
3. गोप्यहरू प्रबन्ध गर्न सजिलो छ किनभने गोप्यहरू पाइपलाइनहरूमा प्रयोग गर्न सकिन्छ र Git मा इन्क्रिप्टेड भण्डारण गर्न सकिन्छ (प्रयोगकर्ताको प्राथमिकताहरूमा निर्भर गर्दछ)।
4. कुनै पनि प्रकारको प्रयोग गर्न सकिने हुनाले कुनै खास उपकरणसँग कुनै जडान छैन।
5. कन्टेनर संस्करण अद्यावधिकहरू निर्माण पाइपलाइन द्वारा सुरु गर्न सकिन्छ।

Минусы:

1. क्लस्टर पहुँच डाटा निर्माण प्रणाली भित्र छ।
2. डिप्लोयमेन्ट कन्टेनरहरू अपडेट गर्न अझै पनि पुल प्रक्रियाको साथ सजिलो छ।
3. CD प्रणालीमा भारी निर्भरता, हामीलाई चाहिने पाइपलाइनहरू मूल रूपमा Gitlab धावकहरूको लागि लेखिएको हुन सक्छ, र त्यसपछि टोलीले Azure DevOps वा Jenkins मा जाने निर्णय गर्छ... र ठूलो संख्यामा निर्माण पाइपलाइनहरू स्थानान्तरण गर्नुपर्नेछ।

परिणाम: धक्का वा तान्नुहोस्?

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

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

त्यसोभए, यदि पुल दृष्टिकोण अधिक श्रम गहन छ र सुरक्षा लाभ प्रदान गर्दैन भने, यो केवल धक्का दृष्टिकोण प्रयोग गर्न तार्किक छैन? तर कसैले तर्क गर्न सक्छ कि पुश दृष्टिकोणमा तपाइँ सीडी प्रणालीमा धेरै बाँधिएको छ र, सायद, यो नगर्नु राम्रो छ ताकि भविष्यमा माइग्रेसनहरू गर्न सजिलो हुनेछ।

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

मलाई आशा छ कि यस विषयमा मेरो अनुभवले तपाइँलाई तपाइँको प्रयोगको प्रकारको लागि कुन विधि बढी उपयुक्त छ भनेर निर्णय गर्न मद्दत गर्नेछ, र म तपाइँको राय सुन्न पाउँदा खुसी हुनेछु।

अनुवादकबाट PS नोट

पुल मोडेलको नकारात्मक पक्ष यो हो कि Git मा रेन्डर गरिएको प्रकटीकरणहरू राख्न गाह्रो छ, तर त्यहाँ कुनै नकारात्मक पक्ष छैन कि पुल मोडेलमा सीडी पाइपलाइन रोलआउटबाट अलग रहन्छ र अनिवार्य रूपमा एक श्रेणी पाइपलाइन बन्छ। निरन्तर लागू गर्नुहोस्। तसर्थ, सबै डिप्लोयमेन्टहरूबाट तिनीहरूको स्थिति सङ्कलन गर्न र कुनै न कुनै रूपमा लग/स्थितिमा पहुँच प्रदान गर्न अझ बढी प्रयासहरू आवश्यक पर्नेछ, अधिमानतः सीडी प्रणालीको सन्दर्भमा।

यस अर्थमा, पुश मोडेलले हामीलाई रोलआउटको कम्तिमा केही ग्यारेन्टीहरू प्रदान गर्न अनुमति दिन्छ, किनभने पाइपलाइनको जीवनकाल रोलआउटको जीवनकाल बराबर बनाउन सकिन्छ।

हामीले दुबै मोडेलहरू प्रयास गर्यौं र लेखको लेखकको रूपमा एउटै निष्कर्षमा पुग्यौं:

1. पुल मोडेल हाम्रो लागि ठूलो संख्यामा क्लस्टरहरूमा प्रणाली घटकहरूको अद्यावधिकहरू व्यवस्थित गर्न उपयुक्त छ (हेर्नुहोस्। addon-operator को बारेमा लेख).
2. GitLab CI मा आधारित पुश मोडेल हेल्म चार्टहरू प्रयोग गरेर अनुप्रयोगहरू रोल आउट गर्नको लागि राम्रोसँग उपयुक्त छ। एकै समयमा, पाइपलाइनहरू भित्र तैनातीहरूको रोलआउट उपकरण प्रयोग गरेर निगरानी गरिन्छ वाफ। खैर, हाम्रो यस परियोजनाको सन्दर्भमा, हामीले KubeCon Europe'19 मा हाम्रो स्ट्यान्डमा DevOps ईन्जिनियरहरूको दबाब समस्याहरूको बारेमा छलफल गर्दा हामीले निरन्तर "GitOps" सुन्यौं।

अनुवादकबाट PPS

हाम्रो ब्लगमा पनि पढ्नुहोस्:

• «Kubernetes सुझाव र युक्तिहरू: हेल्म 2 व्यवस्थापनमा क्लस्टरमा चलिरहेको स्रोतहरू स्थानान्तरण»;
• «Kubernetes स्रोतहरु को निगरानी को लागी kubedog पुस्तकालय को परिचय»;
• «Kubernetes को विस्तार र पूरक (अवलोकन र भिडियो रिपोर्ट)»;
• «GitLab CI मा अनुकूलन कार्यप्रवाहहरू सिर्जना गर्नका लागि सुझावहरू"।

दर्ता भएका प्रयोगकर्ताहरूले मात्र सर्वेक्षणमा भाग लिन सक्छन्। साइन इन गर्नुहोस्कृपया

के तपाइँ GitOps प्रयोग गर्दै हुनुहुन्छ?

• हो, दृष्टिकोण तान्नुहोस्

• हो, धक्का

• हो, पुल + पुश

• हो, अरू केही

• कुनै

30 प्रयोगकर्ताहरूले मतदान गरे। 10 प्रयोगकर्ताहरू रोकिए।

स्रोत: www.habr.com