ഐ. സി. യിലെ ടെറാഫോർംഃ പിആർ സംബന്ധിച്ച പദ്ധതി, ലയനം സംബന്ധിച്ച് അപേക്ഷിക്കുക

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

പരിഹാരം ലളിതവും അറിയപ്പെടുന്നതുമായ ഒരു വർക്ക്ഫ്ലോ ആണ്: പിളര് ക്കുന്നതിനുള്ള അപേക്ഷയില് പ്ലാന്റ് ചെയ്യുക, ലയിപ്പിക്കാന് അപേക്ഷിക്കുക. ഞാനിങ്ങനെ തന്നെ സജ്ജമാക്കിയിട്ടുണ്ട്.

പ്രവര് ത്തന പ്രക്രിയ

1. ഒരു ഡെവലപ്പര് ഒരു ബ്രാഞ്ചില് ഇൻഫ്രാസ്ട്രക്ചര് കോഡ് മാറ്റുകയും ഒരു pull request തുറക്കുകയും ചെയ്യുന്നു.
2. ഐ. ഐ. ഓടുന്നു terraform plan ആ പ്ലാൻ പിൻവലിക്കൽ അഭ്യർത്ഥനയുടെ ഒരു അഭിപ്രായമായി പോസ്റ്റ് ചെയ്യുന്നു.
3. രണ്ടും കോഡായി പരിഗണിക്കപ്പെടുന്നു. ഒപ്പം ആ പ്ലാന് .
4. അംഗീകാരം ലഭിച്ച ശേഷം, പിൻവലിക്കൽ അഭ്യർത്ഥന ലയിപ്പിക്കുന്നു.
5. ഐ. ഐ. ഓടുന്നു terraform apply പ്ലാനുമായി, പ്രധാന ശാഖയിൽ നിന്ന്.

എല്ലാം പരിശോധിക്കുന്നു, എല്ലാം രേഖപ്പെടുത്തുന്നു, ആരും അവരുടെ ലാപ്ടോപ്പിലെ ഉല്പാദന ക്രെഡൻഷ്യലുകൾ ആവശ്യമില്ല, പ്രധാന ശാഖ എപ്പോഴും വിന്യസിച്ചിരിക്കുന്നതിനെ പ്രതിഫലിപ്പിക്കുന്നു.

ആ പ്ലാന് ആണ് യഥാര് ത്ഥ മാറ്റം. ആസൂത്രണം കോഡ് പോലെ തന്നെ ശ്രദ്ധാപൂർവ്വം പരിശോധിക്കുക.

ഓപ്ഷൻ 1: അറ്റ്ലാന്റിസ്

അറ്റ്ലാന്റിസ് ഈ വർക്ക്ഫ്ലോയ്ക്കായി നിർമ്മിച്ച ഒരു ഓപ്പൺ സോഴ്സ് സെർവറാണ്. ഇത് അഭ്യർത്ഥന സംഭവങ്ങൾ പിൻവലിക്കാൻ ശ്രദ്ധിക്കുന്നു, നിങ്ങൾ അഭിപ്രായങ്ങൾ ഉപയോഗിച്ച് അത് നിയന്ത്രിക്കുന്നുഃ

• ഒരു പിആർ തുറക്കുമ്പോള് അറ്റ്ലാന്റിസ് ഓട്ടോമാറ്റിക് ആയി ഓടിപ്പോകും. plan ഒപ്പം ഔട്ട്പുട്ടിനെ കുറിച്ചുള്ള അഭിപ്രായങ്ങളും.
• അഭിപ്രായങ്ങള് atlantis apply അത് പ്രയോഗിക്കുകയും, പിന്നെ ഫലത്തെക്കുറിച്ച് അഭിപ്രായമിടുകയും ചെയ്യുന്നു.
• ഇത് ബാധിത ഡയറക്ടറികളെ ലോക്ക് ചെയ്യുന്നു, അങ്ങനെ രണ്ട് PR- കൾക്ക് ഒരേ സമയം ഒരേ അവസ്ഥ മാറ്റാനാവില്ല.

അറ്റ്ലാന്റിസ് നിങ്ങളുടെ സ്വന്തം ഇൻഫ്രാസ്ട്രക്ചറിൽ പ്രവർത്തിക്കുന്നു (പലപ്പോഴും കുബർനെറ്റസിൽ), അതിനാൽ ക്രെഡൻഷ്യലുകൾ ഒരിക്കലും നിങ്ങളുടെ പരിസ്ഥിതിയെ വിട്ടുപോകുന്നില്ല. ലളിതവും യുദ്ധ പരീക്ഷണ വിധേയവും സൌജന്യവുമാണ്. നിങ്ങള് അത് ആതിഥേയത്വം വഹിക്കുകയും പരിപാലിക്കുകയും വേണം.

ഓപ്ഷൻ 2: ഗിറ്റ്ഹബ് പ്രവർത്തനങ്ങൾ (അല്ലെങ്കിൽ ഏതെങ്കിലും ഐസി)

നിങ്ങളുടെ സാധാരണ ഐ. സി. യിൽ ഒരേ വർക്ക്ഫ്ലോ ഉണ്ടാക്കാം. ലളിതമായ ഗിറ്റ്ഹബ് പ്രവർത്തനങ്ങൾ പതിപ്പ്ഃ

name: terraform

on:
  pull_request:
    paths: ["infrastructure/**"]
  push:
    branches: [main]
    paths: ["infrastructure/**"]

permissions:
  contents: read
  id-token: write
  pull-requests: write

jobs:
  terraform:
    runs-on: ubuntu-latest
    defaults:
      run:
        working-directory: infrastructure/live/production/network
    steps:
      - uses: actions/checkout@<sha> # v4
      - uses: hashicorp/setup-terraform@<sha> # v3
      - uses: aws-actions/configure-aws-credentials@<sha> # v4
        with:
          role-to-assume: arn:aws:iam::123456789012:role/terraform-${{ github.event_name == 'push' && 'apply' || 'plan' }}
          aws-region: eu-central-1
      - run: terraform init -input=false
      - run: terraform plan -input=false -out=tfplan
      - if: github.event_name == 'pull_request'
        run: terraform show -no-color tfplan > plan.txt
        # post plan.txt as a PR comment with your preferred action
      - if: github.event_name == 'push'
        run: terraform apply -input=false tfplan

ശ്രദ്ധിക്കേണ്ട കാര്യങ്ങൾ:

• രണ്ട് വ്യത്യസ്ത ഐ. എ. എം റോളുകൾ: ഒരു റോൾ പ്ലാനുകൾക്ക് വായിക്കാൻ മാത്രം pull അഭ്യർത്ഥനകൾ, ഒരു റോൾ മാത്രം എഴുതുക ആക്സസ് main. ഏത് ശാഖയ്ക്ക് ഏത് റോൾ ഏറ്റെടുക്കാമെന്ന് ട്രസ്റ്റ് നയം പരിമിതപ്പെടുത്തുന്നു.
• ഒഐഡിസി, ക്ലൌഡ് കീകൾ സൂക്ഷിച്ചിട്ടില്ല.
• ഗിറ്റ്ഹബ് പരിതസ്ഥിതികൾ ഉപയോഗിക്കുക ഉല്പാദനത്തിന് ആവശ്യമായ അവലോകകരുമായി ഒരു അധിക അംഗീകാര ഘട്ടം വേണമെങ്കിൽ ബാധകമാണ്.

ഒരു സൂക്ഷ്മത: പിൾ അഭ്യർത്ഥനയുടെ പ്ലാനും ലയനത്തിനു ശേഷമുള്ള ആപ്ലിക്കേഷനും തമ്മിൽ വ്യത്യാസമുണ്ടാകാം. ലയനം പുനഃപരിശോധിക്കുകയും ആ പദ്ധതി നടപ്പിലാക്കുകയും ചെയ്യുക എന്നതാണ് ഏറ്റവും സുരക്ഷിതമായ മാർഗം.

ഓപ്ഷൻ 3: ടാക്കോസ്

"TACOS" (Terraform ഓട്ടോമേഷൻ ആൻഡ് സഹകരണ സോഫ്റ്റ്വെയർ) ഇതിനായി നിർമ്മിച്ച പ്ലാറ്റ്ഫോമുകളുടെ വിളിപ്പേര് ആണ്: എച്ച് സി പി ടെറാഫോർം, ബഹിരാകാശ യാത്ര, പരിസ്ഥിതി, സ്കാൽ, ഹാർനെസ് ഐഎസിഎം മറ്റു ചിലതും. അവർ കൂട്ടിച്ചേര് ത്തു:

• ഓരോ പ്ലാനിലും കോഡായി നയം (ഒപിഎ അല്ലെങ്കിൽ സെന്റിനൽ).
• ഡ്രീഫ്റ്റ് കണ്ടെത്തലും ഷെഡ്യൂൾ ചെയ്ത റണ്ണുകളും.
• സ്റ്റാക്ക് ആശ്രിതത്വം, ചെലവ് കണക്കാക്കല്, അംഗീകാരങ്ങള് , ഓഡിറ്റ് ലോഗ്സ്.
• പല ടീമുകൾക്കും സ്വയം സേവനവും RBAC ഉം.

ഇവയ്ക്ക് ചിലവ് വരും, പക്ഷേ വലിയ സംഘടനകൾക്ക് അവയുടെ നിർമ്മാണവും പരിപാലനവും വളരെ ലാഭകരമാണ്.

അംഗീകാരം

അടിസ്ഥാന സൌകര്യ മാറ്റങ്ങള് ക്ക് ആര് അംഗീകാരം നല് കും? ചില പ്രായോഗിക നിയമങ്ങള്:

• കോഡ് ഉടമകൾ അങ്ങനെ ശരിയായ ടീം അവരുടെ ഭാഗത്തെ മാറ്റങ്ങൾ അവലോകനം ചെയ്യും.
• ആവശ്യമായ അവലോകനങ്ങൾ ശാഖ സംരക്ഷണത്തില് .
• ഉല്പാദനത്തിനുള്ള അധിക അംഗീകാരം ബാധകമാണ്, ഐ. സി. പരിതസ്ഥിതികളിലൂടെയോ പ്ലാറ്റ്ഫോമിലൂടെയോ.
• അവലോകകർക്ക് കാണാവുന്ന പദ്ധതികൾ, ഏറ്റവും നല്ലത് സംഗ്രഹിക്കാം: ചേർത്തതും മാറ്റിയതും നശിപ്പിച്ചതുമായ വിഭവങ്ങളുടെ എണ്ണം. ഉല്പാദനത്തിലെ ഒരു "നശിപ്പിക്കൽ" ശ്രദ്ധേയമായിരിക്കണം.

രഹസ്യങ്ങളും ഒഐഡിസി ആധികാരികതയും

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

എങ്ങിനെ തുടങ്ങും?

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

എന്റെ അഭിപ്രായം: അടിസ്ഥാന സൌകര്യ മാറ്റങ്ങൾ ആപ്ലിക്കേഷൻ കോഡിനോട് തുല്യമായ പൈപ്പ്ലൈൻ അച്ചടക്കം അർഹിക്കുന്നു. പ്ലാന് പുനരവലോകനം ചെയ്യുക, ലയിപ്പിക്കുക, റോബോട്ട് അപേക്ഷിക്കട്ടെ.

ഡെസ്ലി