ભવિષ્ય માટે ટેરાફોર્મમાં ઈન્ફ્રાસ્ટ્રક્ચરનું વર્ણન. એન્ટોન બાબેન્કો (2018)

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

તમારું ઇન્ફ્રાસ્ટ્રક્ચર લગભગ ચોક્કસપણે સરળ રીતે શરૂ થાય છે: થોડા સંસાધનો + થોડા વિકાસકર્તાઓ. સમય જતાં, તે તમામ પ્રકારની દિશાઓમાં વધે છે. શું તમે ટેરાફોર્મ મોડ્યુલોમાં સંસાધનોને જૂથબદ્ધ કરવા, કોડને ફોલ્ડર્સમાં ગોઠવવા અને બીજું શું ખોટું થઈ શકે તે રીતો શોધો છો? (પ્રખ્યાત છેલ્લા શબ્દો)

સમય પસાર થાય છે અને તમને લાગે છે કે તમારું ઇન્ફ્રાસ્ટ્રક્ચર તમારું નવું પાલતુ છે, પણ શા માટે? તમે ઈન્ફ્રાસ્ટ્રક્ચરમાં અકલ્પનીય ફેરફારો વિશે ચિંતિત છો, તમે ઈન્ફ્રાસ્ટ્રક્ચર અને કોડને સ્પર્શ કરવામાં ડરશો - પરિણામે, તમે નવી કાર્યક્ષમતામાં વિલંબ કરો છો અથવા ગુણવત્તામાં ઘટાડો કરો છો...

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

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

ડિસક્લેમર: મેં નોંધ્યું છે કે આ રિપોર્ટ નવેમ્બર 2018 નો છે—2 વર્ષ વીતી ચૂક્યા છે. અહેવાલમાં ચર્ચા કરાયેલ ટેરાફોર્મ 0.11 નું સંસ્કરણ હવે સમર્થિત નથી. છેલ્લા 2 વર્ષોમાં, 2 નવી રિલીઝ રિલીઝ કરવામાં આવી છે, જેમાં ઘણી બધી નવીનતાઓ, સુધારાઓ અને ફેરફારો છે. કૃપા કરીને આના પર ધ્યાન આપો અને દસ્તાવેજો તપાસો.

સંદર્ભો:

• ટેરાફોર્મ-સમુદાય-મોડ્યુલ્સ + terraform-aws-મોડ્યુલ્સ
• antonbabenko/pre-commit-terraform - ઓટો-ફોર્મેટિંગ કોડ અને દસ્તાવેજીકરણ
• એન્ટોનબેબેન્કો/ટેરાપિન - ટેરાફોર્મ મોડ્યુલ્સનું જનરેટર (WIP)
• antonbabenko/modules.tf-lambda - વિઝ્યુઅલ ડાયાગ્રામ્સ (WIP) થી ટેરાફોર્મ કોડ જનરેટર
• www.terraform-best-practices.com
• medium.com/@anton.babenko (નવી પોસ્ટ મારી વ્યક્તિગત વેબસાઇટ www.antonbabenko.com/ પર છે)
• @antonbabenko - Twitter, અને વિવિધ સ્લેક્સનો સમૂહ

મારું નામ એન્ટોન બાબેન્કો છે. તમારામાંથી કેટલાક કદાચ મેં લખેલા કોડનો ઉપયોગ કર્યો છે. હવે હું આ વિશે પહેલા કરતા વધુ આત્મવિશ્વાસ સાથે વાત કરીશ, કારણ કે મારી પાસે આંકડાઓની ઍક્સેસ છે.

હું ટેરાફોર્મ પર કામ કરું છું અને 2015 થી ટેરાફોર્મ અને એમેઝોન સંબંધિત મોટી સંખ્યામાં ઓપન સોર્સ પ્રોજેક્ટ્સમાં સક્રિય સહભાગી અને યોગદાન આપનાર છું.

ત્યારથી મેં તેને રસપ્રદ રીતે મૂકવા માટે પૂરતો કોડ લખ્યો છે. અને હવે હું તમને આ વિશે કહેવાનો પ્રયત્ન કરીશ.

હું ટેરાફોર્મ સાથે કામ કરવાની જટિલતાઓ અને વિશિષ્ટતાઓ વિશે વાત કરીશ. પરંતુ તે ખરેખર હાઇલોડનો વિષય નથી. અને હવે તમે સમજી શકશો કે શા માટે.

સમય જતાં, મેં ટેરાફોર્મ મોડ્યુલ લખવાનું શરૂ કર્યું. વપરાશકર્તાઓએ પ્રશ્નો લખ્યા, મેં તેમને ફરીથી લખ્યા. પછી મેં પ્રી-કમિટ હૂક વગેરેનો ઉપયોગ કરીને કોડને ફોર્મેટ કરવા માટે વિવિધ ઉપયોગિતાઓ લખી.

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

હું યુક્રેનનો છું. હું ઘણા વર્ષોથી નોર્વેમાં રહું છું.

ઉપરાંત, આ રિપોર્ટ માટેની માહિતી એવા લોકો પાસેથી એકત્રિત કરવામાં આવી હતી જેઓ મારું નામ જાણે છે અને મને સોશિયલ નેટવર્ક પર શોધે છે. હું લગભગ હંમેશા એક જ ઉપનામ રાખું છું.

https://github.com/terraform-aws-modules
https://registry.terraform.io/namespaces/terraform-aws-modules

મેં ઉલ્લેખ કર્યો છે તેમ, હું ટેરાફોર્મ AWS મોડ્યુલોનો મુખ્ય જાળવણીકાર છું, જે GitHub પરના સૌથી મોટા ભંડારોમાંથી એક છે જ્યાં અમે સૌથી સામાન્ય કાર્યો માટે મોડ્યુલો હોસ્ટ કરીએ છીએ: VPC, Autoscaling, RDS.

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

ટેરાફોર્મ 2014 માં એક ઉપયોગિતા તરીકે દેખાયું જેણે તમને કોડ તરીકે ઈન્ફ્રાસ્ટ્રક્ચર લખવા, પ્લાન કરવા અને મેનેજ કરવાની મંજૂરી આપી. અહીંનો મુખ્ય ખ્યાલ "કોડ તરીકે ઈન્ફ્રાસ્ટ્રક્ચર" છે.

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

નિયમિત ટેરાફોર્મ રૂપરેખાંકન ફાઈલ આના જેવી દેખાય છે, જ્યાં આપણે પ્રથમ કેટલાક ચલોને વ્યાખ્યાયિત કરીએ છીએ.

આ કિસ્સામાં અમે "aws_region" ને વ્યાખ્યાયિત કરીએ છીએ.

પછી અમે વર્ણન કરીએ છીએ કે આપણે કયા સંસાધનો બનાવવા માંગીએ છીએ.

નિર્ભરતા અને પ્રદાતાઓ લોડ કરવા માટે અમે કેટલાક આદેશો ચલાવીએ છીએ, ખાસ કરીને "ટેરાફોર્મ ઇનિટ".

અને ઉલ્લેખિત રૂપરેખાંકન અમે બનાવેલા સંસાધનો સાથે મેળ ખાય છે કે કેમ તે ચકાસવા માટે અમે "terraform apply" આદેશ ચલાવીએ છીએ. અમે પહેલાં કંઈપણ બનાવ્યું ન હોવાથી, ટેરાફોર્મ અમને આ સંસાધનો બનાવવા માટે સંકેત આપે છે.

અમે આની પુષ્ટિ કરીએ છીએ. આમ આપણે seasnail નામની ડોલ બનાવીએ છીએ.

ત્યાં ઘણી સમાન ઉપયોગિતાઓ પણ છે. તમારામાંથી ઘણા જેઓ Amazon નો ઉપયોગ કરે છે તેઓ AWS CloudFormation અથવા Google Cloud ડિપ્લોયમેન્ટ મેનેજર અથવા Azure Resource Manager જાણે છે. આ દરેક સાર્વજનિક ક્લાઉડ પ્રદાતાઓમાં સંસાધનોનું સંચાલન કરવા માટે તેમાંના દરેકનું પોતાનું કોઈ પ્રકારનું અમલીકરણ છે. ટેરાફોર્મ ખાસ કરીને ઉપયોગી છે કારણ કે તે તમને 100 થી વધુ પ્રદાતાઓને સંચાલિત કરવાની મંજૂરી આપે છે. (વધુ વિગતો અહીં)

ટેરાફોર્મે શરૂઆતથી જ જે લક્ષ્યોને અનુસર્યા છે:

• ટેરાફોર્મ સંસાધનોનું એક દૃશ્ય પ્રદાન કરે છે.
• તમને તમામ આધુનિક પ્લેટફોર્મને સપોર્ટ કરવાની મંજૂરી આપે છે.
• અને ટેરાફોર્મને શરૂઆતથી જ એક ઉપયોગિતા તરીકે ડિઝાઇન કરવામાં આવ્યું હતું જે તમને ઇન્ફ્રાસ્ટ્રક્ચરને સુરક્ષિત રીતે અને અનુમાનિત રીતે બદલવાની મંજૂરી આપે છે.

2014 માં, આ સંદર્ભમાં "અનુમાનિત" શબ્દ ખૂબ જ અસામાન્ય લાગતો હતો.

ટેરાફોર્મ એ સાર્વત્રિક ઉપયોગિતા છે. જો તમારી પાસે API છે, તો પછી તમે સંપૂર્ણપણે બધું નિયંત્રિત કરી શકો છો:

• તમે ઇચ્છો તે બધું મેનેજ કરવા માટે તમે 120 થી વધુ પ્રદાતાઓનો ઉપયોગ કરી શકો છો.
• ઉદાહરણ તરીકે, તમે GitHub રિપોઝીટરીઝની ઍક્સેસનું વર્ણન કરવા માટે Terraform નો ઉપયોગ કરી શકો છો.
• તમે જીરામાં બગ્સ બનાવી અને બંધ પણ કરી શકો છો.
• તમે નવા રેલિક મેટ્રિક્સનું સંચાલન કરી શકો છો.
• જો તમે ખરેખર ઇચ્છો તો તમે ડ્રોપબૉક્સમાં ફાઇલો પણ બનાવી શકો છો.

આ બધું ટેરાફોર્મ પ્રદાતાઓનો ઉપયોગ કરીને પ્રાપ્ત થાય છે, જેની પાસે એક ઓપન API છે જેનું વર્ણન Go માં કરી શકાય છે.

ચાલો કહીએ કે અમે ટેરાફોર્મનો ઉપયોગ કરવાનું શરૂ કર્યું, સાઇટ પર કેટલાક દસ્તાવેજો વાંચ્યા, કેટલાક વિડિયો જોયા, અને main.tf લખવાનું શરૂ કર્યું, જેમ કે મેં અગાઉની સ્લાઇડ્સમાં બતાવ્યું હતું.

અને બધું સરસ છે, તમારી પાસે એક ફાઇલ છે જે VPC બનાવે છે.

જો તમે VPC બનાવવા માંગો છો, તો પછી તમે લગભગ આ 12 રેખાઓનો ઉલ્લેખ કરો. તમે કયા પ્રદેશમાં બનાવવા માંગો છો તેનું વર્ણન કરો, IP એડ્રેસનો કયો cidr_block વાપરવો. બસ એટલું જ.

સ્વાભાવિક રીતે, પ્રોજેક્ટ ધીમે ધીમે વધશે.

અને તમે ત્યાં ઘણી બધી નવી સામગ્રી ઉમેરશો: સંસાધનો, ડેટા સ્ત્રોતો, તમે નવા પ્રદાતાઓ સાથે એકીકૃત થશો, અચાનક તમે તમારા GitHub એકાઉન્ટમાં વપરાશકર્તાઓને મેનેજ કરવા માટે ટેરાફોર્મનો ઉપયોગ કરવા માંગો છો, વગેરે. તમે ઉપયોગ કરવા માંગો છો. વિવિધ DNS પ્રદાતાઓ, બધું પાર કરો. ટેરાફોર્મ આને સરળ બનાવે છે.

ચાલો નીચેના ઉદાહરણ જોઈએ.

તમે ધીમે ધીમે internet_gateway ઉમેરો છો કારણ કે તમે તમારા VPC ના સંસાધનો ઇચ્છો છો કે ઇન્ટરનેટ ઍક્સેસ હોય. આ એક સારો વિચાર છે.

પરિણામ આ main.tf છે:

આ main.tf નો ટોચનો ભાગ છે.

આ main.tf નો નીચેનો ભાગ છે.

પછી તમે સબનેટ ઉમેરો. જ્યાં સુધી તમે NAT ગેટવેઝ, રૂટ્સ, રૂટીંગ કોષ્ટકો અને અન્ય સબનેટ્સનો સમૂહ ઉમેરવા માંગો છો, ત્યાં સુધીમાં તમારી પાસે 38 લાઇન નહીં, પરંતુ લગભગ 200-300 લાઇન હશે.

એટલે કે, તમારી main.tf ફાઇલ ધીમે ધીમે વધી રહી છે. અને ઘણી વાર લોકો બધું એક ફાઈલમાં મૂકે છે. main.tf માં 10-20 Kb દેખાય છે. કલ્પના કરો કે 10-20 Kb એ ટેક્સ્ટ સામગ્રી છે. અને દરેક વસ્તુ દરેક વસ્તુ સાથે જોડાયેલ છે. આ સાથે કામ કરવું ધીમે ધીમે મુશ્કેલ બની રહ્યું છે. 10-20 Kb એ સારો વપરાશકર્તા કેસ છે, ક્યારેક વધુ. અને લોકો હંમેશા એવું માનતા નથી કે આ ખરાબ છે.

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

• કોડ વધી રહ્યો છે.
• સંસાધનો વચ્ચેની નિર્ભરતા પણ વધી રહી છે.

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

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

તેથી અમે એ સમજવાનો પ્રયાસ કરી રહ્યા છીએ કે અમે અમારા 10-20-30 Kb કોડને કેવી રીતે ઑપ્ટિમાઇઝ કરીશું. અમે ધીમે ધીમે સમજી રહ્યા છીએ કે આપણે કેટલાક મોડ્યુલનો ઉપયોગ કરવાની જરૂર છે.

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

સંસાધન મોડ્યુલનું ઉદાહરણ.

જ્યારે આપણે સંસાધન મોડ્યુલને કૉલ કરીએ છીએ, ત્યારે અમે સ્પષ્ટ કરીએ છીએ કે આપણે તેના સમાવિષ્ટો કયા પાથથી લોડ કરીશું.

અમે સૂચવે છે કે અમે કયું સંસ્કરણ ડાઉનલોડ કરવા માંગીએ છીએ.

અમે ત્યાં દલીલોનો સમૂહ પસાર કરીએ છીએ. બસ એટલું જ. જ્યારે આપણે આ મોડ્યુલનો ઉપયોગ કરીએ ત્યારે આટલું જ જાણવાની જરૂર છે.

ઘણા લોકો વિચારે છે કે જો તેઓ નવીનતમ સંસ્કરણનો ઉપયોગ કરે છે, તો બધું સ્થિર થઈ જશે. પણ ના. ઈન્ફ્રાસ્ટ્રક્ચરનું સંસ્કરણ હોવું જોઈએ; આપણે સ્પષ્ટપણે જવાબ આપવો જોઈએ કે આ અથવા તે ઘટક કયા સંસ્કરણ પર તૈનાત કરવામાં આવ્યું હતું.

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

વપરાશકર્તાને તે જાણવાની જરૂર નથી કે તે અંદર કેવી રીતે બને છે.

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

આગળ હું આના કેટલાક ઉદાહરણો બતાવીશ.

ઈન્ફ્રાસ્ટ્રક્ચર મોડ્યુલને બરાબર એ જ રીતે કહેવામાં આવે છે.

સામગ્રી ક્યાંથી ડાઉનલોડ કરવી તે સ્ત્રોત દર્શાવેલ છે.

મૂલ્યોનો સમૂહ આ મોડ્યુલમાં પસાર થાય છે અને પસાર થાય છે.

આગળ, આ મોડ્યુલની અંદર, VPC અથવા એપ્લિકેશન લોડ બેલેન્સર બનાવવા માટે, અથવા સુરક્ષા-જૂથ બનાવવા અથવા સ્થિતિસ્થાપક કન્ટેનર સર્વિસ ક્લસ્ટર માટે સંસાધન મોડ્યુલોનો સમૂહ બોલાવવામાં આવે છે.

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

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

ચાલો આગળ આ મોડ્યુલો કેવી રીતે લખવા તેના પર એક નજર કરીએ. પછી અમે જોઈશું કે તેમને કેવી રીતે કૉલ કરવો અને કોડ સાથે કેવી રીતે કાર્ય કરવું.

ટેરાફોર્મ રજિસ્ટ્રી - https://registry.terraform.io/

ટિપ #0 એ છે કે સંસાધન મોડ્યુલો ન લખો. આમાંના મોટાભાગના મોડ્યુલો તમારા માટે પહેલેથી જ લખેલા છે. મેં કહ્યું તેમ, તેઓ ઓપન સોર્સ છે, તેમાં તમારો કોઈ પણ વ્યવસાય તર્ક નથી, તેમની પાસે IP સરનામાં, પાસવર્ડ્સ વગેરે માટે હાર્ડકોડેડ મૂલ્યો નથી. મોડ્યુલ ખૂબ જ લવચીક છે. અને મોટે ભાગે તે પહેલેથી જ લખવામાં આવ્યું છે. એમેઝોનમાંથી સંસાધનો માટે ઘણા મોડ્યુલો છે. લગભગ 650. અને તેમાંથી મોટા ભાગની ગુણવત્તા સારી છે.

આ ઉદાહરણમાં, કોઈ તમારી પાસે આવ્યું અને કહ્યું, “હું ડેટાબેઝનું સંચાલન કરવા સક્ષમ બનવા માંગુ છું. એક મોડ્યુલ બનાવો જેથી હું ડેટાબેઝ બનાવી શકું." વ્યક્તિ એમેઝોન અથવા ટેરાફોર્મની અમલીકરણ વિગતો જાણતી નથી. તે ફક્ત કહે છે: "મારે MSSQL નું સંચાલન કરવું છે." એટલે કે, અમારો અર્થ એ છે કે તે અમારા મોડ્યુલને કૉલ કરશે, ત્યાં એન્જિનનો પ્રકાર પસાર કરશે અને સમય ઝોન સૂચવશે.

અને વ્યક્તિને ખબર ન હોવી જોઈએ કે અમે આ મોડ્યુલની અંદર બે અલગ-અલગ સંસાધનો બનાવીશું: એક MSSQL માટે, બીજું બધું માટે, માત્ર એટલા માટે કે Terraform 0.11 માં તમે વૈકલ્પિક તરીકે ટાઈમ ઝોન મૂલ્યોનો ઉલ્લેખ કરી શકતા નથી.

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

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

પરંતુ સમસ્યા એ છે કે ટેરાફોર્મ આ મોડ્યુલોને કેવી રીતે બોલાવે છે. ઉદાહરણ તરીકે, જો તમે દરેક વ્યક્તિગત વપરાશકર્તાને બનાવવા માટે મોડ્યુલને કૉલ કરો છો, તો ટેરાફોર્મ પહેલા સમગ્ર રીપોઝીટરી લોડ કરશે અને પછી તે ફોલ્ડર પર નેવિગેટ કરશે જ્યાં તે ચોક્કસ મોડ્યુલ સ્થિત છે. આ રીતે તમે દરેક વખતે એક મેગાબાઈટ ડાઉનલોડ કરશો. જો તમે 100 અથવા 200 વપરાશકર્તાઓનું સંચાલન કરો છો, તો પછી તમે 100 અથવા 200 મેગાબાઇટ્સ ડાઉનલોડ કરશો, અને પછી તે ફોલ્ડરમાં જાઓ. તેથી સ્વાભાવિક રીતે જ્યારે પણ તમે "Terraform init" ને હિટ કરો છો ત્યારે તમે સામગ્રીનો સમૂહ ડાઉનલોડ કરવા માંગતા નથી.

https://github.com/mbtproject/mbt

આ સમસ્યાના બે ઉકેલો છે. પ્રથમ સંબંધિત પાથનો ઉપયોગ કરવાનો છે. આ રીતે તમે કોડમાં સૂચવો છો કે ફોલ્ડર સ્થાનિક છે (./). અને તમે કંઈપણ લોંચ કરો તે પહેલાં, તમે સ્થાનિક રીતે આ રિપોઝીટરીનો ગિટ ક્લોન કરો છો. આ રીતે તમે એકવાર કરો.

ત્યાં, અલબત્ત, ઘણા બધા ડાઉનસાઇડ્સ છે. ઉદાહરણ તરીકે, તમે સંસ્કરણનો ઉપયોગ કરી શકતા નથી. અને આ સાથે જીવવું ક્યારેક મુશ્કેલ હોય છે.

બીજો ઉકેલ. જો તમારી પાસે ઘણા બધા સબમોડ્યુલ્સ છે અને તમારી પાસે પહેલેથી જ અમુક પ્રકારની સ્થાપિત પાઇપલાઇન છે, તો ત્યાં MBT પ્રોજેક્ટ છે, જે તમને મોનોરેપોઝીટરીમાંથી ઘણાં વિવિધ પેકેજો એકત્રિત કરવા અને તેમને S3 પર અપલોડ કરવાની મંજૂરી આપે છે. આ એક ખૂબ જ સારી રીત છે. આમ, iam-user-1.0.0.zip ફાઇલનું વજન માત્ર 1 Kb હશે, કારણ કે આ સંસાધન બનાવવા માટેનો કોડ ઘણો નાનો છે. અને તે ખૂબ ઝડપથી કામ કરશે.

ચાલો મોડ્યુલોમાં શું વાપરી શકાતું નથી તે વિશે વાત કરીએ.

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

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

બીજી દુષ્ટતા પ્રોવિઝનર છે. અહીં દુષ્ટતા એટલી મામૂલી નથી, કારણ કે જો તમે કોડ લખો છો અને તે તમારા માટે કામ કરે છે, તો પછી તમે વિચારી શકો છો કે જો તે કામ કરે છે, તો પછી તેને શા માટે બદલો.

દુષ્ટતા એ છે કે આ પ્રોવિઝનર ક્યારે શરૂ થશે તે તમે હંમેશા નિયંત્રિત કરતા નથી, સૌ પ્રથમ. અને બીજું, તમે aws ec2 નો અર્થ શું છે તે નિયંત્રિત કરતા નથી, એટલે કે હવે આપણે Linux અથવા Windows વિશે વાત કરી રહ્યા છીએ. તેથી તમે કંઈક એવું લખી શકતા નથી જે વિવિધ ઓપરેટિંગ સિસ્ટમ્સ પર અથવા વિવિધ વપરાશકર્તા કેસ માટે સમાન કાર્ય કરશે.

સૌથી સામાન્ય ઉદાહરણ, જે અધિકૃત દસ્તાવેજોમાં પણ સૂચવવામાં આવ્યું છે, તે છે કે જો તમે aws_instance લખો અને દલીલોનો સમૂહ સ્પષ્ટ કરો, તો તેમાં કંઈ ખોટું નથી જો તમે ત્યાં જોગવાઈ "લોકલ-એક્સેસી" નો ઉલ્લેખ કરો અને તમારી જવાબદારી ચલાવો. પ્લેબુક

હકીકતમાં, હા, તેમાં કંઈ ખોટું નથી. પરંતુ શાબ્દિક રૂપે ટૂંક સમયમાં તમને ખ્યાલ આવશે કે આ લોકલ-એક્ઝીક વસ્તુ અસ્તિત્વમાં નથી, ઉદાહરણ તરીકે, launch_configuration માં.

અને જ્યારે તમે launch_configuration નો ઉપયોગ કરો છો, અને તમે એક ઉદાહરણથી ઓટોસ્કેલિંગ જૂથ બનાવવા માંગો છો, તો પછી launch_configuration માં “provisioner” નો કોઈ ખ્યાલ નથી. "વપરાશકર્તા ડેટા" નો ખ્યાલ છે.

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

જો તમે હજુ પણ પ્રોવિઝનરને ચલાવવા માંગતા હોવ, કારણ કે તે એક ગ્લુઇંગ ઘટક છે, જ્યારે એક સંસાધન બનાવવામાં આવે છે, તે સમયે તમારે તમારા પ્રોવિઝનરને ચલાવવાની જરૂર છે, તમારો આદેશ. આવી ઘણી બધી પરિસ્થિતિઓ છે.

અને આ માટે સૌથી સાચો સ્ત્રોત કહેવાય છે null_resource. Null_resource એ બનાવટી સંસાધન છે જે વાસ્તવમાં ક્યારેય બનાવવામાં આવતું નથી. તે કંઈપણ સ્પર્શતું નથી, કોઈ API નથી, કોઈ ઑટોસ્કેલિંગ નથી. પરંતુ તે તમને આદેશ ક્યારે ચલાવવાનો છે તે નિયંત્રિત કરવાની મંજૂરી આપે છે. આ કિસ્સામાં, આદેશ બનાવટ દરમિયાન ચલાવવામાં આવે છે.

કડી http://bit.ly/common-traits-in-terraform-modules

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

જો તમે કંઈક લખવા માંગતા હોવ જેથી લોકો તેનો ઉપયોગ કરે, તો હું આ સંકેતોને અનુસરવાની ભલામણ કરું છું.

આ છે:

• દસ્તાવેજીકરણ અને ઉદાહરણો.
• સંપૂર્ણ કાર્યક્ષમતા.
• વાજબી ડિફોલ્ટ્સ.
• સ્વચ્છ કોડ.
• પરીક્ષણો.

પરીક્ષણો એક અલગ પરિસ્થિતિ છે કારણ કે તે લખવા માટે ખૂબ મુશ્કેલ છે. હું દસ્તાવેજો અને ઉદાહરણોમાં વધુ માનું છું.

તેથી, અમે મોડ્યુલો કેવી રીતે લખવા તે જોયું. બે દલીલો છે. પ્રથમ, જે સૌથી મહત્વપૂર્ણ છે, જો તમે કરી શકો તો લખવાનું નથી, કારણ કે ઘણા લોકો તમારા પહેલાં આ કાર્યો કરી ચૂક્યા છે. અને બીજું, જો તમે હજી પણ નક્કી કરો છો, તો પછી મોડ્યુલો અને પ્રોવિઝનર્સમાં પ્રદાતાઓનો ઉપયોગ ન કરવાનો પ્રયાસ કરો.

આ દસ્તાવેજીકરણનો ગ્રે ભાગ છે. તમે હવે વિચારી રહ્યા હશો: “કંઈક અસ્પષ્ટ છે. ખાતરી નથી." પણ છ મહિનામાં જોઈશું.

હવે ચાલો આ મોડ્યુલોને કેવી રીતે કૉલ કરવા તે વિશે વાત કરીએ.

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

બે ચરમસીમાઓ છે. પ્રથમ આત્યંતિક બધા એકમાં છે. અમારી પાસે એક માસ્ટર ફાઇલ છે. તે સમય માટે, ટેરાફોર્મ વેબસાઇટ પર આ સત્તાવાર શ્રેષ્ઠ પ્રથા હતી.

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

ઘણો સમય છે, ઉદાહરણ તરીકે, 5 મિનિટ. કેટલાક માટે આ ઘણો સમય છે. મેં એવા કિસ્સાઓ જોયા છે જેમાં 15 મિનિટ લાગી. AWS API એ દરેક સંસાધનની સ્થિતિ સાથે શું થઈ રહ્યું છે તે શોધવાનો પ્રયાસ કરવામાં 15 મિનિટ વિતાવી. આ ઘણો મોટો વિસ્તાર છે.

અને, સ્વાભાવિક રીતે, સંબંધિત સમસ્યા દેખાશે જ્યારે તમે એક જગ્યાએ કંઈક બદલવા માંગો છો, પછી તમે 15 મિનિટ રાહ જુઓ, અને તે તમને કેટલાક ફેરફારોનો કેનવાસ આપે છે. તમે થૂંક્યું, “હા” લખ્યું અને કંઈક ખોટું થયું. આ એક ખૂબ જ વાસ્તવિક ઉદાહરણ છે. ટેરાફોર્મ તમને સમસ્યાઓથી બચાવવાનો પ્રયાસ કરતું નથી. એટલે કે, તમને જે જોઈએ છે તે લખો. સમસ્યાઓ હશે - તમારી સમસ્યાઓ. જ્યારે ટેરાફોર્મ 0.11 તમને કોઈપણ રીતે મદદ કરવાનો પ્રયાસ કરતું નથી. 0.12 માં કેટલીક રસપ્રદ જગ્યાઓ છે જે તમને કહેવાની મંજૂરી આપે છે: "વાસ્યા, તમે ખરેખર આ ઇચ્છો છો, શું તમે તમારા હોશમાં આવી શકો છો?"

બીજી રીત આ વિસ્તારને ઘટાડવાનો છે, એટલે કે, એક જગ્યાએથી કોલ બીજી જગ્યાએથી ઓછા કનેક્ટ થઈ શકે છે.

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

આટલું બધું એક જગ્યાએ કોણ રહે છે? એક, બે, ત્રણ લોકો, એટલે કે, કોઈ તેનો ઉપયોગ કરી રહ્યું છે.

અને એક ચોક્કસ ઘટક, એક બ્લોક કે એક ઈન્ફ્રાસ્ટ્રક્ચર મોડ્યુલને કોણ કહે છે? પાંચ-સાત લોકો. આ ઠંડી છે.

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

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

હું કયા ઉકેલો છે તે સૂચવી શકું છું. જાદુ કરવા માટે તમે ટેરાફોર્મનો ઉપયોગ કરી શકો છો અથવા ટેરાફોર્મનો ઉપયોગ કરવા માટે મેકફાઈલ્સનો ઉપયોગ કરી શકો છો. અને જુઓ કે ત્યાં કંઈક બદલાયું છે, તો તમે તેને અહીં લોંચ કરી શકો છો.

તમને આ નિર્ણય કેવો લાગ્યો? શું કોઈ માને છે કે આ એક સરસ ઉપાય છે? હું એક સ્મિત જોઉં છું, દેખીતી રીતે શંકાઓ અંદર આવી ગઈ છે.

અલબત્ત, ઘરે આનો પ્રયાસ કરશો નહીં. ટેરાફોર્મને ક્યારેય ટેરાફોર્મથી ચલાવવા માટે ડિઝાઇન કરવામાં આવ્યું ન હતું.

એક અહેવાલમાં તેઓએ મને કહ્યું: "ના, આ કામ કરશે નહીં." મુદ્દો એ છે કે તે કામ ન કરવું જોઈએ. જો કે તે ખૂબ પ્રભાવશાળી લાગે છે જ્યારે તમે ટેરાફોર્મથી ટેરાફોર્મ અને પછી ટેરાફોર્મ લોંચ કરી શકો છો, તમારે તે ન કરવું જોઈએ. ટેરાફોર્મ હંમેશા ખૂબ જ સરળતાથી શરૂ થવું જોઈએ.

https://github.com/gruntwork-io/terragrunt/

જો તમને એક જગ્યાએ કંઈક બદલાયું હોય ત્યારે કોલ ઓર્કેસ્ટ્રેશનની જરૂર હોય, તો ટેરાગ્રન્ટ છે.

ટેરાગ્રન્ટ એ યુટિલિટી છે, ટેરાફોર્મનું એડ-ઓન, જે તમને ઈન્ફ્રાસ્ટ્રક્ચર મોડ્યુલો પર કોઓર્ડિનેટ અને ઓર્કેસ્ટ્રેટ કરવાની મંજૂરી આપે છે.

એક લાક્ષણિક ટેરાફોર્મ રૂપરેખાંકન ફાઇલ આના જેવી દેખાય છે.

તમે સ્પષ્ટ કરો કે તમે કયા ચોક્કસ મોડ્યુલને કૉલ કરવા માંગો છો.

મોડ્યુલમાં શું નિર્ભરતા છે?

અને આ મોડ્યુલ કઈ દલીલો સ્વીકારે છે. ટેરાગ્રન્ટ વિશે એટલું જ જાણવાનું છે.

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

તેથી ઓર્કેસ્ટ્રેશન ટેરેગ્રન્ટ છે. અન્ય વિકલ્પો છે.

હવે ચાલો કોડ સાથે કેવી રીતે કામ કરવું તે વિશે વાત કરીએ.

જો તમારે તમારા કોડમાં નવી સુવિધાઓ ઉમેરવાની જરૂર હોય, તો મોટાભાગના કિસ્સાઓમાં આ સરળ છે. તમે એક નવું સંસાધન લખી રહ્યા છો, બધું સરળ છે.

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

અને બ્લોક સંસાધનનો ઉપયોગ કરીને નવા સંસાધનોની રચનાને સમર્થન આપ્યું.

આઉટપુટ પર આપણે હંમેશા આઉટપુટ આઈડી પરત કરીએ છીએ જેનો ઉપયોગ કરવામાં આવ્યો હતો તેના આધારે.

ટેરાફોર્મ 0.11 માં બીજી ખૂબ જ નોંધપાત્ર સમસ્યા યાદીઓ સાથે કામ કરી રહી છે.

મુશ્કેલી એ છે કે જો અમારી પાસે આવા વપરાશકર્તાઓની સૂચિ છે.

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

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

આ ઉપાય છે. આ Jsonnet માં લખાયેલ કોડ છે. Jsonnet એ Google તરફથી ટેમ્પલેટીંગ ભાષા છે.

આ કમાન્ડ તમને આ ટેમ્પલેટ સ્વીકારવા દે છે અને આઉટપુટ તરીકે તે તમારા ટેમ્પ્લેટ પ્રમાણે બનેલી json ફાઇલ પરત કરે છે.

નમૂનો આના જેવો દેખાય છે.

ટેરાફોર્મ તમને એચસીએલ અને જેસન બંને સાથે એક જ રીતે કામ કરવાની મંજૂરી આપે છે, તેથી જો તમારી પાસે જેસન જનરેટ કરવાની ક્ષમતા હોય, તો તમે તેને ટેરાફોર્મમાં સરકી શકો છો. એક્સ્ટેંશન .tf.json સાથેની ફાઇલ સફળતાપૂર્વક ડાઉનલોડ થશે.

અને પછી અમે તેની સાથે હંમેશની જેમ કામ કરીએ છીએ: ટેરાફોર્મ ઇનિટ, ટેરામોર્મ લાગુ. અને અમે બે વપરાશકર્તાઓ બનાવીએ છીએ.

હવે કોઈ ટીમ છોડી દે તો અમને ડર નથી. અમે ફક્ત json ફાઇલમાં ફેરફાર કરીશું. વાસ્યા પપકિન બાકી, પેટ્યા પ્યાટોચકીન રહ્યા. પેટ્યા પ્યાટોચકીનને નવી કી પ્રાપ્ત થશે નહીં.

ટેરાફોર્મને અન્ય સાધનો સાથે એકીકૃત કરવું એ ખરેખર ટેરાફોર્મનું કામ નથી. ટેરાફોર્મને સંસાધનો બનાવવા માટેના પ્લેટફોર્મ તરીકે બનાવવામાં આવ્યું હતું અને બસ. અને જે બધું પાછળથી આવે છે તે ટેરાફોર્મની ચિંતા નથી. અને ત્યાં તેને વણાટ કરવાની જરૂર નથી. ત્યાં Ansible છે, જે તમને જરૂરી બધું કરે છે.

પરંતુ પરિસ્થિતિઓ ઊભી થાય છે જ્યારે આપણે ટેરાફોર્મને વિસ્તારવા માંગીએ છીએ અને કંઈક પૂર્ણ થયા પછી અમુક આદેશને કૉલ કરીએ છીએ.

પ્રથમ માર્ગ. અમે આઉટપુટ બનાવીએ છીએ જ્યાં આપણે આ આદેશ લખીએ છીએ.

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

બીજી રીત. આ null_resource નો ઉપયોગ છે જે આપણા ઈન્ફ્રાસ્ટ્રક્ચરમાં થતા ફેરફારોને આધારે છે. કેટલાક સંસાધનોના IDમાં ફેરફાર થતાં જ અમે તે જ સ્થાનિક-exeને કૉલ કરી શકીએ છીએ.

સ્વાભાવિક રીતે, આ બધું કાગળ પર સરળ છે, કારણ કે એમેઝોન, અન્ય તમામ જાહેર પ્રદાતાઓની જેમ, તેના પોતાના ધાર કેસોનો સમૂહ છે.

સૌથી સામાન્ય કિસ્સો એ છે કે જ્યારે તમે AWS એકાઉન્ટ ખોલો છો, ત્યારે તમે કયા પ્રદેશોનો ઉપયોગ કરો છો તે મહત્વનું છે; શું આ સુવિધા ત્યાં સક્ષમ છે; કદાચ તમે તેને ડિસેમ્બર 2013 પછી ખોલ્યું હશે; કદાચ તમે VPC વગેરેમાં ડિફોલ્ટનો ઉપયોગ કરી રહ્યાં છો. ત્યાં ઘણા નિયંત્રણો છે. અને એમેઝોને તેમને સમગ્ર દસ્તાવેજોમાં વેરવિખેર કર્યા.

એવી કેટલીક બાબતો છે જેને હું ટાળવાની ભલામણ કરું છું.

શરૂ કરવા માટે, Terraform પ્લાન અથવા Terraform CLI ની અંદરની તમામ બિન-ગુપ્ત દલીલોને ટાળો. આ બધું કાં તો tfvars ફાઇલમાં અથવા પર્યાવરણ વેરીએબલમાં મૂકી શકાય છે.

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

ઉપરાંત, અવકાશ ઘટાડવા માટે લક્ષ્ય દલીલોનો ઉપયોગ કરશો નહીં. આ માટે નાના ઈન્ફ્રાસ્ટ્રક્ચર મોડ્યુલોનો ઉપયોગ કરવો વધુ સરળ છે.

ઉપરાંત, સમાંતરતાને મર્યાદિત કરવાની અને વધારવાની જરૂર નથી. જો મારી પાસે 150 સંસાધનો છે અને હું એમેઝોન સમાંતરતાને ડિફોલ્ટ 10 થી 100 સુધી વધારવા માંગુ છું, તો મોટા ભાગે કંઈક ખોટું થશે. અથવા તે હવે સારું થઈ શકે છે, પરંતુ જ્યારે એમેઝોન કહે છે કે તમે ઘણા બધા કૉલ્સ કરી રહ્યાં છો, ત્યારે તમે મુશ્કેલીમાં મુકાઈ જશો.

ટેરાફોર્મ આમાંની મોટાભાગની સમસ્યાઓને પુનઃપ્રારંભ કરવાનો પ્રયાસ કરશે, પરંતુ તમે લગભગ કંઈપણ પ્રાપ્ત કરી શકશો નહીં. જો તમે AWS API ની અંદર અથવા Terraform પ્રદાતાની અંદર કોઈ બગ પર અડચણ અનુભવો છો તો સમાંતર=1 એ વાપરવા માટે એક મહત્વપૂર્ણ વસ્તુ છે. અને પછી તમારે સ્પષ્ટ કરવાની જરૂર છે: parallelism=1 અને Terraform એક કૉલ, પછી બીજો, પછી ત્રીજો કૉલ પૂરો કરે ત્યાં સુધી રાહ જુઓ. તે તેમને એક પછી એક લોન્ચ કરશે.

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

વર્કસ્પેસ વપરાશકર્તાઓ દ્વારા બનાવવામાં આવી ન હતી. આનો અર્થ એ નથી કે વપરાશકર્તાઓએ GitHub મુદ્દાઓમાં લખ્યું છે કે અમે ટેરાફોર્મ વર્કસ્પેસ વિના જીવી શકતા નથી. ના આવું નથી. ટેરાફોર્મ એન્ટરપ્રાઇઝ એ ​​વ્યવસાયિક ઉકેલ છે. HashiCorp ના ટેરાફોર્મે નક્કી કર્યું કે અમને વર્કસ્પેસની જરૂર છે, તેથી અમે તેને ફાઇલ કરી દીધી. મને તેને અલગ ફોલ્ડરમાં મૂકવું ખૂબ સરળ લાગે છે. પછી થોડી વધુ ફાઇલો હશે, પરંતુ તે સ્પષ્ટ થશે.

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

અહેવાલનો વિષય "ભવિષ્ય માટે" લખવામાં આવ્યો હતો. હું આ વિશે ખૂબ જ ટૂંકમાં વાત કરીશ. ભવિષ્ય માટે, આનો અર્થ એ છે કે 0.12 ટૂંક સમયમાં રિલીઝ થશે.

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

પણ! જો તમે તૈયાર મોડ્યુલો અને તૃતીય-પક્ષ ઉકેલોનો ઉપયોગ કરીને ઓછા અને વધુ સરળ રીતે લખો છો, તો તમારે રાહ જોવાની જરૂર નથી અને આશા છે કે 0.12 આવશે અને તમારા માટે બધું ઠીક કરશે.

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

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

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

ટેરેટેસ્ટ સૌથી વધુ વારંવાર ઉલ્લેખિત પુસ્તકાલયોમાંની એક છે જે તમને ટેરાફોર્મ માટે એકીકરણ પરીક્ષણો લખવા માટે પરવાનગી આપે છે. આ ઉપયોગિતાઓમાંની એક છે. હું DSL પ્રકાર પસંદ કરું છું, ઉદાહરણ તરીકે, rspec.

એન્ટોન, રિપોર્ટ માટે આભાર! મારું નામ વેલેરી છે. મને થોડો ફિલોસોફિકલ પ્રશ્ન પૂછવા દો. ત્યાં, શરતી રીતે, જોગવાઈ છે, ત્યાં જમાવટ છે. જોગવાઈ મારું ઈન્ફ્રાસ્ટ્રક્ચર બનાવે છે, જમાવટમાં અમે તેને કંઈક ઉપયોગી સાથે ભરીએ છીએ, ઉદાહરણ તરીકે, સર્વર્સ, એપ્લિકેશન્સ વગેરે. અને તે મારા મગજમાં છે કે ટેરાફોર્મ જોગવાઈ માટે વધુ છે, અને જવાબી એ જમાવટ માટે વધુ છે, કારણ કે જવાબીબલ ભૌતિક ઈન્ફ્રાસ્ટ્રક્ચર માટે પણ છે. તમને nginx, Postgres ઇન્સ્ટોલ કરવાની મંજૂરી આપે છે. પરંતુ તે જ સમયે, Ansible જોગવાઈને મંજૂરી આપે છે, ઉદાહરણ તરીકે, Amazon અથવા Google સંસાધનોની. પરંતુ ટેરાફોર્મ તમને તેના મોડ્યુલોનો ઉપયોગ કરીને કેટલાક સોફ્ટવેરનો ઉપયોગ કરવાની પણ પરવાનગી આપે છે. તમારા દૃષ્ટિકોણથી, શું ત્યાં કોઈ પ્રકારની સરહદ છે જે ટેરાફોર્મ અને જવાબીબલ વચ્ચે ચાલે છે, ક્યાં અને શું વાપરવું વધુ સારું છે? અથવા, ઉદાહરણ તરીકે, શું તમને લાગે છે કે Ansible પહેલેથી જ કચરો છે, તમારે દરેક વસ્તુ માટે ટેરાફોર્મનો ઉપયોગ કરવાનો પ્રયાસ કરવો જોઈએ?

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

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

નમસ્તે! રિપોર્ટ માટે આભાર! મારું નામ મીશા છે, આરબીએસ કંપની. સંસાધન બનાવતી વખતે તમે પ્રોવિઝનર દ્વારા Ansible ને કૉલ કરી શકો છો. Ansible માં ડાયનેમિક ઇન્વેન્ટરી નામનો વિષય પણ છે. અને તમે પહેલા ટેરાફોર્મને કૉલ કરી શકો છો, અને પછી એન્સિબલને કૉલ કરી શકો છો, જે રાજ્યમાંથી સંસાધનો લેશે અને તેને એક્ઝિક્યુટ કરશે. શું સારું છે?

લોકો સમાન સફળતા સાથે બંનેનો ઉપયોગ કરે છે. મને એવું લાગે છે કે એન્સિબલમાં ડાયનેમિક ઇન્વેન્ટરી એ એક અનુકૂળ વસ્તુ છે, જો આપણે ઑટોસ્કેલિંગ જૂથ વિશે વાત કરી રહ્યા નથી. કારણ કે ઓટોસ્કેલિંગ જૂથમાં અમારી પાસે પહેલેથી જ અમારી પોતાની ટૂલકીટ છે, જેને લોન્ચ_કોન્ફિગરેશન કહેવામાં આવે છે. લોન્ચ_કોન્ફિગરેશનમાં આપણે નવું સંસાધન બનાવીએ ત્યારે લોન્ચ કરવાની જરૂર હોય તે બધું રેકોર્ડ કરીએ છીએ. તેથી, એમેઝોન સાથે, ડાયનેમિક ઇન્વેન્ટરીનો ઉપયોગ કરવો અને ટેરાફોર્મ ટીએસ ફાઇલ વાંચવી, મારા મતે, ઓવરકિલ છે. અને જો તમે અન્ય ટૂલ્સનો ઉપયોગ કરો છો જ્યાં "ઓટોસ્કેલિંગ જૂથ" નો કોઈ ખ્યાલ નથી, ઉદાહરણ તરીકે, તમે DigitalOcean અથવા કોઈ અન્ય પ્રદાતાનો ઉપયોગ કરો છો જ્યાં કોઈ ઑટોસ્કેલિંગ જૂથ નથી, તો તમારે ત્યાં મેન્યુઅલી API ખેંચવું પડશે, IP સરનામાં શોધવા પડશે, બનાવવા પડશે. ડાયનેમિક ઇન્વેન્ટરી ફાઇલ , અને Ansible પહેલાથી જ તેમાંથી ભટકશે. એટલે કે, એમેઝોન માટે લોન્ચ_કન્ફિગરેશન છે, અને બાકીની દરેક વસ્તુ માટે ડાયનેમિક ઇન્વેન્ટરી છે.

સોર્સ: www.habr.com