Docker ile İzole Edilmiş Geliştirme ve Dağıtım Ortamları

Yeni bir projeyi bilgisayarınıza çektiğinizi ve çalıştırmak için önce doğru runtime sürümünü, database'i, cache servisini, paket yöneticisini ve birkaç sistem aracını kurmanız gerektiğini düşünün. Bir ekip arkadaşınız aynı projeyi farklı işletim sisteminde açtığında tamamen farklı bir hata görebilir. Docker ile İzole Edilmiş Geliştirme ve Dağıtım Ortamları bu sorunu uygulamanın ihtiyaçlarını kodla tanımlanan ve tekrar oluşturulabilen çalışma alanlarına taşıyarak azaltır. Böylece geliştiricinin bilgisayarındaki rastgele kurulumlar yerine repository ile birlikte yönetilen ortak bir çalışma standardı oluşur. İyi tasarlanmış bir container yapısı development hızını artırırken staging ve production geçişlerinde sürprizleri de azaltır.

Bu rehberde Docker ile izole geliştirme ve deployment ortamı nasıl kurulur sorusunu temelden production seviyesine kadar ele alacağız. Docker ile development staging production ortamları nasıl ayrılır, Docker Compose ile yerel geliştirme ortamı nasıl oluşturulur ve Docker container ortamlarında volume network secret ve environment variable yönetimi nasıl yapılır gibi pratik başlıkları adım adım açıklayacağız. Ayrıca image build, registry, healthcheck, logging, backup, rollback, rootless kullanım ve CI/CD süreçlerini aynı bütün içinde değerlendireceğiz. Kurumsal Docker geliştirme ve deployment ortamı kurulum hizmeti arayan ekiplerin hangi teknik ölçütlere bakması gerektiğine de değineceğiz. Docker ve container DevOps danışmanlığı yakınımda şeklinde araştırma yapan ekipler için yalnızca kurulum değil, sürdürülebilir operasyon tasarımının neden önemli olduğunu göstereceğiz.

Docker Nedir?

Docker uygulamaları ve ihtiyaç duydukları çalışma bileşenlerini image adı verilen paketlenebilir yapılarda tanımlamanıza yardımcı olan container platformudur. Uygulama bu image'dan container olarak başlatılır ve host üzerindeki diğer süreçlerden belirli seviyelerde ayrılır. Docker aynı image'ın geliştirici bilgisayarında, CI sunucusunda ve deployment ortamında daha tutarlı biçimde kullanılmasını sağlar. Buradaki temel değer yalnızca uygulamayı çalıştırmak değil, çalışma ortamının tekrar üretilebilir hale gelmesidir. Bu nedenle Docker çoğu DevOps sürecinde build, test ve deployment zincirinin ortak parçalarından biri olarak kullanılır.

Container Nedir?

Container bir uygulama sürecini ihtiyaç duyduğu filesystem, network ve runtime görünümüyle birlikte çalıştıran izole ortamdır. Container klasik sanal makine gibi kendi tam işletim sistemi çekirdeğini taşımak zorunda değildir. Linux tabanlı container'lar çoğunlukla host kernel'ini paylaşır ancak namespace ve resource kontrolleriyle birbirlerinden ayrılır. Bu yapı hızlı başlatma ve daha düşük kaynak tüketimi sağlayabilir. Yine de container izolasyonu tam donanım sanallaştırmasıyla aynı güvenlik sınırı olarak değerlendirilmemelidir.

Docker Image Nedir?

Docker image uygulamanın çalışması için gereken dosyaları ve metadata'yı içeren okunabilir build çıktısıdır. Image genellikle bir Dockerfile kullanılarak katmanlar halinde oluşturulur. Runtime, dependency ve application artifact bu katmanlarda yer alabilir. Aynı image birçok farklı container başlatmak için kullanılabilir. Production açısından en önemli prensip image'ın değiştirilebilir çalışan sunucu klasörü değil, versionlanabilir deployment artifact'ı olarak görülmesidir.

Docker Container Nedir?

Docker container bir image'ın çalışan örneğidir. Aynı image'dan birden fazla bağımsız container başlatılabilir. Container içinde yapılan geçici filesystem değişiklikleri image'ı değiştirmez. Kalıcı veriler volume veya harici veri sistemi üzerinden tutulmalıdır. Container silindiğinde uygulamanın yeniden aynı image ve configuration ile oluşturulabilmesi ideal davranıştır.

Docker Engine Nedir?

Docker Engine container yaşam döngüsünü yöneten temel çalışma katmanıdır. Image build, container create, network ve volume işlemleri bu yapı üzerinden yürütülür. Docker CLI komutları Engine API ile iletişim kurarak işlemleri başlatır. Engine yüksek yetkilerle çalışabildiği için daemon erişimi güvenlik açısından önemlidir. Özellikle Docker socket erişimi sıradan bir dosya izni gibi değerlendirilmemelidir.

Docker Registry Nedir?

Registry container image'larının saklandığı ve dağıtıldığı merkezi hizmettir. CI pipeline build ettiği image'ı registry'ye push edebilir ve deployment sunucusu aynı artifact'ı registry'den pull edebilir. Tag, digest ve retention politikaları image yaşam döngüsünün önemli parçalarıdır. Private registry kullanıldığında authentication ve authorization ayrıca yönetilmelidir. Production deployment için hangi image'ın çalıştığını digest üzerinden takip etmek güçlü bir tekrar üretilebilirlik sağlar.

Docker Compose Nedir?

Docker Compose birden fazla container servisinin tek bir Compose modeli üzerinden tanımlanmasını ve birlikte yönetilmesini sağlar. Backend, database, cache ve worker gibi servisler aynı compose.yaml içinde ifade edilebilir. Network, volume, environment ve dependency ilişkileri de aynı modelde yer alır. docker compose up komutu tanımlanan servisleri oluşturup başlatmak için kullanılabilir. Bu yaklaşım özellikle yerel geliştirme ve tek host üzerinde yönetilen uygulama stack'lerinde güçlü bir ortak çalışma modeli sunar.

İzole Geliştirme Ortamı Nedir?

İzole geliştirme ortamı bir projenin dependency, runtime, network ve filesystem ihtiyaçlarını diğer projelerden mümkün olduğunca ayırır. Böylece bir projede kullanılan runtime sürümünün başka bir projeyi bozması önlenebilir. Database veya cache sürümleri sistem geneline kurulmak yerine proje bağlamında çalıştırılabilir. Yeni geliştirici aynı repository tanımlarını kullanarak benzer ortamı kurabilir. İzolasyon yalnızca rahatlık değil, ekip içindeki çevresel farklılıkları azaltan mühendislik aracıdır.

Development Environment Nedir?

Development environment kod yazma, çalıştırma, test etme ve debug işlemlerinin gerçekleştirildiği çalışma ortamıdır. Runtime, compiler, database, local service ve debugging araçları bu ortamın parçası olabilir. Production'dan farklı olarak hot reload ve development dependency'leri burada bulunabilir. Ortamın hızlı geri bildirim vermesi geliştirici verimliliği açısından önemlidir. Buna rağmen runtime ve temel dependency sürümlerinin production ile uyumlu tutulması gerekir.

Environment Isolation Nedir?

Environment isolation her projenin ihtiyaç duyduğu kaynakları diğer projelerden kontrollü biçimde ayırmasıdır. İki proje farklı runtime veya database sürümü kullanabilir. Container modeli bu farklılıkların host sistemine daha az yayılmasını sağlar. Network ve volume sınırları da servislerin birbirine yanlışlıkla erişmesini azaltabilir. İzolasyon seviyesi projenin riskine göre ayrıca güçlendirilebilir.

Dependency Isolation

Dependency isolation proje paketlerinin sistem genelindeki başka paketlerle çakışmasını azaltır. Örneğin iki uygulama farklı Node.js veya Python sürümü kullanabilir. Image içinde dependency sürümünün sabitlenmesi aynı build davranışını tekrar üretmeyi kolaylaştırır. Lock dosyaları deterministic installation için önemlidir. Host dependency'lerini doğrudan container içine taşımak ise platform farkları nedeniyle problem çıkarabilir.

Process Isolation

Process isolation container içindeki sürecin host ve diğer container süreçlerinden ayrı bir görünümde çalışmasını sağlar. PID namespace bu yapının Linux tarafındaki önemli bileşenlerinden biridir. Container içinde process ID 1 olarak görünen süreç host üzerinde farklı bir PID değerine sahip olabilir. Bu ayrım süreç yönetimini kolaylaştırır. Ancak ortak kernel kullanıldığı için tam sanal makine sınırı oluşmaz.

Network Isolation

Network isolation container'ların ayrı network namespace ve sanal network'ler üzerinden iletişim kurmasını sağlar. Database yalnızca backend network'üne bağlanabilir. Reverse proxy hem public hem private network'te bulunabilir. Gereksiz port publish işlemleri azaltılarak host üzerinden erişim sınırlandırılabilir. Bu yapı uygulama mimarisinin erişim sınırlarını Compose içinde görünür hale getirir.

Filesystem Isolation

Container kendi image filesystem görünümüne sahiptir. Host dosyaları ancak bind mount veya benzeri mekanizmayla açıkça bağlandığında görünür hale gelir. Production container'ın source bind mount kullanmadan immutable image üzerinden çalışması tercih edilir. Yazılması gereken data volume veya geçici filesystem alanına yönlendirilebilir. Read only root filesystem bazı production senaryolarında ek güvenlik sağlar.

Resource Isolation

Resource isolation CPU, memory ve process sayısı gibi kaynakların container bazında sınırlandırılmasını sağlar. Böylece hatalı çalışan tek servis host üzerindeki tüm kaynakları tüketmeyebilir. Development ortamında limitler daha esnek tutulabilir. Production kapasite planında gerçek workload dikkate alınmalıdır. Compose deploy modelinde CPU, memory ve PID limitleri tanımlanabilir. :contentReference[oaicite:1]{index=1}

İzole Ortamlar “Works on My Machine” Problemini Nasıl Azaltır?

Bu problem genellikle geliştiricilerin farklı runtime, dependency veya sistem ayarları kullanmasından doğar. Docker ortam tanımını repository içinde taşınabilir hale getirerek farkları azaltır. Aynı image CI'da ve staging'de çalıştırıldığında çevresel sürprizlerin bir bölümü erken fark edilir. Tam eşitlik yine garanti edilmez, çünkü host kernel, mimari ve external services farklı olabilir. Buna rağmen rastgele local kurulumlara göre daha kontrollü bir başlangıç noktası sunulur.

Docker İzolasyonu Nasıl Çalışır?

Docker izolasyonu tek bir özellikten oluşmaz. Linux namespaces süreç, network ve mount görünümünü ayırırken cgroups kaynak kullanımını kontrol eder. Image layer yapısı filesystem dağıtımını verimli hale getirir. Kullanıcı namespace ve permission modelleri güvenliği güçlendirebilir. Ancak aynı kernel'in paylaşılması nedeniyle izolasyonun teknik sınırlarını anlamadan container'ı güvenlik duvarı gibi görmek doğru değildir.

Linux Namespaces

Linux namespaces süreçlerin sistem kaynaklarını farklı görmesini sağlayan kernel mekanizmalarıdır. Docker container'ları bu yetenekleri kullanarak PID, network, mount ve başka kaynak alanlarını ayırabilir. Uygulama container içinden daha sınırlı bir sistem görünümü görür. Namespace tek başına resource limiti sağlamaz. Resource kontrolü için cgroups gibi başka kernel özellikleri de kullanılır.

PID Namespace

PID namespace process ID görünümünü container bazında ayırır. Container içindeki süreçler host'taki tüm süreçleri normalde görmez. Container ana süreci kendi namespace'inde PID 1 olabilir. Signal handling bu nedenle container uygulamalarında önem kazanır. Uygulamanın stop sinyallerini doğru işlemesi temiz shutdown için gereklidir.

Network Namespace

Network namespace container'a ayrı interface, route ve port görünümü sağlar. İki container aynı internal portu kendi namespace'lerinde kullanabilir. Host'a publish edilmediği sürece port dışarıdan otomatik erişilebilir olmaz. Compose network'leri servisleri ortak sanal ağlarda toplar. DNS tabanlı service discovery container isimlerinden bağımsız servis adlarıyla bağlantı kurmayı kolaylaştırır.

Mount Namespace

Mount namespace filesystem mount görünümünü süreç grupları arasında ayırır. Container image filesystem'i kendi root görünümüne sahip olur. Bind mount ve volume tanımları seçili host veya managed storage alanlarını container'a açar. Gereksiz host path mount etmek izolasyonu zayıflatabilir. Production container'larda yalnızca gerçekten gerekli mount noktaları kullanılmalıdır.

User Namespace

User namespace container UID ve GID değerlerini host üzerindeki farklı kimliklerle eşleştirebilir. Bu özellik container root kullanıcısının host root ile aynı yetki anlamına gelmesini önlemeye yardımcı olabilir. Rootless mode bu yaklaşımı daha ileri taşıyarak daemon ve container'ları root olmayan kullanıcı bağlamında çalıştırır. Docker'ın resmi belgelerine göre rootless mode daemon ve container'ları user namespace içinde root yetkisi olmadan çalıştırabilir. :contentReference[oaicite:2]{index=2} User mapping davranışı volume permission tasarımında dikkatle ele alınmalıdır.

IPC Namespace

IPC namespace süreçler arası iletişim kaynaklarını container bağlamında ayırır. Shared memory ve bazı IPC nesneleri bu izolasyondan etkilenir. Çoğu web uygulaması bu ayrıntıyı doğrudan yönetmez. Ancak database ve yüksek performanslı uygulamalarda shared memory ayarları önemli olabilir. Gereksiz namespace paylaşımı yapılmaması daha güvenli varsayılandır.

Control Groups (cgroups)

cgroups süreç gruplarının CPU, memory ve başka kaynak kullanımlarını kontrol etmeye yardımcı olur. Container'ın belirli bir memory sınırını aşmasını engellemek mümkündür. Bu sınırlar noisy neighbor etkisini azaltır. Memory limiti yanlış belirlenirse uygulama OOM davranışı yaşayabilir. Limitler gözlem verileri ve gerçek workload üzerinden ayarlanmalıdır.

Union Filesystem ve Image Layers

Docker image'ları katmanlı filesystem yaklaşımından yararlanır. Dockerfile'daki birçok build adımı yeni layer oluşturabilir. Ortak base katmanlar cache ve dağıtım verimliliği sağlayabilir. Cache invalidation davranışı Dockerfile sırasını önemli hale getirir. Dependency dosyalarını source code'dan önce kopyalamak sık kullanılan build optimizasyonlarından biridir.

Container İzolasyonunun Sınırları

Container aynı host kernel'ini paylaşabildiği için VM ile aynı izolasyon modeli değildir. Privileged container, Docker socket mount veya geniş capability erişimi güvenlik sınırını ciddi biçimde zayıflatabilir. Kernel açığı birçok container'ı etkileyebilir. Bu nedenle image güvenliği kadar host güvenliği de önemlidir. Yüksek riskli tenant izolasyonunda ek sandbox veya VM sınırları değerlendirilebilir.

Container ile VM İzolasyonu Arasındaki Fark

VM çoğunlukla ayrı guest operating system ve sanallaştırılmış donanım sınırıyla çalışır. Container ise daha hafif yapı için host kernel'ini paylaşır. Container çok hızlı oluşturulabilir ve daha küçük deployment artifact'ları kullanabilir. VM daha güçlü kernel ayrımı gerektiren işlerde tercih edilebilir. İki teknoloji birbirinin tamamen alternatifi değildir ve aynı mimaride birlikte kullanılabilir.

Docker ile Geliştirme Ortamı Kullanmanın Avantajları

Docker'ın geliştirmedeki en büyük faydası proje runtime'ının dokümantasyondan çıkarılıp çalıştırılabilir tanıma dönüşmesidir. Developer onboarding daha hızlı hale gelebilir. Bir projeden diğerine geçerken host sisteminde sürekli runtime değiştirmek gerekmez. CI ile local ortam arasındaki farklar azalabilir. Ekibin aynı Compose ve Dockerfile tanımlarını kullanması çevresel hataların tanılanmasını da kolaylaştırır.

Tutarlı Runtime Sürümleri

Runtime sürümü Dockerfile içinde belirlenebilir. Böylece ekipte bir geliştirici farklı ana sürüm kullanmaz. Base image güncellemesi Pull Request üzerinden kontrollü yapılabilir. CI aynı base image'ı kullanabilir. Production artifact da aynı runtime zincirinden üretilebilir.

Dependency Çakışmalarını Önleme

Proje dependency'leri image veya container bağlamında tutulabilir. Sistem genelindeki paketlar daha az etkilenir. İki proje farklı dependency sürümleriyle yan yana çalışabilir. Native dependency'lerin host yerine target platform için kurulması önemlidir. Lock file kullanımı build tekrarını güçlendirir.

Hızlı Developer Onboarding

Yeni geliştiricinin uzun kurulum belgesi takip etmesi yerine Compose stack başlatması hedeflenebilir. Environment örnek dosyası gerekli configuration anahtarlarını gösterir. Database migration ve seed otomatikleştirilebilir. İlk test komutu onboarding doğrulaması olarak kullanılabilir. Clean clone to running süresi ekip tarafından ölçülebilir.

Projeler Arasında Kolay Geçiş

Her proje kendi container setini kullanabilir. Host üzerinde farklı database servislerini sürekli açıp kapatmak gerekmez. Compose project name ile aynı isimli servisler ayrılabilir. Port çakışmaları environment variable ile yönetilebilir. Proje kapandığında ilgili container'lar tek komutla durdurulabilir.

Kolay Ortam Sıfırlama

Bozulmuş local state container yeniden oluşturularak temizlenebilir. Stateless servisler tamamen kaldırılıp image'dan tekrar başlatılabilir. Development database gerekiyorsa volume kontrollü biçimde sıfırlanabilir. Seed script başlangıç verisini yeniden oluşturabilir. Bu model kişisel makinelerde biriken görünmez ayarların etkisini azaltır.

Production Hatalarını Lokal Ortamda Yeniden Üretme

Aynı image veya yakın configuration local ortamda çalıştırılabilir. Production logundaki sürüm digest'i biliniyorsa aynı artifact indirilebilir. Test data kullanılarak hata yeniden üretilebilir. Gerçek production secret veya kişisel veri local ortama taşınmamalıdır. Aynı artifact kullanımı environment kaynaklı farkları daraltır.

CI Ortamıyla Tutarlılık

CI aynı Dockerfile üzerinden image üretebilir. Integration test için Compose stack oluşturulabilir. Local test edilen servis sürümleri CI'da da sabit tutulabilir. Job sonunda container ve network kaynakları temizlenebilir. Bu yaklaşım local başarılı olup CI'da tamamen farklı davranan kurulumları azaltır.

Takım İçinde Standardizasyon

Dockerfile ve Compose dosyaları ortak çalışma sözleşmesi haline gelebilir. Runtime ve service isimleri repository'de görünür olur. Code review sırasında environment değişiklikleri de incelenebilir. Yeni araç eklenmesi kişisel kurulum notuna bağlı kalmaz. Standardizasyon geliştirici özgürlüğünü yok etmek yerine tekrar eden kurulum işlerini azaltmalıdır.

Docker Geliştirme Ortamının Dezavantajları

Docker her proje için otomatik olarak daha iyi geliştirme deneyimi oluşturmaz. Ek network, volume ve container kavramları öğrenilmelidir. Desktop işletim sistemlerinde filesystem paylaşımı performansı etkileyebilir. Debugger bağlantısı ve UID permission konuları başlangıçta ek iş çıkarabilir. Küçük ve tek runtime kullanan bazı projelerde container katmanı elde edilen faydadan daha fazla operasyon yükü oluşturabilir.

Ek Soyutlama Katmanı

Uygulama artık doğrudan host üzerinde değil container içinde çalışır. Dosya, process ve port sorunları iki katman üzerinden incelenebilir. Developer Docker komutlarını temel seviyede bilmelidir. Hata mesajının application mı container mı kaynaklı olduğu ayırt edilmelidir. İyi tooling bu ek yükü azaltabilir.

Debug Karmaşıklığı

Debugger container içinde çalışırken IDE host üzerinde olabilir. Port forwarding ve source path mapping doğru yapılandırılmalıdır. Breakpoint'in çalışmaması bazen koddan değil mapping'den kaynaklanabilir. Debug tooling yalnızca development stage içinde tutulmalıdır. Production'da debug portu açılmamalıdır.

Dosya Sistemi Performansı

Source code bind mount performansı host platformuna göre değişebilir. Çok sayıda küçük dosya kullanan dependency dizinleri yavaşlık oluşturabilir. Generated output gereksiz yere host ile senkronize edilmemelidir. Named volume veya Compose Watch alternatif olabilir. Performans sorunu ölçülmeden tüm proje yapısını değiştirmek doğru yaklaşım değildir.

Mac ve Windows'ta Bind Mount Performansı

Desktop platformlarında Linux container filesystem'i ile host filesystem arasında ek sanallaştırma katmanı bulunabilir. Büyük monorepo veya yoğun file watcher kullanan projeler bu farkı daha çok hissedebilir. node_modules gibi klasörleri bind mount dışında tutmak faydalıdır. Compose Watch belirli dosyaları senkronize ederek alternatif geliştirme modeli sunabilir. Docker'ın resmi Compose Watch belgeleri de yoğun dependency klasörlerinin senkronizasyondan çıkarılmasını önerir. :contentReference[oaicite:3]{index=3}

Disk Alanı Kullanımı

Image, volume ve build cache zamanla ciddi disk alanı tüketebilir. Development makinelerinde eski image'lar birikebilir. Volume prune komutları veri kaybı riski taşıdığı için dikkatle kullanılmalıdır. Build cache kontrollü temizlenebilir. Düzenli disk gözlemi Docker kullanan ekipler için faydalıdır.

Network Kavramlarının Öğrenilmesi

Container içindeki localhost host makineyi göstermez. Service discovery çoğunlukla Compose servis adıyla yapılır. Port publish ile internal port arasındaki fark anlaşılmalıdır. Birden fazla network kullanıldığında hangi servisin nereye erişebildiği düşünülmelidir. Bu kavramlar öğrenildiğinde production network tasarımını anlamak da kolaylaşır.

Docker Desktop Kaynak Tüketimi

Docker Desktop sanallaştırma ve container servisleri için CPU ve RAM kullanır. Çok servisli development stack cihazı zorlayabilir. Kullanılmayan servisler Compose profiles ile kapalı tutulabilir. Database ve search servislerine gerçekçi fakat kontrollü limit verilebilir. Geliştirici cihaz profiline göre kaynak ayarları düzenlenebilir.

Container Kullanmanın Gereksiz Olduğu Projeler

Tek binary üreten çok küçük bir araç için Docker development zorunlu olmayabilir. Projede harici service veya version conflict yoksa native workflow daha hızlı olabilir. Docker yalnızca teknoloji listesinde bulunsun diye eklenmemelidir. CI veya production packaging ihtiyacı yine Docker kullanımını anlamlı hale getirebilir. Karar gerçek ekip ve deployment ihtiyacına dayanmalıdır.

Docker Geliştirme Ortamının Temel Dosyaları

İyi Docker repository'sinde ortam davranışını birkaç anlaşılır dosya tanımlar. Dockerfile image build sürecini yönetir. Compose dosyaları servislerin nasıl birlikte çalışacağını açıklar. Environment örnekleri configuration sözleşmesini gösterir. Dev Container tanımı ise IDE ve CLI araçlarını development container içinde standardize etmek için kullanılabilir.

Dockerfile

Dockerfile image'ın nasıl oluşturulacağını belirleyen declarative build dosyasıdır. Base image, dependency kurulumu ve application copy adımları burada tanımlanır. Development ve production stage'leri aynı dosyada tutulabilir. Secret değerler Dockerfile içine yazılmamalıdır. Dockerfile değişiklikleri code review sürecinden geçirilmelidir.

compose.yaml

compose.yaml birden fazla servisin birlikte çalışma modelini tanımlar. Service, network, volume ve environment ayarları burada yer alabilir. Default development davranışı mümkün olduğunca anlaşılır tutulmalıdır. Production farkları ayrı override dosyasında yönetilebilir. Final Compose modelinin docker compose config ile kontrol edilmesi faydalıdır.

.dockerignore

.dockerignore build context'e hangi dosyaların gönderilmeyeceğini belirler. node_modules, Git metadata ve local output bu dosyada dışarıda bırakılabilir. Secret dosyalarının build context'e girmemesi ayrıca önemlidir. Daha küçük context build süresini azaltabilir. Ignore kuralları repository yapısı değiştikçe güncellenmelidir.

.env

.env Compose interpolation için sık kullanılan environment dosyasıdır. Hassas secret'ları burada tutmak varsayılan çözüm olmamalıdır. Local developer değerleri Git dışında tutulabilir. Compose variable precedence davranışı bilinmelidir. Production configuration ayrı secret ve configuration yönetimiyle sağlanmalıdır.

.env.example

.env.example uygulamanın hangi environment anahtarlarına ihtiyaç duyduğunu gösterir. Gerçek password veya API key içermez. Yeni geliştirici dosyayı kopyalayıp local değerlerini oluşturabilir. Her variable kısa açıklamayla dokümante edilebilir. Kullanılmayan anahtarlar zamanla temizlenmelidir.

compose.override.yaml

Override dosyası development'a özel davranışları temel Compose modelinin üzerine eklemek için kullanılabilir. Source mount ve debugger portu burada tanımlanabilir. Production dosyası bu ayarları taşımak zorunda kalmaz. Birden fazla dosyanın merge davranışı iyi anlaşılmalıdır. Final configuration her environment için ayrıca doğrulanmalıdır.

compose.production.yaml

Production Compose dosyası immutable image, healthcheck ve controlled resource ayarlarına odaklanmalıdır. Source code bind mount bulunmamalıdır. Image mümkünse digest üzerinden sabitlenmelidir. Secret ve log ayarları production gereksinimine göre düzenlenmelidir. Base Compose ile hangi alanların override edildiği açık tutulmalıdır.

.devcontainer/devcontainer.json

devcontainer.json development container içinde IDE deneyimini tanımlamak için kullanılabilir. Extension, forwarded port ve post create komutları belirtilebilir. Compose servislerinden biri development environment olarak seçilebilir. Non root user ayarı developer permission problemlerini azaltabilir. Bu dosya yeni ekip üyesinin hazır tooling ile başlamasını kolaylaştırır.

Dockerfile Nasıl Çalışır?

Dockerfile yukarıdan aşağıya değerlendirilen image build talimatlarından oluşur. Her talimat aynı türde layer üretmek zorunda olmasa da build cache davranışı talimat sırasından etkilenir. Docker'ın güncel Dockerfile referansı FROM, RUN, COPY, USER, HEALTHCHECK ve diğer temel talimatları açıkça tanımlar. :contentReference[oaicite:4]{index=4} Dockerfile yalnızca çalışan image üretmemeli, aynı zamanda tekrar üretilebilir ve güvenli artifact sağlamalıdır. Özellikle production build'de build tool ve secret kalıntılarının final image'a taşınmaması gerekir.

FROM

FROM yeni build stage'in temel image'ını belirler. Bir Dockerfile birden fazla FROM kullanarak multi stage build oluşturabilir. Base image sürümü mümkün olduğunca bilinçli seçilmelidir. Floating tag update davranışı kontrol edilmelidir. Production güvenliği için güvenilir ve minimal base tercih edilmelidir.

WORKDIR

WORKDIR sonraki komutların çalışacağı container dizinini tanımlar. Sürekli cd kullanma ihtiyacını azaltır. COPY ve RUN talimatları daha okunabilir hale gelir. Uygulama dosyaları tahmin edilebilir bir path altında tutulur. Permission yapısı seçilen USER ile uyumlu olmalıdır.

COPY

COPY build context içindeki dosyaları image filesystem'ine ekler. Dependency manifest'i source code'dan önce kopyalanarak cache kullanımı iyileştirilebilir. Gereksiz dosyalar .dockerignore ile context dışında tutulmalıdır. COPY --chown non root user ownership sorunlarını azaltabilir. Secret dosya yanlışlıkla image'a kopyalanmamalıdır.

RUN

RUN image build sırasında komut çalıştırır. Package installation ve compilation bununla yapılabilir. Bir build stage'de çalışan komut container runtime başlangıcında tekrar çalışmaz. Cache mount ve secret mount gibi BuildKit özellikleri RUN ile birlikte kullanılabilir. Geçici build dosyalarının final stage'e taşınmaması gerekir.

ENV

ENV image içinde default environment variable tanımlar. Runtime Compose ayarları bu değerleri override edebilir. Password veya token ENV içine yazılmamalıdır. Environment precedence nedeniyle gerçek container değerinin hangi kaynaktan geldiği bilinmelidir. Configuration default'ları ile secret değerler ayrı ele alınmalıdır.

ARG

ARG build sırasında kullanılabilen build time variable tanımlar. Runtime container environment'ına otomatik taşınmaz. Buna rağmen ARG secret saklamak için güvenli yöntem değildir. Build history veya metadata üzerinden hassas değer sızabilir. Secret için BuildKit secret mount tercih edilmelidir.

USER

USER sonraki build ve runtime talimatlarının hangi kullanıcıyla çalışacağını belirleyebilir. Production container'ı root olmayan kullanıcıyla çalıştırmak güçlü varsayılandır. UID ve GID bind mount permission davranışını etkiler. Development user host user ile gerektiğinde eşleştirilebilir. Uygulamanın yalnızca ihtiyaç duyduğu filesystem alanlarına yazabilmesi gerekir.

EXPOSE

EXPOSE image'ın hangi portta dinlemeyi beklediğini dokümante eder. Bu talimat portu host'a otomatik publish etmez. Gerçek host mapping Compose ports veya Docker CLI ile yapılır. Production'da gereksiz port publish edilmemelidir. Internal service portu network içindeki diğer container'lar tarafından servis adıyla kullanılabilir.

CMD

CMD container başlatıldığında kullanılacak default komutu veya argümanları tanımlar. Runtime sırasında override edilebilir. Uygulamanın ana process'i foreground çalışmalıdır. Process kapanırsa container da kapanır. Signal handling için exec form çoğu uygulamada daha doğru davranış sağlar.

ENTRYPOINT

ENTRYPOINT container'ın temel executable davranışını tanımlar. CMD ile birlikte default argüman yapısı oluşturulabilir. Wrapper script kullanılıyorsa signal forwarding doğru yapılmalıdır. Shell form davranışı process sinyallerini etkileyebilir. Container mümkün olduğunca tek ana process modeline uygun tasarlanmalıdır.

HEALTHCHECK

HEALTHCHECK çalışan process'in gerçekten hizmet verebilir durumda olup olmadığını kontrol etmek için kullanılabilir. Docker health state'i starting, healthy veya unhealthy olarak raporlayabilir. Interval, timeout, retries ve start period davranışı ayarlanabilir. Healthcheck başarısızlığı ile process exit aynı olay değildir. Docker'ın güncel referansında health status'un container run state'inden ayrı tutulduğu açıkça belirtilir. :contentReference[oaicite:5]{index=5}

Development Dockerfile Nasıl Tasarlanır?

Development Dockerfile hızlı feedback vermeli ve developer tooling için yeterli araç sağlamalıdır. Source code çoğunlukla mount veya Compose Watch ile güncellenebilir. Debugger ve hot reload development stage'de bulunabilir. Runtime sürümü production ile aynı aileden tutulmalıdır. Developer rahatlığı için production image'ını gereksiz araçlarla büyütmek yerine multi stage yaklaşımı kullanılmalıdır.

Development Dependency'leri

Test runner, linter ve development server gibi dependency'ler development stage'de bulunabilir. Bunların production runtime'a taşınması gerekmez. Package manager lock dosyası kullanılmalıdır. Dependency installation cache dostu sıralanmalıdır. Native paketler container target platformu için kurulmalıdır.

Debug Araçları

Debugger ve network inspection araçları development stage'e eklenebilir. Bu araçlar production attack surface'ini büyütmemelidir. IDE attach ayarları repository'de paylaşılabilir. Debug portu yalnızca local host'a publish edilebilir. Production configuration debug flag'ini kapalı tutmalıdır.

Hot Reload

Hot reload source değiştiğinde uygulamayı hızlı günceller. Framework file watcher container içinde çalışabilir. Source bind mount veya Compose Watch değişiklikleri container'a iletebilir. Dependency manifest değiştiğinde rebuild gerekebilir. Hot reload production'da kullanılmamalıdır.

Source Code Mount

Development'ta source code host'tan container'a bind mount edilebilir. Böylece image her kod değişikliğinde rebuild edilmez. Mount hedefi dependency dizinini yanlışlıkla ezmemelidir. Node.js gibi projelerde node_modules ayrı volume içinde tutulabilir. Compose Watch bazı projelerde daha kontrollü senkronizasyon alternatifi sunar.

Development Server

Development server hızlı reload ve debug özellikleri sağlayabilir. Production server ile aynı davranışı göstermesi beklenmemelidir. Port açıkça Compose üzerinden publish edilmelidir. Host binding genellikle container içinde 0.0.0.0 gerektirir. Production performansı development server ile ölçülmemelidir.

Debugger Portu

Debugger portu yalnızca ihtiyaç duyulduğunda publish edilmelidir. Host üzerinde loopback interface'e bağlamak güvenliği artırabilir. Shared network'te debug portunu herkese açmak doğru değildir. IDE configuration aynı portu kullanacak şekilde tanımlanabilir. Production Compose dosyasında debugger portu bulunmamalıdır.

Non-Root Development User

Development container'ı da mümkün olduğunca non root kullanıcıyla çalıştırılmalıdır. Bind mount file ownership problemleri UID eşlemesiyle azaltılabilir. Developer toolchain bu kullanıcının home dizinine kurulabilir. Root gerektiren kurulumlar image build aşamasında yapılabilir. Runtime sırasında sürekli sudo ihtiyacı oluşmaması hedeflenmelidir.

Production Dockerfile Nasıl Tasarlanır?

Production Dockerfile geliştirme kolaylığından çok güvenilir runtime oluşturmaya odaklanır. Final image yalnızca uygulamanın çalışması için gereken bileşenleri taşımalıdır. Source code veya build tool gerekiyorsa yalnızca gerçekten runtime ihtiyacı olan parçalar final stage'e alınmalıdır. Non root user ve minimum filesystem permission uygulanmalıdır. Multi stage build bu ayrımı kurmanın en kullanışlı yöntemlerinden biridir.

Minimal Runtime

Final runtime image gereksiz compiler ve development package taşımamalıdır. Daha az package daha küçük güncelleme ve güvenlik yüzeyi sağlayabilir. Minimal olmak debug edilemez olmak anlamına gelmez. Observability uygulama log ve metric'leri üzerinden sağlanabilir. Incident için ayrı diagnostic image veya ephemeral araç kullanılabilir.

Immutable Application Code

Production code image içinde sabit artifact olarak bulunmalıdır. Host source bind mount ile canlı dosya değiştirilmemelidir. Yeni sürüm için yeni image build edilmelidir. Böylece hangi kodun çalıştığı digest üzerinden izlenebilir. Manuel container içi düzenleme deployment standardını bozar.

Development Dependency'lerini Kaldırmak

Test runner ve hot reload araçlarının production image'da bulunması gerekmez. Package manager production dependency kurulumu destekliyorsa ilgili seçenek kullanılabilir. Unused dependency güvenlik finding sayısını da artırabilir. Build stage ile runtime stage ayrılabilir. Final image içerikleri düzenli olarak incelenmelidir.

Build Araçlarını Runtime'dan Çıkarmak

Compiler ve build chain final container'da çoğu zaman gerekli değildir. Multi stage build artifact'ı build stage'den runtime'a kopyalar. Böylece image küçülebilir. Docker resmi belgeleri multi stage build'in final image'dan gereksiz build bileşenlerini ayırmak için kullanılabileceğini belirtir. :contentReference[oaicite:6]{index=6} Bu ayrım özellikle derlenen uygulamalarda büyük fayda sağlar.

Non-Root Kullanıcı

Uygulama root yetkisi gerektirmiyorsa non root user ile çalıştırılmalıdır. File ownership build sırasında ayarlanabilir. Low port veya privileged operation ihtiyacı yeniden sorgulanmalıdır. Root container breakout riskini tek başına çözmez ama etki alanını azaltabilir. Runtime permission en düşük yetki prensibine göre düzenlenmelidir.

Healthcheck

Production healthcheck uygulamanın gerçekten request kabul edebildiğini kontrol etmelidir. Yalnızca process var mı sorusu çoğu web servisi için yeterli değildir. Dependency'nin tamamını health endpoint içinde zorunlu tutmak zincirleme unhealthy davranış yaratabilir. Readiness ve liveness ayrımı orchestrator kullanıldığında ayrıca tasarlanabilir. Probe maliyeti düşük olmalıdır.

Minimum Attack Surface

Gereksiz shell, compiler, debug port ve package attack surface'i büyütebilir. Base image güvenilir kaynaktan seçilmelidir. Image vulnerability scan pipeline içinde çalıştırılabilir. Root olmayan runtime ve read only filesystem ek koruma sağlar. Security tek Dockerfile ayarı değil katmanlı süreç olarak ele alınmalıdır.

Development ve Production Aynı Dockerfile'ı Kullanmalı mı?

Tek doğru cevap yoktur ancak ortak base ve multi stage tasarım çoğu projede iyi denge sağlar. Aynı Dockerfile içinde development, test, build ve production target'ları oluşturulabilir. Böylece runtime sürümü ve temel dependency adımları paylaşılır. Çok farklı build gereksinimleri varsa ayrı Dockerfile da anlamlı olabilir. Önemli olan iki dosyanın zamanla fark edilmeden farklı runtime dünyalarına dönüşmesini önlemektir.

Tek Dockerfile Yaklaşımı

Tek Dockerfile ortak build mantığını merkezi tutar. Farklı stage target'ları environment ihtiyacına göre seçilebilir. Runtime version drift daha az olur. Dosya çok büyürse okunabilirlik azalabilir. Stage isimleri ve ortak base bu sorunu azaltır.

Ayrı Dockerfile Yaklaşımı

Development ve production build süreçleri çok farklıysa ayrı dosyalar daha açık olabilir. Ancak ortak dependency adımları iki yerde tekrar edilebilir. Bir dosya güncellenip diğeri unutulabilir. CI her iki build'i düzenli test etmelidir. Runtime sürümünün aynı kaldığı otomatik kontrol edilebilir.

Multi-Stage Dockerfile

Multi stage build tek Dockerfile içinde birden fazla FROM stage'i tanımlamayı sağlar. Development stage tooling taşıyabilir. Build stage compiler kullanabilir. Production stage yalnızca final artifact'ı alabilir. Docker belgeleri stage'ler arasında seçili artifact kopyalamanın final image'ı sadeleştirdiğini açıklar. :contentReference[oaicite:7]{index=7}

Build Target Kullanımı

Build target belirli stage'e kadar image oluşturmayı sağlar. Development Compose target: development kullanabilir. CI test target'ını ayrıca çalıştırabilir. Production build final runtime target'ını seçebilir. Bu yaklaşım tek Dockerfile'da farklı kullanım amaçlarını açık tutar.

Ortak Base Stage

Base stage ortak runtime ve sistem dependency'lerini tutabilir. Development ve build stage buradan türeyebilir. Bu yapı version parity sağlar. Base'e gereksiz tool eklemek production stage'e sızabilir. Stage inheritance dikkatle tasarlanmalıdır.

Development ve Production Arasında Neler Aynı Kalmalı?

Ana runtime sürümü mümkün olduğunca aynı olmalıdır. Application dependency lock dosyası ortak kullanılmalıdır. API ve database version beklentileri uyumlu kalmalıdır. Build artifact kaynağı aynı commit olmalıdır. Ortam farklılıkları configuration seviyesinde tutulmalıdır.

Neler Farklı Olmalı?

Development debugger ve hot reload kullanabilir. Production minimal runtime ve stricter permission kullanmalıdır. Local source mount production'da olmamalıdır. Development test credentials ile çalışırken production gerçek secret manager kullanabilir. Logging ve resource limitler de ortama göre farklılaşabilir.

Multi-Stage Build Nedir?

Multi stage build Dockerfile içinde birbirinden farklı amaçlara sahip build aşamaları oluşturur. Her FROM yeni stage başlatır ve stage'ler isimlendirilebilir. Build araçları bir stage'de kalırken yalnızca çıktı başka stage'e kopyalanabilir. Bu yöntem production image boyutunu ve gereksiz package sayısını azaltabilir. Docker resmi belgeleri multi stage build'i build ve runtime ortamını ayırmak için önerilen temel yaklaşımlardan biri olarak açıklar. :contentReference[oaicite:8]{index=8}

Base Stage

Base stage ortak runtime veya temel operating system ayarlarını içerir. Diğer stage'ler buradan türeyebilir. Ortak user ve workdir burada tanımlanabilir. Production'a gerekmeyen package base'e eklenmemelidir. Base değişikliği birçok stage'in cache'ini etkileyebilir.

Development Stage

Development stage hot reload ve debugging araçlarını içerebilir. Source mount bu target ile çalıştırılabilir. Development dependency'leri burada kurulur. Production build bu stage'i final artifact olarak kullanmaz. Compose development configuration doğrudan bu target'ı seçebilir.

Build Stage

Build stage compiler ve package manager araçlarını kullanır. Source code buraya kopyalanıp artifact oluşturulur. Build secret gerekiyorsa temporary secret mount tercih edilmelidir. Üretilen artifact final stage'e kopyalanır. Compiler final runtime'a taşınmaz.

Test Stage

Test stage test dependency'lerini ve test komutlarını içerebilir. CI bu stage'i build ederek erken hata yakalayabilir. Test artifact'ları production stage'e kopyalanmak zorunda değildir. Static analysis burada çalıştırılabilir. Runtime stage yalnızca doğrulanmış build çıktısını alır.

Production Runtime Stage

Production runtime stage mümkün olduğunca küçük tutulur. Build stage'den yalnızca çalıştırılabilir artifact alınır. Non root user burada etkinleştirilir. Healthcheck ve runtime command tanımlanır. Development toolchain bu stage'de bulunmaz.

Build Artifact'larını Stage'ler Arasında Kopyalamak

COPY --from belirli stage'deki dosyaları başka stage'e aktarır. Böylece build dependency'leri taşımadan yalnızca sonuç alınabilir. Path'ler açık ve deterministic tutulmalıdır. Artifact checksum CI içinde doğrulanabilir. Final runtime source build ortamına bağımlı kalmamalıdır.

Multi-Stage Build ile Image Boyutunu Küçültmek

Compiler ve package cache final stage dışında bırakılabilir. Dependency production alt kümesi kullanılabilir. Küçük image network transferini azaltabilir. Daha az package vulnerability tarama yüzeyini de düşürebilir. Boyut tek kalite metriği değildir ve çalışabilirlik her zaman önceliklidir.

Development/Production Parity Doğru Nasıl Yorumlanmalı?

Parity iki ortamın her dosyasının ve aracının birebir aynı olması anlamına gelmez. Asıl hedef runtime ve application behavior açısından önemli farkları azaltmaktır. Development hot reload kullanırken production kullanmamalıdır. Production secret ve data doğal olarak development'tan farklıdır. Aynı build artifact'ının test edilip ilerleyen ortamlara promote edilmesi parity açısından güçlü yaklaşımdır.

Ortamları Birebir Aynı Yapmak Gerekir mi?

Hayır, development ve production farklı hedeflere sahiptir. Development hızlı feedback ister. Production güvenlik ve kararlılık ister. Debugger gibi araçlar yalnızca development'ta bulunabilir. Önemli behavior farkları ise bilinçli ve belgeli olmalıdır.

Runtime Sürümünü Aynı Tutmak

Runtime major ve minor sürüm farkları beklenmeyen davranış üretebilir. Ortak Dockerfile base stage bu farkı azaltır. CI aynı runtime üzerinde test çalıştırabilir. Production deployment aynı artifact'ı kullanabilir. Upgrade tek Pull Request ile kontrollü yapılabilir.

Dependency Sürümlerini Aynı Tutmak

Lock file development, CI ve production build'de aynı dependency ağacını hedeflemelidir. Local ortamda rastgele latest install yapılmamalıdır. Deterministic installation komutları kullanılmalıdır. Native dependency target architecture'a göre build edilmelidir. Dependency update ayrı review sürecinden geçebilir.

Development Tooling'in Production'da Olmaması

Debugger ve test runner production runtime gereksinimi değildir. Multi stage build bunları ayırır. Daha küçük runtime bakım maliyetini düşürür. Security scan daha az gereksiz finding üretir. Development deneyimi bundan olumsuz etkilenmek zorunda değildir.

Hot Reload'un Production'da Olmaması

Production container source değişikliği izlememelidir. Değişiklik yeni immutable image ile gelmelidir. Hot reload process ve filesystem davranışını farklılaştırabilir. Production deployment kontrollü recreate veya rollout ile yapılmalıdır. Böylece değişiklik geçmişi digest üzerinden izlenebilir.

Configuration'ın Ortama Göre Değişmesi

Database URL, domain ve log level ortam bazında farklı olabilir. Bu değerler image içine hardcode edilmemelidir. Environment variable veya secret mechanism kullanılabilir. Production secret local repository'ye konulmamalıdır. Configuration sözleşmesi aynı kalırken değerler ortama göre değişebilir.

Aynı Build Artifact'ını Kullanmak

CI'da bir kez build edilen image test ortamında kullanılabilir. Aynı digest staging'e promote edilebilir. Production için yeniden build yapılmaması supply chain farklarını azaltır. Ortama özel yalnızca configuration değişir. Build once promote everywhere modeli bu prensibi somutlaştırır.

Build Once, Promote Everywhere Yaklaşımı

Build once yaklaşımı source code'dan tek bir immutable image üretmeyi ve bu image'ı testten production'a kadar aynı artifact olarak kullanmayı hedefler. Her ortamda yeniden build yapmak farklı dependency veya base image sonucu üretebilir. Digest belirli image içeriğini tanımlar ve deployment kaydında saklanabilir. Staging'de test edilen digest doğrudan production'a promote edilir. Configuration ve secret değerleri image dışında tutulduğu için aynı artifact farklı ortamlarda güvenli biçimde çalışabilir.

Koddan Image Oluşturmak

CI belirli commit'ten Docker image oluşturur. Build input'ları mümkün olduğunca sabit tutulur. Dockerfile ve lock dosyası source control içindedir. Build sonucuna commit metadata eklenebilir. Image scan işleminden sonra registry'ye gönderilir.

CI'da Tek Kez Build Etmek

Production için ikinci kez build yapılmaz. Aynı artifact önce test ortamına çıkar. Test başarılı olursa promotion devam eder. Böylece ortamlar arasındaki artifact farkı ortadan kalkar. CI build log'u audit kaydı sağlar.

Image Digest Oluşturmak

Registry image içeriğini digest ile adresleyebilir. Tag yeniden başka içeriğe işaret edebilir ancak digest belirli content'i temsil eder. Deployment manifest digest saklayabilir. Rollback eski digest'e dönebilir. Image identity açısından tag'den daha güçlü referanstır.

Test Ortamında Aynı Image'ı Kullanmak

Integration test deploy edilen gerçek image üzerinde çalışabilir. Local source mount test artifact'ını değiştirmemelidir. Test configuration ayrı verilir. Başarılı test sonucu digest ile ilişkilendirilir. Aynı image staging'e gönderilir.

Staging'de Aynı Image'ı Kullanmak

Staging production'a yakın configuration ile çalışabilir. Image yeniden build edilmez. Migration ve smoke test burada doğrulanır. Performance ve integration sinyalleri gözlenebilir. Onaylanan digest production promotion adayına dönüşür.

Production'a Aynı Digest'i Promote Etmek

Production deployment image tag'i yeniden build etmez. Onaylanan digest kullanılır. Deployment kaydı digest ve configuration version içerebilir. Rollback hedefi netleşir. Supply chain izlenebilirliği güçlenir.

Ortama Göre Yalnızca Configuration'ı Değiştirmek

API endpoint, database credential ve domain gibi değerler environment'a göre değişir. Image bu değerleri içine gömmez. Secret manager production credential sağlar. Development dummy değerler kullanabilir. Application aynı configuration contract'ını korur.

Docker Compose ile Çoklu Servis Geliştirme Ortamı

Docker Compose full stack uygulamayı oluşturan servisleri tek model içinde yönetmeyi kolaylaştırır. Web, API, database, cache ve worker ayrı container'lar halinde tanımlanabilir. Servisler ortak network üzerinden birbirini isimle bulabilir. Volume ve healthcheck tanımları repository'de tutulabilir. Docker Compose ile yerel geliştirme ortamı nasıl oluşturulur sorusunun temel cevabı bu servis sözleşmesini basit ve tekrar üretilebilir şekilde kurmaktır.

services

services Compose uygulamasındaki container tabanlı bileşenleri tanımlar. Her servis build veya hazır image kullanabilir. Service adı internal DNS ismi olarak kullanılabilir. Environment ve volume ayarları servis altında tutulur. Gereksiz servisler profile ile optional hale getirilebilir.

build

build servis image'ının local source'dan nasıl oluşturulacağını belirtir. Context ve Dockerfile yolu burada seçilebilir. Multi stage target belirlenebilir. Build args ve secrets kontrollü şekilde aktarılabilir. Development servisleri genellikle build tanımı kullanır.

image

image kullanılacak image referansını belirtir. Registry tag veya digest kullanılabilir. Production'da prebuilt image tercih edilir. Local development bazı dependency servislerinde hazır image kullanabilir. Version sabitlemek beklenmeyen upgrade riskini azaltır.

ports

ports container portunu host üzerinde yayınlar. Her internal service portunu publish etmek gerekmez. Database yalnızca backend tarafından kullanılıyorsa private network yeterli olabilir. Development debugger portları local kullanım için açılabilir. Production'da attack surface'i azaltmak için yalnızca gerekli giriş portları yayınlanmalıdır.

environment

environment container içine environment variable aktarır. Açık configuration için uygundur. Secret değerler için Compose secrets daha kontrollü model sağlayabilir. Aynı variable farklı kaynaklarda tanımlanırsa precedence devreye girer. Docker'ın güncel belgeleri environment, env_file ve image ENV arasında belirli öncelik sırası tanımlar. :contentReference[oaicite:9]{index=9}

env_file

env_file bir veya birden fazla dosyadan environment değerleri yükleyebilir. Development configuration'ı Compose dosyasından ayırmayı kolaylaştırır. Dosya sırası override davranışını etkileyebilir. Production secret'larını düz metin env dosyasında bırakmak uygun değildir. Örnek environment dosyaları gerçek secret içermemelidir.

volumes

volumes persistent data veya host dosya paylaşımı için kullanılır. Source code development'ta bind mount olabilir. Database data named volume üzerinde tutulabilir. Production application code image içinde kalmalıdır. Volume lifecycle container lifecycle'dan bağımsız düşünülmelidir.

networks

networks servis iletişim sınırlarını tanımlar. Frontend ve backend farklı network'lerde tutulabilir. Database private network'e bağlanabilir. Reverse proxy iki network arasında kontrollü giriş noktası olabilir. Network segmentation production güvenliğini destekler.

depends_on

depends_on servislerin oluşturulma sırasını ifade eder. Ancak container'ın başlaması servisin hazır olduğu anlamına gelmez. Docker resmi belgeleri readiness için healthcheck ve condition: service_healthy kullanılabileceğini açıklar. :contentReference[oaicite:10]{index=10} Uygulama yine de dependency bağlantılarında retry yapabilmelidir. Startup order resilience yerine geçmez.

healthcheck

Compose healthcheck servis readiness veya sağlık durumunu gözlemek için kullanılabilir. Test komutu container içinde çalışır. Interval, timeout, retries ve start period ayarlanabilir. Dependency servisleri service healthy koşuluyla beklenebilir. Healthcheck hafif ve güvenilir olmalıdır.

restart

restart container process'i durduğunda Docker'ın nasıl davranacağını tanımlar. Always, on failure ve unless stopped gibi politikalar bulunur. Restart policy unhealthy state'i tek başına self healing olarak yorumlamaz. Docker restart policy esas olarak container exit durumuna bağlıdır. :contentReference[oaicite:11]{index=11} Production davranışı uygulamanın failure modeline göre seçilmelidir.

Örnek Full-Stack Docker Geliştirme Mimarisi

Tipik full stack development ortamı frontend, API, database ve cache servislerinden oluşabilir. Background worker ve mail test servisi gibi parçalar optional profile olarak eklenebilir. Reverse proxy local domain veya TLS ihtiyacını yönetebilir. Her servis için ayrı Dockerfile veya ortak build stage kullanılabilir. Hedef developer'ın tek komutla gerçek uygulama topolojisine yakın fakat güvenli local ortamı başlatabilmesidir.

Frontend Container

Frontend container development server ve hot reload kullanabilir. Source Compose Watch veya bind mount ile güncellenebilir. node_modules container platformunda tutulmalıdır. API adresi service veya proxy üzerinden configuration ile verilebilir. Production build statik artifact olarak ayrı runtime'a taşınabilir.

Backend API Container

Backend API runtime ve application dependency'lerini içerir. Database'e servis adıyla bağlanır. Development debugger gerektiğinde port üzerinden IDE'ye açılabilir. Health endpoint local stack tarafından kullanılabilir. Production target development tooling taşımamalıdır.

PostgreSQL Container

PostgreSQL development database olarak named volume kullanabilir. Version açık biçimde pin edilmelidir. Healthcheck readiness'i kontrol eder. Host port yalnızca gerçekten local tool erişimi gerekiyorsa publish edilir. Production database için backup ve availability gereksinimleri ayrıca değerlendirilmelidir.

Redis Container

Redis cache veya queue dependency'si olarak kullanılabilir. Internal network üzerinden backend ve worker erişebilir. Data persistence development ihtiyacına göre açık veya kapalı olabilir. Healthcheck basit ping ile sağlanabilir. Production persistence ve memory policy ayrı tasarlanmalıdır.

Background Worker

Worker aynı application image'ını farklı command ile kullanabilir. Queue service üzerinden işler alınır. Development logları terminalde görülebilir. Worker restart behavior API'den farklı olabilir. Production scaling ihtiyacı workload metric'lerine göre belirlenir.

Reverse Proxy

Reverse proxy local frontend ve backend routing işlemini tek giriş portunda birleştirebilir. Internal service isimlerini upstream olarak kullanabilir. TLS development certificate gerekiyorsa local güven modeli oluşturulabilir. Production proxy yalnızca gerekli network'lere bağlanmalıdır. Proxy configuration source control içinde tutulabilir.

Mail Testing Service

Development mail testing servisi gerçek müşterilere e posta gönderilmesini önler. Application SMTP configuration local service'e yönlendirilir. Web arayüzü developer tarafından host port üzerinden açılabilir. Bu servis production profile'da başlamamalıdır. Test verisi gerçek kişisel adresler içermemelidir.

Debug Araçları

Database admin veya tracing aracı development profile'a eklenebilir. Default stack'te gereksiz servis çalıştırılmamalıdır. Debug araçları production network'e taşınmamalıdır. Her araç ayrı port ve permission ihtiyacı doğurur. Profiles bu servisleri ihtiyaç anında etkinleştirmeyi kolaylaştırır.

Docker Compose Network Nasıl Çalışır?

Compose varsayılan olarak uygulama servisleri için ortak bir network oluşturabilir. Aynı network üzerindeki servisler birbirlerini servis adıyla çözebilir. Container IP adreslerini uygulama configuration'ına yazmak gerekmez. Host ile container trafiği ise port publish davranışı üzerinden yönetilir. Bu ayrımı anlamak Docker network sorunlarının büyük bölümünü çözmeyi kolaylaştırır.

Default Bridge Network

Compose project kendi default network'ünü oluşturabilir. Servisler aksi belirtilmedikçe bu network'e bağlanır. Aynı host üzerindeki başka Compose project kendi network alanına sahip olabilir. Project name resource isimlerini ayrıştırır. Daha sıkı segmentation için ek network'ler tanımlanabilir.

Service Discovery

Compose servis adı network içinde discovery için kullanılabilir. API container db adıyla database'e bağlanabilir. Container yeniden oluşturulduğunda IP değişse bile service name değişmez. Application configuration bu nedenle IP yerine logical name kullanmalıdır. Discovery network scope'u içinde çalışır.

Container DNS

Docker network container'lar için internal DNS çözümleme sağlar. Service name uygun container adresine çözülür. Application standard DNS client mekanizmasını kullanabilir. Hardcoded hosts file ihtiyacı azalır. Network alias gerektiğinde ek isim sağlayabilir.

Servis Adıyla Bağlantı

Database URL örneğin postgres://db:5432/app biçiminde olabilir. Buradaki db Compose service adıdır. Host makineden aynı isim otomatik çözülmeyebilir. Host bağlantısında published port kullanılır. Environment'a göre connection string farklı olabilir.

Container IP'sini Hardcode Etmemek

Container IP yeniden oluşturma sırasında değişebilir. Hardcode edilen IP deployment'ı kırılgan hale getirir. Service discovery daha kararlı abstraction sağlar. Static IP yalnızca özel network gereksinimlerinde düşünülmelidir. Application config logical endpoint kullanmalıdır.

Host'tan Container'a Bağlantı

Host uygulaması container'a published host port üzerinden ulaşır. Örneğin database 127.0.0.1:5433 üzerinden erişilebilir. Internal container port farklı olabilir. Port mapping yalnızca development ihtiyacı varsa açılmalıdır. Production database çoğu durumda public host portuna çıkarılmamalıdır.

Container'dan Host'a Bağlantı

Container içinden host üzerindeki servise erişim platforma göre özel hostname veya gateway gerektirebilir. localhost container'ın kendi loopback interface'idir. Development external tool bağlantısı için platform tarafından sağlanan host gateway mekanizması kullanılabilir. Production architecture host service dependency'sini mümkün olduğunca azaltmalıdır. Environment configuration bu farkı gizleyebilir.

Docker'daki “localhost” Tuzağı

Docker öğrenirken en sık yaşanan sorunlardan biri container içindeki localhost'un yanlış yorumlanmasıdır. Bir container içinde localhost o container'ın kendi network namespace'ini ifade eder. Database başka container'daysa backend localhost:5432 üzerinden ona ulaşamaz. Compose service name kullanılmalıdır. Host'tan container'a erişim ise publish edilen port üzerinden yapılır.

Container İçindeki localhost Neyi Gösterir?

Container içindeki localhost aynı container'ın loopback adresidir. Başka container bu adresin arkasında bulunmaz. API ve database ayrı container ise farklı endpoint gerekir. Bir service aynı container içinde birden fazla process çalıştırıyorsa localhost kullanılabilir. Ancak single process container yaklaşımı daha yaygındır.

API Container'dan Database'e Bağlantı

API database ile ortak Compose network'ünde bulunmalıdır. Connection host olarak database service name kullanılabilir. Port internal database portudur. Host port publish edilmesi API bağlantısı için gerekli değildir. Authentication secret environment'tan veya secret file'dan alınmalıdır.

db:5432 Kullanımı

db:5432 Compose içindeki database servisine ulaşmanın tipik örneğidir. db DNS tarafından çözülen service adıdır. 5432 container'ın dinlediği internal porttur. Host mapping başka bir port olsa bile container'lar internal portu kullanır. Bu ayrım environment config içinde açık tutulmalıdır.

Host Uygulamasından Docker Database'e Bağlantı

IDE veya host application database'e erişecekse port publish edilmelidir. Örneğin host 5433 container 5432'ye map edilebilir. Connection string localhost:5433 kullanır. Port yalnızca loopback interface'e bağlanabilir. Production'da bu mapping çoğunlukla kaldırılmalıdır.

Ortama Göre Farklı Connection String Yönetimi

Development Compose service name kullanabilir. Host tabanlı test farklı endpoint kullanabilir. Staging ve production managed database DNS adı kullanabilir. Application kodu endpoint'i hardcode etmemelidir. Environment variable aynı config anahtarına farklı değer sağlar.

Docker Network İzolasyonu Nasıl Yapılır?

Network izolasyonu servislerin yalnızca ihtiyaç duydukları bileşenlerle konuşmasını hedefler. Frontend doğrudan database'e erişmek zorunda değildir. Backend private network üzerinden database'e bağlanabilir. Reverse proxy public giriş ile internal application network arasında kontrollü köprü olur. Bu tasarım aynı zamanda Docker container ortamlarında volume network secret ve environment variable yönetimi konusunun network bölümünü somutlaştırır.

Frontend Network

Frontend yalnızca reverse proxy veya backend API ile konuşabilir. Database network'üne eklenmesi gerekmez. Development server host'a port publish edebilir. Production statik frontend proxy üzerinden sunulabilir. Network üyeliği service ihtiyacına göre minimum tutulmalıdır.

Backend Network

Backend API ve worker private backend network'ünde çalışabilir. Database ve cache bu network'e bağlanabilir. Public internetten doğrudan backend portu açılmayabilir. Reverse proxy aynı backend network'e kontrollü biçimde bağlanır. Security group veya host firewall da ek katman sağlar.

Internal Network

Compose internal network external erişimi sınırlandırmak için kullanılabilir. Database gibi servisler yalnızca internal communication yapabilir. External package erişimi gereken build işlemi runtime network'ten ayrılabilir. Uygulama ihtiyaçları doğrulanmadan tüm egress'i kesmek sorun çıkarabilir. Network policy gerçek dependency haritasına dayanmalıdır.

Database'i Public Network'ten Ayırmak

Database doğrudan internet girişine ihtiyaç duymaz. Backend ve migration job özel network üzerinden erişebilir. Host port production'da publish edilmemelidir. Administrative erişim ayrı güvenli kanal üzerinden yapılabilir. Bu model yanlışlıkla açık database riskini azaltır.

Reverse Proxy'yi İki Network'e Bağlamak

Proxy public edge network ve private application network arasında yer alabilir. Client yalnızca proxy portuna ulaşır. Backend doğrudan public network'e bağlanmaz. Proxy service discovery ile backend adını çözebilir. TLS ve request limitleri bu katmanda yönetilebilir.

Container'ların Gereksiz Internet Erişimini Sınırlandırmak

Bazı production workload'ları yalnızca internal service'lere ihtiyaç duyar. Gereksiz outbound internet erişimi azaltılabilir. Ancak dependency API kullanan servisler kontrollü egress ister. Network kısıtı logging ve update akışını da etkileyebilir. Tasarım uygulama dependency haritasına göre yapılmalıdır.

Port Mapping Nasıl Yönetilmeli?

Port mapping container'ın internal dinleme portunu host üzerinden erişilebilir hale getirir. Development'ta web, debugger veya database portları geliştirici araçları için yayınlanabilir. Production'da yalnızca gerçekten dışarı açılması gereken girişler publish edilmelidir. Internal service communication host portuna ihtiyaç duymaz. Birden fazla project aynı host üzerinde çalışıyorsa project bazlı host port değerleri kullanılabilir.

Container Port

Container port uygulamanın network namespace içinde dinlediği porttur. EXPOSE bu portu dokümante edebilir. Internal network trafiği doğrudan bu porta gider. Host portuyla aynı olmak zorunda değildir. Service discovery ile servis adı birlikte kullanılır.

Host Port

Host port dışarıdan container'a giriş sağlar. Aynı host port aynı interface üzerinde iki service tarafından kullanılamaz. Local development'ta farklı project'ler farklı host port seçebilir. Production proxy tek public port kullanabilir. Database host portu gereksizse açılmamalıdır.

Development Portları

Development web server portu host'a publish edilir. Birden fazla repository için environment variable ile değiştirilebilir. Port README yerine .env.example içinde gösterilebilir. Loopback binding local güvenliği artırabilir. Team default'u çakışmayacak aralıkta seçilebilir.

Debug Portları

Debugger portları yalnızca development profile'da açılmalıdır. IDE attach ayarı bu portla eşleşir. Public network interface'e bağlanmamalıdır. Production Compose override debug portunu kaldırmalıdır. Debug service ayrıca profile altında tutulabilir.

Database Portları

Database'e yalnızca container service'ler erişiyorsa host portu gerekli değildir. Local GUI tool kullanılıyorsa loopback port publish edilebilir. Host port default database portundan farklı seçilebilir. Credential development için ayrı olmalıdır. Production database public portu kapalı tutulmalıdır.

Production'da Gereksiz Portları Yayınlamamak

Her published port yeni erişim yüzeyi oluşturur. Internal cache veya worker portu dışarı açılmamalıdır. Reverse proxy kontrollü ingress sağlar. Host firewall ek koruma sunabilir. Port listesi production checklist içinde doğrulanmalıdır.

Birden Fazla Projede Port Çakışmasını Önlemek

Compose file host portu environment variable üzerinden alabilir. Project A ve Project B farklı değer kullanabilir. Dynamic port bazı test senaryolarında tercih edilebilir. Compose project name internal resource isimlerini ayırır ancak host port çakışmasını tek başına çözmez. Onboarding script kullanılabilir uygun portları kontrol edebilir.

Bind Mount ve Named Volume Arasındaki Fark

Bind mount host üzerindeki belirli dosya veya klasörü container içine bağlar. Named volume ise Docker tarafından yönetilen persistent storage alanıdır. Docker resmi belgeleri volume'ların Docker tarafından yönetildiğini, bind mount'ların ise host path yapısına doğrudan bağlı olduğunu belirtir. :contentReference[oaicite:12]{index=12} Source code development'ta bind mount için doğal adaydır. Database data ise çoğu local stack'te named volume üzerinde daha rahat yönetilir.

Bind Mount

Bind mount host path'i container path'e bağlar. Host editöründe yapılan değişiklik anında container tarafından görülebilir. Source code geliştirme için kullanışlıdır. Host filesystem permission ve platform performansı etkileyebilir. Sensitive host klasörleri gereksiz yere mount edilmemelidir.

Named Volume

Named volume Docker tarafından oluşturulur ve yönetilir. Container silinse bile volume varlığını sürdürebilir. Database data için sık kullanılır. Host path yapısına daha az bağımlıdır. Backup yine application data semantics'e göre planlanmalıdır.

Anonymous Volume

Anonymous volume explicit kullanıcı adı olmadan oluşturulur. Container lifecycle sonrasında kolay unutulabilir. Bazı dependency klasörlerini bind mount etkisinden korumak için kullanılabilir. Ancak named volume yönetim açısından daha anlaşılırdır. Cleanup sırasında veri ihtiyacı kontrol edilmelidir.

Source Code İçin Hangisi?

Source code development'ta bind mount veya Compose Watch kullanılabilir. Bind mount en basit canlı paylaşımı sağlar. Büyük dependency klasörleri performans sorununa yol açabilir. Compose Watch daha kontrollü sync yapabilir. Project ve host platformu kararı etkiler.

Database İçin Hangisi?

Development database için named volume genellikle daha uygundur. Data container recreate işleminden etkilenmez. Host database file formatına doğrudan dokunulmaz. Version upgrade sırasında volume compatibility kontrol edilmelidir. Production backup yalnızca volume copy işlemine dayandırılmamalıdır.

Production'da Bind Mount Kullanımı

Production'da configuration veya özel host entegrasyonu için bind mount gerekebilir. Application source code için bind mount kullanılmaması daha iyi modeldir. Read only mount mümkün olduğunda tercih edilebilir. Host path dependency deployment taşınabilirliğini azaltır. Persistent business data için harici database veya managed storage daha güçlü seçenek olabilir.

Hot Reload Nasıl Çalışır?

Hot reload geliştirici source dosyasını kaydettiğinde çalışan uygulamanın değişikliği kısa sürede görmesini sağlar. Containerized development'ta dosya değişikliği container içine aktarılmalıdır. Bind mount doğrudan shared filesystem görünümü sağlarken Compose Watch seçili değişiklikleri senkronize edebilir. Uygulamanın kendi development server'ı değişikliği algılayıp reload yapar. Dependency veya build configuration değişiklikleri ise çoğunlukla image rebuild gerektirir.

Host Dosya Değişikliklerini Container'a Aktarmak

Bind mount host path'i doğrudan container'a yansıtır. Compose Watch değişen dosyaları kural bazlı sync edebilir. Remote development farklı filesystem paylaşım mekanizması kullanabilir. File ownership doğru olmalıdır. Generated output gereksiz senkronize edilmemelidir.

Bind Mount ile Hot Reload

Source klasörü application çalışma dizinine mount edilir. File watcher değişikliği container içinde görür. Bazı platformlarda polling gerekebilir. node_modules benzeri directory ayrı tutulabilir. Production'da bu mount kaldırılır.

Node.js

Node.js development server'ları file watcher ile reload sağlayabilir. Native module'ler host ile container arasında paylaşılmamalıdır. node_modules named volume veya image içinde tutulabilir. package manifest değişince rebuild yapılabilir. Compose Watch bu workflow için kullanışlıdır.

Python

Python web framework development server'ları reload destekleyebilir. Source sync sonrası process otomatik yeniden başlayabilir. Virtual environment host'tan mount edilmemelidir. requirements veya lock dosyası değişince dependency layer rebuild edilmelidir. Production WSGI veya ASGI server development server'dan ayrı tutulabilir.

Go

Go uygulaması source değişiminde yeniden compile edilmelidir. Development watcher build ve restart işlemini otomatikleştirebilir. Build cache volume olarak tutulabilir. Final production image yalnızca binary taşıyabilir. Multi stage build Go için güçlü küçültme sağlar.

Java

Java development container build tool cache'ini volume üzerinde tutabilir. Framework hot reload özelliği kullanılabilir. Source değişikliği incremental compile gerektirebilir. JDK development stage'de bulunurken production yalnızca uygun runtime kullanabilir. Debug portu local profile'da açılabilir.

Frontend Framework'leri

Modern frontend framework'leri development server üzerinden hızlı module update sağlayabilir. Source değişikliklerinin container'a hızlı ulaşması önemlidir. Dependency klasörleri platforma özel native binary içerebilir. Compose Watch ignore kuralı bu klasörleri dışarıda bırakabilir. Production output statik build artifact olarak servis edilebilir.

Docker Compose Watch Nedir?

Compose Watch source değişikliklerini izleyip service container'larını sync, restart veya rebuild gibi aksiyonlarla güncelleyebilen development özelliğidir. Docker'ın güncel belgelerine göre develop.watch Compose 2.22.0 ve sonrası için tanımlanmış bir development özelliğidir. :contentReference[oaicite:13]{index=13} Bu yöntem bind mount'un yerini her durumda almak zorunda değildir. Özellikle native dependency veya büyük file tree bulunan projelerde daha kontrollü senkronizasyon sağlar.

develop.watch

develop.watch service için file değişiklik kurallarını tanımlar. Her kural path ve action içerir. Target container içindeki hedef yolu belirtir. Ignore listesi gereksiz dosyaları dışarıda bırakır. Yalnızca local build kullanan uygun servislerde etkinleştirilmelidir.

sync

sync değişen dosyayı container hedef dizinine kopyalar. Application watcher değişikliği kendisi algılayabilir. Container recreate gerekmez. Source code için hızlı feedback sağlar. Dependency manifest gibi dosyalar genellikle rebuild aksiyonu ister.

sync+restart

sync+restart dosyayı senkronize eder ve ardından container'ı yeniden başlatır. Runtime configuration değişikliği için kullanışlıdır. Uygulama kendi reload özelliğine sahip değilse çözüm sağlayabilir. Restart süresi rebuild'den daha kısadır. Stateful servislerde gereksiz kullanımdan kaçınılmalıdır.

rebuild

rebuild service image'ını yeniden build eder ve container'ı günceller. Dependency manifest değişiklikleri için uygundur. Build cache iyi tasarlandıysa işlem hızlı olabilir. Source dosyalarının her değişiminde rebuild gereksiz maliyet yaratır. Kural path bazında seçilmelidir.

restart

restart service container'ını mevcut image ile yeniden başlatır. Dosya sync gerektirmeyen external configuration senaryolarında kullanılabilir. Process yeniden başlangıç behavior'ı test edilebilir. Development feedback süresi kısa tutulmalıdır. Production rollout mekanizmasıyla karıştırılmamalıdır.

ignore

ignore watch path içindeki belirli dosyaları senkronizasyondan çıkarır. node_modules ve build output sık adaylardır. Docker belgeleri ignore davranışının Watch kuralı kapsamındaki path'e göre değerlendirildiğini belirtir. :contentReference[oaicite:14]{index=14} Büyük dosya ağaçlarını dışarıda bırakmak I/O maliyetini azaltabilir. Secret ve local config dosyaları da gerektiğinde ignore edilmelidir.

initial_sync

initial_sync Watch başlangıcında host ve container içeriğini eşitlemeye yardımcı olur. Docker'ın güncel Watch örneklerinde bu seçenek desteklenir. :contentReference[oaicite:15]{index=15} Başlangıç state farklarını azaltır. Image içinde source kopyası bulunsa bile local dosyalar güncellenebilir. Kullanım projenin build modeline göre seçilmelidir.

docker compose up --watch

docker compose up --watch stack'i başlatır ve Watch modunu etkinleştirir. Docker belgeleri bu komutu Watch workflow'unun standart yollarından biri olarak gösterir. :contentReference[oaicite:16]{index=16} Alternatif olarak docker compose watch ayrı komut olarak kullanılabilir. Service loglarını watch output'undan ayırmak isteyen ekipler ikinci yöntemi tercih edebilir. Repository README tek komutlu development başlangıcını bu davranış üzerine kurabilir.

Compose Watch mı Bind Mount mı?

Bind mount ve Compose Watch birbirinin kesin alternatifi değildir. Bind mount doğrudan filesystem paylaşımı sağlar ve birçok Linux development ortamında oldukça basittir. Compose Watch ise hangi dosyanın sync, restart veya rebuild tetikleyeceğini daha kontrollü tanımlayabilir. Docker'ın belgeleri Watch özelliğini bind mount'a eşlik eden development seçeneği olarak açıklar. :contentReference[oaicite:17]{index=17} Karar host platformu, project büyüklüğü ve dependency yapısına göre verilmelidir.

Bind Mount Avantajları

Kurulumu basittir ve dosya değişiklikleri doğrudan görünür. Editör ayrı bir sync mekanizmasına ihtiyaç duymaz. Linux host'ta performans genellikle güçlüdür. Existing tooling çoğunlukla sorunsuz çalışır. Dependency klasörlerini dikkatli yönetmek gerekir.

Compose Watch Avantajları

File path bazında farklı action tanımlanabilir. Native dependency klasörleri ignore edilebilir. Source sync ve configuration restart ayrılabilir. Package manifest değiştiğinde otomatik rebuild yapılabilir. Cross platform development'ta daha kontrollü davranış sağlayabilir.

Dosya Sistemi Performansı

Büyük bind mount bazı desktop platformlarında yüksek I/O maliyeti yaratabilir. Watch yalnızca değişen dosyaları sync ederek bu yükü azaltabilir. Linux native filesystem'de fark daha küçük olabilir. Monorepo için path kapsamı sınırlandırılmalıdır. Karar benchmark ile verilmelidir.

Native Dependency Sorunları

Host işletim sistemi için derlenen binary container Linux içinde çalışmayabilir. Apple Silicon ile amd64 farkı da aynı problemi büyütebilir. Dependency klasörleri host'tan mount edilmemelidir. Named volume veya container install kullanılabilir. Watch ignore kuralı bu dizinleri koruyabilir.

node_modules

node_modules çok sayıda dosya ve native addon içerebilir. Host node_modules container dizinini ezmemelidir. Named volume container dependency'lerini saklayabilir. Compose Watch source'u sync ederken node_modules'u ignore edebilir. Docker belgeleri de bu klasörün platform portability nedeniyle senkronize edilmemesini önerir. :contentReference[oaicite:18]{index=18}

Python Virtual Environment

Python virtual environment host platformuna ve interpreter path'ine bağlı olabilir. Host venv container içine bind mount edilmemelidir. Dependency container image veya volume içinde kurulabilir. Source ayrı sync edilir. requirements değişimi rebuild tetikleyebilir.

Hangi Projede Hangisi Kullanılmalı?

Küçük Linux projesinde bind mount en basit çözüm olabilir. Büyük Node.js monorepo'da Watch daha iyi performans sağlayabilir. IDE veya framework behavior ayrıca test edilmelidir. Team farklı host platformları kullanıyorsa portable çözüm tercih edilmelidir. Gereksiz araç değişimi yerine ölçülen problemi çözmek hedeflenmelidir.

node_modules ve Native Dependency Sorunu

JavaScript dependency'leri yalnızca JavaScript dosyalarından oluşmayabilir. Bazı paketlar native binary veya platforma özel build çıktısı taşır. Host Windows veya macOS üzerinde kurulan node_modules Linux container'da çalışmayabilir. Bind mount application dizinini tamamen örterse image içinde kurulmuş dependency'ler de görünmez hale gelebilir. Bu nedenle dependency alanını source paylaşımından ayrı tutmak gerekir.

Host OS ve Container OS Farkı

Host işletim sistemi container işletim sistemiyle aynı olmayabilir. Native package derleme hedefi farklı olur. File permission semantics de değişebilir. Dependency container ortamında install edilmelidir. Lock file aynı version setini korur.

Apple Silicon ve Linux Binary'leri

Apple Silicon arm64 mimari kullanır. Production amd64 ise native dependency farklı binary gerektirebilir. Multi platform image build bu farkı yönetebilir. Development target architecture açık olmalıdır. Emulation performans maliyeti yaratabilir.

Bind Mount'un Container Dependency'lerini Ezmesi

Image build sırasında /app/node_modules oluşturulmuş olabilir. Host ./:/app mount edilirse bu dizin host görünümüyle örtülebilir. Host'ta node_modules yoksa dependency kaybolmuş görünür. Ayrı volume hedefi bu sorunu çözebilir. Watch modelinde source selected path'e sync edilebilir.

Named Volume ile node_modules İzolasyonu

node_modules için named volume tanımlanabilir. Container dependency'leri Docker managed storage üzerinde kalır. Source bind mount ayrı path'i günceller. Package update sonrasında install veya rebuild yapılmalıdır. Volume stale dependency taşıyorsa temizleme prosedürü gerekir.

Compose Watch ile node_modules'u Ignore Etmek

Watch kuralı source tree'yi izlerken node_modules'u ignore edebilir. Böylece host dependency'leri container'a kopyalanmaz. Container kendi dependency setini kullanmaya devam eder. Package manifest değişikliği rebuild action'ına bağlanabilir. Bu model Docker'ın resmi Watch örnekleriyle uyumludur. :contentReference[oaicite:19]{index=19}

Dev Containers Nedir?

Dev Containers development ortamının yalnızca application runtime'ını değil, IDE ve CLI tooling'ini de container içinde tanımlamasına yardımcı olur. Böylece geliştiriciler aynı compiler, formatter ve extension setiyle çalışabilir. Repository içinde devcontainer.json dosyası bu deneyimi tanımlar. Docker Compose service bir development container olarak kullanılabilir. Bu yaklaşım onboarding süresini azaltırken local host'a kurulan tool sayısını da düşürür.

Development Container Specification

Development Container Specification development environment metadata'sını standartlaştırmayı hedefler. Runtime image veya Compose service seçilebilir. Feature ve lifecycle command gibi tanımlar kullanılabilir. IDE desteği araca göre değişebilir. Repository configuration source control içinde kalır.

VS Code Dev Containers

VS Code repository'yi container içinde açma deneyimi sağlayabilir. Editor UI host'ta çalışırken extension ve terminal container bağlamında çalışabilir. Source mount edilebilir veya volume tabanlı workspace kullanılabilir. Forwarded port tanımlanabilir. Team extension seti ortaklaştırılabilir.

GitHub Codespaces

GitHub Codespaces devcontainer tanımından yararlanabilen uzak geliştirme ortamı yaklaşımıdır. Compute developer laptop'u yerine remote environment'ta çalışır. Repository tooling hazır şekilde başlatılabilir. Secret ve network access policy ayrıca yönetilmelidir. Cost ve idle lifecycle ekip kullanımına göre planlanmalıdır.

devcontainer.json

devcontainer.json development image, feature, extension ve command ayarlarını tanımlayabilir. Compose service seçilebilir. Remote user belirtilerek non root çalışma sağlanabilir. Port forwarding tanımlanabilir. Dosya değişiklikleri code review ile kontrol edilir.

IDE Extension'larını Standardize Etmek

Formatter ve language extension'ları devcontainer ile ekip standardına dahil edilebilir. Yeni developer manual extension listesi takip etmez. Gereksiz kişisel extension'lar zorunlu hale getirilmemelidir. Security açısından extension source'u değerlendirilmelidir. Project specific araçlar repository tanımına konulmalıdır.

CLI Araçlarını Standardize Etmek

Compiler, formatter ve database client image içinde sabitlenebilir. Host package manager'a bağımlılık azalır. CI ile tool version parity artabilir. Çok fazla diagnostic tool image'ı büyütebilir. Development stage bunun için uygundur.

Takım İçin Hazır Development Environment

Developer repository'yi clone edip development container'ı açabilir. postCreate command dependency hazırlığını tamamlayabilir. Database Compose ile başlatılabilir. İlk test otomatik çalıştırılabilir. Onboarding belgesi birkaç temel adıma indirilebilir.

Dev Container İçinde Neler Tanımlanabilir?

Dev Container yalnızca base image seçimi değildir. Runtime, toolchain, extension, environment variable ve forwarded port aynı development tanımında bir araya getirilebilir. Repository açıldıktan sonra post create komutuyla dependency veya hook kurulabilir. Non root user standardı uygulanabilir. Çok servisli projede belirli Compose service developer workspace olarak seçilebilir.

Runtime

Runtime version image üzerinden sabitlenebilir. Team aynı Node.js, Python veya Java sürümünü kullanır. Upgrade Pull Request ile yapılabilir. Host runtime önemsiz hale gelir. CI parity daha kolay sağlanır.

Toolchain

Compiler ve package manager development image'a eklenebilir. Format ve lint version'ları sabit tutulabilir. Tool cache volume üzerinde saklanabilir. Production image bu araçları taşımaz. Tool update etkisi tüm ekipte aynı olur.

VS Code Extensions

Project için gerekli extension'lar tanımlanabilir. Language server container içinde çalışabilir. Formatter config repository ile uyumlu olur. Çok fazla extension startup süresini artırabilir. Yalnızca proje için gerekli olanlar seçilmelidir.

Environment Variables

Development'a özel non secret environment variable tanımlanabilir. Secret değerler user environment veya secret mechanism üzerinden verilebilir. Real production credential kullanılmamalıdır. Variable isimleri .env.example ile eşleşebilir. Precedence davranışı anlaşılmalıdır.

Forwarded Ports

Container service portları IDE tarafından host'a forward edilebilir. Web server ve debugger için kullanışlıdır. Gereksiz database portları açılmamalıdır. Port açıklamaları configuration'a eklenebilir. Remote environment'ta erişim visibility ayarları önemlidir.

postCreateCommand

Container oluşturulduktan sonra dependency installation veya setup command çalıştırılabilir. Komut idempotent olmalıdır. Uzun işlemler onboarding süresini etkiler. Secret echo edilmemelidir. Failure developer'a anlaşılır mesaj vermelidir.

Non-Root User

Dev container non root user ile çalışabilir. Workspace file permission sorunları azaltılabilir. Tool home directory doğru ayarlanmalıdır. Docker socket mount ediliyorsa ayrıca güvenlik değerlendirmesi yapılmalıdır. Root yalnızca build gerektiğinde kullanılmalıdır.

Docker Compose Service

Devcontainer belirli Compose service'e bağlanabilir. Diğer dependency servisleri aynı project içinde başlatılır. Developer terminali application service içinde açılır. Network service discovery doğrudan kullanılabilir. Workspace mount bu service üzerinde tanımlanır.

Remote Docker Development Ortamları

Remote development compute ve container runtime'ını geliştirici laptop'undan uzak bir sunucuya taşıyabilir. Büyük build ve test workload'larında güçlü donanım paylaşımı sağlar. Source code'un nerede tutulduğu ve hangi secret'lara erişildiği dikkatle yönetilmelidir. SSH veya managed cloud development yaklaşımı kullanılabilir. Uzak ortam hızlı network bağlantısı ve güçlü lifecycle otomasyonu olmadan kullanıcı deneyimini kötüleştirebilir.

Lokal Docker Engine

En basit model Docker Engine'in developer cihazında çalışmasıdır. File access ve debugger latency düşüktür. Laptop resource limitleri stack boyutunu sınırlar. Local secret ve image cache cihazda tutulur. Team farklı cihazlarda benzer Compose modeli kullanır.

Remote Docker Host

Docker context uzak Engine'e bağlanabilir. Container'lar remote host üzerinde çalışır. Bind mount davranışı local host'tan farklıdır çünkü mount daemon host filesystem'ine aittir. Source sync ayrıca tasarlanmalıdır. Engine API erişimi güçlü credential ile korunmalıdır.

SSH Tabanlı Development

Developer SSH ile uzak host üzerinde çalışma alanına bağlanabilir. IDE remote extension üzerinden aynı host'ta terminal ve filesystem kullanabilir. Docker socket yalnızca yetkili user'a açılmalıdır. SSH key yönetimi önemlidir. Çoklu hesaplarda SSH ve Git kimliği yönetimi için https://www.diyarbakiryazilim.com.tr/posts/coklu-hesap-icin-ssh-passphrase-ve-git-kimlik-yonetimi adresindeki yaklaşım da faydalı bir tamamlayıcı olabilir.

Cloud Development Environment

Cloud development environment hazır compute ve lifecycle otomasyonu sunabilir. Developer düşük güçlü cihazdan büyük repository üzerinde çalışabilir. Environment otomatik suspend edilebilir. Cost, data residency ve network policy değerlendirilmelidir. Production network erişimi minimum tutulmalıdır.

Codespaces

Codespaces repository bazlı remote development sağlayabilir. Devcontainer config ortam kurulumunu standardize eder. Secret'lar environment scope'una göre yönetilebilir. Idle timeout maliyeti azaltabilir. Team policy hangi repository'nin hangi network'e erişebileceğini belirlemelidir.

Remote Development'ın Avantajları

Güçlü shared compute build sürelerini azaltabilir. Developer laptop'u daha az kaynak tüketir. Environment standardizasyonu artar. Onboarding daha hızlı olabilir. Merkezi güvenlik policy uygulaması kolaylaşabilir.

Secret ve Source Code Güvenliği

Remote host source code ve development secret'ları taşır. Access control ve disk encryption önemlidir. Personal access token minimum scope ile kullanılmalıdır. Production secret development host'a verilmemelidir. Environment kapanınca temporary credential revoke edilebilir.

Environment Variables Nasıl Yönetilir?

Environment variable container configuration'ını image'dan ayırmanın temel yollarından biridir. Dockerfile ENV default sağlayabilirken Compose environment veya env_file runtime değerleri verebilir. Shell ve CLI override'ları precedence davranışını etkiler. Docker resmi belgelerine göre aynı variable birden fazla kaynaktan geldiğinde CLI, Compose alanları, env file ve image ENV arasında belirli öncelik kuralları uygulanır. :contentReference[oaicite:20]{index=20} Secret değerler için environment variable yerine daha kontrollü secret mekanizması tercih edilmelidir.

Dockerfile ENV

Dockerfile ENV image default configuration sağlar. Ortamlar tarafından override edilebilir. Non sensitive default değerler için uygundur. Secret image layer'a yazılmamalıdır. Runtime behavior'ın hangi ENV değerine bağlı olduğu dokümante edilmelidir.

Compose environment

Compose environment service container'a açık variable tanımlar. Value literal veya interpolation ile gelebilir. Runtime environment default image ENV'i override edebilir. Config için anlaşılırdır. Password gibi değerler secrets mekanizmasına taşınmalıdır.

env_file

env_file environment değerlerini dış dosyada toplar. Birden fazla file sıralı kullanılabilir. Docker Compose güncel sürümlerinde optional env file desteği de bulunur. :contentReference[oaicite:21]{index=21} Development dosyası Git dışında tutulabilir. Production secret file düz metin olarak deployment host'ta bırakılmamalıdır.

Shell Environment

Host shell variable'ları Compose interpolation için kullanılabilir. CI pipeline secret'ı shell üzerinden sağlayabilir. Shell value aynı isimli .env değerini override edebilir. docker compose config --environment interpolation kaynağını anlamaya yardımcı olabilir. :contentReference[oaicite:22]{index=22} Log veya shell history'ye secret yazılmamalıdır.

.env

Compose varsayılan .env dosyasını interpolation için kullanabilir. Project root behavior'ı Compose çağrısına göre belirlenir. Docker belgeleri --env-file ile farklı dosya seçilebileceğini belirtir. :contentReference[oaicite:23]{index=23} Dosya environment sözleşmesini kolaylaştırır. Hassas production secret'ları burada saklanmamalıdır.

Environment Variable Precedence

CLI ile verilen variable yüksek önceliğe sahip olabilir. Compose environment ve env_file kaynakları image ENV değerinin üzerine yazabilir. Docker'ın resmi precedence tablosu farklı kombinasyonların final container değerini nasıl etkilediğini gösterir. :contentReference[oaicite:24]{index=24} Beklenmeyen config sorunu yaşandığında final Compose config incelenmelidir. Aynı anahtarı çok fazla kaynaktan tanımlamak yerine sade yapı tercih edilmelidir.

Ortama Özel .env Dosyaları

Development, test, staging ve production farklı configuration setlerine ihtiyaç duyabilir. Dosya isimleri ortamı açıkça gösterebilir. Gerçek secret'lar source control'e eklenmemelidir. --env-file ile seçilen file interpolation sağlayabilir. Environment dosyalarının içerik sözleşmesi aynı tutulmalıdır.

.env.development

Development dosyası local database ve debug değerlerini içerir. Dummy credential kullanılabilir. Developer override için ayrı ignored dosya kullanılabilir. Production endpoint bulunmamalıdır. Örnek değerler onboarding'i kolaylaştırır.

.env.test

Test dosyası ephemeral database ve deterministic config kullanabilir. External integrations mock endpoint'e yönlendirilebilir. Test secret'ları gerçek production credential olmamalıdır. Random port veya project name CI tarafından eklenebilir. Test sonucu configuration version ile ilişkilendirilebilir.

.env.staging

Staging production'a yakın config modelini kullanır. Secret staging scope'una ait olmalıdır. Production database'e bağlanmamalıdır. Feature flag production'dan farklı olabilir. Aynı image digest staging'de doğrulanabilir.

.env.production

Production environment dosyası yalnızca non secret config için kullanılabilir. Hassas değerler secret manager'dan gelmelidir. File permission çok sıkı tutulmalıdır. Deployment sistemi config version'ını audit edebilir. Repository'de gerçek production value bulunmamalıdır.

Environment Variable ile Secret Arasındaki Fark

Her configuration değeri secret değildir. Log level veya public hostname açık environment variable olabilir. Password, API key ve private certificate ise erişimi sınırlandırılması gereken secret'tır. Docker belgeleri password ve API key gibi hassas verilerin environment variable üzerinden verilmesinin yanlışlıkla log veya process görünürlüğüne sızma riski taşıdığını ve Compose secrets kullanımının daha kontrollü olduğunu belirtir. :contentReference[oaicite:25]{index=25} Secret yönetimi değer kadar erişim yetkisini de kapsar.

Normal Configuration

Application mode veya public port normal configuration olabilir. Source control'de default value bulunabilir. Ortam bazında override edilebilir. Loglarda görünmesi güvenlik olayı yaratmamalıdır. Configuration yine validation ile kontrol edilmelidir.

Password

Password secret olarak değerlendirilmelidir. Image veya repository içine yazılmamalıdır. Environment üzerinden verilirse log ve debug araçlarında görünme riski oluşabilir. File based secret veya manager kullanılabilir. Rotation süreci tasarlanmalıdır.

API Key

API key minimum scope ile oluşturulmalıdır. Her environment ayrı key kullanmalıdır. Development production key taşımamalıdır. Secret manager key lifecycle'ını kolaylaştırabilir. Log masking uygulanmalıdır.

Certificate

Private certificate material secret'tır. Public certificate aynı seviyede hassas olmayabilir. Private key file permission sınırlı olmalıdır. Rotation ve expiration izlenmelidir. Container yalnızca ihtiyacı olan certificate'a erişmelidir.

Database Credential

Database credential environment bazında ayrı tutulmalıdır. Production user minimum yetkiye sahip olmalıdır. Application migration user ile runtime user farklı olabilir. Secret rotation uygulama connection pool davranışını dikkate almalıdır. Credential repository'ye yazılmamalıdır.

Secret'ları Loglardan Koruma

Application startup sırasında tüm environment'ı loglamak risklidir. Error reporting secret value'yu capture etmemelidir. Masking yalnızca belirli variable isimlerine güvenmemelidir. Debug mode production'da kapalı olmalıdır. Incident sırasında log erişimi de yetkili kişilerle sınırlandırılmalıdır.

Minimum Yetkili Secret Kullanımı

Her service yalnızca ihtiyaç duyduğu secret'a erişmelidir. Frontend container database password almamalıdır. Compose secrets service level erişim tanımlamaya izin verir. Rotation ayrı service scope'unda yapılabilir. Bu yaklaşım secret sızıntısının etki alanını sınırlar.

Docker Compose Secrets Nasıl Kullanılır?

Compose secrets hassas verileri service bazında dosya olarak sunmayı sağlar. Top level secrets kaynağı tanımlar, service altındaki secrets ise hangi container'ın erişeceğini belirler. Docker'ın güncel belgelerine göre secret container içinde varsayılan olarak /run/secrets/<secret_name> yolunda dosya olarak sunulur. :contentReference[oaicite:26]{index=26} Bu yapı environment variable'a göre daha kontrollü erişim sağlar. Production'da secret manager ile entegrasyon ayrıca düşünülmelidir.

Top-Level secrets

Top level secrets kullanılabilecek hassas değer kaynaklarını tanımlar. Kaynak file veya desteklenen senaryoda host environment olabilir. Tanımlamak tek başına service'e erişim vermez. Her service ayrıca secret'ı istemelidir. Bu ayrım least privilege modelini destekler.

Service-Level Access

Service altındaki secrets hangi secret'ın container'a sunulacağını belirler. Backend database credential alabilir. Frontend bu secret'ı hiç görmez. Docker belgeleri erişimin service bazında açıkça grant edilmesi gerektiğini belirtir. :contentReference[oaicite:27]{index=27} Access model architecture ownership ile uyumlu olmalıdır.

/run/secrets

Secret dosyaları container içinde /run/secrets altında sunulabilir. Application value'yu file'dan okuyabilir. Bazı resmi image'lar _FILE convention destekler. File path application config ile belirtilir. Secret content loglanmamalıdır.

Servis Bazında Secret Yetkisi

Her service yalnızca gerekli secret listesine sahip olmalıdır. Database root password normal application'a verilmemelidir. Migration job daha geniş credential kullanabilir. Runtime user daha dar credential alır. Böylece credential compromise etki alanı küçülür.

Secret Dosyasını Git'e Eklememek

Compose secret source file local development için kullanılabilir. Gerçek content .gitignore içinde tutulmalıdır. Example file yalnızca formatı gösterir. History'ye giren secret silinmekle güvenli hale gelmez. Credential revoke edilip yenilenmelidir.

Production Secret Manager ile Entegrasyon

Production secret manager merkezi rotation ve audit sağlayabilir. Deployment sırasında secret file veya runtime integration üretilebilir. Secret image build'e dahil edilmemelidir. Access workload identity üzerinden verilebilir. Secret manager availability de deployment tasarımının parçasıdır.

Build-Time Secret Nedir?

Build time secret private package indirmek veya private repository'ye erişmek için image build sırasında geçici olarak gereken hassas bilgidir. Bu değer final image environment'ında bulunmamalıdır. ARG veya ENV üzerinden secret geçirmek güvenli yöntem değildir. Docker BuildKit secret ve SSH mount seçenekleri bu ihtiyaç için tasarlanmıştır. Dockerfile referansı RUN mount seçenekleri içinde secret ve SSH mount desteğini açıkça gösterir. :contentReference[oaicite:28]{index=28}

Private Package Repository Credential

Build sırasında private package registry token gerekebilir. Token yalnızca dependency installation adımına görünmelidir. Final layer'a file olarak kopyalanmamalıdır. Build logunda value görünmemelidir. CI short lived credential kullanabilir.

Git Credential

Private source dependency için Git credential gerekebilir. Personal long lived token image içine yazılmamalıdır. Build secret geçici file sağlayabilir. Source erişimi minimum repository scope'unda olmalıdır. Dependency mümkünse immutable commit üzerinden pin edilmelidir.

SSH Key

Private Git SSH erişimi build sırasında gerekebilir. Private key image layer'a kopyalanmamalıdır. SSH mount agent veya socket kullanımına izin verebilir. Host key verification korunmalıdır. Build tamamlandıktan sonra secret final image'da kalmamalıdır.

ARG ile Secret Vermenin Riski

ARG secret yönetimi için tasarlanmamıştır. Build metadata veya history üzerinden değer sızabilir. CI command log'u da arg value'yu gösterebilir. ARG yalnızca non secret build configuration için kullanılmalıdır. Hassas token BuildKit secret mount ile verilmelidir.

ENV ile Secret Vermenin Riski

ENV image configuration'ında kalıcı olabilir. Final container process'i değeri görebilir. Image inspect ile metadata ortaya çıkabilir. Secret rotation için image rebuild gerekebilir. Bu nedenle production secret ENV içine baked edilmemelidir.

BuildKit Secret Mount

BuildKit secret mount secret'ı yalnızca belirli RUN adımı sırasında erişilebilir kılar. Değer layer'a kalıcı olarak yazılmamalıdır. Docker Compose build secrets bu modele bağlanabilir. :contentReference[oaicite:29]{index=29} Application artifact secret content içermediği doğrulanmalıdır. CI secret scope'u minimum tutulmalıdır.

SSH Mount

SSH mount build sırasında SSH authentication kullanmayı sağlar. Private key'i image context'e kopyalamak gerekmez. Private dependency source için kullanışlıdır. Host verification yine uygulanmalıdır. Build result key materyalini taşımamalıdır.

Docker Compose Profiles Nedir?

Compose profiles her service'in her durumda başlamasını önlemek için optional service grupları oluşturur. Debug, monitoring veya admin tool gibi servisler yalnızca ihtiyaç halinde etkinleştirilebilir. Bu yaklaşım developer cihazında CPU ve RAM tüketimini azaltır. Core service'ler profile olmadan normal başlatılabilir. Docker Compose dokümantasyonu profile'ların environment veya kullanım senaryosuna özel servis grupları için kullanılabileceğini gösterir. :contentReference[oaicite:30]{index=30}

Dev Profile

Development'a özel helper servisler dev profile altında bulunabilir. Mail testing veya mock service buna örnektir. Core API default başlayabilir. Developer yalnızca ihtiyaç duyduğu profile'ı açar. Production bu profile'ı etkinleştirmez.

Debug Profile

Debug proxy veya tracing UI debug profile altında çalıştırılabilir. Normal startup daha hafif kalır. Debug portları yalnızca profile aktifken publish edilir. Sensitive production data bu servislerle paylaşılmamalıdır. Profile adı amacını açıkça göstermelidir.

Test Profile

Test runner ve test dependency servisleri ayrı profile içinde olabilir. CI profile'ı belirli job'da açar. Developer integration test sırasında aynı modeli kullanabilir. Test data volume ephemeral tutulabilir. Normal development stack gereksiz test service taşımamış olur.

Monitoring Profile

Local metric veya log viewer monitoring profile altında bulunabilir. Developer performans sorununu incelerken açabilir. Her startup'ta ağır monitoring stack gerekmez. Production monitoring ayrı deployment olarak yönetilebilir. Local profile gerçek production credential kullanmamalıdır.

Admin Tool Profile

Database admin UI gibi araçlar optional profile olmalıdır. Port yalnızca developer ihtiyaç duyduğunda açılır. Production'da bu tool public olarak çalıştırılmamalıdır. Credential development scope'unda tutulur. Admin profile default startup'ta kapalı kalabilir.

İhtiyaç Olmayan Servisleri Başlatmamak

Her container CPU, RAM ve disk I/O kullanabilir. Profiles developer'ın yalnızca gerekli servisleri açmasını sağlar. Laptop fanı ve startup süresi iyileşebilir. Monorepo'da ekip kendi domain service setini çalıştırabilir. Dependency graph yine doğru tanımlanmalıdır.

Compose Profiles mı Override Files mı?

Profiles optional servisleri açıp kapatmak için uygundur. Override files ise aynı service'in environment'a göre configuration farkını yönetmekte daha doğaldır. Development debugger service profile olabilirken production image digest override file'da tanımlanabilir. İki mekanizma büyük projelerde birlikte kullanılabilir. Hedef configuration modelini anlaşılır tutmak ve bir service'in hangi nedenle farklı davrandığını kolayca görebilmektir.

Profiles İçin Uygun Kullanımlar

Optional debug veya admin service profile için iyi adaydır. Core service yalnızca profile yüzünden kaybolmamalıdır. Developer kendi ihtiyaç setini seçebilir. CI test service profile açabilir. Profile sayısı gereksiz büyütülmemelidir.

Override İçin Uygun Kullanımlar

Aynı service'in image, volume ve port farkları override ile yönetilebilir. Development source mount eklenebilir. Production bind mount kaldırılabilir. Staging resource ayarı farklı olabilir. Final Compose config kontrol edilmelidir.

Environment Bazlı Config

Development ve production farklı restart veya logging ayarlarına sahip olabilir. Override file bu farkı açıkça taşır. Image artifact aynı tutulabilir. Secret source environment'a göre değişebilir. Base Compose ortak service graph'ı korur.

Optional Service Bazlı Config

Mail viewer gibi servis environment değil kullanım ihtiyacına bağlıdır. Profile daha uygun modeldir. Aynı development ortamında bazı developer'lar service'i açabilir. Base config gereksiz büyümez. Documentation hangi profile'ın ne yaptığını açıklamalıdır.

Karmaşık Yapılarda Birlikte Kullanım

Büyük stack'te environment override ve optional profile birlikte kullanılabilir. Production override image digest tanımlar. Monitoring profile local diagnostic service ekleyebilir. CI test override ephemeral volume kullanır. Final model otomatik validation ile kontrol edilmelidir.

Birden Fazla Compose Dosyası ile Ortam Yönetimi

Compose birden fazla configuration dosyasını birlikte değerlendirebilir. Base dosya ortak service graph'ı taşırken test, staging ve production dosyaları environment farklarını ekler. Merge behavior bazı alanlarda replacement bazı alanlarda birleştirme içerdiği için final sonucu kontrol etmek önemlidir. docker compose config bu amaçla değerlidir. Dosya sayısı arttıkça documentation ve automation şart hale gelir.

compose.yaml

Base file ortak service isimlerini ve temel network'leri tanımlar. Ortama bağımlı olmayan configuration burada tutulur. Application build context tanımlanabilir. Secret değer bulunmamalıdır. Diğer dosyalar bu modelin üzerine gelir.

compose.override.yaml

Development source mount ve port mapping burada bulunabilir. Local default override olarak kullanılabilir. Production command bu dosyayı istemeden yüklememelidir. Team kullanılan Compose çağrısını standardize etmelidir. Final config README'de örneklenebilir.

compose.test.yaml

Test file ephemeral database ve test command tanımlayabilir. Host port publish edilmeyebilir. Unique project name CI tarafından verilebilir. Volume job sonunda silinir. Test secret'ları production'dan ayrı tutulur.

compose.staging.yaml

Staging registry image ve staging secret source kullanabilir. Resource limit production'a yakın olabilir. Debug port kapalı tutulmalıdır. Public domain staging'e özel olur. Aynı image digest production adayı olarak test edilir.

compose.production.yaml

Production file immutable registry image kullanır. Source build veya bind mount kaldırılır. Health, logging ve resource limitler eklenir. Secrets production kaynağından gelir. Port ve network exposure minimum tutulur.

Compose Merge Mantığı

Birden fazla Compose file belirli kurallarla birleştirilir. Aynı service alanı sonraki file tarafından override edilebilir veya listeler merge edilebilir. Beklenen davranış tahmin edilmemelidir. Final model tool ile görüntülenmelidir. Production deployment pipeline config validation yapmalıdır.

Final Config'i Doğrulamak

docker compose config birleştirilmiş configuration'ı render eder. Variable interpolation sonucu görülebilir. Secret value output'a yanlışlıkla çıkmamalıdır. CI schema validation çalıştırabilir. Production deploy öncesi final image reference kontrol edilmelidir.

.dockerignore Neden Önemlidir?

Docker build context gereksiz dosyalarla büyüdüğünde build süresi ve cache davranışı olumsuz etkilenebilir. .dockerignore Git metadata, dependency klasörleri ve local artifact'ları context dışında tutar. Secret dosyanın build context'e hiç girmemesi de güçlü korumadır. Dockerfile içinde COPY nokta kullanımı ancak doğru ignore politikasıyla güvenli hale gelir. File değişikliklerinin cache invalidation etkisi de daha kontrollü olur.

Build Context

Build context Docker builder'a erişilebilir dosya setidir. Gereksiz büyük context network ve disk maliyeti oluşturabilir. Builder remote ise etki daha belirgin olur. Ignore file context'i küçültür. Yalnızca build için gerekli dosyalar dahil edilmelidir.

node_modules

Host node_modules build context'e gönderilmemelidir. Container içinde dependency yeniden install edilir. Native platform farkları böylece korunur. Context ciddi biçimde küçülebilir. Lock file ise dahil edilmelidir.

.git

Tüm Git history build için çoğunlukla gerekli değildir. .git context'i büyütebilir. Commit metadata gerekiyorsa CI ayrı build arg veya label sağlayabilir. Secret geçmişi de image context'ten uzak kalır. Build reproducibility daha açık hale gelir.

Local Environment Files

Local .env dosyası hassas değer içerebilir. Build context'e girmemelidir. Example environment file gerektiğinde dahil edilebilir. Production secret image içinde bulunmamalıdır. Ignore kuralı defense in depth sağlar.

Test Output

Coverage ve test artifact'ları build context'e gereksiz eklenmemelidir. Her test run cache'i invalid edebilir. CI artifact storage ayrı kullanılabilir. Final image test report taşımamalıdır. Gerekirse dedicated test image içinde kalabilir.

Build Artifacts

Host'ta üretilmiş build output container build'iyle karışmamalıdır. Platform farkı binary sorununa yol açabilir. Artifact image build stage'de yeniden oluşturulabilir. Deterministic process tercih edilir. Ignore host output'u dışarıda tutar.

Secret Dosyalarının Image'a Girmesini Önlemek

Ignore secret file'ları context dışında tutabilir. Ancak yalnızca ignore kuralına güvenilmemelidir. Secret BuildKit mount ile geçici verilmelidir. Git history'de secret bulunmamalıdır. CI secret scan ek kontrol sağlar.

Build Performansını Artırmak

Küçük context builder'a daha az veri taşır. Cache invalidation gereksiz file değişikliklerinden etkilenmez. Remote CI build daha hızlı olabilir. Monorepo'da service specific context kullanılabilir. Performans ölçümü build log'larıyla yapılmalıdır.

Docker Build Cache Nasıl Çalışır?

Docker build cache önceki build adımlarının tekrar kullanılmasını sağlar. Bir layer'ın input'u değişmediyse yeniden çalıştırılması gerekmeyebilir. Dockerfile sırası bu nedenle build süresini ciddi biçimde etkiler. Dependency manifest sık değişmeyen layer'da tutulurken source code daha sonra kopyalanabilir. CI remote cache kullanarak yeni runner üzerinde bile build süresini azaltabilir.

Image Layers

Dockerfile talimatları image layer yapısını oluşturur. Layer hash input içeriğine bağlıdır. Ortak layer başka image tarafından yeniden kullanılabilir. Runtime final image gereksiz layer içermemelidir. Multi stage build final content'i sınırlar.

Cache Invalidation

Bir build adımının input'u değiştiğinde cache geçersiz olabilir. Sonraki adımlar da yeniden çalışabilir. Source'u çok erken COPY etmek dependency cache'ini sık bozabilir. Build context metadata davranışı önemlidir. Dockerfile sırası gerçek değişiklik sıklığına göre düzenlenmelidir.

Dependency Dosyalarını Önce Kopyalamak

package lock veya requirements file ayrı COPY edilebilir. Dependency install bu layer'da yapılır. Source değişikliği dependency layer'ını bozmaz. Package manifest değişince install tekrar çalışır. Development rebuild süresi önemli ölçüde azalabilir.

Source Code'u Sonra Kopyalamak

Source kodu dependency installation sonrasında kopyalamak cache'i korur. Kod sık değişse de pahalı dependency step'i yeniden kullanılabilir. Generated dosyalar ignore edilmelidir. Build output sonraki stage'de üretilir. Monorepo context daha da daraltılabilir.

Deterministik Dependency Installation

Lock file deterministic version seti sağlar. CI fresh install komutu kullanmalıdır. Floating version build tekrarını bozar. Registry availability ayrıca supply chain riskidir. Dependency checksum doğrulaması mümkünse korunmalıdır.

Build Cache'in CI'da Kullanılması

CI runner ephemeral olsa bile remote cache kullanılabilir. Cache key architecture ve build target'a göre ayrılabilir. Untrusted branch cache poisoning riski açısından değerlendirilmelidir. Production build cache sonucu yine final scan'den geçmelidir. Cache performans aracıdır ve source of truth değildir.

BuildKit ile Build Süresini Azaltmak

BuildKit Docker build işlemlerini daha gelişmiş cache, parallel execution ve mount özellikleriyle gerçekleştiren build backend'idir. Cache mount dependency package cache'ini layer'a kalıcı eklemeden yeniden kullanabilir. Secret ve SSH mount build credential'larını daha güvenli aktarır. Remote cache CI sistemleri arasında paylaşılabilir. Dockerfile referansı RUN mount tipleri arasında cache, secret ve SSH seçeneklerini destekler. :contentReference[oaicite:31]{index=31}

BuildKit Nedir?

BuildKit Docker image build işlemleri için modern backend'dir. Dependency graph üzerinden bazı adımları daha verimli çalıştırabilir. Advanced cache export ve import destekler. Secret handling eski build pattern'lerine göre daha kontrollüdür. Buildx ile birlikte multi platform workflow'larda yaygın kullanılır.

Parallel Build

Birbirinden bağımsız build stage'leri paralel çalıştırılabilir. Büyük multi stage Dockerfile build süresi kısalabilir. Shared dependency step cache'den gelebilir. CI runner CPU kapasitesi sınırlayıcı olabilir. Parallelism ölçülerek optimize edilmelidir.

Cache Mount

Package manager cache'i RUN sırasında mount edilebilir. npm, pip veya apt download tekrarları azalabilir. Cache final image filesystem'ine eklenmek zorunda değildir. CI cache exporter ile paylaşılabilir. Cache corruption durumunda temiz yeniden build yolu bulunmalıdır.

Secret Mount

Secret mount hassas değeri build step'e geçici sunar. ARG veya ENV yerine kullanılması daha güvenlidir. Build output secret içermemelidir. CI secret scope'u minimum olmalıdır. Log command secret value'yu echo etmemelidir.

SSH Mount

SSH mount private Git dependency erişiminde kullanılabilir. Private key context'e kopyalanmaz. Agent forwarding veya controlled key access sağlanır. Host validation sürdürülmelidir. Build tamamlandığında key artifact içinde kalmamalıdır.

Remote Cache

Remote cache build layer metadata'sını registry veya başka backend üzerinden paylaşabilir. Ephemeral CI runner önceki build sonucundan yararlanır. Cache architecture ve branch güvenliği dikkate alınmalıdır. Main cache trusted source olabilir. Cache miss normal build'i yine çalıştırmalıdır.

CI Build Cache

CI pipeline build cache import edebilir. Build sonunda yeni cache export edilebilir. Pull Request cache'i production cache'ini kontrolsüz overwrite etmemelidir. Cache performansı metric olarak izlenebilir. Security scan cache kullanımından bağımsız final image'a uygulanmalıdır.

Multi-Platform Docker Image Nasıl Oluşturulur?

Multi platform image aynı repository artifact'ının farklı CPU veya operating system hedeflerinde çalışmasını sağlar. Docker Buildx ve BuildKit bu süreci yönetebilir. Resmi Docker belgelerine göre tek build çağrısında linux/amd64 ve linux/arm64 gibi birden fazla platform hedeflenebilir. :contentReference[oaicite:32]{index=32} QEMU emulation, native builder ve cross compilation farklı stratejilerdir. Production performansı için mümkün olduğunda native build veya doğru cross compile tercih edilmelidir.

amd64

amd64 birçok server ortamında yaygın CPU architecture'dır. Base image'ın ilgili platform variant'ı bulunmalıdır. Native dependency amd64 için build edilmelidir. ARM developer laptop emulation kullanabilir. Production target açıkça belirtilmelidir.

arm64

arm64 cloud server ve modern developer cihazlarında yaygınlaşmıştır. Image manifest arm64 variant taşıyabilir. Native binary doğru architecture için build edilmelidir. Dependency registry arm64 support sağlamalıdır. CI native ARM runner kullanabilir.

Apple Silicon

Apple Silicon developer cihazları arm64 mimari kullanır. Linux container ise macOS binary çalıştırmaz. Host node_modules paylaşımı bu nedenle sorun çıkarabilir. Multi platform image local ve production hedeflerini destekleyebilir. Platform farkı test pipeline'da görünür tutulmalıdır.

Docker Buildx

Buildx advanced Docker build workflow'larını yönetir. Multi platform target tek command ile belirtilebilir. Custom builder oluşturulabilir. Registry output multi architecture manifest oluşturabilir. CI builder cache ile birlikte yapılandırılabilir.

Multi-Platform Manifest

Manifest list aynı image reference altında birden fazla platform image'ını gösterir. Client kendi platformuna uygun variant'ı seçebilir. Tek tag developer deneyimini kolaylaştırır. Her platform aynı application version'ını temsil etmelidir. Scan ve test platform bazında yapılmalıdır.

Cross-Compilation

Bazı diller farklı target architecture için native binary compile edebilir. Go ve Rust buna uygun örneklerdir. Emulation ihtiyacı azalabilir. C library dependency'leri süreci etkileyebilir. Build target değişkenleri Dockerfile'da kullanılabilir.

QEMU Emulation

QEMU başka architecture instruction set'ini emule ederek build sağlayabilir. Kurulum kolaylığı sunar. Compile yoğun işlerde daha yavaş olabilir. Native test behavior'ı tamamen temsil etmeyebilir. Docker belgeleri multi platform build stratejileri arasında emulation'ı listeler. :contentReference[oaicite:33]{index=33}

Native CI Builder Kullanımı

Her architecture için native runner daha yüksek performans sağlayabilir. Build çıktıları manifest altında birleştirilebilir. Hardware availability maliyeti etkiler. Platform specific tests native environment'ta çalışır. Supply chain metadata her variant için tutulmalıdır.

Docker ile Database Geliştirme Ortamı

Database servislerini Docker ile çalıştırmak developer onboarding'i önemli ölçüde kolaylaştırabilir. Version pinning tüm ekipte aynı database sürümünü sağlar. Named volume local data'yı container lifecycle'dan ayırır. Healthcheck API başlamadan önce database readiness sinyali sağlayabilir. Production database mimarisi local Compose yaklaşımının birebir kopyası olmak zorunda değildir.

PostgreSQL

PostgreSQL image version açıkça belirlenmelidir. Named volume data directory için kullanılabilir. Init script yalnızca local seed ihtiyacını karşılamalıdır. Healthcheck pg_isready benzeri komut kullanabilir. Host port yalnızca developer ihtiyacı varsa açılmalıdır.

MySQL

MySQL development service version pin edilmelidir. Initial database ve user değerleri local secret üzerinden verilebilir. Persistent volume kullanılır. Major version upgrade volume compatibility gerektirir. Healthcheck gerçek login veya ping davranışını doğrulayabilir.

MongoDB

MongoDB local development'ta ayrı service olarak çalışabilir. Volume persistent data sağlar. Authentication development'ta bile açık tutulabilir. Replica set behavior gerekiyorsa local topology ayrıca kurulmalıdır. Production data local ortama taşınmamalıdır.

Redis

Redis cache veya queue dependency'si olarak kolayca containerize edilir. Development persistence ihtiyaca göre kapatılabilir. Healthcheck ping kullanabilir. Memory policy production'da ayrıca ayarlanır. Public host port production'da gereksizdir.

Named Volumes

Named volume database data'yı container silinmesinden korur. Environment reset gerektiğinde bilinçli olarak kaldırılabilir. Volume name Compose project ile ayrılabilir. Backup local development için şart olmayabilir. Production volume data ise backup policy gerektirir.

Database Version Pinning

latest database image local ekipte beklenmeyen upgrade yaratabilir. Major ve gerekirse minor sürüm pin edilmelidir. Upgrade ayrı PR ile test edilmelidir. Migration tool compatibility doğrulanmalıdır. Production version ile development version yakın tutulmalıdır.

Healthcheck

Container process'in çalışması database'in bağlantı kabul ettiği anlamına gelmez. Healthcheck readiness için database client command kullanabilir. depends_on service healthy koşulu API başlangıcını geciktirebilir. Retry logic yine application içinde bulunmalıdır. Startup süreleri cihaz performansına göre değişebilir.

Database'i Public Network'ten İzole Etmek

Database yalnızca backend network'üne bağlanabilir. Host port development GUI ihtiyacında loopback'e publish edilir. Production public IP exposure engellenmelidir. Admin access ayrı güvenli kanal kullanabilir. Database credential minimum privilege ile sınırlandırılmalıdır.

Development Seed Data Nasıl Yönetilir?

Development seed data yeni developer'ın uygulamayı anlamlı state ile açmasını sağlar. Migration schema'yı oluştururken seed örnek business kayıtlarını ekleyebilir. Gerçek production kişisel verisinin local ortama kopyalanması ciddi güvenlik ve uyum riski oluşturur. Deterministic seed aynı test senaryolarını tekrar üretmeyi kolaylaştırır. Ortamın tek komutla reset edilmesi developer deneyimini ciddi biçimde iyileştirir.

Migration

Migration database schema değişikliklerini version control altında tutar. Fresh database baştan sona migration çalıştırabilmelidir. Local ve CI aynı migration setini kullanır. Production migration ayrı deployment riskine sahiptir. Destructive operation staged yapılmalıdır.

Seed

Seed development için örnek business data oluşturur. User, product veya sample configuration eklenebilir. Data deterministic olabilir. Real customer information kullanılmamalıdır. Seed script tekrar çalıştırıldığında duplicate üretmemelidir.

Fixture

Fixture belirli test veya demo state'i için sabit data seti sağlayabilir. Integration test bunu yükleyebilir. Schema değiştiğinde fixture güncellenmelidir. Büyük binary fixture repository'yi şişirebilir. Minimum anlamlı data tercih edilmelidir.

Test Data

Test data production verisinden bağımsız olmalıdır. Edge case senaryoları bilinçli üretilir. Random generation seed ile sabitlenebilir. CI run'ları birbirinden izole data kullanmalıdır. Test bitince database yok edilebilir.

Deterministik Seed

Aynı seed komutu aynı temel state'i oluşturmalıdır. Developer bug senaryosunu kolay paylaşabilir. Test sonuçları daha tekrar üretilebilir olur. Timestamp ve random değerler kontrollü olabilir. Gerektiğinde explicit scenario seed'leri tanımlanabilir.

Personal Data Kullanmamak

Production PII local laptop'a taşınmamalıdır. Sanitized dataset bile yeniden tanımlanabilirlik açısından kontrol edilmelidir. Synthetic data daha güvenlidir. Access policy development database'e uygulanmalıdır. Backup dosyaları da aynı hassasiyetle korunmalıdır.

Ortamı Tek Komutla Resetlemek

Reset script container ve development volume'larını kontrollü temizleyebilir. Database yeniden oluşturulup migration çalışır. Seed data tekrar yüklenir. Developer manual SQL işlemine ihtiyaç duymaz. Production komutuyla karışmaması için güvenlik guard eklenmelidir.

Database Migration Container Ortamında Nasıl Çalıştırılır?

Migration application startup'ına bağlanabilir veya ayrı job olarak çalıştırılabilir. Küçük local development'ta startup migration pratik olabilir. Production'da birden fazla replica aynı migration'ı eş zamanlı başlatmamalıdır. CI schema compatibility ve migration testlerini çalıştırabilir. Rollback planı database işleminin gerçekten tersine çevrilebilir olup olmadığına göre seçilmelidir.

Startup Migration

Application başlangıçta migration çalıştırabilir. Development için oldukça basittir. Production replica sayısı arttığında yarış riski oluşabilir. Long running migration startup timeout yaratabilir. Yüksek riskli environment'ta ayrı job tercih edilebilir.

Ayrı Migration Job

Migration ayrı one off container command olarak çalıştırılabilir. Deploy pipeline application rollout öncesinde bunu tetikler. Job tamamlanmadan yeni version başlamaz. Credential runtime application'dan farklı olabilir. Log ve status audit edilir.

CI/CD Migration

CI migration script'ini fresh database üzerinde test edebilir. Upgrade path eski schema snapshot'ından denenebilir. Production deploy stage migration job çalıştırabilir. Failure rollout'u durdurur. Destructive change backward compatibility kontrolü gerektirir.

Rollback

Her database migration güvenli rollback desteklemez. Data deletion geri döndürülemez olabilir. Expand contract yaklaşımı rollback ihtiyacını azaltır. Application old version yeni schema ile çalışabilmelidir. Migration planı code review içinde açık olmalıdır.

Birden Fazla Replica Durumunda Migration

Tüm replica startup migration çalıştırmamalıdır. Distributed lock bazı framework'lerde çözüm olabilir. Ayrı deployment job daha açık modeldir. Job idempotent tasarlanmalıdır. Failure halinde application eski version ile devam edebilmelidir.

Production Migration Riskleri

Table lock ve long transaction availability'yi etkileyebilir. Büyük backfill ayrı batch job olmalıdır. Index oluşturma engine davranışına göre planlanır. Database backup migration güvenliğinin tek garantisi değildir. Production veri hacminde test ve gözlem gerekir.

Healthcheck Nedir?

Healthcheck container process'inin yalnızca çalışıyor olmasını değil, belirli bir hizmet kontrolünü geçip geçmediğini gösterir. Docker health state run state'den ayrıdır. Dockerfile veya Compose içinde probe tanımlanabilir. Interval, timeout, retries ve start period parametreleri false alarm oranını etkiler. Docker'ın resmi referansı bu ayarları ve healthy, unhealthy durumlarını ayrıntılı biçimde tanımlar. :contentReference[oaicite:34]{index=34}

Running Container ile Healthy Service Arasındaki Fark

Process çalışıyor olabilir ancak request cevaplamıyor olabilir. Deadlock veya dependency problemi buna örnektir. Container run state yalnızca process yaşamını gösterir. Healthcheck uygulama davranışını ek olarak test eder. Orchestrator bu sinyali routing veya restart kararında kullanabilir.

HEALTHCHECK

Dockerfile HEALTHCHECK image default health probe tanımlar. Runtime Compose file bunu override edebilir. Probe command container içinde bulunmalıdır. Exit code health sonucunu belirler. Probe çok pahalı olmamalıdır.

Compose healthcheck

Compose service healthcheck image default'unu tanımlayabilir veya değiştirebilir. Web endpoint veya database readiness test edilebilir. depends_on service healthy ile startup dependency oluşturulabilir. Probe secret value yazmamalıdır. Local ve production parametreleri farklı olabilir.

interval

Interval probe'ların ne sıklıkla çalışacağını belirler. Çok sık probe gereksiz load oluşturur. Çok uzun interval failure detection'i geciktirir. Application SLO dikkate alınmalıdır. Startup period farklı parametreyle yönetilebilir.

timeout

Timeout tek probe'un ne kadar bekleyebileceğini sınırlar. External dependency timeout'u healthcheck içine taşınmamalıdır. Çok kısa değer false unhealthy üretebilir. Çok uzun değer detection'i geciktirir. Local cihaz performansı production'dan farklı olabilir.

retries

Retries kaç ardışık failure sonrası unhealthy sayılacağını belirler. Tek transient hata container'ı hemen unhealthy yapmayabilir. Çok yüksek retry ciddi problemi gizler. Interval ile birlikte toplam detection süresi hesaplanmalıdır. Production gözlem gereksinimine göre ayarlanır.

start_period

Start period uygulamanın initial setup süresinde probe failure'larının tolere edilmesini sağlar. Database warm up buna örnektir. Gereksiz uzun değer gerçek startup failure'ını gizleyebilir. Healthcheck success erken gelirse normal değerlendirme başlayabilir. Docker belgeleri start period davranışını açıkça tanımlar. :contentReference[oaicite:35]{index=35}

depends_on Tek Başına Neden Yeterli Değildir?

depends_on bir service'in başka service'den sonra başlatılmasını sağlayabilir ancak readiness garantisi değildir. Docker resmi Compose belgeleri bir container'ın running olmasının service'in hazır olduğu anlamına gelmediğini açıkça belirtir. :contentReference[oaicite:36]{index=36} Database process başlamış fakat connection kabul etmiyor olabilir. Healthcheck ve condition: service_healthy bu boşluğu azaltır. Uygulamanın kendisi de retry ve resilience logic taşımalıdır.

Container Started

Started state ana process'in çalıştığını gösterir. Application initialization tamamlanmamış olabilir. Database recovery yapıyor olabilir. Web server migration bekliyor olabilir. Readiness ayrı değerlendirilmelidir.

Service Ready

Ready service gerçek request kabul edebilir durumdadır. Healthcheck bunu yaklaşık olarak test eder. Application specific endpoint daha doğru sinyal sağlayabilir. Dependency chain çok derin olmamalıdır. Readiness failure gözlemlenebilir olmalıdır.

condition: service_healthy

service_healthy dependent service başlamadan önce dependency healthcheck success beklenmesini sağlar. Docker'ın resmi startup order örneği bu kullanımı gösterir. :contentReference[oaicite:37]{index=37} Local stack race condition'larını azaltır. Production resilience için yine retry gerekir. Healthcheck doğru service readiness'i temsil etmelidir.

Database Startup

Database container process'i birkaç saniyede başlayabilir. Recovery veya initialization daha uzun sürebilir. API ilk connection'da failure görebilir. Healthcheck database client ile readiness test edebilir. API exponential retry uygulayabilir.

Retry Logic

Distributed system dependency her an geçici olarak unavailable olabilir. Sadece startup order buna çözüm değildir. Application connection retry desteklemelidir. Backoff ve timeout değerleri kontrollü olmalıdır. Sonsuz hızlı retry dependency'yi daha da zorlayabilir.

Uygulama Seviyesinde Resilience

Service restart sonrasında dependency yeniden oluşabilir. Application connection pool recover edebilmelidir. Circuit breaker veya backoff gerektiğinde kullanılabilir. Healthcheck yalnızca dış sinyaldir. Gerçek resilience application behavior'ında tasarlanır.

Healthcheck Self-Healing Sağlar mı?

Plain Docker Engine healthcheck container'ı healthy veya unhealthy olarak işaretleyebilir ancak bu durum tek başına container'ı otomatik yeniden oluşturmaz. Restart policy esas olarak container process exit davranışına göre çalışır. Docker'ın resmi restart policy belgeleri restart kararlarını container'ın durması veya non zero exit gibi durumlarla ilişkilendirir. :contentReference[oaicite:38]{index=38} Gerçek self healing için orchestrator health sinyalini action ile ilişkilendirebilir. Application failure mode buna göre tasarlanmalıdır.

Healthy ve Unhealthy State

Healthcheck success healthy state üretir. Belirlenen sayıda failure unhealthy state'e götürebilir. Container process yine running olabilir. Monitoring bu state'i alarm olarak kullanabilir. Engine otomatik recreate garantisi vermez.

Restart Policy

Restart policy container process durduğunda tekrar başlatma davranışı tanımlar. on-failure non zero exit'e tepki verir. unless-stopped farklı lifecycle davranışı sağlar. Unhealthy olmak process exit değildir. Bu ayrım production runbook'ta açık olmalıdır.

Process Exit ile Unhealthy Arasındaki Fark

Process exit container'ı stopped state'e götürür. Unhealthy state'te process çalışmaya devam edebilir. Restart policy ilk duruma tepki verebilir. Health event monitoring ile yakalanabilir. Uygulama bazı fatal health durumlarında bilinçli exit etmeyi seçebilir.

Plain Docker Engine'in Sınırları

Tek host Engine cluster scheduling sağlamaz. Healthcheck sonucu otomatik başka host'a taşıma yapılmaz. High availability başka mekanizma gerektirir. Compose operasyonel basitlik sağlar ancak cluster orchestrator değildir. Bu sınır deployment gereksiniminde dikkate alınmalıdır.

Orchestrator ile Self-Healing

Orchestrator desired state mantığıyla failed workload'ı yeniden oluşturabilir. Health ve readiness sinyalleri scheduling davranışına bağlanabilir. Multi host placement yapılabilir. Rolling update ve replica yönetimi ek özellikler sunar. İhtiyaç oluşmadan orchestrator eklemek ise operasyon yükünü artırabilir.

Docker ile İzole Test Ortamları

Docker test dependency'lerini her run için geçici olarak oluşturmayı kolaylaştırır. Unit test container gerektirmese bile integration test gerçek database veya cache service kullanabilir. CI job kendi Compose project adıyla izole stack başlatabilir. Test sonunda container, network ve geçici volume kaldırılır. Bu model testler arasında state sızıntısını azaltır.

Unit Test

Unit test çoğunlukla external service gerektirmez. Container içinde aynı runtime ile çalıştırılabilir. CI test stage bunun için kullanılabilir. Test startup overhead düşük tutulmalıdır. Local developer native veya container workflow seçebilir.

Integration Test

Integration test application ile gerçek dependency interaction'ını doğrular. PostgreSQL veya Redis container başlatılabilir. Database migration uygulanır. Test tamamlandıktan sonra environment yok edilir. Sabit test data determinism sağlar.

End-to-End Test

E2E test tüm application stack'i çalıştırabilir. Frontend, backend ve database birlikte doğrulanır. Unique port ve project name kullanılabilir. Browser runner ayrı container olabilir. Test failure durumunda log artifact saklanmalıdır.

Gerçek Database ile Test

Mock database gerçek SQL behavior'ını tam temsil etmeyebilir. Container gerçek engine version çalıştırır. Migration ve transaction davranışı doğrulanır. Test database production data içermez. Version production ile uyumlu tutulur.

Her Test Run İçin Temiz Ortam

Shared test database state leak oluşturabilir. Unique project ve volume her run'ı izole eder. Parallel CI job birbirini etkilemez. Test setup biraz daha maliyetlidir. Cache ve image pre pull süreyi azaltabilir.

Test Sonunda Container'ları Yok Etmek

CI cleanup stack'i durdurup kaldırmalıdır. Temporary volume gerekiyorsa silinir. Failure durumunda cleanup yine çalışmalıdır. Loglar cleanup öncesi artifact olarak alınabilir. Orphan container birikimi engellenir.

Testcontainers Nedir?

Testcontainers test kodunun ihtiyaç duyduğu dependency container'larını programatik olarak başlatmasına yardımcı olan test yaklaşımıdır. Test suite database veya queue service'i gerektiğinde oluşturabilir. Dynamic port ve lifecycle test framework tarafından yönetilebilir. Docker Compose daha çok tüm stack'i deklaratif başlatırken Testcontainers test case veya test suite ihtiyaçlarına daha yakın çalışır. Her iki yöntem farklı test katmanlarında birlikte kullanılabilir.

Test İçinden Container Başlatmak

Test code dependency image seçebilir. Container test başlangıcında oluşturulur. Ready olduğunda connection detail test'e verilir. Test sonunda container kaldırılır. Parallel test için isolation sağlanabilir.

PostgreSQL Testcontainer

PostgreSQL container gerçek SQL engine behavior'ı sağlar. Test schema migration çalıştırılabilir. Dynamic host port kullanılır. Her suite fresh data ile başlayabilir. Production major version ile aynı image tercih edilir.

Redis Testcontainer

Redis cache behavior'ı gerçek service üzerinden test edilebilir. TTL ve transaction özellikleri mock'tan daha doğru temsil edilir. Container startup hızlıdır. Test sonunda data kaybolur. External shared Redis dependency'si gerekmez.

Kafka Testcontainer

Kafka integration test daha ağır olabilir. Container broker test için geçici environment sağlar. Topic ve consumer behavior doğrulanabilir. Startup readiness beklenmelidir. CI runner resource ihtiyacı planlanmalıdır.

Test Başına İzolasyon

Her test veya suite ayrı container kullanabilir. State leakage azalır. Startup maliyeti artabilir. Reuse yalnızca isolation korunuyorsa uygulanmalıdır. Parallelism runner kapasitesine göre sınırlandırılmalıdır.

CI ile Kullanım

CI runner container runtime erişimine ihtiyaç duyar. Docker socket güvenlik modeli değerlendirilmelidir. Ephemeral runner tercih edilebilir. Image pull cache build süresini azaltır. Test log ve container logları failure artifact olabilir.

Docker Compose ile Testcontainers Arasındaki Fark

Compose tüm service graph'ı deklaratif yönetir. Testcontainers test kodundan dependency lifecycle'ını kontrol eder. Full stack E2E için Compose doğal olabilir. Library integration test için Testcontainers daha esnek olabilir. Team test katmanına göre seçim yapmalıdır.

CI Pipeline'da Ephemeral Docker Environment

CI job her çalışma için geçici Docker environment oluşturabilir. Unique Compose project name network ve volume resource'larını başka job'lardan ayırır. Test database başlatılıp migration uygulanır. Integration ve E2E testler tamamlandıktan sonra stack yok edilir. Bu yaklaşım shared test sunucusuna bağımlılığı azaltır ve Pull Request sonuçlarını daha güvenilir hale getirir.

CI Job Başlangıcı

Runner clean workspace ile başlar. Registry authentication gerekiyorsa short lived credential kullanılır. Required image'lar pull edilir. Project name job ID üzerinden belirlenebilir. Secret log masking etkin olmalıdır.

Compose Stack Oluşturmak

CI Compose file test override ile başlatılır. Host port gerekmedikçe publish edilmez. Network project scope'unda oluşur. Service health beklenir. Failure logları toplamak için timeout belirlenir.

Test Database Başlatmak

Database fixed version image kullanır. Ephemeral volume veya tmpfs tercih edilebilir. Production data kullanılmaz. Healthcheck readiness'i doğrular. Test credential job scope'unda kalır.

Migration

Migration job database hazır olduğunda çalışır. Failure testleri durdurur. Schema fresh state'ten oluşturulur. Migration output log artifact olabilir. Backward compatibility ayrı pipeline'da test edilebilir.

Integration Test

Application container gerçek dependency service'lerle konuşur. Test config internal DNS isimleri kullanır. Mock yalnızca external uncontrollable dependency için kullanılabilir. Test failure container loglarıyla ilişkilendirilir. Coverage artifact saklanabilir.

End-to-End Test

Full stack ayağa kaldırılır. Browser veya API client test senaryoları çalışır. Unique domain veya port kullanılabilir. Screenshot failure artifact olabilir. Test tamamlanınca stack kapanır.

Ortamı Yok Etmek

Cleanup her pipeline sonucunda çalışmalıdır. Container ve network kaldırılır. Ephemeral volume silinir. Debug amacıyla gerekli loglar önceden alınır. Orphan resource kalmaması izlenir.

CI Job İzolasyonu

Her job unique project name kullanabilir. Container isimleri ve network'ler ayrılır. Port publish gerekmiyorsa collision oluşmaz. Volume name project scope'unda kalır. Shared Docker daemon güvenliği ayrıca değerlendirilmelidir.

Pull Request Başına İzole Preview Environment

Preview environment her Pull Request için geçici çalışan uygulama ortamı oluşturur. Reviewer ve ürün ekipleri değişikliği merge öncesinde gerçek arayüz üzerinden görebilir. Unique project name, domain ve database her PR'ı diğerinden ayırır. CI deployment otomatik oluşturur ve PR kapandığında ortamı siler. Bu yaklaşım özellikle frontend ve integration review sürecini hızlandırabilir.

Preview Environment Nedir?

Preview environment branch değişikliğinin canlıya benzer geçici deployment'ıdır. Production kullanıcı trafiğini almaz. Test veya synthetic data kullanır. URL Pull Request'e eklenebilir. Lifecycle PR state ile ilişkilendirilir.

Branch Bazlı Environment

Branch veya PR numarası environment identity olarak kullanılabilir. Name sanitize edilmelidir. Aynı branch update olduğunda image güncellenir. Old revision container kaldırılır. Environment TTL belirlenebilir.

Unique Compose Project Name

Project name PR numarasını içerebilir. Container, network ve volume resource'ları ayrılır. Docker resmi Compose belgeleri CI server'da unique build number ile project name kullanmanın build interference önleyebileceğini belirtir. :contentReference[oaicite:39]{index=39} Name production project ile asla çakışmamalıdır. Cleanup aynı project name üzerinden yapılır.

Unique Domain

Her preview kendine ait subdomain alabilir. Reverse proxy routing otomatik güncellenir. TLS wildcard certificate kullanılabilir. Access gerekirse authentication ile korunabilir. Public preview hassas feature'ları göstermemelidir.

Geçici Database

Her preview ayrı database veya schema kullanabilir. Production clone kullanılmamalıdır. Seed synthetic data sağlar. PR kapanınca database silinir. Migration preview deployment sırasında test edilir.

Otomatik Deployment

CI image build sonrası preview stack'i günceller. Healthcheck success beklenir. URL Pull Request comment'ine yazılabilir. Failed deployment reviewer'a görünür olmalıdır. Secret'lar preview scope'unda ayrı tutulmalıdır.

PR Kapanınca Ortamı Silmek

Close veya merge event cleanup tetikler. Container ve network kaldırılır. Temporary volume silinir. DNS veya proxy route temizlenir. Leak environment maliyeti periyodik job ile kontrol edilebilir.

Compose Project Name ile Ortamları İzole Etmek

Compose project name container, network ve volume resource isimlerini ortak namespace altında gruplar. Aynı Compose modelini tek host üzerinde birden fazla kez çalıştırmak için kullanışlıdır. CI job ID veya PR numarası unique project name olarak seçilebilir. Docker'ın resmi belgeleri project name'in shared host ve CI build interference azaltmak için kullanılabileceğini belirtir. :contentReference[oaicite:40]{index=40} Host port ve external resource'lar yine ayrıca benzersiz tutulmalıdır.

Project Name

Project name CLI -p ile verilebilir. Environment variable veya Compose top level name de kullanılabilir. Precedence davranışı Docker dokümantasyonunda tanımlıdır. :contentReference[oaicite:41]{index=41} CI explicit -p kullanabilir. Name safe karakterlerden oluşmalıdır.

Container Name Isolation

Compose generated container isimleri project prefix kullanır. Aynı service adı farklı project'te çakışmaz. Explicit container_name bu avantajı bozabilir. Bu nedenle çoğu projede container_name tanımlamamak daha iyidir. Service discovery generated name yerine service adını kullanır.

Network Isolation

Her Compose project kendi default network'ünü oluşturabilir. Aynı service adları farklı network scope'unda çözülür. Cross project communication açıkça external network gerektirir. Preview environment'lar böylece ayrılır. Host network kullanımından kaçınılmalıdır.

Volume Isolation

Named volume project prefix ile ayrılabilir. Her test run kendi database data'sını taşır. Explicit external volume kullanılırsa isolation kaybolabilir. Cleanup project scope'undaki volume'ları silebilir. Production volume yanlışlıkla test job'a bağlanmamalıdır.

Aynı Sunucuda Birden Fazla Test Ortamı

Unique project name birden fazla stack'i paralel çalıştırır. Host portlar farklı olmalıdır veya yalnızca reverse proxy route kullanılır. CPU ve memory capacity planlanmalıdır. Preview environment TTL ile temizlenir. Network ve volume leakage izlenir.

CI Job Başına Benzersiz Project

Job ID project name'e eklenebilir. Parallel test birbirinin container'ını görmez. Cleanup doğru project'i hedefler. External shared cache kullanılıyorsa key ayrıca ayrılmalıdır. Docker daemon multi tenant güvenliği düşünülmelidir.

Development Image ile Production Image Arasındaki Güvenlik Farkı

Development image geliştiriciye rahatlık sağlayan debugger, compiler ve package manager araçlarını taşıyabilir. Production image'ın bu araçlara çoğu zaman ihtiyacı yoktur. Source code bile bazı compiled uygulamalarda final runtime'da gerekli olmayabilir. Multi stage build final image'a yalnızca çalışması gereken artifact'ı taşır. Böylece image küçülür ve gereksiz attack surface azaltılır.

Debugger

Debugger remote code control sağlayabildiği için production'da açık tutulmamalıdır. Port publish edilmemelidir. Debug library production dependency'den çıkarılabilir. Incident debugging log ve metric ile yapılmalıdır. Gerektiğinde güvenli ephemeral diagnostic araç kullanılabilir.

Compiler

Compiler application runtime için çoğu zaman gerekli değildir. Build stage içinde kalabilir. Final image'da bulunması exploit sonrası attacker'a ek araç sağlayabilir. Image boyutunu da artırır. Derlenmiş artifact runtime'a kopyalanır.

Package Manager

Package manager production container içinde manual install alışkanlığını teşvik edebilir. Yeni dependency image rebuild ile gelmelidir. Minimal runtime manager taşımayabilir. Security patch yeni image olarak build edilir. Immutable deployment prensibi korunur.

Shell

Bazı minimal image'larda shell bulunmayabilir. Bu security yüzeyini azaltabilir ancak operasyon debug yöntemini değiştirir. Application log ve health endpoint daha önemli olur. Shell gereksinimi gerçek operation ihtiyacına göre değerlendirilmelidir. Yalnızca image küçülsün diye debugging tamamen imkansız hale getirilmemelidir.

Source Code

Interpreted language runtime source code'a ihtiyaç duyabilir. Compiled application yalnızca binary taşıyabilir. Source secret değildir ancak intellectual property politikası olabilir. Production container'a host source bind mount yapılmamalıdır. Image digest exact code artifact'ını tanımlar.

Production Image'ı Minimal Tutmak

Minimal runtime gerekli binary ve runtime library'lerle sınırlıdır. Daha küçük image daha hızlı dağıtılabilir. Vulnerability finding sayısı azalabilir. Ancak certificate veya timezone data gibi gerekli runtime dosyaları unutulmamalıdır. Smoke test final image'ı doğrulamalıdır.

Saldırı Yüzeyini Azaltmak

Gereksiz package ve exposed port kaldırılır. Non root user kullanılır. Filesystem mümkünse read only tutulur. Secret image içine gömülmez. Runtime capability ve network erişimi minimumda tutulur.

Container'ları Neden Non-Root Çalıştırmalıyız?

Container içinde root kullanıcısı geniş filesystem ve process yetkilerine sahip olabilir. Container boundary kusursuz kabul edilmemelidir. Non root user exploit sonrası yapılabilecek işlemleri sınırlamaya yardımcı olur. Dockerfile USER bunun için temel araçtır. Development'ta UID ve GID eşlemesi bind mount permission sorunlarını azaltmak için ayrıca önemlidir.

Container Root Kullanıcısı

Birçok base image default root ile başlar. Build sırasında package installation için bu normal olabilir. Runtime'da root gereksinimi ayrıca sorgulanmalıdır. Application high port kullanabilir. File ownership doğru ayarlanmalıdır.

Host Riskleri

Container escape veya unsafe mount host üzerinde etki yaratabilir. Root process daha geniş yetki taşır. Privileged mode riski ciddi biçimde artırır. Docker socket erişimi host kontrolüne yakın yetki verebilir. Non root tek başına tüm bu riskleri çözmez.

Dockerfile USER

USER runtime identity'yi belirler. Application file'ları bu user tarafından okunabilir olmalıdır. Writable directory sınırlı tutulur. COPY chown ownership ayarlayabilir. Production stage sonunda USER açıkça tanımlanabilir.

UID ve GID

Linux permission numeric UID ve GID üzerinden çalışır. Host bind mount farklı UID nedeniyle permission error verebilir. Development image build arg ile user ID eşleyebilir. Production sabit application UID kullanabilir. Shared volume permission modeli test edilmelidir.

Bind Mount Permission Sorunları

Container user host dosyasına yazamıyorsa hot reload veya generated output bozulabilir. Root ile çalıştırmak hızlı fakat zayıf workaround'dur. UID mapping veya file ownership düzeltilmelidir. Read only source mount bazı projelerde yeterlidir. Generated output ayrı volume'a yazılabilir.

Development User ile Host User'ı Eşlemek

Developer UID build arg üzerinden container user'a verilebilir. Linux host'ta created files doğru ownership ile kalır. macOS ve Windows Desktop permission modeli farklı olabilir. Team script platform farkını yönetebilir. Production image bu dynamic user modeline bağımlı olmamalıdır.

Rootless Docker Nedir?

Rootless Docker hem daemon'ı hem container'ları root olmayan kullanıcı bağlamında çalıştırmayı amaçlar. Docker resmi belgelerine göre rootless mode daemon ve container runtime'ını user namespace içinde root yetkisi olmadan çalıştırarak daemon vulnerability etkisini azaltmaya yardımcı olur. :contentReference[oaicite:42]{index=42} Development makinelerinde güçlü güvenlik iyileştirmesi olabilir. Buna rağmen network, storage ve bazı low level feature sınırlamaları değerlendirilmelidir. CI runner kullanımı da workload ihtiyacına göre test edilmelidir.

Docker Daemon Yetkisi

Standart Docker daemon çoğunlukla host root yetkileriyle çalışır. Docker group üyeliği bu nedenle güçlü bir erişimdir. API üzerinden container ve mount oluşturulabilir. Daemon socket korunmalıdır. Rootless model risk alanını azaltır.

Rootless Mode

Rootless mode dockerd ve container'ları user namespace içinde çalıştırır. Docker belgelerine göre daemon kurulumunda bile root gerektirmeden kullanılabilir koşullar bulunur. :contentReference[oaicite:43]{index=43} User scope socket kullanılır. System integration behavior standard mode'dan farklı olabilir. Production'a geçmeden workload compatibility test edilmelidir.

User Namespace

User namespace container identity'lerini host user namespace'e map eder. Container root host root olmak zorunda değildir. Rootless mode bu yapıya dayanır. UID range prerequisite'leri sistemde tanımlanmalıdır. Volume ownership buna göre planlanır.

Geliştirme Makinesindeki Güvenlik Avantajı

Developer laptop'ta malicious build veya container riski vardır. Rootless daemon host root yetkisini doğrudan taşımadığı için etkiyi azaltabilir. Docker socket yine kullanıcı scope'unda güçlü yetkidir. Untrusted code ayrıca sandbox gerektirebilir. Team tooling rootless compatibility açısından test edilmelidir.

CI Runner'larda Rootless Docker

Ephemeral CI runner rootless Docker kullanabilir. Privileged Docker in Docker ihtiyacı azalabilir veya farklı uygulanabilir. Docker belgeleri rootless Docker in Docker image seçeneği de sunar. :contentReference[oaicite:44]{index=44} Build performance ve network behavior test edilmelidir. Runner isolation yalnızca Docker mode'a bırakılmamalıdır.

Rootless Mode'un Sınırlamaları

Bazı networking ve resource control özellikleri host configuration'a bağlı olabilir. Privileged port behavior farklılaşabilir. Storage driver seçimi etkilenebilir. Production monitoring tooling uyumluluğu kontrol edilmelidir. Security faydası gerçek operasyon ihtiyacıyla dengelenmelidir.

Docker Socket Neden Kritik Bir Güvenlik Sınırıdır?

Docker socket Engine API'ye erişim sağlar ve bu API container oluşturma, host path mount etme ve geniş runtime yetkileri isteme gibi güçlü işlemler yapabilir. Bu nedenle /var/run/docker.sock sıradan application socket'i değildir. Bir container'a socket mount edildiğinde o container host Docker daemon üzerinde geniş kontrol kazanabilir. CI runner ve development tool'ları bu erişimi gerçekten gerektirip gerektirmediği açısından incelenmelidir. Rootless Docker veya dar yetkili socket proxy bazı kullanım senaryolarında riski azaltabilir.

/var/run/docker.sock

Linux Docker daemon varsayılan olarak Unix socket üzerinden yönetilebilir. Docker CLI bu endpoint ile iletişim kurar. Socket permission güçlü bir güven sınırıdır. Web application container'ına doğrudan verilmemelidir. Access audit edilmelidir.

Docker API Yetkisi

API container create ve image operations yapabilir. Host bind mount tanımı yapılabilir. Privileged container başlatılabilir. Bu nedenle API access host yönetim yetkisine yakın düşünülebilir. Authentication ve transport security remote daemon'da kritik hale gelir.

Socket Mount Etmenin Host Üzerindeki Etkisi

Socket mount edilen container host daemon'a komut gönderebilir. Host filesystem'i yeni container üzerinden mount edilebilir. Container isolation böylece büyük ölçüde aşılabilir. Tool compromise host compromise'a dönüşebilir. Alternatif API scope modeli değerlendirilmelidir.

Development Tool'larında Socket Kullanımı

Bazı Dev Container araçları sibling container başlatmak için socket ister. Bu convenience güvenlik trade off yaratır. Trusted repository ile untrusted source aynı riskte değildir. Rootless user socket kullanılabilir. Tool permission dokümante edilmelidir.

CI Runner Riski

Untrusted Pull Request CI job'ı socket'e erişirse host üzerinde geniş kontrol elde edebilir. Shared runner için bu ciddi multi tenant riskidir. Ephemeral isolated VM runner daha güçlü sınır sağlar. Fork contribution privileged pipeline'da çalıştırılmamalıdır. Secret erişimi de ayrı sınırlandırılmalıdır.

Socket Proxy

Socket proxy belirli Docker API endpoint'lerini allowlist edebilir. Tool yalnızca ihtiyaç duyduğu read operation'a erişebilir. Ancak proxy configuration yanlışsa güvenlik faydası azalır. Host socket yine proxy arkasında yüksek yetkili kaynaktır. Authentication ve network erişimi korunmalıdır.

Rootless Docker

Rootless socket kullanıcı scope'unda çalışan daemon'a bağlanır. Host root erişim riski azalabilir. Yine de o kullanıcıya ait container ve dosyalar üzerinde güçlü yetki sağlar. Untrusted code'a kontrolsüz verilmemelidir. Rootless mode defense in depth katmanıdır.

Production Container'ı Immutable Hale Getirmek

Immutable container production değişikliklerinin yeni image build'i üzerinden gelmesini sağlar. Source code host'tan mount edilmez. Container içinde SSH ile dosya düzenlemek standart deployment yöntemi değildir. Root filesystem read only yapılabilir ve yalnızca gereken path'lere temporary write alanı sağlanabilir. Bu model deployment tekrarını ve rollback güvenilirliğini artırır.

Source Code Bind Mount Kullanmamak

Production source image içinde bulunmalıdır. Host folder değişince uygulamanın farkında olmadan değişmesi önlenir. Deployment image digest ile takip edilir. Rollback eski digest üzerinden yapılabilir. Configuration source koddan ayrılır.

Image İçindeki Kod

Application artifact image build sırasında eklenir. CI test ettiği aynı artifact'ı registry'ye push eder. Production container image'dan oluşturulur. Manual code copy yapılmaz. Build metadata commit SHA içerebilir.

Read-Only Root Filesystem

Compose service read_only ile root filesystem'i read only çalıştırabilir. Docker Compose servis referansı bu seçeneği destekler. :contentReference[oaicite:45]{index=45} Application write ihtiyacı ayrı volume veya tmpfs'e yönlendirilir. Log stdout'a gönderilebilir. Compatibility önce staging'de test edilmelidir.

Geçici Yazma Alanları

Application temporary file için writable alan isteyebilir. tmpfs veya dedicated volume kullanılabilir. Data container recreate sonrasında gerekmiyorsa tmpfs uygundur. Upload gibi persistent data object storage'a taşınabilir. Write path listesi minimum tutulmalıdır.

Yeni Version İçin Image Rebuild

Code patch container içine kopyalanmaz. Repository değişikliği CI build tetikler. Scan sonrası yeni image digest oluşturulur. Staging aynı digest'i test eder. Production controlled promotion ile güncellenir.

Container İçinde Manuel Değişiklik Yapmamak

Manual package install veya file edit history dışı state oluşturur. Container yeniden başladığında değişiklik kaybolabilir. Incident fix repository ve image üzerinden kalıcı hale getirilmelidir. Emergency change sonradan source'a geri işlenmelidir. Drift monitoring operational discipline'i destekler.

Docker Image Güvenliği

Image güvenliği base image seçiminden başlayıp build, scan, provenance ve registry yönetimine kadar uzanır. Minimal base gereksiz package sayısını azaltır. Multi stage build compiler ve secret kalıntılarını runtime'dan çıkarır. Digest belirli artifact'ı sabitler. SBOM, provenance ve signing supply chain görünürlüğünü güçlendirebilir.

Güvenilir Base Image

Base image kaynağı doğrulanmalıdır. Maintainer ve update policy bilinmelidir. Random public image production'da kullanılmamalıdır. Digest pinning supply chain değişikliğini kontrol eder. Security update ayrı build sürecinden geçer.

Minimal Base Image

Minimal image yalnızca runtime için gerekli package'ları taşır. Scan finding sayısı azalabilir. Download ve startup maliyeti düşebilir. Ancak application gerekli CA certificate veya locale dosyalarını kaybetmemelidir. Smoke test final runtime'ı doğrular.

Non-Root

Runtime user root olmamalıdır. Filesystem ownership build sırasında ayarlanır. Low privilege container exploit etkisini sınırlar. Capability gerekiyorsa explicit eklenir. Privileged mode normal production çözümü değildir.

Multi-Stage Build

Build tool final image dışında bırakılır. Compiler ve development package attack surface'i azaltılır. Sadece artifact runtime stage'e taşınır. Docker resmi dokümantasyonu bu kullanım modelini multi stage build'in temel avantajlarından biri olarak açıklar. :contentReference[oaicite:46]{index=46} Stage'ler CI'da ayrı test edilebilir.

Vulnerability Scanning

Image dependency ve OS package vulnerability açısından taranabilir. Critical finding merge veya deploy gate olabilir. Base image güncellemesi düzenli yapılmalıdır. False positive suppression gerekçeli olmalıdır. Scan sonucu artifact digest ile ilişkilendirilmelidir.

Secret Scanning

Docker build context ve repository secret açısından taranabilir. Image layer içinde credential bulunmamalıdır. BuildKit secret mount tercih edilir. Leak tespit edilirse credential rotate edilir. Sadece Git'ten satırı silmek yeterli değildir.

Image Digest

Digest content addressed identity sağlar. Tag değişebilir ancak digest belirli image içeriğini işaret eder. Deployment record digest saklayabilir. Rollback exact artifact'a döner. Build once promote everywhere modelinin temelidir.

SBOM

SBOM image içindeki package ve component listesini görünür hale getirir. Vulnerability incident sırasında affected image'ları hızlı bulmaya yardımcı olur. Build pipeline SBOM üretebilir. Registry veya artifact store saklayabilir. SBOM doğruluk ve güncellik açısından build artifact ile eşleşmelidir.

Provenance

Provenance artifact'ın nasıl ve hangi kaynaklardan build edildiğine dair metadata sağlar. CI builder identity ve source commit kaydedilebilir. Supply chain policy bu metadata'yı doğrulayabilir. Untrusted builder output production'a alınmayabilir. Provenance signing ile birlikte daha güçlü olur.

Image Signing

Image signing publisher identity ve artifact bütünlüğü hakkında ek güven sağlar. Deployment policy yalnızca güvenilir signer'dan gelen image'ı kabul edebilir. Key management kritik hale gelir. Signature vulnerability olmadığını garanti etmez. Scan ve review süreçleri yine gereklidir.

latest Tag Neden Production İçin Risklidir?

latest tag sabit version anlamına gelmez. Aynı tag zaman içinde farklı image içeriğine işaret edebilir. Deployment sunucusu yeniden pull yaptığında önceki gün test edilen artifact yerine başka content gelebilir. Version tag bu riski azaltır ancak tag yine mutable olabilir. Immutable digest production tekrar üretilebilirliği için daha güçlü referanstır.

Mutable Tag

Registry tag başka digest'e yeniden atanabilir. latest bunun en bilinen örneğidir. Deployment config aynı görünürken artifact değişebilir. Audit zorlaşır. Production digest kullanmalıdır.

Reproducibility

Aynı configuration'ın yarın aynı artifact'ı başlatması gerekir. Mutable tag bunu garanti etmez. Digest exact content'i tanımlar. CI release record digest saklar. Incident rollback daha güvenilir olur.

Version Tag

1.4.2 gibi version tag latest'ten daha anlamlıdır. Release identity okunabilir hale gelir. Registry policy tag overwrite işlemini engelleyebilir. Yine de digest deployment manifest'e kaydedilebilir. Version ve digest birlikte kullanılabilir.

Immutable Digest

Digest image content hash tabanlı referanstır. Aynı digest aynı content'i hedefler. Production promote işlemi digest üzerinden yapılabilir. Registry garbage collection retention'a göre yönetilmelidir. Deployment system digest'i loglamalıdır.

SHA-256 Pinning

Image reference digest formunda yazılabilir. Böylece pull exact artifact getirir. Base image Dockerfile'da da digest ile pin edilebilir. Security patch otomatik gelmez ve bilinçli update gerekir. Dependency update automation bu süreci yönetebilir.

Rollback İçin Eski Digest'i Saklamak

Registry retention son birkaç production digest'ini korumalıdır. Deployment metadata previous digest'i kaydeder. Incident sırasında image rebuild yapılmaz. Eski artifact doğrudan pull edilir. Database compatibility ayrıca doğrulanır.

Container Registry Nasıl Kullanılmalı?

Registry CI ile deployment arasındaki immutable artifact deposudur. Image build sonrası scan edilir ve registry'ye push edilir. Deployment yetkisi yalnızca gerekli repository path'lerine erişmelidir. Retention eski preview image'ları temizlerken rollback için gereken release'leri korumalıdır. Authentication mümkünse short lived token veya workload identity üzerinden sağlanmalıdır.

Docker Hub

Docker Hub public ve private image dağıtımı için kullanılabilen registry hizmetidir. Public base image'lar burada bulunabilir. Production pull rate ve authentication ihtiyaçları değerlendirilmelidir. Organization access düzenli gözden geçirilmelidir. Critical base image digest ile pinlenebilir.

GitHub Container Registry

GitHub Container Registry repository workflow'larıyla image saklamayı ilişkilendirebilir. Package permission ve repository access birlikte yönetilebilir. CI token minimum scope ile kullanılmalıdır. Image tag ve digest release metadata'ya bağlanabilir. Retention policy build sayısına göre planlanmalıdır.

GitLab Container Registry

GitLab Container Registry proje CI pipeline'larıyla image lifecycle'ını aynı proje alanında yönetebilir. Pipeline build ettiği artifact'ı registry'ye push edebilir. Deployment digest referansını kullanabilir. Credential job scope'una göre sınırlandırılmalıdır. Cleanup policy rollback image'larını korumalıdır.

Cloud Registry

Cloud registry managed identity ve regional distribution sağlayabilir. Deployment workload platform identity üzerinden pull yapabilir. Network private endpoint ile sınırlandırılabilir. Image scanning service entegre olabilir. Cost ve retention behavior takip edilmelidir.

Private Registry

Self hosted private registry data control sağlar. TLS ve authentication doğru kurulmalıdır. Backup registry metadata ve blob storage'ı kapsamalıdır. High availability gerçek deployment ihtiyacına göre planlanır. Güncelleme ve security patch operasyon sorumluluğu ekipte kalır.

Image Push

CI verified image'ı registry'ye push eder. Developer local production release push etmemelidir. Tag ve digest pipeline output'unda kaydedilir. Push credential write scope ile sınırlıdır. Scan sonucu release gate'e bağlanabilir.

Image Pull

Deployment host yalnızca gerekli image repository'sine read erişimi alır. Digest ile pull exact artifact getirir. Registry unavailable ise deployment etkilenebilir. Local cache mevcut container'ı çalıştırmaya devam edebilir. Recovery plan registry dependency'sini dikkate almalıdır.

Registry Authentication

Long lived password yerine short lived token tercih edilebilir. Credential CI secret store'da tutulur. Developer kişisel account production deployment'ta kullanılmamalıdır. Access log audit edilir. Credential rotation düzenli yapılır.

Retention Policy

Her commit image'ı sonsuza kadar saklamak pahalı olabilir. Preview image kısa süreli tutulabilir. Production release ve previous rollback digest'leri daha uzun korunur. Legal veya audit requirement ayrıca uygulanır. Cleanup kullanılan deployment metadata ile koordineli olmalıdır.

CI/CD ile Docker Image Yaşam Döngüsü

Docker image yaşam döngüsü Git push ile başlayıp production promotion ile tamamlanabilir. Testler source düzeyindeki hataları yakalar. Build tek immutable image üretir. Vulnerability scan, SBOM ve digest metadata bu artifact'la ilişkilendirilir. Registry'ye push edilen aynı digest staging ve production ortamlarına taşınır.

Git Push

Repository değişikliği CI pipeline tetikler. Commit SHA build identity olarak kullanılır. Pull Request branch farklı policy alabilir. Secret yalnızca gerekli job'a açılır. Untrusted fork pipeline production credential alamaz.

Test

Unit ve integration test build öncesi veya stage içinde çalışabilir. Failure image release'i durdurur. Test container aynı runtime kullanır. Coverage tek kalite sinyali değildir. Test logları artifact olarak saklanabilir.

Docker Build

CI Dockerfile'dan image oluşturur. BuildKit cache kullanabilir. Build secret temporary mount üzerinden verilir. Version metadata label olarak eklenebilir. Build sonucu local değil registry artifact'ına dönüşür.

Vulnerability Scan

Final image taranır. Critical vulnerability release'i engelleyebilir. Base image finding'leri ayrıca izlenir. Exception expiration içermelidir. Scan digest ile ilişkilendirilir.

SBOM

Build pipeline component listesi oluşturabilir. SBOM release metadata ile saklanır. Incident response package usage bulmayı hızlandırır. Artifact değişirse SBOM yeniden üretilir. Production deployment digest ile SBOM eşleştirilebilir.

Image Tag

Version tag insan okunabilir release identity sağlar. Commit SHA tag'i debug için faydalıdır. latest production source of truth olmamalıdır. Tag overwrite policy sınırlandırılabilir. Digest gerçek immutable identity olarak kalır.

Image Digest

Registry push sonrası digest alınır. Pipeline bu değeri deployment manifest'e aktarabilir. Staging aynı digest'i kullanır. Production promotion rebuild yapmaz. Rollback previous digest'e döner.

Registry Push

CI release artifact'ını trusted registry'ye gönderir. Push permission pipeline identity'ye aittir. Developer token'ı kullanılmaz. Network transfer TLS üzerinden yapılır. Registry retention release politikasıyla uyumludur.

Staging Deployment

Staging production adayı digest'i çalıştırır. Migration ve smoke tests tamamlanır. Configuration staging değerlerinden gelir. Production data kullanılmaz. Onay sonrası digest promote edilir.

Production Promotion

Promotion yeni build oluşturmaz. Approved digest production config'e alınır. Deployment event audit edilir. Health ve smoke test sonucu izlenir. Previous digest rollback için tutulur.

Docker Deployment Ortamları Nasıl Ayrılmalı?

Development, automated test, QA, staging ve production aynı application artifact zincirini kullanabilir ancak configuration, secret ve data kesin olarak ayrılmalıdır. Docker ile development staging production ortamları nasıl ayrılır sorusunun temel cevabı her ortamı ayrı identity ve ayrı kaynak sınırlarıyla yönetmektir. Production database local development'a bağlanmamalıdır. Network ve credential scope ortam bazında ayrılmalıdır. Aynı image digest'in farklı configuration ile çalıştırılması artifact parity sağlar.

Development

Development hızlı feedback ve debug için optimize edilir. Source mount veya Watch kullanılır. Dummy secret ve synthetic data bulunur. Resource limitler laptop'a göre ayarlanır. Production network erişimi bulunmaz.

Automated Test

Test environment CI job başına geçici oluşturulur. Fresh database kullanılır. Migration uygulanır. Test tamamlanınca stack silinir. Production credential bu ortamda bulunmaz.

QA

QA environment daha uzun ömürlü olabilir. Product ve test ekipleri ortak senaryolar çalıştırır. Test data controlled tutulur. Image staging adayı olabilir. Configuration production'a benzeyebilir.

Staging

Staging production deployment modeline yakın olmalıdır. Aynı image digest burada doğrulanır. Secret staging scope'una aittir. Network erişimi production'dan ayrı olmalıdır. Smoke ve migration testleri release gate sağlar.

Production

Production gerçek kullanıcı trafiğini taşır. Minimal image ve immutable deployment kullanır. Secret manager ve backup policy devrededir. Logging ve monitoring merkezi olmalıdır. Change yalnızca CI/CD promotion ile gelmelidir.

Ortama Özel Configuration

Domain ve log level ortam bazında değişebilir. Config image içine baked edilmez. Environment variable veya config file kullanılır. Schema aynı kalmalıdır. Değer validation startup'ta yapılmalıdır.

Ortama Özel Secret

Development ve production aynı credential'ı paylaşmamalıdır. Her environment ayrı key ve database user kullanır. Rotation bağımsız yapılabilir. Secret manager namespace ile ayrım sağlayabilir. Cross environment access engellenmelidir.

Ortama Özel Database

Her environment kendi database instance veya database alanına sahip olmalıdır. Test production data yazmamalıdır. Schema migration aynı source code'dan gelir. Backup production'da ayrı gereksinim taşır. Sanitized data kullanımı bile kontrollü olmalıdır.

Ortama Özel Network

Development network production VPC'ye bağlanmamalıdır. Staging ayrı security boundary kullanır. Firewall kuralları environment scope'unda tutulur. DNS isimleri environment bazında farklıdır. Private database public ingress almaz.

Development ve Production Verisi Neden Ayrı Olmalıdır?

Development ortamında yapılan deneysel işlemler production verisine zarar verebilir. Local laptop kaybolabilir veya malware etkilenebilir. Production PII development'a taşındığında erişim alanı gereksiz genişler. Test için synthetic veya dikkatle sanitize edilmiş data kullanılmalıdır. Environment isolation yalnızca container değil veri sınırları açısından da uygulanmalıdır.

Production Database'e Lokalden Bağlanmanın Riski

Yanlış SQL gerçek data'yı değiştirebilir. Local tool credential sızdırabilir. Developer laptop production network'e kalıcı erişim kazanır. Audit zorlaşır. Production erişimi kontrollü operational channel üzerinden yapılmalıdır.

Test Data

Test data scenario ihtiyacına göre üretilir. Gerçek customer kaydı kullanılmaz. Edge case synthetic olarak oluşturulabilir. Seed tekrar üretilebilir olmalıdır. Test sonunda temizlenebilir.

Sanitized Data

Sanitization hassas alanları maskeler veya değiştirir. Ancak ilişkili alanlar kişiyi yeniden tanımlayabilir. Güvenlik review gerekir. Synthetic data çoğu durumda daha güvenlidir. Sanitized export retention sınırlı tutulmalıdır.

PII

Kişisel veri minimum environment'ta bulunmalıdır. Development kullanıcılarının erişim ihtiyacı çoğunlukla yoktur. Log ve backup da PII taşıyabilir. Data policy teknik pipeline ile enforce edilmelidir. Test fixture kişisel veri içermemelidir.

Data Masking

Masking email veya isim gibi alanları dönüştürebilir. Referential integrity korunmalıdır. Production secret veya payment token hiçbir zaman kopyalanmamalıdır. Masking işlemi export sırasında otomatikleşebilir. Dataset access kayıt altına alınmalıdır.

Environment Isolation

Her environment ayrı credential ve network kullanır. Database endpoint karıştırılması zorlaşır. Production destructive command development script'inden erişilemez. Monitoring environment label taşır. Backup ve retention politikaları ortam bazında tanımlanır.

Docker Compose Production'da Kullanılabilir mi?

Docker Compose tek host üzerinde çalışan küçük veya orta ölçekli uygulamalarda production deployment için kullanılabilir. Operasyon modelinin basit kalması önemli avantajdır. Ancak Compose multi host scheduling, gelişmiş cluster self healing ve native rolling orchestration gibi özellikleri tek başına sağlamaz. Bu nedenle workload ve availability beklentisi kararın merkezinde olmalıdır. Tek sunuculu uygulamayı yalnızca popüler olduğu için daha büyük orchestrator'a taşımak gereksiz operasyon yükü doğurabilir.

Tek Sunuculu Deployment

Compose tek Docker host üzerinde service stack yönetir. Reverse proxy ve application birlikte çalışabilir. Restart policy process failure sonrası yeniden başlatma sağlayabilir. Host failure tüm stack'i etkiler. High availability gerekiyorsa ek çözüm gerekir.

Küçük ve Orta Ölçekli Uygulamalar

Az sayıda service ve predictable traffic Compose için uygun olabilir. Deployment script basit kalır. Team küçükse operational overhead düşer. Backup ve monitoring yine ciddi şekilde ele alınmalıdır. Ölçek büyüdükçe limitler düzenli gözden geçirilir.

Predictable Traffic

Workload sabitse manual replica capacity yeterli olabilir. Horizontal autoscaling gerekmeyebilir. Resource limit host kapasitesine göre ayarlanır. Peak trafik önceden planlanır. Ani workload değişimi orchestrator ihtiyacını artırabilir.

Operasyonel Basitlik

Tek host daha az moving part taşır. Troubleshooting daha kolay olabilir. Docker Engine ve OS update sorumluluğu yine vardır. Deployment rollback script ile yönetilebilir. Basitlik reliability açısından gerçek bir avantaj olabilir.

Compose'un Sağlamadığı Özellikler

Compose multi host scheduler değildir. Node failure sonrası container'ı başka host'a taşımaz. Cluster service discovery ve autoscaling sınırlıdır. Rolling update kontrolü orchestrator seviyesinde değildir. Bu ihtiyaçlar arttığında başka platform düşünülmelidir.

Compose Kullanılmaması Gereken Durumlar

Strict multi host high availability gerekiyorsa Compose tek başına yetersizdir. Yüzlerce microservice operasyonu zorlaşabilir. Automated horizontal scaling beklentisi varsa orchestrator daha uygundur. Complex rollout policy native support isteyebilir. Karar ekip operasyon kapasitesiyle birlikte verilmelidir.

Production Compose Dosyası Nasıl Olmalıdır?

Production Compose development dosyasının doğrudan kopyası olmamalıdır. Source bind mount kaldırılmalı ve prebuilt immutable image kullanılmalıdır. Healthcheck, restart, resource ve logging ayarları açıkça tanımlanmalıdır. Secret değerler repository'de bulunmamalıdır. Network yalnızca gerekli servis ilişkilerini açacak şekilde tasarlanmalıdır.

Source Bind Mount Olmaması

Application code image içinden çalışmalıdır. Host filesystem change production code'u değiştirmemelidir. Configuration gerekiyorsa read only mount veya environment kullanılabilir. Release yeni image ile yapılır. Rollback eski digest üzerinden gerçekleştirilir.

Immutable Images

Image CI tarafından build edilir. Runtime host image içinde package install etmez. Tag overwrite engellenebilir. Digest deployment identity olarak tutulur. Scan aynı artifact üzerinde yapılır.

Digest Pinning

Production Compose image reference digest içerebilir. Böylece pull exact artifact getirir. Human readable version deployment metadata'da ayrıca tutulur. Rollback previous digest ile yapılır. Registry retention buna göre ayarlanır.

Named Volumes

Stateful data named volume'da tutulabilir. Container recreate data'yı silmez. Backup strategy volume semantics'i dikkate alır. Database için native backup tercih edilir. Volume permission non root user ile uyumlu olmalıdır.

Healthchecks

Service health production monitoring için sinyal sağlar. Probe gerçek service behavior'ı test etmelidir. Timeout ve retry değerleri uygun olmalıdır. Reverse proxy yalnız healthy backend'e routing yapacak external mekanizmayla entegre olabilir. Unhealthy container behavior runbook'ta tanımlanmalıdır.

Restart Policy

Unexpected process exit sonrası restart policy yardımcı olur. unless-stopped sık kullanılan seçeneklerden biridir. Crash loop logging ve alert üretmelidir. Restart gerçek bug'ı gizlememelidir. Healthcheck unhealthy state'iyle arasındaki fark bilinmelidir.

Resource Limits

CPU ve memory limitleri host'u tek service'in tüketmesini önler. Çok düşük limit performance sorununa yol açar. OOM olayları monitoring'e alınmalıdır. Capacity planning gerçek metric'e dayanır. Compose resource specification uygun biçimde kullanılabilir. :contentReference[oaicite:47]{index=47}

Logging

Application stdout ve stderr'e structured log yazabilir. Docker logging driver rotation ayarı olmalıdır. Merkezi log collector gerektiğinde eklenir. Secret loglanmamalıdır. Disk kullanım alert'i konulmalıdır.

Secrets

Production secret source control dışında tutulur. Service yalnızca gerekli secret'a erişir. Compose secrets file mount sağlayabilir. Secret manager daha güçlü rotation ve audit sunabilir. Runtime credential minimum privilege ile çalışmalıdır.

Network Isolation

Database public port yayınlamaz. Proxy public network ve backend private network arasında bulunur. Cache yalnız application network'üne bağlıdır. Gereksiz cross service iletişim kaldırılır. Host firewall ek koruma sağlar.

Resource Limits Neden Gereklidir?

Container host kaynaklarını limitsiz kullanırsa memory leak veya runaway process tüm uygulamayı etkileyebilir. Resource limit noisy neighbor etkisini azaltır. CPU ve memory sınırı workload'a göre ayrı düşünülmelidir. Çok düşük limit container'ı sürekli throttle veya OOM durumuna sokabilir. Capacity planning limit belirlemenin doğal devamıdır.

CPU Limit

CPU limit container'ın kullanabileceği processing kapasitesini sınırlar. Burst workload etkilenebilir. Latency metric limit kararında izlenmelidir. Development limit daha esnek olabilir. Production host oversubscription kontrollü yapılmalıdır.

Memory Limit

Memory limit process'in allocate edebileceği bellek alanını sınırlar. Uygulama heap ayarı container limitini bilmelidir. Cache workload daha yüksek memory isteyebilir. Limit aşımı OOM kill oluşturabilir. Alerting memory trend'i izlemelidir.

OOM

Out of memory container process'inin kill edilmesine yol açabilir. Restart policy tekrar başlatabilir ancak root cause çözülmez. Memory leak veya yanlış limit araştırılmalıdır. Heap dump gerekiyorsa güvenli artifact alınabilir. OOM rate capacity problemine işaret eder.

Bir Container'ın Host'u Tüketmesini Önlemek

Her critical service için üst resource sınırı tanımlanabilir. PID limit fork bomb riskini azaltabilir. Disk I/O ayrıca gözlenmelidir. Host reserved capacity bırakılmalıdır. Monitoring per container metric sağlamalıdır.

Development ve Production Limitleri

Developer laptop daha düşük total resource'a sahip olabilir. Production workload daha yüksek concurrency taşır. Aynı limitleri kör biçimde kopyalamak doğru değildir. Relative behavior test edilmelidir. Config override environment farkını yönetebilir.

Capacity Planning

Historical CPU ve memory metric incelenir. Peak ve growth trend hesaplanır. Headroom belirlenir. Tek host failure impact değerlendirilir. Orchestrator veya scaling ihtiyacı bu veriden çıkarılabilir.

Docker Logları Nasıl Yönetilmelidir?

Container uygulamaları loglarını stdout ve stderr'e yazdığında Docker logging driver bu stream'leri toplayabilir. Docker'ın varsayılan json-file driver'ı container loglarını dosyada tutar ve rotation yapılmazsa disk kullanımı büyüyebilir. Docker belgeleri max-size ve max-file ayarlarıyla rotation uygulanabileceğini gösterir. :contentReference[oaicite:48]{index=48} Production'da merkezi log sistemi search ve retention ihtiyacını karşılayabilir. Secret ve kişisel veri logging policy ile korunmalıdır.

stdout ve stderr

Application normal loglarını stdout'a yazabilir. Error stream stderr için kullanılabilir. Host file path'e doğrudan yazma ihtiyacı azalır. Docker logging driver output'u toplar. Structured JSON format merkezi sistemde parse edilebilir.

json-file

json-file Docker'ın yaygın default logging driver'ıdır. Loglar Docker tarafından yönetilen dosyalara yazılır. External tool doğrudan bu dosyaları değiştirmemelidir. Docker belgeleri bunun daemon tarafından yönetilmesi gerektiğini belirtir. :contentReference[oaicite:49]{index=49} Rotation ayrıca etkinleştirilmelidir.

Local Logging Driver

Local driver rotation ve compression davranışı sunabilir. Docker belgelerinde default size ve file count seçenekleri bulunur. :contentReference[oaicite:50]{index=50} Host disk kullanımını kontrol etmeyi kolaylaştırabilir. Central collector ile compatibility test edilmelidir. Existing container ayarı recreate gerekebilir.

Log Rotation

Rotation log dosyasının limitsiz büyümesini engeller. Size ve file count belirlenebilir. Retention central log store'da ayrıca yapılır. Disk alert rotation başarısızlığını yakalar. Debug logging production'da sürekli açık kalmamalıdır.

max-size

max-size tek log dosyasının rotate edilmeden önceki maksimum boyutunu belirler. Docker json-file driver bu option'ı destekler. :contentReference[oaicite:51]{index=51} Değer uygulama log hacmine göre seçilmelidir. Çok küçük size incident context'i azaltabilir. Central shipping varsa local retention daha kısa olabilir.

max-file

max-file tutulacak rotated log dosyası sayısını sınırlar. json-file driver'da max-size ile birlikte kullanılır. :contentReference[oaicite:52]{index=52} Disk kullanım üst sınırı daha tahmin edilebilir olur. Central log retention bundan bağımsızdır. Host troubleshooting için birkaç file yararlı olabilir.

Merkezi Log Yönetimi

Birden fazla host olduğunda local docker logs yeterli olmaz. Log collector merkezi search ve retention sağlar. Service, version ve environment label eklenmelidir. Secret masking ingestion öncesi uygulanabilir. Access control log içeriğine göre sınırlandırılmalıdır.

Disk Dolmasını Önlemek

Rotation ilk savunmadır. Disk usage monitoring alert üretmelidir. Crash loop log hacmini hızla artırabilir. Old image ve cache cleanup ayrı alan kazandırır. Production cleanup otomatik fakat kontrollü yapılmalıdır.

Eski Image ve Container'lar Nasıl Temizlenir?

Docker host zamanla stopped container, dangling image ve build cache biriktirebilir. Cleanup yapılmazsa disk alanı dolabilir. Ancak volume prune yanlış kullanılırsa kalıcı data kaybı oluşabilir. Production cleanup hangi resource'un deployment tarafından kullanıldığını bilerek yapılmalıdır. Registry retention ve host cleanup ayrı süreçler olarak tasarlanmalıdır.

Orphan Container

Compose config'ten kaldırılan eski service container host'ta kalabilir. Orphan resource yanlış port veya network kullanabilir. Compose startup warning gösterebilir. Cleanup kontrollü yapılmalıdır. Production'da service removal deployment değişikliği olarak audit edilir.

--remove-orphans

--remove-orphans Compose modelinde artık bulunmayan ilgili project container'larını kaldırabilir. Local development'ta faydalıdır. Yanlış project name hedeflenmemelidir. Production deploy öncesi config diff incelenmelidir. Data volume davranışı ayrıca kontrol edilmelidir.

Dangling Image

Dangling image artık tag referansı olmayan local image layer'ları olabilir. Build işlemleri zamanla bunları biriktirebilir. Prune disk alanı kazandırır. Running container image layer'ı korunur. Rollback için gerekli image registry'de bulunmalıdır.

Build Cache

BuildKit cache development ve CI hızını artırır. Sonsuza kadar tutulması gerekmez. Size metric izlenebilir. Cleanup sonrası ilk build yavaşlar. Remote cache varsa local prune daha rahat yapılabilir.

Image Prune

Image prune kullanılmayan image'ları temizleyebilir. Production host'ta previous rollback image kaybolabilir. Registry pull mümkün olsa da incident sırasında network dependency oluşur. Retention planı belirlenmelidir. Automation dry run veya filter kullanabilir.

Container Prune

Stopped container'lar disk metadata tüketir. Prune bunları temizleyebilir. Debug için gerekli stopped container logu önceden alınmalıdır. Compose project cleanup daha kontrollü olabilir. Production change management ile uyumlu yapılmalıdır.

Volume Prune Riskleri

Volume persistent data taşıyabilir. Unused görünmesi gereksiz olduğu anlamına gelmez. Database volume yanlışlıkla silinirse data kaybı yaşanabilir. Automatic global volume prune production'da risklidir. Backup ve ownership metadata önemlidir.

Production'da Kontrollü Cleanup

Cleanup script allowlist ve age filter kullanabilir. Current ve previous release image korunur. Volume global olarak silinmez. Disk threshold monitoring manual approval tetikleyebilir. İşlem audit log üretmelidir.

Persistent Data Nasıl Yönetilmelidir?

Container ephemeral olarak düşünülürken business data container lifecycle'dan bağımsız tutulmalıdır. Named volume tek host üzerinde persistence sağlayabilir. Daha kritik workload external database veya object storage kullanabilir. Application mümkün olduğunca stateless tasarlanır. Böylece container recreate ve scaling işlemleri data güvenliğini doğrudan etkilemez.

Named Volume

Named volume Docker managed local storage sağlar. Tek host database için kullanılabilir. Container recreate data'yı korur. Host failure'a karşı tek başına backup değildir. Backup offsite tutulmalıdır.

Bind Mount

Bind mount belirli host path üzerinde data saklar. Operational team path'i doğrudan yönetir. Permission ve backup sorumluluğu artar. Host migration path bağımlılığı taşır. Business data için dikkatli kullanılmalıdır.

External Database

Database container stack dışında managed veya dedicated service olabilir. Backup ve high availability ayrı katmanda yönetilir. Application environment variable ile endpoint alır. Network private tutulur. Deployment container recreate database'i etkilemez.

Object Storage

User upload container filesystem'inde tutulmamalıdır. Object storage stateless application scaling'i kolaylaştırır. Access credential minimum permission alır. Signed URL kullanılabilir. Backup ve lifecycle policy storage tarafında yönetilir.

Container Silindiğinde Verinin Korunması

Persistent data container writable layer'da kalmamalıdır. Volume veya external store kullanılır. Deployment recreate işlemi safe hale gelir. Backup ayrıca gereklidir. Restore düzenli test edilmelidir.

Stateless Application Tasarımı

Application session state external cache veya database'e taşınabilir. Container herhangi bir host'ta yeniden oluşturulabilir. Horizontal scaling kolaylaşır. Local temporary file tmpfs kullanabilir. Stateful workload ayrı servis olarak ele alınır.

Docker Volume Backup Nasıl Alınır?

Volume backup yöntemi içerdiği data tipine göre seçilmelidir. Database volume'ını container çalışırken raw file copy yapmak tutarlı backup üretmeyebilir. Database native dump veya snapshot mekanizması daha güvenlidir. Backup offsite ve şifreli tutulmalıdır. En önemli adım backup almak kadar restore testini düzenli yapmaktır.

Database-Native Backup

Database engine kendi consistent dump veya physical backup aracını sunar. Transaction state doğru yönetilir. Restore version compatibility bilinmelidir. Backup automation schedule edilir. Result checksum ve failure alert tutulur.

Volume Backup

Non database file data volume archive olarak yedeklenebilir. Application write işlemi pause gerekebilir. Permission metadata korunmalıdır. Backup container geçici olarak volume mount edebilir. Restore path ayrı environment'ta test edilir.

Snapshot

Storage backend snapshot hızlı point in time copy sağlayabilir. Application consistency yine değerlendirilmelidir. Database flush veya snapshot integration gerekebilir. Snapshot aynı region failure'a karşı yeterli olmayabilir. Offsite copy tutulmalıdır.

Offsite Backup

Backup production host ile aynı disk üzerinde bırakılmamalıdır. Farklı failure domain kullanılmalıdır. Access credential ayrı tutulur. Retention lifecycle belirlenir. Restore bandwidth gereksinimi planlanır.

Encryption

Backup hassas production data içerir. At rest encryption uygulanmalıdır. Transfer TLS üzerinden yapılır. Key management backup'tan ayrı tutulur. Restore yapan identity minimum yetkiye sahip olmalıdır.

Backup Retention

Daily ve weekly retention business requirement'a göre seçilir. Sonsuz backup maliyet ve privacy riski taşır. Regulatory retention ayrıca uygulanır. Deletion policy otomatik olabilir. Critical restore point'ler legal hold altında tutulabilir.

Restore Testi

Backup file varlığı restore edilebilir olduğunu garanti etmez. Düzenli isolated environment'ta restore yapılmalıdır. Application smoke test çalıştırılır. RTO ve RPO ölçülür. Failure runbook güncellenir.

Docker Deployment Nasıl Güncellenir?

Deployment update source code kopyalamak yerine yeni image artifact'ının devreye alınmasıdır. CI yeni image build eder ve registry'ye push eder. Host exact digest'i pull eder. Database migration gerektiğinde kontrollü job olarak çalıştırılır. Yeni container health doğrulamasından sonra eski release rollback için saklanabilir.

Yeni Image Build

CI belirli commit'ten image oluşturur. Test ve scan tamamlanır. Version ve digest metadata üretilir. Developer laptop production artifact build etmez. Build log audit için saklanır.

Registry Push

Image trusted registry'ye push edilir. Write credential yalnız CI'da bulunur. Immutable tag policy uygulanabilir. Digest pipeline output'una yazılır. Registry scan gerekirse tetiklenir.

Image Pull

Deployment host yeni digest'i pull eder. Existing container çalışmaya devam eder. Pull failure release'i durdurur. Registry authentication short lived olabilir. Disk capacity kontrol edilir.

Container Recreate

Compose yeni image ile service'i recreate eder. Persistent volume aynı kalabilir. Environment config version doğrulanır. Healthcheck success beklenir. Failure previous image'a dönüşü tetikleyebilir.

Database Migration

Migration rollout sırasına göre çalıştırılır. Backward compatible schema tercih edilir. Long running operation application restart'tan ayrılır. Failure deployment'ı durdurur. Rollback database compatibility açısından değerlendirilir.

Health Verification

Container running state yeterli değildir. Healthcheck ve smoke test uygulanır. External endpoint response doğrulanır. Error rate monitoring takip edilir. Başarısız release geri alınır.

Eski Image'ı Rollback İçin Saklamak

Previous production digest registry'de korunur. Host cache'de bulunması faydalıdır. Configuration version da kayıt edilir. Database migration old version compatibility'yi korumalıdır. Rollback command runbook'ta hazır tutulur.

Docker Deployment Rollback Nasıl Yapılır?

Rollback yeni release sorun çıkardığında daha önce doğrulanmış artifact'a geri dönmeyi hedefler. Previous image digest deployment sisteminde kayıtlı olmalıdır. Configuration da sürümle birlikte takip edilmelidir. Database schema eski application ile uyumlu değilse simple image rollback tehlikeli olabilir. Healthcheck ve smoke test rollback sonrasında yeniden çalıştırılmalıdır.

Previous Image Digest

Eski release exact digest ile tanımlanır. Mutable tag kullanılmaz. Registry retention artifact'ı korur. Rollback yeniden build yapmaz. Deployment log hangi digest'e dönüldüğünü gösterir.

Previous Configuration

Release yalnız image değişikliği olmayabilir. Environment variable veya feature flag de değişmiş olabilir. Config version source control veya secret manager metadata'da tutulmalıdır. Rollback uyumlu config'i restore eder. Secret rotation geri alınmayabilir ve ayrıca planlanır.

Database Compatibility

Yeni schema old application'ı bozabilir. Expand contract migration bu riski azaltır. Destructive migration deploy ile aynı anda yapılmamalıdır. Rollback test staging'de denenmelidir. Data change geri alınamıyorsa fix forward gerekebilir.

Rollback Command

Runbook exact deployment komutunu içermelidir. Human typo riski azaltılır. Script current ve target digest'i gösterir. Production confirmation guard eklenebilir. Command audit log üretir.

Healthcheck

Eski image başlatıldıktan health status beklenir. Dependency compatibility doğrulanır. Timeout oluşursa escalation yapılır. Healthcheck yalnız internal endpoint'e bağlı olmamalıdır. External smoke test eklenir.

Smoke Test

Critical user flow hızlıca test edilir. Login veya ana API endpoint kontrol edilebilir. Database write behavior gerekirse doğrulanır. Synthetic account kullanılır. Sonuç incident timeline'a eklenir.

Rollback Sonrası Incident Analizi

Rollback kullanıcı etkisini azaltır fakat root cause'u çözmez. Failed release diff ve metrics incelenir. Test neden yakalamadı değerlendirilir. Yeni fix normal CI sürecinden geçer. Runbook öğrenmelerle güncellenir.

Zero-Downtime Deployment Docker Compose ile Yapılabilir mi?

Compose ile sıfır kesinti hedeflenebilir ancak native orchestrator rolling update deneyimi sunmaz. Blue green yaklaşımı iki ayrı Compose stack çalıştırarak uygulanabilir. Reverse proxy yalnız healthy yeni stack'e trafik yönlendirir. Switch sonrası eski stack kısa süre rollback için açık kalır. Çok sık deployment ve yüksek availability gereksiniminde orchestrator operasyonu daha doğal hale getirebilir.

Compose'un Sınırları

Compose desired replica rollout controller değildir. Service recreate kısa kesinti yaratabilir. Multi host scheduling yapmaz. Blue green logic dış automation gerektirir. Basit uygulamada bu yine yeterli olabilir.

Reverse Proxy

Proxy active environment'a traffic route eder. Blue ve green backend network'lerine erişebilir. Healthcheck başarısız environment'a switch yapılmaz. Config reload kesintisiz olmalıdır. TLS termination aynı proxy'de kalabilir.

Blue-Green Deployment

Current release blue olarak çalışır. New release green stack'te başlatılır. Smoke tests green üzerinde çalışır. Proxy traffic green'e alınır. Blue rollback için kısa süre saklanır.

İkinci Stack

Aynı host iki release'i eş zamanlı taşımalıdır. CPU ve RAM capacity yeterli olmalıdır. Unique project name resource çakışmasını önler. Host portlar farklı olabilir. Shared database schema iki version ile uyumlu olmalıdır.

Traffic Switch

Proxy upstream tek operation ile değiştirilebilir. Existing connection davranışı dikkate alınmalıdır. DNS switch daha yavaş cache etkisi yaratabilir. Proxy route genellikle daha kontrollüdür. Switch audit edilir.

Healthcheck

Green stack switch öncesi healthy olmalıdır. Internal health yanında external smoke test yapılır. Warm up tamamlanmalıdır. Database migration hazır olmalıdır. Failed check release'i durdurur.

Rollback

Traffic tekrar blue stack'e yönlendirilebilir. Bu işlem image rebuild gerektirmez. Database compatibility korunmuş olmalıdır. Green logları incident için saklanır. Root cause sonrası yeni release hazırlanır.

Ne Zaman Orchestrator Kullanılmalı?

Birden fazla host ve frequent rollout gerekiyorsa orchestrator değerlendirilebilir. Automated self healing ve scheduling ihtiyacı güçlü sinyaldir. Horizontal scaling artıyorsa manual Compose zorlaşır. Team operasyon kapasitesi de dikkate alınmalıdır. Araç geçişi gerçek problem çözmelidir.

Blue-Green Docker Deployment

Blue green modeli aynı uygulamanın iki ayrı environment'ını paralel çalıştırır. Blue mevcut production release'i, green yeni adayı temsil eder. Her ikisi aynı image artifact zincirinden yönetilir. Green health ve smoke test sonrasında reverse proxy trafiği yeni ortama geçirir. Sorun çıkarsa blue ortamına hızlı dönüş yapılabilir.

Blue Environment

Blue aktif kullanıcı trafiğini taşır. Current digest açıkça kayıtlıdır. Green hazırlanana kadar değişmeden kalır. Monitoring baseline sağlar. Switch sonrası rollback için kısa süre tutulur.

Green Environment

Green yeni release digest'ini çalıştırır. Ayrı project name ve network kullanır. Production config'in uyumlu kopyasını alır. Health ve smoke test tamamlanır. Başarılı olursa traffic hedefi olur.

Aynı Image Artifact

Green CI tarafından üretilmiş release image'ını kullanır. Deployment host'ta rebuild yapılmaz. Staging'de test edilen digest tercih edilir. Artifact provenance korunur. Rollback blue digest ile mümkündür.

Ayrı Project Name

Blue ve green resource isimleri çakışmamalıdır. Compose project name bu ayrımı sağlar. Network ve volume isimleri farklılaşır. Shared external database bilinçli olarak ortak olabilir. Cleanup sadece eski project'i hedefler.

Ayrı Network

Her stack kendi internal network'üne sahip olabilir. Reverse proxy ikisine de bağlanır. Blue service green service'i yanlışlıkla görmez. Database external network üzerinden ortak bağlanabilir. Security rule aynı kalır.

Smoke Test

Green external route üzerinden test edilir. Critical endpoint ve write behavior doğrulanır. Synthetic account kullanılır. Test failure traffic switch'i engeller. Loglar release metadata ile ilişkilendirilir.

Reverse Proxy Traffic Switch

Proxy upstream green'e çevrilir. Configuration reload mümkün olduğunca connection drop yaratmamalıdır. Metric yeni release'i göstermeye başlar. Error rate yükselirse geri dönüş yapılır. Switch event timestamp kaydedilir.

Eski Environment'ı Kapatmak

Stability window sonunda blue stack kapatılır. Container ve network kaldırılır. Rollback image registry'de tutulur. Gereksiz volume silinmeden önce veri ihtiyacı kontrol edilir. Capacity tekrar normal seviyeye döner.

Docker Compose'dan Kubernetes'e Ne Zaman Geçilmeli?

Kubernetes'e geçiş container sayısından çok operasyon ihtiyaçlarıyla ilgilidir. Birden fazla host, self healing ve high availability ihtiyacı güçlü nedenlerdir. Horizontal scaling ve kontrollü rolling update beklentisi arttığında orchestrator değer kazanır. Çok sayıda microservice discovery ve configuration yönetimini zorlaştırabilir. Buna karşılık küçük tek host uygulamasında Kubernetes gereksiz operasyon yükü olabilir.

Birden Fazla Host

Compose tek host merkezlidir. Birden fazla host placement manual hale gelir. Kubernetes scheduler workload'ı cluster node'larına dağıtabilir. Node failure yeniden scheduling tetikleyebilir. Network ve storage modeli cluster seviyesinde çözülür.

Horizontal Scaling

Replica sayısı workload'a göre artabilir. Load balancing servis seviyesinde yapılır. Autoscaling metric'e bağlanabilir. Stateful service scaling ayrı problem olarak kalır. Capacity planning yine gereklidir.

Self-Healing

Desired state controller failed pod'u yeniden oluşturabilir. Node failure workload başka node'a taşınabilir. Health probes routing kararına bağlanabilir. Application data external tutulmalıdır. Self healing root cause monitoring'in yerine geçmez.

Rolling Update

Yeni version replica'lara kademeli uygulanabilir. Availability korunur. Health başarısızsa rollout durabilir. Deployment strategy config ile tanımlanır. Rollback platform tarafından desteklenebilir.

Service Discovery

Cluster service stable DNS adı sağlar. Pod IP değişse bile service endpoint korunur. Load balancing internal yapılabilir. Network policy erişim sınırı tanımlar. External ingress ayrı katmanda yönetilir.

High Availability

Multi node cluster tek host failure etkisini azaltabilir. Control plane ve workload availability ayrı tasarlanır. Database yine uygun HA çözümü gerektirir. Multi zone dağıtım düşünülebilir. Operasyon maliyeti Compose'dan daha yüksektir.

Çok Sayıda Mikroservis

Service sayısı arttıkça manual lifecycle zorlaşır. Config, secret ve deployment coordination büyür. Kubernetes standard API ile yönetim sağlar. Observability ve network policy daha önemli hale gelir. Monolith için zorunlu değildir.

Büyük Operasyon Ekibi

Kubernetes düzenli platform operasyonu gerektirir. Upgrade ve security patch sorumluluğu vardır. Managed service bu yükü azaltabilir. Team gerekli bilgiye sahip olmalıdır. Platform engineering süreçleri developer experience'i desteklemelidir.

Docker Compose, Swarm ve Kubernetes Karşılaştırması

Bu üç yaklaşım farklı operasyon ölçeklerine hitap eder. Docker Compose tek host development ve basit deployment için en sade modeldir. Docker Swarm Docker Engine cluster özellikleri sunan daha basit orchestrator yaklaşımıdır. Kubernetes daha geniş ekosistem ve advanced orchestration özellikleri sunar. Seçim projenin gerçek ölçek, availability ve ekip yetkinliği ihtiyacına göre yapılmalıdır.

Docker Compose

Compose service graph'ı tek host üzerinde yönetir. Development için oldukça güçlüdür. Production küçük uygulamalarda kullanılabilir. Multi host scheduler sağlamaz. Öğrenme yükü diğer seçeneklere göre düşüktür.

Docker Swarm

Swarm Docker Engine üzerinde cluster service modeli sunar. Multi node scheduling sağlayabilir. Compose benzeri service definition yaklaşımına yakındır. Ekosistem Kubernetes kadar geniş değildir. Existing Docker team için daha kolay geçiş olabilir.

Kubernetes

Kubernetes geniş orchestration yetenekleri sunar. Scheduling, rollout ve self healing built in resource modelleriyle yönetilir. Platform öğrenme ve operasyon yükü yüksektir. Managed cluster bu yükün bir bölümünü azaltır. Büyük distributed workload'larda güçlü çözümdür.

Öğrenme Eğrisi

Compose temel container bilgisiyle hızlı öğrenilir. Swarm ek cluster kavramları getirir. Kubernetes resource ve controller modeli daha kapsamlıdır. Team training planı gerekir. Araç ihtiyaca göre seçilmezse öğrenme maliyeti boşa gider.

Tek Host vs Multi-Host

Compose ağırlıklı olarak tek host için uygundur. Swarm ve Kubernetes multi host scheduling sağlar. Host failure recovery buna bağlıdır. Network ve storage cluster düzeyinde çözülür. High availability multi host tasarım gerektirir.

Scaling

Compose manual replica çalıştırabilir ancak cluster autoscaling sağlamaz. Swarm service replica yönetebilir. Kubernetes autoscaling ve advanced scheduling sunar. Application stateless olmalıdır. Database scaling ayrı mimari gerektirir.

Self-Healing

Compose restart policy process exit sonrası yardımcı olur. Swarm desired replica state'i korur. Kubernetes controller failed workload'ı yeniden oluşturur. Health signal davranışı platforma göre değişir. Root cause monitoring yine gereklidir.

Deployment Karmaşıklığı

Compose deployment dosyası sade olabilir. Swarm cluster ek operasyon getirir. Kubernetes manifest, controller ve cluster lifecycle yönetimi ister. Managed platform bazı görevleri azaltır. Basit workload için daha fazla abstraction her zaman avantaj değildir.

Hangi Projede Hangisi?

Local development için Compose doğal seçimdir. Tek host küçük production da Compose ile yönetilebilir. Basit multi host isteyen ekip Swarm değerlendirebilir. Büyük scale ve advanced orchestration Kubernetes'e işaret edebilir. Karar operasyon ekibinin sürdürebileceği çözüme dayanmalıdır.

Docker ile İzole Geliştirme Ortamının Performansı Nasıl Artırılır?

Development performansı image küçültmekten daha geniş bir konudur. Build cache, BuildKit ve doğru file sync yaklaşımı inner loop süresini azaltır. Gereksiz servisler profiles ile kapatılabilir. Bind mount kapsamı daraltılır ve native dependency klasörleri container içinde tutulur. Developer deneyimi build, reload ve test başlangıç süreleriyle ölçülmelidir.

Build Cache

Dependency layer source değişikliklerinden ayrılmalıdır. Lock file önce kopyalanır. Build cache invalidation azaltılır. CI remote cache kullanılabilir. Cache stale behavior gerektiğinde temiz build ile doğrulanır.

BuildKit

BuildKit parallel stage ve advanced cache özellikleri sunar. Cache mount package download süresini azaltabilir. Secret handling build'i daha güvenli yapar. Remote cache CI hızını artırır. Builder resource kullanımı izlenmelidir.

Compose Watch

Watch yalnız değişen source dosyalarını sync edebilir. Dependency change rebuild tetikler. Büyük bind mount I/O'su azalabilir. Ignore native dependency klasörlerini korur. Docker'ın güncel Watch modeli bu senaryoyu doğrudan destekler. :contentReference[oaicite:53]{index=53}

Gereksiz Bind Mount'ları Azaltmak

Tüm repository root'unu mount etmek gerekmeyebilir. Sadece source klasörü paylaşılabilir. Build output container içinde kalabilir. Read only mount bazı path'lerde yeterlidir. Host platform performance'i iyileşebilir.

Image Boyutunu Küçültmek

Küçük development image pull ve rebuild süresini azaltabilir. Ancak gerekli debug tool'ları çıkarmak verimliliği düşürmemelidir. Multi stage production küçültme için daha önemlidir. Base image update düzenli yapılmalıdır. Layer count tek başına performans metriği değildir.

Yalnızca Gerekli Servisleri Profiles ile Açmak

Mail viewer ve monitoring default çalışmayabilir. Developer profile ile açar. CPU ve memory kullanımı azalır. Startup süresi kısalır. Core dependency listesi açık tutulmalıdır.

Docker Desktop CPU/RAM Ayarları

Desktop VM'e ayrılan resource stack ihtiyacına uygun olmalıdır. Çok az memory OOM yaratır. Gereksiz yüksek allocation diğer uygulamaları etkiler. Team minimum öneri paylaşabilir. Developer cihaz özelliklerine göre esneklik bırakılmalıdır.

Database Seed Optimizasyonu

Binlerce gereksiz record startup'ı yavaşlatabilir. Minimal meaningful seed kullanılmalıdır. Bulk insert işlemleri optimize edilebilir. Heavy demo dataset optional command olabilir. Reset süresi developer metric'i olarak izlenebilir.

Docker Development Ortamı Nasıl Debug Edilir?

Debug sürecinde önce hangi katmanda sorun olduğunu belirlemek gerekir. docker compose ps service state'i gösterir. Logs application error'larını, inspect configuration ve health bilgilerini ortaya çıkarır. Network ve volume mapping ayrı kontrol edilmelidir. Environment variable değerleri secret'ları loglamadan doğrulanmalıdır.

docker compose ps

Bu komut project service container durumlarını gösterir. Running, exited veya port mapping görülebilir. Health status varsa listelenebilir. Yanlış project directory çalıştırılmamalıdır. İlk troubleshooting adımı olarak kullanışlıdır.

docker compose logs

Service stdout ve stderr output'u görüntülenir. Belirli service filtrelenebilir. Follow mode live debug sağlar. Secret loglarda görünmemelidir. Crash loop timestamp üzerinden anlaşılabilir.

docker compose exec

Running container içinde command çalıştırmayı sağlar. Environment veya DNS test edilebilir. Production'da manual change yapılmamalıdır. Non root user context korunur. Shell image'da yoksa application specific command kullanılabilir.

docker inspect

Container runtime configuration ayrıntılarını gösterir. Network, mount ve health state incelenebilir. Output secret metadata içerebileceği için paylaşım dikkatli yapılmalıdır. Image digest kontrol edilebilir. Script JSON filter kullanabilir.

Network Kontrolü

Service isimleri DNS ile çözülüyor mu test edilir. Container doğru network'e bağlı mı bakılır. Host port ve internal port karıştırılmamalıdır. Firewall etkisi kontrol edilir. Hardcoded IP kaldırılır.

Volume Kontrolü

Mount source ve target inspect ile görülebilir. Bind mount image dosyalarını ezmiş olabilir. Permission UID mismatch incelenir. Named volume data beklenen path'te olmalıdır. Cleanup öncesi data önemi doğrulanır.

Environment Kontrolü

Final Compose config variable interpolation gösterebilir. Container env komutu non secret değerler için kontrol sağlayabilir. Secret value terminal history'ye yazılmamalıdır. Precedence kaynakları incelenir. Typo application startup failure yaratabilir.

Health Status Kontrolü

Inspect health log son probe output'unu gösterebilir. Timeout ve retry değerleri incelenir. Probe command container içinde manual test edilebilir. Dependency readiness sorunu ayrı değerlendirilir. Unhealthy state restart policy ile karıştırılmamalıdır.

Container İçinde Remote Debugging

Remote debugging IDE'nin host üzerinde çalışırken application debugger'ın container içinde çalışmasına izin verir. Debug port yalnız development ortamında publish edilmelidir. Source path mapping container ve host dosya yollarını eşleştirir. Runtime profiler veya debugger production image'a taşınmamalıdır. Team ortak IDE launch config ile setup süresini azaltabilir.

Node.js Debugger

Node inspector development command ile açılabilir. Debug port host'a loopback üzerinden publish edilir. IDE process'e attach olur. Source map doğru olmalıdır. Production NODE_OPTIONS debug flag içermemelidir.

Python debugpy

debugpy development dependency olarak kurulabilir. Application debug server ile başlayabilir. IDE container portuna attach olur. Source path mapping yapılır. Production requirements debugpy taşımayabilir.

Go Delve

Go Delve development stage'de debug server olarak kullanılabilir. Binary debug symbol ile build edilebilir. Port yalnız local erişime açılır. Production binary optimize edilmiş ayrı stage'den gelir. Debug build production performansını temsil etmez.

Java Debug Port

JVM remote debugging development profile'da etkinleştirilebilir. JDWP portu host'a açılır. IDE attach configuration repository'de paylaşılabilir. Debug security options public network'e uygun değildir. Production JVM debug portu kapalı tutulmalıdır.

IDE Attach

IDE container içindeki process'e network üzerinden bağlanır. Local source ile container source path eşleştirilir. Breakpoint doğru file version'a denk gelmelidir. Compose restart sonrası debugger yeniden attach gerekebilir. Devcontainer bu deneyimi sadeleştirebilir.

Debug Portlarını Production'da Açmamak

Debugger application memory ve execution üzerinde geniş kontrol sağlar. Production network'te açılması ciddi güvenlik riskidir. Firewall'a güvenmek yerine service port tanımı kaldırılmalıdır. Debug package final image'dan çıkarılabilir. Incident investigation observability üzerinden yapılmalıdır.

Development Environment'ın Tek Komutla Kurulması

İyi development ortamı uzun README adımlarına bağımlı kalmamalıdır. Tek komut veya küçük bootstrap wrapper gerekli servisleri başlatmalı, migration çalıştırmalı ve health durumunu doğrulamalıdır. Seed data developer'a çalışabilir başlangıç sağlar. Hata mesajları hangi prerequisite'in eksik olduğunu göstermelidir. Onboarding hedefi clone sonrası birkaç açık adımla uygulamayı çalıştırmaktır.

docker compose up

docker compose up core stack'i oluşturup başlatabilir. Build gerekirse çalışır. Healthcheck service durumunu görünür kılar. Developer startup loglarını aynı terminalde görebilir. Watch mode development feedback'i hızlandırabilir.

Makefile

Makefile uzun Docker komutlarını kısa target'lara dönüştürebilir. make dev ve make test ortak interface sunar. Windows compatibility gerekiyorsa dikkat edilmelidir. Command içeriği source control'de kalır. Secret value Makefile içine yazılmamalıdır.

Task Runner

Cross platform task runner Compose komutlarını orkestre edebilir. Setup, test ve reset görevleri tanımlanır. Exit code CI ile uyumlu olmalıdır. Dependency check yapılabilir. Developer tek tool command öğrenir.

Bootstrap Script

Script environment örnek dosyasını kontrol edebilir. Required Docker version doğrulanabilir. Volume ve database setup yapabilir. Idempotent olmalıdır. Production credential'a erişmemelidir.

Database Migration

Startup flow migration komutunu çalıştırabilir. Fresh volume schema oluşturur. Failure startup'ı durdurur. Migration logu terminalde görünür. Production migration path ayrı tutulabilir.

Seed

Seed developer'a login ve sample data sağlar. Tek komutla yeniden uygulanabilir. Production data kullanılmaz. Seed hızlı olmalıdır. Optional heavy demo data ayrı target olabilir.

Healthcheck

Bootstrap service health durumunu bekleyebilir. Timeout sonrası anlaşılır failure üretir. Database ready olana kadar API race önlenir. Health probe tek başına resilience değildir. Developer hangi service'in başarısız olduğunu görür.

README'yi Minimuma İndirmek

README onlarca manual kurulum adımı içermemelidir. Prerequisite ve başlangıç komutu yeterli olmalıdır. Troubleshooting linkleri eklenebilir. Environment variable sözleşmesi example file'da tutulur. Dokümantasyon gerçek automation ile düzenli test edilmelidir.

Yeni Yazılımcı Onboarding Süreci Nasıl Otomatikleştirilir?

Onboarding otomasyonu yalnız Docker kurmakla tamamlanmaz. Repository clone sonrası environment dosyası, development container ve Compose stack birlikte çalışmalıdır. Database seed yeni geliştiriciye anlamlı örnek data sağlar. IDE configuration repository'de paylaşılabilir. İlk testin başarıyla çalışması ortamın doğru kurulduğuna dair güçlü doğrulamadır.

Repository Clone

Developer repository'yi kendi hesabıyla clone eder. SSH veya HTTPS credential güvenli yapılandırılır. Git hooks gerekiyorsa bootstrap kurar. Submodule varsa otomatik alınabilir. Clone sonrası yalnız repository talimatları yeterli olmalıdır.

.env.example

Gerekli config key'ler bu dosyada görünür. Gerçek secret bulunmaz. Developer local copy oluşturur. Default değerler mümkün olduğunca çalışabilir olur. Yeni variable eklenince example güncellenir.

Dev Container

IDE development container'ı açabilir. Runtime ve toolchain hazır gelir. Extension'lar otomatik kurulur. Non root user kullanılır. Developer host'a daha az tool kurar.

docker compose up

Dependency service'ler tek komutla başlar. Database ve cache health check alır. Application development target kullanır. Watch source değişikliklerini aktarabilir. Hata logu terminalde görünür.

Database Seed

Local demo kullanıcıları oluşturulur. Test data synthetic olur. Feature senaryoları örneklenir. Seed hızlı ve deterministic tasarlanır. Reset komutu seed'i yeniden oluşturabilir.

IDE Configuration

Formatter ve debugger launch configuration source control'de bulunabilir. Developer kişisel ayarını değiştirebilir. Project minimum standardı korunur. Path mapping container ile uyumludur. Debug port yalnız local profile'da açılır.

İlk Testi Çalıştırmak

Onboarding sonunda unit veya smoke test çalıştırılır. Bu test runtime ve dependency bağlantısını doğrular. Failure kurulum hatasını erken gösterir. Komut README'de yer alır. Başarı onboarding completion metric olabilir.

Onboarding Süresini Ölçmek

Clone to running süresi gerçek metric olarak tutulabilir. Yeni ekip üyelerinden feedback alınır. En çok zaman kaybedilen step otomatikleştirilir. Setup failure oranı izlenebilir. Hedef sürekli iyileştirmedir.

Docker Geliştirme Ortamının Kalitesi Nasıl Ölçülür?

Development environment kalitesi hissiyatın yanında ölçülebilir metric'lerle değerlendirilebilir. İlk setup süresi ve clean clone to running zamanı onboarding performansını gösterir. Build ve hot reload süresi inner loop hızını belirler. Environment kaynaklı bug sayısı parity kalitesi hakkında fikir verir. Developer satisfaction ise teknik metric'lerin kaçırdığı günlük sürtünmeleri ortaya çıkarabilir.

First-Time Setup Süresi

Yeni cihazda environment kurmak ne kadar sürüyor ölçülür. Manual install step'leri kayıt altına alınır. Büyük image pull ayrı görülebilir. Setup failure nedenleri kategorize edilir. Automation en yüksek maliyetli adımı hedefler.

Clean Clone-to-Running Süresi

Repository clone anından uygulamanın healthy olmasına kadar süre ölçülür. Cache olmayan senaryo gerçek onboarding'i temsil eder. Warm cache sonucu ayrıca tutulabilir. Database seed bu süreye dahil edilir. Improvement regression CI ile test edilebilir.

Build Süresi

Cold ve warm build ayrı ölçülmelidir. Cache hit oranı izlenebilir. Multi architecture build daha uzun olabilir. Dependency step bottleneck bulunur. BuildKit optimization gerçek data ile yapılır.

Hot Reload Gecikmesi

Dosya save ile browser veya API değişikliğinin görünmesi arasındaki süre ölçülür. Bind mount ve Watch karşılaştırılabilir. Desktop platformlar ayrı değerlendirilebilir. Birkaç saniyelik gecikme developer flow'u etkileyebilir. File watcher configuration optimize edilir.

Test Başlatma Süresi

Container startup integration test feedback'ini geciktirebilir. Image pre pull ve cache süreyi azaltır. Testcontainers lifecycle optimize edilebilir. Shared state pahasına hız kazanılmamalıdır. Fast unit test katmanı korunmalıdır.

Environment-Related Bug Sayısı

Local çalışıp CI'da bozulan incident'lar kategorize edilir. Version drift nedeni tespit edilir. Missing env veya port conflict sayılabilir. Metric düşüyorsa environment standardizasyonu işe yarıyor olabilir. Application bug ile karıştırılmamalıdır.

Onboarding Süresi

Developer'ın ilk üretken değişikliğine kadar süre izlenebilir. Docker setup bunun yalnız bir parçasıdır. Domain dokümantasyonu da önemlidir. Tooling kaynaklı bekleme ayrı ölçülür. Feedback ile süreç geliştirilir.

Developer Satisfaction

Anket veya kısa retrospective environment deneyimini ölçebilir. Slow reload veya random reset sorunları görünür olur. Metric bireysel performansla ilişkilendirilmemelidir. Platform team backlog'una girdi sağlar. Teknik metric'lerle birlikte değerlendirilir.

Uçtan Uca Örnek: Full-Stack Docker Development Ortamı

Örnek bir full stack projede frontend, backend, PostgreSQL ve Redis ayrı servisler olarak tanımlanabilir. Multi stage Dockerfile development ve production target'larını ayırır. Compose network servislerin isimle haberleşmesini sağlar. Named volume database data'yı korurken Compose Watch source değişikliklerini uygulama container'larına aktarabilir. Tek komutlu başlangıç developer'ın tool ayrıntılarıyla uğraşmadan uygulamaya odaklanmasını sağlar.

Proje Yapısı

Repository frontend ve backend klasörlerine ayrılabilir. Root compose file tüm service graph'ı tutar. Dockerfile service klasörlerinde bulunur. Environment example root'ta tutulabilir. Documentation tek startup command verir.

Multi-Stage Dockerfile

Backend base, development, test ve production stage kullanabilir. Frontend development ve build stage'e sahip olabilir. Compiler final runtime'a taşınmaz. Same runtime version korunur. CI production target build eder.

compose.yaml

Compose application, database ve cache service'lerini tanımlar. Development target seçilir. Network ve volume isimleri logical tutulur. Healthcheck dependency startup'ını destekler. Secret values dosyaya yazılmaz.

Development Target

Development image debugger ve hot reload içerir. Source code sync edilir. Dependency image içinde kalır. Container non root user ile çalışır. Production target ayrı oluşturulur.

PostgreSQL

Database pinned version kullanır. Named volume data'yı saklar. Healthcheck readiness'i kontrol eder. Host port optional profile olabilir. Seed synthetic data yükler.

Redis

Redis backend ve worker network'ünde çalışır. Host port publish edilmez. Healthcheck ping kullanır. Development persistence ihtiyaca göre seçilir. Production memory policy ayrıdır.

Network

Frontend proxy network'üne bağlanabilir. Backend private network'te database'e ulaşır. Database public network'e çıkmaz. Service discovery isimle yapılır. Hardcoded IP yoktur.

Named Volumes

PostgreSQL data named volume kullanır. node_modules gerekiyorsa ayrı development volume olabilir. Volume project scope'unda isimlendirilir. Reset command explicit volume siler. Production backup farklı süreçtir.

Secrets

Development secret file Git dışında tutulur. Compose service yalnız ihtiyacı olan secret'ı alır. Database password backend'e verilir. Frontend secret'ı görmez. Production secret manager farklı source kullanır.

Healthchecks

Database ready check bulunur. API kendi health endpoint'ini sunar. depends_on service healthy local startup race'ini azaltır. Frontend proxy API readiness'i bekleyebilir. Probe timeout device performance'e göre ayarlanır.

Compose Watch

Frontend source sync action kullanır. package manifest rebuild tetikler. Backend source sync restart veya framework reload kullanabilir. node_modules ignore edilir. Developer docker compose up --watch ile başlatır.

Seed Data

Migration sonrası seed command çalışır. Demo user oluşturulur. Test payment data synthetic tutulur. Seed deterministic olmalıdır. Reset aynı state'i yeniden üretir.

Debugger

Backend debugger development profile'da çalışır. Port loopback'e publish edilir. IDE attach config repository'de bulunur. Production image debugger içermez. Debug secret output'ta görünmez.

Tek Komutla Başlatma

make dev veya benzeri command Compose Watch başlatabilir. Migration ve seed gerekirse ayrı bootstrap step çalışır. Health status kontrol edilir. Başarısız service açıkça raporlanır. Developer uzun setup listesi takip etmez.

Uçtan Uca Örnek: Development'tan Production'a

Sağlıklı Docker yaşam döngüsü local development'tan production'a tek artifact zinciri üzerinden ilerler. Developer development target ile hızlı feedback alır. CI integration testlerden sonra production image'ını bir kez build eder. Scan ve registry push sonrasında immutable digest staging'de doğrulanır. Production aynı digest'i promote eder ve health failure durumunda previous artifact'a rollback yapılır.

Lokal Development

Developer Compose stack'i başlatır. Source Watch ile sync edilir. Database local named volume kullanır. Dummy secret development scope'unda kalır. Test komutları container içinde çalışabilir.

Integration Tests

CI fresh test stack oluşturur. Database migration çalışır. Application gerçek dependency'lerle test edilir. Environment job sonunda silinir. Test failure release build'ini durdurur.

CI Image Build

Production target bir kez build edilir. BuildKit cache kullanabilir. Build secret temporary mount üzerinden verilir. Commit metadata image'a label olabilir. Artifact immutable olarak ele alınır.

Vulnerability Scan

Final runtime image taranır. Critical finding release'i engelleyebilir. SBOM aynı artifact'tan üretilir. Exception süresi sınırlıdır. Result digest ile kaydedilir.

Registry Push

Image registry'ye push edilir. Version tag ve commit tag eklenebilir. Digest alınır. Write credential yalnız CI'da bulunur. Production deployment read only credential kullanır.

Immutable Image Digest

Digest deployment source of truth olur. Staging reference aynı digest'i kullanır. Tag overwrite release'i etkilemez. Audit hangi artifact'ın çalıştığını gösterir. Previous digest rollback için tutulur.

Staging Deployment

Staging aynı image'ı ayrı config ile başlatır. Migration uygulanır. Health ve smoke tests çalışır. External integration test endpoint kullanır. Approval production promotion'ı açar.

Smoke Tests

Critical user flow kısa testle doğrulanır. API health tek başına yeterli olmayabilir. Database write ve read test edilebilir. Synthetic user kullanılır. Failure deploy'u durdurur.

Production Promotion

CI build işlemini tekrarlamaz. Approved digest production'a atanır. Secret production manager'dan gelir. Deployment event audit edilir. Health verification hemen başlar.

Health Verification

Container healthy state'i beklenir. External monitor endpoint'i kontrol eder. Error rate ve latency izlenir. Business metric değişikliği değerlendirilir. Failure rollback trigger olabilir.

Rollback

Previous digest hızlıca yeniden deploy edilir. Previous compatible config restore edilir. Database schema uyumu kontrol edilir. Health ve smoke test tekrar çalışır. Incident analizi sonradan yapılır.

Docker ile Geliştirmede Sık Yapılan Hatalar

Docker development sorunlarının büyük bölümü birkaç tekrar eden pattern'den çıkar. Container içinde localhost kullanmak veya host dependency klasörünü mount etmek bağlantı ve native binary hataları oluşturur. Root container ve committed environment dosyaları güvenlik riskini artırır. depends_on readiness mekanizması sanıldığında startup race devam eder. Build cache'e uygun olmayan Dockerfile ise her değişiklikte gereksiz uzun rebuild üretir.

Container İçinde localhost Kullanmak

localhost aynı container'ı gösterir. Database ayrı service ise service name kullanılmalıdır. Host'a erişim özel gateway gerektirebilir. Connection string environment'a göre değişir. Network troubleshooting ilk olarak endpoint'i kontrol etmelidir.

Her Proje Dosyasını Bind Mount Etmek

node_modules ve build cache gereksiz share olabilir. Desktop filesystem yavaşlayabilir. Image içindeki dependency ezilebilir. Yalnız source path mount edilmelidir. Compose Watch alternatif olabilir.

Host node_modules'u Container'a Taşımak

Host OS ve container OS farklı olabilir. Native binary çalışmaz. Apple Silicon architecture farkı ek sorun çıkarabilir. Container kendi dependency install'ını kullanmalıdır. node_modules volume veya Watch ignore ile korunabilir.

Development Container'ı Root Çalıştırmak

Root file ownership sorunlarını gizleyebilir. Host mount'ta root owned dosyalar oluşur. Tooling gereksiz privilege kazanır. Non root user oluşturulmalıdır. UID mapping gerekiyorsa uygulanır.

.env Dosyasını Git'e Eklemek

Environment dosyası secret içerebilir. Git history kalıcı kayıt oluşturur. Example file yalnız key isimlerini göstermelidir. Leak credential rotate edilmelidir. Secret manager kullanımı tercih edilir.

depends_on ile Readiness'i Karıştırmak

Container started database ready demek değildir. Healthcheck service healthy kullanılabilir. Application retry yine gereklidir. Startup order network failure'ını çözmez. Docker belgeleri bu ayrımı açıkça belirtir. :contentReference[oaicite:54]{index=54}

.dockerignore Kullanmamak

Build context gereksiz büyür. Secret file image build'e sızabilir. node_modules platform hatası yaratabilir. Cache invalidation artar. Ignore policy repository'nin temel parçası olmalıdır.

Dependency Sürümlerini Sabitlememek

Bugünkü build yarın farklı dependency çekebilir. Team makineleri ayrışır. Lock file kullanılmalıdır. Base image version da bilinçli seçilmelidir. Upgrade controlled PR üzerinden yapılmalıdır.

Image Build Cache'i Bozan Dockerfile Yazmak

Source code dependency install'dan önce kopyalanırsa her değişiklik cache'i bozar. Lock file ayrı layer'a alınmalıdır. Build context küçültülmelidir. Cache mount kullanılabilir. Warm build süresi metric olarak izlenmelidir.

Production Database'i Development'ta Kullanmak

Yanlış query gerçek data'yı bozabilir. Credential developer laptop'a yayılır. PII local ortamda kopyalanır. Development kendi database'ini kullanmalıdır. Synthetic seed yeterli test data sağlar.

Docker Deployment'ta Sık Yapılan Hatalar

Production Docker hataları çoğunlukla development kolaylıklarının doğrudan canlı ortama taşınmasından kaynaklanır. Source bind mount, latest tag ve root runtime reproducibility ile güvenliği zayıflatır. Resource limit ve log rotation eksikliği host stability problemlerine yol açabilir. Healthcheck ve rollback planı olmadan release sonucu güvenilir biçimde değerlendirilemez. Stateful data backup edilmeden container çalıştırılması en riskli operational eksiklerden biridir.

Development Compose Dosyasını Production'a Kopyalamak

Development file source mount ve debug port içerir. Production secret handling farklıdır. Resource ve logging ayarları eksik olabilir. Dedicated override kullanılmalıdır. Final config deploy öncesi kontrol edilmelidir.

Source Code Bind Mount Kullanmak

Host file değişikliği çalışan uygulamayı anında değiştirebilir. Artifact identity kaybolur. Rollback zorlaşır. Image code source of truth olmalıdır. Config ayrı mount olabilir.

latest Image Kullanmak

Latest mutable referanstır. Aynı deploy command farklı artifact çekebilir. Version tag daha iyi ama digest daha güçlüdür. Production exact digest kullanmalıdır. Rollback previous digest'i saklamalıdır.

Root Container Çalıştırmak

Application gereksiz host impact riski taşır. File permission çok geniş olabilir. Dockerfile USER ile non root runtime tanımlanmalıdır. Capability minimum tutulmalıdır. Privileged mode normal çözüm değildir.

Resource Limit Koymamak

Memory leak tüm host'u etkileyebilir. CPU runaway diğer service'leri yavaşlatır. Limits capacity planına göre belirlenmelidir. OOM monitoring gerekir. Host headroom korunmalıdır.

Log Rotation Yapmamak

json-file logları büyüyebilir. Disk dolması tüm Docker host'u etkiler. max-size ve max-file ayarlanmalıdır. Merkezi logging retention ayrı tutulur. Docker resmi belgeleri rotation seçeneklerini destekler. :contentReference[oaicite:55]{index=55}

Healthcheck Olmadan Deployment Yapmak

Running state service readiness'i göstermez. Deployment başarı sinyali zayıf kalır. Health endpoint eklenmelidir. Smoke test external behavior'ı doğrular. Failure rollback'e bağlanabilir.

Secret'ları Environment Dosyasında Açık Tutmak

Production env file backup veya shell erişiminde sızabilir. Secret manager daha kontrollü model sağlar. Compose secrets file based access verebilir. Service scope minimum tutulmalıdır. Secret rotation düzenli yapılmalıdır.

Backup Olmadan Stateful Container Çalıştırmak

Volume host failure'a karşı backup değildir. Database native backup kurulmalıdır. Offsite copy tutulur. Restore test edilmelidir. RPO ve RTO business ihtiyacına göre belirlenir.

Docker Socket'i Kontrolsüz Mount Etmek

Socket Engine üzerinde geniş yetki verir. Compromised container host'u etkileyebilir. Application service socket'e ihtiyaç duymaz. CI runner isolation sağlanmalıdır. Proxy veya rootless alternatif değerlendirilebilir.

Rollback Planı Olmaması

Incident anında hangi image'a dönüleceği bilinmez. Previous digest saklanmalıdır. Database compatibility düşünülmelidir. Rollback command önceden test edilmelidir. Health verification dönüş sonrasında yapılır.

Production Öncesi Docker Kontrol Listesi

Production deployment öncesi yalnız container'ın çalıştığını görmek yeterli değildir. Image artifact, security scan, runtime user ve network exposure birlikte kontrol edilmelidir. Health, logging, backup ve rollback operasyonel güvenliğin parçasıdır. Secret yönetimi source code'dan ayrılmalıdır. Bu kontrol listesi deployment'ın repeatable ve geri alınabilir olmasını hedefler.

Image Tek Bir CI Build'inden mi Geliyor?

Production image developer laptop'ta build edilmemelidir. CI source commit'ten tek artifact üretmelidir. Staging aynı artifact'ı test etmelidir. Production yeniden build yapmamalıdır. Build log audit için saklanmalıdır.

Image Digest Sabit mi?

Deployment exact digest kullanmalıdır. Tag yalnız okunabilir version bilgisi olabilir. Digest registry push sonrası kaydedilir. Promotion aynı değeri taşır. Rollback previous digest kullanır.

Vulnerability Scan Yapıldı mı?

Final runtime image taranmalıdır. Critical finding policy ile değerlendirilir. Base image patch seviyesi kontrol edilir. Exception gerekçeli ve süreli olmalıdır. Scan sonucu digest'e bağlanır.

Secret Scan Yapıldı mı?

Repository ve image layer secret açısından taranabilir. Build context kontrol edilir. Leak varsa credential rotate edilir. BuildKit secret mount kullanılır. Production env file repository'de bulunmaz.

Production Container Non-Root mu?

Dockerfile USER kontrol edilmelidir. Application non privileged port kullanabilir. Writable path listesi sınırlıdır. File ownership test edilir. Root ihtiyacı varsa gerekçesi belgelenir.

Source Bind Mount Kaldırıldı mı?

Production code image içinden gelmelidir. Development source mount override dışarıda kalır. Config read only mount olabilir. Final Compose config bunu doğrular. Host path drift önlenir.

Healthcheck Var mı?

Application health endpoint tanımlanmalıdır. Probe timeout ve retries makul olmalıdır. Database readiness ayrı kontrol edilir. External smoke test ek güven sağlar. Monitoring health state'i takip eder.

Restart Policy Tanımlı mı?

Unexpected process exit sonrası davranış bilinmelidir. Crash loop alert üretmelidir. Manual stop semantics anlaşılmalıdır. Health unhealthy state farklıdır. Policy service türüne göre seçilir.

Resource Limit Var mı?

CPU ve memory sınırları belirlenmelidir. Host capacity ölçülür. OOM event monitoring'e alınır. Critical service headroom alır. Limit load test ile doğrulanır.

Network'ler İzole mi?

Frontend database network'üne gereksiz bağlanmamalıdır. Proxy gerekli network'lere bağlıdır. Cache public değildir. External egress ihtiyaç kadar açılır. Firewall Compose network'ünü tamamlar.

Database Public Port'a Kapalı mı?

Production database host public interface'te publish edilmemelidir. Backend private network kullanır. Admin access secure tunnel üzerinden yapılır. Firewall connection kaynağını sınırlar. Credential minimum privilege alır.

Secret'lar Güvenli mi?

Secret repository'de bulunmamalıdır. Service based access uygulanır. Secret manager audit ve rotation sağlar. Log masking açıktır. Development ve production credential ayrıdır.

Log Rotation Aktif mi?

Docker logging driver size limit taşımalıdır. max file değeri belirlenmelidir. Disk alert eklenir. Central logging gerekli retention'ı sağlar. Crash loop log storm izlenir.

Backup Var mı?

Stateful data düzenli yedeklenmelidir. Backup offsite tutulmalıdır. Encryption uygulanır. Failure alert gerekir. Retention policy tanımlanır.

Restore Test Edildi mi?

Backup yalnız file oluşmasıyla doğrulanmaz. Isolated ortamda restore yapılmalıdır. Application data'yı okuyabilmelidir. Restore süresi ölçülür. Runbook gerçek test sonucu güncellenir.

Rollback İçin Eski Image Digest'i Var mı?

Previous production digest metadata'da bulunmalıdır. Registry retention artifact'ı korur. Previous config version da bilinmelidir. Database schema old version ile uyumlu olmalıdır. Rollback command hazır olmalıdır.

Docker için En İyi Programlama Dili Hangisidir?

Docker belirli bir programlama diline bağlı değildir. Container'ın ihtiyacı Linux process veya desteklenen platformda çalışabilen uygulama artifact'ıdır. Python, JavaScript, Go, Java, .NET, PHP ve Rust gibi birçok ekosistem Docker ile rahat kullanılabilir. Dil seçimi team yetkinliği, workload ve runtime ihtiyacına göre yapılmalıdır. Container açısından asıl önemli konu küçük, güvenli ve iyi tanımlanmış runtime üretmektir.

Docker Bir Programlama Diline Bağlı mıdır?

Hayır, Docker application language'ından bağımsızdır. Dockerfile runtime environment'ı paketler. Compiled veya interpreted uygulama çalışabilir. Base image dil ekosistemine göre seçilir. Deployment modeli dil seçiminden ayrı düşünülebilir.

Python

Python web ve data workload'larında sık kullanılır. Virtual environment yerine container dependency isolation sağlayabilir. Production WSGI veya ASGI server tercih edilir. requirements lock edilmelidir. Multi stage build native dependency compile işlemini ayırabilir.

JavaScript ve TypeScript

Node.js container workflow'ları hızlı development sağlar. node_modules platforma özel olabilir. Compose Watch hot reload için uygundur. Production dependency alt kümesi final image'a alınabilir. Frontend statik build ayrıca oluşturulabilir.

Go

Go statik binary üretimi container için avantajlıdır. Build stage compiler kullanır. Final image çok küçük olabilir. Cross compilation multi platform build'i kolaylaştırır. CA certificate gibi runtime ihtiyaçları unutulmamalıdır.

Java

Java JDK build stage ve JRE runtime stage kullanabilir. Layer cache Maven veya Gradle dependency'lerinde önemlidir. JVM memory container limitini anlamalıdır. Health endpoint framework tarafından sunulabilir. Remote debug development'a özel tutulur.

C# / .NET

.NET SDK build stage'de kullanılabilir. Runtime image final stage'e alınır. Publish output artifact olur. Container memory ve GC ayarları workload'a göre test edilir. Non root runtime güncel base image davranışına göre yapılandırılır.

PHP

PHP application web server veya FPM container'ında çalışabilir. Composer dependency build stage'de kurulabilir. Web server ayrı container olabilir. Uploaded file object storage'a taşınabilir. Production config development'tan ayrılır.

Rust

Rust build stage compiler ve Cargo kullanır. Final binary minimal runtime'a taşınabilir. Native library dependency gerektiğinde runtime package eklenir. Build cache süreyi önemli ölçüde etkileyebilir. Multi platform cross compile değerlendirilebilir.

Uygulama Türüne Göre Dil Seçimi

API latency, developer availability ve library ekosistemi seçimde önemlidir. Docker kullanıyor olmak dili belirlemez. Existing team expertise çoğu zaman en büyük faktördür. Performance ihtiyacı benchmark ile ölçülmelidir. Operasyon özellikleri container design ile çözülür.

En İyi Programlama Dilinden Daha Önemli Olan Container Tasarımı

Root olmayan runtime önemlidir. Image dependency'leri sabit olmalıdır. Health, log ve signal behavior doğru tasarlanmalıdır. Application state container filesystem'ine bağımlı olmamalıdır. Build once promote everywhere dili ne olursa olsun değerlidir.

Yazılımcı Olmak İçin Ne Yapmalı? Docker ve DevOps Yol Haritası

Docker öğrenmek tek başına yazılımcı veya DevOps uzmanı olmak için yeterli değildir. Linux, networking, Git ve en az bir programlama dili temel oluşturur. Dockerfile ve Compose bu bilgilerin pratik birleşimidir. CI/CD ve container security production düşüncesini geliştirir. Cloud ve Kubernetes ise temel ihtiyaçlar oturduktan sonra öğrenildiğinde çok daha anlamlı hale gelir.

Linux Temelleri

Process, file permission ve signal kavramları öğrenilmelidir. Filesystem path ve user modeli Docker debugging'i kolaylaştırır. Shell temel komutları yeterlidir. System service behavior anlaşılmalıdır. Namespace kavramı Linux bilgisiyle daha kolay öğrenilir.

Networking

IP, port ve DNS temel konulardır. localhost ile service address farkı anlaşılmalıdır. HTTP ve TLS bilgisi gerekir. Firewall ve private network öğrenilmelidir. Container network bu temellerin üzerine gelir.

Git

Branch, commit ve Pull Request workflow öğrenilmelidir. Dockerfile değişiklikleri version control altında tutulur. CI Git event'leriyle çalışır. Release tag ve commit SHA artifact identity sağlar. Collaboration becerisi teknik yetkinliğin parçasıdır.

Bir Programlama Dili

Container yalnız application paketleme aracıdır. Önce gerçek uygulama geliştirme becerisi gerekir. Error handling ve test yazma öğrenilmelidir. Database ve API tasarımı önemlidir. Docker bu uygulamayı tekrar üretilebilir ortamda çalıştırır.

Docker

Image, container, volume ve network kavramları öğrenilmelidir. docker run ile temel lifecycle anlaşılır. Logs ve inspect debugging pratiği yapılmalıdır. Root ve permission modeli incelenmelidir. Küçük application containerize edilmelidir.

Dockerfile

FROM, COPY ve RUN ile başlanabilir. Layer cache öğrenilmelidir. Multi stage build uygulanmalıdır. Non root runtime eklenmelidir. Secret build'e nasıl verilmez konusu anlaşılmalıdır.

Docker Compose

API ve database birlikte tanımlanabilir. Service discovery öğrenilir. Volume persistence test edilir. Healthcheck eklenir. Profiles ve Watch daha sonra kullanılabilir.

CI/CD

Test ve build automation kurulmalıdır. Image registry'ye push edilir. Digest deployment'a aktarılır. Staging smoke test eklenir. Rollback workflow uygulanır.

Container Security

Non root ve minimal image temel konulardır. Secret handling öğrenilmelidir. Docker socket riski anlaşılmalıdır. Vulnerability scan uygulanır. Supply chain metadata incelenir.

Cloud

Compute, network ve object storage temelleri öğrenilebilir. Container registry managed service kullanılabilir. IAM least privilege önemlidir. Cost monitoring unutulmamalıdır. Managed platform operasyon yükünü azaltabilir.

Kubernetes

Compose ile service ilişkilerini anladıktan sonra Kubernetes daha kolay öğrenilir. Pod, Deployment ve Service temel resource'lardır. Config ve Secret ayrımı öğrenilir. Health probes uygulanır. Cluster operation ayrı beceri alanıdır.

Gerçek Bir Containerized Proje Geliştirmek

Frontend, API ve database içeren küçük proje kurulabilir. Docker Compose local development sağlar. CI image build edip registry'ye gönderir. Production test host'a deploy edilir. Logging, backup ve rollback gerçek şekilde uygulanır.

Open Source ve İşbirliği Docker Öğrenmeye Nasıl Katkı Sağlar?

Open source projeler gerçek Dockerfile ve Compose tasarımlarını görmenin güçlü yollarından biridir. Issue ve Pull Request tartışmaları neden belirli container kararlarının alındığını gösterir. Base image ve OCI standardı gibi altyapı bileşenlerinin çalışma prensipleri daha iyi anlaşılır. Kendi örnek Compose yapınızı paylaşmak documentation ve review becerisi kazandırır. Ekip içinde ortak container standardı oluşturmak ise öğrendiklerinizi kalıcı mühendislik pratiğine dönüştürür.

Docker'ın Açık Kaynak Ekosistemi

Container dünyası birçok açık kaynak bileşene dayanır. Runtime, image format ve tooling ayrı projeler halinde gelişir. Source code okumak implementation detail öğretir. Issue tartışmaları trade off'ları gösterir. Contribution documentation improvement ile başlayabilir.

Moby

Moby container build ve runtime bileşenlerinin açık kaynak ekosisteminde önemli projelerinden biridir. Docker teknolojilerinin bazı temel parçalarını anlamaya yardımcı olur. Source incelemek ileri seviye öğrenme sağlar. Issue takip etmek yeni davranışları gösterir. Başlangıç için doğrudan contribution şart değildir.

Containerd

containerd container lifecycle yönetiminde yaygın kullanılan runtime bileşenidir. Image transfer ve container execution alanında rol oynar. Kubernetes ve Docker ekosisteminde farklı entegrasyonlar bulunur. Runtime katmanlarını anlamak troubleshooting'i geliştirir. Production operator için temel kavramları bilmek faydalıdır.

OCI

OCI image ve runtime standardizasyonuna katkı sağlar. Container image'larının farklı tooling arasında taşınabilirliğini destekleyen specification'lar sunar. Docker image ecosystem bu standartlarla ilişkilidir. Standard okumak format ve runtime separation anlayışını geliştirir. Vendor bağımlılığına daha bilinçli bakmayı sağlar.

Açık Kaynak Base Image'lar

Base image Dockerfile'ları incelenebilir. Package seçimi ve security update yaklaşımı görülebilir. Random image yerine iyi yönetilen base seçmek öğrenilir. Digest ve release note kontrolü yapılabilir. Kendi base image'ınızı gereksiz yere üretmeden önce mevcut seçenekler değerlendirilmelidir.

GitHub Issue

Issue gerçek kullanıcı problemlerini gösterir. Dockerfile veya Compose bug'ları analiz edilebilir. Reproduction environment oluşturmak pratik kazandırır. Log paylaşımında secret maskelenmelidir. Çözüm tartışmaları troubleshooting yaklaşımını geliştirir.

Pull Request

Pull Request küçük documentation veya container fix ile başlanabilir. Code review feedback alınır. CI testleri gerçek contribution workflow'u öğretir. Dockerfile değişikliğinin platform etkisi görülür. İşbirliği becerisi teknik bilgiyi güçlendirir.

Docker Compose Örneklerini Paylaşmak

Çalışır örnek repository başkalarının öğrenmesini kolaylaştırır. README minimum setup adımlarını içerir. Secret gerçek değer taşımaz. Multi architecture veya Watch behavior dokümante edilebilir. Feedback örneğin kalitesini artırır.

Açık Kaynak Projelere Dev Container Eklemek

Devcontainer contributor onboarding'i hızlandırabilir. Toolchain standardize edilir. Repository yeni contributor için daha erişilebilir olur. Container size ve startup süresi dikkate alınmalıdır. Maintainer ile workflow uyumu konuşulmalıdır.

Ekip İçinde Container Standardı Oluşturmak

Common Dockerfile pattern tekrar eden hataları azaltır. Non root ve healthcheck baseline olabilir. Compose service naming ortaklaştırılabilir. Template sürekli review edilmelidir. Standard rigid değil ekip ihtiyaçlarına uyumlu olmalıdır.

Diyarbakır Yazılım Topluluğu ile Docker ve DevOps Çalışmaları

Docker öğrenmenin en etkili yollarından biri yalnızca komut ezberlemek yerine küçük fakat gerçek projeler üretmektir. Diyarbakır Yazılım Topluluğu çevresinde container teknolojileri, CI/CD, Linux ve açık kaynak işbirliği aynı uygulama içinde ele alınabilir. Docker ile İzole Edilmiş Geliştirme ve Dağıtım Ortamları konusu full stack laboratuvarlarından self hosted deployment çalışmalarına kadar birçok uygulamalı çalışma için uygun temel sunar. Topluluk projelerini https://www.diyarbakiryazilim.com.tr/projects adresinden inceleyebilirsiniz. Topluluğun çalışma yaklaşımı hakkında daha fazla bilgi için https://www.diyarbakiryazilim.com.tr/about adresi kullanılabilir.

Diyarbakır Yazılım Topluluğu İçinde Container Teknolojileri

Container çalışmaları yalnız docker run komutuyla sınırlı kalmamalıdır. Network, volume ve image lifecycle birlikte ele alınabilir. Katılımcılar aynı repository üzerinde farklı host sistemlerden çalışma deneyimi kazanabilir. Production security ayrıca laboratuvar konusu olabilir. Öğrenme gerçek deployment senaryosuyla pekişir.

Docker Workshopları

Workshop temel image build ile başlayabilir. Katılımcı kendi Dockerfile'ını üretir. Non root user ve healthcheck eklenir. Multi stage build uygulanır. Son adım registry ve deployment olabilir.

Docker Compose Laboratuvarları

Frontend, API ve database aynı Compose stack içinde kurulabilir. Service discovery ve localhost farkı uygulamalı görülür. Named volume persistence test edilir. Watch hot reload için eklenebilir. Profiles optional tooling'i yönetir.

CI/CD Çalışmaları

Repository push sonrası test pipeline çalıştırılabilir. Image bir kez build edilir. Scan ve registry push eklenir. Staging aynı digest'i kullanır. Rollback senaryosu laboratuvarda test edilebilir.

Open Source ve İşbirliği Projeleri

Ortak repository contribution pratiği sağlar. Issue ve Pull Request ile task yönetilebilir. Dockerfile değişikliği review edilir. CI sonuçları tüm katılımcılara görünür olur. Documentation da proje çıktısının parçasıdır.

Diyarbakır'daki En İyi Yazılımcılarla Teknik Deneyim Paylaşımı

Teknik deneyim paylaşımı farklı problem çözme yaklaşımlarını görmeyi sağlar. Container network veya build cache gibi konular gerçek örneklerle konuşulabilir. Katılımcılar kendi projelerindeki sorunları anonim teknik senaryoya dönüştürebilir. Review kültürü ortak öğrenmeyi güçlendirir. Amaç tek kişiye bağlı bilgi yerine paylaşılabilir mühendislik pratiği oluşturmaktır.

Ortak Docker Proje Fikirleri

Docker öğrenmek için proje gerçek service ilişkileri içermelidir. Full stack environment iyi başlangıçtır. Mikroservis laboratuvarı network ve observability pratiği sağlar. CI/CD pipeline artifact promotion yaklaşımını öğretir. Self hosted stack backup ve rollback gibi production konularını görünür hale getirir.

Full-Stack Development Environment

Frontend, backend, PostgreSQL ve Redis birlikte kurulabilir. Compose Watch hot reload sağlar. Named volume database data'yı saklar. Development ve production stage'leri ayrılır. README tek komutlu onboarding hedefler.

Mikroservis Laboratuvarı

İki küçük API ayrı service olarak çalışabilir. Internal network communication test edilir. Reverse proxy routing eklenir. Distributed logging uygulanabilir. Failure ve retry davranışı gözlenir.

CI/CD Pipeline

Commit test pipeline tetikler. Image build ve scan tamamlanır. Registry digest üretilir. Staging deployment smoke test çalıştırır. Approved digest production benzeri environment'a promote edilir.

Self-Hosted Uygulama Stack'i

Tek host Compose production modeli kurulabilir. Reverse proxy ve TLS yapılandırılır. Backup ve log rotation eklenir. Health ve rollback script'i hazırlanır. Host update ve security maintenance de çalışmanın parçası olur.

Sık Sorulan Sorular

Docker konusunda en sık sorulan sorular development ile production arasındaki farklarda yoğunlaşır. Docker yalnız container başlatma aracı olarak görüldüğünde volume, secret ve image lifecycle gibi önemli konular kolayca gözden kaçar. Sağlıklı yaklaşım development hızını korurken production artifact'ını immutable tutmaktır. Compose tek host ve local geliştirmede güçlüdür ancak her ölçek problemine cevap vermek zorunda değildir. Aşağıdaki kısa açıklamalar temel karar noktalarını özetler.

Docker nedir?

Docker container tabanlı uygulama build ve çalışma platformudur. Application dependency'lerini image içinde tanımlamayı sağlar. Container bu image'ın çalışan örneğidir. Network ve volume gibi ek kaynakları yönetebilir. CI/CD sürecinde aynı artifact'ın taşınmasını kolaylaştırır.

Docker ile geliştirme ortamı nasıl oluşturulur?

Önce application Dockerfile ile containerize edilir. Database ve cache Compose service olarak eklenir. Source bind mount veya Compose Watch ile development feedback sağlanır. Environment örnekleri ve seed script eklenir. Tek komutlu startup hedeflenir.

Docker gerçekten izolasyon sağlar mı?

Evet, namespace, filesystem ve resource sınırlarıyla önemli izolasyon sağlar. Ancak container host kernel'ini paylaşabilir. VM ile aynı güvenlik sınırı değildir. Privileged mode ve Docker socket izolasyonu zayıflatabilir. Security defense in depth yaklaşımı gerektirir.

Docker container ile sanal makine arasındaki fark nedir?

VM ayrı guest OS ve sanallaştırılmış kernel sınırı kullanır. Container çoğunlukla host kernel'ini paylaşır. Container daha hızlı başlar ve daha hafif olabilir. VM güçlü tenant isolation sağlayabilir. İki yaklaşım aynı altyapıda birlikte kullanılabilir.

Docker Compose nedir?

Docker Compose birden fazla service container'ını tek application modeliyle yönetir. Network ve volume tanımları aynı dosyada bulunur. Development stack tek komutla başlatılabilir. Profiles optional service'leri yönetir. Production tek host deployment'ta da kullanılabilir.

Development ve production için ayrı Dockerfile gerekir mi?

Her zaman gerekmez. Multi stage Dockerfile çoğu projede iyi çözümdür. Development target debugger taşır. Production target minimal runtime üretir. Çok farklı build süreçlerinde ayrı Dockerfile düşünülebilir.

Docker Compose Watch nedir?

Compose Watch local file değişikliklerini container service'e aktarır. Sync, restart ve rebuild aksiyonları tanımlanabilir. Docker Compose 2.22.0 ve sonrası develop specification içinde kullanılabilir. :contentReference[oaicite:56]{index=56} Native dependency klasörleri ignore edilebilir. Hot reload inner loop'u hızlandırır.

Compose Watch mı bind mount mı kullanılmalı?

Basit Linux projede bind mount yeterli olabilir. Desktop platformlarda büyük file tree için Watch faydalı olabilir. node_modules gibi klasörler Watch ile ignore edilebilir. Bind mount doğrudan paylaşım sağlar. Karar gerçek performans ölçümüne göre verilmelidir.

Dev Container nedir?

Dev Container development toolchain'ini container içinde tanımlar. IDE extension ve CLI araçları standardize edilebilir. Runtime version repository ile birlikte yönetilir. Compose service workspace olarak kullanılabilir. Yeni developer onboarding'i hızlanır.

Docker içinde localhost neden çalışmaz?

localhost yalnız aynı container'ı gösterir. Database başka container ise service name kullanılmalıdır. Compose internal DNS bunu sağlar. Host'a bağlanmak farklı endpoint gerektirir. Port mapping yalnız host erişimi için kullanılır.

Docker volume ile bind mount arasındaki fark nedir?

Bind mount belirli host path'i container'a bağlar. Volume Docker tarafından yönetilen storage alanıdır. Source development için bind mount uygundur. Database data için named volume sık kullanılır. Docker belgeleri de volume'ları Docker managed persistent storage olarak tanımlar. :contentReference[oaicite:57]{index=57}

Development ve production aynı image'ı kullanmalı mı?

En güçlü model production candidate image'ın test ve staging'de aynı artifact olarak kullanılmasıdır. Development hot reload için farklı target kullanabilir. Ortak base runtime korunmalıdır. Production image development tooling taşımamalıdır. Build once promote everywhere final release açısından hedeflenmelidir.

Docker Compose production'da kullanılabilir mi?

Evet, tek host küçük ve orta ölçekli uygulamalarda kullanılabilir. Health, restart ve backup süreçleri yine tasarlanmalıdır. Compose multi host orchestrator değildir. High availability ihtiyacı büyüdüğünde başka platform gerekebilir. Operasyonel basitlik gerçek avantajdır.

Docker Compose ne zaman yetersiz kalır?

Multi host scheduling gerektiğinde sınırlar belirginleşir. Automated self healing ve horizontal scaling ihtiyacı artabilir. Yüksek availability ve advanced rollout beklentisi orchestrator gerektirebilir. Çok sayıda service manual operation'ı zorlaştırır. Team operasyon kapasitesi kararı etkiler.

Docker Compose ile Kubernetes arasındaki fark nedir?

Compose tek host service management odaklıdır. Kubernetes cluster level scheduling ve desired state yönetir. Kubernetes rolling update ve multi node self healing sağlar. Öğrenme ve operasyon yükü daha yüksektir. Local development için Compose çok daha sade olabilir.

Docker container neden root çalıştırılmamalıdır?

Root runtime exploit etkisini artırabilir. Non root user filesystem ve process yetkilerini sınırlar. Dockerfile USER kullanılabilir. Permission doğru ayarlanmalıdır. Root olmamak tek güvenlik kontrolü değildir.

Rootless Docker nedir?

Rootless mode Docker daemon ve container'ları root olmayan user namespace içinde çalıştırır. Docker resmi belgeleri bu yöntemin daemon ve runtime vulnerability etkisini azaltmaya yardımcı olduğunu belirtir. :contentReference[oaicite:58]{index=58} Development cihazlarında iyi seçenek olabilir. Bazı low level feature sınırlamaları vardır. Workload compatibility test edilmelidir.

Docker socket neden tehlikelidir?

Docker socket Engine API kontrolü verir. Host mount ve privileged container oluşturma mümkün olabilir. Socket'e erişen application host üzerinde geniş yetki kazanabilir. CI untrusted code'a socket vermemelidir. Rootless veya proxy bazı riskleri azaltabilir.

Docker secret nasıl saklanır?

Secret repository veya Dockerfile içine yazılmamalıdır. Compose secrets service bazında file mount sağlayabilir. Varsayılan path /run/secrets altındadır. :contentReference[oaicite:59]{index=59} Production secret manager rotation ve audit sağlayabilir. Her service yalnız gerekli secret'a erişmelidir.

Docker image nasıl güvenli hale getirilir?

Güvenilir minimal base kullanılmalıdır. Multi stage build final runtime'ı küçültür. Non root user tercih edilir. Vulnerability ve secret scan yapılır. Digest, SBOM ve signing supply chain güvenini güçlendirir.

Docker ile CI/CD nasıl yapılır?

Commit sonrası test çalışır. CI image'ı bir kez build eder. Scan ve registry push yapılır. Digest staging'de test edilir. Aynı digest production'a promote edilir.

Docker için en iyi programlama dili hangisidir?

Docker belirli dile bağlı değildir. Uygulama ihtiyacı ve team deneyimi daha önemlidir. Python, Node.js, Go, Java ve diğer runtime'lar kullanılabilir. Container design dili tamamlar. Sağlıklı build ve runtime ayrımı daha kritik konudur.

Docker öğrenmek yazılımcı olmak için gerekli midir?

Her yazılımcı için zorunlu değildir. Ancak modern backend ve DevOps workflow'larında çok faydalıdır. Linux ve networking temellerinden sonra öğrenilmesi daha kolaydır. Gerçek proje üzerinde çalışmak en iyi yöntemdir. Docker temel programlama bilgisinin yerine geçmez.

Open source ve işbirliği Docker öğrenmeye nasıl katkı sağlar?

Gerçek Dockerfile örnekleri görülebilir. Issue ve Pull Request üzerinden troubleshooting öğrenilir. Container standardı üzerine review alınır. Devcontainer veya Compose contribution yapılabilir. Ekip çalışması production pratiğini güçlendirir.

Sonuç: Docker ile Gerçekten İzole ve Tekrarlanabilir Ortam Nasıl Kurulur?

Docker ile İzole Edilmiş Geliştirme ve Dağıtım Ortamları yalnız uygulamayı container içine koymakla tamamlanmaz. Development hızlı feedback için optimize edilirken production minimal, non root ve immutable artifact kullanmalıdır. Build yalnız CI içinde bir kez yapılmalı ve aynı image digest test, staging ve production zincirinde ilerlemelidir. Configuration, secret, data ve network her environment için ayrı tutulmalıdır. Healthcheck, logging, backup ve rollback olmadan container çalıştırmak production operasyonunun yalnız yarısını tamamlamak anlamına gelir.

Ortamı Kodla Tanımlayın

Dockerfile runtime build sürecini tanımlar. Compose service ilişkilerini repository'ye taşır. Environment example configuration sözleşmesini gösterir. Setup manual komutlara bağımlı kalmaz. Code review environment değişikliklerini görünür hale getirir.

Development Ortamını Hızlı Geri Bildirim İçin Optimize Edin

Hot reload developer inner loop'unu hızlandırır. Bind mount veya Compose Watch ihtiyaca göre seçilir. Build cache dependency installation süresini azaltır. Profiles gereksiz service'leri kapalı tutar. Debug tooling yalnız development stage'de kalır.

Production Image'ını Minimal ve Immutable Tutun

Source bind mount kullanılmaz. Compiler ve debugger final image'da bulunmaz. Non root user ile çalıştırılır. Yeni değişiklik yeni image build'iyle gelir. Container içinde manual patch yapılmaz.

Development ve Production'ı Aynı Artifact Zincirine Bağlayın

Runtime ve dependency version'ları ortak tutulur. Development farklı target kullanabilir. CI final production image'ı üretir. Staging aynı artifact'ı test eder. Environment farkı configuration'da kalır.

Build Once, Promote Everywhere Yaklaşımını Kullanın

CI image'ı tek kez build eder. Registry digest artifact identity olur. Test ve staging aynı digest'i kullanır. Production yeniden build yapmaz. Rollback previous digest'e döner.

Configuration ve Secret'ları Image'dan Ayırın

Non secret config environment variable olabilir. Password ve key secret mekanizmasıyla verilir. Production secret manager kullanılabilir. Build secret BuildKit mount üzerinden geçer. Image environment'a özel credential taşımaz.

Network ve Yetkileri Minimumda Tutun

Database public port yayınlamaz. Frontend database network'üne bağlanmaz. Container non root user kullanır. Docker socket yalnız zorunlu tool'a verilir. External egress gerçek ihtiyaca göre sınırlandırılır.

CI Testlerini Geçici ve İzole Ortamlarda Çalıştırın

Her CI job unique Compose project oluşturabilir. Fresh database ve migration kullanılır. Testler birbirinin state'ini görmez. Failure logları artifact olarak saklanır. Job sonunda container ve volume temizlenir.

Production'da Health, Logs, Backup ve Rollback Süreçlerini Tasarlayın

Healthcheck deployment doğrulamasını destekler. Log rotation host diskini korur. Merkezi logging incident analizini kolaylaştırır. Stateful data düzenli backup alır ve restore test edilir. Previous image digest rollback için her zaman hazır tutulur.

Compose Yetersiz Kaldığında Orchestrator'a Geçin

Tek host Compose birçok uygulama için yeterli olabilir. Multi host ve high availability ihtiyacı büyüdüğünde orchestrator değerlendirilebilir. Horizontal scaling ve rolling update gerçek gerekçe olmalıdır. Kubernetes gibi platformlar operasyon yükünü de beraberinde getirir. Araç seçimi ekip kapasitesi ve sistem gereksinimine dayanmalıdır.

Kurumsal Docker geliştirme ve deployment ortamı kurulum hizmeti değerlendirirken yalnız Dockerfile yazılıp yazılmadığına bakmayın. Development onboarding, CI artifact üretimi, secret yönetimi, image güvenliği, backup, monitoring ve rollback aynı çalışma içinde ele alınmalıdır. Diyarbakır Yazılım Topluluğu tarafından paylaşılan çalışmalar ve proje yaklaşımı için https://www.diyarbakiryazilim.com.tr/projects ve https://www.diyarbakiryazilim.com.tr/about adreslerini inceleyebilirsiniz. Docker ve container DevOps danışmanlığı yakınımda şeklinde araştırma yapıyorsanız hedefiniz yalnız container başlatmak değil, aynı artifact'ın güvenle test edilip production'a taşındığı sürdürülebilir bir süreç kurmak olmalıdır. Docker ve DevOps çalışmaları için https://www.diyarbakiryazilim.com.tr üzerinden iletişim kurabilirsiniz.

Docker ile İzole Geliştirme ve Dağıtım Ortamları Hakkında Ek Sık Sorulan Sorular

Docker projelerinde olgunluk arttıkça sorular container komutlarından environment governance konularına doğru ilerler. Aynı image'ın hangi ortamlarda kullanılacağı, secret'ların nasıl verileceği ve database'in hangi network'te bulunacağı önemli kararlar haline gelir. Docker Compose local ve tek host senaryolarında güçlü bir model sunar. CI/CD aynı artifact'ı environment'lar boyunca ilerlettiğinde deployment farkları daha görünür ve yönetilebilir olur. Aşağıdaki sorular uygulamaya geçerken en sık karşılaşılan beş ihtiyacı özetler.

Docker ile izole edilmiş geliştirme ve dağıtım ortamları nasıl oluşturulur?

Önce uygulamanın runtime ve dependency'leri Dockerfile içinde tanımlanmalıdır. Database, cache ve worker gibi servisler Compose üzerinden ayrı container'lar halinde çalıştırılabilir. Development source paylaşımı için bind mount veya Compose Watch kullanılırken production immutable registry image kullanmalıdır. Volume, network, environment variable ve secret'lar source koddan ayrı ve environment bazında yönetilmelidir. CI aynı image'ı build edip test, staging ve production süreçlerinde digest üzerinden ilerletmelidir.

Docker kullanımı geliştirme staging ve production ortamları arasındaki tutarlılığı nasıl sağlar?

Runtime ve application dependency'leri image içinde sabitlendiğinde ortamların temel çalışma katmanı aynı kalır. CI tarafından bir kez build edilen image staging ve production'a yeniden oluşturulmadan taşınabilir. Böylece staging'de test edilen artifact ile production'da çalışan artifact aynı digest'e sahip olur. Ortama göre yalnız database endpoint, secret, domain ve benzeri configuration değerleri değişir. Tam eşitlik yerine davranışı etkileyen runtime parçalarında kontrollü parity hedeflenir.

Docker Compose ile çoklu servislerden oluşan geliştirme ortamları nasıl yönetilir?

Frontend, backend, database, cache ve worker servisleri compose.yaml içinde ayrı service olarak tanımlanır. Servisler internal Compose network üzerinden isimleriyle birbirlerini bulabilir. Database ve dependency state named volume üzerinde tutulabilir. Healthcheck ve depends_on local startup düzenini iyileştirirken profiles ihtiyaç olmayan debug veya admin servislerini kapalı tutabilir. Compose Watch source değişikliklerini sync, restart veya rebuild aksiyonlarıyla development container'larına aktarabilir.

Docker container’larında volume network environment variable ve güvenlik ayarları nasıl yapılandırılmalıdır?

Source development'ta bind mount veya Watch kullanabilirken database data için named volume tercih edilebilir. Network tarafında database public girişten ayrılmalı ve yalnız backend service'in bulunduğu private network'e bağlanmalıdır. Açık configuration environment variable ile verilebilir ancak password ve API key gibi değerler secret olarak yönetilmelidir. Production container non root çalıştırılmalı, gereksiz portlar kapatılmalı ve Docker socket mount edilmemelidir. Resource limit, healthcheck, log rotation ve immutable image digest bu yapıyı tamamlamalıdır.

Docker ile izole geliştirme ve dağıtım ortamları konusunda yakınımda danışmanlık veya eğitim nerede bulabilirim?

Danışmanlık veya eğitim seçerken yalnız Docker komutlarını anlatan içerik yerine development, CI/CD ve production operasyonunu birlikte ele alan yaklaşımı tercih edin. BuildKit, Compose Watch, network isolation, secret yönetimi, image güvenliği, logging, backup ve rollback aynı proje üzerinde uygulanmalıdır. Diyarbakır Yazılım Topluluğu'nun proje çalışmalarını https://www.diyarbakiryazilim.com.tr/projects adresinden inceleyebilirsiniz. Topluluk hakkında ayrıntılı bilgi için https://www.diyarbakiryazilim.com.tr/about adresini kullanabilirsiniz. Docker ve DevOps süreçleri hakkında iletişim kurmak için https://www.diyarbakiryazilim.com.tr adresine ulaşabilirsiniz.