Container Nedir? Sanallaştırma vs Containerization

Yazılım dünyasında öyle bir cümle var ki, muhtemelen her geliştiricinin en az bir kez söylediği ve her operasyon mühendisinin duyduğunda gözlerini devireceği bir cümle: "Ama benim bilgisayarımda çalışıyor!"

Bu ders, işte tam olarak bu sorunun neden var olduğunu ve Docker'ın bu sorunu nasıl kökünden çözdüğünü anlatacak. Ama başlamadan önce, sana bir analoji vereyim — çünkü teknik kavramları somut örneklerle anlamak çok daha kolay.

Apartman Dairesi mi, Müstakil Ev mi?

Bir apartman düşün. Her dairenin kendi mutfağı, banyosu ve elektrik sayacı var. Ama hepsi aynı binayı, aynı temeli, aynı çatıyı paylaşıyor. Komşunun mutfağında ne piştiğini bilmene gerek yok — senin dairen senin, onun dairesi onun. Ama binanın temeli herkese ait.

Şimdi bir de müstakil ev düşün. Kendi temelin, kendi çatın, kendi bahçen var. Komşuyla hiçbir şey paylaşmıyorsun. Tam izolasyon. Ama bunun bedeli ne? Çok daha fazla alan, çok daha fazla maliyet, çok daha fazla bakım.

İşte Docker dünyasında container, o apartman dairesi. Sanal makine (VM) ise müstakil ev. İkisi de seni "izole" ediyor, ama biri çok daha hafif, çok daha hızlı, çok daha verimli. Bu derste bu farkı derinlemesine anlayacağız.

Peki Sorun Ne? Neden Bu Teknolojiye İhtiyaç Var?

Diyelim ki bir web uygulaması geliştiriyorsun. Bilgisayarında Python 3.11 var, PostgreSQL 15 çalışıyor, libssl 1.1.1 yüklü ve /tmp/uploads diye bir dizin oluşturdun. Uygulaman gayet güzel çalışıyor. Harika.

Sonra bu uygulamayı sunucuya deploy etme vakti geldi. Sunucuda ne var? Python 3.9, PostgreSQL 14, libssl 3.0 ve /tmp/uploads diye bir dizin yok. Sonuç? Uygulama patlar. Ve sen saatlerce "ama bende çalışıyordu" diye debug edersin.

Bu sorunun kökü basit: ortam farklılıkları. Senin bilgisayarındaki ortam ile sunucudaki ortam birebir aynı değil. Bir kütüphanenin versiyonu bile farklı olsa, her şey alt üst olabiliyor.

Container'lar bu sorunu kökünden çözer. Nasıl mı? Uygulamayı, tüm bağımlılıklarını, konfigürasyonunu ve çalışma ortamını tek bir paket haline getirirsin. Bu paket nereye götürürsen götür — laptopuna, AWS'ye, Azure'a, arkadaşının bilgisayarına — aynı şekilde çalışır. Çünkü ortam artık uygulamanın içinde.

Önce Sanallaştırmayı Anlayalım

Container'ı anlamak için önce sanallaştırmanın ne olduğunu bilmemiz gerekiyor. Çünkü container, sanallaştırmanın evrimleşmiş hali gibi.

Geleneksel Sunucu — Her Şey İç İçe

Eskiden sunucular şöyle çalışıyordu: Bir fiziksel makine, üzerinde bir işletim sistemi, ve o işletim sistemi üzerinde birden fazla uygulama. Basit ama sorunlu.

┌─────────────────────────────┐
│         Uygulama A          │
│         Uygulama B          │
│         Uygulama C          │
├─────────────────────────────┤
│       İşletim Sistemi       │
├─────────────────────────────┤
│         Donanım             │
└─────────────────────────────┘

Sorun şu: Uygulama A Python 2 istiyor, Uygulama B Python 3 istiyor. İkisi aynı işletim sistemi üzerinde çatışıyor. Birini güncellersen diğeri bozuluyor. Bu yüzden insanlar "her uygulama için ayrı sunucu alalım" demeye başladı. Ama bu da çılgınca pahalı.

Sanal Makineler — Ayrı Dünyalar

İşte bu noktada sanallaştırma devreye girdi. Bir fiziksel makine üzerinde birden fazla "sanal makine" oluşturabilirsin. Her sanal makinenin kendi işletim sistemi var.

┌───────────┐ ┌───────────┐ ┌───────────┐
│   App A   │ │   App B   │ │   App C   │
├───────────┤ ├───────────┤ ├───────────┤
│  Guest OS │ │  Guest OS │ │  Guest OS │
│ (Ubuntu)  │ │ (CentOS)  │ │ (Alpine)  │
└─────┬─────┘ └─────┬─────┘ └─────┬─────┘
      │              │              │
┌─────┴──────────────┴──────────────┴─────┐
│           Hypervisor (VMware, KVM)       │
├─────────────────────────────────────────┤
│            Host İşletim Sistemi          │
├─────────────────────────────────────────┤
│                 Donanım                  │
└─────────────────────────────────────────┘

Güzel, artık her uygulama kendi dünyasında. Python 2 ve Python 3 yan yana, birbirini görmeden çalışıyor. Ama bir bedeli var: her sanal makine tam bir işletim sistemi çalıştırıyor. Bu ne demek?

Her VM yüzlerce megabayttan birkaç gigabayta kadar disk alanı kaplıyor. Her biri açılmak için 30-60 saniye bekliyor. Her biri ciddi miktarda RAM tüketiyor — çünkü her birinin kendi kernel'ı, kendi servis yöneticisi, kendi dosya sistemi var. İşe yarıyor ama ağır. Çok ağır.

Container'lar — Hafif, Hızlı, Verimli

Ve işte container'lar tam bu noktada sahneye çıkıyor.

┌───────────┐ ┌───────────┐ ┌───────────┐
│   App A   │ │   App B   │ │   App C   │
│  + libs   │ │  + libs   │ │  + libs   │
└─────┬─────┘ └─────┬─────┘ └─────┬─────┘
      │              │              │
┌─────┴──────────────┴──────────────┴─────┐
│         Container Runtime (Docker)       │
├─────────────────────────────────────────┤
│            Host İşletim Sistemi          │
├─────────────────────────────────────────┤
│                 Donanım                  │
└─────────────────────────────────────────┘

Farkı gördün mü? Container'lar host işletim sisteminin kernel'ını paylaşıyor. Ayrı bir OS boot etmiyorlar. Sadece uygulamanın ihtiyacı olan kütüphaneleri ve dosyaları içeriyorlar.

Bu ne anlama geliyor pratikte? Birkaç megabayt boyut (gigabayt değil). Milisaniyeler içinde başlama (dakikalar değil). Ve minimal kaynak tüketimi. Aynı sunucuya 10-20 VM sığdırabilirsin. Ama aynı sunucuya 100'den fazla container sığdırabilirsin.

Şimdi bunu bir tabloyla özetleyelim ki kafanda netleşsin:

Burada kritik bir nokta var: container daha az izole ama çok daha hafif. VM daha izole ama çok daha ağır. Bu ikisi birbirinin rakibi değil — farklı senaryolarda farklı tercihler yaparsın. Ama günümüzde çoğu uygulama için container yeterli ve tercih edilen çözüm.

Container Nasıl Çalışır? — Linux'un İki Süper Gücü

"Tamam, container hafif ve hızlı. Ama nasıl oluyor da aynı kernel'ı paylaşan uygulamalar birbirini görmüyor?" diye sorabilirsin. Çok haklı bir soru.

Container'lar sihir değil. Linux kernel'ının iki temel özelliği üzerine kurulu: Namespaces ve cgroups. Bu ikisini anlaman, Docker'ın "nasıl" çalıştığını kavramak için yeterli.

Namespaces — "Görebildiğin Dünya"

Namespace, bir prosesin görebildiği dünyayı kısıtlayan bir mekanizma. Şöyle düşün: senin bilgisayarında yüzlerce proses çalışıyor. Ama bir container başlattığında, o container sadece kendi proseslerini görüyor. Dışarıdaki yüzlerce proses onun için yok.

Altı farklı namespace türü var ve her biri farklı bir şeyi izole ediyor:

PID namespace proses ID'lerini izole eder. Container kendi proseslerini görür, host'un veya başka container'ların proseslerini göremez. NET namespace ağ arayüzlerini izole eder — her container'ın kendi IP adresi ve portları var. MNT namespace dosya sistemini izole eder — container kendi dosya ağacını görür. UTS namespace hostname'i izole eder. IPC namespace prosesler arası iletişimi izole eder. Ve USER namespace kullanıcı ID'lerini izole eder — container içindeki root, host'taki root ile aynı değildir.

Bunu gözle görmek ister misin? Şunu deneyelim:

# Önce host'ta kaç proses çalışıyor bakalım
ps aux | wc -l
# Çıktı: 237 (yüzlerce proses)

# Şimdi bir container içinde aynı komutu çalıştıralım
docker run --rm alpine ps aux
# PID   USER     COMMAND
#   1   root     ps aux

Gördün mü? Host'ta yüzlerce proses var, ama container sadece kendisini görüyor. Tek bir proses: ps aux komutu. Container, host'taki diğer proseslerin varlığından bile haberdar değil. İşte namespace'lerin gücü bu.

cgroups — "Kullanabileceğin Kaynaklar"

Namespace "ne göreceğini" belirlerken, cgroups "ne kadar kullanabileceğini" belirler. Bir container'a "sen maksimum 512MB RAM ve 1 CPU core kullanabilirsin" diyebilirsin.

# Container'a kaynak limiti verelim
docker run --memory=512m --cpus=1 nginx

Bu container ne kadar RAM isterse istesin 512MB'ı geçemez. Ne kadar CPU kullanmak isterse istesin 1 core'dan fazlasını alamaz. Eğer memory limitini aşmaya kalkarsa, Linux kernel onu sonlandırır (OOM Kill). Bu, bir container'ın diğerlerini "boğmasını" önler.

Bu iki mekanizma birlikte çalışınca ne elde ediyoruz? İzole, kaynak-sınırlı, güvenli bir çalışma ortamı. İşte buna container diyoruz.

Docker — Container'ı Herkesin Kullanabileceği Hale Getiren Platform

Aslında container kavramı Docker'dan önce de vardı. Linux'ta LXC (Linux Containers) 2008'den beri mevcuttu. Ama LXC kullanmak karmaşıktı — namespace ve cgroup'ları manuel yönetmen, dosya sistemlerini elle ayarlaman gerekiyordu. Normal bir geliştirici için bu pratik değildi.

2013'te Docker sahneye çıktı ve her şeyi değiştirdi. Docker, tüm bu karmaşıklığı tek bir komutun arkasına gizledi:

docker run nginx

Bu tek komut arka planda neler yapıyor biliyor musun? Önce nginx image'ını kontrol ediyor — yerelde yoksa Docker Hub'dan indiriyor. Sonra o image'dan bir container oluşturuyor. Namespace'leri konfigüre ediyor. cgroup'ları ayarlıyor. Ağ yapılandırmasını yapıyor. Ve container'ı başlatıyor. Altta düzinelerce sistem çağrısı yapılıyor, ama sen sadece docker run yazıyorsun. İşte Docker'ın dehası bu: karmaşıklığı basitliğe dönüştürmek.

Docker'ın iç yapısına kısaca bakalım, çünkü ileriki derslerde bu katmanlarla karşılaşacaksın:

┌─────────────────────────────────────────┐
│              Docker CLI                  │
│         (senin yazdığın komutlar)        │
└─────────────┬───────────────────────────┘
              │ REST API
┌─────────────▼───────────────────────────┐
│          Docker Daemon (dockerd)         │
│    (arka planda çalışan servis)          │
└─────────────┬───────────────────────────┘
              │
┌─────────────▼───────────────────────────┐
│          containerd                      │
│    (container yaşam döngüsü yönetimi)   │
└─────────────┬───────────────────────────┘
              │
┌─────────────▼───────────────────────────┐
│            runc                           │
│   (Linux kernel ile konuşan katman)      │
└─────────────────────────────────────────┘

Sen terminalde docker run yazdığında, bu komut Docker CLI tarafından alınıp Docker Daemon'a iletiliyor. Daemon, containerd'ye "şu container'ı oluştur" diyor. containerd de runc aracılığıyla Linux kernel'ın namespace ve cgroup özelliklerini kullanarak container'ı hayata geçiriyor.

Günlük kullanımda bu katmanların detayını bilmen gerekmez. Ama "Docker aslında nasıl çalışıyor?" sorusunun cevabı bu. Ve bu bilgi, sorun yaşadığında neyin nerede olduğunu anlamana yardımcı olacak.

Image ve Container — Bu Ayrımı Şimdi Kavramak Çok Önemli

Şimdi sana Docker'ın en temel ayrımını anlatacağım. Bu ayrımı şimdi net kavramak, ileriki tüm dersleri kolaylaştıracak.

Bir yemek tarifini düşün. Tarif kağıda yazılmış, sabit, değişmez. Ama o tariften istediğin kadar yemek yapabilirsin — bugün de yaparsın, yarın da. Her seferinde aynı tarif, ama her seferinde yeni bir yemek.

Docker'da image, o yemek tarifi. Değişmez, sabittir, disk üzerinde durur. Container ise o tariften yapılmış yemek — çalışan, yaşayan bir instance.

# Image'ı indirelim (tarifi alalım)
docker pull nginx

# Aynı image'dan birden fazla container oluşturalım (yemek yapalım)
docker run --name web1 nginx
docker run --name web2 nginx
docker run --name web3 nginx

Üç ayrı container, hepsi aynı image'dan. Her biri bağımsız çalışıyor. Birinde yaptığın değişiklik diğerlerini etkilemiyor.

Şu tabloyu kafana kazı:

Bu ayrım neden bu kadar önemli? Çünkü Docker'ın tüm felsefesi bu ayrım üzerine kurulu. Image'lar paylaşılabilir, versiyonlanabilir, bir registry'de saklanabilir. Container'lar ise geçici — her an silinip yeniden oluşturulabilir. Bu "geçicilik" (ephemeral) kavramını ileride çok duyacaksın.

Hadi Ellerimizi Kirletelim — İlk Container Deneyleri

Teoriyi yeterince konuştuk. Şimdi gerçekten bir şeyler çalıştıralım. Docker kurulumu bir sonraki derste ama eğer Docker zaten kuruluysa bu örnekleri hemen deneyebilirsin. Kurulu değilse kavramsal olarak takip et.

Hello World — Docker'ın "Merhaba Dünya"sı

docker run hello-world

Bu komutu çalıştırdığında şöyle bir çıktı göreceksin:

Unable to find image 'hello-world:latest' locally
latest: Pulling from library/hello-world
c1ec31eb5944: Pull complete
Digest: sha256:...
Status: Downloaded newer image for hello-world:latest

Hello from Docker!
This message shows that your installation appears to be working correctly.

Peki burada ne oldu, adım adım bakalım. Docker önce hello-world image'ını bilgisayarında aradı — bulamadı. Sonra Docker Hub'dan (Docker'ın merkezi image deposu) indirdi. İndirdiği image'dan bir container oluşturdu. Container bir mesaj yazdırdı ve işi bitti — container durdu.

Basit görünüyor ama arka planda çok şey oldu. Image indirildi, katmanlar çözüldü, container oluşturuldu, namespace'ler ayarlandı ve proses çalıştırıldı. Hepsi bir saniyeden kısa sürede.

İnteraktif Bir Linux Shell

Şimdi daha ilginç bir şey yapalım:

docker run -it ubuntu bash

Bu komutu çalıştırdığın anda kendini tam bir Ubuntu ortamının içinde bulacaksın:

root@a1b2c3d4e5f6:/# cat /etc/os-release
# Ubuntu bilgileri görünür

root@a1b2c3d4e5f6:/# apt update && apt install -y curl
# Paketler yükleniyor...

root@a1b2c3d4e5f6:/# curl --version
# curl çalışıyor!

root@a1b2c3d4e5f6:/# exit

Burada çok önemli bir şey fark etmeni istiyorum: exit yazıp çıktığın anda container durur. Ve içine yüklediğin curl de dahil her şey kaybolur. Container'ı tekrar başlatsan bile, sıfırdan başlar. Bu, container'ların "geçici" (ephemeral) doğasının en güzel gösterimi. Kalıcı veri saklamak istersen volume kullanman gerekir — onu da ileriki derslerde öğreneceğiz.

Web Sunucusu — Gerçek Bir Senaryo

Şimdi bir web sunucusu ayağa kaldıralım:

docker run -d -p 8080:80 nginx

Buradaki flag'leri açıklayayım. -d "detached" demek — container arka planda çalışsın, terminalimi meşgul etmesin. -p 8080:80 ise port mapping — "host'umun 8080 portuna gelen istekleri container'ın 80 portuna yönlendir" demek.

Şimdi tarayıcıda http://localhost:8080 adresini aç. Nginx'in karşılama sayfasını göreceksin. Tek bir komutla, bilgisayarında hiç Nginx kurmadan, bir web sunucusu çalıştırdın!

Çalışan container'ları görmek için:

docker ps

Çıktıda container'ın ID'sini, image'ını, durumunu ve port bilgisini göreceksin. Durdurmak için:

docker stop <container_id>

Docker Neden Bu Kadar Popüler?

Container teknolojisi Docker'dan önce de vardı ama Docker patlamayı yarattı. Neden? Çünkü gerçek dünya problemlerini somut şekilde çözüyor.

Tutarlılık — "Benim Makinemde Çalışıyor" Sorunu Biter

Geliştirme, test, staging, production — hepsi aynı container'ı çalıştırıyor. Ortam farkı sorunu kökten çözülüyor. Bir geliştirici "bende çalışıyor" dediğinde, artık "tabii ki çalışıyor, aynı container her yerde aynı çalışır" diye cevap verirsin.

İzolasyon — Uygulamalar Birbirine Karışmaz

Python 2 ve Python 3 yan yana, Node 16 ve Node 20 yan yana — çatışma yok. Her container kendi dünyasında. Hatta aynı sunucuda PHP 5.6 gerektiren eski bir uygulama ile PHP 8.3 gerektiren yeni bir uygulama sorunsuzca çalışabilir:

docker run -d -p 8080:80 php:5.6-apache   # Eski uygulama
docker run -d -p 8081:80 php:8.3-apache   # Yeni uygulama

Hız — Saniyeler İçinde Başlar

VM'ler dakikalar alırken, container'lar saniyeler hatta milisaniyeler içinde başlar. Bu fark CI/CD pipeline'larında, auto-scaling'de ve geliştirme döngüsünde hayati önem taşır.

Verimlilik — Aynı Sunucudan Daha Fazla İş Çıkar

Bir sunucuya 10 VM sığdırabilirsin. Aynı sunucuya 100'den fazla container sığdırabilirsin. Çünkü container'lar kernel'ı paylaşır — her biri için ayrı işletim sistemi çalıştırmana gerek yok.

Taşınabilirlik — Nereye Götürürsen Çalışır

Docker image'ını laptopunda build et, test ortamında test et, AWS'ye deploy et, Azure'a taşı — her yerde aynı şekilde çalışır. "Hangi bulut sağlayıcısını kullanacağız?" kararını verirken Docker ile daha özgürsün.

Ekip Verimliliği — Yeni Geliştirici 3 Dakikada Hazır

Yeni biri ekibe katıldığında: "Docker'ı kur, docker-compose up çalıştır, başla." 3 saat süren ortam kurulumu → 3 dakika. Bu, özellikle büyük ekiplerde muazzam bir verimlilik artışı sağlar.

Container'ın Yaşam Döngüsü

Bir container doğar, yaşar ve ölür. Bu yaşam döngüsünü bilmek, container'larla çalışırken seni çok rahatlatacak.

Created → Running → Paused → Running → Stopped → Removed
   ↑                                        │
   └────────────────────────────────────────┘
                  (restart)

Bunu pratikte görelim:

# 1. Container'ı oluştur (ama başlatma)
docker create --name myapp nginx

# 2. Başlat
docker start myapp

# 3. Çalışıyor mu bakalım
docker ps
# STATUS: Up ...

# 4. Duraklat (prosesler donuyor, silinmiyor)
docker pause myapp

# 5. Devam ettir
docker unpause myapp

# 6. Nazikçe durdur (SIGTERM gönderir, 10 saniye bekler)
docker stop myapp

# 7. Tamamen sil (artık yok)
docker rm myapp

Günlük kullanımda docker run komutunu kullanırsın — bu create ve start'ı birlikte yapar. Ve container'ı durdurmak istediğinde docker stop, silmek istediğinde docker rm.

Bir kısa yol daha: docker run --rm ile başlattığın container, durduğu anda otomatik silinir. Tek seferlik işler için çok kullanışlı.

Docker Ne Değildir? — Yanlış Anlaşılmaları Temizleyelim

Docker hakkında çok yaygın bazı yanlış anlamalar var. Bunları baştan temizlemek, ileride kafanın karışmasını önler.

Docker bir sanal makine değildir. Bunu en baştan netleştirelim. VM tam bir işletim sistemi çalıştırır, Docker ise host kernel'ını paylaşır. Bu temel fark, performanstan kaynak kullanımına kadar her şeyi etkiler.

Docker sadece Linux'ta çalışmaz. macOS ve Windows'ta da kullanabilirsin. Ama arka planda ne oluyor biliyor musun? Docker Desktop, hafif bir Linux VM çalıştırıyor ve container'lar o VM'in içinde çalışıyor. Sen farkında bile olmuyorsun — docker run yazıyorsun, gerisi otomatik.

Docker her sorunu çözmez. GUI uygulamaları, kernel seviyesinde işlemler veya yoğun I/O gerektiren bazı workload'lar için container en uygun çözüm olmayabilir. Docker bir araç — doğru yerde kullanırsan harika, yanlış yerde kullanırsan zorlarsın.

Docker ve Kubernetes aynı şey değildir. Docker container çalıştırır. Kubernetes ise yüzlerce-binlerce container'ı orkestre eder — hangisi nerede çalışacak, biri çökerse ne olacak, nasıl ölçeklenecek. Farklı katmanlar, farklı sorumluluklar.

Container otomatik olarak güvenli değildir. Varsayılan ayarlarla container'lar yeterince izole olmayabilir. Güvenlik için ekstra yapılandırma gerekir — bunu kursun ilerleyen bölümlerinde detaylıca ele alacağız.

İyi Alışkanlıklar — Şimdiden Başla

Henüz Docker'ın başındayız ama bazı alışkanlıkları şimdiden edinmek önemli. Bu kurallar deneyimli Docker kullanıcılarının yıllar içinde öğrendiği dersler:

Her container tek bir iş yapsın. Bir container'a web sunucusu, veritabanı ve cache hepsini birden koymaya çalışma. Her biri ayrı container'da olsun. Buna "Single Responsibility" prensibi deniyor.

Container'ları geçici olarak düşün. Bir container her an silinip yeniden oluşturulabilmeli. İçinde önemli veri saklama — veri volume'larda yaşamalı.

Container içine SSH ile bağlanıp elle değişiklik yapma. Bir şeyi değiştirmek istiyorsan Dockerfile'ı güncelle ve yeniden build et. Container'ın içinde yapılan manuel değişiklikler, container silindiğinde kaybolur.

Resmi image'ları tercih et. Docker Hub'da "Official Image" rozeti taşıyan image'lar Docker tarafından doğrulanmıştır. Güvenlik yamaları düzenli gelir, dokümantasyonu iyi olur.

Yaygın Hatalarla Tanışalım

Docker'a yeni başlayanların sıkça karşılaştığı hatalar var. Bunları şimdiden bilmek seni çok zaman kazandırır.

"docker: command not found" hatası alıyorsan, Docker henüz kurulu değil veya PATH'te değil. Bir sonraki derste kurulumu detaylıca yapacağız.

"permission denied while trying to connect to Docker daemon" hatası Linux'ta çok yaygın. Docker daemon'a erişim için yetki gerekiyor. Ya sudo ile çalıştırırsın ya da kullanıcını docker grubuna eklersin:

sudo usermod -aG docker $USER
# Çıkış yap ve tekrar gir

"port is already allocated" hatası, başka bir proses o portu zaten kullanıyor demek. Farklı bir port dene:

docker run -p 8081:80 nginx   # 8080 yerine 8081

Container başladı ama hemen durdu? Bu genellikle container'ın ön planda çalışacak bir prosesi olmadığı anlamına gelir. docker logs <container_id> ile ne olduğuna bak.

Bu Derste Ne Öğrendik?

Bu ilk derste Docker ve container dünyasının temellerini attık. Özetleyelim:

• Container, bir uygulamayı tüm bağımlılıklarıyla birlikte paketleyen, izole ve hafif bir çalışma ortamıdır. Apartman dairesi gibi — kendi alanın var ama binayı paylaşıyorsun.

• Sanal makine tam bir OS çalıştırırken, container kernel'ı paylaşır. Bu yüzden container çok daha hızlı başlar, çok daha az kaynak tüketir.

• Container teknolojisi Linux'un namespace (izolasyon) ve cgroup (kaynak sınırlama) özelliklerini kullanır. Sihir yok, sağlam mühendislik var.

• Image şablondur (yemek tarifi), container o şablondan oluşturulan çalışan instance'tır (yemek). Bir image'dan istediğin kadar container oluşturabilirsin.

• Docker, container teknolojisini herkesin kolayca kullanabileceği hale getiren platformdur. Karmaşıklığı basitliğe dönüştürür.

• Container'lar geçicidir (ephemeral). Kalıcı veri container içinde değil, volume'larda saklanır.

Bir sonraki derste Docker ekosisteminin tüm bileşenlerini — Engine, CLI, Desktop, Hub — tek tek tanıyacağız. Görüşmek üzere!