Loading...

راهنمای CDN.com.tr

انتقال یک سایت زنده Pull-CDN به Platforms بدون قطعی

سرویس‌های مبدأ خود را روی Platforms در cdn.com.tr اجرا کنید در حالی که سایت شما همچنان از طریق Pull CDN سرویس‌دهی می‌شود: اپلیکیشن‌ها را در کنار تحویل فعلی خود فعال کنید، همه‌چیز را روی زیردامنه‌های ca-* بسازید و اعتبارسنجی کنید، سپس دامنه اصلی را تنها زمانی که آماده بودید تعویض کنید — کاملاً برگشت‌پذیر.

انتقال یک سایت زنده Pull-CDN به Platforms بدون قطعی

سرویس‌های مبدأ خود را روی Platforms در cdn.com.tr اجرا کنید در حالی که سایت شما همچنان از طریق Pull CDN سرویس‌دهی می‌شود: اپلیکیشن‌ها را در کنار تحویل فعلی خود فعال کنید، همه‌چیز را روی زیردامنه‌های ca-* بسازید و اعتبارسنجی کنید، سپس دامنه اصلی را تنها زمانی که آماده بودید تعویض کنید — کاملاً برگشت‌پذیر.

مسیر در پنل

  1. Management Panel
  2. CDN Accounts
  3. Platforms tab
  4. Enable apps alongside current delivery
  5. Container Apps / Compose import
  6. Validate on ca-* subdomains
  7. Cut over main domain
  8. Decommission old origin

نقاط بازبینی اسکرین‌شات

گام ۱ — فعال کردن اپلیکیشن‌ها در کنار تحویل فعلی

گام ۱ — فعال کردن اپلیکیشن‌ها در کنار تحویل فعلی

در تب Platforms یک حساب Pull-CDN (یا Push-CDN)، روی «Enable apps alongside current delivery» کلیک کنید. این افزایشی است: دامنه اصلی شما همچنان زنده سرویس‌دهی می‌کند و دوباره مستقر نمی‌شود.

گام ۲ — ساخت، اعتبارسنجی، سپس تعویض

گام ۲ — ساخت، اعتبارسنجی، سپس تعویض

پس از فعال شدن اپلیکیشن‌ها، آن‌ها را روی زیردامنه‌های ca-* می‌سازید. وقتی همه‌چیز درست بود، اقدام جداگانه «Cut over main domain to app» دامنه اصلی را جابه‌جا می‌کند — مبدأ قبلی شما در دسترس می‌ماند تا بتوانید بازگردانید.

موارد کاربرد

یک سایت روی Pull CDN (مبدأ خودش) زنده است و مالک می‌خواهد کل پشته (وب، APIها، workerها، Redis، صف و غیره) را بدون قطعی به پلتفرم منتقل کند.

جریان کاری

  1. Managed Container Apps را در کنار تحویل فعلی خود فعال کنید — این نحوه سرویس‌دهی دامنه اصلی شما را تغییر نمی‌دهد (روی Pull CDN و زنده باقی می‌ماند).
  2. پشته خود را بسازید: docker-compose.yml خود را وارد کنید (یا اپلیکیشن‌ها را یک‌به‌یک بسازید). Redis/PostgreSQL/MySQL/NATS به افزونه‌های مدیریت‌شده تبدیل می‌شوند؛ RabbitMQ/Valkey/Jenkins به‌عنوان اپلیکیشن کانتینری با یک والیوم پایا اجرا می‌شوند.
  3. هر اپلیکیشن زیردامنه ca-*.cdn.com.tr خودش را (و یک نام DNS سرویس داخلی) می‌گیرد. کل پشته را روی آن URLها آزمایش کنید در حالی که سایت زنده دست‌نخورده است.
  4. وقتی همه‌چیز درست بود، تعویض کنید: دامنه اصلی خود را به اپلیکیشن جلویی اشاره دهید. مبدأ قدیمی شما بالا می‌ماند، پس می‌توانید فوراً بازگردانید.

بررسی‌ها

  • فعال کردن اپلیکیشن‌ها منبع محتوای شما را تغییر نمی‌دهد یا دامنه اصلی شما را دوباره مستقر نمی‌کند — سایت زنده Pull-CDN دست‌نخورده است.
  • اپلیکیشن‌ها پیش از هر تعویضی روی زیردامنه‌های ca-* و از طریق نام‌های سرویس داخلی در دسترس‌اند.
  • تعویض یک گام جداگانه و سنجیده است؛ مبدأ قدیمی تا زمانی که آن را از رده خارج کنید یک بازگشت تک‌کلیکی باقی می‌ماند.
  • سرویس‌ها را درست نگاشت کنید: Express/Next/بک‌اند ← اپلیکیشن کانتینری؛ Redis ← افزونه Redis؛ پایگاه‌داده ← افزونه Postgres/MySQL؛ صف ← افزونه NATS یا اپلیکیشن RabbitMQ؛ Jenkins ← اپلیکیشن (بدون Docker-in-Docker).

پرسش‌های متداول

آیا سایت زنده من هنگام راه‌اندازی این کار از دسترس خارج می‌شود؟

خیر. فعال کردن Managed Container Apps در کنار Pull CDN افزایشی است — هرگز سرویس‌دهی دامنه اصلی شما را تغییر نمی‌دهد. سایت شما در تمام مدت از مبدأ فعلی خود سرویس‌دهی می‌کند؛ تنها گام تعویض صریح، تحویل را تغییر می‌دهد.

چطور پیش از تعویض آزمایش کنم؟

هر اپلیکیشن روی زیردامنه ca-*.cdn.com.tr خودش افشا می‌شود (و به‌صورت داخلی با نام سرویس در دسترس است). کل پشته را آنجا اعتبارسنجی کنید. دامنه اصلی تنها هنگام تعویض جابه‌جا می‌شود.

آیا می‌توانم تعویض را بازگردانم؟

بله. مبدأ قدیمی را در حال اجرا نگه دارید؛ اگر پس از تعویض چیزی اشتباه بود، دامنه اصلی را دوباره به آن اشاره دهید. مبدأ قدیمی را تنها زمانی که مطمئن شدید از رده خارج کنید.

کدام‌یک از سرویس‌های من می‌توانند منتقل شوند؟

همه آن‌ها به‌عنوان image‌های کانتینر یا سرویس‌های compose. برای Redis/PostgreSQL/MySQL/NATS از افزونه‌های مدیریت‌شده استفاده کنید. RabbitMQ و Valkey به‌عنوان اپلیکیشن کانتینری اجرا می‌شوند (Valkey با Redis سازگار است، پس افزونه Redis اغلب جایگزین آن می‌شود). Jenkins به‌عنوان یک اپلیکیشن اجرا می‌شود اما نمی‌تواند image را درون کانتینر بسازد (بدون Docker socket / Docker-in-Docker).

آیا به یک پلن ویژه نیاز دارم؟

اجرای چندین اپلیکیشن + نقطه پایانی به یک پلن Enterprise نیاز دارد. پیش از وارد کردن یک فایل compose بزرگ، حق استفاده خود را بررسی کنید.

صفحات مرتبط

مهاجرت Managed Container Apps

ساخت یک اپلیکیشن کانتینری، اعتبارنامه رجیستری، env/secrets، وارد کردن‌ها، jobها، استقرار، وضعیت و لاگ‌ها از صفحات مشتری.

Object Storage و AWS CLI

ساخت باکت‌ها، چرخش کلیدهای دسترسی، اتصال باکت‌ها به اپلیکیشن‌ها و تأیید با نقطه پایانی سازگار با S3.

چه چیزی می‌توانید اجرا کنید — قابلیت‌ها و محدودیت‌ها

یک پلتفرم کانتینری مدیریت‌شده (با Kubernetes در زیرساخت)، نه یک VM یا سرور shell: شما image‌های کانتینر یا یک docker-compose.yml می‌آورید و پلتفرم آن‌ها را اجرا می‌کند، همراه با افزونه‌های مدیریت‌شده Redis/PostgreSQL/MySQL/NATS، والیوم‌های پایا، DNS سرویس داخلی و افشای HTTP(S) از طریق لبه CDN.

ذخیره‌سازی پایا برای یک اپلیکیشن مدیریت‌شده

به یک اپلیکیشن کانتینری یک والیوم پایا بدهید تا داده‌های آن پس از راه‌اندازی مجدد و استقرارهای دوباره باقی بمانند: ذخیره‌سازی را فعال کنید، مسیر mount درون کانتینر و اندازه را تنظیم کنید. یک والیوم به‌ازای هر اپلیکیشن، mount شده در یک مسیر، روی CephFS.