Terraform થી CloudFormation પર સ્વિચ કર્યું - અને તેના માટે ખેદ વ્યક્ત કર્યો

પુનરાવર્તિત ટેક્સ્ટ ફોર્મેટમાં કોડ તરીકે ઇન્ફ્રાસ્ટ્રક્ચરનું પ્રતિનિધિત્વ એ સિસ્ટમો માટે એક સરળ શ્રેષ્ઠ પ્રથા છે જેને ઉંદર સાથે હલાવવાની જરૂર નથી. આ પ્રથાનું નામ છે - કોડ તરીકે ઈન્ફ્રાસ્ટ્રક્ચર, અને અત્યાર સુધી તેને અમલમાં મૂકવા માટે બે લોકપ્રિય સાધનો છે, ખાસ કરીને AWS માં: ટેરાફોર્મ и ક્લાઉડફોર્મેશન.

ટેરાફોર્મ અને ક્લાઉડફોર્મેશન સાથેના અનુભવની સરખામણી

આવતા પહેલા twitch (તે એમેઝોન જુનિયર) મેં કામ કર્યું એક સ્ટાર્ટઅપમાં અને ત્રણ વર્ષ સુધી ટેરાફોર્મનો ઉપયોગ કર્યો. નવી જગ્યાએ, મેં મારી તમામ શક્તિ સાથે ટેરાફોર્મનો પણ ઉપયોગ કર્યો, અને પછી કંપનીએ ક્લાઉડફોર્મેશન સહિત દરેક વસ્તુને લા એમેઝોન તરફ આગળ ધપાવી. મેં બંને માટે ખંતપૂર્વક શ્રેષ્ઠ પ્રેક્ટિસ વિકસાવી છે અને ખૂબ જ જટિલ, સંસ્થા-વ્યાપી વર્કફ્લોમાં બંને ટૂલ્સનો ઉપયોગ કર્યો છે. પાછળથી, ટેરાફોર્મથી ક્લાઉડફોર્મેશનમાં સ્થળાંતર કરવાના અસરોને વિચારપૂર્વક ધ્યાનમાં લીધા પછી, મને ખાતરી થઈ કે ટેરાફોર્મ સંસ્થા માટે કદાચ શ્રેષ્ઠ પસંદગી છે.

ટેરાફોર્મ ભયાનક

બીટા સોફ્ટવેર

ટેરાફોર્મે હજુ સુધી વર્ઝન 1.0 પણ બહાર પાડ્યું નથી, જે તેનો ઉપયોગ ન કરવાનું એક સારું કારણ છે. મેં મારી જાતે પ્રયાસ કર્યો ત્યારથી તે ઘણો બદલાઈ ગયો છે, પરંતુ તે પછી terraform apply ઘણીવાર ઘણા અપડેટ્સ પછી અથવા ફક્ત થોડા વર્ષોના ઉપયોગ પછી તૂટી જાય છે. હું કહીશ કે "હવે બધું અલગ છે," પણ... દરેક એવું જ કહે છે, ના? એવા ફેરફારો છે જે અગાઉના સંસ્કરણો સાથે અસંગત છે, જો કે તે યોગ્ય છે, અને એવું પણ લાગે છે કે સંસાધન સ્ટોર્સના વાક્યરચના અને એબ્સ્ટ્રેક્શન હવે આપણને જોઈએ છે. એવું લાગે છે કે સાધન ખરેખર સારું બન્યું છે, પરંતુ... :-0

બીજી બાજુ, AWS એ પછાત સુસંગતતા જાળવવાનું સારું કામ કર્યું છે. આ કદાચ એટલા માટે છે કારણ કે તેમની સેવાઓનું સંસ્થામાં ઘણી વખત સંપૂર્ણ પરીક્ષણ કરવામાં આવે છે અને માત્ર ત્યારે જ, નામ બદલીને, પ્રકાશિત કરવામાં આવે છે. તેથી "તેઓએ સખત પ્રયાસ કર્યો" એ અલ્પોક્તિ છે. AWS જેવી વૈવિધ્યસભર અને જટિલ સિસ્ટમ માટે APIs સાથે પછાત સુસંગતતા જાળવવી અતિ મુશ્કેલ છે. કોઈપણ જેમણે સાર્વજનિક API ને જાળવવું પડ્યું છે જેનો ઉપયોગ તેઓ જેટલો વ્યાપકપણે થાય છે તે સમજવું જોઈએ કે આટલા વર્ષો સુધી આમ કરવું કેટલું મુશ્કેલ છે. પરંતુ ક્લાઉડફોર્મેશનનું વર્તન, મારી યાદમાં, વર્ષોથી ક્યારેય બદલાયું નથી.

પગને મળો... તે ગોળી છે

જ્યાં સુધી હું જાણું છું, સંસાધન કાઢી નાખો બહારની વ્યક્તિ તમારા CF સ્ટેકમાંથી CloudFormation સ્ટેક શક્ય નથી. ટેરાફોર્મ સાથે પણ આવું જ છે. તે તમને તમારા સ્ટેકમાં હાલના સંસાધનોને આયાત કરવાની મંજૂરી આપે છે. કાર્યને અદ્ભુત કહી શકાય, પરંતુ મહાન શક્તિ સાથે મોટી જવાબદારી આવે છે. તમારે ફક્ત સ્ટેકમાં એક સંસાધન ઉમેરવાની જરૂર છે, અને જ્યારે તમે તમારા સ્ટેક સાથે કામ કરી રહ્યાં હોવ, ત્યારે તમે આ સંસાધનને કાઢી અથવા બદલી શકતા નથી. એક દિવસ તે બેકફાયર થયું. Twitch પર એક દિવસ, કોઈએ આકસ્મિક રીતે કોઈ અન્યના AWS સુરક્ષા જૂથને તેમના પોતાના ટેરાફોર્મ સ્ટેકમાં આયાત કર્યું, જ્યારે કોઈ તોફાન ન થાય. મેં ઘણા આદેશો દાખલ કર્યા અને... સુરક્ષા જૂથ (આવતા ટ્રાફિક સાથે) અદૃશ્ય થઈ ગયું.

ટેરાફોર્મ ગ્રેટ

અપૂર્ણ રાજ્યોમાંથી પુનઃપ્રાપ્તિ

કેટલીકવાર CloudFormation સંપૂર્ણપણે એક રાજ્યમાંથી બીજા રાજ્યમાં સંક્રમણ કરવામાં નિષ્ફળ જાય છે. તે જ સમયે, તે પાછલા એક પર પાછા ફરવાનો પ્રયાસ કરશે. તે દયાની વાત છે કે આ હંમેશા શક્ય નથી. પછીથી જે બન્યું તે ડીબગ કરવું તે ખૂબ ડરામણી હોઈ શકે છે - તમે ક્યારેય જાણતા નથી કે ક્લાઉડફોર્મેશન ખુશ થશે કે તે હેક થઈ રહ્યું છે - માત્ર તેને ઠીક કરવા માટે પણ. પાછલી સ્થિતિમાં પાછા આવવું શક્ય બનશે કે નહીં, તે ખરેખર કેવી રીતે નક્કી કરવું તે જાણતો નથી અને, મૂળભૂત રીતે, ચમત્કારની રાહ જોતા કલાકો સુધી અટકી જાય છે.

બીજી બાજુ, ટેરાફોર્મ, નિષ્ફળ સંક્રમણોમાંથી વધુ આકર્ષક રીતે પુનઃપ્રાપ્ત થવાનું વલણ ધરાવે છે અને અદ્યતન ડીબગીંગ ટૂલ્સ ઓફર કરે છે.

દસ્તાવેજની સ્થિતિમાં સ્પષ્ટ ફેરફારો

“ઠીક છે, લોડ બેલેન્સર, તમે બદલો છો. પરંતુ કેવી રીતે?"

-ચિંતિત એન્જિનિયર, "સ્વીકારો" બટન દબાવવા માટે તૈયાર.

કેટલીકવાર મારે CloudFormation સ્ટેકમાં લોડ બેલેન્સર સાથે કેટલાક મેનિપ્યુલેશન્સ કરવાની જરૂર પડે છે, જેમ કે પોર્ટ નંબર ઉમેરવો અથવા સુરક્ષા જૂથ બદલવું. ClouFormation ખરાબ ફેરફારો દર્શાવે છે. હું, પિન અને સોય પર, yaml ફાઇલને દસ વખત બે વાર તપાસો જેથી ખાતરી કરો કે મેં કંઈપણ જરૂરી ભૂંસી નાખ્યું નથી અને કંઈપણ બિનજરૂરી ઉમેર્યું નથી.

ટેરાફોર્મ આ બાબતે વધુ પારદર્શક છે. કેટલીકવાર તે ખૂબ પારદર્શક પણ હોય છે (વાંચો: કંટાળાજનક). સદનસીબે, નવીનતમ સંસ્કરણમાં ફેરફારોના સુધારેલા પ્રદર્શનનો સમાવેશ થાય છે જેથી કરીને તમે હવે બરાબર જોઈ શકો કે શું બદલાઈ રહ્યું છે.

સુગમતા

સોફ્ટવેર પાછળની તરફ લખો.

સ્પષ્ટ શબ્દોમાં કહીએ તો, લાંબા સમય સુધી જીવતા સૉફ્ટવેરની સૌથી મહત્ત્વની લાક્ષણિકતા એ પરિવર્તનને અનુકૂલન કરવાની ક્ષમતા છે. કોઈપણ સોફ્ટવેર પાછળની તરફ લખો. મોટાભાગે હું "સરળ" સેવા લઈને, અને પછી એક જ ક્લાઉડફોર્મેશન અથવા ટેરાફોર્મ સ્ટેકમાં બધું ક્રેમ કરવાનું શરૂ કરીને ભૂલો કરું છું. અને અલબત્ત, મહિનાઓ પછી તે જાહેર થયું કે હું બધું ખોટું સમજી ગયો હતો, અને સેવા ખરેખર સરળ નહોતી! અને હવે મારે કોઈક રીતે મોટા સ્ટેકને નાના ઘટકોમાં તોડવાની જરૂર છે. જ્યારે તમે CloudFormation સાથે કામ કરો છો, ત્યારે આ ફક્ત પહેલા અસ્તિત્વમાંના સ્ટેકને ફરીથી બનાવીને જ કરી શકાય છે, અને હું મારા ડેટાબેસેસ સાથે આવું કરતો નથી. બીજી બાજુ, ટેરાફોર્મે સ્ટેકનું વિચ્છેદન કરવું અને તેને વધુ સમજી શકાય તેવા નાના ભાગોમાં તોડવાનું શક્ય બનાવ્યું.

git માં મોડ્યુલો

CloudFormation કોડને શેર કરવા કરતાં બહુવિધ સ્ટેક્સ પર ટેરાફોર્મ કોડ શેર કરવો વધુ સરળ છે. ટેરાફોર્મ સાથે, તમે તમારા કોડને ગિટ રિપોઝીટરીમાં મૂકી શકો છો અને સિમેન્ટીક વર્ઝન કંટ્રોલનો ઉપયોગ કરીને તેને ઍક્સેસ કરી શકો છો. આ રીપોઝીટરીની ઍક્સેસ ધરાવનાર કોઈપણ શેર કરેલ કોડનો ફરીથી ઉપયોગ કરી શકે છે. CloudFormation ની સમકક્ષ S3 છે, પરંતુ તેના સમાન લાભો નથી, અને ત્યાં કોઈ કારણ નથી કે શા માટે આપણે S3 ની તરફેણમાં ગિટને છોડી દેવી જોઈએ.

સંસ્થાનો વિકાસ થયો અને સામાન્ય સ્ટેક્સ શેર કરવાની ક્ષમતા નિર્ણાયક સ્તરે પહોંચી. ટેરાફોર્મ આ બધું સરળ અને સ્વાભાવિક બનાવે છે, જ્યારે ક્લાઉડફોર્મેશન તમને આના જેવું કામ મેળવતા પહેલા હૂપ્સમાંથી કૂદકો મારશે.

કોડ તરીકે કામગીરી

"ચાલો તેને સ્ક્રિપ્ટ કરીએ અને ઠીક છે."

-ટેરાફોર્મ સાયકલની શોધ કરતા 3 વર્ષ પહેલા એક એન્જિનિયર.

જ્યારે સોફ્ટવેર ડેવલપમેન્ટની વાત આવે છે, ત્યારે ગો અથવા જાવા પ્રોગ્રામ માત્ર કોડ નથી.

કોડ તરીકે કોડ

ઈન્ફ્રાસ્ટ્રક્ચર પણ છે જેના પર તે કામ કરે છે.

કોડ તરીકે ઈન્ફ્રાસ્ટ્રક્ચર

પરંતુ તેણી ક્યાંથી છે? તેનું નિરીક્ષણ કેવી રીતે કરવું? તમારો કોડ ક્યાં રહે છે? શું વિકાસકર્તાઓને ઍક્સેસ પરવાનગીની જરૂર છે?

કોડ તરીકે કામગીરી

સોફ્ટવેર ડેવલપર હોવાનો અર્થ માત્ર કોડ લખવાનો નથી.

AWS એકમાત્ર નથી: તમે કદાચ અન્ય પ્રદાતાઓનો ઉપયોગ કરો છો. SignalFx, PagerDuty અથવા Github. કદાચ તમારી પાસે CI/CD માટે આંતરિક જેનકિન્સ સર્વર અથવા દેખરેખ માટે આંતરિક Grafana ડેશબોર્ડ છે. ઇન્ફ્રા એઝ કોડ વિવિધ કારણોસર પસંદ કરવામાં આવે છે, અને દરેક સોફ્ટવેર સંબંધિત દરેક વસ્તુ માટે સમાન રીતે મહત્વપૂર્ણ છે.

જ્યારે મેં Twitch પર કામ કર્યું, ત્યારે અમે Amazon ની મિશ્ર એમ્બેડેડ અને AWS સિસ્ટમની અંદર સેવાઓને ઝડપી બનાવી. અમે મંથન કર્યું અને ઘણી માઈક્રો સર્વિસિસને ટેકો આપ્યો, ઓપરેશનલ ખર્ચમાં વધારો કર્યો. ચર્ચાઓ કંઈક આના જેવી થઈ:

• Я: અરે, એક માઇક્રોસર્વિસને ઓવરક્લોક કરવા માટે તે ઘણી બધી ચેષ્ટાઓ છે. AWS એકાઉન્ટ બનાવવા માટે મારે આ કચરાનો ઉપયોગ કરવો પડશે (અમે 2 એકાઉન્ટ પર ગયા માઇક્રોસર્વિસ), પછી આ ચેતવણીઓ સેટ કરવા માટે, આ કોડ રીપોઝીટરી માટે, અને આ ઇમેઇલ સૂચિ માટે, અને પછી આ...
• લીડ: ચાલો તેને સ્ક્રિપ્ટ કરીએ અને ઠીક છે.
• Я: ઠીક છે, પણ સ્ક્રિપ્ટ પોતે બદલાઈ જશે. આ તમામ બિલ્ટ-ઇન એમેઝોન ગીઝમોઝ અપ ટુ ડેટ છે કે નહીં તે તપાસવા માટે અમને એક રીતની જરૂર પડશે.
• લીડ: સારું લાગે છે. અને અમે આ માટે સ્ક્રિપ્ટ લખીશું.
• Я: સરસ! અને સ્ક્રિપ્ટને કદાચ હજુ પણ પરિમાણો સેટ કરવાની જરૂર પડશે. શું તે તેમને સ્વીકારશે?
• લીડ: તે જ્યાં જાય છે તેને લઈ જવા દો!
• Я: પ્રક્રિયા બદલાઈ શકે છે અને પછાત સુસંગતતા ખોવાઈ જશે. અમુક પ્રકારના સિમેન્ટીક વર્ઝન કંટ્રોલની જરૂર પડશે.
• લીડ: મહાન વિચાર!
• Я: ટૂલ્સને યુઝર ઈન્ટરફેસની અંદર મેન્યુઅલી બદલી શકાય છે. અમને આને તપાસવા અને ઠીક કરવા માટે એક રીતની જરૂર પડશે.

…3 વર્ષ પછી:

• લીડ: અને અમને ટેરાફોર્મ મળ્યું.

વાર્તાની નૈતિકતા છે: ભલે તમે એમેઝોન દરેક બાબતમાં હીલ્સ પર માથું, તમે હજી પણ AWS માંથી ન હોય તેવી કોઈ વસ્તુનો ઉપયોગ કરી રહ્યાં છો, અને આ સેવાઓની સ્થિતિ છે જે તે સ્થિતિને સમન્વયિત રાખવા માટે રૂપરેખાંકન ભાષાનો ઉપયોગ કરે છે.

ક્લાઉડફોર્મેશન લેમ્બડા વિ ગિટ મોડ્યુલ્સ ટેરાફોર્મ

lambda એ કસ્ટમ લોજિક સમસ્યા માટે CloudFormation નો ઉકેલ છે. લેમ્બડા સાથે તમે કરી શકો છો મેક્રો બનાવો અથવા વપરાશકર્તા સંસાધન. આ અભિગમ વધારાની જટિલતાઓને રજૂ કરે છે જે ટેરાફોર્મના ગિટ મોડ્યુલોના સિમેન્ટીક સંસ્કરણમાં હાજર નથી. મારા માટે, આ બધા વપરાશકર્તા લેમ્બડાસ (અને આ ડઝનેક AWS એકાઉન્ટ્સ છે) માટે પરવાનગીઓનું સંચાલન કરવાની સૌથી વધુ દબાણની સમસ્યા હતી. બીજી મહત્વની સમસ્યા એ હતી કે “પહેલા શું આવ્યું, ચિકન કે ઈંડું?” સમસ્યા: તે લેમ્બડા કોડ સાથે સંબંધિત હતી. આ ફંક્શન પોતે જ ઈન્ફ્રાસ્ટ્રક્ચર અને કોડ છે, અને તેને પોતે મોનિટરિંગ અને અપડેટ્સની જરૂર છે. શબપેટીમાં અંતિમ ખીલી એ લેમ્બડા કોડ ફેરફારોને અર્થપૂર્ણ રીતે અપડેટ કરવામાં મુશ્કેલી હતી; અમારે એ પણ સુનિશ્ચિત કરવાનું હતું કે સીધા આદેશ વિના સ્ટેક ક્રિયાઓ રન વચ્ચે બદલાઈ ન જાય.

મને યાદ છે કે એકવાર હું ક્લાસિક લોડ બેલેન્સર સાથે સ્થિતિસ્થાપક બીનસ્ટાલ્ક પર્યાવરણ માટે કેનેરી ડિપ્લોયમેન્ટ બનાવવા માંગતો હતો. સૌથી સરળ બાબત એ છે કે ઉત્પાદન પર્યાવરણની બાજુમાં EB માટે બીજી જમાવટ કરવી, તેને એક પગલું આગળ લઈ જઈને: ઉત્પાદન પર્યાવરણમાં ડિપ્લોયમેન્ટ LB સાથે ઓટો-સ્કેલિંગ કેનેરી ડિપ્લોયમેન્ટ જૂથનું સંયોજન. અને ત્યારથી Terraform ઉપયોગ કરે છે નિષ્કર્ષ તરીકે ASG beantalk, આને ટેરાફોર્મમાં કોડની 4 વધારાની લાઇનની જરૂર પડશે. જ્યારે મેં પૂછ્યું કે ક્લાઉડફોર્મેશનમાં કોઈ તુલનાત્મક ઉકેલ છે કે કેમ, તેઓએ મને ડિપ્લોયમેન્ટ પાઇપલાઇન અને દરેક વસ્તુ સાથેના સંપૂર્ણ ગિટ રિપોઝીટરી તરફ નિર્દેશ કર્યો, બધું જ કંઈક માટે જે ટેરાફોર્મ કોડની નબળી 4 લાઇન કરી શકે છે.

તે ડ્રિફ્ટને વધુ સારી રીતે શોધે છે

ખાતરી કરો કે વાસ્તવિકતા અપેક્ષાઓ સાથે મેળ ખાય છે.

ડ્રિફ્ટ ડિટેક્શન કોડ સુવિધા તરીકે ખૂબ જ શક્તિશાળી કામગીરી છે કારણ કે તે ખાતરી કરવામાં મદદ કરે છે કે વાસ્તવિકતા અપેક્ષાઓ સાથે મેળ ખાય છે. તે CloudFormation અને Terraform બંને સાથે ઉપલબ્ધ છે. પરંતુ જેમ જેમ પ્રોડક્શન સ્ટેક વધતો ગયો તેમ, ક્લાઉડફોર્મેશનમાં ડ્રિફ્ટની શોધમાં વધુને વધુ ખોટા શોધો થયા.

ટેરાફોર્મ સાથે તમારી પાસે ડ્રિફ્ટ ડિટેક્શન માટે વધુ અદ્યતન લાઇફસાઇકલ હુક્સ છે. ઉદાહરણ તરીકે, તમે આદેશ દાખલ કરો અવગણો_ફેરફારો જો તમે તમારા સમગ્ર ECS ડિપ્લોયમેન્ટમાં ફેરફારોને અવગણ્યા વિના ચોક્કસ કાર્ય વ્યાખ્યામાં ફેરફારોને અવગણવા માંગતા હોવ તો સીધા ECS કાર્ય વ્યાખ્યામાં.

સીડીકે અને ક્લાઉડફોર્મેશનનું ભવિષ્ય

ક્લાઉડફોર્મેશનને મોટા, ક્રોસ-ઇન્ફ્રાસ્ટ્રક્ચર સ્કેલ પર સંચાલિત કરવું મુશ્કેલ છે. આમાંની ઘણી મુશ્કેલીઓ ઓળખાય છે અને સાધનને જેવી વસ્તુઓની જરૂર છે aws-cdk, કોડમાં ક્લાઉડ ઈન્ફ્રાસ્ટ્રક્ચરને વ્યાખ્યાયિત કરવા અને તેને AWS CloudFormation દ્વારા ચલાવવા માટેનું માળખું. aws-cdk માટે ભવિષ્ય શું ધરાવે છે તે જોવું રસપ્રદ રહેશે, પરંતુ ટેરાફોર્મની અન્ય શક્તિઓ સાથે સ્પર્ધા કરવામાં તેને મુશ્કેલ સમય આવશે; ક્લાઉડફોર્મેશનને અદ્યતન લાવવા માટે, વૈશ્વિક ફેરફારોની જરૂર પડશે.

જેથી ટેરાફોર્મ નિરાશ ન થાય

આ "કોડ તરીકે ઇન્ફ્રાસ્ટ્રક્ચર" છે, અને "ટેક્સ્ટ તરીકે" નથી.

ટેરાફોર્મની મારી પ્રથમ છાપ ઘણી ખરાબ હતી. મને લાગે છે કે હું માત્ર અભિગમ સમજી શક્યો નથી. લગભગ તમામ ઇજનેરો અનૈચ્છિક રીતે તેને ટેક્સ્ટ ફોર્મેટ તરીકે સમજે છે જેને ઇચ્છિત ઇન્ફ્રાસ્ટ્રક્ચરમાં રૂપાંતરિત કરવાની જરૂર છે. આ રીતે ન કરો.

સારા સોફ્ટવેર ડેવલપમેન્ટના નિયમો ટેરાફોર્મને પણ લાગુ પડે છે.

મેં જોયું છે કે સારા કોડ બનાવવા માટે અપનાવવામાં આવતી ઘણી પ્રથાઓને ટેરાફોર્મમાં અવગણવામાં આવી રહી છે. તમે સારા પ્રોગ્રામર બનવા માટે વર્ષોથી અભ્યાસ કર્યો છે. તમે ટેરાફોર્મ સાથે કામ કરી રહ્યાં છો એટલા માટે જ આ અનુભવ છોડશો નહીં. સારા સોફ્ટવેર ડેવલપમેન્ટના નિયમો ટેરાફોર્મને લાગુ પડે છે.

કોડ કેવી રીતે દસ્તાવેજીકૃત કરી શકાતો નથી?

મેં બિલકુલ દસ્તાવેજો વિના વિશાળ ટેરાફોર્મ સ્ટેક્સ જોયા છે. તમે પૃષ્ઠોમાં કોડ કેવી રીતે લખી શકો છો - બિલકુલ કોઈ દસ્તાવેજો વિના? દસ્તાવેજો ઉમેરો જે સમજાવે છે કે તમારા કોડ ટેરાફોર્મ (શબ્દ "કોડ" પર ભાર), શા માટે આ વિભાગ ખૂબ મહત્વપૂર્ણ છે અને તમે શું કરો છો.

અમે સેવાઓને કેવી રીતે જમાવી શકીએ જે એક સમયે એક મોટું મુખ્ય() કાર્ય હતું?

મેં એક મોડ્યુલ તરીકે રજૂ કરેલા ખૂબ જ જટિલ ટેરાફોર્મ સ્ટેક્સ જોયા છે. શા માટે આપણે આ રીતે સોફ્ટવેર જમાવતા નથી? શા માટે આપણે મોટા કાર્યોને નાનામાં વિભાજિત કરીએ છીએ? સમાન જવાબો ટેરાફોર્મ પર લાગુ થાય છે. જો તમારું મોડ્યુલ ખૂબ મોટું છે, તો તમારે તેને નાના મોડ્યુલમાં વિભાજીત કરવાની જરૂર છે.

શું તમારી કંપની પુસ્તકાલયોનો ઉપયોગ કરતી નથી?

મેં જોયું છે કે કેવી રીતે ઇજનેરો, ટેરાફોર્મનો ઉપયોગ કરીને એક નવો પ્રોજેક્ટ બનાવતા, મૂર્ખતાપૂર્વક અન્ય પ્રોજેક્ટ્સમાંથી વિશાળ હિસ્સાને તેમના પોતાનામાં કોપી-પેસ્ટ કરે છે, અને પછી તે કામ કરવાનું શરૂ કરે ત્યાં સુધી તેમની સાથે ટિંકર કરે છે. શું તમે તમારી કંપનીમાં "લડાઇ" કોડ સાથે આ રીતે કામ કરશો? અમે ફક્ત પુસ્તકાલયોનો ઉપયોગ કરતા નથી. હા, દરેક વસ્તુ પુસ્તકાલય હોવી જરૂરી નથી, પરંતુ આપણે સિદ્ધાંતમાં વહેંચાયેલ પુસ્તકાલયો વિના ક્યાં છીએ?!

શું તમે PEP8 અથવા gofmt નો ઉપયોગ નથી કરતા?

મોટાભાગની ભાષાઓમાં પ્રમાણભૂત, સ્વીકૃત ફોર્મેટિંગ સ્કીમ હોય છે. પાયથોનમાં આ PEP8 છે. Go માં - gofmt. ટેરાફોર્મનું પોતાનું છે: terraform fmt. તમારા સ્વાસ્થ્ય માટે તેનો આનંદ માણો!

શું તમે JavaScript ને જાણ્યા વગર React નો ઉપયોગ કરશો?

ટેરાફોર્મ મોડ્યુલ્સ તમે બનાવેલ જટિલ ઈન્ફ્રાસ્ટ્રક્ચરના અમુક ભાગને સરળ બનાવી શકે છે, પરંતુ તેનો અર્થ એ નથી કે તમે તેની સાથે બિલકુલ ટિંકર કરી શકતા નથી. સંસાધનોને સમજ્યા વિના ટેરાફોર્મનો યોગ્ય રીતે ઉપયોગ કરવા માંગો છો? તમે વિનાશકારી છો: સમય પસાર થશે, અને તમે ક્યારેય ટેરાફોર્મમાં નિપુણતા મેળવી શકશો નહીં.

શું તમે સિંગલટોન અથવા ડિપેન્ડન્સી ઈન્જેક્શન સાથે કોડિંગ કરી રહ્યાં છો?

ડિપેન્ડન્સી ઈન્જેક્શન એ સોફ્ટવેર ડેવલપમેન્ટ માટે માન્ય શ્રેષ્ઠ પ્રેક્ટિસ છે અને તેને સિંગલટોન કરતાં પ્રાધાન્ય આપવામાં આવે છે. ટેરાફોર્મમાં આ કેવી રીતે ઉપયોગી છે? મેં ટેરાફોર્મ મોડ્યુલો જોયા છે જે રિમોટ સ્ટેટ પર આધાર રાખે છે. દૂરસ્થ સ્થિતિને પુનઃપ્રાપ્ત કરતા મોડ્યુલો લખવાને બદલે, પેરામીટર્સ લેતું મોડ્યુલ લખો. અને પછી આ પરિમાણોને મોડ્યુલમાં પસાર કરો.

શું તમારી લાઈબ્રેરીઓ દસ વસ્તુઓ સારી રીતે કરે છે કે એક વસ્તુ સારી?

પુસ્તકાલયો જે શ્રેષ્ઠ કાર્ય કરે છે તે તે છે જે એક કાર્ય પર ધ્યાન કેન્દ્રિત કરે છે જે તેઓ ખૂબ સારી રીતે કરે છે. મોટા ટેરાફોર્મ મોડ્યુલો લખવાને બદલે કે જે એક જ સમયે બધું કરવાનો પ્રયાસ કરે છે, તેના ભાગો બનાવો જે એક વસ્તુ સારી રીતે કરે છે. અને પછી તેમને જરૂર મુજબ ભેગું કરો.

તમે પછાત સુસંગતતા વિના પુસ્તકાલયોમાં ફેરફાર કેવી રીતે કરશો?

એક સામાન્ય ટેરાફોર્મ મોડ્યુલ, નિયમિત લાઇબ્રેરીની જેમ, પાછળની તરફ સુસંગત થયા વિના વપરાશકર્તાઓને ફેરફારોની વાતચીત કરવાની જરૂર છે. જ્યારે આ ફેરફારો પુસ્તકાલયોમાં થાય છે ત્યારે તે હેરાન કરે છે, અને જ્યારે ટેરાફોર્મ મોડ્યુલોમાં બિન-પછાત-સુસંગત ફેરફારો કરવામાં આવે છે ત્યારે તે હેરાન કરે છે. ટેરાફોર્મ મોડ્યુલોનો ઉપયોગ કરતી વખતે ગિટ ટૅગ્સ અને સેમવરનો ઉપયોગ કરવાની ભલામણ કરવામાં આવે છે.

શું તમારી ઉત્પાદન સેવા તમારા લેપટોપ પર ચાલી રહી છે કે ડેટા સેન્ટરમાં?

હાશિકોર્પ જેવા સાધનો ધરાવે છે ટેરાફોર્મ વાદળ તમારા ટેરાફોર્મ ચલાવવા માટે. આ કેન્દ્રિય સેવાઓ ટેરાફોર્મ ફેરફારોનું સંચાલન, ઑડિટ અને મંજૂર કરવાનું સરળ બનાવે છે.

શું તમે પરીક્ષણો લખતા નથી?

ઇજનેરો ઓળખે છે કે કોડનું પરીક્ષણ કરવાની જરૂર છે, પરંતુ ટેરાફોર્મ સાથે કામ કરતી વખતે તેઓ ઘણીવાર પરીક્ષણ કરવાનું ભૂલી જાય છે. ઈન્ફ્રાસ્ટ્રક્ચર માટે, આ વિશ્વાસઘાત ક્ષણોથી ભરપૂર છે. મારી સલાહ એ છે કે CI/CD દરમિયાન પરીક્ષણ માટે યોગ્ય રીતે ગોઠવી શકાય તેવા મોડ્યુલોનો ઉપયોગ કરીને સ્ટેક્સનું “પરીક્ષણ” કરો અથવા “ઉદાહરણ બનાવો”.

ટેરાફોર્મ અને માઇક્રોસર્વિસિસ

માઇક્રોસર્વિસ કંપનીઓનું જીવન અને મૃત્યુ નવા માઇક્રોસર્વિસ વર્કસ્ટેક્સની ઝડપ, નવીનતા અને વિક્ષેપ પર આધારિત છે.

માઇક્રોસર્વિસ આર્કિટેક્ચર્સ સાથે સંકળાયેલું સૌથી સામાન્ય નકારાત્મક પાસું, અને જેને દૂર કરી શકાતું નથી, તે કોડ સાથે નહીં પણ કાર્ય સાથે સંબંધિત છે. જો તમે ટેરાફોર્મને માઇક્રોસર્વિસિસ આર્કિટેક્ચરની માત્ર ઇન્ફ્રાસ્ટ્રક્ચર બાજુને સ્વચાલિત કરવાની રીત તરીકે વિચારો છો, તો તમે સિસ્ટમના સાચા લાભો ગુમાવી રહ્યાં છો. હવે તે પહેલેથી જ છે બધું કોડ જેવું છે.

સોર્સ: www.habr.com