Docker — kararlı siteler için yalıtılmış konteynerler

Konteyner nedir — ve siteniz için neden önemli

Konteyner, uygulamayı ve çalışması için gereken her şeyi — runtime, kütüphaneler, yapılandırma — içeren standartlaştırılmış bir pakettir. Konteyner, sunucunun geri kalanından yalıtılmış çalışır ancak ana makinenin Linux çekirdeğini doğrudan kullanır — uygulama başına ayrı bir işletim sistemi olmadan. 2013'te çıkan Docker bu teknolojiyi erişilebilir bir standarda dönüştürdü; imaj biçimi bugün OCI (Open Container Initiative) olarak standartlaştırılmıştır ve herhangi bir Linux sunucusunda veya bulutta aynı şekilde çalışır.

Klasik benzetme deniz konteyneridir: içinde ne olursa olsun aynı standart biçime sahiptir ve herhangi bir gemiye, trene veya kamyona taşınabilir. Aynı şekilde, sitenizi kuran ve yayınlayan 4buildsite servisleri — editör, FastAPI API'si, render motoru — test sunucusunda da üretim sunucusunda da aynı çalışan standart imajlar içinde paketlenir. Bir site veya mağaza sahibi olarak sizin için bu, öngörülebilirlik demektir: önizlemede gördüğünüz, ziyaretçilerin aldığının tam olarak aynısıdır.

• Konteyner = uygulama + bağımlılıkları, tek bir yalıtılmış pakette
• Standart OCI biçimi — aynı imaj her sunucuda veya bulutta çalışır
• Servis başına ayrı işletim sistemi yok — dakikalar değil, saniyeler içinde başlatma
• 4buildsite'ta konteynerleştirmeyi platform yönetir — siz yalnızca yayımlarsınız

Yalıtım: siteniz komşularına bağımlı değildir

Klasik paylaşımlı hosting'de yüzlerce site aynı sunucuyu, aynı süreçleri ve çoğu zaman aynı PHP kurulumunu paylaşır. Bir komşu ani bir trafik dalgası alırsa veya kötü yazılmış bir betik tüm işlemciyi tüketirse siteniz yavaşlar — “noisy neighbour” (gürültülü komşu) olgusu. 4buildsite sorunu iki yönden ele alır. Birincisi: yayımlanan siteler statik olarak render edilir — onları sunan sunucularda site başına kod (PHP, eklentiler, betikler) çalışmaz; dolayısıyla işlemciyi tüketecek bir komşunun kötü yazılmış betiği yoktur. İkincisi: platform servislerinin her biri kendi konteynerinde, ayrı süreç ve dosyalarla (namespaces aracılığıyla) ve CPU ile bellek sınırı koyma imkânıyla (Linux çekirdeğinin mekanizmaları olan cgroups aracılığıyla) çalışır.

Yalıtım güvenlik için de aynı derecede önemlidir. Paylaşımlı hosting'de ele geçirilmiş bir site, aynı sunucudaki komşu sitelere açılan bir kapıya dönüşebilir. 4buildsite'ta yayımlanan site statik dosyalardan oluşur — eklentiler veya temalar aracılığıyla ele geçirilebilecek kod çalışmaz — veriyi işleyen platform servisleri (siparişler, ödemeler, editör) ise ayrı konteynerlerde durur: dosya sistemi yalıtılmıştır ve olası bir olay ilgili konteynerin içinde kalır.

• Yayımlanan site = statik dosyalar — ele geçirilecek site başına kod yok
• Platform servisleri: konteyner başına ayrı dosya sistemi ve süreçler
• Öngörülebilir davranış: statik sunum, gece saat 3'te de kampanya zirvesinde de aynı

Her yerde aynı sürüm: “bende çalışıyor, canlıda çalışmıyor” yok

Klasik web'de hataların en sık kaynağı, sitenin test edildiği ortam ile canlı çalıştığı sunucu arasındaki farktır: başka bir dil sürümü, eksik başka bir eklenti, başka bir yapılandırma. Bir Docker imajı bu kategorideki sorunların tamamını ortadan kaldırır: imaj, tüm bağımlılıklar sabitlenerek yalnızca bir kez oluşturulur ve tam olarak aynı çıktı hem testte hem üretimde çalışır. “Sunucuda elle yapılandırılmış” diye bir şey yoktur.

Bu, doğrudan kararlılığa dönüşür. panel.4buildsite.net'teki görsel editörde sitenizi değiştirip yayımla'ya bastığınızda ziyaretçilere ulaşan sürüm, her seferinde aynı adımlardan, aynı konteynerleştirilmiş servislerden geçmiştir. Yayından sonra daha az sürpriz, mağazanın çöktüğü daha az gece demektir — bir online mağaza için ise kesintinin her saati kaybedilen sipariş anlamına gelir.

Kesintisiz yayınlar ve önceki sürüme geri dönüş

4buildsite'ta bir yayın, “siteyi durdurup dosyaları kopyalıyor ve umuyoruz” demek değildir. Her yayın, sitenizin canlı olandan ayrı biçimde statik olarak render edilmiş, yeni ve eksiksiz bir sürümünü üretir; ona geçiş atomiktir: tek bir işlemle sunum servisi yeni sürümü sunmaya başlar. Aynı ilke platform servisleri için de geçerlidir: bir konteynerin yeni sürümü eskisinin yanında başlar ve trafiği ancak sağlık kontrollerinden sonra devralır.

Geri dönüş yolu da aynı derecede önemlidir. Sitenin yayımlanmış her sürümü olduğu gibi saklanır; dolayısıyla önceki sürüme dönmek basitçe geri geçiş yapmak demektir — saatler süren bir yedekten geri yükleme değil, basit bir geçiş işlemi. Bir yayın sorun çıkarırsa mağazanız hatalı sürümde takılı kalmaz. Tek dürüst nüans: veriler (siparişler, ürünler, içerik) veritabanında, yayımlanmış sürümlerden ayrı yaşar — bu yüzden site dosyalarından ayrı, kalıcı birimlerde yönetilirler.

• Her yayın = yeni, eksiksiz, atomik olarak değiştirilen bir sürüm
• Geri alma = önceki sürüme geri geçiş
• Satış sezonunun ortasında bile istediğiniz zaman değişiklik yayımlayın

Verimlilik ve maliyetler: aynı parayla daha fazla kapasite

Klasik bir sanal makine, her uygulama için eksiksiz bir işletim sistemi çalıştırır — yalnızca “ambalaj” için harcanan gigabaytlarca bellek ve dakikalarca başlatma süresi. Konteynerler ana makinenin çekirdeğini paylaşır; bu yüzden aynı sunucuya çok daha fazla site sığar ve her biri kendi yalıtımına sahiptir. Bu yoğunluk, 4buildsite'ın abonelikte hosting ve SSL'i site başına ayrı bir altyapı maliyeti olmadan sunabilmesinin nedenidir.

Yayımlanan siteniz için trafiğe göre ölçekleme daha da basittir: statik dosya oldukları için sunulmaları son derece ucuzdur — bir ziyaretçi zirvesi, birbirinin ayağına basan ek süreçler değil, daha fazla sunulan dosya demektir. Saniyeler içinde başlayan konteynerler olan platform servisleri ise gerektiğinde ek örnekler alabilir. Yılın en yoğun günü için kalıcı olarak boyutlandırılmış bir altyapıya değil, öngörülebilir bir aboneliğe ödeme yaparsınız. Bu konteynerleri fiilen nasıl işlettiğimiz — orkestrasyon, proxy, CI/CD, izleme — hakkında Cloud & DevOps sayfasını okuyun.