Purge, cache'lemenin diğer yarısı neden
Bir CDN, sitenizi tam olarak içeriği elinde tuttuğu için hızlandırır, ancak aynı davranış bir düzenlemenin cache'lenmiş kopya süresi dolana kadar görünmez kalması anlamına gelir; bu da saatler sürebilir. Purge, kaçış kapısıdır: edge'e belirli nesneleri hemen düşürmesini söyler, böylece bir sonraki istek origin'den taze bir kopya çeker. Güvenilir bir purge olmadan, agresif cache'leme bir yükümlülük haline gelir çünkü hiçbir şeyi uzun süre cache'lemeye cesaret edemezsiniz; onunla birlikte, hız için cömert TTL'ler belirleyebilir ve yine de acil değişiklikleri saniyeler içinde canlıya alabilirsiniz. Bu yüzden purge ve cache aynı aracın ayrı özellikleri değil, iki yarısıdır.
Cerrahi purge'e karşı tam purge
Tek satırlık bir metin düzenlemesinden sonra tüm cache'i temizlemek işe yarar, ancak her ısınmış nesneyi çöpe atar ve edge'in her şeyi yeniden çekmesine zorlar; bu da kısa süreliğine origin yükünü artırır ve ilk ziyaretçileri yavaşlatır. cdn.com.tr, tek bir URL'yi veya bir path setini purge etmenize izin verir; böylece tam olarak neyin değiştiğini invalidate eder, cache'in geri kalanını sıcak bırakırsınız. Genel kural, içerik düzenlemeleri için dar kapsamlı purge yapmak ve tam purge'i global bir stylesheet veya her yerde kullanılan bir template gibi paylaşılan varlıklara dokunan release'ler için ayırmaktır; doğru kapsamı seçmek hem doğruluğu hem de performansı sağlam tutar.
Otomatik pipeline'lar için purge API
Manuel purge, unutana kadar işe yarar; unutulan bir purge, siz düzeltmenin deploy edildiğine yemin ederken kullanıcıların eski bir sayfaya bakması demektir. Purge API, deploy pipeline'ınızın ship etmenin bir parçası olarak invalidation çağırmasına izin vererek insan adımını ortadan kaldırır; böylece bir build tetikleyen bir merge, aynı zamanda o build'in değiştirdiği tam URL'leri de temizleyebilir. Bu, cache'in dadılık yapmanız gereken bir şey olması ile kendi kendine doğru kalan görünmez bir katman olması arasındaki farktır ve günde birkaç kez deploy yapan ekipler için vazgeçilmezdir.
Bir şeyler bozulduğunda canlı log'lar
Bir sayfa hata döndürdüğünde veya bir deploy beklenmedik davrandığında tahmin yürütmek pahalıdır ve tahmin yürütmeyi durdurmanın yolu log akışıdır. Container uygulamalar için cdn.com.tr, stdout ve stderr'i akışa alır; böylece uygulamanın kendi çıktısını neredeyse gerçek zamanlı izleyebilir ve genel bir 500'den çıkarım yapmak yerine gerçek stack trace'i, başarısız sorguyu veya başlangıç hatasını okuyabilirsiniz. Bir release sırasında log görünümünü açık tutmak, kötü bir rollout'u düzeltmenin hâlâ ucuz olduğu ilk saniyelerde yakalamanız anlamına gelir, sonradan kullanıcılardan duymanız yerine.
Durum: gerçekte neyin canlı olduğunu bilmek
Bir sürümü deploy etmiş olmakla o sürümün gerçekten trafik sunması arasında tehlikeli bir boşluk vardır ve status bunu kapatır. Panel; hangi release'in güncel olduğunu, ne zaman deploy edildiğini ve healthcheck'in geçip geçmediğini gösterir; böylece yeşil bir durum, yeni container'ın gerçekten ayağa kalktığının ve istekleri yanıtladığının somut bir onayıdır. Bu, bir rollout'tan hemen sonra en çok önem taşır; çünkü bir build başarılı olabilir, ancak uygulama yine de kötü bir ortam değeri veya eksik bir bağımlılık yüzünden başlamayı başaramayabilir ve bunu hemen ortaya çıkaran şey healthcheck'tir.
Ship etmek ve doğrulamak için tek bir yer
Purge, log ve durumu bir araya getirmenin değeri, tüm deploy-ve-doğrulama döngüsünün araçlara dağılmış olmak yerine tek bir yüzeyde yaşamasıdır. Bir değişiklik gönderirsiniz, etkilenen cache'i purge edersiniz, hatalar için log'ları izlersiniz ve başarıyı onaylamak için health durumunu okursunuz; hepsi paneli hiç terk etmeden veya üç farklı dashboard'u eşleştirmeden. Sık üretim değişikliği yapan ekipler için bu birleştirme, siteyi işletmeyi endişeli değil kontrollü hissettiren şeydir; çünkü bir deploy'dan sonra sorduğunuz her sorunun cevabı tam orada bulunur.
Adım adım nasıl kurulur
Purge kontrollerini bulun
Panelde domain'inizi veya uygulamanızı açın ve cache/purge bölümüne gidin. Burada tek bir URL'yi, bir grup path'i veya zone'un tüm cache'ini purge edebilirsiniz. Tek URL purge, değişen bir sayfa için cerrahi bir seçenektir; tam purge ise site genelinde bir release için kaba bir araçtır.
Her içerik değişikliğinden sonra purge yapın
Bir sayfayı düzenlediğinizde, bir görseli değiştirdiğinizde veya bir deploy gönderdiğinizde, etkilenen URL'leri purge edin; böylece edge, TTL sona erene kadar cache'lenmiş sürümü sunmak yerine bir sonraki istekte taze kopyalar çeker. Ziyaretçilerin hiçbir zaman dünün içeriğini görmemesi için bunu bir alışkanlık haline getirin.
Purge'i pipeline'ınıza bağlayın
CI/CD veya deploy script'inizden invalidation'ı otomatik tetiklemek için purge API'yi kullanın; böylece bir build ship edildiği anda, kimse paneli açmadan ilgili cache girdileri temizlenir. Cache doğruluğunu insan hafızasına güvenmeden korumanın yolu budur.
Uygulama log'larınızı akışa alın
Container uygulamalar için, stdout ve stderr'i neredeyse gerçek zamanlı izlemek üzere logs görünümünü açın. Bir istek başarısız olduğunda veya bir deploy beklenmedik davrandığında gerçek hatayı gördüğünüz yer log akışıdır; bu yüzden bir release sırasında ve hemen sonrasında açık tutun.
Deploy ve health durumunu okuyun
Hangi release'in canlı olduğunu, ne zaman deploy edildiğini ve healthcheck'in geçip geçmediğini onaylamak için status görünümünü kontrol edin. Bir rollout sonrası yeşil bir health durumu, yeni sürümün yalnızca yüklenmiş değil, gerçekten trafik sunduğunun işaretidir.
Bunu bir rutine dönüştürün
Sabit bir deploy-sonrası döngü benimseyin: ship et, purge et, log'ları izle, health'i onayla. Her seferinde aynı kısa kontrol listesini takip etmek, deploy'ları bir kumardan kontrollü, gözlemlenebilir bir operasyona dönüştüren şeydir.
Örnek senaryolar
Bir geliştirici yeni CSS ve JavaScript gönderir, bu belirli varlık URL'lerini pipeline'dan purge eder ve ziyaretçilerin uzun bir TTL altında tutulan cache'lenmiş sürümler yerine hemen yeni build'i yüklediğini doğrular.
Bir rollout hatalar döndürdükten sonra ekip uygulamanın canlı log'larını izler, başlangıç trace'inde eksik bir ortam değişkeni fark eder, düzeltir, yeniden deploy eder ve toparlanmayı doğrulamak için healthcheck'in yeşile döndüğünü izler.
Bir editör yayınlanmış bir makaledeki gerçek hatasını düzeltir, o tek URL'yi purge eder ve düzeltilmiş sayfa cache'in kendiliğinden süresinin dolmasını beklemeden saniyeler içinde canlıya çıkar.
Sıkça sorulan sorular
Bir purge ne kadar hızlı etkili olur?
Purge, hedeflenen nesneleri geçersiz olarak işaretler; böylece bir sonraki istek onları cache'ten sunulmak yerine origin'den taze olarak çeker. Pratikte değişiklik saniyeler içinde etkili olur; bu yüzden purge, TTL'nin bitmesini beklemek yerine acil düzeltmeler için doğru araçtır.
Her şeyi mi yoksa yalnızca değişen URL'leri mi purge etmeliyim?
Mümkün olduğunda dar kapsamlı purge yapın. Tek bir URL'yi veya küçük bir path setini temizlemek, tam olarak neyin değiştiğini yenilerken cache'in geri kalanını sıcak tutar; böylece bir origin trafiği patlamasından kaçınırsınız. Tam purge'i, tüm site genelinde kullanılan paylaşılan varlıkları değiştiren release'ler için ayırın.
Purge'leri deploy pipeline'ımdan otomatik tetikleyebilir miyim?
Evet. Purge API, CI/CD veya deploy script'inizin ship etmenin bir parçası olarak invalidation çağırmasına izin verir; böylece bir build'in değiştirdiği URL'lerin cache'i, kimsenin paneli açmasına gerek kalmadan deploy edildiği anda otomatik olarak temizlenir.
Container log'ları bana neyi gösterir?
Uygulamanızın kendi stdout ve stderr'ini neredeyse gerçek zamanlı olarak akışa alırlar; böylece hata stack trace'leri, başarısız sorgular ve başlangıç mesajları gibi gerçek çalışma zamanı çıktısını görürsünüz. Bu, bir hatanın gerçek nedenini okumak ile genel bir hata sayfasından tahmin yürütmek arasındaki farktır.
Bir deploy'un gerçekten başarılı olduğunu nasıl anlarım?
Status görünümünü okuyun. Hangi release'in güncel olduğunu, ne zaman deploy edildiğini ve healthcheck'in geçip geçmediğini gösterir. Bir build tamamlanabilir ama uygulama yine de başlamayı başaramayabilir; bu yüzden geçen bir healthcheck, yeni sürümün gerçekten trafik sunduğunun somut onayıdır.
Bir deploy'dan sonra önerilen sıra nedir?
Değişikliği ship edin, ziyaretçilerin yeni sürümü alması için etkilenen cache'i purge edin, başlangıç sırasında herhangi bir hata için canlı log'ları izleyin ve son olarak healthcheck'in yeşil olduğunu onaylayın. Her seferinde aynı kısa döngüyü çalıştırmak, deploy'ları gözlemlenebilir ve düşük riskli tutar.