Purge، لاگ‌ها و وضعیت

چرا purge نیمه دیگر cache است

یک CDN دقیقاً به این دلیل سایت شما را سریع می‌کند که محتوا را نگه می‌دارد، اما همین رفتار به این معناست که یک ویرایش تا انقضای نسخه cache‌شده نامرئی می‌ماند، که می‌تواند ساعت‌ها طول بکشد. purge دریچه فرار است: به edge می‌گوید اشیای مشخصی را بی‌درنگ رها کند تا درخواست بعدی نسخه‌ای تازه از origin بکشد. بدون یک purge قابل‌اتکا، cache تهاجمی به یک ریسک تبدیل می‌شود چون جرئت نمی‌کنید چیزی را برای مدت طولانی cache کنید؛ با آن، می‌توانید TTL های سخاوتمندانه برای سرعت تنظیم کنید و همچنان تغییرات فوری را ظرف چند ثانیه زنده کنید. به همین دلیل purge و cache دو نیمه یک ابزار واحدند، نه دو امکان جداگانه.

purge جراحی در برابر کامل

پاک کردن کل cache پس از یک ویرایش یک‌خطی متن جواب می‌دهد، اما هر شیء گرم را دور می‌ریزد و edge را وادار می‌کند همه چیز را دوباره بکشد، که کوتاه‌مدت بار origin را بالا می‌برد و اولین بازدیدکنندگان را کند می‌کند. cdn.com.tr به شما امکان می‌دهد یک URL واحد یا مجموعه‌ای از مسیرها را پاک کنید تا دقیقاً همان چیزی را که تغییر کرده باطل کنید و بقیه cache را گرم بگذارید. قاعده سرانگشتی این است که برای ویرایش محتوا به‌صورت محدود purge کنید و purge کامل را برای انتشارهایی نگه دارید که به دارایی‌های مشترک مانند یک stylesheet سراسری یا یک قالب پُرکاربرد دست می‌زنند، و انتخاب دامنه درست هم درستی و هم کارایی را دست‌نخورده نگه می‌دارد.

purge API برای خطوط خودکار

purge دستی تا وقتی که فراموش نکنید کار می‌کند، و یک purge فراموش‌شده یعنی کاربران به یک صفحه کهنه خیره شده‌اند در حالی که شما قسم می‌خورید اصلاح deploy شده است. purge API گام انسانی را حذف می‌کند با اجازه دادن به خط deploy شما تا باطل‌سازی را به‌عنوان بخشی از انتشار فراخوانی کند، بنابراین یک merge که یک build را راه می‌اندازد می‌تواند دقیقاً همان URLهایی را که آن build تغییر داده پاک کند. این تفاوت میان cache به‌عنوان چیزی است که باید مراقبش باشید و cache به‌عنوان یک لایه نامرئی که خودبه‌خود درست می‌ماند، و برای تیم‌هایی که روزی چند بار deploy می‌کنند ضروری است.

لاگ‌های زنده وقتی چیزی خراب می‌شود

وقتی یک صفحه خطا برمی‌گرداند یا یک deploy درست رفتار نمی‌کند، حدس زدن پرهزینه است و پخش لاگ راهی است برای توقف حدس زدن. برای اپلیکیشن‌های container، cdn.com.tr، stdout و stderr را پخش می‌کند تا بتوانید خروجی خودِ اپلیکیشن را تقریباً بلادرنگ تماشا کنید و stack trace واقعی، کوئری ناموفق یا خطای راه‌اندازی را بخوانید به‌جای استنتاج آن از یک خطای عمومی ۵۰۰. باز نگه داشتن نمای لاگ در حین یک انتشار یعنی یک rollout بد را در چند ثانیه اول می‌گیرید، وقتی اصلاح هنوز ارزان است، به‌جای شنیدن آن از کاربران بعداً.

وضعیت: دانستن اینکه واقعاً چه چیزی زنده است

یک شکاف خطرناک میان deploy کردن یک نسخه و پاسخ‌دهی واقعی آن نسخه به ترافیک وجود دارد، و وضعیت آن را می‌بندد. پنل نشان می‌دهد کدام انتشار جاری است، چه زمانی deploy شده و آیا healthcheck موفق است، بنابراین یک وضعیت سبز تأیید ملموسی است که container جدید بالا آمده و به درخواست‌ها پاسخ می‌دهد. این درست پس از یک rollout بیشترین اهمیت را دارد، وقتی یک build می‌تواند موفق شود اما اپلیکیشن همچنان به‌دلیل یک مقدار محیطی بد یا یک وابستگی گم‌شده در راه‌اندازی ناموفق بماند، و healthcheck همان چیزی است که این را بی‌درنگ آشکار می‌کند.

یک جا برای انتشار و راستی‌آزمایی

ارزش کنار هم گذاشتن purge، لاگ‌ها و وضعیت این است که کل حلقه deploy-و-تأیید روی یک سطح قرار دارد به‌جای پراکنده شدن در چند ابزار. یک تغییر را منتشر می‌کنید، cache متأثر را purge می‌کنید، لاگ‌ها را برای خطا تماشا می‌کنید و وضعیت سلامت را برای تأیید موفقیت می‌خوانید، همه بدون ترک پنل یا هم‌بسته کردن سه داشبورد مختلف. برای تیم‌هایی که تغییرات تولیدی مکرر انجام می‌دهند، همین یکپارچگی است که کار کردن با سایت را کنترل‌شده حس می‌کند نه پُر از دلهره، چون هر پرسشی که پس از یک deploy دارید پاسخش همان‌جاست.

نمونه سناریوها