استقرار روی Kubernetes با استفاده از Argo CD و GitOps

مقدمه

استفاده از Kubernetes برای استقرار اپلیکیشن شما می‌تواند مزایای زیرساختی قابل‌توجهی فراهم کند؛ مانند مقیاس‌دهی منعطف، مدیریت اجزای توزیع‌شده و کنترل نسخه‌های مختلف اپلیکیشن شما. با این حال، افزایش کنترل، همراه با افزایش پیچیدگی می‌آید. سیستم‌های یکپارچسازی و استقرار پیوسته (CI/CD) معمولاً در سطحی بالاتر از انتزاع کار می‌کنند تا کنترل نسخه، ثبت تغییرات (Change Logging) و قابلیت Rollback را فراهم کنند. یکی از رویکردهای محبوب برای این لایه انتزاع، GitOps نام دارد.

GitOps از Git به‌عنوان «منبع واحد حقیقت» (Single Source of Truth) برای فرایندهای CI/CD استفاده می‌کند؛ تغییرات کد را در یک مخزن واحد و مشترک برای هر پروژه یکپارچه کرده و از Pull Requestها برای مدیریت زیرساخت و استقرار استفاده می‌کند. این مفهوم در ابتدا در سال ۲۰۱۷ توسط Weaveworks پیشنهاد شد و از آن زمان توسط پروژه OpenGitOps زیر بنیاد Cloud Native Computing Foundation (CNCF) رسمی شده است.

چند ابزار وجود دارند که از Git به‌عنوان نقطه کانونی فرایندهای DevOps روی Kubernetes استفاده می‌کنند. در این آموزش، یاد می‌گیرید از Argo CD استفاده کنید؛ یک ابزار اعلانی (Declarative) تحویل پیوسته (Continuous Delivery). Argo CD ابزارهایی فراهم می‌کند که هر زمان تغییری در مخزن GitHub شما ایجاد شود، اپلیکیشن شما را به‌طور خودکار همگام‌سازی و مستقر می‌کند. با مدیریت استقرار و چرخه حیات یک اپلیکیشن، راه‌حل‌هایی برای کنترل نسخه، پیکربندی‌ها و تعاریف اپلیکیشن در محیط‌های Kubernetes فراهم می‌کند و داده‌های پیچیده را با یک رابط کاربری قابل‌فهم سازمان‌دهی می‌کند. این ابزار می‌تواند چندین نوع Manifest مربوط به Kubernetes را هندل کند؛ شامل Jsonnet، اپلیکیشن‌های Kustomize، Chartهای Helm و فایل‌های YAML/JSON و از اطلاع‌رسانی Webhook از GitHub، GitLab و Bitbucket پشتیبانی می‌کند.

در این مقاله، از Argo CD برای همگام‌سازی و استقرار یک اپلیکیشن از یک مخزن GitHub استفاده می‌کنید.

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

نکات کلیدی

• GitOps از Git به‌عنوان منبع واحد حقیقت برای هم کد اپلیکیشن و هم پیکربندی زیرساخت استفاده می‌کند و استقرارهای مبتنی بر Pull روی Kubernetes را ممکن می‌سازد.
• Argo CD یک ابزار تحویل پیوسته اعلانی و بومی GitOps است که داخل کلاستر شما اجرا شده و به‌طور پیوسته مخازن Git شما را برای تغییرات مانیتور می‌کند.
• Argo CD از Chartهای Helm، Kustomize، Jsonnet و Manifestهای YAML ساده پشتیبانی می‌کند؛ که به شما انعطاف می‌دهد اپلیکیشن‌هایتان را هرطور که می‌خواهید تعریف کنید.
• حلقه Reconciliation در Argo CD به‌طور خودکار انحراف (Drift) بین وضعیت موردنظر در Git و وضعیت زنده در کلاستر شما را تشخیص داده و سپس آن‌ها را همگام می‌کند.
• می‌توانید استقرارها را در چندین کلاستر Kubernetes از یک اینستنس واحد Argo CD مدیریت کنید.

اصول پایه GitOps

قبل از پرداختن به مراحل نصب، آشنایی با اصول پایه پشت GitOps که آن را برای استقرارهای Kubernetes مؤثر می‌کند، مفید است.

زیرساخت اعلانی. کل وضعیت موردنظر سیستم شما به‌صورت اعلانی توصیف می‌شود. به‌جای نوشتن اسکریپت‌هایی که می‌گویند «این کار را بکن، بعد آن کار را»، نتیجه نهایی را تعریف می‌کنید. Kubernetes از قبل از طریق Manifestهای YAML به این شکل کار می‌کند؛ که آن را به یک گزینه طبیعی برای GitOps تبدیل می‌کند.

Git به‌عنوان منبع واحد حقیقت. همه تغییرات وضعیت موردنظر به‌صورت کامیت در یک مخزن Git ذخیره می‌شوند. این یعنی هر تغییری نسخه‌بندی‌شده، قابل‌ممیزی و قابل‌بازگشت است. اگر مشکلی پیش بیاید، می‌توانید به یک کامیت قبلی Rollback کنید.

استقرار مبتنی بر Pull. خطوط لوله سنتی CI/CD تغییرات را به کلاستر شما Push می‌کنند. GitOps این مدل را وارونه می‌کند. یک Agent که داخل کلاستر شما اجرا می‌شود (مثل Argo CD)، تغییرات را از Git می‌کشد و اعمال می‌کند. این کار نیاز به اعطای دسترسی مستقیم سیستم‌های خارجی به کلاسترتان را کاهش می‌دهد.

Reconciliation پیوسته. Agent مربوط به GitOps به‌طور پیوسته وضعیت موردنظر در Git را با وضعیت واقعی در کلاستر مقایسه می‌کند. اگر کسی به‌صورت دستی یک منبع را در کلاستر تغییر دهد، Agent این انحراف را تشخیص داده و می‌تواند به‌طور خودکار آن را اصلاح کند. این همان چیزی است که Argo CD حلقه Reconciliation خود می‌نامد.

برای درک عمیق‌تر مفاهیم Kubernetes، به مقاله «مقدمه‌ای بر Kubernetes» مراجعه کنید.

GitOps در برابر CI/CD سنتی

اگر قبلاً از خطوط لوله سنتی CI/CD استفاده کرده‌اید، درک تفاوت GitOps می‌تواند به روشن‌شدن دلیل وجود ابزارهایی مانند Argo CD کمک کند.

ویژگی	CI/CD سنتی	GitOps با Argo CD
مدل استقرار	مبتنی بر Push	مبتنی بر Pull
منبع حقیقت	پیکربندی خط لوله CI	مخزن Git
تشخیص انحراف	دستی یا هیچ	حلقه Reconciliation خودکار
Rollback	اجرای مجدد خط لوله یا اسکریپت‌ها	Revert کردن کامیت Git
دسترسی به کلاستر	سیستم CI به اطلاعات احراز هویت نیاز دارد	Agent داخل کلاستر اجرا می‌شود
رد ممیزی	لاگ‌های خط لوله	تاریخچه کامیت‌های Git
پشتیبانی چندکلاستری	نیازمند اسکریپت‌نویسی سفارشی	داخلی (Built-in)

در یک گردش کار سنتی CI/CD، خط لوله Jenkins یا GitHub Actions یا مشابه آن، اپلیکیشن را Build کرده و سپس استقرار را با kubectl apply یا دستورات Helm به کلاستر شما Push می‌کند. این یعنی سیستم CI شما به دسترسی مستقیم به API کوبزنتیس نیاز دارد؛ که سطح امنیتی‌ای می‌سازد که باید مدیریتش کنید.

با GitOps، خط لوله CI ساخت و تست کد را هندل کرده و سپس پیکربندی جدید (مثل یک Tag ایمیج به‌روز شده) را به یک مخزن Git Push می‌کند. Argo CD که داخل کلاستر در حال اجراست، تغییر را تشخیص داده و وضعیت جدید را Pull می‌کند. کلاستر عملاً استقرارهای خودش را مدیریت می‌کند.

برای دید کلی مفاهیم و بهترین شیوه‌های CI/CD، مقاله «مقدمه‌ای بر بهترین شیوه‌های CI/CD» را ببینید.

پیش‌نیازها

برای دنبال کردن این آموزش به موارد زیر نیاز دارید:

• یک جفت کلید SSH روی ماشین محلی لینوکس/macOS/BSD خود. اگر قبلاً از کلیدهای SSH استفاده نکرده‌اید، می‌توانید راه‌اندازی آن‌ها را با دنبال‌کردن این توضیحِ «راه‌اندازی کلیدهای SSH روی ماشین محلی» یاد بگیرید. اگر از ویندوز استفاده می‌کنید، باید در محیط Windows Subsystem for Linux کار کنید.
• یک کلاستر Kubernetes موجود شامل حداقل یک نود Worker. ابزار kubectl باید در محیط کاری شما نصب و قادر به اتصال به کلاسترتان باشد. Kubernetes مدیریت‌شده پارمین کلود به‌صورت پیش‌فرض پیکربندی‌ای مانند این را در اختیارتان می‌گذارد. اگر از Kubernetes مدیریت‌شده پارمین کلود استفاده می‌کنید، باید راهنمای «اتصال به کلاستر» را مرور کنید. برای مقایسه رویکردهای مدیریت کلاستر، مقاله «Kubernetes مدیریت‌نشده در برابر مدیریت‌شده» را ببینید.
• آشنایی با مفاهیم Kubernetes. لطفاً برای جزئیات بیشتر به مقاله «مقدمه‌ای بر Kubernetes» مراجعه کنید.

مرحله ۱ — نصب Argo CD روی کلاستر شما

برای نصب Argo CD، ابتدا باید یک پیکربندی معتبر Kubernetes با kubectl راه‌اندازی کرده باشید که بتوانید از طریق آن نودهای Worker خود را بررسی کنید. می‌توانید این را با اجرای kubectl get nodes تست کنید:

kubectl get nodes

این دستور باید فهرستی از نودها با وضعیت Ready برگرداند:

خروجی:

NAME                   STATUS   ROLES    AGE   VERSION
pool-uqv8a47h0-ul5a7   Ready    <none>   22m   v1.21.5
pool-uqv8a47h0-ul5am   Ready    <none>   21m   v1.21.5
pool-uqv8a47h0-ul5aq   Ready    <none>   21m   v1.21.5

اگر kubectl مجموعه‌ای از نودها با وضعیت Ready برنگرداند، باید پیکربندی کلاستر و مستندات Kubernetes خود را مرور کنید.

سپس، Namespace با نام argocd را در کلاستر خود بسازید که Argo CD و سرویس‌های مرتبط با آن را در خود جای دهد:

kubectl create namespace argocd

بعد از آن، می‌توانید اسکریپت نصب Argo CD را که توسط نگهدارندگان پروژه فراهم شده اجرا کنید:

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

پس از تکمیل موفق نصب، می‌توانید با دستور watch وضعیت Podهای Kubernetes خود را بررسی کنید:

watch kubectl get pods -n argocd

به‌صورت پیش‌فرض، باید پنج Pod وجود داشته باشند که به‌عنوان بخشی از یک نصب استاندارد Argo CD در نهایت وضعیت Running بگیرند:

خروجی:

NAME                                  READY   STATUS    RESTARTS   AGE
argocd-application-controller-0       1/1     Running   0          2m28s
argocd-dex-server-66f865ffb4-chwwg    1/1     Running   0          2m30s
argocd-redis-5b6967fdfc-q4klp         1/1     Running   0          2m30s
argocd-repo-server-656c76778f-vsn7l   1/1     Running   0          2m29s
argocd-server-cd68f46f8-zg7hq         1/1     Running   0          2m28s

می‌توانید برای خروج از رابط watch، Ctrl+C را فشار دهید. اکنون Argo CD در کلاستر Kubernetes شما در حال اجراست! با این حال، به دلیل روشی که Kubernetes انتزاع‌هایی دور اینترفیس‌های شبکه شما می‌سازد، بدون فوروارد کردن پورت‌ها از داخل کلاستر، قادر به دسترسی مستقیم به آن نخواهید بود. نحوه انجام این کار را در مرحله بعد یاد می‌گیرید.

مرحله ۲ — فوروارد کردن پورت‌ها برای دسترسی به Argo CD

چون Kubernetes سرویس‌ها را روی آدرس‌های شبکه دلخواهی داخل کلاستر شما مستقر می‌کند، برای دسترسی به آن‌ها از ماشین محلی خود باید پورت‌های مربوطه را فوروارد کنید. Argo CD سرویسی با نام argocd-server روی پورت 443 به‌صورت داخلی راه‌اندازی می‌کند. چون پورت 443 پورت پیش‌فرض HTTPS است و ممکن است سرویس‌های HTTP/HTTPS دیگری در حال اجرا داشته باشید، روش معمول این است که آن را به پورت‌های دلخواه دیگری مثل 8080 فوروارد کنید؛ به این شکل:

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

فوروارد پورت، تا زمانی که فعال است، ترمینالی که در آن اجرا شده را مسدود می‌کند؛ پس احتمالاً می‌خواهید آن را در یک پنجره ترمینال جدید اجرا کنید while ادامه کار می‌دهید. می‌توانید وقتی می‌خواهید فوروارد پورت را متوقف کنید، برای خروج به‌نرمی از یک پروسه مسدودکننده مثل این، Ctrl+C را فشار دهید.

در این میان، باید بتوانید با مراجعه به localhost:8080 در یک مرورگر وب به Argo CD دسترسی پیدا کنید. با این حال، از شما رمز عبوری درخواست می‌شود که برای بازیابی آن، در مرحله بعد باید از خط فرمان استفاده کنید. احتمالاً باید یک هشدار امنیتی را رد کنید؛ چون Argo CD هنوز با یک گواهی SSL معتبر پیکربندی نشده است.

توجه: استفاده از گواهی‌های HTTPS مربوط به LetsEncrypt با Kubernetes، به بهترین شکل با استفاده از ابزارهای اضافی مانند Cert-Manager انجام می‌شود.

مرحله ۳ — کار با Argo CD از خط فرمان

برای مراحل بعدی، باید دستور argocd را به‌صورت محلی نصب داشته باشید تا بتوانید با اینستنس Argo CD خود تعامل کرده و تنظیماتش را تغییر دهید. مستندات رسمی Argo CD توصیه می‌کند آن را از طریق مدیر پکیج Homebrew نصب کنید. Homebrew برای مدیریت ابزارهای خط فرمان در macOS بسیار محبوب است و اخیراً به لینوکس هم منتقل شده تا نگهداری ابزارهایی مانند این را آسان‌تر کند.

اگر هنوز Homebrew نصب ندارید، می‌توانید آن را با یک دستور تک‌خطی دریافت و نصب کنید:

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

ممکن است در طول فرایند نصب از شما رمز عبور خواسته شود. پس از آن، باید دستور brew در ترمینال شما در دسترس باشد. می‌توانید از آن برای نصب Argo CD استفاده کنید:

brew install argocd

این در نهایت دستور argocd را فراهم می‌کند. قبل از استفاده از آن، باید دوباره از kubectl استفاده کنید تا رمز عبور admin را که هنگام نصب به‌طور خودکار تولید شده بازیابی کنید تا بتوانید با آن وارد شوید. یک مسیر به یک فایل JSON خاص را که با Secretهای Kubernetes ذخیره شده به آن پاس می‌دهید و مقدار مربوطه را استخراج می‌کنید:

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

خروجی:

fbP20pvw-o-D5uxH

سپس می‌توانید با بازگشت به localhost:8080 در یک مرورگر و ورود به‌عنوان کاربر admin با رمز عبور خودتان، وارد داشبورد Argo CD شوید:

[تصویر: وضعیت اپلیکیشن در Argo CD]

وقتی همه‌چیز کار می‌کند، می‌توانید با همان اطلاعات احراز هویت و با اجرای argocd login، از طریق خط فرمان وارد Argo CD شوید. این برای استقرار از خط فرمان در مراحل بعدی لازم خواهد بود:

argocd login localhost:8080

اینجا هم هشدار معادل گواهی را دوباره در خط فرمان دریافت می‌کنید و باید هنگام درخواست، برای ادامه y را وارد کنید. در صورت تمایل، می‌توانید سپس رمز عبور خود را با اجرای argocd account update-password به چیزی امن‌تر یا به‌یادماندنی‌تر تغییر دهید. پس از آن، یک پیکربندی کاملاً کارآمد Argo CD خواهید داشت. در مراحل پایانی این آموزش، یاد می‌گیرید که چطور از آن برای استقرار چند اپلیکیشن نمونه استفاده کنید.

مرحله ۴ — مدیریت چند کلاستر (اختیاری)

قبل از استقرار یک اپلیکیشن، باید بررسی کنید که واقعاً کجا می‌خواهید آن را مستقر کنید. به‌صورت پیش‌فرض، Argo CD اپلیکیشن‌ها را روی همان کلاستری که خودِ Argo CD در آن اجرا می‌شود مستقر می‌کند؛ که برای یک دمو مناسب است اما احتمالاً چیزی نیست که در production بخواهید. برای فهرست‌کردن همه کلاسترهای شناخته‌شده برای ماشین فعلی خود، می‌توانید از kubectl config استفاده کنید:

kubectl config get-contexts -o name

خروجی:

test-deploy-cluster
test-target-cluster

با فرض اینکه Argo CD را در test-deploy-cluster نصب کرده‌اید و می‌خواهید از آن برای استقرار اپلیکیشن‌ها روی test-target-cluster استفاده کنید، می‌توانید test-target-cluster را با اجرای argocd cluster add در Argo CD ثبت کنید:

argocd cluster add target-k8s

این کار اطلاعات ورودِ کلاستر اضافی را به Argo CD اضافه کرده و به آن امکان می‌دهد سرویس‌ها را روی آن کلاستر مستقر کند.

مرحله ۵ — استقرار یک اپلیکیشن نمونه (اختیاری)

حالا که Argo CD در حال اجراست و درک کردید چطور اپلیکیشن‌ها را روی کلاسترهای مختلف Kubernetes مستقر کنید، وقت عملی‌کردن آن است. پروژه Argo CD مخزنی از اپلیکیشن‌های نمونه را نگهداری می‌کند که برای نمایش اصول پایه GitOps معماری شده‌اند. بسیاری از این مثال‌ها، نسخه‌هایی از همان اپلیکیشن دموی guestbook برای انواع مختلف Manifestهای Kubernetes — مانند Jsonnet — هستند. در این مورد، مثال helm-guestbook را مستقر می‌کنید که از یک Helm Chart استفاده می‌کند؛ یکی از بادوام‌ترین راه‌حل‌های مدیریت Kubernetes.

برای آشنایی با Helm و نحوه مدیریت پکیج‌های Kubernetes توسط آن، مقاله «مقدمه‌ای بر Helm، مدیر پکیج Kubernetes» را ببینید.

برای این کار، از دستور argocd app create استفاده می‌کنید؛ با ارائه مسیر مخزن Git، مثال خاص helm-guestbook و پاس دادن مقصد و Namespace پیش‌فرض خود:

argocd app create helm-guestbook --repo https://github.com/argoproj/argocd-example-apps.git --path helm-guestbook --dest-server https://kubernetes.default.svc --dest-namespace default

پس از «ساخت» اپلیکیشن داخل Argo CD، می‌توانید وضعیتش را با argocd app get بررسی کنید:

argocd app get helm-guestbook

خروجی:

Name:               helm-guestbook
Project:            default
Server:             https://kubernetes.default.svc
Namespace:          default
URL:                https://localhost:8080/applications/helm-guestbook
Repo:               https://github.com/argoproj/argocd-example-apps.git
Target:
Path:               helm-guestbook
SyncWindow:         Sync Allowed
Sync Policy:        <none>
Sync Status:        OutOfSync from  (53e28ff)
Health Status:      Missing

GROUP  KIND        NAMESPACE  NAME            STATUS     HEALTH   HOOK  MESSAGE
       Service     default    helm-guestbook  OutOfSync  Missing
apps   Deployment  default    helm-guestbook  OutOfSync  Missing

وضعیت OutOfSync اپلیکیشن طبیعی است. شما Helm Chart اپلیکیشن را از GitHub دریافت و ورودی‌ای برای آن در Argo CD ساخته‌اید؛ اما هنوز هیچ منبعِ Kubernetesای برای آن راه‌اندازی نکرده‌اید. برای استقرار واقعی اپلیکیشن، دستور argocd app sync را اجرا می‌کنید:

argocd app sync helm-guestbook

sync اینجا هم‌معنای استقرار (Deployment) است؛ هم‌راستا با اصول GitOps. هدف هنگام استفاده از Argo CD این است که اپلیکیشن شما همیشه ۱:۱ با پیکربندی بالادستی (Upstream) خود ردیابی شود.

خروجی:

TIMESTAMP                  GROUP        KIND   NAMESPACE                  NAME    STATUS    HEALTH        HOOK  MESSAGE
2022-01-19T11:01:48-08:00            Service     default        helm-guestbook  OutOfSync  Missing
2022-01-19T11:01:48-08:00   apps  Deployment     default        helm-guestbook  OutOfSync  Missing
2022-01-19T11:01:48-08:00            Service     default        helm-guestbook    Synced  Healthy
2022-01-19T11:01:48-08:00            Service     default        helm-guestbook    Synced   Healthy              service/helm-guestbook created
2022-01-19T11:01:48-08:00   apps  Deployment     default        helm-guestbook  OutOfSync  Missing              deployment.apps/helm-guestbook created
2022-01-19T11:01:49-08:00   apps  Deployment     default        helm-guestbook    Synced  Progressing              deployment.apps/helm-guestbook created

Name:               helm-guestbook
Project:            default
Server:             https://kubernetes.default.svc
Namespace:          default
URL:                https://localhost:8080/applications/helm-guestbook
Repo:               https://github.com/argoproj/argocd-example-apps.git
Target:
Path:               helm-guestbook
SyncWindow:         Sync Allowed
Sync Policy:        <none>
Sync Status:        Synced to  (53e28ff)
Health Status:      Progressing

Operation:          Sync
Sync Revision:      53e28ff20cc530b9ada2173fbbd64d48338583ba
Phase:              Succeeded
Start:              2022-01-19 11:01:49 -0800 PST
Finished:           2022-01-19 11:01:50 -0800 PST
Duration:           1s
Message:            successfully synced (all tasks run)

GROUP  KIND        NAMESPACE  NAME            STATUS  HEALTH       HOOK  MESSAGE
       Service     default    helm-guestbook  Synced  Healthy            service/helm-guestbook created
apps   Deployment  default    helm-guestbook  Synced  Progressing        deployment.apps/helm-guestbook created

اکنون یک اپلیکیشن را با استفاده از Argo CD با موفقیت مستقر کرده‌اید! انجام همین کار از رابط وب Argo CD ممکن است؛ اما استقرار از طریق خط فرمان معمولاً سریع‌تر و تکرارپذیرتر است. با این حال، بررسی داشبورد وب Argo CD پس از استقرار برای تأیید اینکه اپلیکیشن‌های شما به‌درستی اجرا می‌شوند، بسیار مفید است. می‌توانید این را با باز کردن localhost:8080 در یک مرورگر ببینید:

[تصویر: وضعیت اپلیکیشن در Argo CD]

در این نقطه، آخرین کار این است که مطمئن شوید می‌توانید استقرار جدید خود را در یک مرورگر باز کنید. برای این کار، پورت دیگری را همان‌طور که برای خودِ Argo CD انجام دادید فوروارد می‌کنید. به‌صورت داخلی، اپ helm-guestbook روی پورت معمولی HTTP یعنی 80 اجرا می‌شود و برای جلوگیری از تداخل با هر چیزی که ممکن است روی پورت 80 خودتان یا پورت 8080ی که برای Argo CD استفاده می‌کنید در حال اجرا باشد، می‌توانید آن را به پورت 9090 فوروارد کنید:

kubectl port-forward svc/helm-guestbook 9090:80

مثل قبل، احتمالاً می‌خواهید این کار را در ترمینال دیگری انجام دهید؛ چون تا وقتی Ctrl+C را برای توقف فوروارد پورت فشار ندهید، آن ترمینال را مسدود می‌کند. سپس می‌توانید localhost:9090 را در یک پنجره مرورگر باز کنید تا اپلیکیشن نمونه Guestbook خود را ببینید:

[تصویر: اپلیکیشن Guestbook]

هر Push بعدی به این مخزن GitHub به‌طور خودکار در Argo CD منعکس شده و استقرار شما را — while دسترس‌پذیری پیوسته فراهم می‌کند — دوباره همگام‌سازی می‌کند.

مدیریت استقرارها با Helm و Kustomize

Argo CD به‌صورت بومی از چندین فرمت Manifest برای تعریف اپلیکیشن‌های Kubernetes پشتیبانی می‌کند. دو مورد پرکاربرد، Helm و Kustomize هستند.

Chartهای Helm با Argo CD

Helm یک مدیر پکیج برای Kubernetes است که منابع مرتبط را در یک Chart بسته‌بندی می‌کند. وقتی Argo CD را به یک Helm Chart در یک مخزن Git اشاره می‌دهید، قالب‌های (Template) Chart را با مقادیری که ارائه می‌دهید Render کرده و Manifestهای حاصل را روی کلاستر شما اعمال می‌کند.

می‌توانید مقادیر Helm را مستقیماً در Manifest اپلیکیشنِ Argo CD خود Override کنید:

my-app.yaml

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: charts/my-app
    helm:
      valueFiles:
        - values-production.yaml
  destination:
    server: https://kubernetes.default.svc
    namespace: production

این رویکرد اعلانی یعنی Releaseهای Helm شما در Git ردیابی شده و به‌طور خودکار توسط Argo CD همگام می‌شوند. برای جزئیات بیشتر درباره کار با Helm، مقاله «مقدمه‌ای بر Helm، مدیر پکیج Kubernetes» را ببینید.

Kustomize با Argo CD

Kustomize به شما اجازه می‌دهد Manifestهای Kubernetes را بدون تغییر فایل‌های YAML اصلی سفارشی کنید. این ابزار از Overlayها برای Patch کردن پیکربندی‌های پایه برای محیط‌های مختلف استفاده می‌کند. Argo CD فایل‌های kustomization.yaml را به‌طور خودکار تشخیص داده و با پشتیبانی داخلی Kustomize اعمالشان می‌کند.

یک ساختار دایرکتوری معمول Kustomize برای چند محیط به این شکل است:

base/
  deployment.yaml
  service.yaml
  kustomization.yaml
overlays/
  staging/
    kustomization.yaml
  production/
    kustomization.yaml

هر Overlay به پایه (Base) ارجاع داده و Patchهای خاصِ محیط را اضافه می‌کند؛ مانند تعداد Replicaهای متفاوت، محدودیت‌های منابع یا Tagهای ایمیج.

استراتژی GitOps چندمحیطی

در production، معمولاً روی چند محیط مانند development، staging و production استقرار می‌کنید. Argo CD چند استراتژی برای مدیریت این موضوع پشتیبانی می‌کند:

• دایرکتوری‌های جداگانه برای هر محیط. Manifestهای خود را در دایرکتوری‌های مخصوص هر محیط داخل یک مخزن واحد ذخیره کنید. هر اپلیکیشن Argo CD به مسیر دایرکتوری مربوطه اشاره می‌کند.
• شاخه‌های (Branch) جداگانه برای هر محیط. از شاخه‌های Git مانند develop، staging و main برای نمایش محیط‌های مختلف استفاده کنید. Argo CD می‌تواند یک شاخه مشخص را در فیلد targetRevision ردیابی کند.
• مخازن جداگانه برای هر محیط. برای سازمان‌های بزرگ‌تر، ممکن است برای پیکربندی هر محیط یک مخزن Git اختصاصی نگه دارید. این قوی‌ترین ایزولاسیون را فراهم می‌کند.

انتخاب به اندازه تیم و الزامات امنیتی شما بستگی دارد. برای بیشتر تیم‌ها، رویکرد مبتنی بر دایرکتوری، تعادل خوبی بین سادگی و جداسازی فراهم می‌کند.

بهترین شیوه‌های امنیتی برای Argo CD

هنگام اجرای Argo CD در production، این اقدامات امنیتی را در نظر بگیرید:

• رمز عبور پیش‌فرض admin را فوراً تغییر دهید. رمز عبور تولیدشده خودکار که در مرحله ۳ بازیابی کردید، فقط برای راه‌اندازی اولیه در نظر گرفته شده است. بلافاصله بعد از اولین ورود، دستور argocd account update-password را اجرا کنید.
• RBAC را فعال کنید. Argo CD از کنترل دسترسی مبتنی بر نقش (RBAC) برای محدودکردن اینکه کدام کاربران می‌توانند روی کدام پروژه‌ها و کلاسترها استقرار کنند پشتیبانی می‌کند. می‌توانید سیاست‌ها را در ConfigMap با نام argocd-rbac-cm تعریف کنید.
• احراز هویت SSO را استفاده کنید. Argo CD با ارائه‌دهندگان هویت از طریق OIDC، SAML 2.0 و LDAP یکپارچه می‌شود. این به شما اجازه می‌دهد به‌جای مدیریت حساب‌های محلی، از سیستم احراز هویت موجود سازمان‌تان استفاده کنید.
• دسترسی شبکه را محدود کنید. به‌جای در معرض نمایش گذاشتن مستقیم سرور Argo CD، از یک Ingress Controller مربوط به Kubernetes همراه با خاتمه TLS استفاده کنید. می‌توانید گواهی‌های HTTPS را با Cert-Manager روی Kubernetes پارمین کلود راه‌اندازی کنید.
• لاگ‌گیری ممیزی را فعال کنید. Argo CD همه عملیات‌های همگام‌سازی اپلیکیشن را لاگ می‌کند؛ که یک رد ممیزی فراهم می‌آورد. این لاگ‌ها را برای نگهداری بلندمدت به یک سیستم لاگ‌گیری متمرکز فوروارد کنید.
• از کامیت‌های امضاشده Git استفاده کنید. در مخزن GitOps خود، کامیت‌های امضاشده با GPG را الزامی کنید تا تأیید شود فقط اعضای مجاز تیم می‌توانند وضعیت موردنظرِ کلاستر را تغییر دهند.

Argo CD در برابر Flux: انتخاب ابزار GitOps

Argo CD و Flux دو ابزار محبوب GitOps برای Kubernetes هستند. هر دو پروژه CNCF هستند و از همان اصول پایه GitOps پیروی می‌کنند. مقایسه آن‌ها به این شکل است:

ویژگی	Argo CD	Flux
رابط کاربری	رابط وب و CLI داخلی	فقط CLI (رابط‌های شخص ثالث موجودند)
چند-مستأجری (Multi-Tenancy)	ایزولاسیون مبتنی بر AppProject	ایزولاسیون مبتنی بر Namespace
پشتیبانی Manifest	Helm، Kustomize، Jsonnet، YAML	Helm، Kustomize، YAML
رویکرد Sync	دستی یا خودکار	به‌صورت پیش‌فرض خودکار
چندکلاستری	پشتیبانی بومی	از طریق Cluster API پشتیبانی می‌شود
RBAC	موتور سیاست داخلی	RBAC بومی Kubernetes
معماری	سرور متمرکز	Controllerهای توزیع‌شده

وقتی Argo CD را انتخاب کنید که به یک داشبورد بصری نیاز دارید، کنترل دسترسی دقیق با سیستم RBAC داخلی‌اش را می‌خواهید یا چند کلاستر را از یک صفحه کنترل مرکزی مدیریت می‌کنید.

وقتی Flux را انتخاب کنید که رویکردی سبک و مبتنی بر Controller را ترجیح می‌دهید که با الگوهای بومی Kubernetes یکپارچه است، یا می‌خواهید هر تیم پیکربندی GitOps خودش را مستقل مدیریت کند.

هر دو ابزار برای GitOps روی Kubernetes خوب کار می‌کنند و بهترین انتخاب به ترجیحات گردش کار تیم و الزامات زیرساخت شما بستگی دارد.

عیب‌یابی مشکلات رایج

مشکلات رایجی که ممکن است هنگام کار با Argo CD با آن‌ها روبرو شوید و راه‌حل‌شان به این شرح است.

مشکل	علت	راه‌حل
گیرکردن اپلیکیشن روی OutOfSync	تنظیم‌نبودن سیاست Sync یا عدم تطابق منبع	argocd app sync <app-name> را اجرا کنید یا Auto-Sync را فعال کنید
خطای ComparisonError در وضعیت اپ	Manifestهای نامعتبر یا نبودن مقادیر Helm	برای جزئیات خطا، argocd app get <app-name> را بررسی کنید
عدم توان اتصال به رابط Argo CD	غیرفعال بودن فوروارد پورت یا پورت اشتباه	دستور kubectl port-forward را دوباره اجرا کنید
وضعیت سلامت Unknown	منبع سفارشی بدون تعریف Health Check	یک Health Check سفارشی در ConfigMap مربوط به argocd-cm اضافه کنید
موفقیت Sync اما کرش کردن Podها	خطای پیکربندی اپلیکیشن	لاگ Podها را با kubectl logs <pod-name> بررسی کنید
خطای Permission denied هنگام Sync	نبودن نقش‌های RBAC یا دسترسی کلاستر	argocd cluster list و تنظیمات RBAC را تأیید کنید

برای اطلاعات خطای دقیق درباره هر اپلیکیشن، اجرا کنید:

argocd app get <app-name> --show-operation

این آخرین عملیات Sync و هر پیام خطای مرتبط با آن را نشان می‌دهد.

سوالات متداول

۱. GitOps در Kubernetes چیست؟

GitOps یک روش‌شناسی استقرار است که از یک مخزن Git به‌عنوان منبع واحد حقیقت برای وضعیت موردنظر کلاستر Kubernetes شما استفاده می‌کند. یک Agent داخل کلاستر به‌طور پیوسته وضعیت زنده را با آنچه در Git تعریف شده مقایسه کرده و هر تفاوتی را به‌طور خودکار همگام می‌کند. این رویکرد استقرارهای نسخه‌بندی‌شده، Rollbackهای آسان از طریق Revert کردن Git و رد ممیزی واضحی از هر تغییر فراهم می‌کند.

۲. آیا Argo CD ابزار CI است یا CD؟

Argo CD یک ابزار تحویل پیوسته (CD) است، نه یکپارچسازی پیوسته (CI). این ابزار سمت استقرارِ خط لوله را با همگام‌کردن کلاستر Kubernetes شما با وضعیت موردنظرِ ذخیره‌شده در یک مخزن Git هندل می‌کند. برای سمت CI — که شامل Build کد، اجرای تست‌ها و ساخت ایمیج‌های کانتینر است — از یک ابزار جداگانه مانند GitHub Actions، Jenkins یا GitLab CI استفاده کرده و آن را با Argo CD یکپارچه می‌کنید.

۳. Argo CD چطور انحراف (Drift) را تشخیص می‌دهد؟

Argo CD یک حلقه Reconciliation را اجرا می‌کند که به‌صورت دوره‌ای وضعیت موردنظرِ تعریف‌شده در مخزن Git شما را با وضعیت زنده در کلاستر Kubernetes مقایسه می‌کند. به‌صورت پیش‌فرض این بررسی هر سه دقیقه اجرا می‌شود؛ هرچند می‌توانید بازه را پیکربندی کنید. اگر کسی با kubectl edit یا ابزار دیگری تغییر دستی روی یک منبع در کلاستر اعمال کند، Argo CD اپلیکیشن را OutOfSync علامت‌گذاری کرده و — اگر گزینه Self-Heal را در سیاست Sync فعال کرده باشید — می‌تواند به‌صورت اختیاری تغییر را به‌طور خودکار بازگرداند.

۴. آیا Argo CD می‌تواند Helm Chartها را مستقر کند؟

بله. Argo CD از Helm Chartها به‌صورت بومی پشتیبانی می‌کند. وقتی یک اپلیکیشن Argo CD را به دایرکتوری‌ای حاوی فایل Chart.yaml اشاره می‌دهید، به‌طور خودکار قالب‌های Helm را Render کرده و Manifestهای حاصل را اعمال می‌کند. می‌توانید فایل‌های مقادیر سفارشی تعیین کنید، پارامترهای منفرد تنظیم کنید و نسخه‌های خاصی از Chart را ردیابی کنید؛ همه به‌صورت اعلانی در Specification اپلیکیشن.

۵. تفاوت Argo CD و Flux چیست؟

هر دو Argo CD و Flux ابزارهای GitOps با پشتیبانی CNCF برای Kubernetes هستند. Argo CD یک رابط وب داخلی، یک CLI، RBAC دقیق و یک معماری متمرکز فراهم می‌کند که آن را برای مدیریت چند کلاستر از یک صفحه کنترل واحد مناسب می‌سازد. Flux رویکردی توزیع‌شده‌تر و مبتنی بر Controller دارد که با الگوهای بومی Kubernetes یکپارچه است. Flux رابط وب داخلی ندارد اما عموماً در مصرف منابع سبک‌تر است.

جمع‌بندی

اکنون اصول پایه نصب و استقرار اپلیکیشن‌ها با استفاده از Argo CD و روش‌شناسی GitOps را دیدید. چون Kubernetes به لایه‌های زیادی از انتزاع نیاز دارد، مهم است مطمئن شوید استقرارهای شما تا جای ممکن قابل‌نگهداری هستند و فلسفه GitOps راه‌حل خوبی است. با هندل‌کردن Reconciliation پیوسته، تشخیص انحراف و همگام‌سازی خودکار از Git توسط Argo CD، می‌توانید روی نوشتن کد تمرکز کنید؛ درحالی‌که استقرارهایتان سازگار و قابل‌ممیزی باقی می‌مانند.