راه‌اندازی ArgoCD برای GitOps در کلاستر Kubernetes خودمیزبان روی سرور اختصاصی و VPS

وقتی یک کلاستر Kubernetes را خودتان روی سرور اختصاصی یا VPS بالا می‌آورید، دیر یا زود به این مشکل می‌خورید: استقرار اپلیکیشن‌ها با kubectl apply دستی، غیرقابل ردیابی و مستعد خطا می‌شود. هیچ لاگی از اینکه چه کسی چه زمانی چه چیزی را تغییر داده وجود ندارد، و بازگشت به نسخه قبل یعنی حدس زدن. راه‌اندازی ArgoCD دقیقاً همین مشکل را حل می‌کند: به جای دستور دادن مستقیم به کلاستر، وضعیت مطلوب را در یک Git repository تعریف می‌کنید و ArgoCD پیوسته کلاستر را با آن هماهنگ نگه می‌دارد.

GitOps چیست و ArgoCD چه نقشی دارد؟

GitOps یعنی Git به عنوان منبع واحد حقیقت (single source of truth) برای وضعیت زیرساخت و اپلیکیشن‌ها عمل کند. هر تغییری، از تعداد replica ها تا نسخه image، اول در یک commit ثبت می‌شود، بعد یک کنترلر داخل کلاستر آن تغییر را اعمال می‌کند.

ArgoCD این کنترلر است. یک Application تعریف می‌کنید که به یک مسیر در یک repository اشاره دارد؛ ArgoCD آن مسیر را می‌خواند، manifest ها را رندر می‌کند (Helm، Kustomize یا YAML خام) و وضعیت واقعی کلاستر را با آن مقایسه می‌کند. اگر تفاوتی باشد، یا خودکار sync می‌کند یا به شما اطلاع می‌دهد.

روی کلاستر خودمیزبان این مزیت دوچندان است، چون کنترل پلین را خودتان مدیریت می‌کنید و هیچ لایه مدیریت‌شده‌ای مثل سرویس‌های ابری بزرگ پشت سرتان نیست که خطاهای دستی را بپوشاند.

پیش‌نیازها

قبل از شروع راه‌اندازی ArgoCD این موارد باید آماده باشد:

• یک کلاستر Kubernetes در حال اجرا (kubeadm، k3s یا RKE2 روی سرور اختصاصی یا VPS، فرقی نمی‌کند)
• دسترسی kubectl با یک context معتبر به کلاستر
• حداقل ۲ vCPU و ۲ گیگابایت RAM آزاد روی نود کنترل پلین یا نودی که ArgoCD را میزبانی می‌کند
• یک Git repository (GitHub، GitLab یا هر سرور Git self-hosted) برای نگه‌داری manifest ها

برای کلاسترهای تولیدی، منابع کافی روی نود اهمیت دارد؛ ArgoCD چند کامپوننت (API server، repo-server، application-controller، redis) را هم‌زمان اجرا می‌کند و روی VPS با منابع محدود ممکن است با سایر Pod ها رقابت کند.

نصب ArgoCD روی کلاستر

ساده‌ترین روش، نصب مستقیم با manifest رسمی پروژه است:

kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

برای مدیریت نسخه و پیکربندی پایدارتر، نصب با Helm chart رسمی گزینه بهتری برای محیط‌های خودمیزبان است:

helm repo add argo https://argoproj.github.io/argo-helm
helm repo update
helm install argocd argo/argo-cd -n argocd --create-namespace

بعد از نصب، وضعیت Pod ها را بررسی کنید:

kubectl get pods -n argocd

وقتی همه Pod ها در حالت Running هستند، نصب کامل شده است.

دسترسی به ArgoCD UI و CLI

روی سرور اختصاصی یا VPS معمولاً Ingress controller یا LoadBalancer ابری در دسترس ندارید، پس ساده‌ترین راه برای تست اولیه port-forward است:

kubectl port-forward svc/argocd-server -n argocd 8080:443

رمز ادمین پیش‌فرض در یک Secret ذخیره شده:

kubectl -n argocd get secret argocd-initial-admin-secret \
  -o jsonpath="{.data.password}" | base64 -d

بعد از اولین ورود، همان ابتدا رمز را تغییر دهید. برای دسترسی دائمی، یک Ingress با TLS واقعی (مثلاً از طریق cert-manager) بهتر از port-forward موقتی است، چون تیم شما نیاز به دسترسی مداوم به داشبورد خواهد داشت.

تعریف Application در ArgoCD

هسته راه‌اندازی ArgoCD همین‌جاست: یک منبع Application که به Git repository و مسیر مشخصی اشاره می‌کند.

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-app
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/your-org/your-repo.git
    targetRevision: main
    path: k8s/overlays/production
  destination:
    server: https://kubernetes.default.svc
    namespace: production
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

این فایل را با kubectl apply -f application.yaml ثبت کنید. از این لحظه، ArgoCD دائماً namespace production را با آنچه در مسیر k8s/overlays/production از شاخه main تعریف شده مقایسه می‌کند.

فعال‌سازی Auto-Sync و Self-Healing

بخش syncPolicy.automated در نمونه بالا دو رفتار مهم را فعال می‌کند:

• prune: هر منبعی که از Git حذف شده، از کلاستر هم حذف می‌شود.
• selfHeal: اگر کسی مستقیماً با kubectl edit چیزی را در کلاستر تغییر دهد، ArgoCD آن را به حالت تعریف‌شده در Git برمی‌گرداند.

بدون این دو گزینه، ArgoCD فقط تفاوت را نشان می‌دهد و منتظر تأیید دستی برای sync می‌ماند؛ این حالت برای محیط‌های حساس (مثل production مالی) هم گزینه معتبری است، چون یک لایه تأیید انسانی قبل از هر تغییر اضافه می‌کند.

مقایسه: استقرار دستی در برابر GitOps با ArgoCD

معیار	استقرار دستی با kubectl	GitOps با ArgoCD
ردیابی تغییرات	وابسته به حافظه و لاگ ترمینال	تاریخچه کامل در Git history
بازگشت به نسخه قبل	دستی و پرخطا	git revert و sync خودکار
تشخیص drift	نیازمند بررسی دستی	تشخیص و اصلاح خودکار با selfHeal
دسترسی مستقیم به کلاستر	معمولاً برای همه اعضای تیم	محدود به مرحله review در Git
مناسب چند کلاستر	نیازمند اسکریپت جداگانه	یک Application برای هر مقصد

نکات امنیتی و بهترین شیوه‌ها

• RBAC داخل ArgoCD: نقش‌های پیش‌فرض را نگه ندارید؛ برای هر تیم یک AppProject با دسترسی محدود به namespace و repository مشخص تعریف کنید.
• مدیریت Secret: manifest های خام Secret را در Git commit نکنید. از Sealed Secrets یا SOPS برای رمزنگاری قبل از قرار گرفتن در repository استفاده کنید.
• محدود کردن دسترسی به repo-server: روی سرور اختصاصی خودمیزبان، کنترل دسترسی شبکه به namespace argocd را با NetworkPolicy مشخص کنید، چون هیچ لایه امنیتی ابری پیش‌فرضی پشت آن نیست.
• به‌روزرسانی منظم: نسخه‌های ArgoCD را با فاصله زمانی منطقی به‌روز نگه دارید؛ نسخه‌های قدیمی‌تر می‌توانند آسیب‌پذیری‌های امنیتی داشته باشند که در نسخه‌های جدیدتر رفع شده‌اند.

تفاوت اجرا روی سرور اختصاصی و VPS

روی VPS با منابع محدود، بهتر است ArgoCD را روی یک namespace جدا با محدودیت resource request/limit اجرا کنید تا با اپلیکیشن‌های دیگر روی رقابت منابع نیفتد. روی سرور اختصاصی با منابع بیشتر، می‌توانید replica تعداد بالاتری برای application-controller و repo-server تعریف کنید تا در کلاسترهای با تعداد Application زیاد، صف sync طولانی نشود.

برای تیم‌هایی که چند محیط (staging، production) را روی ماشین‌های مجزا نگه می‌دارند، یک نصب ArgoCD مرکزی روی سرور اختصاصی و اتصال آن به چند کلاستر remote (با argocd cluster add) معمولاً ساده‌تر از نصب جدا روی هر VPS است.

جمع‌بندی

راه‌اندازی ArgoCD روی یک کلاستر Kubernetes خودمیزبان، فاصله بین «تغییر در کد» و «تغییر در production» را به یک مرحله ساده تبدیل می‌کند: commit کردن در Git. با فعال‌سازی Auto-Sync و Self-Healing، کلاستر همیشه با وضعیتی که در repository تعریف شده هم‌راستا می‌ماند، حتی اگر کسی به اشتباه چیزی را دستی تغییر دهد.

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

سرور اختصاصی مناسب برای کلاستر Kubernetes خودتان را از آریاسرویس انتخاب کنید