മറ്റുള്ളവര് ക്ക് ഉപയോഗിക്കാന് ആഗ്രഹിക്കുന്ന ടെറാഫോർം മൊഡ്യൂളുകള്

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

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

വ്യക്തമായ ഒരു ലക്ഷ്യത്തോടെ തുടങ്ങുക

ഒരു നല്ല മോഡുലര് ഒരു കാര്യം നന്നായി ചെയ്യുന്നു, ഒരു അഭിപ്രായം. "എല്ലാ വാദങ്ങളും ഒരു പൊതിഞ്ഞ അല്ല aws_db_instance"എന്നാല് "ഒരു പോസ്റ്റ്ഗ്രെ എസ്. ക്യു. എൽ. ഡാറ്റാബേസ് ക്രമീകരിച്ചിരിക്കുന്നത് നമ്മൾ ഡാറ്റാ ബേസുകള് ഇവിടെ പ്രവർത്തിപ്പിക്കുന്ന രീതിയിലാണ്":

ഈ മോഡുല് അടിസ്ഥാന റിസോഴ്സിന്റെ എല്ലാ ആർഗ്യുമെന്റുകളിലൂടെയും കടന്നുപോകുന്നുവെങ്കില് അത് ഒരു മൂല്യവും കൂട്ടിച്ചേര് ക്കുന്നില്ല. ടീമുകൾക്ക് നേരിട്ട് റിസോഴ്സ് ഉപയോഗിക്കാം.

നല്ല ഒരു മോഡുലര് തീരുമാനങ്ങള് നീക്കം ചെയ്യുന്നു. ഒരു മോശം മോഡുലര് അവരെ മറ്റൊരു ഫയലിലേക്ക് മാറ്റുന്നു.

ശുദ്ധമായ ഒരു ഘടന

modules/rds-postgres/
  main.tf
  variables.tf
  outputs.tf
  versions.tf
  README.md
  examples/
    basic/
      main.tf
  tests/
    defaults.tftest.hcl

• versions.tf ആവശ്യമായ ടെറാഫോർം പതിപ്പും ദാതാവിന്റെ പതിപ്പും പിൻസ് ചെയ്യുക.
• examples/ ഇത് യഥാർത്ഥ ഉപയോഗം കാണിക്കുന്നു, ഒരു ടെസ്റ്റ് ഫിക്ചർ ആയി ഇരട്ടിക്കുന്നു.
• tests/ കൂടെ terraform test ഫയലുകൾ

ഇൻപുട്ടുകളും ഔട്ട്പുട്ടുകളും പരിശോധനയും

കുറച്ച് ഇൻപുട്ടുകൾ ആവശ്യമുണ്ട്, ബാക്കി നല്ല സ്ഥിരസ്ഥിതികളാണ്. അടിസ്ഥാന ഉദാഹരണം കുറച്ച് വരികൾ മാത്രം ആവശ്യമായി വരും:

module "orders_db" {
  source      = "git::https://github.com/acme/terraform-modules.git//rds-postgres?ref=v2.3.0"
  name        = "orders"
  environment = "production"
  size        = "medium"
}

ഇൻപുട്ടുകൾ സാധൂകരിക്കുക അതുകൊണ്ട് തെറ്റുകൾക്ക് നേരത്തേ ഒരു വ്യക്തമായ സന്ദേശവുമായി പരാജയപ്പെടാം:

variable "size" {
  description = "Database size: small, medium or large."
  type        = string
  default     = "small"

  validation {
    condition     = contains(["small", "medium", "large"], var.size)
    error_message = "size must be one of: small, medium, large."
  }
}

പരിഭാഷ size = "medium" ഓരോ ടീമും അവരുടെ കോഡ് മാറ്റാതെ തന്നെ അടിസ്ഥാന ഇൻസ്റ്റൻസിനു് തരം മാറ്റാം.

ഉപയോഗപ്രദമായ ഔട്ട്പുട്ടുകൾ: ഐഡി, എൻഡ് പോയിന്റ്, ARN, സെക്യൂരിറ്റി ഗ്രൂപ്പ് ഐഡി, രഹസ്യമായി സൂക്ഷിക്കുന്ന ക്രെഡൻഷ്യലുകളുടെ പേര്. അടുത്ത റിസോഴ്സ് എന്തായിരിക്കുമെന്ന് ആലോചിക്കുക.

കൃത്യമായ തരം ഉപയോഗിക്കുക: object({...}) പൊതുവായ ഒരു ആട്രിബ്യൂട്ടിന് പകരം ഓപ്ഷണൽ ആട്രിബിറ്റുകളുള്ളവ map(any).

പതിപ്പ് നിയന്ത്രണവും സ്വകാര്യ രജിസ്ട്രിയും

മൊഡ്യൂളുകൾ മാറുന്നു. ഉപയോക്താക്കൾക്ക് സ്ഥിരത വേണം. അപ്പോൾ:

• ടാഗ് റിലീസുകൾ സെമാന്റിക് പതിപ്പുകളുമായി: v1.4.0, v2.0.0.
• എല്ലായ്പ്പോഴും ഒരു പതിപ്പ് പരാമർശിക്കുക (?ref=v2.3.0 ഗിറ്റിനു വേണ്ടി, അല്ലെങ്കിൽ version = "~> 2.3" ഒരു രജിസ്ട്രിക്ക് വേണ്ടി). ഒരിക്കലും ചൂണ്ടിക്കാണിക്കരുത് main.
• ഒരു മാറ്റലോഗ് എഴുതുക, ഒപ്പം മാറ്റങ്ങൾ വ്യക്തമായി അടയാളപ്പെടുത്തുക. ഒരു മാറ്റം ഒരു പുതിയ വൻ പതിപ്പ് എന്നാണ് അർത്ഥമാക്കുന്നത്.
• ഒരു സ്വകാര്യ രജിസ്ട്രിയിൽ പ്രസിദ്ധീകരിക്കുക നിങ്ങൾക്ക് കഴിയുമെങ്കിൽ: എച്ച് സി പി ടെറാഫോർം, ഗിറ്റ്ലാബ്, ആർട്ടിഫാക്ടറി, സ്പേസ് ലിഫ്റ്റ് തുടങ്ങിയവയാണ് ഇവ വാഗ്ദാനം ചെയ്യുന്നത്. ഇത് നിങ്ങൾക്ക് പതിപ്പ് നിയന്ത്രണങ്ങളും കണ്ടെത്തലും ഡോക്യുമെന്റേഷനും ഒരു സ്ഥലത്ത് നൽകുന്നു.
• പുതുക്കൽ മോഡുലുകളുടെ പതിപ്പുകൾ അപ്ഡേറ്റ് ചെയ്യട്ടെ ഉപഭോഗം ചെയ്യുന്ന റെപൊസിറ്ററികളില് .

സ്വയം എഴുതുന്ന രേഖകൾ

ആരും കൈകൊണ്ട് ഒരു README പരിപാലിക്കാൻ ആഗ്രഹിക്കുന്നില്ല. ടെറാഫോം ഡോക്കുകൾ നിങ്ങളുടെ കോഡിൽ നിന്നും ഇൻപുട്ട്, ഔട്ട്പുട്ട് പട്ടികകൾ സൃഷ്ടിക്കുന്നു:

terraform-docs markdown table --output-file README.md --output-mode inject .

പ്രീ-കോംമിറ്റ് ഹുക്കിലോ ഐ. സി. യിലോ ഓടിച്ചാല് ഡോക്യുമെന്റേഷന് സമന്വയിപ്പിക്കും. മുകളിൽ ഒരു ചെറിയ മനുഷ്യ എഴുതിയ വിഭാഗം ചേർക്കുകഃ മൊഡ്യൂൾ എന്താണ്, അത് സ്വതവേ എന്താണ് ചെയ്യുന്നത്, ഒരു മിനിമം ഉദാഹരണം.

പരിശോധനാ ഘടകങ്ങൾ

ചില പരിശോധനകൾ പോലും ധാരാളം സഹായിക്കുന്നു:

• പ്ലാനിന് അടിസ്ഥാനമാക്കിയുള്ള പരിശോധനകൾ കൂടെ terraform test സ്ഥിരസ്ഥിതി പരിശോധനയ്ക്കായി: എൻക്രിപ്ഷൻ ഓൺ, ഇല്ലാതാക്കൽ പരിരക്ഷ ഓൺ, ടാഗുകൾ നിലവിലുണ്ട്.
• പരിശോധന തെറ്റായ ഇൻപുട്ടുകൾ നിരസിക്കപ്പെടുന്നു എന്ന് പരിശോധിക്കുക.
• ഒരു പരീക്ഷണം എല്ലാ കമ്മിറ്റുകളിലും അല്ല, റിലീസില് റൺ ചെയ്യണം.
• സ്റ്റാറ്റിക് പരിശോധന (ടിഫ്ലിന്റ്, ചെക്കോവ്) മൊഡ്യൂളിലെ തന്നെ.

എപ്പോഴാണ് നിഷ്കൃഷ്ടമായത് നിർത്തേണ്ടത്?

ഞാൻ കാണുന്ന ഏറ്റവും സാധാരണമായ തെറ്റ്: മൊഡ്യൂളുകൾ പൊതിഞ്ഞ മൊഡ്യൂൾ പൊതിഞ്ഞ മോഡ്യൂളുകളാണ്, ഡസൻ കണക്കിന് വേരിയബിളുകളുള്ള, എല്ലാ സാധ്യതയുള്ള ഉപയോഗ കേസുകൾക്കും ഫീച്ചർ ഫ്ലാഗുകൾ, count എല്ലായിടത്തും തമാശകൾ.

നിങ്ങള് വളരെ ദൂരെ പോയിരിക്കുന്നു എന്നതിന്റെ അടയാളങ്ങള്:

• ഈ മൊഡ്യൂളിന് അത് സൃഷ്ടിക്കുന്ന വിഭവങ്ങളേക്കാൾ കൂടുതൽ വേരിയബിളുകൾ ഉണ്ട്.
• ഒരു പ്രത്യേക പതാക സ്ഥാപിക്കുമ്പോൾ എന്ത് സംഭവിക്കുമെന്ന് ആർക്കും വിശദീകരിക്കാനാവില്ല.
• ടീമുകൾ മോഡുലര് വിഭജിക്കുന്നു കാരണം അത് മാറ്റുന്നത് വളരെ ഭീതിദമാണ്.

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

അതുകൊണ്ട്, എന്താണ് ഒരു വലിയ മൊഡ്യൂൾ ഉണ്ടാക്കുന്നത്?

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

എന്റെ അഭിപ്രായം: ശരിയായ വഴി ചുരുക്കവും വ്യക്തവുമാക്കുന്ന മോഡ്യൂളുകൾ നിർമ്മിക്കുക. പകരം ആളുകൾ വിഭവങ്ങൾ പകര് ത്ത് ഉപയോഗിക്കുന്നുവെങ്കില് , മൊഡ്യൂള് അവരെ സഹായിക്കില്ല.

ഡെസ്ലി