مشکل: یک image کارآمد یک سرویس در حال اجرا نیست
build شدن تمیز یک API به یک image از نوع container، ۲۰ درصد آسان است؛ رساندن آن به تولید ۸۰ درصد دیگر است. بهطور سنتی این یعنی اجاره یک VM، نصب یک runtime، پیکربندی یک reverse proxy، گرفتن و تمدید گواهیهای TLS، باز کردن port های درست، افزودن یک process manager تا اپلیکیشن روی crash دوباره راه بیفتد، سیمکشی جمعآوری لاگ، و نگهبانی در برابر مهاجمانی که جعبه را ظرف ساعتها پس از آنلاین شدن مییابند. هر یک از آن گامها کار زیرساخت بیثمری است که هیچ ربطی به کار واقعی API شما ندارد، و هرکدام جایی است که امنیت یا قابلیت اطمینان را بهطور نامحسوس اشتباه انجام دهید. Container Apps وجود دارد تا آن کل چکلیست را در چند فیلد جمع کند.
cdn.com.tr چگونه آن را حل میکند: container های مدیریتشده پشت edge
به پلتفرم یک image، یک port و یک healthcheck میدهید، و آن container را اجرا میکند، ترافیک را از طریق edge به آن مسیریابی میکند و آن را زنده نگه میدارد. TLS توسط Auto SSL رسیدگی میشود، نقطه ورود عمومی بهجای container خام همان مسیر edge است، و WAF ترافیک مخرب را پیش از رسیدن به سرویس شما فیلتر میکند. پیکربندی بهعنوان متغیرهای محیطی و secret های تزریقشده در زمان اجرا میآید، مقیاسدهی یک تعداد replica است که تنظیم میکنید، و لاگها و وضعیت در پنل نمایان میشوند. نتیجه این است که تنها چیزی که مسئول آن هستید image اپلیکیشن شماست؛ نگرانیهای سرور، proxy، گواهی و فایروال توسط پلتفرم جذب میشوند.
healthcheck ها: تور ایمنی deploy
healthcheck همان چیزی است که یک deploy را از یک امید به یک عملیات کنترلشده تبدیل میکند. وقتی یک نسخه جدید push میکنید، پلتفرم container را شروع و endpoint سلامت شما را نظرسنجی میکند، و تنها وقتی آن endpoint سلامت را گزارش دهد ترافیک را به instance جدید مسیریابی میکند. یک build که هنگام بوت crash میکند، نمیتواند به دیتابیس خود برسد، یا یک secret لازم را ندارد، در check شکست میخورد و در چرخش قرار نمیگیرد، بنابراین یک deploy بد در rollout گرفته میشود نه توسط کاربران شما. به همین دلیل healthcheck باید آمادگی واقعی را راستیآزمایی کند — قابلدسترس بودن وابستگیها، حضور پیکربندی — نه اینکه صرفاً بیقیدوشرط 200 برگرداند. یک healthcheck معنادار تفاوت میان deploy های مجدد ایمن و قطعیهای بیصداست.
محیط در برابر secret ها: پیکربندی بدون نشت
API ها به پیکربندی نیاز دارند — URL های دیتابیس، کلیدهای شخصثالث، feature flag ها — و راه اشتباه برای تأمین آن، پختن آن در image یا commit کردن آن به مخزن است، جایی که برای همیشه در لایهها و تاریخچه زندگی میکند. پلتفرم متغیرهای محیطی ساده را از secret ها جدا میکند: تنظیمات غیرحساس بهعنوان محیط وارد میشوند، در حالی که password ها، توکنها و کلیدهای API بهعنوان secret ذخیره و در زمان اجرا با کلید تزریق میشوند، هرگز بازتاب داده یا در build شما نوشته نمیشوند. این یعنی همان image میتواند با پیکربندی متفاوت میان محیطها جابهجا شود، اعتبارنامههای شما بیرون از version control میمانند، و چرخاندن یک secret یک اقدام پلتفرم است نه یک تقلای build-و-deploy مجدد.
مقیاسدهی، لاگها و حلقه عملیاتی
پس از اینکه API زنده شد، اجرای آن بهجای مدیریت سرور، مسئله چند کنترل است. یک پلن منابع انتخاب و تعیین میکنید چند replica اجرا شود، برای یک راهاندازی یا یک جهش ترافیک بالا مقیاس میدهید و پس از آن پایین میآورید. لاگها در پنل پخش میشوند تا بتوانید یک درخواست را ردیابی کنید، یک 500 را عیبیابی کنید، یا تأیید کنید یک deploy واقعاً انجام شد، و وضعیت به شما نشان میدهد آیا سرویس سالم است و آخرین بار کی restart شده. هر deploy مجدد از همان دروازه healthcheck میگذرد، بنابراین ارسال یک build جدید یک اقدام تکرارپذیر و قابلمشاهده است — image را push میکنید، تماشا میکنید که check موفق میشود، و در لاگها تأیید میکنید، بدون آنکه هرگز به چیزی SSH بزنید.
سیمکشی ذخیرهسازی و داده
بیشتر API ها جایی برای نگه داشتن وضعیت نیاز دارند، و سرویس برای آن بهتمیزی با بقیه پلتفرم جور درمیآید. میتوانید یک bucket از نوع Object Storage را به container بهعنوان متغیرهای محیطی bind کنید تا رسانه یا اسناد را مستقیماً بخواند و بنویسد، و میتوانید یک دیتابیس مدیریتشده یا Redis متصل کنید تا سرویس بدون آنکه شما هم آنها را اداره کنید ماندگاری و caching داشته باشد. چون اینها از طریق پلتفرم متصل و بهعنوان پیکربندی تزریقشده تحویل میشوند، API یک image بدونوضعیت میماند که میتوان آزادانه آن را مقیاس و دوباره deploy کرد در حالی که دادهاش در سرویسهای مدیریتشده کنارش زندگی میکند.
راهاندازی گامبهگام
به image خود اشاره کنید
در پنل یک Container App بسازید و به image از پیش ساختهشده خود (برای مثال myorg/api:1.4) از یک registry عمومی یا خصوصی ارجاع دهید. برای image های خصوصی، یک اعتبارنامه registry را یکبار اضافه کنید تا پلتفرم بتواند آن را pull کند. port ای را که API شما روی آن گوش میدهد تنظیم کنید تا edge بداند ترافیک را به کجا بفرستد.
healthcheck را تعریف کنید
به اپلیکیشن یک مسیر healthcheck مانند /health یا /ready بدهید که تنها وقتی سرویس واقعاً قادر به ارائه است 200 برمیگرداند. این همان چیزی است که پلتفرم برای تصمیم درباره سالم بودن یک deploy جدید پیش از دریافت ترافیک استفاده میکند، بنابراین آن را طوری بسازید که چیزهایی را که واقعاً مهماند، مانند اتصال دیتابیس، بررسی کند.
محیط و secret ها را تنظیم کنید
پیکربندی غیرحساس را بهعنوان متغیرهای محیطی و مقادیر حساس — کلیدهای API، password های دیتابیس، توکنها — را بهعنوان secret اضافه کنید، تا در زمان اجرا تزریق شوند بهجای پخته شدن در image یا commit شدن به مخزن شما. مقادیر secret بهصورت امن ذخیره و با کلید ارجاع داده میشوند، نه بازتاب داده.
deploy کنید و healthcheck را تماشا کنید
deploy را از پنل یا با cdnctl راه بیندازید. container شروع میشود، healthcheck نظرسنجی میشود، و سرویس تنها وقتی موفق شود بهعنوان آماده علامت میخورد — و تنها آنگاه در چرخش قرار میگیرد — بنابراین یک build خراب بیصدا ترافیک نمیگیرد.
یک دامنه با Auto SSL و WAF متصل کنید
سرویس را در معرض دید بگذارید تا یک URL رایگان name.cdn.com.tr با HTTPS خودکار بگیرید، یا دامنه خودتان را متصل و بگذارید Auto SSL گواهی را صادر کند. WAF را فعال کنید تا API پشت فیلترینگ edge بنشیند، و container از نوع origin تنها از طریق آن مسیر edge در دسترس باشد.
مقیاس دهید و مشاهده کنید
پلن منابع و تعداد replica را برای باری که انتظار دارید تنظیم کنید، و از لاگها و وضعیت برای تماشای deploy ها، restart ها و رفتار زمان اجرا استفاده کنید. deploy های مجدد همان مسیر دروازهبندیشده با healthcheck را دنبال میکنند، بنابراین push یک نسخه جدید یک عملیات روتین و قابلمشاهده است.
نمونه سناریوها
یک API از نوع JSON از image خود پشت یک دامنه با Auto SSL و WAF منتشر میشود و به فرانتاند یک endpoint پایدار و امن HTTPS میدهد بدون هیچ سروری برای نگهداری.
یک گیرنده webhook، پردازشگر تصویر یا سرویس احراز هویت بهصورت مجزا با مقیاسدهی و secret های خودش اجرا میشود، مستقل از هر چیز دیگر deploy و دوباره deploy میگردد.
یک تیم محصول یک container را از یک image برچسبدار بالا میآورد تا یک URL قابلاشتراک HTTPS برای یک دمو بگیرد، سپس آن را برمیچیند یا با پیش رفتن build دوباره deploy میکند.
پرسشهای پرتکرار
آیا پلتفرم image مرا میسازد یا من یکی میآورم؟
شما یک image از پیش ساختهشده از یک registry میآورید. Container Apps، image ای را که فراهم میکنید اجرا و مسیریابی میکند؛ اگر خصوصی است، یک اعتبارنامه registry را یکبار اضافه میکنید تا پلتفرم بتواند آن را در حین deploy، pull کند.
اگر deploy جدید من خراب باشد چه اتفاقی میافتد؟
در healthcheck شکست میخورد و در چرخش قرار نمیگیرد، بنابراین ترافیک همچنان به نسخه کارآمد میرود. یک container که هنگام بوت crash میکند یا نمیتواند به وابستگیهای خود برسد، در rollout گرفته میشود نه اینکه به کاربران شما خطا ارائه دهد.
چگونه کلیدهای API و password های دیتابیس را از کدم بیرون نگه دارم؟
آنها را بهعنوان secret ذخیره کنید، که در زمان اجرا با کلید به container تزریق میشوند و هرگز در image پخته یا به مخزن شما commit نمیشوند. تنظیمات غیرحساس بهعنوان متغیرهای محیطی ساده وارد میشوند، بنابراین همان image در محیطهای مختلف با پیکربندی متفاوت اجرا میشود.
آیا API من میتواند به یک دیتابیس یا bucket از نوع Object Storage برسد؟
بله. میتوانید یک bucket از نوع Object Storage را به container بهعنوان متغیرهای محیطی bind کنید و یک دیتابیس مدیریتشده یا Redis متصل کنید، تا سرویس ذخیرهسازی، ماندگاری و caching داشته باشد در حالی که یک image بدونوضعیت و قابلdeploy مجدد میماند.
چگونه یک جهش ترافیک را رسیدگی کنم؟
تعداد replica و در صورت نیاز پلن منابع اپلیکیشن را بالا ببرید. چون ترافیک از طریق edge وارد میشود و container ها پشت آن مینشینند، تعداد instance ها را برای تطبیق با بار مقیاس میدهید و پس از آن پایین میآورید.
آیا میتوانم بهجای پنل از خط فرمان deploy کنم؟
بله. cdnctl همان عملیات container را از ترمینال شما پیش میبرد — deploy، deploy مجدد، مقیاسدهی و بازرسی — بنابراین میتوانید deploy ها را اسکریپت کنید یا آنها را از CI اجرا کنید در حالی که همان رفتار دروازهبندیشده با healthcheck مانند پنل را میگیرید.