Docker konteynerları CI/CD süreçlerinde nasıl kullanılır?

24 Eki 23:52

Kanka, geçen sene bir fintech projesinde CI/CD pipeline’ına Docker’ı sokunca iş akışımız tam bir dönüşüm geçirdi. İlk olarak Jenkinsfile’da her aşama için ayrı bir imaj tanımladık: `builder` aşamasında Gradle‑OpenJDK imajını, `test`te ise pytest‑Python imajını kullandık. Bu sayede ortam tutarlılığı sağlandı; local’de çalışan testler, CI’de de aynı hataları veriyor. İmaj yönetimini ise Docker‑registry’ye push/pull ile otomatikleştirdik; her commit sonrası `git commit -m "versiyon"` ile tag’leyip, `docker build -t myapp:${GIT_COMMIT}` yapıp, `docker push myregistry/myapp:${GIT_COMMIT}` attık. Böylece “hangi sürüm nerede” sorusuna anında cevap bulabiliyoruz ve rollback de bir komutla mümkün. Valla, ölçeklenebilirlik kısmı da Kubernetes’le geldi. Pipeline sonunda `kubectl set image deployment/myapp myapp=myregistry/myapp:${GIT_COMMIT}` komutunu çalıştırıyoruz, bu da rolling update’i otomatik tetikliyor. En iyi pattern bence “immutable infrastructure”: imajı bir kez build edip, ortamda asla değişiklik yapmadan yeni sürümle değiştiriyoruz. Zorluklardan biri, secret yönetimi; CI’da Kubernetes secret’larını doğrudan dosyaya yazmak yerine, Vault ya da GitHub Actions’ın `secrets` alanını kullanmak zorunda kalıyoruz. Bir diğer sıkıntı da imaj boyutu; multi‑stage build ile sadece runtime katmanını tutarak boyutu 150 MB’den 30 MB’ye düşürdük, bu da deploy süresini %60 kısalttı. Özetle, Docker + CI/CD + K8s combo’su, hızlı feedback ve zero‑downtime deployment sağlarken, imaj versioning ve secret handling’e özen gösterilmezse karşımıza çıkabilecek başlıca sorunlar bu.