Bir yazılımı konteynerleştirmek, ilk bakışta çocuk oyuncağı gibi görünür (buna dikkat edin). Asıl mesele şu: beş farklı monoliti aynı anda alıp, her birinin huyunu suyunu çözmek. Bir tanesi Node.js, diğeri Python… biri statik dosya servis ediyor, öteki Go ile tek binary çalıştırıyor. Kâğıt üstünde hepsi “Dockerfile yazarız biter” seviyesinde duruyor — ama pratikte iş biraz daha karışıyor. Hatta bayağı.
Geçen yıl, 2024 Nisan’ında İstanbul’da bir fintech ekibiyle yaptığım kısa danışmanlıkta buna çok benzer bir tablo görmüştüm. Ekip, tek bir uygulamayı EKS’e taşırken bile image boyutu, build süresi ve izinler arasında gidip geliyordu; üstüne üstlük her çözüm yeni bir sorun doğuruyordu, hani şu “bir yamayı yapıştır üç delik açılır” durumunun ta kendisi. Beş uygulama olunca sorun katlanıyor — yani mesele sadece konteyner yapmak değil, bakım maliyetini de makul tutmak — dürüst olayım, biraz hayal kırıklığı —
Neden bu iş önemli?
İşin garibi, Monolit kelimesi bazen insanı korkutuyor. Ama açık konuşayım. Çoğu şirketin gerçek hayatı zaten bu. Mikroservis masalı güzel geliyor; küçük ekiplerde, hatta — ki bu tartışılır — orta ölçekli yapılarda monolit hâlâ en mantıklı seçenek olabiliyor. Operasyonel yükü dramatik biçimde düşük tutuyor. Sorun monolitin kendisi değil — sorunsuz çalıştığını sanıp onu yıllarca ellememek.
Peki neden?
Benim kendi not defterimde 2023 sonbaharında Ankara’daki bir SaaS projesi için aldığım not hâlâ duruyor: “Build süresi 14 dakika olduysa biri bir şeyi yanlış yapmıştır.” Tam da bu yüzden konteyner stratejisi önemli. İyi paketlenmiş bir uygulama daha hızlı dağıtılır, daha rahat ölçeklenir ve prod ortamında sürpriz çıkarma ihtimali azalır — her üçü de ayrı ayrı değerli şeyler.
Bi saniye — Gel gelelim herkesin ilk takıldığı yer imaj boyutu oluyor (buna dikkat edin). Küçük görünen farklar bile prod tarafında can sıkıyor. 1 GB’lık gereksiz katmanlar hem registry’yi şişiriyor hem de node açılışını uzatıyor. Bilhassa Kubernetes’te düğüm değiştiğinde bunu anında hissediyorsunuz. Ciddi fark var.
Peki neden?
Node.js tarafında.dockerignore neden kritik?
Garip gelecek ama, Node dünyasında en klasik hata şu: node_modules klasörünü build context’e boca etmek. Sonra Docker seni bekliyor gibi davranıyor ama aslında kendi ayağına sıkıyorsun. Ben bunu ilk kez 2022’de İzmir’de küçük bir e-ticaret projesinde gördüm; arkadaşımın laptopunda build yarım saati geçmişti, çünkü context gereksiz dosyalarla doluydu. Kimse fark etmemişti, ay sonra tesadüfen keşfettik.
.dockerignore burada basit ama iş gören bir sigorta gibi çalışıyor. Git deposunda ne kadar çöp varsa dışarıda bırakıyorsun. Image küçülüyor, build süresi kısalıyor. Üstelik iki aşamalı build yaklaşımıyla yalnızca üretimde gereken parçaları taşıyorsun.
node_modules
npm-debug.log
.env
.gitUser olarak node ile çalışmak da küçük ama değerli bir hamle. Root ile container çalıştırmak teoride kolaydır; pratikte ise güvenlik açısından hiç iç açıcı değildir. Bir container escape yaşanırsa olay büyür. Fazla büyür.
| Yaklaşım | Artı | Eksi |
|---|---|---|
| Tek katmanlı Node image | Kurması kolay | Büyük image, yavaş deploy |
| İki aşamalı build | Daha temiz ve küçük image | Dockerfile biraz uzar |
| .dockerignore olmadan build | Neredeyse yok | Ağır context, boşa zaman kaybı |
Python/Flask cephesinde Alpine tuzağı
Alpine ilk bakışta çok çekici geliyor (yanlış duymadınız). Minicik çünkü. Ama Python ekosisteminde her zaman dostane davranmıyor — özellikle C extension kullanan paketlerde işler fena karışabiliyor; musl libc bazı kütüphanelerin canını sıkıyor. Derleme süreleri uzadıkça uzuyor, sonunda “neden bu kadar sürdü” diye bakıyorsun kendine.
Buna benzer bir problemi 2024 Şubat’ında Berlin merkezli bir sağlık teknolojisi firmasının test ortamında yaşamıştım. cryptography paketi Alpine üzerinde sürekli sürpriz çıkarıyordu; kimi zaman wheel bulamıyor, kimi zaman derleme hatası veriyordu. Sonra Debian tabanlı slim imaja geçince ortalık sakinleşti. Neyse uzatmayalım. Bu konuyla ilgili ASCII’yi Python ve JavaScript’te Böyle Okuyun: Kolay Rehber yazımıza da göz atmanızı tavsiye ederim. Bu konuyla ilgili PDF Dünyasında Bir Nefes: Ücretsiz ve Limitsiz Araçlar yazımıza da göz atmanızı tavsiye ederim.
Durun, bir saniye. Daha fazla bilgi için Butterfly CSS: 2026’da Dikkat Çeken Hafif Bir Seçenek yazımıza bakabilirsiniz.
Açıkçası burada “en küçük image en iyidir” diye körü körüne gitmemek lazım. Kâğıt üstünde Alpine kazanıyor gibi görünür — ama pratikte geliştirici zamanı daha pahalı olabiliyor. Bence hayal kırıklığının tam kaynağı da bu zaten: küçük olmak her zaman iyi demek değil.
Slim mi Alpine mi?
Küçük startup için hızlı kurulum önemliyse python:3.12-slim çoğu durumda daha mantıklı. Ekip saatlerini paket derlemekle harcamıyor (ki bu çoğu kişinin gözünden kaçıyor). Uğraşmıyor işte. Bu konuyla ilgili TypeScript ile Bulut Kurmak: Koddan Altyapıya Tek Hamle yazımıza da göz atmanızı tavsiye ederim.
Kurum tarafında ise standartlaştırma daha ön plana geliyor; güvenlik taraması kolay olsun, dependency zinciri net olsun istersin. Orada da slim çoğu kez daha az baş ağrıtıyor — deneyimlerime göre en azından.
NestJS ve Go örnekleri bize ne anlatıyor?
İlginç olan şu ki, NestJS tarafındaki üç aşamalı yapı bana hep mutfakta hazırlık yapmayı hatırlatıyor: önce malzemeleri ayıkla, sonra pişir, en son servis et (yanlış duymadınız). Dependency stage, compile stage ve runtime stage ayrımı tam olarak bunun teknik karşılığı.
Böyle yapınca final image içine TypeScript derleyicisini ya da gereksiz kaynakları sokmazsın. Bu özellikle CI/CD hattında işe yarıyor çünkü artifact daha öngörülebilir oluyor. Yani pipeline “bir gün geçti ertesi gün patladı” tarzına dönmüyor. Hiç dönmemeli zaten. Daha fazla bilgi için Prime Day İndirimlerinde Akıllı Alışveriş: Kaçırmama Rehberi yazımıza bakabilirsiniz.
Go tarafı ise ayrı dünya. Statik binary üretince distroless imaj kullanmak bayağı temiz sonuç veriyor (inanın bana) (bu konuda ikircikliyim). Ben bunu 2023 Temmuz’unda Londra’daki bir logistics startup’ta denemiştim; Go servisi o kadar sadeleşmişti ki debug sırasında bile neredeyse “fazlalık yok” diyorduk. Tabii dezavantaj da var: distroless içinde shell olmadığı için acil müdahalede biraz zorlanıyorsun — bunu da hesaba katmak lazım.
EKS’e geçince oyun neden değişiyor?
Konteyneri yerelde çalıştırmak başka şey. EKS üzerinde düzgün işletmek bambaşka şey. Cluster içinde readiness/liveness probe ayarları yanlışsa servis ayağa kalkmış görünüyor ama trafik alamıyorsun (evet, doğru duydunuz). O an ekran başında insan kendine bakıp “ben nerede hata yaptım?” diye soruyor. Biliyorum, yaşadım.
EKS’in güzel tarafı ölçeklenebilir olması; kötü tarafı seni disiplinli olmaya zorlaması (evet, bazen sinir bozucu, bunu kabul edelim). Namespace düzeni, resource limitleri, IAM rolleri ve secret yönetimi düzgün değilse Kubernetes affetmiyor (bizzat test ettim). Maalesef.
Kubernetes’e giden yol “önce çalışsın sonra düzeltiriz” mantığıyla yürümüyor; özellikle prod’da bu yaklaşım geri teper.
Küçük ekip vs kurumsal ekip farkı
- Küçük ekipte hız öncelikli olur; sade manifestler iş görür.
- Kurumda gözlemleme, loglama ve politika setleri şart olur.
- Küçük projede tek cluster yeterken enterprise tarafta çoklu ortam gerekebilir.
- Küçük takımda manuel kontrol tolere edilir; büyük yerde otomasyon mecburi hale gelir.
Bana göre asıl ders neydi?
Şunu söyleyeyim: Her stack’in güçlü yani başka yerde yatıyor ve tek kalıp çözüm yok. Node.js’de temizlik kazandırıyor, Python’da doğru base image fark yaratıyor, NestJS’de aşamalı build düzen sağlıyor, React SPA’da Nginx işleri toparlıyor, Go’da ise minimalizm ödül veriyor. Hepsinin ayrı karakteri var, nasıl desem.
Şahsen, Bu konuyu yazıya dökerken aklıma hep aynı şey geldi. İnsanlar genelde başarı hikâyesini seviyor ama asıl öğrenme başarısızlıkta oluyor. Ben bazı container denemelerinde ilk — kendi adıma konuşayım — etapta fazla optimize etmeye çalışıp kendi işimi zorlaştırdım — geriye dönüp bakınca gülümsüyorum şimdi. Daha sonra şunu kabul ettim: önce stabilite, sonra incelikler (şaşırtıcı ama gerçek). Sırası önemli.
Aman ha, unutmayın: pratik noktalar
- .dockerignore kullanmadan başlamayın: Build context şişmesin. — ciddi fark yaratıyor
- User root olmasın: Güvenlik için küçük ama etkili adım.
- Slim vs Alpine kararını paketlere göre verin: Tek başına boyuta bakmayın.
- Liveness/readiness probe’u ihmal etmeyin: Aksi halde sahte sağlık kontrolü yaşarsınız.
- EKS rol ve secret düzenini erkenden kurun: Sonradan yamamak zor olur. — bunu es geçmeyin
Sıkça Sorulan Sorular
EKS’e monolit taşımak mantıklı mı?
Evet, eğer amaç mikroservise bölmeden önce altyapıyı modernleştirmekse mantıklı olabilir.
Bilhassa de deployment hızını artırmak ve operasyonu standartlaştırmak için iyi bir ara adımdır.
Ama sırf moda diye yapılmamalıdır.
Docker image boyutunu nasıl düşürürüm?
Araya gireyim:.dockerignore kullanın,
çok aşamalı build yapın,
gereksiz bağımlılıkları runtime’a taşımayın.
Ayrıca base image seçimini aceleye getirmeyin;
küçük olan her zaman daha iyi değildir.
Peki Alpine neden herkese uygun değil?
C extension kullanan Python paketlerinde sorun çıkarabilir. Derleme süresi uzayabilir veya paket hiç kurulmayabilir. Bu yüzden slim tabanlı imaj çoğu projede daha rahat ilerletir.
Kubernetes’te en sık yapılan hata nedir?
Liveness/readiness probe’ları yüzeysel ayarlamak. Servis içeride sağlıklı görünse bile dışarıdan trafik alamayabilir. Bir diğer klasik hata da resource limit koymamaktır.
Kaynaklar ve İleri Okuma”
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
