ساخت پایپ‌لاین‌های CI/CD خودترمیم‌شونده با GitHub Actions و ArgoCD برای کوبرنیتس

در عصر مدرن توسعه بومی ابری، سرعت تحویل اغلب نه تنها با سرعتی که می‌توانید کد را استقرار دهید، بلکه با سرعتی که می‌توانید از یک شکست بهبود یابید، سنجیده می‌شود. پایپ‌لاین‌های سنتی CI/CD اغلب به محض شکست استقرار، متوقف می‌شوند و نیازمند مداخله دستی توسعه‌دهنده برای عیب‌یابی و استقرار مجدد هستند. اگرچه این رویکرد برای تیم‌های کوچک موثر است، اما به خوبی مقیاس‌پذیر نیست. در اینجا مفهوم پایپ‌لاین خودترمیم‌شونده وارد می‌شود: سیستمی که نه تنها انحراف استقرار یا شکست‌های چک سلامت را تشخیص می‌دهد، بلکه به طور خودکار مراحل اصلاح را برای بازگرداندن خوشه به وضعیت مطلوب، فعال می‌کند.

با ترکیب قدرت ارکستراسیون GitHub Actions با قابلیت‌های همگام‌سازی اعلانی ArgoCD، می‌توانیم زیرساختی قوی و خودکار بسازیم که اطمینان حاصل کند خوشه‌های کوبرنیتس شما با حداقل مداخله انسانی سالم باقی می‌مانند. این پست به بررسی معماری و پیاده‌سازی چنین سیستمی می‌پردازد.

درک معماری

معماری پیشنهادی از نقاط قوت هر دو ابزار بهره می‌برد. GitHub Actions به عنوان موتور برای فازهای «ساخت» و «آزمون» عمل می‌کند که کارهای پیچیده را اجرا کرده، تست‌های واحد را اجرا می‌کند و تصاویر کانتینری را می‌سازد. به محض اینکه تصویر به یک مخزن (Registry) ارسال شود، به عنوان «آماده انتشار» علامت‌گذاری می‌شود.

ArgoCD، از سوی دیگر، به عنوان لایه تحویل مداوم عمل می‌کند. آن به طور مداوم مخزن Git را برای تغییرات پیکربندی پایش کرده و وضعیت زنده خوشه کوبرنیتس را با وضعیت مطلوب اعلام شده مقایسه می‌کند. هنگامی که یک ناهمخوانی یافت می‌شود—مانند شکست در چرخه انتشار (roll-failing) یا ورود یک پاد به وضعیت CrashLoopBackOff—ArgoCD می‌تواند به گونه‌ای پیکربندی شود که به طور خودکار وضعیت را همگام‌سازی کند. برای دستیابی به خودترمیم‌شوندگی واقعی، ما چک‌های سلامت را ادغام می‌کنیم که یک بازگشت به عقب (rollback) یا استقرار مجدد را از طریق GitHub Actions فعال می‌کنند و یک حلقه بازخورد بسته ایجاد می‌کنند.

پیکربندی GitHub Actions برای ساخت و استقرار خودکار

گام اول ایجاد یک پایپ‌لاین است که قوی و خودکار باشد. ما به یک گردش کار (Workflow) نیاز داریم که تصویر کانتینری شما را بسازد، آن را به یک مخزن ارسال کند و مخزن Git را با برچسب‌های مانیفست جدید به‌روزرسانی کند. این اطمینان را ایجاد می‌کند که ArgoCD همیشه آخرین وضعیت را برای همگام‌سازی در اختیار دارد.

name: CI/CD Self-Healing Pipeline

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      
      - name: Build Docker Image
        run: docker build -t my-registry/my-app:${{ github.sha }} .
        
      - name: Push Image
        run: docker push my-registry/my-app:${{ github.sha }}
        
      - name: Update Manifest and Commit
        run: |
          kubectl set image deployment/my-app my-app=my-registry/my-app:${{ github.sha }}
          git config user.email "actions@github.com"
          git config user.name "GitHub Actions"
          git add k8s/deployment.yaml
          git commit -m "chore: update image to ${{ github.sha }}"
          git push

در این مثال، گردش کار به طور خودکار مانیفست کوبرنیتس را با برچسب تصویر جدید پس از یک ساخت موفق به‌روزرسانی می‌کند. این کامیت یک وب‌هوک را به ArgoCD فعال کرده و فرآیند همگام‌سازی را آغاز می‌کند.

پیاده‌سازی خودترمیم‌شوندگی با ArgoCD

اگرچه ArgoCD قدرتمند است، اما عمدتاً یک ابزار همگام‌سازی است. برای اینکه آن را «خودترمیم‌شونده» کنیم، باید آن را طوری پیکربندی کنیم که به وضعیت‌های سلامت خاصی واکنش نشان دهد. ArgoCD به شما اجازه می‌دهد توابع چک سلامت سفارشی و گزینه‌های همگام‌سازی را تعریف کنید. برای یک پایپ‌لاین خودترمیم‌شونده، ما معمولاً به گزینه‌های «Prune» (حذف) و «Self-Heal» (خودترمیم‌شوندگی) تکیه می‌کنیم، اما برای بازیابی پویا، اغلب از توانایی ArgoCD در فعال کردن وب‌هوک‌ها یا ادغام آن با چک‌کننده‌های سلامت خارجی استفاده می‌کنیم.

سناریویی را در نظر بگیرید که در آن یک استقرار در وضعیت Synced (همگام‌شده) است اما سلامت برنامه False (نادرست) است. یک استراتژی خودترمیم‌شونده ممکن است شامل یک وب‌هوک باشد که یک سیستم پایش را مطلع می‌کند، که سپس یک GitHub Action را برای بازگرداندن آخرین کامیت موفق به Git فعال می‌کند.

شما می‌توانید برنامه (Application) را در مخزن GitOps خود به شرح زیر پیکربندی کنید تا خودترمیم‌شوندگی تهاجمی را فعال کند:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-app
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/my-org/my-repo.git
    targetRevision: HEAD
    path: k8s
  destination:
    server: https://kubernetes.default.svc
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
      allowEmpty: false
    syncOptions:
      - PruneLast=true
      - CreateNamespace=true

با selfHeal: true، ArgoCD به طور خودکار هرگونه انحرافی را اصلاح می‌کند. با این حال، برای شکست‌های سطح برنامه (مانند یک پیکربندی نادرست که باعث کرش می‌شود)، ما اغلب این را با یک GitHub Action جفت می‌کنیم که برای وب‌هوک‌های رویداد ArgoCD گوش می‌دهد. هنگامی که ArgoCD شکستی را تشخیص می‌دهد که همگام‌سازی نمی‌تواند آن را حل کند، یک رویداد را شلیک می‌کند. یک گردش کار GitHub Action اختصاصی می‌تواند سپس لاگ‌ها را تحلیل کرده و در صورت لزوم، کامیت Git که باعث مشکل شده است را بازگرداند.

پیاده‌سازی عملی: حلقه بازخورد

ایجاد این حلقه نیازمند یک گردش کار خاص است که برای رویداد وب‌هوک application/sync.failed از ArgoCD گوش می‌دهد. این گردش کار می‌تواند سپس یک revert (بازگردانی) در Git انجام دهد.

name: Auto-Rollback on Failure
on:
  webhook:
    types: [application_sync_failed]

jobs:
  rollback:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Identify Bad Commit
        run: |
          # Logic to identify the commit causing the failure
          git revert HEAD
      - name: Push Rollback
        run: |
          git config user.email "bot@argocd.io"
          git config user.name "ArgoCD Bot"
          git push

نتیجه‌گیری

ساخت پایپ‌لاین‌های CI/CD خودترمیم‌شونده، اوج یک فرهنگ DevOps بالغ است. با بهره‌گیری از GitHub Actions برای کارهای سنگین ساخت و آزمون، و ArgoCD برای همگام‌سازی مداوم و مدیریت وضعیت، شما سیستمی را ایجاد می‌کنید که ذاتاً مقاوم است. این رویکرد زمان متوسط بازیابی (MTTR) را به طور قابل توجهی کاهش می‌دهد و به تیم شما اجازه می‌دهد بر نوآوری به جای آتش‌نشانی مسائل استقرار تمرکز کند. اگرچه خودکارسازی کامل نیازمند تنظیمات دقیق برای جلوگیری از حلقه‌های بی‌نهایت است، اما تعادل بین همگام‌سازی خودکار و استراتژی‌های بازگشت هوشمندانه، پایه‌ای قدرتمند برای قابلیت اطمینان بومی ابری فراهم می‌کند.