Terraform वरून CloudFormation वर स्विच केले - आणि खेद वाटला

पुनरावृत्ती करता येण्याजोग्या मजकूर स्वरुपात कोड म्हणून पायाभूत सुविधांचे प्रतिनिधित्व करणे ही प्रणालींसाठी एक सोपा सर्वोत्तम सराव आहे ज्यांना उंदरांशी हलगर्जीपणा करण्याची आवश्यकता नाही. या प्रथेला एक नाव आहे - संहिता म्हणून पायाभूत सुविधा, आणि आतापर्यंत त्याची अंमलबजावणी करण्यासाठी दोन लोकप्रिय साधने आहेत, विशेषतः AWS मध्ये: टेराफॉर्म и क्लाउडफॉर्मेशन.

टेराफॉर्म आणि क्लाउडफॉर्मेशनसह अनुभवाची तुलना करणे

वर येण्यापूर्वी हिसका (तो आहे Amazon Jr.) मी काम केले एका स्टार्टअपमध्ये आणि तीन वर्षे टेराफॉर्म वापरले. नवीन ठिकाणी, मी माझ्या सर्व शक्तीने टेराफॉर्मचा वापर केला आणि नंतर कंपनीने क्लाउडफॉर्मेशनसह, अॅमेझॉनच्या प्रत्येक गोष्टीवर संक्रमण केले. मी परिश्रमपूर्वक दोन्हीसाठी सर्वोत्तम पद्धती विकसित केल्या आहेत आणि अतिशय जटिल, संस्था-व्यापी कार्यप्रवाहांमध्ये दोन्ही साधने वापरली आहेत. नंतर, टेराफॉर्ममधून क्लाउडफॉर्मेशनमध्ये स्थलांतरित होण्याच्या परिणामांचा विचारपूर्वक विचार केल्यावर, मला खात्री पटली की टेराफॉर्म कदाचित संस्थेसाठी सर्वोत्तम पर्याय आहे.

टेराफॉर्म भयानक

बीटा सॉफ्टवेअर

टेराफॉर्मने अद्याप आवृत्ती 1.0 देखील जारी केलेली नाही, जे ते न वापरण्याचे एक चांगले कारण आहे. मी प्रथम स्वतः प्रयत्न केल्यापासून ते खूप बदलले आहे, परंतु नंतर terraform apply बर्‍याचदा बर्‍याच अद्यतनांनंतर किंवा फक्त काही वर्षांच्या वापरानंतर खंडित होते. मी म्हणेन की "आता सर्व काही वेगळे आहे," पण... प्रत्येकजण तेच म्हणू शकतो, नाही का? असे बदल आहेत जे मागील आवृत्त्यांशी विसंगत आहेत, जरी ते योग्य आहेत, आणि असे वाटते की रिसोर्स स्टोअर्सची वाक्यरचना आणि अॅब्स्ट्रॅक्शन्स आता आपल्याला आवश्यक आहेत. इन्स्ट्रुमेंट खरोखर चांगले झाले आहे असे दिसते, परंतु... :-0

दुसरीकडे, AWS ने मागास अनुकूलता राखून चांगले काम केले आहे. याचे कारण असे की त्यांच्या सेवांची अनेकदा संस्थेमध्ये कसून चाचणी केली जाते आणि त्यानंतरच नाव बदलून प्रकाशित केले जाते. म्हणून "त्यांनी खूप प्रयत्न केले" हे एक अधोरेखित आहे. AWS सारख्या वैविध्यपूर्ण आणि जटिल प्रणालीसाठी APIs सह मागास अनुकूलता राखणे आश्चर्यकारकपणे कठीण आहे. ज्याला सार्वजनिक API ची देखरेख करावी लागली आहे जे ते तितक्याच मोठ्या प्रमाणावर वापरले जातात, त्यांना हे समजले पाहिजे की इतकी वर्षे असे करणे किती कठीण आहे. परंतु क्लाउडफॉर्मेशनचे वर्तन, माझ्या आठवणीत, गेल्या काही वर्षांत कधीही बदलले नाही.

पायाला भेटा... ही गोळी आहे

माझ्या माहितीनुसार, संसाधन हटवा बाहेरचा माणूस तुमच्या CF स्टॅकमधून CloudFormation स्टॅक शक्य नाही. टेराफॉर्मच्या बाबतीतही असेच आहे. हे तुम्हाला तुमच्या स्टॅकमध्ये विद्यमान संसाधने आयात करण्यास अनुमती देते. कार्य आश्चर्यकारक आहे असे म्हटले जाऊ शकते, परंतु मोठ्या सामर्थ्याने मोठी जबाबदारी येते. तुम्हाला फक्त स्टॅकमध्ये एक संसाधन जोडण्याची आवश्यकता आहे आणि तुम्ही तुमच्या स्टॅकसह काम करत असताना, तुम्ही हे संसाधन हटवू किंवा बदलू शकत नाही. एके दिवशी त्याचा उलटसुलट परिणाम झाला. Twitch वर एके दिवशी, कोणीतरी चुकून कोणाच्या तरी AWS सुरक्षा गटाला त्यांच्या स्वतःच्या टेराफॉर्म स्टॅकमध्ये आयात केले, परंतु कोणत्याही प्रकारचा गैरफायदा न घेता. मी अनेक आदेश प्रविष्ट केले आणि... सुरक्षा गट (येणाऱ्या रहदारीसह) गायब झाला.

टेराफॉर्म ग्रेट

अपूर्ण अवस्थांमधून पुनर्प्राप्ती

कधीकधी CloudFormation पूर्णपणे एका राज्यातून दुसर्‍या स्थितीत संक्रमण करण्यात अयशस्वी होते. त्याच वेळी, तो मागील एकावर परतण्याचा प्रयत्न करेल. हे खेदजनक आहे की हे नेहमीच शक्य नसते. नंतर जे घडले ते डीबग करणे खूप भीतीदायक असू शकते - क्लाउडफॉर्मेशन हॅक केले जात आहे याचा आनंद होईल की नाही हे तुम्हाला कधीच माहित नाही - अगदी फक्त त्याचे निराकरण करण्यासाठी. तो पूर्वीच्या स्थितीत परत येऊ शकेल की नाही, हे कसे ठरवायचे हे त्याला खरोखरच माहित नाही आणि डीफॉल्टनुसार, चमत्काराच्या प्रतीक्षेत तासनतास लटकत आहे.

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

दस्तऐवज स्थितीत स्पष्ट बदल

“ठीक आहे, लोड बॅलन्सर, तू बदलत आहेस. पण कसे?"

चिंताग्रस्त अभियंता, “स्वीकारा” बटण दाबण्यासाठी तयार.

कधीकधी मला क्लाउडफॉर्मेशन स्टॅकमधील लोड बॅलन्सरसह काही हाताळणी करावी लागतात, जसे की पोर्ट नंबर जोडणे किंवा सुरक्षा गट बदलणे. ClouFormation खराब बदल प्रदर्शित करते. मी, पिन आणि सुयांवर, मी आवश्यक काहीही मिटवले नाही आणि अनावश्यक काहीही जोडले नाही याची खात्री करण्यासाठी दहा वेळा yaml फाइल दोनदा तपासली.

या संदर्भात टेराफॉर्म अधिक पारदर्शक आहे. कधीकधी तो अगदी पारदर्शक असतो (वाचा: कंटाळवाणा). सुदैवाने, नवीनतम आवृत्तीमध्ये बदलांचे सुधारित प्रदर्शन समाविष्ट आहे जेणेकरून तुम्ही आता नक्की काय बदलत आहे ते पाहू शकता.

लवचिकता

सॉफ्टवेअर मागे लिहा.

स्पष्टपणे सांगायचे तर, दीर्घायुषी सॉफ्टवेअरचे सर्वात महत्त्वाचे वैशिष्ट्य म्हणजे बदलांशी जुळवून घेण्याची क्षमता. कोणतेही सॉफ्टवेअर मागे लिहा. बर्‍याचदा मी एक "साधी" सेवा घेऊन चुका केल्या आणि नंतर सर्वकाही एकाच क्लाउडफॉर्मेशन किंवा टेराफॉर्म स्टॅकमध्ये क्रॅम करणे सुरू केले. आणि अर्थातच, काही महिन्यांनंतर हे उघड झाले की मला सर्वकाही चुकीचे समजले आहे आणि सेवा प्रत्यक्षात सोपी नव्हती! आणि आता मला कसा तरी मोठा स्टॅक लहान घटकांमध्ये मोडण्याची गरज आहे. जेव्हा तुम्ही CloudFormation सोबत काम करता, तेव्हा हे फक्त प्रथम विद्यमान स्टॅक पुन्हा तयार करून केले जाऊ शकते आणि मी हे माझ्या डेटाबेससह करत नाही. दुसरीकडे, टेराफॉर्मने स्टॅकचे विच्छेदन करणे आणि अधिक समजण्यायोग्य लहान भागांमध्ये तोडणे शक्य केले.

गिटमधील मॉड्यूल्स

टेराफॉर्म कोड एकाधिक स्टॅकवर सामायिक करणे क्लाउडफॉर्मेशन कोड सामायिक करण्यापेक्षा बरेच सोपे आहे. टेराफॉर्मसह, तुम्ही तुमचा कोड गिट रिपॉझिटरीमध्ये ठेवू शकता आणि सिमेंटिक आवृत्ती नियंत्रण वापरून त्यात प्रवेश करू शकता. या भांडारात प्रवेश असलेले कोणीही सामायिक केलेला कोड पुन्हा वापरू शकतो. CloudFormation चे समतुल्य S3 आहे, परंतु त्याचे समान फायदे नाहीत आणि आम्ही S3 च्या बाजूने git अजिबात सोडून देण्याचे कोणतेही कारण नाही.

संस्था वाढली आणि सामायिक स्टॅक सामायिक करण्याची क्षमता गंभीर पातळीवर पोहोचली. टेराफॉर्म हे सर्व सोपे आणि नैसर्गिक बनवते, तर CloudFormation तुम्हाला असे काही काम मिळण्यापूर्वी हूप्समधून उडी मारेल.

कोड म्हणून ऑपरेशन्स

"चला स्क्रिप्ट करू आणि ठीक आहे."

- टेराफॉर्म सायकलचा शोध लावण्याच्या ३ वर्षांपूर्वी एक अभियंता.

जेव्हा सॉफ्टवेअर डेव्हलपमेंटचा विचार केला जातो तेव्हा गो किंवा जावा प्रोग्राम फक्त कोड नाही.

कोड म्हणून कोड

ज्या पायाभूत सुविधांवर ते काम करते.

संहिता म्हणून पायाभूत सुविधा

पण ती कुठली? त्याचे निरीक्षण कसे करावे? तुमचा कोड कुठे राहतो? विकासकांना प्रवेश परवानगी आवश्यक आहे का?

कोड म्हणून ऑपरेशन्स

सॉफ्टवेअर डेव्हलपर असण्याचा अर्थ फक्त कोड लिहिणे असा नाही.

AWS हे एकमेव नाही: तुम्ही कदाचित इतर प्रदाते वापरता. SignalFx, PagerDuty किंवा Github. कदाचित तुमच्याकडे CI/CD साठी अंतर्गत Jenkins सर्व्हर असेल किंवा मॉनिटरिंगसाठी अंतर्गत Grafana डॅशबोर्ड असेल. Infra as Code वेगवेगळ्या कारणांसाठी निवडले आहे आणि प्रत्येक सॉफ्टवेअरशी संबंधित प्रत्येक गोष्टीसाठी तितकेच महत्त्वाचे आहे.

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

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

…3 वर्षांनंतर:

• आघाडी: आणि आम्हाला टेराफॉर्म मिळाला.

कथेची नैतिकता आहे: जरी आपण ऍमेझॉन सर्वकाही मध्ये टाच वर डोके, तुम्ही अजूनही AWS मधून नसलेले काहीतरी वापरत आहात आणि या सेवांमध्ये अशी स्थिती आहे जी ती स्थिती समक्रमित ठेवण्यासाठी कॉन्फिगरेशन भाषा वापरते.

क्लाउडफॉर्मेशन लॅम्बडा वि गिट मॉड्यूल टेराफॉर्म

lambda हे कस्टम लॉजिक समस्येचे क्लाउडफॉर्मेशनचे समाधान आहे. लॅम्बडा सह आपण हे करू शकता मॅक्रो तयार करा किंवा वापरकर्ता संसाधन. हा दृष्टिकोन टेराफॉर्मच्या गिट मॉड्यूल्सच्या सिमेंटिक आवृत्तीमध्ये नसलेल्या अतिरिक्त जटिलतेचा परिचय देतो. माझ्यासाठी, या सर्व वापरकर्ता लॅम्बडास (आणि ही डझनभर AWS खाती आहेत) साठी परवानग्या व्यवस्थापित करणे ही सर्वात महत्त्वाची समस्या होती. दुसरी महत्त्वाची समस्या होती “प्रथम काय आले, कोंबडी की अंडी?” समस्या: ती लॅम्बडा कोडशी संबंधित होती. हे फंक्शन स्वतःच इन्फ्रास्ट्रक्चर आणि कोड आहे आणि त्याला स्वतःच मॉनिटरिंग आणि अपडेट्सची आवश्यकता आहे. शवपेटीतील अंतिम खिळे म्हणजे लॅम्बडा कोड बदलांना अर्थपूर्णपणे अद्यतनित करण्यात अडचण; आम्हाला हे देखील सुनिश्चित करावे लागेल की थेट आदेशाशिवाय स्टॅक क्रिया रन दरम्यान बदलत नाहीत.

मला आठवते की एकदा मला क्लासिक लोड बॅलन्सरसह इलास्टिक बीनस्टॉक वातावरणासाठी कॅनरी उपयोजन तयार करायचे होते. उत्पादन वातावरणाशेजारी EB साठी दुसरी तैनाती करणे ही सर्वात सोपी गोष्ट आहे, ते आणखी एक पाऊल पुढे टाकून: स्वयं-स्केलिंग कॅनरी उपयोजन गटाला उत्पादन वातावरणात उपयोजन LB सह एकत्रित करणे. आणि Terraform वापरते पासून निष्कर्ष म्हणून ASG beantalk, यासाठी टेराफॉर्ममध्ये 4 अतिरिक्त कोडची आवश्यकता असेल. जेव्हा मी विचारले की क्लाउडफॉर्मेशनमध्ये तुलनात्मक उपाय आहे का, तेव्हा त्यांनी मला डिप्लॉयमेंट पाइपलाइनसह संपूर्ण गिट रेपॉजिटरी आणि सर्वकाही, टेराफॉर्म कोडच्या खराब 4 ओळी करू शकतील अशा गोष्टीसाठी मला सूचित केले.

हे ड्रिफ्ट अधिक चांगल्या प्रकारे ओळखते

वास्तविकता अपेक्षांशी जुळते याची खात्री करा.

वाहून नेणे कोड वैशिष्ट्य म्हणून हे एक अतिशय शक्तिशाली ऑपरेशन आहे कारण ते वास्तव अपेक्षांशी जुळते याची खात्री करण्यात मदत करते. हे CloudFormation आणि Terraform दोन्हीसह उपलब्ध आहे. परंतु जसजसे उत्पादनाचा स्टॅक वाढत गेला, क्लाउडफॉर्मेशनमध्ये ड्रिफ्ट शोधण्याने अधिकाधिक खोट्या शोधांची निर्मिती केली.

टेराफॉर्मसह तुमच्याकडे ड्रिफ्ट शोधण्यासाठी अधिक प्रगत लाइफसायकल हुक आहेत. उदाहरणार्थ, तुम्ही कमांड एंटर करा दुर्लक्ष_बदल तुम्ही तुमच्या संपूर्ण ECS उपयोजनातील बदलांकडे दुर्लक्ष न करता विशिष्ट कार्य व्याख्येतील बदलांकडे दुर्लक्ष करू इच्छित असल्यास थेट ECS टास्क डेफिनिशनमध्ये.

सीडीके आणि क्लाउडफॉर्मेशनचे भविष्य

क्लाउडफॉर्मेशन मोठ्या, क्रॉस-इन्फ्रास्ट्रक्चर स्केलवर व्यवस्थापित करणे कठीण आहे. यापैकी बर्‍याच अडचणी ओळखल्या जातात आणि साधनाला यासारख्या गोष्टींची आवश्यकता असते aws-cdk, कोडमध्ये क्लाउड इन्फ्रास्ट्रक्चर परिभाषित करण्यासाठी आणि AWS CloudFormation द्वारे चालविण्यासाठी एक फ्रेमवर्क. aws-cdk साठी भविष्यात काय आहे हे पाहणे मनोरंजक असेल, परंतु टेराफॉर्मच्या इतर सामर्थ्यांशी स्पर्धा करणे कठीण होईल; CloudFormation अद्ययावत आणण्यासाठी, जागतिक बदल आवश्यक असतील.

जेणेकरून टेराफॉर्म निराश होणार नाही

हे "कोड म्हणून पायाभूत सुविधा" आहे, आणि "मजकूर म्हणून" नाही.

टेराफॉर्मची माझी पहिली छाप खूपच वाईट होती. मला वाटते की मला फक्त दृष्टीकोन समजला नाही. जवळजवळ सर्व अभियंते अनैच्छिकपणे ते मजकूर स्वरूप म्हणून समजतात ज्यास इच्छित पायाभूत सुविधांमध्ये रूपांतरित करणे आवश्यक आहे. अशा प्रकारे करू नका.

चांगल्या सॉफ्टवेअर डेव्हलपमेंटचे नियम टेराफॉर्मवर देखील लागू होतात.

मी टेराफॉर्ममध्ये चांगला कोड तयार करण्यासाठी अवलंबलेल्या अनेक पद्धती पाहिल्या आहेत ज्याकडे दुर्लक्ष केले जात आहे. चांगला प्रोग्रामर होण्यासाठी तुम्ही अनेक वर्षांपासून अभ्यास केला आहे. तुम्ही टेराफॉर्मसोबत काम करत आहात म्हणून हा अनुभव सोडू नका. चांगल्या सॉफ्टवेअर डेव्हलपमेंटचे नियम टेराफॉर्मला लागू होतात.

कोडचे दस्तऐवजीकरण कसे केले जाऊ शकत नाही?

मी कोणतेही कागदपत्र नसलेले प्रचंड टेराफॉर्म स्टॅक पाहिले आहेत. तुम्ही पानांमध्ये कोड कसे लिहू शकता - पूर्णपणे कागदपत्रांशिवाय? आपले स्पष्टीकरण देणारे दस्तऐवज जोडा कोड टेराफॉर्म ("कोड" शब्दावर जोर), हा विभाग इतका महत्त्वाचा का आहे आणि तुम्ही काय करता.

पूर्वी एक मोठे मुख्य() फंक्शन असलेल्या सेवा आम्ही कशा तैनात करू शकतो?

मी एकल मॉड्यूल म्हणून सादर केलेले अतिशय जटिल टेराफॉर्म स्टॅक पाहिले आहेत. आम्ही अशा प्रकारे सॉफ्टवेअर का उपयोजित करत नाही? आपण मोठ्या फंक्शन्सना छोट्या फंक्शन्समध्ये का विभाजित करतो? तीच उत्तरे Terraform ला लागू होतात. तुमचे मॉड्यूल खूप मोठे असल्यास, तुम्हाला ते लहान मॉड्यूल्समध्ये मोडणे आवश्यक आहे.

तुमची कंपनी लायब्ररी वापरत नाही का?

मी पाहिले आहे की, अभियंते, टेराफॉर्मचा वापर करून नवीन प्रकल्प कसा बनवतात, मूर्खपणाने इतर प्रकल्पांमधून मोठ्या प्रमाणात कॉपी-पेस्ट करतात आणि नंतर ते काम सुरू होईपर्यंत त्यांच्याशी छेडछाड करतात. तुम्ही तुमच्या कंपनीत "लढाऊ" कोडसह असे काम कराल का? आम्ही फक्त लायब्ररी वापरत नाही. होय, प्रत्येक गोष्ट लायब्ररी असावी असे नाही, पण तत्त्वतः सामायिक लायब्ररींशिवाय आपण कुठे आहोत?!

तुम्ही PEP8 किंवा gofmt वापरत नाही आहात का?

बहुतेक भाषांमध्ये मानक, स्वीकृत स्वरूपन योजना असते. Python मध्ये हे PEP8 आहे. Go मध्ये - gofmt. टेराफॉर्मचे स्वतःचे आहे: terraform fmt. आपल्या आरोग्यासाठी याचा आनंद घ्या!

तुम्ही JavaScript जाणून न घेता React वापराल का?

टेराफॉर्म मॉड्यूल्स तुम्ही तयार करत असलेल्या जटिल पायाभूत सुविधांचा काही भाग सुलभ करू शकतात, परंतु याचा अर्थ असा नाही की तुम्ही त्यात अजिबात टिंकर करू शकत नाही. संसाधने न समजता Terraform योग्यरित्या वापरू इच्छिता? तुम्ही नशिबात आहात: वेळ निघून जाईल आणि तुम्ही कधीही टेराफॉर्मवर प्रभुत्व मिळवू शकणार नाही.

तुम्ही सिंगलटन किंवा डिपेंडेंसी इंजेक्शनने कोडिंग करत आहात?

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

तुमची लायब्ररी दहा गोष्टी चांगल्या करतात की एक उत्तम?

सर्वोत्कृष्ट कार्य करणारी लायब्ररी अशी आहेत जी एका कार्यावर लक्ष केंद्रित करतात जे ते खूप चांगले करतात. सर्व काही एकाच वेळी करण्याचा प्रयत्न करणारे मोठे टेराफॉर्म मॉड्यूल लिहिण्याऐवजी, त्यांचे भाग तयार करा जे एक गोष्ट चांगली करतात. आणि नंतर आवश्यकतेनुसार ते एकत्र करा.

बॅकवर्ड कंपॅटिबिलिटीशिवाय तुम्ही लायब्ररीमध्ये बदल कसे कराल?

एका सामान्य टेराफॉर्म मॉड्यूलला, नेहमीच्या लायब्ररीप्रमाणे, पाठीमागे सुसंगत न होता वापरकर्त्यांना बदलांची माहिती देणे आवश्यक आहे. जेव्हा हे बदल लायब्ररीमध्ये होतात तेव्हा ते त्रासदायक असते आणि जेव्हा टेराफॉर्म मॉड्यूल्समध्ये गैर-मागे-सुसंगत बदल केले जातात तेव्हा ते त्रासदायक असते. टेराफॉर्म मॉड्यूल वापरताना गिट टॅग आणि सेमव्हर वापरण्याची शिफारस केली जाते.

तुमची उत्पादन सेवा तुमच्या लॅपटॉपवर चालू आहे की डेटा सेंटरमध्ये?

हॅशिकॉर्प सारखी साधने आहेत टेराफॉर्म ढग तुमचा टेराफॉर्म चालवण्यासाठी. या केंद्रीकृत सेवा टेराफॉर्म बदल व्यवस्थापित करणे, ऑडिट करणे आणि मंजूर करणे सोपे करतात.

तुम्ही परीक्षा लिहित नाही का?

अभियंते ओळखतात की कोडची चाचणी करणे आवश्यक आहे, परंतु ते स्वतः टेराफॉर्मसह काम करताना चाचणी विसरतात. पायाभूत सुविधांसाठी, हे विश्वासघातकी क्षणांनी भरलेले आहे. माझा सल्ला आहे की CI/CD दरम्यान चाचणीसाठी योग्यरित्या उपयोजित केलेले मॉड्यूल वापरून स्टॅकची “चाचणी” किंवा “उदाहरण तयार करा”.

टेराफॉर्म आणि मायक्रो सर्व्हिसेस

मायक्रोसर्व्हिसेस कंपन्यांचे जीवन आणि मृत्यू नवीन मायक्रोसर्व्हिस वर्कस्टॅकच्या गती, नावीन्य आणि व्यत्यय यावर अवलंबून आहे.

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

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