HTTP/3 (QUIC) Nedir? Nginx ve Cloudflare Üzerinde Etkinleştirme Rehberi

HTTP/3 ve QUIC neden önemli?

Web sitelerinin hızlı yüklenmesi, hem kullanıcı deneyimi hem de SEO açısından belirleyicidir. HTTP/3, Google’ın QUIC taşıma protokolü üzerine inşa edilen en yeni HTTP sürümüdür ve UDP üzerinden çalışır. Bağlantı kurulumu için gereksiz el sıkışmaları ortadan kalkar, paket kaybı durumunda satır sonu tıkanması azalır ve özellikle mobil ile yüksek gecikmeli ağlarda belirgin hız kazanımı sağlar. Bu sayede TTFB düşer, etkileşim metrikleri iyileşir ve Core Web Vitals performansınız olumlu etkilenir.

HTTP/3 vs. HTTP/2: Öne çıkan farklar

HTTP/2 TCP üzerinde çalışırken, HTTP/3 QUIC sayesinde UDP kullanır. Bu mimari fark, bağlantı geçişlerinde (ör. Wi‑Fi’den 4G’ye) ve paket kaybı yaşanan ortamlarda akışların birbirini beklememesini sağlar. Üstelik 0‑RTT oturum yenileme sayesinde tekrar bağlanan kullanıcılar daha az gecikme yaşar. Sonuç olarak, aynı içerik daha akıcı ve daha hızlı sunulur.

Ön gereksinimler ve uyumluluk

HTTP/3 bugün Chrome, Edge, Firefox ve Safari’nin güncel sürümlerinde desteklenir. Sunucu tarafında ise iki kritik gereksinim ortaya çıkar: UDP/443 trafiğinin güvenlik duvarında açık olması ve TLS 1.3 desteği. Ayrıca Nginx gibi web sunucularında HTTP/3 desteği için doğru sürüm ve uygun TLS kitaplığı (OpenSSL’in QUIC destekli bir sürümü, BoringSSL veya quictls) gerekir.

Cloudflare üzerinde HTTP/3’ü etkinleştirme

Cloudflare kullanıyorsanız, HTTP/3 etkinleştirmek birkaç tıklama kadar kolaydır. Cloudflare panelinde alan adınızı seçin, Network sekmesine girin ve HTTP/3 (with QUIC) seçeneğini On konumuna getirin. Cloudflare, ziyaretçilere Alt-Svc başlığı ile HTTP/3’ü ilan eder ve QUIC üzerinden içerik sunmaya başlar. Bu aşamada ek bir sunucu yapılandırması gerekmeyebilir; ancak kaynak sunucunuzun HTTP/2 veya HTTP/1.1 için sağlıklı cevap verdiğinden emin olun.

Nginx’te HTTP/3 (QUIC) kurulum adımları

HTTP/3’ü doğrudan Nginx’te sunmak istiyorsanız, önce HTTP/3 modülü destekli bir Nginx derlemesine ihtiyaç vardır. En güncel mainline Nginx sürümünü kullanın ve derleme sırasında HTTP/3 modülünü etkinleştirin. Ayrıca QUIC destekli bir TLS kütüphanesi (örneğin OpenSSL’in QUIC desteği olan bir sürümü veya BoringSSL/quictls) ile derleme yapmanız gerekir.

Yapılandırma tarafında, site (server) bloğunuzda hem klasik TLS hem de QUIC için dinleme direktifleri ekleyin. Tipik olarak 443 portu için iki dinleme satırı kullanılır: biri listen 443 ssl; diğeri listen 443 quic reuseport;. TLS 1.3’ü açın ve geçerli bir sertifika/anahtar atayın. İstemcilerin HTTP/3’ü kolay keşfetmesi için Alt-Svc başlığı tavsiye edilir; örneğin Alt-Svc: h3=":443"; ma=86400 gibi. Böylece tarayıcılar sonraki isteklerde HTTP/3 yolunu tercih eder.

Konfigürasyon güncellemesinden sonra Nginx’i hatasız yeniden başlatın. Güvenlik duvarında UDP 443’ün gerçekten açık olduğundan emin olun; aksi halde tarayıcılar HTTP/3’e geçemeyip HTTP/2’ye geri döner.

Doğrulama ve test

Hızlı bir kontrol için tarayıcınızın geliştirici araçlarındaki Network panelinde ilgili isteğin Protocol sütununa bakın; h3 görüyorsanız HTTP/3 aktif demektir. Alternatif olarak HTTP/3 destekli bir curl sürümüyle başlıkları sorgulayabilirsiniz: curl --http3 -I https://alanadiniz.com. Dönen yanıtta alt-svc başlığı ve protokolün h3 olduğuna dair işaretler görmelisiniz. Dış doğrulama için çevrimiçi HTTP/3 test araçlarını da kullanabilirsiniz.

Performans ipuçları ve en iyi uygulamalar

HTTP/3 tek başına bir sihirli değnek değildir; ancak iyi bir önbellekleme stratejisi, doğru cache-control başlıkları, Early Hints (103) ve kaynak önceliklendirmesiyle birleştiğinde etkisi katlanır. Resimleri modern formatlara (AVIF/WebP) taşıyın, kritik CSS’i optimize edin ve CDN’inizi edge’de önbelleklemek üzere yapılandırın. Mobil ağlarda daha da iyi sonuç için DNS çözümleme sürelerini kısaltın ve gereksiz üçüncü taraf istekleri budayın.

Sorun giderme: En sık görülen engeller

- UDP kapalı: Birçok güvenlik duvarı varsayılan olarak UDP 443’ü engeller. Kuralı açın ve sağlayıcınızın UDP’yi desteklediğinden emin olun.
- Ortak barındırma kısıtları: Bazı paylaşımlı hosting ortamlarında HTTP/3 henüz sunulmaz. Bu durumda bir CDN üzerinde HTTP/3’ü etkinleştirmek pratik bir ara çözümdür.
- Yanlış TLS kitaplığı: Nginx derlemenizde QUIC destekli bir TLS kitaplığı kullanmadıysanız HTTP/3 aktif olmayacaktır. Sürüm ve yapı bayraklarını gözden geçirin.
- Orta katman proxy’ler: WAF, DDoS koruması veya ek proxy katmanları UDP’yi bozabilir. Trafik zincirindeki her bileşenin HTTP/3 uyumluluğunu doğrulayın.

SEO ve iş etkisi

Daha hızlı bağlantı kurulumu ve paket kaybına dayanıklı aktarım, özellikle mobil kullanıcıların ilk etkileşim süresini düşürür. Bu, LCP ve FID/INP gibi metriklere olumlu yansır, hemen çıkma oranlarını azaltır ve dönüşüm oranlarını artırabilir. Arama motorları doğrudan “HTTP/3 kullanıyor musunuz?” diye puan vermez; fakat hız ve kullanıcı deneyimi sinyalleri arka planda sıralamayı etkiler. Kısacası HTTP/3, teknik borcunuzu azaltan ve yatırımı hızlı geri ödeyen bir yükseltmedir.

Sonuç

HTTP/3 (QUIC), günümüzün değişken ve gürültülü ağ koşullarında web’i daha hızlı ve dayanıklı kılan önemli bir adımdır. Cloudflare gibi CDN’lerle dakikalar içinde aktif edebilir, Nginx üzerinde ise doğru sürüm ve TLS kitaplığıyla uçtan uca kontrol sağlayabilirsiniz. UDP 443’ü açmayı, TLS 1.3’ü etkinleştirmeyi ve Alt-Svc ilanını eklemeyi unutmayın. Doğrulama testlerinden sonra performans metriklerinizi izleyin; çoğu sitede ölçülebilir iyileşme göreceksiniz.

Parolasız Gelecek: WebAuthn Passkey Entegrasyonu ile Güvenli Giriş (Next.js Örneği)

Parolasız Gelecek: WebAuthn Passkey Entegrasyonu ile Güvenli Giriş (Next.js Örneği)

Parolalar, yıllardır sızıntıların ve kimlik avı saldırılarının baş aktörü oldu. Passkey (WebAuthn + FIDO2) yaklaşımı, biyometrik doğrulama (Touch ID, Windows Hello, Android Biometrics) veya donanım anahtarı ile tek dokunuşla güvenli oturum açmayı mümkün kılar. Bu yazıda, güncel tarayıcılar ve işletim sistemleriyle uyumlu passkey altyapısını nasıl kuracağınızı, geliştirici bakışıyla adım adım anlatıyorum. Örnek teknoloji olarak Next.js kullanacağız ancak anlatım, API uç noktaları olan her yığını kapsar.

Passkey Nedir? Passkey, kullanıcının cihazında güvenli bir şekilde saklanan asimetrik anahtar çifti ile çalışır. Sunucu yalnızca genel anahtarı tutar, gizli anahtar cihazdan çıkmaz. Oturum açma akışı; origin, RP ID (Relying Party ID) ve kullanıcı doğrulaması gibi bağlamlarla sınırlandırıldığı için kimlik avı ve kimlik bilgisi doldurma saldırılarına karşı son derece dirençlidir.

Neden Passkey?

- Kimlik avına dayanıklı: İmzalama süreci etki alanına (origin) bağlıdır, sahte sitelerde işe yaramaz.
- Kullanıcı deneyimi: Tek dokunuş, yüz tanıma ya da PIN ile saniyeler içinde giriş.
- Çoklu cihaz desteği: iCloud Keychain, Google Password Manager gibi kasalarla cihazlar arası senkronizasyon.

Mimari Özet ve Gereksinimler

Sunucu tarafında challenge üretir, saklar ve istemciye gönderirsiniz. İstemci bu challenge ile cihazdaki authenticator üzerinden kayıt (registration) veya giriş (assertion) akışını tamamlar; dönen yanıtı sunucuya iletir ve sunucu WebAuthn kurallarına göre doğrular. Sunucunuzda TLS zorunlu olmalı (localhost geliştirmenin istisnasıdır). RP ID genellikle alan adınızın köküdür (ör. example.com). Veritabanında kullanıcı, keyId, publicKey, alg, signCount gibi alanlar saklanır.

Kayıt (Registration) Akışı Adımları

1) Kullanıcı e-postasını veya benzersiz kimliğini alıp sunucunuza gönderin. Sunucu, PublicKeyCredentialCreationOptions üretir: challenge (base64url), rp.id, rp.name, user.id, user.name, pubKeyAlgo listesi (örn. -7 ES256, -257 RS256), authenticatorSelection (residentKey, userVerification) ve timeout gibi alanları içerir.

2) İstemci tarafında navigator.credentials.create() ile native WebAuthn API’sini çağırın. Dönen yanıt, attestationObject ve clientDataJSON içerir.

3) Bu verileri base64url ile sunucuya POST edin. Sunucu, attestation’ı doğrular; origin, challenge eşleşmesi, RP ID hash kontrolü ve sertifika zinciri doğrulaması yapar. Başarılıysa kullanıcıya ait publicKey, keyId ve signCount’ı veritabanına kaydeder.

Giriş (Authentication) Akışı Adımları

1) Sunucu, PublicKeyCredentialRequestOptions üretir: challenge, rpId, allowCredentials (kayıtlı anahtarlar) ve userVerification.

2) İstemci, navigator.credentials.get() çağırır ve authenticator’dan imzalı assertion alır: authenticatorData, clientDataJSON ve signature.

3) Sunucu; challenge, origin, rpIdHash doğrular; publicKey ile imzayı denetler ve signCount güncellenir. Ardından oturum açma token’ı veya session başlatılır.

Next.js ile Minimal Örnek Mantığı

- /api/webauthn/register/options: Kullanıcı kimliği ile çağrılır, creationOptions döner ve server-side Session’a challenge yazılır.
- /api/webauthn/register/verify: İstemciden gelen attestation yanıtını doğrular ve anahtarı kaydeder.
- /api/webauthn/login/options: Kullanıcının kayıtlı keyId’lerine göre requestOptions üretir, challenge’ı saklar.
- /api/webauthn/login/verify: Assertion’ı doğrular, session veya JWT üretir.

Doğrulama adımları için community tarafından desteklenen simplewebauthn gibi kütüphaneler süreci kolaylaştırır. İstemci tarafında base64url dönüştürmeleri (ArrayBuffer ⇄ base64url) dikkat ister; hataların çoğu burada çıkar.

En İyi Uygulamalar ve Güvenlik İpuçları

- Origin ve RP ID tutarlılığı: www ile çıplak alan adı karışıklığı yaşamamak için tek tercih belirleyin.
- User Verification: “required” seçeneği güvenliği yükseltir (biyometrik/PIN zorunlu).
- Resident Key (Discoverable Credentials): Kullanıcı adı sormadan doğrudan passkey ile giriş akışı sağlar; UX’i iyileştirir.
- Attestation politikası: Genellikle “none” yeterlidir; donanım güveni gerekiyorsa “indirect” veya belirli CA’lar ile doğrulayın.
- signCount ve Clone Detection: signCount düşerse potansiyel klon tespitine karşı hesabı işaretleyin.
- Yedekleme: Kullanıcıya birden fazla passkey ekletin ve acil kurtarma için e-posta linki veya destek kanalı sunun (parolaya geri dönüş önermeyin).

Sık Karşılaşılan Hatalar

- TypeError: create() ya da get() için beklenen ArrayBuffer yerine base64 string gönderildi. Çözüm: Base64url’ü Uint8Array’e çevirin.
- DOMException NotAllowedError: Kullanıcı iptal etti veya sayfa güvenli değil. HTTPS kullanın ve UI’de açık bilgi verin.
- InvalidStateError: Aynı kullanıcı için aynı authenticator’da ikinci kez kayıt deneniyor. allowCredentials stratejisini gözden geçirin.

SEO ve Üretim Notları

Passkey, WebAuthn ve FIDO2 anahtar kelimelerini sayfadaki başlık ve açıklamalara ekleyin. Schema.org Person ve WebSite şemaları ile login sayfasını işaretlemek, arama motorlarına daha net sinyaller verir. Üretimde HSTS etkinleştirin, doğru CORS politikası tanımlayın ve CSRF koruması kullanın. Reverse proxy arkasında çalışıyorsanız X-Forwarded-Proto başlığının doğruluğunu garanti edin; aksi halde origin eşleşmeleri başarısız olur.

Sonuç

Passkey entegrasyonu, modern web uygulamalarında güvenliği yükseltirken kullanıcı deneyimini ciddi ölçüde iyileştirir. Next.js veya benzeri bir yığınla, birkaç API uç noktası ve iyi kurgulanmış bir doğrulama katmanı ile parolasız girişe geçebilirsiniz. Küçük bir POC ile başlayın, kayıt ve giriş akışlarını uçtan uca test edin, ardından çoklu cihaz ve kurtarma senaryolarını ekleyerek üretime taşıyın. Parolasız gelecek, bugün erişilebilir durumda.

Web Uygulamana Passkey (WebAuthn) Ekleme: Node.js ile Şifresiz Giriş Rehberi 2025

Giriş

Şifresiz kimlik doğrulama, son yılların en önemli güvenlik dönüşümlerinden biri. Passkey (FIDO2/WebAuthn) sayesinde kullanıcılar, karmaşık şifrelerle uğraşmadan biyometri, güvenli donanım anahtarları veya cihaz kilidi ile giriş yapabiliyor. Bu rehberde, modern bir web uygulamasına Node.js ve tarayıcı WebAuthn API kullanarak passkey ekleme sürecini adım adım anlatıyorum. Odak noktamız: kolay kurulum, sağlam güvenlik ve güncel tarayıcı desteği.

Ön Koşullar

- Alan adınız ve HTTPS etkin (localhost için https://localhost da çalışır, ancak gerçek kullanıcılar için zorunlu HTTPS gereklidir).
- Node.js 18+ (WebCrypto ve fetch desteği için önerilir).
- Basit bir kullanıcı veritabanı (PostgreSQL, MongoDB ya da SQLite).
- Sunucu tarafında WebAuthn doğrulaması için bir kütüphane (örneğin simplewebauthn).
- RP ID (Relying Party ID) olarak genellikle kök alan adınız: example.com. Origin ise https://app.example.com gibi tam kaynak adresidir.

Mimari ve Akış

WebAuthn iki ana akıştan oluşur: Kayıt (Registration) ve Giriş (Authentication). Her ikisi de sunucunun ürettiği rastgele bir challenge değeriyle başlar.

1) Kayıt: Sunucu kullanıcıyı tanımlar, PublicKeyCredentialCreationOptions oluşturur ve challenge döner. Tarayıcı navigator.credentials.create() ile kullanıcıdan attestation üretir. Sunucu attestation’ı doğrular, credentialId ve publicKey gibi özet bilgileri veritabanına kaydeder.

2) Giriş: Sunucu PublicKeyCredentialRequestOptions döner. Tarayıcı navigator.credentials.get() ile assertion (imzalı kanıt) üretir. Sunucu imzayı ve sayaç değerini doğrular, oturumu açar.

Frontend: Kayıt Akışı

Kullanıcı giriş yaptıktan (veya e-posta doğruladıktan) sonra passkey kaydı başlatın. İstemci tarafında tipik istek:

const regOpts = await fetch('/webauthn/register/options').then(r => r.json());
const credential = await navigator.credentials.create({ publicKey: regOpts });
await fetch('/webauthn/register/verify', { method: 'POST', body: JSON.stringify(credential) });

SEO açısından önemli noktalar: “passkey kaydı”, “WebAuthn tarayıcı API”, “şifresiz kimlik doğrulama” gibi anahtar kelimeleri akışa doğal yerleştirin.

Backend: Kayıt Doğrulama

Sunucuda challenge değerini kullanıcıya özel ve tek kullanımlık olarak üretin. @simplewebauthn/server kullanıyorsanız generateRegistrationOptions ile seçenekleri üretir, verifyRegistrationResponse ile attestation doğrularsınız. Doğrulama sonrası şu alanları saklayın:

- credentialId: Kimlik.
- publicKey: İmza doğrulaması için gereken anahtar.
- signCount: Yeniden oynatma saldırılarına karşı sayaç.
- transports ve aaguid gibi meta bilgiler.

Frontend: Giriş (Authentication) Akışı

Kullanıcı giriş sayfasına geldiğinde, eğer passkey kayıtlıysa “Tek tıkla şifresiz giriş” sunabilirsiniz:

const authOpts = await fetch('/webauthn/auth/options?username=ali').then(r => r.json());
const assertion = await navigator.credentials.get({ publicKey: authOpts });
await fetch('/webauthn/auth/verify', { method: 'POST', body: JSON.stringify(assertion) });

Chrome’un Conditional UI özelliğiyle, kullanıcı adı alanına odaklanıldığında passkey önerisi otomatik çıkar. Bunun için mediation: 'conditional' kullanın ve sayfada autocomplete="username" bulunan bir alan bulundurun.

Güvenlik ve En İyi Uygulamalar

- Origin ve rpId kesin eşleşmeli. Ters proxy (Cloudflare, Nginx) arkası dağıtıma dikkat edin.
- Challenge benzersiz ve kısa ömürlü olsun; kullanıldıktan sonra silin.
- userVerification değerini tehdit modelinize göre belirleyin: required (yüksek güvenlik) veya preferred (daha iyi uyumluluk).
- residentKey (discoverable credentials) ile kullanıcı adı girmeden giriş deneyimi sağlayabilirsiniz. Bunun için residentKey: 'required' ve authenticatorSelection.requireResidentKey = true.
- Çoklu cihaz senkronizasyonu (iCloud Keychain, Google Password Manager) sayesinde passkey’ler cihazlar arasında taşınabilir; ancak kurumsal ortamda donanım güvenlik anahtarlarını (YubiKey vb.) zorunlu kılmak isteyebilirsiniz.

Test ve Hata Ayıklama

Chrome DevTools > More Tools > Virtual Authenticator ile fiziksel cihaz olmadan test yapabilirsiniz. Buradan platform/harici anahtar seçebilir, kullanıcı doğrulamasını simüle edebilirsiniz. Sık görülen hatalar: “Invalid RP ID” (alan adınız uyuşmuyor), “DOMException: The operation is insecure” (HTTPS yok), “Challenge mismatch” (eski veya farklı kullanıcıya ait challenge).

Veri Modeli ve Uyum

Bir kullanıcı birden fazla passkey’e sahip olabilir. Veritabanında users, credentials şeklinde ayrıştırın. Girişte birden çok allowCredentials döndürebilir veya discoverable credential ile boş gönderip tarayıcının seçmesini izleyebilirsiniz. KV veya bellek içi önbellek ile challenge yönetimini hızlandırın. KV kullansanız bile kalıcılık için veritabanına yedekleyin.

Dağıtım İpuçları

Sunucunuz HTTP/2 veya HTTP/3 arkasındaysa, Origin başlığının ve CF-Connecting-IP / X-Forwarded-Proto gibi başlıkların framework’ünüz tarafından doğru işlendiğinden emin olun. Serverless (Vercel, Cloudflare Workers) üzerinde de WebAuthn rahatlıkla çalışır; sadece rpId ve origin sabit ve tutarlı olmalı.

Sonuç

Passkey (WebAuthn) ile şifresiz kimlik doğrulama, hem güvenliği hem kullanıcı deneyimini ciddi biçimde iyileştiriyor. Node.js ve WebAuthn API sayesinde birkaç uç noktayı doğru kurgulayarak dakikalar içinde prototip çıkabilir, Conditional UI ile tek dokunuşla giriş deneyimi sunabilirsiniz. Doğru RP ID, benzersiz challenge yönetimi ve kapsamlı doğrulama kontrolleriyle, 2025’in güvenlik standartlarına uygun modern bir “şifresiz giriş” altyapısını bugün projelerinize ekleyin.

Tarayıcıda Yüksek Performanslı Görüntü İşleme: WebGPU ve WGSL ile Adım Adım Başlangıç Rehberi

WebGPU Nedir ve Neden Önemli?

WebGPU, tarayıcıda düşük seviyeli GPU erişimi sağlayan modern bir web standardıdır. WebGL’in yerini hedefleyen bu API, yalnızca çizim için değil, genel amaçlı hesaplama (compute) iş yükleri için de GPU gücünü kullanmanızı mümkün kılar. Bu sayede yüksek çözünürlüklü görüntü filtreleri, gerçek zamanlı video işleme veya makine öğrenmesi çıkarımı gibi ağır işleri tarayıcıda akıcı biçimde gerçekleştirebilirsiniz. Bu rehberde, WebGPU ve WGSL (WebGPU Shading Language) kullanarak basit bir görüntü filtresini nasıl kurgulayacağınızı, performans ve uyumluluk detaylarıyla anlatıyorum.

Önkoşullar ve Uyumluluk

WebGPU, Chrome 113+ ve Edge’de varsayılan olarak etkin, Safari’de 17+ sürümlerde geniş ölçüde destekleniyor. Firefox tarafında Nightly sürümünde bayrakla test edilebiliyor. Geliştirme sırasında sayfanızın HTTPS üzerinden servis edilmesi önerilir; yerelde localhost istisna kabul edilir. Uygulama başlangıcında if ('gpu' in navigator) ile özellik tespiti yaparak destek yoksa zarif bir geri dönüş (örneğin Canvas 2D veya WebGL) uygulayın.

Temel Akış: Adaptör, Cihaz ve Bağlam

İlk adımda navigator.gpu.requestAdapter() ile bir adaptör talep edilir; ardından adapter.requestDevice() ile GPU cihazı oluşturulur. Görüntü çıktınız bir <canvas> üzerindeyse, canvas.getContext('webgpu') çağrısı ile bir bağlam alınır ve uygun formatla (genellikle navigator.gpu.getPreferredCanvasFormat()) yapılandırılır. En iyi verim için cihaz ve bağlamı tek sefer oluşturup tüm etkileşimlerde yeniden kullanın.

Veri Temsili: Buffer ve Texture Seçimleri

Görüntü işleme söz konusu olduğunda veriyi çoğunlukla GPUTexture olarak tutmak gerekir. Statik resimleri ImageBitmap üzerinden yükleyip copyExternalImageToTexture ile GPU tarafına taşıyabilirsiniz. Filtre uygulanacak hedef için storage izinli bir kaplama (örneğin rgba8unorm formatında) tanımlayın. Parametreler (örneğin kernel boyutu, yoğunluk) için küçük bir GPUBuffer yeterli olacaktır. Farklı geçişlerde (compute vs render) aynı texture’ı hem storage hem texture-binding haklarıyla oluşturmayı planlayın.

WGSL ile Basit Bir Filtre Tasarlama

WGSL, WebGPU’nun yerel gölgelendirici dilidir. Örnek olarak gri tonlama filtresi düşünelim: Her piksel için RGB bileşenlerinin ağırlıklı ortalamasını alıp aynı değeri tüm kanallara yazarsınız. Compute yaklaşımında, bir @compute shader ile iş parçacıklarını 2B çalışma gruplarına böler, giriş kaplamasından örnek alır ve çıktıyı storage kaplamaya yazarsınız. Performans için @workgroup_size(8, 8) veya ekran kartınıza uygun başka bir boyut seçip test edin; farklı boyutlar, cihaz ve çözünürlüğe bağlı olarak ciddi fark yaratabilir.

Render Pass mı, Compute Pass mı?

Basit bir tonlama veya tek dokunuşlu efektlerde fragment shader’lı bir render pass yeterli olabilir; bir ekran dolgu üçgeni veya dörtgen ile giriş dokuyu örnekleyip sonuç doğrudan ekrana çıkarılır. Çok adımlı bulanıklaştırma (örneğin Gaussian blur), kenar algılama veya konvolüsyon temelli filtrelerde compute pass genellikle daha esnek ve performanslıdır. İki yaklaşımı da prototiplemek ve profil ile kıyaslamak iyi bir pratiktir.

Komut Akışı ve Kaynak Yönetimi

Her karede yeni bir komut kodlayıcı (commandEncoder) oluşturur, gerekli geçişleri kaydedip device.queue.submit() ile çalıştırırsınız. Maliyetli işlemler: tekrar tekrar buffer/texture oluşturmak, çok sayıda küçük submit yapmak ve gereksiz mapAsync çağrılarıdır. Bunları en aza indirin. Bind group’ları ve pipeline’ları mümkün olduğunca önceden oluşturup yeniden kullanın, yalnızca parametre değiştiğinde güncelleyin.

Performans İpuçları

- Yüksek çözünürlükte çalışmak yerine, görüntüyü ölçekli (örneğin 0.75x) işlemeyi deneyin ve sonuçta tekrar ölçekleyin; çoğu filtrede görsel kalite farkı az, hız kazancı yüksektir.

- Uygunsa rgba8unorm gibi 8 bit formatları tercih edin. Yarı hassas (16 bit float) gereksinimi yoksa daha hafif formatlar bellek bant genişliğini azaltır.

- Zaman ölçümü için CPU tarafında performance.now() kullanmak başlangıç için yeterli; daha ileri düzeyde cihazınız destekliyorsa timestamp-query özelliğiyle GPU süresi ölçebilirsiniz.

- Dizüstü bilgisayarlarda entegre ve ayrık GPU arasında fark büyük olabilir. requestAdapter sırasında powerPreference: 'high-performance' ipucunu verip sahada A/B testleri yapın.

Hata Ayıklama ve Geliştirici Deneyimi

WGSL hata mesajları başta göz korkutabilir. Shader’ları küçük, tek amaçlı fonksiyonlara bölmek ve her adımı ayrı çalıştırıp görselleştirmek (örneğin ara sonuçları ekrana basmak) sorun tespitini kolaylaştırır. Chrome’da chrome://gpu sayfası ve konsol uyarıları donanım/driver durumunu anlamaya yardımcı olur. Ayrıca pipeline oluştururken cihaz özelliklerini ve format desteklerini sorgulayıp koşullu yollar izlemek (örn. device.features) saha stabilitesini artırır.

Güvenlik ve Üretim Hazırlığı

WebGPU, tasarımı gereği güvenli; ancak yüksek frekansta veri aktarımı ve CORS kısıtları gibi web’in temel dinamikleri hala geçerli. Harici görsel yüklerken CORS başlıklarını doğru ayarlayın, kullanıcı verilerini işliyorsanız istemci tarafı GPU hesaplamalarının gizlilik etkilerini göz önünde bulundurun. Üretimde, hatalı cihazları belirlemek için basit bir “öz tanılama” ekranı (desteklenen formatlar, maksimum texture boyutu, başarısız pipeline sayısı) değerli geri bildirim sağlar.

Adım Adım Özet

1) Özellik tespiti yapın ve zarif bir geri dönüş belirleyin. 2) Adaptör ve cihazı oluşturun, canvas bağlamını yapılandırın. 3) Giriş görüntüsünü texture’a kopyalayın, çıktı için storage texture hazırlayın. 4) WGSL ile filtre shader’ını yazın (compute veya fragment). 5) Bind group/pipeline oluşturun, komut akışını kodlayın. 6) Performans ölçüp darboğazları azaltın. 7) Uyumluluk, hata ayıklama ve güvenlik kontrollerini ekleyin.

Sonuç

WebGPU, tarayıcıda görüntü işleme projelerini profesyonel sınıfa taşıyor. Doğru veri temsilini seçip WGSL ile minimal, okunabilir shader’lar yazdığınızda 4K çözünürlükte bile akıcı sonuçlar elde edebilirsiniz. İlk uygulamada basit bir gri tonlama veya kutu bulanıklaştırma ile başlayın; ardından çok geçişli Gaussian, kenar algılama ve renk uzayı dönüştürme gibi filtrelere genişletin. Elde edeceğiniz hız kazanımı ve taşınabilirlik, modern web uygulamalarınız için oyunu değiştirecek.

Docker Compose ile Yerel LLM Kurulumu: Ollama ve Open WebUI (Llama 3.1 8B Rehberi)

Özet ve Amaç

Yerel büyük dil modeli (LLM) çalıştırmak artık sadece veri bilimi ekiplerinin değil, geliştiricilerin ve meraklı kullanıcıların da gündeminde. Bu rehberde, Docker Compose kullanarak Ollama ve Open WebUI ile bilgisayarınızda Llama 3.1 8B modelini nasıl çalıştıracağınızı adım adım anlatıyorum. Kurulum tamamen yerel olduğu için gizlilik avantajı sağlar, gecikme süresini düşürür ve internet erişimi olmadan üretken yapay zeka deneyimi yaşatır.

Gereksinimler

- İşletim sistemi: Linux, macOS veya Windows (Windows için WSL2 önerilir).
- Donanım: En az 16 GB RAM önerilir. GPU şart değil; olsa da performans artar. NVIDIA GPU hızlandırması için Linux + NVIDIA Container Toolkit gerekir.
- Yazılım: Docker ve Docker Compose (Docker Desktop içerir).
- İnternet: İlk model indirme için gerekli.

Adım 1: Docker’ı Hazırlayın

Docker yüklü değilse Docker Desktop’ı kurun. Kurulum sonrası aşağıdaki komutlarla sürümü doğrulayın:
docker --version
docker compose version
Her iki komut da sürüm döndürüyorsa hazırsınız.

Adım 2: Proje Klasörü ve Compose Dosyası

Boş bir klasör oluşturun ve kök dizine docker-compose.yml dosyasını ekleyin. Aşağıdaki içerik, Ollama ve Open WebUI’yi tek komutla ayağa kaldırır. WebUI, Ollama’yı dahili ağ üzerinden görecek şekilde ayarlanmıştır.

version: "3.9"
services:
  ollama:
    image: ollama/ollama:latest
    container_name: ollama
    ports:
      - "11434:11434"
    volumes:
      - ollama:/root/.ollama
    restart: unless-stopped

  open-webui:
    image: ghcr.io/open-webui/open-webui:latest
    container_name: open-webui
    ports:
      - "3000:8080"
    environment:
      - OLLAMA_BASE_URL=http://ollama:11434
    depends_on:
      - ollama
    volumes:
      - openwebui:/app/backend/data
    restart: unless-stopped

volumes:
  ollama:
  openwebui:

Not: GPU hızlandırması istiyorsanız Linux’ta NVIDIA Container Toolkit kurup Ollama servisini GPU ile çalıştırabilirsiniz. Compose tarafında farklı varyasyonlar olsa da en sorunsuz yol genellikle tek servis için docker run --gpus all ... kullanmaktır. Bu rehber CPU’da sorunsuz çalışan kurulum üzerine odaklanır.

Adım 3: Servisleri Başlatın

Proje klasörünüzde şu komutu çalıştırın:
docker compose up -d
İlk kurulumda imajlar indirileceği için biraz zaman alabilir. Durumu görmek için:
docker compose ps ve docker compose logs -f ollama komutlarını kullanabilirsiniz.

Adım 4: Modeli İndirin (Llama 3.1 8B)

Ollama konteynerine girip modeli çekin:
docker exec -it ollama bash
ollama pull llama3.1:8b
İlk indirme birkaç GB olabilir. Sisteminizin RAM ve disk durumuna göre indirip hazırlayacaktır. Daha az bellek kullanan kuantize sürümler için Ollama içindeki etiketleri inceleyebilir veya ollama run llama3.1:8b ile doğrudan test edebilirsiniz.

Adım 5: Open WebUI ile Görsel Arayüz

Tarayıcınızda http://localhost:3000 adresine gidin. İlk açılışta basit bir kayıt formu çıkabilir. Ardından sol alttaki model listesinden llama3.1:8b seçin. Eğer listede görünmüyorsa OLLAMA_BASE_URL ayarının http://ollama:11434 olduğundan ve Ollama servisinin çalışma durumundan emin olun. Alternatif olarak “Add Model” bölümünden ismi elle girebilirsiniz.

Performans İpuçları

- Kuantize modeller: 8B modellerde q4 veya q5 gibi kuantizasyonlar RAM kullanımını ciddi azaltır. Doğruluk bir miktar düşse de masaüstü sistemlerde büyük fark yaratır.
- Bağlam penceresi: Gerekli değilse yüksek context length kullanmayın. Daha az bellek tüketir ve yanıtlar hızlanır.
- Paralellik: Aynı anda çok istek göndermeyin. OLLAMA_NUM_PARALLEL=1 bırakmak çoğu sistemde daha kararlı sonuç verir.

Sorun Giderme

- Port çakışması: 11434 veya 3000 kullanımda ise compose dosyasındaki portları değiştirin (ör. 3001:8080).
- Yavaş ilk yanıt: Model ilk yüklemede belleğe alınır; ikinci istekler daha hızlı olacaktır.
- Bellek yetersiz: Kuantize sürüme geçin veya daha küçük bir model seçin (ör. 7B/8B yerine 3B-4B familyası).
- Güncelleme: docker compose pull ardından docker compose up -d ile imajları güncel tutun.

Güvenlik ve Ağ

Bu kurulum yerel geliştirme içindir. Portları internetten erişilebilir yapmayın. Uzak erişim gerekiyorsa ters proxy ve kimlik doğrulama koyun. Verileriniz container volume’larında tutulur; hassas içerik paylaşıyorsanız yedekleme ve şifreleme politikalarınızı belirleyin.

Sonuç

Dakikalar içinde Docker Compose ile Ollama ve Open WebUI’yi kurup Llama 3.1 8B gibi güncel bir LLM’i yerelde çalıştırabilirsiniz. Bu yaklaşım, gizlilik, kontrol ve düşük gecikme avantajları sunar. İhtiyaçlarınıza göre kuantize modellerle bellek kullanımını düşürüp verimi artırabilir, ileride GPU desteği ekleyerek daha hızlı sonuçlar alabilirsiniz. Yerel LLM ile prototipleme, dahili araç geliştirme ve offline kullanım senaryoları çok daha erişilebilir hale geliyor.

Kubernetes’te GitOps: Argo CD ile Sıfırdan Kurulum, Yapılandırma ve En İyi Uygulamalar

GitOps Nedir ve Neden Argo CD?

GitOps, uygulama ve altyapı durumunu tek gerçek kaynak olarak Git deposunda tutup teslimatı otomatikleştiren bir yaklaşım. Kubernetes dünyasında bu modelin en pratik karşılığı Argo CD. Argo CD, Git’teki deklaratif manifestleri izler, kümeye uygular ve sapmaları sürekli olarak düzeltir. Bu sayede manuel kubectl komutları azalır, güvenlik artar ve geri dönüş (rollback) işlemleri kolaylaşır. Bu yazıda Argo CD’yi sıfırdan kurup ilk “Application” nesnemizi oluşturacak, ardından pratik ipuçları ve sorun giderme önerileriyle süreci üretim standartlarına yaklaştıracağız.

Önkoşullar

Başlamadan önce aşağıdaki araçlara ihtiyacınız olacak: Kubernetes kümesi (Minikube, Kind veya bulut), kubectl (1.25+), Helm (3.x) ve örnek bir Git deposu (GitHub/GitLab). Lokal bir deneme için Minikube idealdir: minikube start. Kümede cluster-admin yetkinizin olduğundan emin olun.

Argo CD Kurulumu (Helm ile)

Helm kullanarak Argo CD’yi kurmak, yapılandırmayı sürdürmek ve güncellemeleri yönetmek için en esnek yollardan biri. Aşağıdaki adımları izleyin:

1) Argo repo’yu ekleyin:
helm repo add argo https://argoproj.github.io/argo-helm
helm repo update

2) Namespace oluşturup yükleyin:
kubectl create namespace argocd
helm install argocd argo/argo-cd -n argocd

3) Arayüze erişim: Hızlı denemeler için port yönlendirme yapabilirsiniz:
kubectl port-forward svc/argocd-server -n argocd 8080:443
Arayüz: https://localhost:8080

4) İlk parola: Varsayılan kullanıcı admin’dir. Parolayı alın:
kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d; echo

İlk Uygulamanızı (Application) Tanımlayın

Argo CD’nin kalbi Application CRD’sidir. Git deposunu, hedef namespace’i ve senkronizasyon politikasını burada tanımlarsınız. Basit bir NGINX dağıtımı için örnek bir Application yaratabilirsiniz. Aşağıdaki içeriği app-nginx.yaml olarak kaydedip uygulayın:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: demo-nginx
  namespace: argocd
spec:
  project: default
  source:
   repoURL: https://github.com/kullanici/manifestler.git
   targetRevision: main
   path: k8s/nginx
  destination:
   server: https://kubernetes.default.svc
   namespace: demo
  syncPolicy:
   automated:
    prune: true
    selfHeal: true

Uygulamak için: kubectl apply -f app-nginx.yaml. Ardından Argo CD arayüzünde “demo-nginx” uygulamasını göreceksiniz. Automated sync sayesinde Git’e her push’ta küme otomatik güncellenecektir. “prune: true” ile Git’te çıkarılan kaynaklar kümeden de temizlenir; “selfHeal: true” ise drift (sapma) olduğunda durumu geri alır.

CLI ile Yönetim (Opsiyonel ama Önerilir)

Argo CD CLI, betiklenebilir ve hızlı yönetim için idealdir. Kurulum: macOS için brew install argocd. Giriş:
argocd login localhost:8080 --username admin --password <parola> --insecure
Uygulama oluşturma örneği:
argocd app create demo-nginx --repo https://github.com/kullanici/manifestler.git --path k8s/nginx --dest-server https://kubernetes.default.svc --dest-namespace demo --sync-policy automated --self-heal --auto-prune

Depo Yapısı ve Manifest Stratejileri

Üretimde depo düzeni, sürdürülebilirliğin anahtarıdır. Sıklıkla app-of-apps paterni tercih edilir: tek bir “root” uygulama, alt uygulamaları referans eder. Ortam ayrımı için Kustomize overlay’leri (dev/stage/prod) veya Helm chart’ları kullanın. “Config” ile “kod”u ayırın; hassas verileri Sealed Secrets veya External Secrets Operator ile yönetin.

En İyi Uygulamalar

- Şube stratejisi: Prod için korumalı branch kullanın; korumalı gözden geçirme (PR) olmadan birleşim yapmayın.
- RBAC ve SSO: Argo CD’yi OIDC/SAML ile kimlik sağlayıcınıza bağlayın; takım ve proje bazlı yetki verin.
- Sadece Git yazar: Manuel kubectl ile müdahaleyi sınırlayın; drift yaratır. Operasyonlar Git üzerinden ilerlesin.
- Health checks: Özel CRD’ler için sağlık kuralları tanımlayın; bekleme ve time-out eşiklerini ayarlayın.
- Namespace izolasyonu: Her ekip/ürün için ayrık namespace ve proje kullanın.
- Kaynak kotası ve limitler: Pod crash-loop ve aşırı kaynak kullanımını böyle önleyin.
- Audit ve izleme: Argo CD Event’lerini ve Kubernetes denetim izlerini toplayın; Prometheus/Grafana ve OpenTelemetry ile görünürlük sağlayın.

Yaygın Sorunlar ve Çözüm İpuçları

- OutOfSync ama Apply olmuyor: RBAC, mutating webhook veya admission policy engelliyor olabilir. kubectl describe ile olayları inceleyin.
- Image pull hatası: Registry kimlik bilgilerini Secret olarak tanımlayıp ServiceAccount’a bağlayın; repo başvurularını güncelleyin.
- Helm values uyuşmazlığı: Her ortam için ayrı values dosyası kullanın; Argo CD’de spec.source.helm.valueFiles ile belirtin.
- Finalizer takılması: Silinemeyen kaynaklarda finalizer’ları kaldırmadan önce bağımlılıkları temizleyin; Argo CD’nin “prune” davranışını kontrol edin.
- Sync dalgası (sync wave): Kaynak sırala(niyet)ması için argocd.argoproj.io/sync-wave anotasyonunu kullanın; CRD’ler CR’lardan önce uygulanmalı.

Güvenlik ve Güncelleme

Argo CD’yi düzenli olarak güncelleyin: helm upgrade argocd argo/argo-cd -n argocd --version <hedef>. Admin varsayılan parolasını kurulumdan sonra hemen değiştirin, mümkünse SSO zorunlu hale getirin. Arayüzü doğrudan internete açmak yerine Ingress + WAF arkasında ve mTLS/oidc ile koruyun.

Sonuç

GitOps ile operasyonel borç azalır, dağıtım tekrarlanabilirliği artar ve denetlenebilirlik kazanırsınız. Argo CD, Kubernetes üzerinde bu yaklaşımı benimsemek için olgun, topluluk tarafından desteklenen bir araç. İlk kurulumdan sonra depo yapınızı sağlamlaştırın, otomasyonu politikalarla çerçeveleyin ve her değişikliği Git üstünden yürütün. Böylece hem geliştirici deneyimi hem de üretim güvenilirliği belirgin şekilde iyileşir.

Docker Buildx ile Çok Mimarili İmaj Oluşturma ve GitHub Actions ile Otomatik Yayınlama (2025 Rehberi)

Giriş

Apple Silicon (arm64) makineler, Raspberry Pi gibi ARM tabanlı cihazlar ve geleneksel x86_64 sunucuların aynı anda hedeflenmesi artık modern projeler için kaçınılmaz. Çok mimarili (multi-arch) Docker imajları, tek bir etiket altında hem amd64 hem de arm64 varyantlarını barındırarak bu ihtiyacı şık biçimde çözer. Bu rehberde, Docker Buildx ile yerelde çok mimarili imaj üretmeyi ve GitHub Actions üzerinden Docker Hub’a otomatik yayınlamayı adım adım anlatıyorum. Hedefimiz: sürtünmesiz bir CI/CD hattı, hızlı önbellekleme ve güvenilir üretim dağıtımları.

Ön Gereksinimler

Yerel ortamda Docker Engine veya Docker Desktop’ın güncel bir sürümünü (tercihen 24+) kullanın. BuildKit artık varsayılan, ancak gerekirse DOCKER_BUILDKIT=1 ile etkinleştirildiğinden emin olun. Bir Docker Hub hesabı ve GitHub deposu hazırlayın. Reponuzda hassas bilgileri GitHub Secrets ile saklayacağız (DOCKERHUB_USERNAME, DOCKERHUB_TOKEN vb.).

Yerelde Buildx ile Çok Mimarili İmaj Oluşturma

Önce Buildx sürümünü kontrol edin: docker buildx version. Özel bir builder oluşturup devreye alın: docker buildx create --name multi --use. Ardından QEMU emülasyonunu etkinleştirin ki yerel mimariniz dışında da derleme yapabilesiniz: docker run --privileged --rm tonistiigi/binfmt --install all. Builder’ı hazırlayın: docker buildx inspect --bootstrap. Artık çok mimarili derleme komutu hazır: docker buildx build --platform linux/amd64,linux/arm64 -t KULLANICI/IMAJ:1.0 --push . Bu komut Docker Hub’a doğrudan push yapacağından, önce docker login ile oturum açmayı unutmayın.

Dockerfile İpuçları (Mimariden Bağımsız ve Hızlı)

Temel imaj seçimi kritik: Hem amd64 hem arm64 desteği olan resmi imajları tercih edin (ör. node:20-alpine, python:3.12-slim, golang:1.22-alpine). Çok aşamalı (multi-stage) Dockerfile kullanarak build bağımlılıklarını runtime’dan ayırın; bu boyutu küçültür ve güvenliği artırır. Mimariye özel binary indiriyorsanız TARGETARCH veya TARGETOS argümanlarını kullanın. Örnek: ARG TARGETARCH satırından sonra, curl -L https://example.com/bin-$TARGETARCH -o /usr/local/bin/app gibi bir strateji uygulayabilirsiniz. Node.js projelerinde native modüller (ör. Sharp) için build araçlarını sadece builder aşamasında yükleyip, final aşamada minimal tabana geçmek iyi bir pratik.

Örnek Build Komutu ve Hızlı Doğrulama

Yerel denemede aşağıdaki tek satır oldukça pratik çalışır: docker buildx build --platform linux/amd64,linux/arm64 -t KULLANICI/IMAJ:latest --push -f Dockerfile . Yayın sonrası manifesti doğrulamak için: docker buildx imagetools inspect KULLANICI/IMAJ:latest. Çıktıda iki platformu birden görmelisiniz. Ayrıca farklı makinelerde docker pull yaparak gerçek koşullarda test edin (ör. bir M2 Mac ve bir x86_64 bulut sunucusu).

GitHub Actions ile Otomatik Yayınlama (CI/CD)

Depo köküne .github/workflows/docker.yml oluşturun ve şu adımları içeren bir iş akışı kurgulayın: kaynak kodu checkout, QEMU kurulumu, Buildx kurulumu, Docker Hub’a giriş, imaj etiketlerini otomatik üreten metadata, çok mimarili build ve push. Özet akış şöyle olmalı: checkout → setup-qemu → setup-buildx → login → metadata → build-push.

Önerilen ana adımlar: actions/checkout@v4 ile kodu çekin. docker/setup-qemu-action@v3 QEMU’yu kurar. docker/setup-buildx-action@v3 Buildx’i etkinleştirir. docker/login-action@v3 ile Docker Hub’a giriş yapın (secrets kullanın). docker/metadata-action@v5 commit SHA, branch, semver tag’lerden akıllı etiketler üretir. docker/build-push-action@v6 ile platforms: linux/amd64,linux/arm64, push: true parametreleriyle build ve yayın yapın.

Önbellek (cache) çok önemlidir. docker/build-push-action içinde cache-from: type=gha ve cache-to: type=gha,mode=max kullanarak GitHub’ın yerleşik önbelleğini devreye alın. Bu, aynı bağımlılıkları tekrar tekrar derlemeyi önleyerek build süresini ciddi ölçüde azaltır.

Sık Karşılaşılan Sorunlar ve Çözümleri

1) QEMU kaynaklı derleme hataları: setup-qemu-action adımının çalıştığını ve en güncel binfmt’nin kurulduğunu doğrulayın. Gerekirse yerelde tonistiigi/binfmt konteyneriyle tazeleyin.

2) Temel imajda arm64 desteği yok: Kullanılan base image’ın manifestini kontrol edin veya alternatif bir resmi imaja geçin (-alpine sürümleri genellikle çok mimarili gelir).

3) Native modül derleme sorunları: Build aşamasında gerekli paketleri (ör. build-base, python3, libvips-dev) kurup final aşamada temizleyin. Node projelerinde npm ci --omit=dev ve npm rebuild --arch=$TARGETARCH gibi çözümler işe yarar.

4) Büyük imaj boyutu: Multi-stage yapı, --chown ile katman optimizasyonu, gereksiz dosyaları .dockerignore ile hariç tutma ve distroless/slim tabanlar boyutu ciddi şekilde düşürür.

Performans ve Güvenlik İpuçları

- CI’da cache’i etkin kullanın; bağımlılıkların hash’lenmesi ve doğru katmanlama build’i hızlandırır. - Tek bir manifest altında birden çok mimari barındırmak, çekme (pull) sırasında istemcinin doğru varyantı otomatik seçmesini sağlar; bu da kullanıcı deneyimini iyileştirir. - Minimum yetkili kullanıcı oluşturun (USER node gibi) ve kök kullanıcıyla çalışmaktan kaçının. - Sürüm etiketlerine özen gösterin: latest yanında 1.2.3, 1.2 gibi semantik etiketler yayınlamak geriye dönük uyumluluk ve geri dönüş kolaylığı sağlar.

Sonuç

Docker Buildx ve GitHub Actions kombinasyonu, çok mimarili imajları üretme ve dağıtma işini otomatikleştirerek geliştirme ekiplerine önemli hız kazandırır. Bu rehberdeki adımları izleyerek hem yerelde hem de CI ortamında linux/amd64 ve linux/arm64 için tek komutta güvenilir, hızlı ve ölçeklenebilir bir yayın akışı kurabilirsiniz. Doğru taban imajı, akıllı önbellek, temiz Dockerfile ve iyi etiket yönetimiyle, 2025’te çok mimarili dağıtım stratejinizi gönül rahatlığıyla standart hale getirebilirsiniz.