പരിശോധന ഇൻഫ്രാസ്ട്രക്ചർ കോഡ്

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

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

അടിസ്ഥാന സൌകര്യങ്ങളുടെ പരീക്ഷണ പിരമിഡ്

ആപ്ലിക്കേഷൻ ടെസ്റ്റിംഗിനെ പോലെ തന്നെ, ഇൻഫ്രാസ്ട്രക്ചർ ടെസ്റ്റിങ്ങിനും പലതരം പാളികളുണ്ട്, വിലകുറഞ്ഞതും വേഗത കുറഞ്ഞതും വേഗത കുറയുന്നതും ചെലവേറിയതും:

1. സ്റ്റാറ്റിക് പരിശോധന: ഫോർമാറ്റിംഗ്, പരിശോധന, ലിന്റ്റിംഗ്, സുരക്ഷാ സ്കാനിംഗ്. നിമിഷങ്ങൾ, മേഘം വേണ്ട.
2. നയ പരിശോധനകൾഎല്ലാ പദ്ധതികളും പാലിക്കേണ്ട നിയമങ്ങളുണ്ട്. പ്ലാന് ഔട്ട്പുട്ട് ഉപയോഗിച്ച് നിമിഷങ്ങൾ.
3. യൂണിറ്റ് തരം പരിശോധനകൾ: ഒരു പ്ലാനിനൊപ്പമോ, അല്ലെങ്കിൽ കളിയാക്കിയ ദാതാക്കളോ ഉപയോഗിച്ച് മൊഡ്യൂൾ ലോജിക് പരിശോധിക്കുന്നു. വേഗം.
4. സമന്വയ പരിശോധനകൾ: ഒരു ടെസ്റ്റ് അക്കൌണ്ടിൽ യഥാർത്ഥ വിഭവങ്ങൾ സൃഷ്ടിക്കുക, അവ പരിശോധിക്കുക, നശിപ്പിക്കുക. മിനിറ്റ്, പണം ചിലവാകും.

മൂല്യം കൂടുതലും ആദ്യത്തെ രണ്ട് പാളികളിൽ നിന്നാണ്. അവസാനത്തെ കാര്യം പ്രധാനപ്പെട്ട പങ്കിട്ട മൊഡ്യൂളുകൾക്ക് വിലപ്പെട്ടതാണ്.

ആദ്യം വിലകുറഞ്ഞ ചെക്കുകൾ

ഈ പരിശോധനകൾ ഓരോ കമ്മിറ്റിലും നടത്തണം, മുൻകൂട്ടി കമ്മിറ്റ് ഹുക്കുകളായി, CI ൽഃ

terraform fmt -check -recursive
terraform validate
tflint --recursive
checkov -d .          # or: trivy config .

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

അവ വേഗതയുള്ളതും സൌജന്യവുമാണ്. അതിശയകരമായ ഒരു എണ്ണം യഥാർത്ഥ പ്രശ്നങ്ങൾ പിടിച്ചെടുക്കുന്നു.

ഏറ്റവും നല്ല ഇൻഫ്രാസ്ട്രക്ചർ ബഗ് ആദ്യം പിടിച്ചതാണ്. terraform plan നിന്റെ മേഘത്തോട് സംസാരിക്കാന് .

ടെറാഫോം പരിശോധന

പതിപ്പ് 1.6 മുതൽ, ടെറാഫോർമിന് ഒരു ബിൽറ്റ്-ഇൻ ടെസ്റ്റിംഗ് ഫ്രെയിംവർക്ക് ഉണ്ട് (ഓപ്പൺ ടോഫുവിന് തുല്യമായ ഒരു tofu test) പരിശോധനകൾ HCL ൽ എഴുതുന്നു, .tftest.hcl ഫയലുകൾ:

# tests/bucket.tftest.hcl
variables {
  name        = "acme-test-logs"
  environment = "staging"
}

run "bucket_is_private_and_encrypted" {
  command = plan

  assert {
    condition     = aws_s3_bucket_public_access_block.this.block_public_acls == true
    error_message = "Bucket must block public ACLs."
  }

  assert {
    condition     = aws_s3_bucket.this.tags["environment"] == "staging"
    error_message = "Bucket must be tagged with its environment."
  }
}

കൂടെ command = plan, പരീക്ഷണങ്ങൾ പ്ലാനിന് വിരുദ്ധമായി നടക്കുന്നു, ഒന്നും സൃഷ്ടിക്കാതെ. കൂടെ command = apply, അവ യഥാര് ത്ഥ വിഭവങ്ങള് സൃഷ്ടിക്കുകയും പിന്നീട് അവയെ നശിപ്പിക്കുകയും ചെയ്യുന്നു. നിങ്ങള് ക്കും കഴിയും വ്യാജ സേവനദാതാക്കൾ, ഇത് യൂണിറ്റ് രീതിയിലുള്ള പരിശോധനകളെ വേഗത്തിലും സൌജന്യമായും ചെയ്യുന്നു.

മോഡ്യൂളുകളുടെ രചയിതാക്കൾക്ക്, ഇത് പരീക്ഷണം ആരംഭിക്കുന്നതിനുള്ള ഏറ്റവും എളുപ്പവഴിയാണ്. പുതിയ ഭാഷയും അധിക ഉപകരണങ്ങളും ഇല്ല.

ടെറാടെസ്റ്റ്

ടെറാടെസ്റ്റ്, ഗ്രന്ത് വർക്ക്, ഇന്റഗ്രേഷൻ ടെസ്റ്റിംഗിനുള്ള ഒരു ഗോ ലൈബ്രറിയാണ്. ഇത് യഥാർത്ഥ ഇൻഫ്രാസ്ട്രക്ചർ വിന്യസിക്കുന്നു, അതിനെതിരെ പരിശോധനകൾ നടത്തുന്നു (HTTP അഭ്യർത്ഥനകൾ, SSH കമാൻഡുകൾ, API കോളുകൾ), അത് തകർക്കുന്നു.

func TestWebModule(t *testing.T) {
    opts := &terraform.Options{TerraformDir: "../examples/web"}
    defer terraform.Destroy(t, opts)
    terraform.InitAndApply(t, opts)

    url := terraform.Output(t, opts, "url")
    http_helper.HttpGetWithRetry(t, url, nil, 200, "OK", 30, 10*time.Second)
}

ഇത് വളരെ ശക്തമാണ് കാരണം ഇത് അടിസ്ഥാന സൌകര്യം ശരിയായി ക്രമീകരിച്ചിട്ടുണ്ടോ എന്ന് മാത്രമല്ല, അത് ശരിക്കും പ്രവർത്തിക്കുന്നുണ്ടോ എന്ന് പരിശോധിക്കുന്നു. അത് വേഗത കുറഞ്ഞതും ഗോ അറിവ് ആവശ്യമുള്ളതും ഓരോ റണ്ണിനും യഥാർഥ പണം ചിലവാകുന്നതുമാണ്.

നയ പരിശോധനകൾ

ഓരോ മാറ്റത്തിനും, അത് എഴുതിയത് ആരായാലും, "ഇത് അനുവദനീയമാണോ" എന്ന് നയങ്ങൾ മറുപടി നൽകുന്നു.

• ഒ. പി. എ / കോന്ഫെസ്റ്റ റെഗോയിൽ എഴുതിയ നയങ്ങളുമായി, JSON ഫോർമാറ്റിൽ പ്ലാനിനെതിരെ പ്രവർത്തിപ്പിക്കുക.
• ചെക്കോവ് കസ്റ്റംസ് നയങ്ങൾ പൈത്തൺ അല്ലെങ്കിൽ യാംഎംഎല്ലില് .
• സെൻറീനൽ ഹെച്പി ടെറാഫോർമിലെ, അല്ലെങ്കിൽ ഒപിഎ മറ്റ് പ്ലാറ്റ്ഫോമുകളില് സംയോജിപ്പിക്കുക.

ഉദാഹരണ നിയമങ്ങൾ: പൊതുവായ S3 ബക്കറ്റുകൾ ഇല്ല, എല്ലാ വിഭവങ്ങൾക്കും ഉടമസ്ഥന്റെ ടാഗ് ഉണ്ടായിരിക്കണം, അംഗീകൃത ഇൻസ്റ്റൻസിംഗ് തരങ്ങൾ മാത്രം, ഉത്പാദന ഡാറ്റാബേസുകൾ ഇല്ലാതാക്കൽ പരിരക്ഷ ഉണ്ടായിരിക്കണം.

terraform plan -out=plan.out
terraform show -json plan.out > plan.json
conftest test plan.json --policy policies/

പരീക്ഷണ പരിതസ്ഥിതികൾക്ക് പണം നല്കുക

ഇന്റഗ്രേഷന് ടെസ്റ്റുകള് ക്ക് ചിലവ് വരും. നിയന്ത്രണം നിലനിർത്താനുള്ള വഴികൾ:

• ഒരു പ്രത്യേക ടെസ്റ്റ് അക്കൌണ്ട് ബജറ്റുകളും അലേർട്ടുകളും.
• എപ്പോഴും നശിപ്പിക്കുക പരീക്ഷണത്തിനു ശേഷം, രാത്രിയിൽ വൃത്തിയാക്കൽ ജോലി നടത്തുക (ക്ലൌഡ്-ന്യൂക്ക് അല്ലെങ്കിൽ ആസ്-ന്യൂക്ക് പോലുള്ള ഉപകരണങ്ങൾ) അവശേഷിക്കുന്ന എന്തിനും വേണ്ടി.
• ചെറിയ വിലകുറഞ്ഞ വിഭവങ്ങളുടെ അളവ് പരീക്ഷണ ഉദാഹരണങ്ങളിൽ.
• സംയോജന പരിശോധനകൾ സംയോജിപ്പിക്കുക അല്ലെങ്കിൽ രാത്രിയിൽ നടത്തുകഎല്ലാ കംപൈറ്റിലും അല്ല.
• ടെസ്റ്റ് മൊഡ്യൂളുകൾ, മുഴുവൻ പരിതസ്ഥിതികളല്ല.

എവിടെ നിന്നാണ് ഞാൻ തുടങ്ങേണ്ടത്?

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

എന്റെ അഭിപ്രായം: ചെലവേറിയ രീതിയിലുള്ള അടിസ്ഥാന സൌകര്യങ്ങളുടെ പരാജയം. ചില വിലകുറഞ്ഞ പരിശോധനകൾ പിന്നീട് വിലയേറിയ ഒരു പാഠം രക്ഷിക്കും.

ഡെസ്ലി