എന്റെ സിഐ/സിഡി പൈപ്പ്ലൈൻ, നിർമ്മാണത്തിലേക്ക്

പത്ത് ഡി.വി.ഒ. എഞ്ചിനീയർമാരോട് ഒരു ഐ.സി. /സിഡി പൈപ്പ്ലൈൻ വരയ്ക്കാൻ ആവശ്യപ്പെടുക, നിങ്ങൾക്ക് പത്ത് വ്യത്യസ്ത ഡ്രോയിംഗുകൾ ലഭിക്കും. പക്ഷേ, നല്ല പൈപ്പ്ലൈനിന് റെ അടിഭാഗം ഒരേ രൂപമാണ്. അവ വേഗത്തിൽ ഫീഡ്ബാക്ക് നൽകുന്നു, പ്രശ്നങ്ങൾ നേരത്തേ കണ്ടെത്തുന്നു, വിന്യസനം മടുപ്പിക്കുന്നു.

ഇതാ ഒരു സാധാരണ കണ്ടെയ്നറൈസ്ഡ് വെബ് സർവീസ് ഉപയോഗിക്കുന്ന പൈപ്പ്ലൈൻ, ഗിറ്റ്ഹബ് ആക്ഷനുകളിലെ ഒരു പ്രവർത്തന ഉദാഹരണത്തിലൂടെ പടിപടിയായി.

ഘട്ടങ്ങളും കാരണങ്ങളും

1. ലിന്റ്, യൂണിറ്റ് പരിശോധനകൾ. ആദ്യം പെട്ടെന്നുള്ള പരിശോധന. ഇവ പരാജയപ്പെട്ടാൽ, വേറെ ഒന്നും ചെയ്യാനില്ല.
2. പണിതു. ഒരു തവണ കണ്ടെയ്നർ ഇമേജ് സൃഷ്ടിക്കുക, അത് commit SHA ഉപയോഗിച്ച് ടാഗ് ചെയ്യുക.
3. സ്കാൻ ചെയ്യുക. അറിയപ്പെടുന്ന പ്രശ്നങ്ങള് ക്ക് ആശ്രിതത്വങ്ങളും, ചിത്രവും, ഇൻഫ്രാസ്ട്രക്ചർ കോഡും പരിശോധിക്കുക.
4. ഇന്റഗ്രേഷന് ടെസ്റ്റുകൾ. അതിന്റെ യഥാർത്ഥ ആശ്രിതത്വങ്ങളുമായി നിർമ്മിച്ച ചിത്രം പരിശോധിക്കുക.
5. പ്രസിദ്ധീകരിക്കുക. ചിത്രം റെജിസ്ട്രിയിലേക്ക് അയച്ചു കൊടുക്കുക, ഒപ്പിട്ടു.
6. സജ്ജീകരണത്തിലേക്ക് വിന്യസിക്കുക. ഓട്ടോമാറ്റിക്കായി, ഓരോ മെയിൻ ലയനത്തിലും.
7. പരിശോധിക്കുക. സ്റ്റെജിംഗിനെതിരായ പുക പരിശോധനകൾ.
8. ഉല്പാദനത്തിലേക്ക് വിന്യസിക്കുക. അതേ കൃത്രിമ വസ്തു, അംഗീകാരത്തിനു ശേഷം അല്ലെങ്കിൽ ഓട്ടോമാറ്റിക്കായി, ക്രമേണ വിന്യസിച്ചുകൊണ്ട്.
9. വീണ്ടും പരിശോധിക്കുക. അളവുകള് നോക്കൂ, മോശമായാല് തിരികെ പോകൂ.

രണ്ടാമത്തെ ഘട്ടത്തില് ഏറ്റവും പ്രധാനപ്പെട്ട തത്ത്വം ഒളിഞ്ഞിരിക്കുന്നു: ഒരിക്കൽ നിർമ്മിച്ചാലും, എല്ലായിടത്തും ഒരേ കൃത്രിമ വസ്തു വിന്യസിക്കും. ഒരിക്കലും ഉല്പാദനത്തിനായി പുനർനിര് മിക്കുകയില്ല. നിങ്ങള് പരീക്ഷിച്ചതൊക്കെ നിങ്ങള് കയറ്റി അയയ്ക്കുന്നതാകും.

നല്ല പൈപ്പ്ലൈനില് ശരിയായ കാര്യം ഓട്ടോമാറ്റിക് ആക്കുകയും അപകടകരമായ കാര്യം ദൃശ്യമാക്കുകയും ചെയ്യും.

പൂർണ്ണമായ ഉദാഹരണം

ഗിറ്റ്ഹബ് ആക്ഷനുകളിൽ ഇത് എങ്ങനെയായിരിക്കും കാണപ്പെടുന്നത് എന്നതിന്റെ ഒരു ചുരുക്കിയ പതിപ്പ്:

name: ci-cd

on:
  pull_request:
  push:
    branches: [main]

permissions:
  contents: read

env:
  IMAGE: ghcr.io/my-org/shop-api

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@<sha> # v4
      - uses: actions/setup-go@<sha> # v5
        with:
          go-version-file: go.mod
          cache: true
      - run: go vet ./...
      - run: go test ./... -race -coverprofile=coverage.out

  build:
    needs: test
    runs-on: ubuntu-latest
    permissions:
      contents: read
      packages: write
      id-token: write          # for keyless signing
    outputs:
      digest: ${{ steps.push.outputs.digest }}
    steps:
      - uses: actions/checkout@<sha> # v4
      - uses: docker/setup-buildx-action@<sha> # v3
      - uses: docker/login-action@<sha> # v3
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}
      - id: push
        uses: docker/build-push-action@<sha> # v6
        with:
          push: ${{ github.event_name == 'push' }}
          tags: ${{ env.IMAGE }}:${{ github.sha }}
          cache-from: type=gha
          cache-to: type=gha,mode=max
      - name: Scan image
        uses: aquasecurity/trivy-action@<sha>
        with:
          image-ref: ${{ env.IMAGE }}:${{ github.sha }}
          severity: HIGH,CRITICAL
          ignore-unfixed: true
          exit-code: "1"

  deploy-staging:
    if: github.event_name == 'push'
    needs: build
    runs-on: ubuntu-latest
    environment: staging
    steps:
      - run: echo "Update the staging GitOps repo to ${{ github.sha }}"
      - run: ./scripts/smoke-test.sh https://staging.example.com

  deploy-production:
    needs: deploy-staging
    runs-on: ubuntu-latest
    environment: production      # requires approval in repo settings
    steps:
      - run: echo "Update the production GitOps repo to ${{ github.sha }}"

(പകരം <sha> ഗിറ്റ്ഹബ് പ്രവർത്തനങ്ങൾ പൂട്ടിയിടുന്നതിനെ കുറിച്ചുള്ള എന്റെ പോസ്റ്റിൽ വിവരിച്ചിരിക്കുന്നതുപോലെ, പിൻഡ് ചെയ്ത commit SHAs ഉപയോഗിച്ച്.

ശ്രദ്ധിക്കേണ്ട ചില വിശദാംശങ്ങള്:

• പരിസ്ഥിതി (staging, production) അംഗീകാരങ്ങൾ ആവശ്യപ്പെടുകയും അവരുടെ രഹസ്യങ്ങൾ സൂക്ഷിക്കുകയും ചെയ്യാം.
• വിന്യാസം ഒരു GitOps റിപ്പോ അപ്ഡേറ്റുചെയ്യുന്നു വിളിക്കുന്നതിനു പകരം kubectl നേരിട്ട് അര് ഗോ സിഡി അല്ലെങ്കിൽ ഫ്ലക്സ് മാറ്റം പ്രയോഗിക്കുന്നു, അത് ഐ. സി. യിൽ നിന്നും ക്രെഡൻഷ്യലുകളെ അകറ്റിനിർത്തുന്നു.
• അഭ്യർത്ഥനകൾ പിൻവലിക്കുക പരിശോധനകൾ നടത്തുക, ബിൽഡ് ചെയ്യുക പക്ഷെ തള്ളരുത്, വിന്യസിക്കരുത്.

വേഗത്തിലാക്കുന്നു

പതുക്കെയുണ്ടാകുന്ന പൈപ്പ്ലൈനുകൾ ഡെവലപ്പർമാരുടെ വിശ്വാസം നഷ്ടപ്പെടുത്തുന്നു. ചില ശീലങ്ങള് കാര്യങ്ങൾ വേഗത്തില് മുന്നോട്ട് കൊണ്ടുപോകുന്നു:

• ആദ്യം വേഗതയേറിയ പരിശോധന നടത്തുക. ഒപ്പം സമാന്തരമായി.
• കാഷെ ആശ്രിതത്വം ഡോക്കർ ലെയറുകളും (ഡോക്കർ ലേയറുകളും) cache-from / cache-to മുകളിലെ വരികൾ).
• മാറ്റം വന്നത് മാത്രം പ്രവർത്തിപ്പിക്കുക. മോണോറെപ്പോസ്, പാത്ത് ഫിൽട്ടറുകൾ ഉപയോഗിച്ച്.
• ഇന്റഗ്രേഷന് ടെസ്റ്റുകള് ശ്രദ്ധിക്കുക. പ്രധാനപ്പെട്ട പാതകളെ പരിശോധിക്കുക, എല്ലാം അല്ല.
• ലക്ഷ്യം പത്തു മിനിറ്റിനു താഴെ "മർജറിന് റെഡി" എന്നതിൽ നിന്നും "പുഷ്" എന്നതിലേക്ക്.

എങ്ങിനെ ഞാൻ തിരിച്ചു പോകുന്നു

ഒരു റോൾബാക്ക് ഒരു വിന്യാസം പോലെ എളുപ്പമായിരിക്കണം, അത് പരിശീലിക്കണം:

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

പിന്നെ, കുറഞ്ഞത് എത്രയാണ്?

നിങ്ങളുടെ പൈപ്പ്ലൈൻ മറ്റൊന്നും ചെയ്യുന്നില്ലെങ്കിൽ, ഇത് ചെയ്യുകഃ ഓരോ പിൻ അഭ്യർത്ഥനയിലും പരിശോധനകൾ നടത്തുക, ഓരോ കമ്മിറ്റിനും ഒരു ചിത്രം നിർമ്മിക്കുക, അത് സ്കാൻ ചെയ്യുക, കൃത്യമായ ചിത്രം യാന്ത്രികമായി സ്റ്റേജിംഗിലേക്ക് വിന്യസിക്കുക, അതേ ചിത്രം ഉൽപാദനത്തിലേക്ക് പ്രോത്സാഹിപ്പിക്കുക. മറ്റെല്ലാം മുകളിൽ മെച്ചപ്പെടുത്തലാണ്.

എന്റെ അഭിപ്രായം: ഒരിക്കൽ നിർമ്മിക്കുക, നേരത്തെ പരീക്ഷിക്കുക, എല്ലായിടത്തും ഒരേ കാര്യം വിന്യസിക്കുക, എപ്പോഴെങ്കിലും എങ്ങനെ തിരിച്ചു പോകണമെന്ന് അറിയുക.

ഡെസ്ലി