پرسش واقعی، قیمت نیست
مقایسهٔ فاکتور یک VPS با اشتراک یک پلتفرم، پاسخ پرسش اشتباهی است. هر گزینهای میتواند کانتینر شما را اجرا کند؛ آنچه فرق میکند این است که پس از نخستین استقرار، چقدر از توجه شما را مدام طلب میکند.
یک کانتینر در production به یک دامنه و گواهیای که خودش تمدید شود نیاز دارد، به راهی برای restart وقتی crash میکند، به جایی که logها بروند، به داستانی برای بهروزرسانی بدون قطعی، و به دیتابیسی که بکاپ گرفته شود. هیچکدام کار Docker نیست. آنچه واقعاً میانش انتخاب میکنید این است که چه کسی اینها را برعهده میگیرد — و مقایسهٔ صادقانه ساعتهای شما را قیمتگذاری میکند، نه فقط سرور را.
گزینهٔ ۱ — یک VPS که خودتان مدیریت میکنید
یک ماشین مجازی اجاره کنید، Docker را نصب کنید، کانتینر خود را اجرا کنید. مستقیمترین مسیر است و واقعاً هم کار میکند، با دسترسی کامل root و بدون هیچ لایهٔ انتزاعی میان شما و ماشین.
بعد کار همیشگی شروع میشود: بهروزرسانیهای امنیتی سیستمعامل، یک reverse proxy جلویش، گواهیهایی که باید تمدید شوند، یک سیاست restart برای وقتی کانتینر ساعت چهار صبح میمیرد، دیسکی که با logها و imageهایی که کسی prune نکرده پر میشود، و بکاپهایی که خودتان پیکربندی میکنید و — که مهمتر است — تستشان میکنید. یک deploy اسکریپت خودتان است و zero-downtime چیزی است که خودتان باید بسازید.
این را وقتی انتخاب کنید که root میخواهید، وقتی دارید یاد میگیرید قطعات چطور کنار هم جا میافتند، یا وقتی از قبل سرور اجرا میکنید و یکی بیشتر تفاوتی نمیکند. وقتی محصول شما همان اپلیکیشن است و نه زیرساخت زیرش، از آن پرهیز کنید.
گزینهٔ ۲ — Kubernetes
Kubernetes مسائل واقعیای را حل میکند: سرویسهای متعدد، rolling deployها، خودترمیمی، autoscaling. اگر دهها سرویس را در یک تیم اداره میکنید، پیچیدگیاش را حق خودش کرده است.
پایینتر از آن مقیاس، نسبت وارونه میشود. یک cluster، ارتقاهایش، ingress آن، گواهیهایش و YAML آن را نگه میدارید تا مشتی کانتینر را اجرا کنید — و خود cluster تبدیل به سیستمی میشود که تخصص خودش را میخواهد. Kubernetes مدیریتشده بخشی از این را برمیدارد، اما نه وزن مفهومیاش را.
وقتی انتخابش کنید که مقیاس یا تیم شما از قبل آن را طلب میکند. به این دلیل انتخابش نکنید که شرکتهای جدی از آن استفاده میکنند؛ جدیبودن در تطبیق ابزار با اندازهٔ مسئله است.
گزینهٔ ۳ — یک پلتفرم کانتینر مدیریتشده
اینجا کانتینر را تحویل میدهید و پلتفرم اجرایش میکند: یک دامنه با HTTPS خودکار، restartها، logها، یک rollout که پشت healthcheck کنترل میشود، و Postgres، Redis یا ذخیرهسازی سازگار با S3 بهصورت مدیریتشده که هر وقت لازم داشتید متصل میشوند.
در cdn.com.tr یک deploy کانتینر جدید را راه میاندازد، منتظر میماند تا مسیر healthcheck شما اعلام آمادگی کند، بعد ترافیک را جابهجا میکند و کانتینر قدیمی را بازنشسته میکند — پس یک build خراب هرگز سرویس را آفلاین نمیکند، چون ترافیک بهسادگی روی نسخهای میماند که هنوز کار میکند. edge شبکه CDN جلویش مینشیند، همراه با WAF و محافظت DDoS.
معامله واقعی است و گفتنش لازم: نه root روی هاست، نه نصب پکیج در سطح سیستمعامل، و دسترسی عمومی بهجای پورتهای دلخواه TCP از طریق HTTP(S) است. اگر اپلیکیشن شما به چیزی نیاز دارد که پلتفرم در اختیار نمیگذارد، پاسخ صادقانه یک VPS است.
سه راه ورود، بسته به آنچه دارید
مسیر درست بستگی دارد image شما از کجا میآید.
اگر از قبل imageها را build و به یک registry push میکنید، از Container Apps استفاده کنید: مرجع image و port را به آن بدهید و مستقر میشود. هیچ چیز دیگری در pipeline شما عوض نمیشود.
اگر push-to-deploy از سورس میخواهید، از GitHub Deploy استفاده کنید. گام build را برای شما انجام میدهد — Dockerfile شما در یک builder ایزوله build میشود و به registry خصوصی ما push میشود، پس به هیچ حساب registry از خودتان نیاز ندارید. روی برنچ خود push کنید و نسخهٔ جدید پشت healthcheck منتشر میشود.
اگر اپ شما چند سرویس است، از Docker Compose Instant Deploy استفاده کنید. سرویسهایی که بخش `build:` دارند از Dockerfile خودشان build میشوند؛ سرویسهایی که به یک `image:` عمومی ارجاع میدهند (دیتابیسها، cacheها، صفها) بهعنوان add-on یا اپ مدیریتشده سیمکشی میشوند. buildهای multi-stage، `target:` و `build.args` رعایت میشوند. پیش از ساختهشدن هر چیزی، پلن را پیشنمایش کنید و بعد اعمالش کنید.
پیشنمایش اینکه یک فایل compose به چه چیزی تبدیل میشود، و بعد اعمال آن
# see the plan first — nothing is created
cdnctl container compose preview --account <uuid> --file docker-compose.yml
# apply it when the plan looks right
cdnctl container compose apply --account <uuid> --file docker-compose.ymlپیش از تعهد چه چیزی را بررسی کنید
از هر راهی که بروید، پرسشهای ارزشمند یکی است. یک deploy چگونه منتشر میشود — آیا یک build شکستخورده سایت را پایین میآورد یا ترافیک روی آخرین نسخهٔ سالم میماند؟ logها کجا میروند و آیا میتوانید بدون SSH بخوانیدشان؟ بر سر دادههای شما چه میآید: دیتابیس مدیریتشده و بکاپگرفتهشده است یا کانتینری روی دیسکی است که خودتان مسئولش هستید؟ میتوانید بیرون بیایید — آیا image شما قابلحمل است یا شما را در چیزی اختصاصی بازنویسی کردهاند؟
همین پرسش آخر همانی است که آدمها از آن میگذرند و بعد پشیمان میشوند. یک image داکر که از Dockerfile خودتان build شده ذاتاً قابلحمل است: روی یک VPS، روی Kubernetes و روی یک پلتفرم مدیریتشده یکسان اجرا میشود. همینطور نگهداشتنش همان چیزی است که انتخاب شما را برگشتپذیر میکند.
پرسشهای پرتکرار
آیا باید خودم image را build کنم؟
فقط اگر بخواهید. Container Apps یک image از پیش buildشده را که به یک registry push میکنید مستقر میکند. GitHub Deploy و Docker Compose Instant Deploy از Dockerfile شما در یک builder ایزوله build میکنند و به registry خصوصی ما push میکنند، پس به هیچ حساب registry نیاز ندارید.
میتوانم اینجا یک دیتابیس را داخل کانتینر اجرا کنم؟
میتوانید، اما برای هر چیزی که برایتان مهم است بهجایش از add-onهای مدیریتشدهٔ Postgres یا Redis استفاده کنید — آنها برای شما اداره و بکاپ گرفته میشوند. یک دیتابیس در یک کانتینر ساده یعنی دیسکی که شخصاً مسئولش هستید، و همین بخشی است که بعداً درد میشود.
اگر اپ من به SSH یا یک پکیج سیستمی سفارشی نیاز داشته باشد چه؟
پکیجهای سیستمی را در Dockerfile خود بگذارید — دقیقاً کاری که imageها برایش هستند. اگر به SSH روی هاست، نصبهای سطح سیستمعامل در زمان اجرا، یا پورتهای خام عمومی TCP نیاز دارید، پلتفرم مدیریتشده گزینهٔ درستی نیست و پاسخ صادقانه یک VPS است.
آیا یک پلتفرم مدیریتشده از سرور خودم کندتر است؟
ذاتاً نه، و در عمل معمولاً سریعتر هم درمیآید چون edge جهانی جلویش cache میکند. خود کانتینر روی همان نوع سختافزار اجرا میشود؛ آنچه از دست میدهید دسترسی root است، نه سرعت.