در یک cluster بزرگ، صدها node همزمان یک image می‌کشند:

Registry / Harbor
    ↑  ↑  ↑  ↑  ↑   ← طوفان QPS و bandwidth
  node node node …

نتیجه: pull کند، registry داغ، rollout شکست‌خورده، هزینه egress بالا.

Dragonfly پاسخ cloud-native است:

Delivers efficient, stable, and secure data distribution and acceleration powered by P2P technology, with an optional content-addressable filesystem that accelerates OCI container launch.

یعنی توزیع فایل و image با P2P — Peerها از همدیگر قطعه می‌گیرند؛ source فقط یک‌بار (یا کم) تحت فشار است. همراه اختیاری: Nydus برای شتاب راه‌اندازی OCI.

CNCF Graduated — ۲۸ اکتبر ۲۰۲۵ (Sandbox نوامبر ۲۰۱۸، Incubating آوریل ۲۰۲۰). نسخه docs فعلی حول v2.5.0. Production در Alibaba، Ant Group، ByteDance-scale adopters، Baidu، Meituan، Huawei، Datadog و ده‌ها شرکت دیگر.

مشکل: Registry به‌عنوان تک‌نقطه فشار

بدون P2P:
  N node × pull کامل = N × traffic به registry

با Dragonfly:
  1× back-to-source (Seed Peer)
  (N−1) × از Peerهای محلی / هم‌شبکه

Dragonfly فقط برای container image نیست — فایل، OCI artifact، مدل AI/ML، cache، log، dependency و هر داده قابل‌توزیع بزرگ.

Dragonfly چیست؟

Dragonfly سیستم data distribution and acceleration مبتنی بر P2P است که:

• پهنای باند بیکار Peerها را برای download سریع‌تر به کار می‌گیرد
• غیرتهاجمی با runtimeها، ابزارهای download و زیرساخت AI یکپارچه می‌شود
• consistency فایل را حتی بدون چک صریح کاربر تضمین می‌کند
• exception را در سطح Service / Peer / Task ایزوله می‌کند
• با Harbor، Nydus، containerd، و toolingهای pull ادغام می‌شود

Site: d7y.io
Docs: d7y.io/docs
Repo: github.com/dragonflyoss/dragonfly
Nydus: github.com/dragonflyoss/nydus

License: Apache 2.0

نام دامنه d7y از «dragonfly» می‌آید (۷ حرف بین d و y).

تاریخچه و milestones

ریشه پروژه در اکوسیستم Alibaba / Ant — امروز استاندارد توزیع image در معماری cloud-native بسیاری از adopters آسیایی و جهانی.

معماری: چهار نقش

طبق مستندات رسمی:

                    ┌──────────┐
                    │ Manager  │  config, console, multi-cluster relations
                    └────┬─────┘
                         │
                    ┌────▼─────┐
                    │Scheduler │  parent selection, DAG, back-to-source
                    └────┬─────┘
           ┌─────────────┼─────────────┐
           ▼             ▼             ▼
      Seed Peer        Peer          Peer
      (root / source)  (dfdaemon)    (dfdaemon)
           │
           ▼
     Registry / HTTP origin / S3 / …

Manager

• روابط بین P2P clusterها
• dynamic configuration و جمع‌آوری داده
• Console وب برای مدیریت بصری
• keepalive با Scheduler و Seed Peer
• فیلتر بهترین scheduler cluster برای client
• async task مثل image preheat (ترکیب با Harbor)
• پاک‌سازی cache تسک‌ها

Scheduler

• انتخاب optimal parent برای هر Peer در حال download
• ساخت DAG زمان‌بندی برای شبکه P2P
• حذف Peer ناسالم بر اساس ارزیابی multi-feature
• در شکست scheduling → دستور back-to-source
• metadata برای نوشتن فایل و seeding
• الگوریتم load-aware دو مرحله‌ای (مرکزی + سطح node)

Seed Peer

• Root peer شبکه — upload و download
• توسط Scheduler برای کشیدن از source فعال می‌شود
• قطعات (pieces) را به بقیه Peerها پخش می‌کند
• در بهترین حالت، همان task فقط یک‌بار از registry می‌آید

Peer (dfdaemon)

• agent روی node / client
• upload + download
• درخواست از طریق HTTP/HTTPS Proxy یا gRPC
• می‌تواند در حالت Seed Peer هم کار کند

ابزار کلاسیک client: dfget — دانلود با قابلیت‌های P2P؛ dfdaemon gRPC و proxy برای runtimeها فراهم می‌کند.

جریان کار: اولین pull در برابر pull بعدی

Client → Peer (proxy/gRPC)
       → register Task با Scheduler

اولین دانلود در cluster

1. Scheduler می‌بیند task جدید است
2. Seed Peer را برای download از source (registry) trigger می‌کند
3. فایل به pieces تقسیم می‌شود
4. Peer به Scheduler وصل می‌شود؛ قطعه به قطعه از Seed Peer می‌گیرد
5. metadata هر piece گزارش می‌شود → برای scheduling بعدی

دانلودهای بعدی

1. اگر pieces در cache محلی باشد → اسمبل و return بدون Scheduler
2. وگرنه Scheduler Peerهایی که محتوا را دارند به‌عنوان Parents می‌دهد
3. دانلود موازی از چند Parent → اسمبل فایل کامل

نتیجه عملی در cluster بزرگ: فشار QPS و bandwidth روی Harbor/registry به‌شدت کم می‌شود — به‌خصوص با Nydus که range requestهای زیاد تولید می‌کند.

ویژگی‌های کلیدی

Nydus: filesystem برای شتاب OCI

Nydus یک content-addressable filesystem است (RAFS) که:

• image را on-demand لود می‌کند (نه لزوماً کل layer قبل از start)
• با FUSE، virtiofs، یا EROFS + fscache در کرنل کار می‌کند
• با OCI و eStargz سازگار است
• backend: Registry، OSS، NAS، shared disk، و Dragonfly P2P

چرا با Dragonfly؟

Nydus فایل را به chunkهای حدود ۱MB می‌شکند و با HTTP range می‌کشد → در cluster بزرگ = طوفان درخواست به registry.

Dragonfly به‌عنوان cache / P2P layer:

• proxy.rules.regex URL ریپوی Nydus را intercept می‌کند
• Seed Peer می‌تواند با prefetch کل resource را بعد از range اول بگیرد → hit rate بهتر
• در حالت ایده‌آل همان task فقط یک‌بار back-to-source می‌شود
• گزارش‌های production (مثلاً Ant Group): کاهش چشمگیر latency شبکه (حتی >۸۰٪ در برخی سناریوها)

ابزارها: nydusd، nydus-image، nydusctl — و integration در Harbor برای تبدیل/ساخت imageهای Nydus.

یکپارچگی با اکوسیستم

Container runtimes

• containerd — proxy یا snapshotter path
• CRI-O / Docker (via compatible proxy patterns)
• پیکربندی runtime برای عبور pull از dfdaemon proxy

Harbor

• preheat image به Seed Peerها قبل از rollout
• کاهش cold-start وقتی Deployment بزرگ scale می‌شود

AI / ML

• توزیع مدل‌های بزرگ و dataset artifacts بین workerها
• همان منطق P2P — registry یا object store کمتر داغ می‌شود

Download tools

• HTTP clients از طریق proxy dfdaemon
• dfget برای فایل‌های عمومی

نصب روی Kubernetes

الگوی رایج با Helm:

helm repo add dragonfly https://dragonflyoss.github.io/helm-charts/
helm repo update

helm install --wait --timeout 10m \
  --dependency-update \
  --create-namespace \
  --namespace dragonfly-system \
  dragonfly dragonfly/dragonfly \
  --set dfdaemon.config.download.prefetch=true \
  --set seedPeer.config.download.prefetch=true

kubectl -n dragonfly-system get pods

اجزای معمول chart: Manager، Scheduler، Seed Peer، dfdaemon (DaemonSet روی nodeها).

Lightweight vs با Manager

طبق Quick Start:

• Lightweight — ساده‌تر برای lab / تک‌cluster
• با Manager — console، multi-cluster، preheat، config مرکزی
• Multi-cluster Kubernetes — چند P2P domain با مدیریت Manager

بعد از نصب، runtime را طوری تنظیم کنید که pull از proxy/port dfdaemon روی node عبور کند — جزئیات در docs نسخه شما: Getting Started on Kubernetes.

مشاهده Scheduler / dfdaemon (debug)

export SCHEDULER_POD_NAME=$(kubectl get pods -n dragonfly-system \
  -l "app=dragonfly,component=scheduler" \
  -o jsonpath='{.items[0].metadata.name}')

kubectl -n dragonfly-system port-forward "$SCHEDULER_POD_NAME" 8002:8002

تنظیمات مهم production

Exception isolation در سه سطح کمک می‌کند یک Peer خراب کل cluster را خراب نکند.

مقایسه با جایگزین‌ها

Dragonfly جایگزین registry نیست — جلوی آن می‌نشیند تا توزیع را شتاب بدهد و فشار را کم کند.

Observability و troubleshooting

kubectl -n dragonfly-system get pods
kubectl -n dragonfly-system logs -l component=scheduler --tail=100
kubectl -n dragonfly-system logs -l component=dfdaemon --tail=100

Metrics برای task success، back-to-source rate، peer bandwidth — هدف: نسبت back-to-source پایین بعد از warm cache.

امنیت

• محدودیت اینکه چه URLهایی از proxy P2P عبور کنند (allowlist / regex)
• جداسازی شبکه Manager/Scheduler از internet
• احراز هویت به registry (pull secret) همچنان روی path source
• به‌روزرسانی منظم — P2P سطح حمله را عوض می‌کند (Peer-to-Peer) پس isolation و limit حیاتی است
• Console Manager پشت SSO / Ingress + cert-manager

ارتباط با stack شما

kubectl apply / [Argo CD](/blog/argo-project-kubernetes-gitops-cicd/)
        │
        ▼
   kubelet → CRI ([containerd](/blog/containerd-container-runtime-guide/))
        │
        ▼
   dfdaemon Peer  ←──P2P──→  Peers / Seed Peer
        │
        ▼ (miss)
   Harbor / Registry / Object storage

Optional:
   Nydus snapshotter → on-demand layers via Dragonfly cache

Cluster foundation:
   [CoreDNS](/blog/coredns-kubernetes-dns-guide/) · [Cilium](/blog/cilium-ebpf-kubernetes-networking/) · [etcd](/blog/etcd-distributed-key-value-store-guide/)

برای platform engineering، Crossplane می‌تواند cluster/node را provision کند؛ Dragonfly لایه distribution را هنگام scale اپ‌ها سبک نگه می‌دارد.

Best practices

1. Preheat imageهای rollout بزرگ قبل از deploy
2. Seed Peer را روی node با uplink و disk قوی بگذارید
3. برای AI modelهای چند‌GB، همان P2P path را تست کنید نه فقط OCI
4. Monitor back-to-source ratio به‌عنوان KPI
5. Peer cache را روی volume جدا از OS نگه دارید
6. Nydus را فقط وقتی on-demand لازم است اضافه کنید — پیچیدگی بیشتر
7. در multi-AZ، scheduling را طوری تنظیم کنید که P2P از AZ گران‌قیمت بی‌خودی عبور نکند
8. با GitOps نسخه chart و config را قفل کنید
9. Load test با N همزمان pull قبل از Black Friday / sale event
10. مستندات نسخه chart را با runtime (containerd config) sync نگه دارید

چه زمانی Dragonfly؟

✅ استفاده کنید

• cluster بزرگ با pull همزمان زیاد
• CI/CD که هر pipeline image سنگین می‌کشد
• AI training / inference با artifactهای مشترک بزرگ
• کاهش هزینه و QPS Harbor/cloud registry
• نیاز به Nydus برای cold start سریع‌تر Pod

⚠️ شاید نه

• ۳ node و image کوچک — overhead ارزش ندارد
• فقط یک registry pull-through کافی است
• شبکه بین nodeها بسیار ضعیف / گران (P2P بدتر می‌کند)
• تیم بدون ظرفیت ops برای Manager/Scheduler/Seed

جمع‌بندی

Dragonfly registry را حذف نمی‌کند — طوفان pull را به همکاری Peerها تبدیل می‌کند تا Kubernetes در مقیاس واقعی سریع و پایدار بماند.

قدم بعدی

1. Helm نصب در namespace dragonfly-system روی cluster آزمایشی
2. یک node را با dfdaemon proxy به containerd وصل کنید
3. همان image را از ۱۰ Pod همزمان بکشید — متریک registry را ببینید
4. (اختیاری) Nydus + prefetch را برای یک image آزمایشی فعال کنید
5. Harbor preheat را برای Production rollout طراحی کنید

منابع

• Dragonfly — d7y.io
• Introduction / Docs
• Quick Start
• Nydus integration
• GitHub — dragonflyoss/dragonfly
• GitHub — dragonflyoss/nydus
• CNCF: Nydus and Dragonfly practices (Ant Group)

منتشر شده در P30Light — بخش زیرساخت و سرور.