تحویل مدرن اپلیکیشنها نه تنها به سرعت، بلکه به قابلیت اطمینان نیاز دارد. در دنیای Kubernetes، دستیابی به استقرار بدون توقف دیگر یک لوکس نیست؛ بلکه یک انتظار پایهای برای سیستمهای سطح تولید است. با ترکیب استحکام GitLab CI برای فرآیندهای ساخت و تست با قدرت اظهاری ArgoCD برای هماهنگسازی استقرار، میتوانید یک خط لوله مبتنی بر GitOps ایجاد کنید که تضمین میکند سرویسهای شما در طول بهروزرسانیها در دسترس باقی میمانند.
چرا GitLab CI و ArgoCD را ترکیب کنیم؟
ابزارهای سنتی CI/CD اغلب هم ساخت و هم استقرار را در یک مرحله واحد و یکپارچه مدیریت میکنند. اگرچه این رویکرد مؤثر است، اما میتواند منجر به مشکلات پیچیده در مدیریت وضعیت شود. تفکیک نگرانیها مزایای مشخصی دارد:
- GitLab CI: در کامپایل، تستهای واحد، ساخت تصویر و ارسال خروجیها به ثبتنامگر کانتینر عالی است.
- ArgoCD: تخصص آن در همگامسازی وضعیت مطلوب تعریفشده در مخزن Git شما با وضعیت زنده خوشه Kubernetes شماست.
این تفکیک به شما امکان میدهد «نحوه ساخت» را از «نحوه استقرار» جدا کنید، که منجر به ردیابیهای ممیزی شفافتر و مکانیزمهای بازگشت سادهتر میشود.
راهاندازی خط لوله GitLab CI
ابتدا، بیایید جریان کاری GitLab CI را تعریف کنیم. هدف اصلی در اینجا تولید یک تصویر کانتینر و بهروزرسانی مانیفستهای Kubernetes در مخزن Git شماست. این اصل بنیادین GitOps است: مخزن Git تنها منبع حقیقت است.
stages:
- build
- push
- deploy
variables:
REGISTRY_IMAGE: $CI_REGISTRY_IMAGE
build:
stage: build
image: docker:latest
services:
- docker:dind
script:
- docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
- docker build -t $REGISTRY_IMAGE:$CI_COMMIT_SHA .
only:
- main
push:
stage: push
image: alpine:latest
script:
- apk add --no-cache git
- git config --global user.email "gitlab-ci-token@gl-sa-pipeline"
- git config --global user.name "GitLab CI"
- echo "$CI_REGISTRY_PASSWORD" > ~/.netrc
- docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
- docker push $REGISTRY_IMAGE:$CI_COMMIT_SHA
update-manifests:
stage: deploy
image: alpine:latest
script:
- apk add --no-cache git
- git config --global user.email "gitlab-ci-token@gl-sa-pipeline"
- git config --global user.name "GitLab CI"
- cd k8s-manifests
- sed -i 's|image: .*$|image: '$REGISTRY_IMAGE':$CI_COMMIT_SHA|' deployment.yaml
- git add .
- git commit -m "Update image to $CI_COMMIT_SHA" || true
- git push origin main
only:
- main
after_script:
- echo "Manifests updated. ArgoCD will now detect the change."
به شغل update-manifests توجه کنید. این شغل مستقیماً به Kubernetes استقرار نمیدهد. به جای آن، فایل deployment.yaml را در مخزن با تگ تصویر جدید بهروزرسانی میکند. این کار باعث میشود ArgoCD تغییر در مخزن Git را تشخیص دهد.
پیکربندی ArgoCD برای GitOps
ArgoCD به عنوان یک کنترلر در خوشه Kubernetes شما اجرا میشود. به طور مداوان مخزن Git شما را تحت نظر دارد. وقتی تغییری در مانیفستها (مانند بهروزرسانی تگ تصویر از GitLab CI) تشخیص دهد، به طور خودکار خوشه را با وضعیت جدید همگام میکند.
برای اطمینان از عدم توقف، استراتژی استقرار Kubernetes شما باید روی RollingUpdate تنظیم شود. این استراتژی پیشفرض است، اما خوب است که صریحاً مشخص شود.
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app
spec:
replicas: 3
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 1
maxUnavailable: 0
template:
metadata:
labels:
app: my-app
spec:
containers:
- name: my-app
image: registry.gitlab.com/group/my-app:latest
ports:
- containerPort: 8080
readinessProbe:
httpGet:
path: /health
port: 8080
initialDelaySeconds: 5
periodSeconds: 10
پیکربندی کلیدی برای عدم توقف:
maxUnavailable: 0: تضمین میکند که در طول بهروزرسانی، بیش از صفر پاد در دسترس نباشد. این تضمین میکند که همیشه حداقلreplicas(در این مورد ۳) پاد در حال اجرا و آماده برای ارائه ترافیک هستند.readinessProbe: ArgoCD و Kubernetes به این پروب برای تعیین اینکه آیا یک پاد «آماده» است یا خیر، تکیه میکنند. یک پاد جدید تنها پس از عبور از این پروب سالم در نظر گرفته میشود و IP آن به Endpoints سرویس اضافه میشود. این کار از مسیریابی ترافیک به پادهایی که کاملاً راهاندازی نشدهاند جلوگیری میکند.
جریان بدون توقف
در اینجا فرآیند گامبهگام زمانی است که یک توسعهدهنده کد را به شاخه main ادغام میکند:
- راهاندازی: خط لوله GitLab CI شروع میشود.
- ساخت و ارسال: یک تصویر Docker جدید ساخته شده و با تگ SHA کامیت منحصربهفرد به ثبتنامگر ارسال میشود.
- بهروزرسانی مانیفست: شغل CI فایل
deployment.yamlرا در مخزن Git برای ارجاع به تگ تصویر جدید بهروزرسانی کرده و آن را کامیت میکند. - همگامسازی ArgoCD: ArgoCD تغییر کامیت Git را تشخیص میدهد. وضعیت مطلوب (تصویر جدید) را با وضعیت زنده (تصویر قدیمی) مقایسه میکند.
- بهروزرسانی لغزنده: ArgoCD مانیفست جدید را به Kubernetes اعمال میکند.
- Kubernetes یک ReplicaSet جدید با تصویر جدید ایجاد میکند.
- پادهای جدید راهاندازی شده و از پروبهای آمادگی خود عبور میکنند.
- فقط پس از آماده شدن پادهای جدید، Kubernetes شروع به پایان دادن به پادهای قدیمی میکند.
- LoadBalancer/Service در طول این گذار به مسیریابی ترافیک به پادهای سالم ادامه میدهد.
- تکمیل: تمام پادهای جدید در حال اجرا هستند، پادهای قدیمی پایان یافتهاند و اپلیکیشن به طور کامل بدون توقف بهروزرسانی شده است.
بهترین روشها برای تابآوری
- استفاده از نسخهبندی معنایی برای تصاویر: اگرچه SHAهای کامیت دقیق هستند، استفاده از تگهای معنایی (مثلاً
v1.2.0) بازگشتها را در رابط کاربری ArgoCD آسانتر میکند. میتوانید به سادگی کامیت Git را بازگردانید تا تگ تصویر به نسخه پایدار قبلی تغییر کند. - بررسیهای سلامت حیاتی هستند: اطمینان حاصل کنید که
livenessProbeوreadinessProbeشما به درستی پیکربندی شدهاند. اگر یک پاد جدید در بررسی آمادگی خود شکست بخورد، ArgoCD همگامسازی را ناسالم علامتگذاری میکند و به شما امکان میدهد قبل از حذف پادهای قدیمی مداخله کنید. - پنجرههای همگامسازی ArgoCD: برای کنترل سختگیرانهتر، پنجرههای همگامسازی ArgoCD را پیکربندی کنید تا از استقرارهای خودکار در ساعات تجاری حیاتی جلوگیری شود.
- مانیتورینگ: متریکهای ArgoCD را با Prometheus/Grafana یکپارچه کنید تا وضعیت همگامسازی، سلامت و مدت زمان استقرار را پایش کنید.
نتیجهگیری
با استفاده از GitLab CI برای خودکارسازی ساخت و ArgoCD برای استقرار اظهاری، یک خط لوله CI/CD مستحکم، قابل ممیزی و تابآور ایجاد میکنید. کلید عدم توقف در خود ابزارها نیست، بلکه در پیکربندی صحیح استراتژیهای بهروزرسانی لغزنده Kubernetes و پروبهای سلامت دقیق است. این رویکرد GitOps تضمین میکند که استقرارهای شما قابل پیشبینی، قابل بازگشت و همیشه همگام با منبع حقیقت شما: مخزن Git شما، هستند.