از یک image تا یک URL عمومی، بدون اجرای سرور
رساندن یک container واحد به اینترنت معمولاً یعنی تأمین یک host، نصب یک runtime از نوع container، سیمکشی یک reverse proxy، گرفتن یک گواهی و باز کردن port های فایروال — کلی کار بیثمر برای یک API. Container Apps این را جمع میکند: به آن یک image و یک port میدهید، و یک URL زنده و امنشده با HTTPS از نوع name.cdn.com.tr بازمیگرداند. نه host ای برای وصله کردن هست، نه nginx ای برای پیکربندی، و نه cron از نوع certbot ای برای مراقبت، چون edge و TLS بخشی از پلتفرماند.
healthcheck ها و rollout های بدون قطعی
یک deploy که container ها را در لحظهای که فرآیند شروع میشود جابهجا میکند، تا وقتی اپلیکیشن هنوز در حال گرم شدن است درخواستها را از دست میدهد. پلتفرم از مسیر healthcheck شما برای تصمیم درباره آمادگی استفاده میکند: در یک deploy جدید، container جدید را بالا میآورد، منتظر میماند تا healthcheck موفق شود، ترافیک را جابهجا میکند و تنها آنگاه container قدیمی را بازنشسته میکند. این یعنی یک image بد که هرگز سالم نمیشود، سرویس را از کار نمیاندازد — نسخه قبلی تا اثبات نسخه جدید همچنان ارائه میدهد.
محیط و secret ها بهدرستی انجامشده
اپلیکیشنهای دوازدهعاملی پیکربندی خود را از محیط میخوانند، و container ها هم فرقی ندارند. تنظیمات ساده بهعنوان متغیرهای محیطی وارد میشوند؛ هر چیز حساس — password های دیتابیس، کلیدهای API شخصثالث، secret های امضا — بهعنوان یک secret وارد میشود که رمزنگاریشده ذخیره و پس از ذخیره تنها با نام کلید نمایش داده میشود، هرگز با مقدار. وقتی object storage یا یک دیتابیس مدیریتشده را متصل میکنید، اعتبارنامههای آنها به همان روش تزریق میشوند، بنابراین هیچ چیز حساسی درون image پخته یا در یک build log چاپ نمیشود.
مقیاسپذیری و پلنهای منابع که با بار واقعی جور درمیآیند
برای هر اپلیکیشن یک پلن منابع (CPU و حافظه) و یک تعداد replica انتخاب میکنید، بنابراین یک ابزار داخلی کمترافیک و یک API عمومی مجبور نیستند همان ردپا را به اشتراک بگذارند. اجرای چند replica همچنین به شما تابآوری میدهد: اگر یک container در حال restart باشد، بقیه همچنان ارائه میدهند. چون rollout ها با healthcheck دروازهبندی میشوند، مقیاسدهی یا deploy یک نسخه جدید لحظهای ایجاد نمیکند که اپلیکیشن در دسترس نباشد.
مسیر edge، Auto SSL و WAF در جلوی API شما
هر اپلیکیشن container در معرض دید از طریق edge شبکه cdn.com.tr در دسترس قرار میگیرد، بنابراین همان محافظتهایی که وبسایتهای شما میگیرند برای API های شما هم اعمال میشوند. Auto SSL گواهی را فراهم و تمدید میکند، WAF ترافیک مخرب و اسکنر را پیش از رسیدن به سرویس شما فیلتر میکند، و میتوانید پاسخهای امن GET را در edge cache کنید تا بار خواندن از container برداشته شود. container از نوع origin شما هرگز مستقیماً توسط عموم آدرسدهی نمیشود — تنها ترافیکی را میگیرد که edge ارسال میکند.
پنل یا cdnctl، و با استک شما جور درمیآید
هر کاری که در پنل میتوانید انجام دهید — deploy، تنظیم env و secret، مقیاسدهی، خواندن لاگها، restart — از طریق ابزار خطفرمان cdnctl نیز در دسترس است، بنابراین عملیات container در اسکریپتها و CI جای میگیرد. Container Apps همچنین مقصد Docker Compose Instant Deploy است: یک فایل compose چندسرویسی در یک apply به چند اپلیکیشن container بهعلاوه افزونههای مدیریتشده تبدیل میشود، که سریعترین راه برای بالا آوردن یک استک موجود است بهجای بازسازی دستی هر سرویس.
راهنمای گامبهگام deploy
یک اپلیکیشن container بسازید
در پنل بخش Container Apps را باز کنید و یک اپلیکیشن از یک image از پیش ساختهشده بسازید، برای مثال myorg/api:1.4 از Docker Hub یا یک registry خصوصی. port ای را که سرویس شما روی آن گوش میدهد تنظیم کنید تا پلتفرم بداند ترافیک را به کجا بفرستد.
یک اعتبارنامه registry خصوصی اضافه کنید (در صورت نیاز)
اگر image خصوصی است، یک نام کاربری و access token برای registry را یکبار زیر Container Apps ← اعتبارنامههای registry اضافه کنید تا پلتفرم بتواند آن را در هر deploy pull کند. image های عمومی این گام را بهکلی رد میکنند.
محیط، secret ها و healthcheck را تنظیم کنید
پیکربندی ساده را بهعنوان متغیرهای محیطی و مقادیر حساس — کلیدهای API، password های دیتابیس، توکنها — را بهعنوان secret اضافه کنید، که رمزنگاریشده ذخیره و هرگز بازتاب داده نمیشوند. یک مسیر healthcheck تعریف کنید تا پلتفرم بداند چه زمانی یک container جدید واقعاً آماده ارائه است، نه فقط راهاندازیشده.
deploy و در معرض دید قرار دهید
اپلیکیشن را deploy کنید، سپس port وب را در معرض دید بگذارید تا یک URL رایگان name.cdn.com.tr با HTTPS خودکار بگیرید، یا دامنه خودتان را متصل کنید. اکنون ترافیک از مسیر edge شبکه cdn.com.tr به container شما جریان مییابد، در حالی که SSL در edge خاتمه مییابد.
مقیاس دهید، لاگها را تماشا کنید و بهروزرسانیها را منتشر کنید
replica ها و یک پلن منابع را برای باری که انتظار دارید تنظیم کنید، لاگها را از پنل برای عیبیابی پخش کنید، و یک tag جدید image را push کنید تا یک rollout بدون قطعی راه بیفتد. ترمینال را ترجیح میدهید؟ cdnctl همان عملیات deploy، مقیاسدهی و لاگ را از shell شما انجام میدهد.
نمونه سناریوها
یک API از نوع Node یا Go از یک image دیپلوی، روی یک دامنه با Auto SSL در معرض دید قرار میگیرد و توسط WAF محافظت میشود، در حالی که پاسخهای امن GET در edge cache میشوند.
یک سرویس واحد با پلن منابع و secret های خودش اجرا میشود، برای تابآوری به چند replica مقیاس مییابد، بدون به اشتراک گذاشتن یک host با بقیه استک.
یک تیم محصول یک محیط یکبارمصرف را از یک tag مربوط به image روی یک URL از نوع name.cdn.com.tr بالا میآورد، سپس پس از پایان بازبینی آن را برمیچیند.
پرسشهای پرتکرار
آیا Container Apps از یک Dockerfile برای من image میسازد؟
خیر — image های از پیش ساختهشده را deploy میکند. شما image را میسازید و به یک registry (Docker Hub یا یک registry خصوصی) push میکنید و ارجاع image و port را به پلتفرم میدهید. اگر push-to-deploy از منبع میخواهید، آن را با GitHub Deploy که گام build را رسیدگی میکند جفت کنید، یا برای یک استک چندسرویسی از Docker Compose Instant Deploy استفاده کنید.
یک deploy بدون قطعی اینجا دقیقاً چگونه کار میکند؟
در یک deploy جدید، پلتفرم container جدید را شروع میکند، منتظر میماند تا مسیر healthcheck شما آمادگی را گزارش دهد، سپس ترافیک را به آن جابهجا و container قدیمی را بازنشسته میکند. اگر container جدید هرگز healthcheck خود را رد نکند، ترافیک روی نسخه قبلی میماند، بنابراین یک build خراب سرویس را از دسترس خارج نمیکند.
آیا secret های من پس از ذخیره قابلمشاهدهاند؟
خیر. secret ها رمزنگاریشده ذخیره و پس از ذخیره تنها با نام کلید نمایش داده میشوند — مقادیر در پنل، در لاگها یا در پیشنمایشها بازتاب داده نمیشوند. این به شما امکان میدهد یک secret را از پنل بچرخانید بدون آنکه به یک screen recording، یک نشست پشتیبانی یا یک build log نشت کند.
آیا container من میتواند به یک دیتابیس مدیریتشده یا object storage دسترسی پیدا کند؟
بله. یک دیتابیس مدیریتشده، Redis یا یک bucket از نوع object storage را به اپلیکیشن bind میکنید، و جزئیات اتصال و access key ها بهعنوان متغیرهای محیطی یا secret تزریق میشوند. container آنها را از محیط خود میخواند، بنابراین اعتبارنامهها هرگز نباید درون image پخته شوند.
چگونه بیش از یک instance اجرا کنم، و چرا باید این کار را بکنم؟
تعداد replica را روی اپلیکیشن تنظیم کنید. چند replica به شما تابآوری میدهد — اگر یکی در حال restart یا ناسالم باشد، بقیه همچنان ارائه میدهند — و به اپلیکیشن امکان میدهند ترافیک همزمان بیشتری را رسیدگی کند. در ترکیب با rollout های دروازهبندیشده با سلامت، مقیاسدهی بازهای ایجاد نمیکند که سرویس در دسترس نباشد.
آیا میتوانم اپلیکیشنهای container را از خط فرمان و CI مدیریت کنم؟
بله. ابزار cdnctl همان عملیات deploy، مقیاسدهی، لاگ، restart و پیکربندی را مانند پنل انجام میدهد، بنابراین میتوانید عملیات container را اسکریپت کنید یا آنها را از یک خط CI بهجای کلیک کردن در UI اجرا کنید. همچنین اینگونه یک import از نوع Docker Compose را از ترمینال پیشنمایش و apply میکنید.