Terraform बाट CloudFormation मा स्विच गरियो - र पश्चाताप भयो

पूर्वाधारलाई दोहोर्याउन मिल्ने पाठ ढाँचामा कोडको रूपमा प्रस्तुत गर्नु भनेको प्रणालीहरूका लागि एक सरल उत्तम अभ्यास हो जसलाई मुसाहरूसँग फिडिङ आवश्यक पर्दैन। यस अभ्यासको नाम छ - कोडको रूपमा पूर्वाधार, र अहिले सम्म त्यहाँ यसलाई लागू गर्न दुई लोकप्रिय उपकरणहरू छन्, विशेष गरी AWS मा: ट्राफर्म и CloudFormation.

Terraform र CloudFormation संग अनुभव तुलना

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

Terraform भयानक

बीटा सफ्टवेयर

Terraform ले अहिलेसम्म संस्करण 1.0 जारी गरेको छैन, जुन यसलाई प्रयोग नगर्ने राम्रो कारण हो। यो धेरै परिवर्तन भएको छ जब देखि मैले यसलाई आफैंले प्रयास गरें, तर पछि terraform apply प्राय: धेरै अपडेटहरू पछि वा केही वर्षको प्रयोग पछि भाँचिन्छ। म भन्न चाहन्छु कि "अहिले सबै कुरा फरक छ," तर ... सबैले यही भन्छन्, होइन? त्यहाँ परिवर्तनहरू छन् जुन अघिल्लो संस्करणहरूसँग असंगत छन्, यद्यपि तिनीहरू उपयुक्त छन्, र यो पनि लाग्छ कि सिन्ट्याक्स र संसाधन स्टोरहरूको एब्स्ट्र्याक्सनहरू अब हामीलाई चाहिन्छ। उपकरण साँच्चै राम्रो भएको जस्तो देखिन्छ, तर... :-0

अर्कोतर्फ, AWS ले पछाडी अनुकूलता कायम राख्न राम्रो काम गरेको छ। यो हुनसक्छ किनभने तिनीहरूका सेवाहरू प्राय: संगठन भित्र राम्ररी परीक्षण गरिन्छ र त्यसपछि मात्र, पुन: नामाकरण, प्रकाशित गरिन्छ। त्यसोभए "उनीहरूले कडा प्रयास गरे" एक अल्पसंख्यक हो। AWS जस्तै विविध र जटिल प्रणालीको लागि APIs सँग पछाडि अनुकूलता कायम राख्न अविश्वसनीय रूपमा गाह्रो छ। जो कोहीले सार्वजनिक एपीआईहरू कायम राख्नु परेको छ जुन तिनीहरूको रूपमा व्यापक रूपमा प्रयोग गरिन्छ भनेर बुझ्नुपर्छ कि यति धेरै वर्षसम्म यो गर्न कत्ति गाह्रो छ। तर CloudFormation को व्यवहार, मेरो सम्झनामा, वर्षहरूमा कहिल्यै परिवर्तन भएको छैन।

खुट्टा भेट्नुहोस् ... यो एक गोली हो

जहाँसम्म मलाई थाहा छ, स्रोत मेटाउनुहोस् बाहिरी तपाईंको CF स्ट्याकबाट CloudFormation स्ट्याक सम्भव छैन। Terraform मा पनि त्यस्तै छ। यसले तपाइँलाई तपाइँको स्ट्याकमा अवस्थित स्रोतहरू आयात गर्न अनुमति दिन्छ। समारोह अचम्मको हुन सक्छ, तर ठूलो शक्ति संग ठूलो जिम्मेवारी आउँछ। तपाईंले स्ट्याकमा स्रोत थप्न आवश्यक छ, र तपाईंले आफ्नो स्ट्याकसँग काम गर्दा, तपाईंले यो स्रोतलाई मेटाउन वा परिवर्तन गर्न सक्नुहुन्न। एक दिन उल्टो भयो । एक दिन ट्विचमा, कसैले गलतीले अरू कसैको AWS सुरक्षा समूहलाई आफ्नै टेराफर्म स्ट्याकमा आयात गर्‍यो जब कि कुनै पनि दुराचार गर्न नपरोस्। मैले धेरै आदेशहरू प्रविष्ट गरें र... सुरक्षा समूह (आगमन ट्राफिकको साथ) गायब भयो।

Terraform महान

अपूर्ण अवस्थाहरूबाट रिकभरी

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

अर्कोतर्फ, टेराफर्मले असफल ट्रान्जिसनबाट धेरै राम्रोसँग पुन: प्राप्ति गर्न खोज्छ र उन्नत डिबगिङ उपकरणहरू प्रदान गर्दछ।

कागजात स्थितिमा स्पष्ट परिवर्तनहरू

"ठीक छ, लोड ब्यालेन्सर, तपाईं परिवर्तन गर्दै हुनुहुन्छ। तर कसरी?"

चिन्तित इन्जिनियर, "स्वीकार गर्नुहोस्" बटन थिच्न तयार।

कहिलेकाहीँ मैले CloudFormation स्ट्याकमा लोड ब्यालेन्सरसँग केही हेरफेर गर्न आवश्यक छ, जस्तै पोर्ट नम्बर थप्ने वा सुरक्षा समूह परिवर्तन गर्ने। ClouFormation ले खराब परिवर्तनहरू देखाउँछ। म, पिन र सुईहरूमा, yaml फाइललाई दस पटक डबल-जाँच गर्छु कि मैले आवश्यक केहि मेटेको छैन र अनावश्यक केहि थपेको छैन।

Terraform यस सन्दर्भमा धेरै पारदर्शी छ। कहिलेकाहीँ ऊ धेरै पारदर्शी पनि हुन्छ (पढ्नुहोस्: कष्टप्रद)। सौभाग्यवश, नवीनतम संस्करणले परिवर्तनहरूको सुधारिएको प्रदर्शन समावेश गर्दछ ताकि तपाईले अब के परिवर्तन भइरहेको छ भनेर देख्न सक्नुहुन्छ।

लचिलोपन

पछाडि सफ्टवेयर लेख्नुहोस्।

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

Git मा मोड्युलहरू

धेरै स्ट्याकहरूमा Terraform कोड साझेदारी गर्नु CloudFormation कोड साझेदारी गर्नु भन्दा धेरै सजिलो छ। Terraform को साथ, तपाईं आफ्नो कोड एक git भण्डारमा राख्न सक्नुहुन्छ र अर्थ संस्करण नियन्त्रण प्रयोग गरेर पहुँच गर्न सक्नुहुन्छ। यस भण्डारमा पहुँच भएका जो कोहीले साझा कोड पुन: प्रयोग गर्न सक्छन्। CloudFormation को बराबर S3 हो, तर यसमा समान फाइदाहरू छैनन्, र त्यहाँ कुनै कारण छैन कि हामीले S3 को पक्षमा git त्याग्नु पर्छ।

संगठन बढ्यो र साझा स्ट्याकहरू साझा गर्ने क्षमता महत्वपूर्ण स्तरमा पुग्यो। Terraform ले यो सबै सजिलो र प्राकृतिक बनाउँछ, जबकि CloudFormation ले तपाइँलाई यो काम जस्तो केहि प्राप्त गर्नु अघि हुप्स मार्फत हाम फाल्नेछ।

कोडको रूपमा सञ्चालन

"यो स्क्रिप्ट गरौं र ठीक छ।"

- टेराफर्म साइकल आविष्कार गर्नुभन्दा ३ वर्षअघि इन्जिनियर।

जब यो सफ्टवेयर विकासको लागि आउँछ, गो वा जाभा प्रोग्राम कोड मात्र होइन।

कोडको रूपमा कोड

त्यहाँ काम गर्ने पूर्वाधार पनि छ।

कोडको रूपमा पूर्वाधार

तर उनी कहाँकी हुन् ? यसको अनुगमन कसरी गर्ने ? तपाईको कोड कहाँ बस्छ? विकासकर्ताहरूलाई पहुँच अनुमति चाहिन्छ?

संहिताको रूपमा सञ्चालन

सफ्टवेयर विकासकर्ता हुनु भनेको कोड लेख्नु मात्र होइन।

AWS मात्र एक होइन: तपाईले अन्य प्रदायकहरू प्रयोग गर्नुहुन्छ। SignalFx, PagerDuty वा Github। हुनसक्छ तपाईसँग CI/CD को लागि आन्तरिक जेनकिन्स सर्भर वा निगरानीको लागि आन्तरिक Grafana ड्यासबोर्ड छ। इन्फ्रा कोडको रूपमा विभिन्न कारणहरूका लागि छनौट गरिएको छ, र प्रत्येक सफ्टवेयरसँग सम्बन्धित सबै कुराको लागि समान रूपमा महत्त्वपूर्ण छ।

जब मैले ट्विचमा काम गरें, हामीले Amazon को मिश्रित एम्बेडेड र AWS प्रणालीहरू भित्र सेवाहरूलाई गति दियौं। हामीले धेरै लघु सेवाहरूलाई मन्थन र समर्थन गर्‍यौं, परिचालन लागतहरू बढाउँदै। छलफल यसरी भयो:

• Я: धिक्कार छ, यो एउटा माइक्रोसर्भिसलाई ओभरक्ल गर्नका लागि धेरै इशाराहरू हो। मैले AWS खाता सिर्जना गर्न यो फोहोर प्रयोग गर्नुपर्नेछ (हामी 2 खाताहरूमा गयौं माइक्रो सेवा), त्यसपछि यो अलर्टहरू सेटअप गर्नको लागि, यो कोड भण्डारको लागि, र यो इमेल सूचीको लागि, र त्यसपछि यो...
• नेतृत्व: यसलाई स्क्रिप्ट गरौं र ठीक छ।
• Я: ठीक छ, तर स्क्रिप्ट आफै परिवर्तन हुनेछ। हामीलाई यी सबै बिल्ट-इन अमेजन गिज्मोहरू अप टु डेट छन् भनेर जाँच गर्न एउटा तरिका चाहिन्छ।
• नेतृत्व: राम्रो लाग्छ। र हामी यसको लागि एक स्क्रिप्ट लेख्नेछौं।
• Я: महान! र स्क्रिप्टले अझै पनि प्यारामिटरहरू सेट गर्न आवश्यक हुनेछ। के उहाँले तिनीहरूलाई स्वीकार गर्नुहुन्छ?
• नेतृत्व: उसलाई जहाँ जान्छ त्यहाँ लैजान दिनुहोस्!
• Я: प्रक्रिया परिवर्तन हुन सक्छ र पछाडि अनुकूलता हराउनेछ। केहि प्रकारको सिमान्टिक संस्करण नियन्त्रण आवश्यक हुनेछ।
• नेतृत्व: उच्च विचार!
• Я: उपकरणहरू प्रयोगकर्ता इन्टरफेस भित्र म्यानुअल रूपमा परिवर्तन गर्न सकिन्छ। हामीलाई यसलाई जाँच गर्न र समाधान गर्ने तरिका चाहिन्छ।

…३ वर्षपछि:

• नेतृत्व: र हामीले टेराफार्म पायौं।

कथाको नैतिकता हो: यदि तपाईं अमेजनमा सबै कुरामा हेड माथि हेड, तपाईंले अझै पनि AWS बाट नभएको कुरा प्रयोग गरिरहनुभएको छ, र यी सेवाहरूमा त्यो अवस्थालाई सिङ्कमा राख्न कन्फिगरेसन भाषा प्रयोग गर्ने राज्य छ।

CloudFormation lambda बनाम git मोड्युल टेराफार्म

lambda अनुकूलन तर्क मुद्दाको CloudFormation को समाधान हो। Lambda संग तपाईं सक्नुहुन्छ म्याक्रोहरू सिर्जना गर्नुहोस् वा प्रयोगकर्ता स्रोत। यस दृष्टिकोणले थप जटिलताहरू परिचय गराउँछ जुन Terraform को git मोड्युलहरूको सिमेन्टिक संस्करणमा अवस्थित छैन। मेरो लागि, सबै भन्दा थिचिएको समस्या यी सबै प्रयोगकर्ता lambdas (र यी दर्जनौं AWS खाताहरू हुन्) को लागि अनुमतिहरू प्रबन्ध गर्ने थियो। अर्को महत्त्वपूर्ण समस्या "पहिले के आयो, कुखुरा वा अण्डा?" समस्या थियो: यो लाम्ब्डा कोडसँग सम्बन्धित थियो। यो प्रकार्य आफैंमा पूर्वाधार र कोड हो, र यसलाई आफैंलाई निगरानी र अद्यावधिकहरू चाहिन्छ। लाम्ब्डा कोड परिवर्तनहरू सिमेन्टिक रूपमा अद्यावधिक गर्न कफिनमा अन्तिम कील थियो; हामीले यो पनि सुनिश्चित गर्नुपर्‍यो कि प्रत्यक्ष आदेश बिना स्ट्याक कार्यहरू रनहरू बीचमा परिवर्तन भएन।

मलाई याद छ एक पटक म क्लासिक लोड ब्यालेन्सरको साथ इलास्टिक बीनस्टक वातावरणको लागि क्यानरी डिप्लोइमेन्ट सिर्जना गर्न चाहन्थें। गर्नको लागि सबैभन्दा सजिलो कुरा EB को लागि उत्पादन वातावरणको छेउमा दोस्रो डिप्लोइमेन्ट गर्नु हो, यसलाई एक कदम अगाडि बढाउँदै: उत्पादन वातावरणमा डिप्लोयमेन्ट LB सँग अटो-स्केलिंग क्यानरी डिप्लोयमेन्ट समूह संयोजन गर्दै। र जब देखि Terraform प्रयोग गर्दछ ASG beantalk निष्कर्षको रूपमा, यसका लागि Terraform मा कोडको 4 अतिरिक्त लाइनहरू आवश्यक पर्दछ। जब मैले सोधे कि क्लाउडफोर्मेशनमा तुलनात्मक समाधान छ कि छैन, तिनीहरूले मलाई डिप्लोइमेन्ट पाइपलाइन र सबै चीजको साथ सम्पूर्ण गिट भण्डारमा औंल्याए, टेराफर्म कोडको खराब 4 लाइनहरूले के गर्न सक्छ भन्ने खातिर।

यसले बहाव राम्रोसँग पत्ता लगाउँछ

निश्चित गर्नुहोस् कि वास्तविकता अपेक्षाहरूसँग मेल खान्छ।

बहाव पत्ता लगाउने कोड सुविधाको रूपमा एक धेरै शक्तिशाली अपरेशन हो किनभने यसले वास्तविकता अपेक्षाहरूसँग मेल खान्छ भनेर सुनिश्चित गर्न मद्दत गर्दछ। यो CloudFormation र Terraform दुवै संग उपलब्ध छ। तर उत्पादन स्ट्याक बढ्दै जाँदा, क्लाउडफर्मेसनमा बहावको खोजीले थप र धेरै झूटा पहिचानहरू उत्पादन गर्यो।

Terraform को साथ तपाईंसँग बहाव पत्ता लगाउनको लागि धेरै उन्नत जीवनचक्र हुकहरू छन्। उदाहरण को लागी, तपाइँ आदेश प्रविष्ट गर्नुहोस् ignore_changes यदि तपाइँ तपाइँको सम्पूर्ण ECS परिनियोजनमा परिवर्तनहरूलाई बेवास्ता नगरीकन कुनै विशेष कार्य परिभाषामा परिवर्तनहरूलाई बेवास्ता गर्न चाहनुहुन्छ भने सीधा ECS कार्य परिभाषामा।

CDK र CloudFormation को भविष्य

CloudFormation ठूलो, क्रस-पूर्वाधार स्केलमा व्यवस्थापन गर्न गाह्रो छ। यी धेरै कठिनाइहरू पहिचान छन् र उपकरण जस्तै चीजहरू आवश्यक छ aws-cdk, कोडमा क्लाउड पूर्वाधार परिभाषित गर्न र AWS CloudFormation मार्फत चलाउने ढाँचा। aws-cdk को लागि भविष्यले के राख्छ भनेर हेर्न चाखलाग्दो हुनेछ, तर Terraform को अन्य शक्तिहरूसँग प्रतिस्पर्धा गर्न गाह्रो हुनेछ; CloudFormation लाई अप टु डेट ल्याउन, विश्वव्यापी परिवर्तनहरू आवश्यक हुनेछ।

ताकि Terraform निराश छैन

यो "कोडको रूपमा पूर्वाधार" हो, र "पाठको रूपमा" होइन।

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

राम्रो सफ्टवेयर विकासको ट्रिज्म टेराफार्ममा पनि लागू हुन्छ।

मैले टेराफर्ममा राम्रो कोड सिर्जना गर्न अपनाइएको धेरै अभ्यासहरू बेवास्ता गरेको देखेको छु। तपाईंले राम्रो प्रोग्रामर बन्न वर्षौंको लागि अध्ययन गर्नुभएको छ। तपाईंले Terraform सँग काम गरिरहनुभएकोले मात्र यो अनुभव नछोड्नुहोस्। राम्रो सफ्टवेयर विकासको ट्रिज्म Terraform मा लागू हुन्छ।

कोड कसरी कागजात गर्न सकिँदैन?

मैले कुनै कागजात बिना विशाल टेराफर्म स्ट्याकहरू देखेको छु। तपाइँ कसरी पृष्ठहरूमा कोड लेख्न सक्नुहुन्छ - बिल्कुल कुनै कागजात बिना? तपाईंको व्याख्या गर्ने कागजातहरू थप्नुहोस् कोड Terraform (शब्द "कोड" मा जोड), किन यो खण्ड यति महत्त्वपूर्ण छ, र तपाईं के गर्नुहुन्छ।

हामी कसरी सेवाहरू डिप्लोय गर्न सक्छौं जुन एक पटक ठूलो मुख्य() प्रकार्य थियो?

मैले एकल मोड्युलको रूपमा प्रस्तुत धेरै जटिल Terraform स्ट्याकहरू देखेको छु। हामी किन यसरी सफ्टवेयर डिप्लोइ गर्दैनौं? हामी किन ठूला कार्यहरूलाई सानोमा विभाजन गर्छौं? उही जवाफ Terraform मा लागू हुन्छ। यदि तपाईंको मोड्युल धेरै ठूलो छ भने, तपाईंले यसलाई साना मोड्युलहरूमा तोड्न आवश्यक छ।

के तपाईंको कम्पनीले पुस्तकालयहरू प्रयोग गर्दैन?

मैले देखेको छु कि कसरी ईन्जिनियरहरूले टेराफर्म प्रयोग गरेर नयाँ परियोजनालाई स्पिन गर्दै, मूर्खतापूर्वक अन्य परियोजनाहरूबाट ठूलो टुक्राहरू आफ्नैमा प्रतिलिपि गरेर टाँस्छन्, र त्यसपछि काम सुरु नगरेसम्म तिनीहरूसँग टिंकर गरे। के तपाइँ तपाइँको कम्पनी मा "लडाई" कोड संग यो जस्तै काम गर्नुहुन्छ? हामी पुस्तकालयहरू मात्र प्रयोग गर्दैनौं। हो, सबै कुरा पुस्तकालय हुनुपर्छ भन्ने छैन, तर हामी सैद्धान्तिक रूपमा साझा पुस्तकालयहरू बिना कहाँ छौं?!

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

धेरै भाषाहरूमा मानक, स्वीकृत ढाँचा योजना छ। Python मा यो PEP8 हो। Go मा - gofmt। Terraform यसको आफ्नै छ: terraform fmt। स्वास्थ्यमा प्रयोग गर्नुहोस्!

के तपाइँ JavaScript जानी बिना प्रतिक्रिया प्रयोग गर्नुहुन्छ?

Terraform मोड्युलहरूले तपाईंले सिर्जना गर्नुभएको जटिल पूर्वाधारको केही भागलाई सरल बनाउन सक्छ, तर यसको मतलब यो होइन कि तपाईंले यसमा कुनै किसिमको टिंकर गर्न सक्नुहुन्न। स्रोतहरू नबुझेर Terraform सही रूपमा प्रयोग गर्न चाहनुहुन्छ? तपाईं बर्बाद हुनुहुन्छ: समय बित्नेछ, र तपाईंले कहिल्यै टेराफर्ममा मास्टर गर्नुहुनेछैन।

के तपाइँ सिंगलटन वा निर्भरता इंजेक्शन संग कोडिङ गर्दै हुनुहुन्छ?

निर्भरता इंजेक्शन सफ्टवेयर विकासको लागि एक मान्यता प्राप्त उत्तम अभ्यास हो र सिंगलटन भन्दा प्राथमिकता दिइन्छ। Terraform मा यो कसरी उपयोगी छ? मैले टेराफार्म मोड्युलहरू देखेको छु जुन रिमोट स्टेटमा निर्भर हुन्छ। टाढाको अवस्था पुन: प्राप्त गर्ने मोड्युलहरू लेख्नुको सट्टा, परिमितिहरू लिने मोड्युल लेख्नुहोस्। र त्यसपछि यी प्यारामिटरहरू मोड्युलमा पास गर्नुहोस्।

के तपाईंका पुस्तकालयहरूले दस चीजहरू राम्ररी गर्छन् वा एउटा राम्रो कुरा?

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

तपाईं पछाडि अनुकूलता बिना पुस्तकालयहरूमा परिवर्तन कसरी गर्नुहुन्छ?

एक सामान्य टेराफर्म मोड्युल, एक नियमित पुस्तकालय जस्तै, कुनै न कुनै रूपमा प्रयोगकर्ताहरूलाई पछाडि मिल्दो नभई परिवर्तनहरू सञ्चार गर्न आवश्यक छ। पुस्तकालयहरूमा यी परिवर्तनहरू हुँदा यो कष्टप्रद हुन्छ, र Terraform मोड्युलहरूमा गैर-पछाडि-कम्प्याटिबल परिवर्तनहरू गर्दा यो कष्टप्रद हुन्छ। Terraform मोड्युलहरू प्रयोग गर्दा git ट्यागहरू र semver प्रयोग गर्न सिफारिस गरिन्छ।

के तपाइँको उत्पादन सेवा तपाइँको ल्यापटप वा डाटा केन्द्र मा चलिरहेको छ?

Hashicorp जस्ता उपकरणहरू छन् टेराफर्म बादल आफ्नो terraform चलाउन। यी केन्द्रीकृत सेवाहरूले टेराफार्म परिवर्तनहरू व्यवस्थित गर्न, लेखा परीक्षण गर्न र अनुमोदन गर्न सजिलो बनाउँदछ।

के तपाई परीक्षा लेख्नुहुन्न?

ईन्जिनियरहरूले कोडलाई परीक्षण गर्न आवश्यक छ भनी बुझ्छन्, तर तिनीहरू आफैंले टेराफर्मसँग काम गर्दा परीक्षणको बारेमा बिर्सन्छन्। पूर्वाधारको लागि, यो विश्वासघाती क्षणहरूले भरिएको छ। मेरो सल्लाह "परीक्षण" वा "उदाहरण सिर्जना गर्नुहोस्" मोड्युलहरू प्रयोग गरेर स्ट्याकहरू जुन CI/CD को समयमा परीक्षणको लागि सही रूपमा प्रयोग गर्न सकिन्छ।

Terraform र microservices

माइक्रोसर्भिसेस कम्पनीहरूको जीवन र मृत्यु नयाँ माइक्रोसर्भिस वर्कस्ट्याकहरूको गति, नवीनता र अवरोधमा निर्भर गर्दछ।

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

स्रोत: www.habr.com