Loading...

یادگیری / کانتینرها و پلتفرم

یک کانتینر Docker را روی CDN مستقر کنید و از edge ارائه دهید

برای گذاشتن یک کانتینر Docker روی اینترنت مجبور نیستید سرور خودتان را اجرا کنید. روی پلتفرم مدیریت‌شدهٔ cdn.com.tr، image داکر خود را به‌عنوان یک اپ کانتینر مدیریت‌شده مستقر می‌کنید و از طریق edge شبکه CDN ارائه می‌شود — با یک دامنه اختصاصی، HTTPS خودکار، و cache و WAF جلویش. این‌جا می‌بینید «Docker روی CDN» یعنی چه، چگونه یک کانتینر Docker را از پنل یا CLI به‌نام cdnctl مستقر کنید، چگونه یک استک کامل docker-compose را با add-onها اجرا کنید و push-to-deploy از Git چگونه کار می‌کند.

Updated

یک کانتینر Docker را روی CDN مستقر کنید و از edge ارائه دهید

منظور از «Docker روی CDN» چیست

یک CDN در شکل کلاسیک خود جلوی وب‌سایتی می‌نشیند که از قبل اجرا می‌کنید: edge سرور origin استاتیک شما را cache می‌کند و سرعتش می‌بخشد. این همان حالت Pull است و وقتی سروری جایی دارید عالی است. اما اگر آنچه دارید یک image داکر است — یک API بک‌اند، یک وب‌اپ، یک worker — همچنان به یک ماشین نیاز دارید تا آن کانتینر را واقعاً اجرا کند. این همان شکافی است که پلتفرم کانتینر مدیریت‌شده پر می‌کند.

در cdn.com.tr خود image داکر را مستقر می‌کنید. پلتفرم کانتینر شما را به‌عنوان یک اپ کانتینر مدیریت‌شده اجرا می‌کند و آن را پشت edge شبکه CDN قرار می‌دهد، پس همان imageای که روی لپ‌تاپ شما با docker run اجرا می‌شود اکنون روی یک دامنه واقعی با HTTPS خودکار، cache شدن در edge و یک WAF جلویش ارائه می‌شود — بدون اینکه شما یک VM تهیه کنید، Docker نصب کنید، TLS را سیم‌کشی کنید یا یک reverse proxy برپا کنید. شما یک image و یک port می‌آورید؛ پلتفرم اجرا و ارائهٔ جهانی آن را برعهده می‌گیرد. این همان چیزی است که مردم از «Docker روی یک CDN» یا «Docker hosting» به شیوهٔ مدیریت‌شده منظور دارند: کانتینر همان origin است و edge آن را تحویل می‌دهد.

گزینهٔ الف — استقرار از پنل (بدون CLI)

مسیر بدون کد کاملاً در پنل مدیریت cdn.com.tr اجرا می‌شود. زیر CDN Hosting / Platforms، Managed Container را انتخاب کنید و از image خود یک اپ بسازید. آن را به یک registry image و تگ اشاره می‌دهید (مثلاً registry.example.com/acme/app:1.0.0)، پورتی را که کانتینر شما روی آن گوش می‌دهد تنظیم می‌کنید (مثلاً 8080)، و یک مسیر health check اضافه می‌کنید تا پلتفرم بداند کانتینر واقعاً چه زمانی آماده است (یک مسیر HTTP مثل /health، یک بررسی TCP، یا هیچ‌کدام). دامنه اختصاصیای را که می‌خواهید رویش ارائه شود اضافه کنید، و اگر image در یک registry خصوصی زندگی می‌کند، اعتبارنامه‌های registryای را که پیش‌تر ذخیره کرده‌اید متصل کنید.

سپس روی Deploy بزنید. پلتفرم image را می‌کشد، کانتینر را راه‌اندازی می‌کند، منتظر می‌ماند تا health check پاس شود و آن را پشت edge آنلاین می‌کند. از نمای Operations اپ می‌توانید پیشرفت استقرار را ببینید، logها را دنبال کنید، status و revisionها را ببینید و restart یا rollback کنید — همه بدون دست‌زدن به یک ترمینال. این مسیر درست است وقتی می‌خواهید همه‌چیز را به‌صورت بصری ببینید یا یک کانتینر تکی را دستی مستقر می‌کنید.

گزینهٔ ب — CLI به‌نام cdnctl

cdnctl ابزار خط‌فرمان اپراتور برای cdn.com.tr است و همان پلتفرم را هدایت می‌کند. یک‌بار وارد شوید و حساب خود را انتخاب کنید تا هر دستور بداند کجا باید کار کند: cdnctl login --email you@example.com --password ... را اجرا کنید (یا cdnctl configure --endpoint https://cdn.com.tr --token <token> اگر از یک API token استفاده می‌کنید)، سپس cdnctl accounts use <account_uuid>. پیش از نخستین استقرار، cdnctl container preflight --account <uuid> بررسی می‌کند که حساب آماده است.

کانتینر را در دو گام بسازید و مستقر کنید. نخست آن را تعریف کنید: cdnctl container apps create --account <uuid> --name mobile-backend --image registry.example.com/acme/app --tag 1.0.0 --port 8080 --healthcheck /health --healthcheck-type http --domain api.example.com (برای یک image خصوصی --registry-credential <uuid> بیفزایید، و اگر به یک persistent volume نیاز دارد --persistent-mount-path /app/data --persistent-storage-gb 5). سپس آن را بفرستید: cdnctl container apps deploy --account <uuid> --app <app_uuid>. برای گرفتن یک پیش‌نمایش فوری بدون راه‌اندازی DNS، cdnctl container apps expose --account <uuid> --app <app_uuid> یک URL تغییرناپذیر <uid>.cdn.com.tr می‌سازد که همان لحظه می‌توانید به آن سر بزنید.

عملیات روزمره هم همه اینجاست: apps logs --tail 100 برای دنبال‌کردن خروجی، apps status و apps wait --status running --timeout 300 برای بررسی آمادگی، apps restart، apps scale --replicas 0 برای متوقف‌کردن (یا بالابردن مقیاس)، apps show برای دیدن اپ و revisionهایش، apps rollback --revision <uuid> برای بازگشت به یک نسخهٔ شناخته‌شدهٔ سالم، apps diagnose وقتی چیزی درست نیست، و apps update ... --env-json '{"APP_URL":"https://api.example.com"}' برای تغییر پیکربندی. برای imageهای خصوصی، یک‌بار اعتبارنامه را با cdnctl container registry-credentials create --account <uuid> --name docker --registry-url https://index.docker.io/v1/ --username <user> --password <token> بسازید و هنگام ساخت اپ به آن ارجاع دهید.

استک‌های چندسرویسی، add-onها، jobها و داده

اپ‌های واقعی به‌ندرت یک کانتینر تکی هستند. اگر از قبل استک خود را با docker-compose توصیف کرده‌اید، می‌توانید کل آن را مستقر کنید: cdnctl container compose preview --account <uuid> --file docker-compose.yml نشان می‌دهد چه چیزی ساخته خواهد شد، و cdnctl container compose apply --account <uuid> --file docker-compose.yml --yes استک چندسرویسی را مستقر می‌کند. فایل compose شما روی پلتفرم به اپ‌های کانتینر مدیریت‌شده تبدیل می‌شود.

برای قطعاتی که اپ شما به آن‌ها وابسته است، به‌جای اجرای خودتان، managed add-onها را متصل کنید: cdnctl container addons enable-redis، enable-postgres، enable-database یا enable-nats سرویس را تهیه می‌کنند و جزئیات اتصال آن را به‌صورت environment variable به اپ شما تزریق می‌کنند (از --env-prefix برای کنترل نام آن‌ها استفاده کنید). کارهای پس‌زمینه و زمان‌بندی‌شده با jobs پوشش داده می‌شوند: cdnctl container jobs create --account <uuid> --app <app_uuid> --name sync --schedule "*/30 * * * *" --method POST --path "/run" یک job به سبک cron ثبت می‌کند که اپ شما را طبق زمان‌بندی فرا می‌خواند، و jobs run [--wait] آن را دستی اجرا می‌کند. و برای seed کردن state، cdnctl container imports database --file dump.sql.gz یک dump از SQL را بارگذاری می‌کند، درحالی‌که cdnctl container imports files --file data.tar.gz --target-path /app/data فایل‌ها را در یک persistent volume باز می‌کند.

ارائه از طریق edge شبکه CDN

نکتهٔ اجرای کانتینر شما اینجا به‌جای یک VM خام همان چیزی است که جلویش می‌نشیند. پس از استقرار، اپ شما روی دامنه اختصاصیای که متصل کرده‌اید در دسترس است و از طریق edge شبکه CDN ارائه می‌شود. TLS خودکار است — HTTPS می‌گیرید بدون گواهیای که بخرید، نصب کنید یا تمدید کنید — و پاسخ‌های قابل‌cache نزدیک بازدیدکنندگان شما در edge cache می‌شوند، پس کانتینر شما کار کمتری می‌کند و کاربران پاسخ‌های سریع‌تری می‌گیرند. یک WAF جلویش می‌نشیند تا ترافیک مخرب را فیلتر کند و حملات را پیش از رسیدن به کانتینر شما جذب کند.

برای شروع تست به دامنه اختصاصی نیاز ندارید. cdnctl container apps expose (یا همان عمل در پنل) یک URL تغییرناپذیر <uid>.cdn.com.tr به شما می‌دهد که بلافاصله کانتینر در حال اجرای شما را ارائه می‌دهد — ایده‌آل برای یک پیش‌نمایش، یک دمو، یا سیم‌کشی یک کلاینت موبایل به یک بک‌اند پیش از آماده‌شدن DNS. وقتی برای production آماده‌اید، دامنه واقعی خود را به اپ اشاره دهید و به‌جای آن روی همان دامنه ارائه می‌شود، با همان HTTPS خودکار و محافظت edge.

استقرار از Git — CI/CD و promoteهای بدون قطعی

برای یک پروژهٔ در حال اجرا معمولاً نمی‌خواهید هر بار دستور deploy را دستی اجرا کنید. یک مخزن را در پنل متصل کنید و pushها می‌توانند auto-deploy شوند: وقتی push می‌کنید، پلتفرم به‌طور خودکار build و redeploy می‌کند، پس فرستادن یک تغییر فقط یک git push است. این همان مسیر CI/CD برای کانتینرها روی CDN است.

برای امن‌نگه‌داشتن production، استقرارها از یک pipeline staging → production عبور می‌کنند. یک push نخست محیط Staging شما را redeploy می‌کند، جایی که می‌توانید نسخهٔ تازه را روی یک URL پیش‌نمایش بررسی کنید؛ وقتی درست به‌نظر رسید، یک Promote دستی و تکی آن build را فوراً به Production سوییچ می‌کند. چون promote یک سوییچ فوری یک نسخهٔ از قبل build‌شده و از قبل گرم‌شده است، production بدون هیچ قطعیای عوض می‌شود — بدون rebuild، بدون cold start برای بازدیدکنندگان شما. cdnctl همان جریان را از یک pipeline CI برازش می‌دهد: با یک token احراز هویت کنید، سپس اپ را به‌عنوان یک گام build بسازید/مستقر کنید، پس GitHub یا GitLab CI موجود شما هم می‌تواند استقرارها را هدایت کند.

مردم چه چیزی را به‌عنوان کانتینر Docker روی CDN اجرا می‌کنند

APIهای بک‌اند و وب‌اپ‌ها

سرویس Node، Python، Go، PHP یا Java خود را به‌عنوان یک کانتینر مستقر کنید و روی یک دامنه واقعی با HTTPS خودکار و یک WAF جلویش ارائه دهید.

استک‌های docker-compose

فایل docker-compose موجود خود را بیاورید و کل استک چندسرویسی را مستقر کنید، با Redis، Postgres یا NATS مدیریت‌شده متصل‌شده به‌صورت env var.

بک‌اندهای موبایل و اپ

یک بک‌اند بفرستید، یک URL فوری <uid>.cdn.com.tr برای تست کلاینت خود expose کنید، سپس بدون هیچ قطعیای روی دامنه اختصاصی خود به production پروموت کنید.

پرسش‌های پرتکرار دربارهٔ Docker روی CDN

آیا می‌توانم یک کانتینر Docker را روی یک CDN اجرا کنم؟

بله. روی پلتفرم مدیریت‌شدهٔ cdn.com.tr، image داکر خود را به‌عنوان یک اپ کانتینر مدیریت‌شده مستقر می‌کنید و از طریق edge شبکه CDN ارائه می‌شود — با یک دامنه اختصاصی، HTTPS خودکار و cache و WAF جلویش. شما سروری تهیه یا نگه‌داری نمی‌کنید؛ یک image و یک port می‌آورید و پلتفرم آن را اجرا می‌کند.

یک کانتینر Docker را چگونه مستقر کنم — پنل یا خط‌فرمان؟

هر دو همان پلتفرم را هدایت می‌کنند. از پنل مدیریت (CDN Hosting / Platforms → Managed Container) برای ساخت یک اپ از یک image و Deploy کردن به‌صورت بصری استفاده کنید، یا از CLI به‌نام cdnctl: cdnctl container apps create ... سپس cdnctl container apps deploy. CLI در CI/CD هم به‌خوبی جا می‌گیرد.

برای پیش‌نمایش کانتینر خود به دامنه اختصاصی نیاز دارم؟

نه. cdnctl container apps expose را اجرا کنید (یا همان عمل در پنل) و یک URL تغییرناپذیر <uid>.cdn.com.tr می‌گیرید که بلافاصله کانتینر در حال اجرای شما را ارائه می‌دهد — بدون نیاز به راه‌اندازی DNS. دامنه اختصاصی خود را وقتی برای production آماده‌اید متصل کنید.

می‌توانم یک استک کامل docker-compose را مستقر کنم؟

بله. cdnctl container compose preview نشان می‌دهد چه چیزی ساخته خواهد شد و cdnctl container compose apply --file docker-compose.yml --yes استک چندسرویسی را مستقر می‌کند. همچنین می‌توانید managed add-onها — Redis، Postgres یا NATS — را متصل کنید تا جزئیات اتصال آن‌ها به‌صورت environment variable به اپ شما برسد.

استقرار از Git چگونه کار می‌کند و آیا production امن است؟

یک مخزن را متصل کنید و pushها می‌توانند auto-deploy شوند. استقرارها از یک pipeline staging → production عبور می‌کنند: یک push، Staging را redeploy می‌کند، و یک Promote دستی و تکی build را فوراً به Production سوییچ می‌کند. چون promote یک سوییچ فوری یک نسخهٔ از قبل build‌شده است، production بدون هیچ قطعیای عوض می‌شود.