راه‌اندازی Observability با LGTM و Pyroscope، بخش ۲: استقرار اپلیکیشن Django با GitOps و Argo CD

رضا قنبری ۷ اوت ۲۰۲۶ Observability ۱۰ دقیقه مطالعه

در بخش اول یک cluster از Kubernetes را با k0s راه‌اندازی کردیم. در این بخش، اولین بار کاری واقعی را روی این cluster مستقر می‌کنیم: یک اپلیکیشن Django. اما به‌جای اجرای دستی دستورها، از روش GitOps و ابزار Argo CD استفاده می‌کنیم تا وضعیت cluster همیشه با آنچه در Git تعریف شده هماهنگ بماند.

GitOps چیست؟

در روش GitOps، مخزن Git به‌عنوان «منبع حقیقت» در نظر گرفته می‌شود. وضعیت مطلوب سامانه به‌شکل فایل‌های تعریفی (مانیفست‌های Kubernetes) در Git نگه‌داری می‌شود، و یک کنترلر به‌طور پیوسته وضعیت واقعی cluster را با آن مقایسه و در صورت اختلاف، آن را اصلاح می‌کند. مزایای اصلی این رویکرد:

  • هر تغییر از مسیر Git انجام می‌شود؛ بنابراین تاریخچه، بازبینی و بازگردانی تغییرات ساده است.
  • وضعیت cluster قابل بازتولید است؛ اگر cluster از بین برود، از روی همان مخزن دوباره ساخته می‌شود.
  • تغییرات دستی خارج از Git به‌طور خودکار شناسایی و در صورت لزوم بازگردانده می‌شوند.

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

اپلیکیشن نمونه

اپلیکیشن ما یک دفترچه‌ی یادداشت ساده (guestbook) با Django است: فهرستی از پیام‌ها را نشان می‌دهد و امکان افزودن پیام تازه را می‌دهد. کد کامل آن در مخزن عمومی این مجموعه در دسترس است:

https://github.com/obsernetics/observability-lab

برای اجرای اپلیکیشن روی Kubernetes، ابتدا آن را در قالب یک container بسته‌بندی می‌کنیم. فایل Dockerfile اپلیکیشن به این شکل است:

FROM python:3.12-slim
ENV PYTHONDONTWRITEBYTECODE=1 PYTHONUNBUFFERED=1
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY . .
EXPOSE 8000
ENTRYPOINT ["./entrypoint.sh"]

ساخت و انتشار image

image اپلیکیشن را می‌سازیم و در یک registry منتشر می‌کنیم تا Kubernetes بتواند آن را دریافت کند. اینجا از GitHub Container Registry استفاده می‌کنیم:

docker build -t ghcr.io/obsernetics/guestbook:v1 .
docker push ghcr.io/obsernetics/guestbook:v1

نصب Argo CD

Argo CD را در یک namespace جداگانه نصب می‌کنیم. به‌دلیل بزرگ بودن تعریف‌های آن، از حالت server-side apply استفاده می‌کنیم:

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

تعریف اپلیکیشن به‌شکل GitOps

حالا به‌جای اجرای دستی مانیفست‌ها، یک شیء از نوع Application برای Argo CD تعریف می‌کنیم. این شیء به Argo CD می‌گوید کدام مخزن، کدام مسیر و کدام namespace را مدیریت کند. بخش syncPolicy.automated باعث می‌شود همگام‌سازی به‌طور خودکار انجام شود:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: guestbook
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/obsernetics/observability-lab.git
    targetRevision: main
    path: django-app/k8s
  destination:
    server: https://kubernetes.default.svc
    namespace: guestbook
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=true

برای مدیریت منظم‌تر، از الگوی «app-of-apps» استفاده می‌کنیم: یک اپلیکیشن ریشه‌ای که خودش پوشه‌ی apps را می‌خواند و بقیه‌ی اپلیکیشن‌ها را می‌سازد. کافی است همین یک شیء را اعمال کنیم و بقیه به‌طور خودکار از روی Git ساخته شوند.

اعمال و همگام‌سازی

اپلیکیشن ریشه‌ای را اعمال می‌کنیم و سپس وضعیت اپلیکیشن‌ها را بررسی می‌کنیم. وضعیت Synced یعنی cluster با Git هماهنگ است و Healthy یعنی منابع سالم اجرا می‌شوند:

اعمال اپلیکیشن ریشه‌ای و بررسی وضعیت با kubectl
اعمال اپلیکیشن ریشه‌ای؛ سپس هر دو اپلیکیشن root و guestbook در وضعیت Synced و Healthy قرار می‌گیرند و pod اپلیکیشن در حال اجراست.

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

رابط کاربری Argo CD با دو اپلیکیشن Synced و Healthy
نمای اپلیکیشن‌ها در Argo CD. هر دو اپلیکیشن از مخزن observability-lab همگام شده‌اند و سالم هستند.

مشاهده‌ی درخت منابع

با ورود به اپلیکیشن guestbook، Argo CD درخت کامل منابع ساخته‌شده را نشان می‌دهد: از Deployment و ReplicaSet تا Pod و Service. همچنین مشخص است که این وضعیت از کدام commit در Git همگام شده است:

درخت منابع اپلیکیشن guestbook در Argo CD
درخت منابع اپلیکیشن: Deployment، ReplicaSet، Pod و Service. Argo CD نشان می‌دهد وضعیت از آخرین commit روی شاخه‌ی main همگام شده است.

اپلیکیشن در حال اجرا

در نهایت خود اپلیکیشن در دسترس است. این همان دفترچه‌ی یادداشتی است که در بخش‌های بعد آن را با متریک، لاگ، ردیابی و پروفایلینگ زیر نظر خواهیم گرفت:

اپلیکیشن Django guestbook در حال اجرا
اپلیکیشن Django در حال اجرا روی Kubernetes، مستقرشده به‌شکل کاملاً خودکار از روی Git.

جمع‌بندی و بخش بعد

در این بخش اپلیکیشن Django را کانتینری کردیم و آن را با Argo CD و روش GitOps روی cluster مستقر کردیم؛ به‌گونه‌ای که هر تغییری در Git به‌طور خودکار روی cluster اعمال می‌شود. این همان بستری است که بقیه‌ی مجموعه روی آن ساخته می‌شود.

در بخش بعد، اولین سیگنال Observability را اضافه می‌کنیم: متریک‌ها را با Mimir جمع‌آوری و در Grafana به‌شکل یک داشبورد نمایش می‌دهیم.

بخش‌های این مجموعه

← بازگشت به وبلاگ