ഭാവിയിലേക്കുള്ള ടെറാഫോമിലെ അടിസ്ഥാന സൗകര്യങ്ങളുടെ വിവരണം. ആന്റൺ ബാബെങ്കോ (2018)

പലരും അവരുടെ ദൈനംദിന ജോലികളിൽ Terraform അറിയുകയും ഉപയോഗിക്കുകയും ചെയ്യുന്നു, എന്നാൽ അതിനുള്ള മികച്ച രീതികൾ ഇതുവരെ രൂപപ്പെട്ടിട്ടില്ല. ഓരോ ടീമും അവരുടേതായ സമീപനങ്ങളും രീതികളും കണ്ടുപിടിക്കണം.

നിങ്ങളുടെ ഇൻഫ്രാസ്ട്രക്ചർ മിക്കവാറും ലളിതമായി ആരംഭിക്കുന്നു: കുറച്ച് വിഭവങ്ങൾ + കുറച്ച് ഡെവലപ്പർമാർ. കാലക്രമേണ, അത് എല്ലാ ദിശകളിലും വളരുന്നു. വിഭവങ്ങൾ ടെറാഫോം മൊഡ്യൂളുകളിലേക്ക് ഗ്രൂപ്പുചെയ്യാനും കോഡ് ഫോൾഡറുകളായി ഓർഗനൈസ് ചെയ്യാനും മറ്റെന്താണ് തെറ്റ് സംഭവിക്കാനുമുള്ള വഴികൾ നിങ്ങൾ കണ്ടെത്തുന്നുണ്ടോ? (പ്രശസ്തമായ അവസാന വാക്കുകൾ)

സമയം കടന്നുപോകുന്നു, നിങ്ങളുടെ അടിസ്ഥാന സൗകര്യങ്ങൾ നിങ്ങളുടെ പുതിയ വളർത്തുമൃഗമാണെന്ന് നിങ്ങൾക്ക് തോന്നുന്നു, പക്ഷേ എന്തുകൊണ്ട്? ഇൻഫ്രാസ്ട്രക്ചറിലെ വിശദീകരിക്കാനാകാത്ത മാറ്റങ്ങളെക്കുറിച്ച് നിങ്ങൾ ആശങ്കാകുലരാണ്, ഇൻഫ്രാസ്ട്രക്ചറും കോഡും സ്പർശിക്കാൻ നിങ്ങൾ ഭയപ്പെടുന്നു - തൽഫലമായി, നിങ്ങൾ പുതിയ പ്രവർത്തനം വൈകിപ്പിക്കുകയോ ഗുണനിലവാരം കുറയ്ക്കുകയോ ചെയ്യുന്നു...

Github-ലെ AWS-നുള്ള ടെറാഫോം കമ്മ്യൂണിറ്റി മൊഡ്യൂളുകളുടെ ഒരു ശേഖരം കൈകാര്യം ചെയ്തതിനും നിർമ്മാണത്തിൽ ടെറാഫോമിന്റെ ദീർഘകാല പരിപാലനത്തിനും ശേഷം, ആന്റൺ ബാബെങ്കോ തന്റെ അനുഭവം പങ്കിടാൻ തയ്യാറാണ്: TF മൊഡ്യൂളുകൾ എങ്ങനെ എഴുതാം, അങ്ങനെ അത് ഭാവിയിൽ ഉപദ്രവിക്കില്ല.

സംഭാഷണത്തിന്റെ അവസാനത്തോടെ, ടെറാഫോമിലെ റിസോഴ്‌സ് മാനേജ്‌മെന്റ് തത്വങ്ങൾ, ടെറാഫോമിലെ മൊഡ്യൂളുകളുമായി ബന്ധപ്പെട്ട മികച്ച രീതികൾ, ഇൻഫ്രാസ്ട്രക്ചർ മാനേജ്‌മെന്റുമായി ബന്ധപ്പെട്ട ചില തുടർച്ചയായ ഏകീകരണ തത്വങ്ങൾ എന്നിവയിൽ പങ്കെടുക്കുന്നവർക്ക് കൂടുതൽ പരിചയമുണ്ടാകും.

നിരാകരണം: ഈ റിപ്പോർട്ട് നവംബർ 2018-ലെ തീയതിയാണെന്ന് ഞാൻ ശ്രദ്ധിക്കുന്നു—ഇതിനകം 2 വർഷം കഴിഞ്ഞു. റിപ്പോർട്ടിൽ ചർച്ച ചെയ്ത Terraform 0.11-ന്റെ പതിപ്പ് ഇനി പിന്തുണയ്‌ക്കില്ല. കഴിഞ്ഞ 2 വർഷത്തിനിടയിൽ, 2 പുതിയ റിലീസുകൾ പുറത്തിറങ്ങി, അതിൽ ഒരുപാട് പുതുമകളും മെച്ചപ്പെടുത്തലുകളും മാറ്റങ്ങളും ഉൾപ്പെടുന്നു. ദയവായി ഇത് ശ്രദ്ധിക്കുകയും ഡോക്യുമെന്റേഷൻ പരിശോധിക്കുകയും ചെയ്യുക.

റെഫറൻസുകൾ:

• ടെറാഫോം-കമ്മ്യൂണിറ്റി-മൊഡ്യൂളുകൾ + terraform-aws-modules
• antonbabenko/pre-commit-terraform - ഓട്ടോ ഫോർമാറ്റിംഗ് കോഡും ഡോക്യുമെന്റേഷനും
• ആന്റൺബാബെങ്കോ/ടെറാപിൻ - ടെറാഫോം മൊഡ്യൂളുകളുടെ ജനറേറ്റർ (WIP)
• antonbabenko/modules.tf-lambda - വിഷ്വൽ ഡയഗ്രമുകളിൽ നിന്നുള്ള ടെറാഫോം കോഡ് ജനറേറ്റർ (WIP)
• www.terraform-best-practices.com
• media.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 പ്രത്യക്ഷപ്പെട്ടു. ഇവിടെ പ്രധാന ആശയം "കോഡ് ആയി ഇൻഫ്രാസ്ട്രക്ചർ" എന്നതാണ്.

എല്ലാ ഡോക്യുമെന്റേഷനുകളും, ഞാൻ പറഞ്ഞതുപോലെ, എഴുതിയിരിക്കുന്നു terraform.io. മിക്ക ആളുകൾക്കും ഈ സൈറ്റിനെക്കുറിച്ച് അറിയാമെന്നും ഡോക്യുമെന്റേഷൻ വായിച്ചിട്ടുണ്ടെന്നും ഞാൻ പ്രതീക്ഷിക്കുന്നു. അങ്ങനെയാണെങ്കിൽ, നിങ്ങൾ ശരിയായ സ്ഥലത്താണ്.

ഒരു സാധാരണ ടെറാഫോം കോൺഫിഗറേഷൻ ഫയൽ ഇങ്ങനെയാണ് കാണപ്പെടുന്നത്, ഇവിടെ നമ്മൾ ആദ്യം ചില വേരിയബിളുകൾ നിർവചിക്കുന്നു.

ഈ സാഹചര്യത്തിൽ നമ്മൾ "aws_region" എന്ന് നിർവ്വചിക്കുന്നു.

അതിനുശേഷം ഞങ്ങൾ സൃഷ്ടിക്കാൻ ആഗ്രഹിക്കുന്ന ഉറവിടങ്ങൾ വിവരിക്കുന്നു.

ഡിപൻഡൻസികളും ദാതാക്കളും ലോഡ് ചെയ്യുന്നതിനായി ഞങ്ങൾ ചില കമാൻഡുകൾ റൺ ചെയ്യുന്നു, പ്രത്യേകിച്ചും "terraform init".

നിർദ്ദിഷ്ട കോൺഫിഗറേഷൻ ഞങ്ങൾ സൃഷ്‌ടിച്ച ഉറവിടങ്ങളുമായി പൊരുത്തപ്പെടുന്നുണ്ടോയെന്ന് പരിശോധിക്കുന്നതിനായി ഞങ്ങൾ “ടെറാഫോം പ്രയോഗിക്കുക” കമാൻഡ് പ്രവർത്തിപ്പിക്കുന്നു. ഞങ്ങൾ മുമ്പ് ഒന്നും സൃഷ്‌ടിച്ചിട്ടില്ലാത്തതിനാൽ, ഈ ഉറവിടങ്ങൾ സൃഷ്‌ടിക്കാൻ ടെറാഫോം ഞങ്ങളെ പ്രേരിപ്പിക്കുന്നു.

ഞങ്ങൾ ഇത് സ്ഥിരീകരിക്കുന്നു. അങ്ങനെ നമ്മൾ സീസ്‌നൈൽ എന്ന ഒരു ബക്കറ്റ് ഉണ്ടാക്കുന്നു.

സമാനമായ നിരവധി യൂട്ടിലിറ്റികളും ഉണ്ട്. ആമസോൺ ഉപയോഗിക്കുന്ന നിങ്ങളിൽ പലർക്കും AWS CloudFormation അല്ലെങ്കിൽ Google Cloud Deployment Manager അല്ലെങ്കിൽ Azure Resource Manager എന്നിവ അറിയാം. ഈ പബ്ലിക് ക്ലൗഡ് ദാതാക്കളിൽ ഓരോന്നിനും ഉറവിടങ്ങൾ കൈകാര്യം ചെയ്യുന്നതിനായി ഓരോന്നിനും അതിന്റേതായ നടപ്പാക്കൽ ഉണ്ട്. ടെറാഫോം പ്രത്യേകിച്ചും ഉപയോഗപ്രദമാണ്, കാരണം ഇത് 100-ലധികം ദാതാക്കളെ നിയന്ത്രിക്കാൻ നിങ്ങളെ അനുവദിക്കുന്നു. (കൂടുതൽ വിശദാംശങ്ങൾ ഇവിടെ)

ടെറാഫോം തുടക്കം മുതൽ പിന്തുടരുന്ന ലക്ഷ്യങ്ങൾ:

• ടെറാഫോം വിഭവങ്ങളുടെ ഒരൊറ്റ കാഴ്ച നൽകുന്നു.
• എല്ലാ ആധുനിക പ്ലാറ്റ്ഫോമുകളെയും പിന്തുണയ്ക്കാൻ നിങ്ങളെ അനുവദിക്കുന്നു.
• അടിസ്ഥാന സൗകര്യങ്ങൾ സുരക്ഷിതമായും പ്രവചനാതീതമായും മാറ്റാൻ നിങ്ങളെ അനുവദിക്കുന്ന ഒരു യൂട്ടിലിറ്റി എന്ന നിലയിലാണ് ടെറാഫോം ആദ്യം മുതൽ രൂപകൽപ്പന ചെയ്തിരിക്കുന്നത്.

2014-ൽ, "പ്രവചനാതീതമായ" എന്ന വാക്ക് ഈ സന്ദർഭത്തിൽ വളരെ അസാധാരണമായി തോന്നി.

ടെറാഫോം ഒരു സാർവത്രിക യൂട്ടിലിറ്റിയാണ്. നിങ്ങൾക്ക് ഒരു API ഉണ്ടെങ്കിൽ, നിങ്ങൾക്ക് എല്ലാം നിയന്ത്രിക്കാനാകും:

• നിങ്ങൾക്ക് ആവശ്യമുള്ളതെല്ലാം മാനേജ് ചെയ്യാൻ 120-ലധികം ദാതാക്കളെ ഉപയോഗിക്കാം.
• ഉദാഹരണത്തിന്, GitHub റിപ്പോസിറ്ററികളിലേക്കുള്ള ആക്സസ് വിവരിക്കാൻ നിങ്ങൾക്ക് Terraform ഉപയോഗിക്കാം.
• നിങ്ങൾക്ക് ജിറയിൽ ബഗുകൾ സൃഷ്ടിക്കാനും അടയ്ക്കാനും കഴിയും.
• നിങ്ങൾക്ക് പുതിയ റെലിക് മെട്രിക്‌സ് മാനേജ് ചെയ്യാം.
• നിങ്ങൾക്ക് ശരിക്കും വേണമെങ്കിൽ ഡ്രോപ്പ്ബോക്സിൽ ഫയലുകൾ സൃഷ്ടിക്കാനും കഴിയും.

Go-യിൽ വിവരിക്കാവുന്ന ഒരു ഓപ്പൺ API ഉള്ള Terraform ദാതാക്കൾ ഉപയോഗിച്ചാണ് ഇതെല്ലാം നേടിയത്.

ഞങ്ങൾ ടെറാഫോം ഉപയോഗിക്കാൻ തുടങ്ങി, സൈറ്റിലെ ചില ഡോക്യുമെന്റേഷൻ വായിച്ചു, കുറച്ച് വീഡിയോ കണ്ടു, ഞാൻ മുൻ സ്ലൈഡുകളിൽ കാണിച്ചത് പോലെ main.tf എഴുതാൻ തുടങ്ങി.

എല്ലാം മികച്ചതാണ്, നിങ്ങൾക്ക് ഒരു VPC സൃഷ്ടിക്കുന്ന ഒരു ഫയൽ ഉണ്ട്.

നിങ്ങൾ ഒരു VPC സൃഷ്ടിക്കാൻ ആഗ്രഹിക്കുന്നുവെങ്കിൽ, നിങ്ങൾ ഏകദേശം ഈ 12 വരികൾ വ്യക്തമാക്കുക. ഏത് മേഖലയിലാണ് നിങ്ങൾ സൃഷ്ടിക്കാൻ ആഗ്രഹിക്കുന്നതെന്നും ഏത് ഐപി വിലാസങ്ങളുടെ cidr_block ഉപയോഗിക്കണമെന്നും വിവരിക്കുക. അത്രയേയുള്ളൂ.

സ്വാഭാവികമായും, പദ്ധതി ക്രമേണ വളരും.

നിങ്ങൾ അവിടെ ഒരു കൂട്ടം പുതിയ കാര്യങ്ങൾ ചേർക്കും: ഉറവിടങ്ങൾ, ഡാറ്റ ഉറവിടങ്ങൾ, നിങ്ങൾ പുതിയ ദാതാക്കളുമായി സംയോജിപ്പിക്കും, നിങ്ങളുടെ GitHub അക്കൗണ്ടിലെ ഉപയോക്താക്കളെ നിയന്ത്രിക്കുന്നതിന് പെട്ടെന്ന് Terraform ഉപയോഗിക്കാൻ നിങ്ങൾ ആഗ്രഹിക്കും. DNS ദാതാക്കൾ, എല്ലാം മറികടക്കുക. ടെറാഫോം ഇത് എളുപ്പമാക്കുന്നു.

ഇനി പറയുന്ന ഉദാഹരണം നോക്കാം.

നിങ്ങളുടെ VPC-യിൽ നിന്നുള്ള ഉറവിടങ്ങൾ ഇന്റർനെറ്റ് ആക്‌സസ്സ് വേണമെന്നതിനാൽ നിങ്ങൾ ക്രമേണ internet_gateway ചേർക്കുന്നു. ഇതൊരു നല്ല ആശയമാണ്.

ഫലം ഇതാണ് 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 എന്നത് തീർച്ചയായും വളരെ വലുതല്ല, പക്ഷേ ഞങ്ങൾ നെറ്റ്‌വർക്ക് സ്റ്റാക്കിനെക്കുറിച്ചാണ് സംസാരിക്കുന്നത്, അതായത് നിങ്ങൾക്ക് നെറ്റ്‌വർക്ക് ഉറവിടങ്ങൾ മാത്രമേ ചേർത്തിട്ടുള്ളൂ. 100 Kb എളുപ്പത്തിൽ നെയ്തെടുക്കാൻ കഴിയുന്ന ആപ്ലിക്കേഷൻ ലോഡ് ബാലൻസർ, വിന്യാസം ES ക്ലസ്റ്റർ, കുബർനെറ്റ്സ് മുതലായവയെക്കുറിച്ചല്ല ഞങ്ങൾ സംസാരിക്കുന്നത്. നിങ്ങൾ ഇതെല്ലാം എഴുതുകയാണെങ്കിൽ, ടെറാഫോം ടെറാഫോം മൊഡ്യൂളുകൾ നൽകുന്നുവെന്ന് നിങ്ങൾ വളരെ വേഗം മനസ്സിലാക്കും.

ടെറാഫോം മൊഡ്യൂളുകൾ ഒരു ഗ്രൂപ്പായി നിയന്ത്രിക്കപ്പെടുന്ന ഒരു സ്വയം ഉൾക്കൊള്ളുന്ന ടെറാഫോം കോൺഫിഗറേഷനാണ്. ടെറാഫോം മൊഡ്യൂളുകളെ കുറിച്ച് നിങ്ങൾ അറിഞ്ഞിരിക്കേണ്ടത് ഇത്രമാത്രം. അവർ ഒട്ടും മിടുക്കരല്ല, എന്തിനെയെങ്കിലും ആശ്രയിച്ച് സങ്കീർണ്ണമായ കണക്ഷനുകൾ ഉണ്ടാക്കാൻ അവർ നിങ്ങളെ അനുവദിക്കുന്നില്ല. ഇതെല്ലാം ഡെവലപ്പർമാരുടെ ചുമലിൽ പതിക്കുന്നു. അതായത്, ഇത് നിങ്ങൾ ഇതിനകം എഴുതിയ ഒരുതരം ടെറാഫോം കോൺഫിഗറേഷൻ മാത്രമാണ്. നിങ്ങൾക്ക് അതിനെ ഒരു ഗ്രൂപ്പായി വിളിക്കാം.

അതിനാൽ ഞങ്ങളുടെ 10-20-30 Kb കോഡ് എങ്ങനെ ഒപ്റ്റിമൈസ് ചെയ്യുമെന്ന് മനസിലാക്കാൻ ഞങ്ങൾ ശ്രമിക്കുന്നു. ചില മൊഡ്യൂളുകൾ ഉപയോഗിക്കേണ്ടതുണ്ടെന്ന് ഞങ്ങൾ ക്രമേണ മനസ്സിലാക്കുന്നു.

നിങ്ങൾ നേരിടുന്ന ആദ്യ തരം മൊഡ്യൂളുകൾ റിസോഴ്സ് മൊഡ്യൂളുകളാണ്. നിങ്ങളുടെ ഇൻഫ്രാസ്ട്രക്ചർ എന്തിനെക്കുറിച്ചാണ്, നിങ്ങളുടെ ബിസിനസ്സ് എന്തിനെക്കുറിച്ചാണ്, എവിടെ, എന്തെല്ലാം വ്യവസ്ഥകൾ എന്നിവ അവർക്ക് മനസ്സിലാകുന്നില്ല. ഓപ്പൺ സോഴ്‌സ് കമ്മ്യൂണിറ്റിയുമായി ചേർന്ന് ഞാൻ നിർവ്വഹിക്കുന്ന മൊഡ്യൂളുകൾ ഇവയാണ്, നിങ്ങളുടെ ഇൻഫ്രാസ്ട്രക്ചറിനായുള്ള പ്രാരംഭ നിർമ്മാണ ബ്ലോക്കുകളായി ഞങ്ങൾ മുന്നോട്ട് വെക്കുന്നു.

ഒരു റിസോഴ്സ് മൊഡ്യൂളിന്റെ ഉദാഹരണം.

ഞങ്ങൾ ഒരു റിസോഴ്സ് മൊഡ്യൂളിനെ വിളിക്കുമ്പോൾ, ഏത് പാതയിൽ നിന്നാണ് അതിന്റെ ഉള്ളടക്കങ്ങൾ ലോഡ് ചെയ്യേണ്ടതെന്ന് ഞങ്ങൾ വ്യക്തമാക്കുന്നു.

ഏത് പതിപ്പാണ് ഡൗൺലോഡ് ചെയ്യേണ്ടതെന്ന് ഞങ്ങൾ സൂചിപ്പിക്കുന്നു.

ഞങ്ങൾ ഒരു കൂട്ടം വാദങ്ങൾ അവിടെ പാസാക്കുന്നു. അത്രയേയുള്ളൂ. ഈ മൊഡ്യൂൾ ഉപയോഗിക്കുമ്പോൾ നമ്മൾ അറിയേണ്ടത് ഇത്രമാത്രം.

ഏറ്റവും പുതിയ പതിപ്പ് ഉപയോഗിച്ചാൽ എല്ലാം സുസ്ഥിരമാകുമെന്ന് പലരും കരുതുന്നു. പക്ഷെ ഇല്ല. ഇൻഫ്രാസ്ട്രക്ചർ പതിപ്പ് ആയിരിക്കണം; ഈ അല്ലെങ്കിൽ ആ ഘടകം ഏത് പതിപ്പിലേക്കാണ് വിന്യസിച്ചതെന്ന് ഞങ്ങൾ വ്യക്തമായി ഉത്തരം നൽകണം.

ഈ മൊഡ്യൂളിനുള്ളിലെ കോഡ് ഇതാ. സുരക്ഷാ ഗ്രൂപ്പ് മൊഡ്യൂൾ. ഇവിടെ സ്ക്രോൾ 640-ാമത്തെ വരിയിലേക്ക് പോകുന്നു. സാധ്യമായ എല്ലാ കോൺഫിഗറേഷനിലും ആമസോണിൽ ഒരു സെക്യൂരിറ്റി-ക്രൂപ്പ് റിസോഴ്സ് സൃഷ്ടിക്കുന്നത് വളരെ നിസ്സാരമല്ലാത്ത ഒരു ജോലിയാണ്. ഒരു സെക്യൂരിറ്റി ഗ്രൂപ്പ് ഉണ്ടാക്കി അതിന് എന്ത് നിയമങ്ങളാണ് പാസാക്കേണ്ടതെന്ന് പറഞ്ഞാൽ മാത്രം പോരാ. ഇത് വളരെ ലളിതമായിരിക്കും. ആമസോണിനുള്ളിൽ ഒരു ദശലക്ഷം വ്യത്യസ്ത നിയന്ത്രണങ്ങളുണ്ട്. ഉദാഹരണത്തിന്, നിങ്ങൾ ഉപയോഗിക്കുകയാണെങ്കിൽ VPC എൻഡ്‌പോയിന്റ്, പ്രിഫിക്‌സ് ലിസ്റ്റ്, വിവിധ API-കൾ കൂടാതെ ഇതെല്ലാം മറ്റെല്ലാ കാര്യങ്ങളുമായി സംയോജിപ്പിക്കാൻ ശ്രമിക്കുന്നു, തുടർന്ന് ടെറാഫോം ഇത് ചെയ്യാൻ നിങ്ങളെ അനുവദിക്കുന്നില്ല. ആമസോൺ API ഇതും അനുവദിക്കുന്നില്ല. അതിനാൽ, ഈ ഭയാനകമായ യുക്തികളെല്ലാം ഒരു മൊഡ്യൂളിൽ മറയ്ക്കുകയും ഇതുപോലെയുള്ള ഉപയോക്തൃ കോഡ് നൽകുകയും വേണം.

ഇത് എങ്ങനെയാണ് ഉള്ളിൽ നിർമ്മിക്കുന്നതെന്ന് ഉപയോക്താവിന് അറിയേണ്ടതില്ല.

റിസോഴ്സ് മൊഡ്യൂളുകൾ അടങ്ങുന്ന രണ്ടാമത്തെ തരം മൊഡ്യൂളുകൾ, നിങ്ങളുടെ ബിസിനസ്സിന് കൂടുതൽ ബാധകമായ പ്രശ്നങ്ങൾ ഇതിനകം പരിഹരിക്കുന്നു. മിക്കപ്പോഴും ഇത് ടെറാഫോമിന്റെ വിപുലീകരണവും കമ്പനി മാനദണ്ഡങ്ങൾക്കായി ടാഗുകൾക്കായി ചില കർക്കശമായ മൂല്യങ്ങൾ സജ്ജമാക്കുന്നതുമായ ഒരു സ്ഥലമാണ്. Terraform നിങ്ങളെ നിലവിൽ ഉപയോഗിക്കാൻ അനുവദിക്കാത്ത പ്രവർത്തനക്ഷമതയും അവിടെ ചേർക്കാവുന്നതാണ്. ഇത് ഇപ്പോൾ ശരിയാണ്. ഇപ്പോൾ പതിപ്പ് 0.11, അത് ഭൂതകാലത്തിന്റെ ഒരു കാര്യമായി മാറാൻ പോകുന്നു. എന്നിട്ടും, പ്രീപ്രോസസറുകൾ, jsonnet, കുക്കികട്ടർ എന്നിവയും മറ്റ് നിരവധി കാര്യങ്ങളും പൂർണ്ണമായ പ്രവർത്തനത്തിന് ഉപയോഗിക്കേണ്ട സഹായ സംവിധാനമാണ്.

അടുത്തതായി ഞാൻ ഇതിന്റെ ചില ഉദാഹരണങ്ങൾ കാണിക്കും.

ഇൻഫ്രാസ്ട്രക്ചർ മൊഡ്യൂളിനെ കൃത്യമായി അതേ രീതിയിൽ വിളിക്കുന്നു.

ഉള്ളടക്കം എവിടെ നിന്ന് ഡൗൺലോഡ് ചെയ്യണമെന്ന് ഉറവിടം സൂചിപ്പിച്ചിരിക്കുന്നു.

ഒരു കൂട്ടം മൂല്യങ്ങൾ ഈ മൊഡ്യൂളിലേക്ക് കടത്തിവിടുന്നു.

അടുത്തതായി, ഈ മൊഡ്യൂളിനുള്ളിൽ, ഒരു VPC അല്ലെങ്കിൽ ആപ്ലിക്കേഷൻ ലോഡ് ബാലൻസർ സൃഷ്ടിക്കുന്നതിനോ ഒരു സുരക്ഷാ ഗ്രൂപ്പ് സൃഷ്ടിക്കുന്നതിനോ അല്ലെങ്കിൽ ഒരു ഇലാസ്റ്റിക് കണ്ടെയ്നർ സർവീസ് ക്ലസ്റ്ററിനോ വേണ്ടി ഒരു കൂട്ടം റിസോഴ്സ് മൊഡ്യൂളുകളെ വിളിക്കുന്നു.

രണ്ട് തരം മൊഡ്യൂളുകൾ ഉണ്ട്. ഇത് മനസ്സിലാക്കേണ്ടത് പ്രധാനമാണ്, കാരണം ഈ റിപ്പോർട്ടിൽ ഞാൻ ഗ്രൂപ്പുചെയ്‌ത മിക്ക വിവരങ്ങളും ഡോക്യുമെന്റേഷനിൽ എഴുതിയിട്ടില്ല.

ടെറാഫോമിലെ ഡോക്യുമെന്റേഷൻ ഇപ്പോൾ വളരെ പ്രശ്‌നകരമാണ്, കാരണം ഈ സവിശേഷതകൾ ഉണ്ടെന്ന് അത് പറയുന്നു, നിങ്ങൾക്ക് അവ ഉപയോഗിക്കാൻ കഴിയും. എന്നാൽ ഈ സവിശേഷതകൾ എങ്ങനെ ഉപയോഗിക്കണമെന്ന് അവൾ പറയുന്നില്ല, എന്തുകൊണ്ട് അവ ഉപയോഗിക്കുന്നത് നല്ലതാണ്. അതിനാൽ, വളരെയധികം ആളുകൾ തങ്ങൾക്ക് ജീവിക്കാൻ കഴിയാത്ത എന്തെങ്കിലും എഴുതുന്നു.

ഈ മൊഡ്യൂളുകൾ എങ്ങനെ എഴുതാമെന്ന് അടുത്തതായി നോക്കാം. അപ്പോൾ അവരെ എങ്ങനെ വിളിക്കാമെന്നും കോഡ് ഉപയോഗിച്ച് എങ്ങനെ പ്രവർത്തിക്കാമെന്നും നമുക്ക് നോക്കാം.

ടെറാഫോം രജിസ്ട്രി - https://registry.terraform.io/

ടിപ്പ് #0 റിസോഴ്സ് മൊഡ്യൂളുകൾ എഴുതാതിരിക്കുക എന്നതാണ്. ഈ മൊഡ്യൂളുകളിൽ ഭൂരിഭാഗവും നിങ്ങൾക്കായി ഇതിനകം എഴുതിയിട്ടുണ്ട്. ഞാൻ പറഞ്ഞതുപോലെ, അവ ഓപ്പൺ സോഴ്‌സാണ്, അവയിൽ നിങ്ങളുടെ ബിസിനസ്സ് ലോജിക്കൊന്നും അടങ്ങിയിട്ടില്ല, IP വിലാസങ്ങൾ, പാസ്‌വേഡുകൾ മുതലായവയ്‌ക്കായി അവയ്ക്ക് ഹാർഡ്‌കോഡ് മൂല്യങ്ങൾ ഇല്ല. മൊഡ്യൂൾ വളരെ വഴക്കമുള്ളതാണ്. കൂടാതെ, ഇത് മിക്കവാറും ഇതിനകം എഴുതിയതാണ്. ആമസോണിൽ നിന്നുള്ള വിഭവങ്ങൾക്കായി നിരവധി മൊഡ്യൂളുകൾ ഉണ്ട്. ഏകദേശം 650. അവയിൽ മിക്കതും നല്ല നിലവാരമുള്ളവയാണ്.

ഈ ഉദാഹരണത്തിൽ, ഒരാൾ നിങ്ങളുടെ അടുത്ത് വന്ന് പറഞ്ഞു, “എനിക്ക് ഒരു ഡാറ്റാബേസ് മാനേജ് ചെയ്യാൻ കഴിയണം. ഒരു മൊഡ്യൂൾ സൃഷ്ടിക്കുക, അതുവഴി എനിക്ക് ഒരു ഡാറ്റാബേസ് സൃഷ്ടിക്കാൻ കഴിയും." ആമസോണിന്റെയോ ടെറാഫോമിന്റെയോ നടപ്പാക്കൽ വിശദാംശങ്ങൾ വ്യക്തിക്ക് അറിയില്ല. അദ്ദേഹം ലളിതമായി പറയുന്നു: "എനിക്ക് MSSQL നിയന്ത്രിക്കണം." അതായത്, അത് ഞങ്ങളുടെ മൊഡ്യൂളിനെ വിളിക്കുകയും എഞ്ചിൻ തരം അവിടെ കൈമാറുകയും സമയ മേഖല സൂചിപ്പിക്കുകയും ചെയ്യും എന്നാണ് ഞങ്ങൾ അർത്ഥമാക്കുന്നത്.

ഈ മൊഡ്യൂളിനുള്ളിൽ ഞങ്ങൾ രണ്ട് വ്യത്യസ്ത ഉറവിടങ്ങൾ സൃഷ്ടിക്കുമെന്ന് ഒരു വ്യക്തി അറിയരുത്: ഒന്ന് MSSQL-ന്, രണ്ടാമത്തേത് മറ്റെല്ലാത്തിനും, കാരണം ടെറാഫോം 0.11-ൽ നിങ്ങൾക്ക് സമയ മേഖല മൂല്യങ്ങൾ ഓപ്‌ഷണലായി വ്യക്തമാക്കാൻ കഴിയില്ല.

ഈ മൊഡ്യൂളിൽ നിന്ന് പുറത്തുകടക്കുമ്പോൾ, ഒരു വ്യക്തിക്ക് ഒരു വിലാസം സ്വീകരിക്കാൻ കഴിയും. ഏത് ഡാറ്റാബേസിൽ നിന്നാണ്, ഏത് ഉറവിടത്തിൽ നിന്നാണ് ഞങ്ങൾ ഇതെല്ലാം ആന്തരികമായി സൃഷ്ടിക്കുന്നതെന്ന് അവനറിയില്ല. ഇത് മറയ്ക്കുന്നതിനുള്ള വളരെ പ്രധാനപ്പെട്ട ഘടകമാണ്. ഓപ്പൺ സോഴ്‌സിൽ പൊതുവായുള്ള മൊഡ്യൂളുകൾക്ക് മാത്രമല്ല, നിങ്ങളുടെ പ്രോജക്റ്റുകൾക്കും ടീമുകൾക്കും ഉള്ളിൽ നിങ്ങൾ എഴുതുന്ന മൊഡ്യൂളുകൾക്കും ഇത് ബാധകമാണ്.

ഇത് രണ്ടാമത്തെ വാദമാണ്, നിങ്ങൾ കുറച്ചുകാലമായി ടെറാഫോം ഉപയോഗിക്കുന്നുണ്ടെങ്കിൽ അത് വളരെ പ്രധാനമാണ്. നിങ്ങളുടെ എല്ലാ ടെറാഫോം മൊഡ്യൂളുകളും കമ്പനിയ്‌ക്കായി സ്ഥാപിക്കുന്ന ഒരു ശേഖരം നിങ്ങൾക്കുണ്ട്. കാലക്രമേണ ഈ പ്രോജക്റ്റ് ഒന്നോ രണ്ടോ മെഗാബൈറ്റിന്റെ വലുപ്പത്തിലേക്ക് വളരുക എന്നത് തികച്ചും സാധാരണമാണ്. ഇത് കൊള്ളാം.

എന്നാൽ ടെറാഫോം ഈ മൊഡ്യൂളുകളെ എങ്ങനെ വിളിക്കുന്നു എന്നതാണ് പ്രശ്നം. ഉദാഹരണത്തിന്, ഓരോ ഉപയോക്താവിനെയും സൃഷ്ടിക്കാൻ നിങ്ങൾ ഒരു മൊഡ്യൂളിനെ വിളിക്കുകയാണെങ്കിൽ, Terraform ആദ്യം മുഴുവൻ ശേഖരണവും ലോഡ് ചെയ്യും, തുടർന്ന് ആ നിർദ്ദിഷ്ട മൊഡ്യൂൾ സ്ഥിതിചെയ്യുന്ന ഫോൾഡറിലേക്ക് നാവിഗേറ്റ് ചെയ്യും. ഇങ്ങനെ ഓരോ തവണയും നിങ്ങൾ ഒരു മെഗാബൈറ്റ് ഡൗൺലോഡ് ചെയ്യും. നിങ്ങൾ 100 അല്ലെങ്കിൽ 200 ഉപയോക്താക്കളെ നിയന്ത്രിക്കുകയാണെങ്കിൽ, നിങ്ങൾ 100 അല്ലെങ്കിൽ 200 മെഗാബൈറ്റുകൾ ഡൗൺലോഡ് ചെയ്യും, തുടർന്ന് ആ ഫോൾഡറിലേക്ക് പോകുക. അതുകൊണ്ട് സ്വാഭാവികമായും നിങ്ങൾ "Terraform init" അമർത്തുമ്പോഴെല്ലാം ഒരു കൂട്ടം സ്റ്റഫ് ഡൗൺലോഡ് ചെയ്യാൻ ആഗ്രഹിക്കുന്നില്ല.

https://github.com/mbtproject/mbt

ഈ പ്രശ്നത്തിന് രണ്ട് പരിഹാരങ്ങളുണ്ട്. ആദ്യത്തേത് ആപേക്ഷിക പാതകൾ ഉപയോഗിക്കുക എന്നതാണ്. ഈ രീതിയിൽ നിങ്ങൾ ഫോൾഡർ ലോക്കൽ (./) ആണെന്ന് കോഡിൽ സൂചിപ്പിക്കുന്നു. നിങ്ങൾ എന്തെങ്കിലും സമാരംഭിക്കുന്നതിന് മുമ്പ്, നിങ്ങൾ പ്രാദേശികമായി ഈ സംഭരണിയുടെ ഒരു Git ക്ലോൺ ചെയ്യുക. ഈ രീതിയിൽ നിങ്ങൾ ഒരിക്കൽ ചെയ്യുക.

തീർച്ചയായും, ധാരാളം കുറവുകൾ ഉണ്ട്. ഉദാഹരണത്തിന്, നിങ്ങൾക്ക് പതിപ്പിംഗ് ഉപയോഗിക്കാൻ കഴിയില്ല. ഇത് ചിലപ്പോൾ ജീവിക്കാൻ ബുദ്ധിമുട്ടാണ്.

രണ്ടാമത്തെ പരിഹാരം. നിങ്ങൾക്ക് ധാരാളം സബ്‌മോഡ്യൂളുകൾ ഉണ്ടെങ്കിൽ, നിങ്ങൾക്ക് ഇതിനകം ഏതെങ്കിലും തരത്തിലുള്ള പൈപ്പ്ലൈൻ ഉണ്ടെങ്കിൽ, MBT പ്രോജക്റ്റ് ഉണ്ട്, അത് ഒരു മോണോപോസിറ്ററിയിൽ നിന്ന് നിരവധി പാക്കേജുകൾ ശേഖരിക്കാനും അവ S3-ലേക്ക് അപ്‌ലോഡ് ചെയ്യാനും നിങ്ങളെ അനുവദിക്കുന്നു. ഇത് വളരെ നല്ല മാർഗമാണ്. അതിനാൽ, iam-user-1.0.0.zip ഫയലിന്റെ ഭാരം 1 Kb മാത്രമായിരിക്കും, കാരണം ഈ ഉറവിടം സൃഷ്ടിക്കുന്നതിനുള്ള കോഡ് വളരെ ചെറുതാണ്. മാത്രമല്ല ഇത് വളരെ വേഗത്തിൽ പ്രവർത്തിക്കുകയും ചെയ്യും.

മൊഡ്യൂളുകളിൽ ഉപയോഗിക്കാൻ കഴിയാത്തവയെക്കുറിച്ച് സംസാരിക്കാം.

എന്തുകൊണ്ടാണ് ഇത് മൊഡ്യൂളുകളിൽ മോശമായിരിക്കുന്നത്? ഏറ്റവും മോശം കാര്യം ഉപയോക്താവിനെ അനുമാനിക്കുക എന്നതാണ്. വ്യത്യസ്‌ത ആളുകൾക്ക് ഉപയോഗിക്കാനാകുന്ന ഒരു ദാതാവിന്റെ പ്രാമാണീകരണ ഓപ്ഷനാണ് ഉപയോക്താവെന്ന് കരുതുക. ഉദാഹരണത്തിന്, നമ്മൾ എല്ലാവരും റോൾ സ്വാംശീകരിക്കും. ഇതിനർത്ഥം ടെറാഫോം ഈ റോൾ ഏറ്റെടുക്കും എന്നാണ്. തുടർന്ന് ഈ റോൾ ഉപയോഗിച്ച് അത് മറ്റ് പ്രവർത്തനങ്ങൾ ചെയ്യും.

ദോഷം എന്തെന്നാൽ, ഒരു വിധത്തിൽ ആമസോണിലേക്ക് കണക്റ്റുചെയ്യാൻ വാസ്യ ഇഷ്ടപ്പെടുന്നുവെങ്കിൽ, ഉദാഹരണത്തിന്, ഡിഫോൾട്ട് എൻവയോൺമെന്റ് വേരിയബിൾ ഉപയോഗിച്ച്, കൂടാതെ രഹസ്യ സ്ഥലത്തുള്ള അവന്റെ പങ്കിട്ട കീ ഉപയോഗിക്കാൻ പെത്യ ഇഷ്ടപ്പെടുന്നുവെങ്കിൽ, നിങ്ങൾക്ക് രണ്ടും വ്യക്തമാക്കാൻ കഴിയില്ല. ടെറാഫോം. അവർ കഷ്ടപ്പാടുകൾ അനുഭവിക്കാതിരിക്കാൻ, ഈ ബ്ലോക്ക് മൊഡ്യൂളിൽ സൂചിപ്പിക്കേണ്ടതില്ല. ഇത് ഉയർന്ന തലത്തിൽ സൂചിപ്പിക്കണം. അതായത്, ഞങ്ങൾക്ക് ഒരു റിസോഴ്സ് മൊഡ്യൂളും ഒരു ഇൻഫ്രാസ്ട്രക്ചർ മൊഡ്യൂളും മുകളിൽ ഒരു കോമ്പോസിഷനും ഉണ്ട്. ഇത് എവിടെയെങ്കിലും മുകളിൽ സൂചിപ്പിക്കണം.

രണ്ടാമത്തെ തിന്മ പ്രൊവിഷനർ ആണ്. ഇവിടെ തിന്മ അത്ര നിസ്സാരമല്ല, കാരണം നിങ്ങൾ കോഡ് എഴുതുകയും അത് നിങ്ങൾക്കായി പ്രവർത്തിക്കുകയും ചെയ്യുന്നുവെങ്കിൽ, അത് പ്രവർത്തിക്കുന്നുവെങ്കിൽ, അത് എന്തിനാണ് മാറ്റുന്നത് എന്ന് നിങ്ങൾ ചിന്തിച്ചേക്കാം.

ആദ്യം ഈ പ്രൊവിഷനർ എപ്പോൾ സമാരംഭിക്കുമെന്ന് നിങ്ങൾ എപ്പോഴും നിയന്ത്രിക്കുന്നില്ല എന്നതാണ് ദോഷം. രണ്ടാമതായി, aws ec2 എന്താണ് അർത്ഥമാക്കുന്നത് എന്ന് നിങ്ങൾ നിയന്ത്രിക്കുന്നില്ല, അതായത് നമ്മൾ ഇപ്പോൾ സംസാരിക്കുന്നത് Linux അല്ലെങ്കിൽ Windows നെക്കുറിച്ചാണ്. അതിനാൽ വ്യത്യസ്ത ഓപ്പറേറ്റിംഗ് സിസ്റ്റങ്ങളിലോ വ്യത്യസ്ത ഉപയോക്തൃ കേസുകൾക്കോ ​​ഒരേപോലെ പ്രവർത്തിക്കുന്ന എന്തെങ്കിലും നിങ്ങൾക്ക് എഴുതാൻ കഴിയില്ല.

ഔദ്യോഗിക ഡോക്യുമെന്റേഷനിൽ സൂചിപ്പിച്ചിരിക്കുന്ന ഏറ്റവും സാധാരണമായ ഉദാഹരണം, നിങ്ങൾ aws_instance എഴുതുകയും ഒരു കൂട്ടം ആർഗ്യുമെന്റുകൾ നൽകുകയും ചെയ്യുന്നുവെങ്കിൽ, അവിടെ പ്രൊവിഷനർ "ലോക്കൽ-എക്‌സിക്" വ്യക്തമാക്കുകയും നിങ്ങളുടെ അൻസിബിൾ പ്രവർത്തിപ്പിക്കുകയും ചെയ്താൽ അതിൽ തെറ്റൊന്നുമില്ല. പ്ലേബുക്ക്.

വാസ്തവത്തിൽ, അതെ, അതിൽ തെറ്റൊന്നുമില്ല. എന്നാൽ ഈ ലോക്കൽ-എക്‌സെക് സംഗതി നിലവിലില്ലെന്ന് അക്ഷരാർത്ഥത്തിൽ നിങ്ങൾ ഉടൻ മനസ്സിലാക്കും, ഉദാഹരണത്തിന്, ലോഞ്ച്_കോൺഫിഗറേഷനിൽ.

നിങ്ങൾ ലാഞ്ച്_കോൺഫിഗറേഷൻ ഉപയോഗിക്കുമ്പോൾ, ഒരു സന്ദർഭത്തിൽ നിന്ന് ഒരു ഓട്ടോസ്‌കേലിംഗ് ഗ്രൂപ്പ് സൃഷ്ടിക്കാൻ നിങ്ങൾ ആഗ്രഹിക്കുന്നുവെങ്കിൽ, ലോഞ്ച്_കോൺഫിഗറേഷനിൽ “പ്രൊവിഷനർ” എന്ന ആശയം ഇല്ല. "ഉപയോക്തൃ ഡാറ്റ" എന്ന ആശയം ഉണ്ട്.

അതിനാൽ, കൂടുതൽ സാർവത്രിക പരിഹാരം ഉപയോക്തൃ ഡാറ്റ ഉപയോഗിക്കുക എന്നതാണ്. ഇൻസ്റ്റൻസ് ഓണായിരിക്കുമ്പോൾ, അല്ലെങ്കിൽ അതേ ഉപയോക്തൃ ഡാറ്റയിൽ, ഓട്ടോസ്‌കേലിംഗ് ഗ്രൂപ്പ് ഈ ലോഞ്ച്_കോൺഫിഗറേഷൻ ഉപയോഗിക്കുമ്പോൾ അത് ലോഞ്ച് ചെയ്യപ്പെടും.

നിങ്ങൾക്ക് ഇപ്പോഴും പ്രൊവിഷനർ പ്രവർത്തിപ്പിക്കണമെങ്കിൽ, അത് ഒരു ഗ്ലൂയിംഗ് ഘടകമായതിനാൽ, ഒരു റിസോഴ്സ് സൃഷ്ടിക്കുമ്പോൾ, ആ നിമിഷം നിങ്ങളുടെ പ്രൊവിഷനർ, നിങ്ങളുടെ കമാൻഡ് പ്രവർത്തിപ്പിക്കേണ്ടതുണ്ട്. അത്തരം സാഹചര്യങ്ങൾ ധാരാളം ഉണ്ട്.

ഇതിനുള്ള ഏറ്റവും ശരിയായ ഉറവിടത്തെ 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/

ഒരിടത്ത് എന്തെങ്കിലും മാറ്റമുണ്ടായാൽ നിങ്ങൾക്ക് കോൾ ഓർക്കസ്ട്രേഷൻ ആവശ്യമുണ്ടെങ്കിൽ, ടെറഗ്രന്റ് ഉണ്ട്.

ടെറാഗ്രന്റ് എന്നത് ടെറാഫോമിലേക്കുള്ള ഒരു ആഡ്-ഓൺ ആണ്, അത് ഇൻഫ്രാസ്ട്രക്ചർ മൊഡ്യൂളുകളിലേക്കുള്ള കോളുകൾ ഏകോപിപ്പിക്കാനും ക്രമീകരിക്കാനും നിങ്ങളെ അനുവദിക്കുന്നു.

ഒരു സാധാരണ Terraform കോൺഫിഗറേഷൻ ഫയൽ ഇതുപോലെ കാണപ്പെടുന്നു.

ഏത് നിർദ്ദിഷ്ട മൊഡ്യൂളാണ് നിങ്ങൾ വിളിക്കേണ്ടതെന്ന് വ്യക്തമാക്കുക.

മൊഡ്യൂളിന് എന്ത് ഡിപൻഡൻസികൾ ഉണ്ട്?

ഈ മൊഡ്യൂൾ എന്ത് വാദങ്ങൾ സ്വീകരിക്കുന്നു. ടെറഗ്രണ്ടിനെക്കുറിച്ച് അത്രയേ അറിയൂ.

ഡോക്യുമെന്റേഷൻ അവിടെയുണ്ട്, GitHub-ൽ 1 നക്ഷത്രങ്ങളുണ്ട്. എന്നാൽ മിക്ക കേസുകളിലും നിങ്ങൾ അറിയേണ്ടത് ഇതാണ്. ടെറാഫോമിൽ പ്രവർത്തിക്കാൻ തുടങ്ങുന്ന കമ്പനികളിൽ ഇത് നടപ്പിലാക്കാൻ വളരെ എളുപ്പമാണ്.

അതിനാൽ ഓർക്കസ്ട്രേഷൻ ടെറഗ്രന്റ് ആണ്. മറ്റ് ഓപ്ഷനുകൾ ഉണ്ട്.

ഇപ്പോൾ കോഡ് ഉപയോഗിച്ച് എങ്ങനെ പ്രവർത്തിക്കാം എന്നതിനെക്കുറിച്ച് സംസാരിക്കാം.

നിങ്ങളുടെ കോഡിലേക്ക് പുതിയ സവിശേഷതകൾ ചേർക്കണമെങ്കിൽ, മിക്ക കേസുകളിലും ഇത് എളുപ്പമാണ്. നിങ്ങൾ ഒരു പുതിയ ഉറവിടം എഴുതുകയാണ്, എല്ലാം ലളിതമാണ്.

നിങ്ങൾ മുൻകൂട്ടി സൃഷ്‌ടിച്ച ചില ഉറവിടങ്ങൾ നിങ്ങളുടെ പക്കലുണ്ടെങ്കിൽ, ഉദാഹരണത്തിന്, നിങ്ങൾ ഒരു AWS അക്കൗണ്ട് തുറന്നതിന് ശേഷം ടെറാഫോമിനെക്കുറിച്ച് നിങ്ങൾ മനസ്സിലാക്കുകയും നിങ്ങൾക്ക് ഇതിനകം ഉള്ള ഉറവിടങ്ങൾ ഉപയോഗിക്കാൻ ആഗ്രഹിക്കുകയും ചെയ്യുന്നുവെങ്കിൽ, നിങ്ങളുടെ മൊഡ്യൂൾ ഈ രീതിയിൽ വിപുലീകരിക്കുന്നത് ഉചിതമാണ്. നിലവിലുള്ള വിഭവങ്ങളുടെ ഉപയോഗത്തെ ഇത് പിന്തുണയ്ക്കുന്നു.

ബ്ലോക്ക് റിസോഴ്‌സ് ഉപയോഗിച്ച് പുതിയ ഉറവിടങ്ങൾ സൃഷ്ടിക്കുന്നതിനെ പിന്തുണച്ചു.

ഔട്ട്‌പുട്ടിൽ, ഉപയോഗിച്ചതിനെ ആശ്രയിച്ച് ഞങ്ങൾ എല്ലായ്പ്പോഴും ഔട്ട്‌പുട്ട് ഐഡി നൽകുന്നു.

Terraform 0.11 ലെ രണ്ടാമത്തെ വളരെ പ്രധാനപ്പെട്ട പ്രശ്നം ലിസ്റ്റുകളുമായി പ്രവർത്തിക്കുന്നു.

ഞങ്ങൾക്ക് അത്തരം ഉപയോക്താക്കളുടെ ഒരു ലിസ്റ്റ് ഉണ്ടെങ്കിൽ എന്നതാണ് ബുദ്ധിമുട്ട്.

ബ്ലോക്ക് റിസോഴ്‌സ് ഉപയോഗിച്ച് ഞങ്ങൾ ഈ ഉപയോക്താക്കളെ സൃഷ്ടിക്കുമ്പോൾ, എല്ലാം ശരിയാകും. ഞങ്ങൾ മുഴുവൻ ലിസ്റ്റിലൂടെയും കടന്നുപോകുന്നു, ഓരോന്നിനും ഒരു ഫയൽ സൃഷ്ടിക്കുന്നു. എല്ലാം നന്നായിട്ടുണ്ട്. തുടർന്ന്, ഉദാഹരണത്തിന്, മധ്യഭാഗത്തുള്ള user3, ഇവിടെ നിന്ന് നീക്കംചെയ്യണം, തുടർന്ന് അദ്ദേഹത്തിന് ശേഷം സൃഷ്ടിച്ച എല്ലാ ഉറവിടങ്ങളും വീണ്ടും സൃഷ്ടിക്കപ്പെടും, കാരണം സൂചിക മാറും.

ഒരു സംസ്ഥാന പരിതസ്ഥിതിയിൽ ലിസ്റ്റുകൾക്കൊപ്പം പ്രവർത്തിക്കുന്നു. എന്താണ് ഒരു സംസ്ഥാന പരിസ്ഥിതി? ഈ വിഭവം സൃഷ്ടിക്കുമ്പോൾ ഒരു പുതിയ മൂല്യം സൃഷ്ടിക്കപ്പെടുന്ന സാഹചര്യമാണിത്. ഉദാഹരണത്തിന്, AWS ആക്സസ് കീ അല്ലെങ്കിൽ AWS രഹസ്യ കീ, അതായത് ഞങ്ങൾ ഒരു ഉപയോക്താവിനെ സൃഷ്ടിക്കുമ്പോൾ, ഞങ്ങൾക്ക് ഒരു പുതിയ ആക്സസ് അല്ലെങ്കിൽ രഹസ്യ കീ ലഭിക്കും. ഓരോ തവണയും ഞങ്ങൾ ഒരു ഉപയോക്താവിനെ ഇല്ലാതാക്കുമ്പോൾ, ഈ ഉപയോക്താവിന് ഒരു പുതിയ കീ ഉണ്ടായിരിക്കും. എന്നാൽ ഇത് ഫെങ് ഷൂയി അല്ല, കാരണം ഒരാൾ ടീമിൽ നിന്ന് പുറത്തുപോകുമ്പോഴെല്ലാം അവനുവേണ്ടി ഒരു പുതിയ ഉപയോക്താവിനെ സൃഷ്ടിച്ചാൽ ഉപയോക്താവിന് ഞങ്ങളുമായി ചങ്ങാതിമാരാകാൻ ആഗ്രഹമില്ല.

ഇതാണ് പരിഹാരം. ഇത് Jsonnet-ൽ എഴുതിയ കോഡാണ്. Google-ൽ നിന്നുള്ള ഒരു ടെംപ്ലേറ്റിംഗ് ഭാഷയാണ് Jsonnet.

ഈ കമാൻഡ് നിങ്ങളെ ഈ ടെംപ്ലേറ്റ് സ്വീകരിക്കാൻ അനുവദിക്കുന്നു കൂടാതെ നിങ്ങളുടെ ടെംപ്ലേറ്റ് അനുസരിച്ച് നിർമ്മിച്ച ഒരു json ഫയൽ ഔട്ട്പുട്ടായി ഇത് നൽകുന്നു.

ടെംപ്ലേറ്റ് ഇതുപോലെ കാണപ്പെടുന്നു.

HCL, Json എന്നിവയിൽ ഒരേ രീതിയിൽ പ്രവർത്തിക്കാൻ Terraform നിങ്ങളെ അനുവദിക്കുന്നു, അതിനാൽ നിങ്ങൾക്ക് Json സൃഷ്ടിക്കാനുള്ള കഴിവുണ്ടെങ്കിൽ, നിങ്ങൾക്ക് അത് Terraform-ലേക്ക് സ്ലിപ്പ് ചെയ്യാം. .tf.json വിപുലീകരണമുള്ള ഫയൽ വിജയകരമായി ഡൗൺലോഡ് ചെയ്യപ്പെടും.

തുടർന്ന് ഞങ്ങൾ പതിവുപോലെ പ്രവർത്തിക്കുന്നു: terraform init, terramorm ബാധകം. ഞങ്ങൾ രണ്ട് ഉപയോക്താക്കളെ സൃഷ്ടിക്കുന്നു.

ഇനി ആരെങ്കിലും ടീം വിട്ടാൽ ഞങ്ങൾക്ക് പേടിയില്ല. ഞങ്ങൾ json ഫയൽ എഡിറ്റ് ചെയ്യും. വാസ്യ പപ്കിൻ പോയി, പെത്യ പ്യാറ്റോച്ച്കിൻ തുടർന്നു. Petya Pyatochkin ഒരു പുതിയ കീ ലഭിക്കില്ല.

ടെറാഫോം മറ്റ് ഉപകരണങ്ങളുമായി സംയോജിപ്പിക്കുന്നത് യഥാർത്ഥത്തിൽ ടെറാഫോമിന്റെ ജോലിയല്ല. വിഭവങ്ങൾ സൃഷ്ടിക്കുന്നതിനുള്ള ഒരു പ്ലാറ്റ്ഫോമായി ടെറാഫോം സൃഷ്ടിച്ചു, അത്രമാത്രം. പിന്നീട് വരുന്നതെല്ലാം ടെറാഫോമിന്റെ ആശങ്കയല്ല. പിന്നെ അവിടെ നെയ്യേണ്ട കാര്യമില്ല. നിങ്ങൾക്ക് ആവശ്യമുള്ളതെല്ലാം ചെയ്യുന്ന അൻസിബിൾ ഉണ്ട്.

എന്നാൽ ടെറാഫോം വിപുലീകരിക്കാനും എന്തെങ്കിലും പൂർത്തിയായതിന് ശേഷം കുറച്ച് കമാൻഡ് വിളിക്കാനും ഞങ്ങൾ ആഗ്രഹിക്കുന്ന സാഹചര്യങ്ങൾ ഉണ്ടാകുന്നു.

ആദ്യ വഴി. ഈ കമാൻഡ് എഴുതുന്നിടത്ത് ഞങ്ങൾ ഒരു ഔട്ട്പുട്ട് ഉണ്ടാക്കുന്നു.

തുടർന്ന് നമ്മൾ ഷെൽ ടെറഫോം ഔട്ട്പുട്ടിൽ നിന്ന് ഈ കമാൻഡ് വിളിക്കുകയും നമുക്ക് ആവശ്യമുള്ള മൂല്യം വ്യക്തമാക്കുകയും ചെയ്യുന്നു. അങ്ങനെ, കമാൻഡ് എല്ലാ പകരമുള്ള മൂല്യങ്ങളും ഉപയോഗിച്ച് നടപ്പിലാക്കുന്നു. ഇത് വളരെ സുഖകരമാണ്.

രണ്ടാമത്തെ വഴി. ഞങ്ങളുടെ ഇൻഫ്രാസ്ട്രക്ചറിലെ മാറ്റങ്ങൾ അനുസരിച്ച് null_resource-ന്റെ ഉപയോഗമാണിത്. ചില റിസോഴ്‌സുകളുടെ ഐഡി മാറിയാൽ ഉടൻ തന്നെ അതേ ലോക്കൽ-എക്‌സിനെ നമുക്ക് വിളിക്കാം.

സ്വാഭാവികമായും, ഇതെല്ലാം കടലാസിൽ സുഗമമാണ്, കാരണം മറ്റെല്ലാ പൊതു ദാതാക്കളെയും പോലെ ആമസോണിനും അതിന്റേതായ ഒരു കൂട്ടം കേസുകൾ ഉണ്ട്.

നിങ്ങൾ ഒരു AWS അക്കൗണ്ട് തുറക്കുമ്പോൾ, നിങ്ങൾ ഏത് മേഖലയാണ് ഉപയോഗിക്കുന്നതെന്നത് പ്രധാനമാണ് എന്നതാണ് ഏറ്റവും സാധാരണമായ എഡ്ജ് കേസ്; ഈ സവിശേഷത അവിടെ പ്രവർത്തനക്ഷമമാക്കിയിട്ടുണ്ടോ; 2013 ഡിസംബറിന് ശേഷം നിങ്ങൾ അത് തുറന്നേക്കാം; വിപിസിയിലും മറ്റും നിങ്ങൾ ഡിഫോൾട്ട് ഉപയോഗിക്കുന്നുണ്ടാകാം. നിരവധി നിയന്ത്രണങ്ങളുണ്ട്. ആമസോൺ അവയെ ഡോക്യുമെന്റേഷനിൽ ഉടനീളം ചിതറിച്ചു.

ഒഴിവാക്കാൻ ഞാൻ ശുപാർശ ചെയ്യുന്ന ചില കാര്യങ്ങളുണ്ട്.

ആരംഭിക്കുന്നതിന്, Terraform പ്ലാനിലോ Terraform CLI-യിലോ ഉള്ള എല്ലാ രഹസ്യമല്ലാത്ത ആർഗ്യുമെന്റുകളും ഒഴിവാക്കുക. ഇതെല്ലാം ഒരു tfvars ഫയലിലേക്കോ അല്ലെങ്കിൽ ഒരു എൻവയോൺമെന്റ് വേരിയബിളിലേക്കോ ചേർക്കാം.

എന്നാൽ ഈ മാന്ത്രിക കമാൻഡ് മുഴുവനായും നിങ്ങൾ മനഃപാഠമാക്കേണ്ടതില്ല. ടെറാഫോം പ്ലാൻ - var, ഓഫ് ഞങ്ങൾ പോകുന്നു. ആദ്യത്തെ വേരിയബിൾ var ആണ്, രണ്ടാമത്തെ വേരിയബിൾ var ആണ്, മൂന്നാമത്തേത്, നാലാമത്തേത്. ഞാൻ മിക്കപ്പോഴും ഉപയോഗിക്കുന്ന കോഡ് എന്ന നിലയിൽ ഇൻഫ്രാസ്ട്രക്ചറിന്റെ ഏറ്റവും പ്രധാനപ്പെട്ട തത്വം, കോഡ് നോക്കുന്നതിലൂടെ, അവിടെ എന്താണ് വിന്യസിച്ചിരിക്കുന്നത്, ഏത് അവസ്ഥയിലാണ്, ഏത് മൂല്യങ്ങളോടെ എന്നതിനെക്കുറിച്ച് എനിക്ക് വ്യക്തമായ ധാരണ ഉണ്ടായിരിക്കണം എന്നതാണ്. അതിനാൽ എനിക്ക് ഡോക്യുമെന്റേഷൻ വായിക്കുകയോ ഞങ്ങളുടെ ക്ലസ്റ്റർ സൃഷ്ടിക്കാൻ അദ്ദേഹം എന്ത് പാരാമീറ്ററുകൾ ഉപയോഗിച്ചുവെന്ന് വാസ്യയോട് ചോദിക്കുകയോ ചെയ്യേണ്ടതില്ല. എനിക്ക് tfvars എക്സ്റ്റൻഷനുള്ള ഒരു ഫയൽ തുറക്കേണ്ടതുണ്ട്, അത് പലപ്പോഴും പരിസ്ഥിതിയുമായി പൊരുത്തപ്പെടുന്നു, അവിടെയുള്ള എല്ലാം നോക്കുക.

കൂടാതെ, വ്യാപ്തി കുറയ്ക്കാൻ ടാർഗെറ്റ് ആർഗ്യുമെന്റുകൾ ഉപയോഗിക്കരുത്. ഇതിനായി ചെറിയ ഇൻഫ്രാസ്ട്രക്ചർ മൊഡ്യൂളുകൾ ഉപയോഗിക്കുന്നത് വളരെ എളുപ്പമാണ്.

കൂടാതെ, സമാന്തരത പരിമിതപ്പെടുത്തുകയും വർദ്ധിപ്പിക്കുകയും ചെയ്യേണ്ട ആവശ്യമില്ല. എനിക്ക് 150 ഉറവിടങ്ങൾ ഉണ്ടെങ്കിൽ, ആമസോൺ പാരലലിസം ഡിഫോൾട്ട് 10 ൽ നിന്ന് 100 ആയി വർദ്ധിപ്പിക്കാൻ ഞാൻ ആഗ്രഹിക്കുന്നുവെങ്കിൽ, മിക്കവാറും എന്തെങ്കിലും തെറ്റ് സംഭവിക്കും. അല്ലെങ്കിൽ ഇപ്പോൾ അത് നന്നായി പോയേക്കാം, എന്നാൽ നിങ്ങൾ വളരെയധികം കോളുകൾ ചെയ്യുന്നുണ്ടെന്ന് ആമസോൺ പറയുമ്പോൾ, നിങ്ങൾ കുഴപ്പത്തിലാകും.

ഈ പ്രശ്‌നങ്ങളിൽ ഭൂരിഭാഗവും പുനരാരംഭിക്കാൻ ടെറാഫോം ശ്രമിക്കും, പക്ഷേ നിങ്ങൾക്ക് ഒന്നും നേടാനാകില്ല. AWS API-യിലോ ടെറാഫോം ദാതാവിനുള്ളിലോ എന്തെങ്കിലും ബഗിൽ നിങ്ങൾ ഇടറിവീഴുകയാണെങ്കിൽ പാരലലിസം=1 എന്നത് ഉപയോഗിക്കേണ്ട ഒരു പ്രധാന കാര്യമാണ്. തുടർന്ന് നിങ്ങൾ വ്യക്തമാക്കേണ്ടതുണ്ട്: പാരലലിസം=1 ടെറാഫോം ഒരു കോൾ പൂർത്തിയാക്കുന്നത് വരെ കാത്തിരിക്കുക, തുടർന്ന് രണ്ടാമത്തേത്, തുടർന്ന് മൂന്നാമത്തേത്. അവൻ അവ ഓരോന്നായി വിക്ഷേപിക്കും.

ആളുകൾ എന്നോട് പലപ്പോഴും ചോദിക്കാറുണ്ട്, "ടെറാഫോം വർക്ക്‌സ്‌പേസ് മോശമാണെന്ന് ഞാൻ കരുതുന്നത് എന്തുകൊണ്ട്?" അടിസ്ഥാന സൗകര്യങ്ങളുടെ ഒരു കോഡായി ഞാൻ വിശ്വസിക്കുന്നു, എന്തെല്ലാം അടിസ്ഥാന സൗകര്യങ്ങൾ സൃഷ്ടിച്ചു, എന്ത് മൂല്യങ്ങളോടെയാണ് അത് സൃഷ്ടിക്കപ്പെട്ടതെന്ന് കാണുക എന്നതാണ്.

ഉപയോക്താക്കൾ സൃഷ്‌ടിച്ചതല്ല വർക്ക്‌സ്‌പെയ്‌സ്. ടെറാഫോം വർക്ക്‌സ്‌പെയ്‌സ് ഇല്ലാതെ ഞങ്ങൾക്ക് ജീവിക്കാൻ കഴിയില്ലെന്ന് ഉപയോക്താക്കൾ GitHub പ്രശ്‌നങ്ങളിൽ എഴുതിയിട്ടുണ്ടെന്ന് ഇതിനർത്ഥമില്ല. ഇല്ല ഇങ്ങനെയല്ല. ടെറാഫോം എന്റർപ്രൈസ് ഒരു വാണിജ്യ പരിഹാരമാണ്. ഹാഷികോർപ്പിൽ നിന്നുള്ള ടെറാഫോം ഞങ്ങൾക്ക് വർക്ക്‌സ്‌പെയ്‌സ് ആവശ്യമാണെന്ന് തീരുമാനിച്ചു, അതിനാൽ ഞങ്ങൾ അത് ഫയൽ ചെയ്തു. ഇത് ഒരു പ്രത്യേക ഫോൾഡറിൽ ഇടുന്നത് വളരെ എളുപ്പമാണെന്ന് ഞാൻ കാണുന്നു. അപ്പോൾ കുറച്ചുകൂടി ഫയലുകൾ ഉണ്ടാകും, പക്ഷേ അത് കൂടുതൽ വ്യക്തമാകും.

കോഡ് ഉപയോഗിച്ച് എങ്ങനെ പ്രവർത്തിക്കാം? വാസ്തവത്തിൽ, ലിസ്റ്റുകൾക്കൊപ്പം പ്രവർത്തിക്കുന്നത് ഒരേയൊരു വേദനയാണ്. ടെറാഫോം എളുപ്പത്തിൽ എടുക്കുക. നിങ്ങൾക്കായി എല്ലാം മഹത്തരമായി ചെയ്യുന്ന കാര്യമല്ല ഇത്. ഡോക്യുമെന്റേഷനിൽ എഴുതിയിരിക്കുന്നതെല്ലാം അവിടെ തള്ളേണ്ട ആവശ്യമില്ല.

റിപ്പോർട്ടിന്റെ വിഷയം "ഭാവിയിൽ" എഴുതിയതാണ്. ഞാൻ ഇതിനെക്കുറിച്ച് വളരെ ഹ്രസ്വമായി സംസാരിക്കും. ഭാവിയിൽ, 0.12 ഉടൻ പുറത്തിറങ്ങും എന്നാണ് ഇതിനർത്ഥം.

0.12 എന്നത് ഒരു ടൺ പുതിയ സാധനങ്ങളാണ്. നിങ്ങൾ സാധാരണ പ്രോഗ്രാമിംഗിൽ നിന്നാണ് വരുന്നതെങ്കിൽ, എല്ലാത്തരം ഡൈനാമിക് ബ്ലോക്കുകൾ, ലൂപ്പുകൾ, ശരിയായതും സോപാധികവുമായ താരതമ്യ പ്രവർത്തനങ്ങൾ എന്നിവ നിങ്ങൾക്ക് നഷ്ടമാകും, അവിടെ ഇടതും വലതും വശങ്ങൾ ഒരേസമയം കണക്കാക്കില്ല, പക്ഷേ സാഹചര്യം അനുസരിച്ച്. നിങ്ങൾ ഇത് വളരെയധികം നഷ്ടപ്പെടുത്തുന്നു, അതിനാൽ 0.12 നിങ്ങൾക്കായി ഇത് പരിഹരിക്കും.

പക്ഷേ! റെഡിമെയ്ഡ് മൊഡ്യൂളുകളും മൂന്നാം കക്ഷി പരിഹാരങ്ങളും ഉപയോഗിച്ച് നിങ്ങൾ കുറച്ചുകൂടി ലളിതമായി എഴുതുകയാണെങ്കിൽ, നിങ്ങൾ കാത്തിരിക്കേണ്ടതില്ല, 0.12 വന്ന് നിങ്ങൾക്കായി എല്ലാം ശരിയാക്കുമെന്ന് പ്രതീക്ഷിക്കുക.

റിപ്പോർട്ടിന് നന്ദി! നിങ്ങൾ ഇൻഫ്രാസ്ട്രക്ചറിനെ കോഡായി സംസാരിച്ചു, ടെസ്റ്റുകളെ കുറിച്ച് അക്ഷരാർത്ഥത്തിൽ ഒരു വാക്ക് പറഞ്ഞു. മൊഡ്യൂളുകളിൽ പരിശോധനകൾ ആവശ്യമാണോ? ഇത് ആരുടെ ഉത്തരവാദിത്തമാണ്? ഞാൻ ഇത് സ്വയം എഴുതേണ്ടതുണ്ടോ അതോ മൊഡ്യൂളുകളുടെ ഉത്തരവാദിത്തമാണോ?

എല്ലാം പരീക്ഷിക്കാൻ ഞങ്ങൾ തീരുമാനിച്ചു എന്ന റിപ്പോർട്ടുകളാൽ അടുത്ത വർഷം നിറയും. എന്ത് പരീക്ഷിക്കണം എന്നതാണ് ഏറ്റവും വലിയ ചോദ്യം. ധാരാളം ഡിപൻഡൻസികൾ ഉണ്ട്, വ്യത്യസ്ത ദാതാക്കളിൽ നിന്നുള്ള ധാരാളം നിയന്ത്രണങ്ങൾ. നിങ്ങളും ഞാനും സംസാരിക്കുമ്പോൾ, "എനിക്ക് ടെസ്റ്റുകൾ വേണം" എന്ന് നിങ്ങൾ പറയുമ്പോൾ, ഞാൻ ചോദിക്കുന്നു: "നിങ്ങൾ എന്ത് പരീക്ഷിക്കും?" നിങ്ങളുടെ പ്രദേശത്ത് പരീക്ഷിക്കുമെന്ന് നിങ്ങൾ പറയുന്നു. അപ്പോൾ ഞാൻ പറയുന്നു ഇത് എന്റെ പ്രദേശത്ത് പ്രവർത്തിക്കുന്നില്ല. അതായത്, ഞങ്ങൾക്ക് ഇത് അംഗീകരിക്കാൻ പോലും കഴിയില്ല. സാങ്കേതിക പ്രശ്‌നങ്ങൾ ഏറെയുണ്ടെന്ന് പറയാതെ വയ്യ. അതായത്, ഈ ടെസ്റ്റുകൾ എങ്ങനെ എഴുതാം, അങ്ങനെ അവ മതിയാകും.

ഞാൻ ഈ വിഷയത്തിൽ സജീവമായി ഗവേഷണം നടത്തുകയാണ്, അതായത് നിങ്ങൾ എഴുതിയ ഇൻഫ്രാസ്ട്രക്ചറിനെ അടിസ്ഥാനമാക്കി ടെസ്റ്റുകൾ സ്വയമേവ എങ്ങനെ ജനറേറ്റ് ചെയ്യാം. അതായത്, നിങ്ങൾ ഈ കോഡ് എഴുതിയിട്ടുണ്ടെങ്കിൽ, എനിക്ക് ഇത് പ്രവർത്തിപ്പിക്കേണ്ടതുണ്ട്, ഇതിനെ അടിസ്ഥാനമാക്കി എനിക്ക് ടെസ്റ്റുകൾ സൃഷ്ടിക്കാൻ കഴിയും.

ടെറാറ്റെസ്റ്റ് ടെറാഫോമിനായി ഇന്റഗ്രേഷൻ ടെസ്റ്റുകൾ എഴുതാൻ നിങ്ങളെ അനുവദിക്കുന്ന ഏറ്റവും കൂടുതൽ പരാമർശിക്കപ്പെടുന്ന ലൈബ്രറികളിൽ ഒന്നാണ്. ഇത് യൂട്ടിലിറ്റികളിൽ ഒന്നാണ്. ഞാൻ DSL തരമാണ് ഇഷ്ടപ്പെടുന്നത്, ഉദാഹരണത്തിന്, rspec.

ആന്റൺ, റിപ്പോർട്ടിന് നന്ദി! എന്റെ പേര് വലേരി. ഞാൻ ഒരു ചെറിയ ദാർശനിക ചോദ്യം ചോദിക്കട്ടെ. സോപാധികമായി, പ്രൊവിഷനിംഗ് ഉണ്ട്, വിന്യാസമുണ്ട്. പ്രൊവിഷനിംഗ് എന്റെ ഇൻഫ്രാസ്ട്രക്ചർ സൃഷ്ടിക്കുന്നു, വിന്യാസത്തിൽ ഞങ്ങൾ അത് ഉപയോഗപ്രദമായ എന്തെങ്കിലും കൊണ്ട് പൂരിപ്പിക്കുന്നു, ഉദാഹരണത്തിന്, സെർവറുകൾ, ആപ്ലിക്കേഷനുകൾ മുതലായവ. ടെറാഫോം കൂടുതൽ പ്രൊവിഷനിംഗിനും അൻസിബിൾ വിന്യാസത്തിനും കൂടുതലാണെന്നത് എന്റെ തലയിലാണ്, കാരണം അൻസിബിൾ ഫിസിക്കൽ ഇൻഫ്രാസ്ട്രക്ചറിന് കൂടിയാണ്. nginx, Postgres ഇൻസ്റ്റാൾ ചെയ്യാൻ നിങ്ങളെ അനുവദിക്കുന്നു. എന്നാൽ അതേ സമയം, ആമസോൺ അല്ലെങ്കിൽ ഗൂഗിൾ റിസോഴ്സുകളുടെ പ്രൊവിഷനിംഗ് അൻസിബിൾ അനുവദിക്കുന്നതായി തോന്നുന്നു. എന്നാൽ ടെറാഫോം അതിന്റെ മൊഡ്യൂളുകൾ ഉപയോഗിച്ച് ചില സോഫ്റ്റ്‌വെയറുകൾ വിന്യസിക്കാനും നിങ്ങളെ അനുവദിക്കുന്നു. നിങ്ങളുടെ കാഴ്ചപ്പാടിൽ, ടെറാഫോമിനും അൻസിബിളിനും ഇടയിൽ പ്രവർത്തിക്കുന്ന ഏതെങ്കിലും തരത്തിലുള്ള ബോർഡർ ഉണ്ടോ, എവിടെ, എന്താണ് ഉപയോഗിക്കുന്നതാണ് നല്ലത്? അല്ലെങ്കിൽ, ഉദാഹരണത്തിന്, അൻസിബിൾ ഇതിനകം മാലിന്യമാണെന്ന് നിങ്ങൾ കരുതുന്നുണ്ടോ, എല്ലാത്തിനും ടെറാഫോം ഉപയോഗിക്കാൻ നിങ്ങൾ ശ്രമിക്കണോ?

നല്ല ചോദ്യം, വലേരി. 2014 മുതൽ ഉദ്ദേശ്യത്തിന്റെ കാര്യത്തിൽ ടെറാഫോമിന് മാറ്റമൊന്നും സംഭവിച്ചിട്ടില്ലെന്ന് ഞാൻ വിശ്വസിക്കുന്നു. ഇത് അടിസ്ഥാന സൗകര്യങ്ങൾക്കായി സൃഷ്ടിച്ചതാണ്, അടിസ്ഥാന സൗകര്യങ്ങൾക്കായി മരിച്ചു. കോൺഫിഗറേഷൻ മാനേജ്‌മെന്റ് അൻസിബിളിന്റെ ആവശ്യകത ഞങ്ങൾക്ക് ഇപ്പോഴും ഉണ്ടായിരുന്നു. ലോഞ്ച്_കോൺഫിഗറേഷനിൽ ഉപയോക്തൃ ഡാറ്റയുണ്ട് എന്നതാണ് വെല്ലുവിളി. അവിടെ നിങ്ങൾ അൻസിബിളും മറ്റും വലിക്കുന്നു. ഇതാണ് എനിക്ക് ഏറ്റവും ഇഷ്ടപ്പെട്ട സ്റ്റാൻഡേർഡ് വ്യതിരിക്തത.

മനോഹരമായ ഇൻഫ്രാസ്ട്രക്ചറിനെക്കുറിച്ചാണ് നമ്മൾ സംസാരിക്കുന്നതെങ്കിൽ, ഈ ചിത്രം ശേഖരിക്കുന്ന പാക്കർ പോലുള്ള യൂട്ടിലിറ്റികളുണ്ട്. ഈ ചിത്രം കണ്ടെത്തുന്നതിനും അതിന്റെ ലോഞ്ച്_കോൺഫിഗറേഷൻ അപ്‌ഡേറ്റ് ചെയ്യുന്നതിനും Terraform ഡാറ്റ ഉറവിടം ഉപയോഗിക്കുന്നു. അതായത്, ഈ രീതിയിൽ പൈപ്പ്ലൈൻ നമ്മൾ ആദ്യം ട്രാക്കർ വലിക്കുക, തുടർന്ന് ടെറാഫോം വലിക്കുക എന്നതാണ്. നിർമ്മാണം സംഭവിക്കുകയാണെങ്കിൽ, ഒരു പുതിയ മാറ്റം സംഭവിക്കുന്നു.

ഹലോ! റിപ്പോർട്ടിന് നന്ദി! എന്റെ പേര് മിഷ, RBS കമ്പനി. ഒരു റിസോഴ്സ് സൃഷ്ടിക്കുമ്പോൾ പ്രൊവിഷനർ വഴി നിങ്ങൾക്ക് അൻസിബിളിനെ വിളിക്കാം. അൻസിബിളിന് ഡൈനാമിക് ഇൻവെന്ററി എന്നൊരു വിഷയവുമുണ്ട്. നിങ്ങൾക്ക് ആദ്യം ടെറാഫോമിൽ വിളിക്കാം, തുടർന്ന് അൻസിബിളിനെ വിളിക്കാം, അത് സംസ്ഥാനത്ത് നിന്ന് വിഭവങ്ങൾ എടുത്ത് അത് നടപ്പിലാക്കും. എന്താണ് നല്ലത്?

രണ്ടും തുല്യമായ വിജയത്തോടെയാണ് ആളുകൾ ഉപയോഗിക്കുന്നത്. ഓട്ടോസ്‌കേലിംഗ് ഗ്രൂപ്പിനെക്കുറിച്ചല്ല നമ്മൾ സംസാരിക്കുന്നതെങ്കിൽ, അൻസിബിളിലെ ഡൈനാമിക് ഇൻവെന്ററി ഒരു സൗകര്യപ്രദമാണെന്ന് എനിക്ക് തോന്നുന്നു. കാരണം ഓട്ടോസ്‌കേലിംഗ് ഗ്രൂപ്പിൽ ഞങ്ങൾക്ക് ഇതിനകം തന്നെ ഞങ്ങളുടെ സ്വന്തം ടൂൾകിറ്റ് ഉണ്ട്, അതിനെ launch_configuration എന്ന് വിളിക്കുന്നു. ലാഞ്ച്_കോൺഫിഗറേഷനിൽ ഞങ്ങൾ ഒരു പുതിയ ഉറവിടം സൃഷ്ടിക്കുമ്പോൾ ലോഞ്ച് ചെയ്യേണ്ടതെല്ലാം ഞങ്ങൾ രേഖപ്പെടുത്തുന്നു. അതിനാൽ, ആമസോണിനൊപ്പം, ഡൈനാമിക് ഇൻവെന്ററി ഉപയോഗിക്കുകയും ടെറാഫോം ടിഎസ് ഫയൽ വായിക്കുകയും ചെയ്യുന്നത്, എന്റെ അഭിപ്രായത്തിൽ, ഓവർകില്ലാണ്. “ഓട്ടോസ്‌കേലിംഗ് ഗ്രൂപ്പ്” എന്ന ആശയം ഇല്ലാത്ത മറ്റ് ടൂളുകൾ നിങ്ങൾ ഉപയോഗിക്കുകയാണെങ്കിൽ, ഉദാഹരണത്തിന്, നിങ്ങൾ ഡിജിറ്റൽ ഓഷ്യൻ അല്ലെങ്കിൽ ഓട്ടോസ്‌കേലിംഗ് ഗ്രൂപ്പ് ഇല്ലാത്ത മറ്റേതെങ്കിലും ദാതാവ് ഉപയോഗിക്കുന്നുവെങ്കിൽ, അവിടെ നിങ്ങൾ സ്വമേധയാ API വലിക്കുകയും IP വിലാസങ്ങൾ കണ്ടെത്തുകയും സൃഷ്ടിക്കുകയും വേണം. ഒരു ഡൈനാമിക് ഇൻവെന്ററി ഫയൽ, അൻസിബിൾ ഇതിനകം അതിലൂടെ അലഞ്ഞുതിരിയുന്നു. അതായത്, Amazon-ന് launch_configuration ഉണ്ട്, മറ്റെല്ലാത്തിനും ഡൈനാമിക് ഇൻവെന്ററി ഉണ്ട്.

അവലംബം: www.habr.com