DOCKER CONTAINER VE IMAGE NEDİR?

Docker hakkında araştırmaya yeni başlayan çoğu kişi onu "hafif bir sanal makine" olarak tanımlar. Bu yaygın açıklama yanıltıcıdır ve container davranışını anlamayı ileride zorlaştırır — çünkü Docker sanal makineden temelde farklı çalışır. Container ve image kavramları da bu farkın üzerine kurulur. Bu yazı Docker'a yeni giren geliştiriciler, sistem yöneticileri ve eğitim sürecindeki öğrenciler için yazıldı. Sonunda elinizde net bir tanım, Dockerfile'a baktığınızda zihninizde canlanan doğru harita ve "hangi sorunu çözüyor" sorusuna pratik cevap olacak.

Docker Sanal Makine Değildir

Bu yanlış anlaşılma o kadar yaygın ki en başta ayırmak gerekir. Sanal makine (VM), fiziksel donanım üstünde tam bir işletim sistemi simüle eder. Her VM kendi kernel'ını, kendi sürücülerini, kendi belleğini taşır. Bir Linux sunucusunda iki VM açtığınızda her birinin gigabaytlarca RAM ve disk maliyeti vardır.

Docker container ise farklıdır. Konuk işletim sistemi yoktur. Container, host işletim sisteminin kernel'ını paylaşır ve sadece kendi süreçlerini, kendi dosya sistemini, kendi ağ yığınını izole bir alanda tutar. Bu izolasyon Linux kernel'ının namespaces ve cgroups özellikleriyle sağlanır. Sonuç: container saniyeler içinde ayağa kalkar, megabayt seviyesinde bellek tüketir, taşınabilirlik açısından VM ile karşılaştırılamaz hızdadır.

Bu ayrımı resmi Docker dokümantasyonu da net biçimde vurgular — container hafiftir çünkü tam bir OS taşımaz, sadece izole bir süreç çalıştırır.

Container Nedir

Container, kendi dosya sistemi, kendi süreç ağacı ve kendi ağ konfigürasyonu olan izole bir Linux süreci olarak düşünülebilir. Bir Python uygulamasını container içinde çalıştırdığınızda o uygulama:

• Sadece kendi içinde gördüğü dosyalara erişebilir; host'taki dosyalara doğrudan ulaşamaz
• Sadece kendi açtığı portları görür; host'un diğer portlarından habersizdir
• Bağımlılıkları (Python sürümü, pip paketleri, sistem kütüphaneleri) container'ın içinde paketlenmiştir
• Host makinedeki başka Python kurulumlarından etkilenmez

Bu yapı "bende çalışıyor" problemini büyük ölçüde ortadan kaldırır. Geliştirici makinesinde, test sunucusunda ve canlı ortamda aynı container çalışır — aynı kütüphane sürümleri, aynı konfigürasyon. Container ayağa kalktığında docker ps komutuyla listelenir, docker stop ile durdurulur, docker rm ile silinir.

Image Nedir

Container'ı bir çalışan örnek olarak düşünüyorsanız, image o örneğin şablonudur. Image, container ayağa kalktığında ortamı oluşturan dosya yapısı, bağımlılıklar ve konfigürasyonun salt-okunur (read-only) bir paketidir. Bir image üzerinden istediğiniz kadar container üretebilirsiniz — bir Python image'inden 10 farklı container ayağa kaldırırsanız hepsi aynı paketten doğmuş ama bağımsız çalışan süreçler olur.

Image'ler katmanlı yapıdadır. Her image bir base üzerine inşa edilir: FROM python:3.12-slim direktifi Python imaj'ını temel alır, üzerine sizin uygulama katmanınız yerleşir. Bu katman mantığı ve build cache invalidasyonu kendi başına geniş bir konudur ve Docker image katmanları başlığında ayrıca detaylandırılır.

Image'ler genellikle Docker Hub gibi public veya private registry'lerde tutulur. docker pull nginx:alpine komutu Docker Hub'dan nginx image'inin alpine tag'ini indirir. Kendi image'inizi push etmek de aynı mantıkla yapılır; git'in remote repository ile çalışma şekline yakın bir akıştır.

Image ve Container Arasındaki İlişki

Karışıklığın çoğu bu iki kavramın iç içe geçtiği yerde yaşanır. Basit bir analoji yardımcı olur:

• Image: Programın derlenmiş .exe dosyası gibi — disk üzerinde duran statik şablon
• Container: O .exe çift tıklandığında başlayan süreç gibi — bellekte koşan canlı örnek

Bir image asla "çalışmaz". Bir image'i çalıştırmak için docker run komutuyla ondan bir container yaratırsınız. docker images sistemdeki image'leri listeler; docker ps çalışan container'ları listeler. Aynı image üzerinden 100 container açabilirsiniz — disk üzerinde image bir kez vardır, container'lar onun üstüne ince yazılabilir katmanlar ekler.

Dockerfile ile Image Üretmek

Image'ler genellikle elden hazırlanmaz; Dockerfile adında bir metin tarifle build edilir. Tipik bir Dockerfile şöyle görünür:

FROM python:3.12-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY . .
CMD ["python", "app.py"]

Bu dosya bir reçetedir:

1. FROM — hangi base image'in üzerine inşa edileceği
2. WORKDIR — container içindeki çalışma dizini
3. COPY — host'taki dosyaların container'a kopyalanması
4. RUN — image build edilirken çalışacak komutlar
5. CMD — container başladığında çalışacak ana komut

docker build -t myapp:1.0 . komutu bu Dockerfile'ı yorumlar ve adım adım katmanlar üreterek myapp:1.0 etiketli bir image oluşturur. Sonra docker run myapp:1.0 ile bu image'den bir container ayağa kaldırırsınız. Dockerfile sürüm kontrolüne girer; ekipteki herkes aynı reçeteyle aynı image'i üretir.

Docker'ın Geliştiriciye Pratik Katkısı

Teoriye fazla takılmadan, Docker'ın günlük geliştirme akışında somut olarak ne yaptığını saymak gerekirse:

• Bağımlılık karmaşası biter: Aynı makinede Python 3.10, 3.11 ve 3.12 isteyen üç proje çakışmadan yan yana çalışır
• Onboarding kısalır: Yeni geliştiriciye 40 sayfalık kurulum dokümanı vermek yerine docker compose up komutu yeterli olur
• Ortamlar tutarlı kalır: Local, staging ve production aynı image üzerinden çalıştığında "test'te geçti ama prod'da patladı" senaryosu belirgin biçimde azalır
• Mikroservis mimarisi mümkün olur: Kubernetes'in ölçeklediği şey aslında Docker container'larıdır; container olmadan modern bulut mimarileri kurulamaz

Docker'ı tüm bu boyutlarıyla yapılandırılmış öğrenmek isteyenler için Docker eğitimi Dockerfile yazımı, image yönetimi, network ve volume konularını uygulamalı olarak işler.

Docker'ın Sınırları ve Yanlış Kullanımları

Docker her problemin çözümü değildir. Bazı sınırlamalar başlangıçta bilinmediğinde ileride bedel ödetir.

Container'lar varsayılan olarak stateless kabul edilir. Container silindiğinde içinde yazılı her şey kaybolur. Veritabanı gibi stateful servisler için volume veya bind mount kullanmadan production'a çıkmak veri kaybına davetiyedir. Container içindeki log'ları stdout/stderr'e yönlendirmek ve dışarıdan toplamak da artık standart pratiktir.

Windows ve macOS üzerinde Docker, arka planda hafif bir Linux VM çalıştırır — çünkü container teknolojisi temelde Linux kernel özelliklerine dayanır. Bu durum performans ve dosya I/O açısından native Linux ortamdan daha yavaştır. Yoğun I/O gerektiren build süreçlerinde fark belirgin hale gelir.

Container güvenlik yüzeyi geniştir. Image'in içinden ne çıktığı, hangi base'i kullandığı, hangi paketin güncelliği denetlenmediğinde production container'ı bilinen zafiyetlere açık olabilir. Trivy veya Snyk gibi imaj tarama araçları artık CI/CD akışlarının standart parçasıdır. Docker güçlü bir araçtır ama güvenli kullanımı disiplin ister.