VDS'de Docker Kurulumu ve Container Yönetimi

VDS sunucuya Docker kurulumu (Ubuntu 22.04/24.04, AlmaLinux 9), KVM virtio I/O performansı, daemon.json yapılandırma, cgroups v2 kaynak limitleri, rootless Docker, json-file log rotation, Compose stack, Docker Swarm vs k3s, sysctl tuning ve production güvenlik rehberi.

Büyükweb Editör EkibiHosting, Sunucu ve Sistem Yönetimi Editörü24 Ekim 202530 dakika okumaGüncellendi · 11 Mayıs 2026

VDS'de Docker Kurulumu ve Container Yönetimi

Docker, modern web uygulama deploy süreçlerinin temel taşı haline geldi. Geliştirici makinesinde çalışan bir kodun, aynı bağımlılık ve kernel kullanıcı uzayı ile sunucuda da çalışacağını garanti eden image katmanı, "bende çalışıyordu" tartışmasını sona erdirdi. Ancak Docker'ı VDS sunucu üzerinde production'a almak, sadece "docker-ce" paketini kurup üzerine bir-iki container açmaktan ibaret değildir. Hangi sanallaştırma katmanında çalıştığınız (KVM vs konteyner tabanlı), depolama I/O için virtio paravirtualization aktif mi, log driver dolduğunda disk neye uğradığını şaşırmadan döndürür mü, cgroups limit'lerini doğru çekmiş misiniz, rootless mod gerçek bir güvenlik kazancı mı yoksa kısıt mı, tek host'ta Compose mu yetiyor yoksa Swarm/k3s'e geçme vakti mi geldi — bu kararlar Docker'ı stabil tutan asıl iskelet.

Bu rehber Buyukweb VDS sunucularında Docker odaklıdır. Generic Docker kurulum yazılarından farklı olarak burada KVM tam sanallaştırma + virtio I/O entegrasyonu, VDS dedicated kaynak modeli içinde cgroups v2 limit politikası, json-file log driver disk dolma riski ve loki/journald'a geçiş, sysctl ayarları, Docker daemon güvenlik (socket, userns-remap, rootless), single-host Compose'dan Swarm'a geçiş eşiği gibi VDS-spesifik kararları işliyoruz. Dockerfile multi-stage build, Compose Spec detayı, image güvenlik tarama gibi yatay Docker konularını Docker ile Web Uygulaması Deploy yazımızda işledik; burada VDS bağlamına odaklanıyoruz.

Buyukweb perspektifi: VDS E5-V4 paketleri ₺250-600/ay aralığındadır ve KVM tam sanallaştırma + virtio I/O paravirtualization ile çalışır — Docker için ideal. Root erişim tam, daemon.json düzenleme, kernel modül yükleme (overlay2, btrfs, zfs), sysctl tuning, iptables/nftables zinciri yönetimi serbesttir. Bursa Tier 3 datacenter, DDoS L3+L4+L7 koruma, %99.8 uptime SLA, host seviyesinde günlük Veeam yedek. 17+ yıl deneyimle 7/24 destek hattı 0850 302 60 70. Şu kritik notla başlayalım: paylaşımlı hosting, cPanel/Plesk paketleri, Reseller paketlerinde Docker desteklenmez — Docker mutlaka VDS (veya Dedicated Sunucu) gerektirir.

Docker Mimarisi: Sadece "docker run" Demek Değil

Docker'ı kurmadan önce mimarisini anlamak, sonradan hata ayıklama sırasında çok zaman kazandırır. "Docker" tek bir binary değil, birbirine bağlı 4-5 ayrı bileşendir:

[Docker CLI]              kullanici komutlari (docker run, docker build, docker ps)
     |                    REST API ile dockerd ile konusur
     v
[dockerd (Docker Daemon)] /var/run/docker.sock unix soket dinler
     |                    image build, container yasam dongusu, network/volume
     v
[containerd]              container runtime ust katman, OCI spec uyumlu
     |                    /run/containerd/containerd.sock
     v
[runc]                    OCI low-level runtime, namespace + cgroups
     |                    yeni container icin clone()/unshare() syscall'lari
     v
[Linux Kernel]            namespaces (pid, net, mnt, uts, ipc, user, cgroup)
                          cgroups v2 (memory, cpu, io, devices, pids)
                          overlay2 storage driver (default)
                          seccomp, AppArmor/SELinux, capabilities

Bilesenlerin Rolu

Docker CLI (docker): Sadece kullanıcı arayüzü. dockerd'ye REST API çağrısı yapar, kendi başına container çalıştıramaz. docker context ile uzak dockerd'ye bağlanılabilir.
dockerd (Docker Daemon): Resmi adı Docker Engine. /var/run/docker.sock unix soketi veya TCP üzerinden komut alır. Image build (BuildKit), volume/network yönetimi, image registry pull/push, container lifecycle koordinasyonu yapar.
containerd: dockerd'nin altındaki "container manager". OCI uyumlu (Open Container Initiative). ctr CLI ile direkt konuşulabilir (debug için), normalde dockerd üzerinden kullanılır. Kubernetes de containerd'yi doğrudan kullanır (CRI ile).
runc: En düşük seviye OCI runtime. Container'ı gerçekten oluşturan binary. clone()/unshare() syscall'ları ile yeni namespace + cgroup hiyerarşisi yaratır, /proc/[pid]/ns altında dosya descriptor'ları açar, ardından container process'e dönüşür.
BuildKit: Modern image build motoru (eski docker build yerine). Paralel layer build, cache mount, secret mount, multi-platform build. DOCKER_BUILDKIT=1 veya buildx ile aktif.

OCI: Open Container Initiative

OCI üç şartname yayınlar:

Image Spec: Image katman dosyası formatı (tar + manifest.json + config.json)
Runtime Spec: Container'ı çalıştıracak süreç parametreleri (rootfs path, mount listesi, namespace listesi)
Distribution Spec: Image registry HTTP API (v2)

Docker, OCI uyumludur. Bu da Docker image'ının Podman, CRI-O, containerd, BuildKit gibi alternatif runtime'larda da çalışabileceği anlamına gelir.

Container vs VM Derin Karsilastirma

Yüzeysel anlatımda "container yalın, VM ağır" denir. Doğru ama eksik. Detayda neyin paylaşıldığı, neyin izole edildiği önemli:

Bileşen	Container (Docker)	VM (KVM/Hyper-V)
Kernel	Host ile paylaşır	Kendi kernel'i (guest OS)
Boot süresi	~50-500 ms	~10-60 saniye
RAM overhead	~10-50 MB	~512 MB-2 GB (guest OS)
Disk overhead	~50 MB (alpine) - 500 MB	~5-15 GB (full OS)
İzolasyon	Namespace + cgroups + seccomp	Hardware-assisted (VT-x/AMD-V)
Güvenlik sınırı	Kernel exploit → host'a kaçabilir	Hypervisor escape (çok zor)
Aynı host'ta sayı	Yüzlerce	Onlarca
Live migration	Sınırlı (CRIU ile)	Yaygın (KVM live migrate)
Network performansı	Native (veya overlay)	Virtio için native gibi

Namespace: Yedi Tür İzolasyon

Linux kernel yedi namespace sağlar; her container ayrı set alır:

Namespace	Ne İzole Eder
pid	Process ID ağacı (container içinde PID 1 = init)
net	Ağ arayüzleri, iptables, routing tablosu, port'lar
mnt	Mount point'leri (chroot benzeri ama daha güçlü)
uts	Hostname ve domain adı
ipc	System V IPC, POSIX message queue
user	UID/GID eşleme (root container içinde, normal user host'ta)
cgroup	cgroup root görünümü (container kendi cgroup'una kök gibi bakar)

Cgroups v1 vs v2: Tek Hiyerarşi

Cgroups v1: Her kontrolör (memory, cpu, io) ayrı hiyerarşide. Bir process'in CPU limit'ini ayarlamak başka, bellek limit'ini ayarlamak başka cgroup tree'ye yazmak demek. Karmaşık ve tutarsız davranışlara yol açar.

Cgroups v2 (Unified Hierarchy): Tek bir cgroup tree. Tüm kontrolörler aynı dizin altında yapılandırılır. Ubuntu 22.04+, AlmaLinux 9+, Debian 11+ varsayılan olarak cgroups v2 kullanır. Docker 20.10+ tam destekli.

cgroups v2 ile gelen başlıca controller'lar:

Controller	Kontrol Eder
memory	RAM + swap kullanımı, OOM davranışı
cpu	CPU shares (weight), bandwidth (period/quota)
io	Disk I/O (blkio yerine), bandwidth + IOPS
pids	Maksimum process sayısı (fork bomb koruma)
cpuset	CPU affinity ve NUMA node atama
devices	Hangi /dev cihazlarına erişim izni

Cgroups v2'nin v1'e kıyasla avantajı: tek mount point (/sys/fs/cgroup), tutarlı bellek hesaplama (page cache dahil), thread mode desteği, daha temiz dökümantasyon.

Storage Driver: overlay2

Container'ın read-only image katmanı + write katmanı (container layer) birleşimi için storage driver kullanılır. Modern Docker varsayılanı overlay2 (Linux 4.0+ kernel ile birlikte gelir):

upperdir = container write katmani (sadece container ile var olan dosyalar)
lowerdir = image read-only katmanlar (alttan ust katmana siralanir)
merged   = container'in gordugu birlestirilmis dosya sistemi
workdir  = overlay'in atomic operasyonlar icin gecici alani

overlay2 alternatifleri: btrfs (snapshot destekli, COW), zfs (ZFS dataset bazlı), aufs (eski, deprecated), devicemapper (eski RHEL varsayılanı, eski). VDS'te overlay2 default ve çoğu durumda en iyi seçim.

Seccomp, Capabilities, AppArmor/SELinux

Container'ın güvenlik sınırını üç ek katman güçlendirir:

Seccomp (Secure Computing Mode): Container'ın kullanabileceği syscall listesini filtreler. Docker default profile, ~300 syscall'dan ~50'sini bloklar (reboot, kexec_load, module_init gibi tehlikeli olanlar).
Linux Capabilities: Root'un sahip olduğu yetkileri ~40 parçaya böler. Default container, sadece 14 capability alır (NET_BIND_SERVICE, CHOWN, DAC_OVERRIDE, SETUID, SETGID...). Diğerleri (CAP_SYS_ADMIN, CAP_NET_ADMIN...) drop edilir. --cap-add/--cap-drop ile özelleştirilir.
AppArmor / SELinux: MAC (Mandatory Access Control) katmanı. Ubuntu varsayılan AppArmor, RHEL/AlmaLinux varsayılan SELinux. Docker, container'a otomatik profil uygular.

Neden VDS Docker Icin Ideal? KVM + Virtio

Docker'ın temel beklentisi: kendi kernel modüllerini yükleyebilmek, overlay2 storage driver çalıştırmak, iptables/nftables ile NAT zinciri kurmak, cgroups + namespace syscall'larını çağırmak, /proc ve /sys'e tam erişim. Hangi sanallaştırma modeli bunlara izin verir?

Sanallaştırma	Docker Çalışır mı?	Performans	Açıklama
Bare metal	Evet	Native	Doğrudan donanım üzerinde Linux
KVM (full virt)	Evet, native gibi	Çok yüksek	Buyukweb VDS varsayılan
Xen HVM	Evet	Yüksek	Tam virt, KVM benzeri
Xen PV	Kısıtlı	Düşük	Paravirt, kernel uyumluluk sorunu
OpenVZ / Virtuozzo	Kısıtlı/Yok	Düşük	Container-in-container, kernel paylaşım
LXC	Evet ama riskli	İyi	Container-in-container, kernel paylaşım

Sonuç: KVM = Docker için altın standart. Buyukweb VDS sunucuları KVM tam sanallaştırma ile gelir. KVM, donanım yardımıyla (Intel VT-x / AMD-V) tam izole bir misafir kernel çalıştırır. Misafir içinde Docker, native bir Linux makineye sığar gibi davranır.

Virtio Paravirtualization: KVM'in I/O Hizlandiricisi

KVM, virtio denilen paravirtualization sürücüleri ile I/O performansını native'e yaklaştırır. Klasik emule edilmiş cihaz (e1000 NIC, IDE disk) yerine virtio şu cihazları sağlar:

Virtio Sürücü	Cihaz Türü	Performans Etkisi
virtio-net	Ağ kartı	Native'e yakın (~95%+)
virtio-blk / virtio-scsi	Blok cihaz (disk)	Native'e yakın (~90%+)
virtio-balloon	RAM balon (host'a dön)	Bellek esnekliği
virtio-rng	Random number generator	Container'lar için kritik
virtio-9p / virtiofs	Dosya paylaşımı	Host ↔ guest fast FS

Buyukweb VDS sunucuları varsayılan olarak virtio-net + virtio-blk ile yapılandırılır. Bu, Docker container'larının disk I/O ve network throughput'unun, bare metal'e çok yakın olduğu anlamına gelir. virtio-blk ile MySQL gibi I/O yoğun container'lar 10.000+ IOPS aralığında çalışabilir.

KVM + Docker: Nested vs Native

"Docker, KVM içinde çalışıyor. Bu nested virtualization değil mi?" Hayır:

Nested virtualization = KVM içinde KVM çalıştırmak (örn. VDS içinde VirtualBox VM)
Docker in KVM = KVM içinde Linux kernel namespace + cgroups kullanmak

Docker, sanallaştırma değildir; kernel feature'larıdır. Bu yüzden KVM içinde Docker, ek katman olmadan native performansta çalışır. Nested KVM (VirtualBox/VMware Workstation VDS'te) ise CPU tarafından desteklenmelidir; Buyukweb VDS planları nested virt'i talep üzerine sunabilir, ancak çoğu Docker senaryosunda bu gerekli değildir.

Docker Kurulumu: Ubuntu 22.04/24.04

cPanel/Plesk olmadan, "çıplak" Ubuntu üzerine resmi Docker CE deposundan kurulum. Apt paket yöneticisindeki docker.io paketi yerine resmi Docker repo'sunu kullanmak güncel sürüm ve docker compose plugin için kritik:

1. Eski docker.io / docker-doc Paketlerini Kaldir

for pkg in docker.io docker-doc docker-compose docker-compose-v2 podman-docker containerd runc; do
  apt-get remove -y \${pkg}
done

2. Apt Sertifika ve Anahtar

apt-get update
apt-get install -y ca-certificates curl gnupg

install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg \
  | gpg --dearmor -o /etc/apt/keyrings/docker.gpg
chmod a+r /etc/apt/keyrings/docker.gpg

3. Apt Source Ekle

echo \
  "deb [arch=\$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] \
  https://download.docker.com/linux/ubuntu \
  \$(. /etc/os-release && echo \"\${VERSION_CODENAME}\") stable" \
  | tee /etc/apt/sources.list.d/docker.list > /dev/null

apt-get update

4. Docker Paketlerini Kur

apt-get install -y \
  docker-ce \
  docker-ce-cli \
  containerd.io \
  docker-buildx-plugin \
  docker-compose-plugin

5. Service Aktiflestir

systemctl enable --now docker
systemctl status docker
docker run --rm hello-world

Apt Pinning (Versiyon Sabitleme)

Production'da otomatik Docker minor upgrade istemiyorsanız:

cat <<EOF > /etc/apt/preferences.d/docker
Package: docker-ce docker-ce-cli containerd.io
Pin: version 26.1.*
Pin-Priority: 1001
EOF

Docker Kurulumu: AlmaLinux 9 / Rocky Linux 9

RHEL ailesinde dnf üzerinden:

dnf -y install dnf-plugins-core
dnf config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo

dnf -y install \
  docker-ce \
  docker-ce-cli \
  containerd.io \
  docker-buildx-plugin \
  docker-compose-plugin

systemctl enable --now docker
docker --version

SELinux aktif AlmaLinux 9'da Docker, /var/lib/docker altına otomatik container_t etiketi atar. Eğer bind mount kullanıyorsanız host dizinine :Z ekleyerek SELinux uyumu sağlayın: -v /host/data:/container/data:Z.

Post-Install: Kritik Yapilandirma

Docker kurulu artık ama production için mutlaka ele alınması gereken yapılandırmalar var:

1. docker Grubu

groupadd docker
usermod -aG docker \${USER}
# logout/login veya: newgrp docker

Güvenlik uyarısı: docker grubuna eklemek sudo root vermekle eşdeğerdir. Çünkü docker run -v /:/host alpine chroot /host ile root shell alınabilir. Hassas VDS'te sadece sysadmin'ler bu grupta olmalı.

2. /etc/docker/daemon.json — Merkezi Yapilandirma

Docker daemon'ın varsayılan davranışını değiştirmek için tek doğru yer burası. Servis restart gerektirir.

{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "5",
    "compress": "true"
  },
  "storage-driver": "overlay2",
  "live-restore": true,
  "default-runtime": "runc",
  "userland-proxy": false,
  "no-new-privileges": true,
  "default-ulimits": {
    "nofile": {
      "Name": "nofile",
      "Hard": 65536,
      "Soft": 65536
    }
  },
  "registry-mirrors": [],
  "insecure-registries": [],
  "metrics-addr": "127.0.0.1:9323",
  "experimental": false,
  "icc": false,
  "userns-remap": "default"
}

Anahtar ayarların açıklaması:

log-driver: json-file + max-size: 10m + max-file: 5: ÇOK ÖNEMLİ. Varsayılan Docker, container log'larını json-file driver ile /var/lib/docker/containers/[id]/[id]-json.log altında sınırsız büyüten dosyaya yazar. Yoğun log üreten bir container, bir gecede VDS diskini doldurabilir. max-size: 10m + max-file: 5 = container başına maksimum 50 MB. Compress aktif ile %70 sıkıştırma.
live-restore: true: Docker daemon yeniden başlarken (systemctl restart docker) çalışan container'lar dururkene karışmadan ayakta kalmaya devam eder. Production kritik.
userland-proxy: false: NAT için docker-proxy userspace process yerine doğrudan iptables NAT kullanılır. Daha düşük overhead, ancak bazı senaryolarda (loopback erişim) sorun çıkarabilir.
no-new-privileges: true: Container içinde setuid binary'lerinin privilege escalation yapmasını engeller. CIS Docker Benchmark önerisi.
icc: false: Container-to-container otomatik bağlantı kapalı. Compose'da explicit network tanımlamanız gerekir; daha güvenli default.
userns-remap: default: User namespace remap aktif. Container içinde root, host'ta 231072 gibi bir UID'ye eşlenir. Container escape'i ciddi anlamda zorlaştırır.
metrics-addr: Prometheus formatlı Docker daemon metrik endpoint'i.

Daemon.json değiştirdikten sonra:

systemctl restart docker

3. systemd Unit Override (Opsiyonel)

Docker servisinin OOM (Out of Memory) önceliği, restart davranışı:

mkdir -p /etc/systemd/system/docker.service.d/
cat > /etc/systemd/system/docker.service.d/override.conf <<'EOF'
[Service]
LimitNOFILE=infinity
LimitNPROC=infinity
LimitCORE=infinity
OOMScoreAdjust=-500
TasksMax=infinity
EOF

systemctl daemon-reload
systemctl restart docker

4. Log Rotation: json-file'in Otesinde

json-file driver basit ama büyük ölçeklerde yetersiz. Alternatifler:

Log Driver	Avantaj	Dezavantaj
json-file	Default, kolay (`docker logs`)	Disk dolma riski, query zor
journald	systemd entegre, `journalctl`	json metadata kayıp olabilir
syslog	Klasik UDP/TCP, remote ship	Format kayıp
local	Sıkıştırılmış, JSON dışı format	`docker logs` çalışır
fluentd	Esnek pipeline, çok hedef	Fluentd kurmak gerekir
splunk	Splunk HEC entegre	Splunk lisansı
awslogs / gcplogs	Bulut log servisleri	(Buyukweb dışı)

Buyukweb VDS önerisi: json-file + max-size 10m + max-file 5 başlangıç için yeterli. Yüksek hacim (saniyede 100+ log satırı) durumunda Loki + Promtail self-host kurulumu öneririz: promtail container'ı /var/lib/docker/containers ve /var/log/journal izler, Loki'ye gönderir, Grafana'da Logfmt query.

Rootless Docker: Kavram ve Sinir

Klasik Docker daemon root olarak çalışır. /var/run/docker.sock'a erişim = root erişim. Rootless Docker, daemon'ı bir kullanıcı olarak çalıştırarak bu güvenlik sınırını kapatır.

# Kullanici olarak (root olmadan)
curl -fsSL https://get.docker.com/rootless | sh

# systemd user service
systemctl --user start docker
systemctl --user enable docker
loginctl enable-linger \${USER}

# Cevre degiskeni
export DOCKER_HOST=unix:///run/user/1000/docker.sock
export PATH=/home/myuser/bin:\$PATH

Rootless Avantajları

Daemon root değil — host compromise yüzeyi küçülür
Container escape olsa bile sadece kullanıcı UID'sine düşer
Multi-tenant ortamlar için tercih edilir (her kullanıcı kendi Docker'ı)

Rootless Sınırları

Port < 1024: Direkt bind edilemez (Linux unprivileged port rule). 80/443 için setcap CAP_NET_BIND_SERVICE veya reverse proxy gerekir.
Cgroups v2 zorunlu: cgroups v1 sistemde rootless çalışmaz veya kısıtlıdır.
Network performansı: Rootless mode, slirp4netns veya VPN-Kit benzeri user-space network stack kullanır. Native bridge'e göre %5-15 throughput kaybı.
Bazı volume mount kombinasyonları kısıtlı: --privileged, --cap-add SYS_ADMIN, --device gibi yetkiler ile uyumsuzluk.
AppArmor profili sınırlı: Default AppArmor profili user-space'de yüklenemez.

Ne Zaman Rootless?

Dev/staging ortamlarda her zaman ✓
Multi-tenant shared VPS ortamlarında ✓
Production'da: workload'unuz port < 1024'e bind etmiyorsa ve network throughput kritik değilse ✓
Yüksek performans HTTP/3 + QUIC gateway gibi: rootful + capability drop ile daha iyi sonuç

Podman: Daemonless Alternatif (Kavramsal)

Podman, Red Hat'in geliştirdiği daemonless container engine'dir. Docker CLI ile büyük ölçüde uyumlu (alias docker=podman). Farkları:

Boyut	Docker	Podman
Mimari	dockerd daemon + CLI	Daemonless, fork-exec
Root gerekli mi?	Daemon root	Rootless default
systemd entegre	Manuel	`podman generate systemd` ile native
Pod kavramı	Yok (sadece container)	Var (Kubernetes pod'a benzer)
Compose	docker compose plugin	podman-compose veya kube YAML
Build engine	BuildKit	Buildah
OCI uyumlu	Evet	Evet
RHEL ailesi default	(Docker)	Podman (RHEL 8+)

AlmaLinux/Rocky 9'da varsayılan kurulumda Podman geliyor. Eğer ekibiniz Docker CLI'ya alışkın değilse veya security-first yaklaşım istiyorsa, Podman güçlü bir alternatiftir. Buyukweb VDS planlarında müşteri tercihi ile her ikisi de kurulabilir.

Image Yonetimi ve Self-Host Registry

Image Lifecycle

# Pull (registry'den indir)
docker pull nginx:1.27-alpine

# List
docker images
docker image ls --filter "dangling=true"   # tagsiz orphan'lar

# Inspect
docker image inspect nginx:1.27-alpine

# Build (Dockerfile'dan image olustur)
docker build -t myorg/myapp:v1.0.0 .
DOCKER_BUILDKIT=1 docker build --cache-from myorg/myapp:cache .

# Push (registry'ye yukle)
docker login registry.sirket.com.tr
docker push myorg/myapp:v1.0.0

# Cleanup
docker image prune              # dangling
docker image prune -a           # kullanilmayan tum image'lar
docker system prune -a --volumes  # her sey (DIKKATLI)

Tag Stratejisi: Tag Immutability

Asla latest tag'i production'a deploy etmeyin. latest kaymalı bir referanstır:

Bugün latest = v1.5.2
Yarın latest = v1.6.0 (breaking change içerebilir)
Production tek-yönlü patladığında "ne deploy ettim?" sorusunun cevabı yok

Doğru yaklaşım:

myorg/myapp:v1.0.0        # semantic version (release)
myorg/myapp:v1.0.0-sha    # git SHA ekli (immutable)
myorg/myapp:2026-05-11    # tarih bazli (CI)
myorg/myapp:cache         # build cache (yardimci)

Image digest (sha256:abc123...) ile pin etmek en güvenli:

services:
  app:
    image: myorg/myapp@sha256:abc123def456...

Self-Host Registry (registry:2)

Docker Inc resmi registry image'ı (registry:2) tek container'da çalışan basit registry sunar. Buyukweb VDS'inizde kendi private registry'nizi 10 dakikada kurabilirsiniz:

# docker-compose.yml
services:
  registry:
    image: registry:2
    restart: unless-stopped
    ports:
      - "5000:5000"
    environment:
      REGISTRY_AUTH: htpasswd
      REGISTRY_AUTH_HTPASSWD_REALM: "Registry Realm"
      REGISTRY_AUTH_HTPASSWD_PATH: /auth/htpasswd
      REGISTRY_HTTP_TLS_CERTIFICATE: /certs/fullchain.pem
      REGISTRY_HTTP_TLS_KEY: /certs/privkey.pem
      REGISTRY_STORAGE_DELETE_ENABLED: "true"
    volumes:
      - ./data:/var/lib/registry
      - ./auth:/auth:ro
      - /etc/letsencrypt/live/registry.sirket.com.tr:/certs:ro

htpasswd ile basic auth:

docker run --rm --entrypoint htpasswd httpd:2 -Bbn admin 'StrongPassword!123' \
  > auth/htpasswd

Daha kurumsal ihtiyaç (vulnerability scan, replication, RBAC, web UI) için Harbor (kavramsal alternatif). Harbor kurulum ayrı bir konu; basit private registry için registry:2 yeterli.

Dockerfile: VDS Baglaminda Hizli Hatirlatici

Yatay Dockerfile detayını Docker ile Web Uygulaması Deploy yazımızda işledik. Burada sadece VDS bağlamında kritik 4 nokta:

1. Multi-Stage Build (Image Kucult)

# Stage 1: build (700 MB)
FROM node:20-alpine AS build
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

# Stage 2: production (60 MB)
FROM node:20-alpine
WORKDIR /app
COPY --from=build /app/dist ./dist
COPY --from=build /app/node_modules ./node_modules
COPY --from=build /app/package.json ./
USER node
EXPOSE 3000
CMD ["node", "dist/server.js"]

VDS'in disk maliyeti var (E5-V4 paketlerinde 50-500 GB SSD). 700 MB yerine 60 MB image, hem registry storage'ı hem deploy süresini kısaltır.

2. .dockerignore (Build Context Kucult)

node_modules
.git
.env
.env.*
*.log
coverage
.next
.vscode
.idea
docker-compose*.yml
README.md

VDS'te 1 GB build context yerine 50 MB → daha hızlı build.

3. USER non-root (Container Icinde Root Olma)

RUN addgroup --gid 1001 nodejs && \
    adduser --uid 1001 --ingroup nodejs --disabled-password --no-create-home appuser
USER appuser

Container içinde root, escape durumunda host'a sızma yüzeyini büyütür. Non-root user ile çalışmak best practice.

4. HEALTHCHECK (Compose ile Etkilesim)

HEALTHCHECK --interval=30s --timeout=5s --start-period=10s --retries=3 \
  CMD curl -fsS http://localhost:3000/health || exit 1

Compose'da depends_on: condition: service_healthy ile başka servisler bu container hazır olunca başlar.

BuildKit: Modern Image Build

DOCKER_BUILDKIT=1 docker build veya docker buildx build ile aktif:

export DOCKER_BUILDKIT=1
docker build -t myapp .

Cache Mount (Bagımlilik Cache'i)

# syntax=docker/dockerfile:1.7
FROM node:20-alpine
WORKDIR /app
COPY package*.json ./
RUN --mount=type=cache,target=/root/.npm \
    npm ci
COPY . .
RUN npm run build

.npm cache'i build'ler arası persist olur. CI'da build süresi %50-70 düşer.

Secret Mount (Build Sirasinda Gizli)

docker build --secret id=npmrc,src=$HOME/.npmrc .

Dockerfile'da:

RUN --mount=type=secret,id=npmrc,target=/root/.npmrc \
    npm ci

Secret build sırasında dosya olarak görünür, image katmanına yazılmaz. CI'da kritik.

Parallel Layer Build

BuildKit, bağımsız stage'leri paralel build eder. Multi-stage Dockerfile'da büyük kazanç.

Compose v2: Production-Ready Stack

docker compose (v2, plugin) komutu — docker-compose (v1, Python) eski. Yeni proje için her zaman v2.

Tam Ozellikli Compose Ornegi: WordPress + MariaDB + Redis + Traefik

# docker-compose.yml
name: kurumsal-wp

services:
  traefik:
    image: traefik:v3.1
    restart: unless-stopped
    command:
      - "--api.dashboard=true"
      - "--providers.docker=true"
      - "--providers.docker.exposedbydefault=false"
      - "--entrypoints.web.address=:80"
      - "--entrypoints.web.http.redirections.entrypoint.to=websecure"
      - "--entrypoints.web.http.redirections.entrypoint.scheme=https"
      - "--entrypoints.websecure.address=:443"
      - "[email protected]"
      - "--certificatesresolvers.le.acme.storage=/letsencrypt/acme.json"
      - "--certificatesresolvers.le.acme.httpchallenge=true"
      - "--certificatesresolvers.le.acme.httpchallenge.entrypoint=web"
      - "--accesslog=true"
      - "--metrics.prometheus=true"
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
      - traefik-letsencrypt:/letsencrypt
    networks:
      - frontend
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.dashboard.rule=Host(\`traefik.sirket.com.tr\`)"
      - "traefik.http.routers.dashboard.entrypoints=websecure"
      - "traefik.http.routers.dashboard.tls.certresolver=le"
      - "traefik.http.routers.dashboard.service=api@internal"
      - "traefik.http.routers.dashboard.middlewares=auth"
      - "traefik.http.middlewares.auth.basicauth.users=admin:\$\$2y\$\$10\$\$..."

  wordpress:
    image: wordpress:6.5-php8.2-fpm-alpine
    restart: unless-stopped
    depends_on:
      mariadb:
        condition: service_healthy
      redis:
        condition: service_started
    environment:
      WORDPRESS_DB_HOST: mariadb:3306
      WORDPRESS_DB_USER: wpuser
      WORDPRESS_DB_PASSWORD_FILE: /run/secrets/wp_db_password
      WORDPRESS_DB_NAME: wpdb
      WORDPRESS_TABLE_PREFIX: wp_
      WORDPRESS_CONFIG_EXTRA: |
        define('WP_REDIS_HOST', 'redis');
        define('WP_REDIS_PORT', 6379);
        define('WP_CACHE', true);
    secrets:
      - wp_db_password
    volumes:
      - wp-content:/var/www/html/wp-content
    networks:
      - backend
      - frontend
    healthcheck:
      test: ["CMD", "wp", "core", "is-installed", "--allow-root"]
      interval: 30s
      timeout: 10s
      retries: 5
      start_period: 30s
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.wp.rule=Host(\`sirket.com.tr\`)"
      - "traefik.http.routers.wp.entrypoints=websecure"
      - "traefik.http.routers.wp.tls.certresolver=le"
      - "traefik.http.services.wp.loadbalancer.server.port=9000"
    deploy:
      resources:
        limits:
          cpus: "2.0"
          memory: 1G
        reservations:
          cpus: "0.5"
          memory: 256M

  mariadb:
    image: mariadb:10.11
    restart: unless-stopped
    environment:
      MARIADB_ROOT_PASSWORD_FILE: /run/secrets/db_root_password
      MARIADB_DATABASE: wpdb
      MARIADB_USER: wpuser
      MARIADB_PASSWORD_FILE: /run/secrets/wp_db_password
    secrets:
      - db_root_password
      - wp_db_password
    volumes:
      - mariadb-data:/var/lib/mysql
    networks:
      - backend
    healthcheck:
      test: ["CMD", "healthcheck.sh", "--connect", "--innodb_initialized"]
      interval: 10s
      timeout: 5s
      retries: 10
    deploy:
      resources:
        limits:
          memory: 1G

  redis:
    image: redis:7-alpine
    restart: unless-stopped
    command: ["redis-server", "--maxmemory", "256mb", "--maxmemory-policy", "allkeys-lru"]
    networks:
      - backend
    deploy:
      resources:
        limits:
          memory: 320M

networks:
  frontend:
    driver: bridge
  backend:
    driver: bridge
    internal: true   # Internet erisimi yok, sadece icteki container'lar

volumes:
  wp-content:
  mariadb-data:
  traefik-letsencrypt:

secrets:
  wp_db_password:
    file: ./secrets/wp_db_password.txt
  db_root_password:
    file: ./secrets/db_root_password.txt

Çalıştırma:

# secret dosyalari hazirla
mkdir -p secrets
openssl rand -base64 32 > secrets/wp_db_password.txt
openssl rand -base64 32 > secrets/db_root_password.txt
chmod 600 secrets/*.txt

docker compose up -d
docker compose ps
docker compose logs -f wordpress

Compose Best Practice'leri

name: üst seviyede: docker compose -p yerine deterministik proje adı.
secrets:: env'de plain text DB şifresi yerine secret file mount. Process listesinde görünmez, image katmanına yazılmaz.
healthcheck:: depends_on: condition: service_healthy ile zincirli başlatma.
networks:: frontend (Traefik <-> WP) ve backend (WP <-> MariaDB) ayrımı. internal: true ile DB sadece internal'da.
deploy.resources: cgroups v2 limit ve reservation. OOM'u öngörülebilir kılar.
restart: unless-stopped: VDS reboot'tan sonra otomatik başlama.

Docker Network Tipleri

Driver	Kullanım	Notlar
bridge	Default, tek host container'lar	Linux bridge `docker0`. NAT ile dış.
host	Container, host network stack'i kullanır	Performans yüksek, izolasyon yok. `--network host`.
none	Network yok	Sadece localhost. Highly isolated batch için.
overlay	Multi-host (Swarm)	VXLAN encapsulation. Swarm/k8s.
macvlan	Container'a doğrudan MAC + IP	VLAN entegrasyonu, fizik ağa MAC seviyesinde
ipvlan	macvlan benzeri ama L3	Bazı switch'lerde MAC limit aşımı için
custom bridge	İsimli bridge	DNS otomatik. Compose'un kullandığı.

Bridge vs Custom Bridge

# Default bridge (eski, DNS yok)
docker run --network bridge nginx

# Custom bridge (modern, DNS var)
docker network create mynet
docker run --network mynet --name web nginx
docker run --network mynet alpine ping web   # DNS calisir

Modern Docker projeleri her zaman custom bridge (veya Compose'un otomatik yarattığı bridge) kullanır. Default bridge'i sadece tek-shot docker run debug için.

Volume Stratejisi

services:
  app:
    volumes:
      # Named volume (production prefer)
      - data:/var/lib/mydata

      # Bind mount (dev tercihi)
      - ./config:/etc/myapp:ro

      # tmpfs (RAM, ephemeral)
      - type: tmpfs
        target: /tmp
        tmpfs:
          size: 100m

      # NFS volume (multi-host)
      - type: volume
        source: nfs-data
        target: /shared
volumes:
  data:
  nfs-data:
    driver: local
    driver_opts:
      type: nfs
      o: addr=10.0.0.5,rw,nfsvers=4
      device: ":/exports/data"

Volume Backup

Klasik trick:

docker run --rm \
  -v mariadb-data:/data:ro \
  -v \${PWD}/backup:/backup \
  busybox \
  tar czf /backup/mariadb-\$(date +%F).tar.gz -C /data .

VDS host seviyesinde günlük Veeam yedek zaten alınıyor (Buyukweb dahili), bu ek bir restore noktası.

Production Deploy Patterns: Single-Host vs Cluster

Pattern 1: Single-Host Compose (Buyukweb VDS Tipik)

Senaryo: Tek VDS'te 5-15 container, 50-500 concurrent kullanıcı, 1-2 milyon istek/gün.

Mimari: Tek VDS + Compose stack + Traefik reverse proxy + LetsEncrypt + Watchtower (otomatik update).

[Internet]
    |
[Cloudflare CDN] (opsiyonel)
    |
[Buyukweb VDS DDoS koruma]
    |
[Traefik :443] -> [WordPress] -> [MariaDB]
              -> [API service]    -> [Redis]
              -> [Static site]

Avantajlar: basit, tek faturalama, tek SLA, network round-trip sıfır.
Dezavantajlar: tek SPOF (Single Point of Failure), dikey ölçekleme limiti.

Pattern 2: Docker Swarm (Yerlesik Orchestration)

Docker Engine'in dahili cluster modu. Komut: docker swarm init.

# Master (manager) node
docker swarm init --advertise-addr 195.85.100.52

# Worker node ekleme
docker swarm join --token SWMTKN-1-xxxxx 195.85.100.52:2377

# Stack deploy
docker stack deploy -c docker-compose.yml mystack

# Service scale
docker service scale mystack_web=3

Swarm özellikleri:

Compose Spec'i docker stack ile direkt deploy
Built-in load balancer (ingress routing mesh)
Secrets (docker secret) ve Configs (docker config)
Rolling update, health check, rollback
Overlay network (VXLAN encrypted)
Manager-worker model (manager 1, 3 veya 5 — Raft quorum)

Ne Zaman Swarm?: 2-5 VDS arası dağıtım, basit cluster ihtiyacı, Compose Spec'i değiştirmek istemiyorsanız. Kubernetes öğrenme eğrisinden kaçınmak isteyen ekipler için ideal "yumuşak orchestration".

Pattern 3: Kubernetes (k3s/k0s veya Tam)

Kubernetes, Docker Swarm'dan çok daha kapsamlı bir orchestration sistemidir. YÖNETİLEN BİR KUBERNETES SERVİSİ BUYUKWEB'DE YOKTUR; ancak VDS sunucularımızda self-host k3s veya k0s kurulumu yapabilirsiniz.

k3s (Rancher Labs): Hafif Kubernetes distribütörü. Tek binary, etcd yerine SQLite, ARM uyumlu.

# Master
curl -sfL https://get.k3s.io | sh -

# Token
cat /var/lib/rancher/k3s/server/node-token

# Worker
curl -sfL https://get.k3s.io | \
  K3S_URL=https://master.sirket.com.tr:6443 \
  K3S_TOKEN=xxxxx sh -

# kubectl
export KUBECONFIG=/etc/rancher/k3s/k3s.yaml
kubectl get nodes

k0s (Mirantis): k3s'e benzer, biraz daha modüler.

Tam Kubernetes (kubeadm ile): Production cluster, 3+ master node, 3+ worker, etcd HA. VDS'ler arası önerilir, ancak self-host bakım yükü Swarm'a göre çok daha ağırdır.

Ne Zaman Kubernetes?: 10+ VDS dağıtım, CI/CD pipeline tam otomatik, geliştirici ekibi 10+, kurumsal compliance (SOC 2, PCI-DSS).

Sysctl Tuning: Docker Icin Kritik Parametreler

VDS'te /etc/sysctl.d/99-docker.conf altına:

# Container'lar arasi paket routing (Docker bunu zaten aktif eder
# ama explicit yazmak good practice)
net.ipv4.ip_forward = 1
net.ipv6.conf.all.forwarding = 1

# Yuksek concurrent connection
net.ipv4.tcp_max_syn_backlog = 8192
net.core.somaxconn = 65535
net.core.netdev_max_backlog = 16384

# Connection tracking (NAT icin)
net.netfilter.nf_conntrack_max = 1000000
net.netfilter.nf_conntrack_tcp_timeout_established = 86400

# Swap minimum (container performans icin)
vm.swappiness = 10

# File descriptor limit
fs.file-max = 2097152
fs.nr_open = 2097152

# Inotify (Docker daemon icin)
fs.inotify.max_user_watches = 524288
fs.inotify.max_user_instances = 512

# Container port range (eger yuksek-yogunluk kullaniyorsaniz)
net.ipv4.ip_local_port_range = 1024 65535

Uygula:

sysctl --system

Monitoring: cAdvisor + Prometheus + Grafana + Portainer

cAdvisor (Container Metric)

services:
  cadvisor:
    image: gcr.io/cadvisor/cadvisor:v0.49.1
    restart: unless-stopped
    ports:
      - "127.0.0.1:8080:8080"
    volumes:
      - /:/rootfs:ro
      - /var/run:/var/run:ro
      - /sys:/sys:ro
      - /var/lib/docker/:/var/lib/docker:ro
      - /dev/disk/:/dev/disk:ro
    devices:
      - /dev/kmsg
    privileged: true

Endpoint: http://127.0.0.1:8080/metrics — Prometheus formatı.

Prometheus + Grafana

Self-host Prometheus + Grafana stack, Linux sunucu izleme yazımızda detaylı. Buyukweb VDS'inizde Compose ile 10 dakikada kurulur. Grafana dashboard docker monitoring import edip kullanmaya başlayabilirsiniz.

Portainer (Web UI)

services:
  portainer:
    image: portainer/portainer-ce:2.21.0
    restart: unless-stopped
    ports:
      - "127.0.0.1:9443:9443"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - portainer-data:/data
volumes:
  portainer-data:

Traefik label'ı ekleyip portainer.sirket.com.tr üzerinden TLS ile açabilirsiniz. Container listeleme, log görüntüleme, image yönetimi, volume backup, stack deploy hepsi UI üzerinden.

ctop (CLI top)

docker run --rm -ti \
  --name ctop \
  --volume /var/run/docker.sock:/var/run/docker.sock:ro \
  quay.io/vektorlab/ctop:latest

Container'lara htop benzeri canlı görünüm. SSH terminalde hızlı durum kontrol için ideal.

Security: Production Onlem Listesi

1. Image Scan: Trivy

# Trivy install (binary)
curl -sfL https://raw.githubusercontent.com/aquasecurity/trivy/main/contrib/install.sh \
  | sh -s -- -b /usr/local/bin

# Image scan
trivy image myorg/myapp:v1.0.0

# Sadece HIGH ve CRITICAL CVE
trivy image --severity HIGH,CRITICAL myorg/myapp:v1.0.0

# CI'da exit code ile fail
trivy image --exit-code 1 --severity CRITICAL myorg/myapp:v1.0.0

Trivy alternatifi Grype (Anchore) — benzer hız, biraz farklı CVE DB. CI pipeline'a her image build sonrası ekleyin.

2. Docker Bench for Security

docker run --rm --net host --pid host --userns host --cap-add audit_control \
  -e DOCKER_CONTENT_TRUST=\${DOCKER_CONTENT_TRUST} \
  -v /etc:/etc:ro \
  -v /usr/bin/containerd:/usr/bin/containerd:ro \
  -v /usr/bin/runc:/usr/bin/runc:ro \
  -v /usr/lib/systemd:/usr/lib/systemd:ro \
  -v /var/lib:/var/lib:ro \
  -v /var/run/docker.sock:/var/run/docker.sock:ro \
  --label docker_bench_security \
  docker/docker-bench-security

CIS Docker Benchmark testlerini çalıştırır. 5-7 dakikada Pass/Warn/Fail raporu.

3. Docker Socket Guvenligi

/var/run/docker.sock = root erişim. Aşağıdaki tehlikeli mount kesinlikle yapılmamalı:

# YANLIS - container'a host'ta root yetkisi verir
services:
  badapp:
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock

Eğer container'ın Docker'a komut göndermesi şart ise (CI runner, Portainer):

socket-proxy container ile sadece read-only veya sınırlı endpoint expose et
Traefik gibi etiket okuyan servisler için socket read-only mount yeterli (:ro)
Mümkünse rootless Docker ile socket yetki kapsamını sınırla

4. Read-Only Root Filesystem

services:
  app:
    read_only: true
    tmpfs:
      - /tmp
      - /run
    volumes:
      - app-data:/var/lib/app

Container'ın çoğu dizini read-only olur, sadece data volume yazılır. Compromise olsa bile malware persistence imkanı düşük.

5. Capability Drop + No-New-Privileges

services:
  app:
    cap_drop:
      - ALL
    cap_add:
      - NET_BIND_SERVICE   # sadece 80/443 bind icin
    security_opt:
      - no-new-privileges:true
      - seccomp:default
      - apparmor:docker-default

6. User Namespace Remap

/etc/docker/daemon.json içinde "userns-remap": "default". Container içinde root, host'ta yüksek UID (231072+) ile çalışır.

/etc/subuid ve /etc/subgid dosyaları otomatik üretilir:

dockremap:231072:65536

Container escape olsa bile host'ta normal kullanıcı yetkisi vardır, root değil.

7. Falco (Runtime Detection)

Falco container runtime'da anormal davranış tespiti:

Container içinde shell açılması
Hassas dosya okunması (/etc/shadow)
Beklenmedik network bağlantısı
Privilege escalation girişimi

Production'da kurulum biraz emek alır ama yatırımına değer. SIEM ile entegrasyon ile incident response süresi düşer.

Buyukweb VDS Docker Karar Matrisi

Senaryo	Önerilen Plan	Mimari
Tek WordPress + DB (KOBİ)	VDS Başlangıç — 2 vCPU, 4 GB RAM	Compose: nginx + php-fpm + MariaDB
Çoklu WordPress (3-5 site)	VDS Performans — 4 vCPU, 8 GB	Compose: traefik + wp x3 + maria + redis
Headless CMS + API	VDS Performans — 4 vCPU, 8 GB	Compose: api + db + redis + cache
Microservice (5-10 container)	VDS Premium — 6-8 vCPU, 16 GB	Compose: traefik + 8 servis + prometheus
Kurumsal (10+ servis)	2x VDS + Swarm	Manager + Worker, Compose stack
Yüksek erişilebilirlik	3x VDS + Swarm/k3s	HA cluster, geo redundancy
50+ container, dinamik scale	Dedicated Sunucu + k3s/k8s	Full cluster, GitOps

Karar Sorulari (Kontrol Listesi)

Toplam container sayısı 15'in altında mı?
Trafik 1 milyon istek/gün altında mı?
Geliştirici ekibi 1-3 kişi mi?
CI/CD pipeline manuel ya da basit otomatik mi?
99.9% (8 saat/yıl downtime) yeterli mi?

Tümü Evet → Tek VDS + Compose yeterli.

Container sayısı 15-50 mi?
Trafik 5-20 milyon istek/gün mi?
Ekip 3-10 kişi mi?
99.95% (4 saat/yıl) gerekiyor mu?

Tümü Evet → 2-3x VDS + Docker Swarm öneriyoruz.

Container sayısı 50+?
Trafik 50+ milyon istek/gün?
Ekip 10+ kişi?
Tam GitOps + Helm + ArgoCD ihtiyacı?
99.99% (53 dakika/yıl) gerekiyor mu?

Tümü Evet → Dedicated Sunucu cluster + k3s/k8s. Buyukweb satış ekibimiz ile karar matrisini görüşelim.

CI/CD Entegrasyonu (Yuzeysel)

Docker image build + push + deploy zinciri için tipik araçlar (self-host):

Araç	Tip	Özellik
Gitea Actions	Git server + CI	Self-host, hafif
Forgejo Actions	Gitea fork, community	Self-host
Drone CI	Container-native CI	YAML pipeline
Woodpecker CI	Drone fork	Hafif
Concourse CI	Pipeline tabanlı	Karmaşık ama güçlü
Jenkins	Klasik	Plugin ekosistemi geniş

Buyukweb VDS'te Gitea + Drone kombinasyonu popüler: tek VDS'te Git + CI + private registry. Push → build → test → push image → ssh deploy → docker compose pull && up -d zinciri 5-10 dakikada tamamlanır.

10 Yaygin Hata

latest tag prod'a deploy: Pin a specific version (v1.0.0 veya sha digest).
Root user container'da: USER appuser Dockerfile'a ekleyin.
Secret env var'da: Compose secrets veya secret file mount kullanın.
Default json-file log driver: max-size 10m max-file 5 ekleyin, yoksa disk dolar.
Image layer şişmiş: Multi-stage build + .dockerignore.
Restart policy yok: restart: unless-stopped her servise.
Healthcheck yok: Compose'da condition: service_healthy çalışmaz.
--network host abuse: İzolasyon kaybı, sadece zorunlu durumda.
EXPOSE vs ports karışıklığı: EXPOSE sadece dokümantasyon, port mapping için ports: veya Traefik label.
NTP/saat senkron yok: TLS sertifika doğrulama ve log timestamp için chronyd veya systemd-timesyncd aktif olmalı.

Sik Sorulan Sorular

"cPanel'de Docker var mi?"

Hayır. cPanel paylaşımlı hosting paketleri, kernel namespace + cgroups + iptables manipülasyonu gerektiren Docker daemon'ı çalıştıramaz. cPanel sunucu yöneticisi Docker kullanabilir ama kullanıcı izolasyonu açısından son kullanıcıya açılmaz. Docker için VDS veya Dedicated Sunucu gereklidir.

"Paylasimli hostingte Docker olur mu?"

Olmaz. Paylaşımlı hosting cgroups namespace seviyesinde izolasyon sunar ama kullanıcıya root yetkisi vermez. Docker ise root yetkisi ister. Paylaşımlı hosting müşterisi kendi container'ını çalıştıramaz.

"Tek VDS'te tum projelerimi mi calistirayim?"

5-15 container, 1-2 milyon istek/gün'e kadar tek VDS yeterli. Üzerinde scale-up (VDS planını büyüt) veya scale-out (Docker Swarm ile 2-3 VDS) düşünün.

"Kubernetes mi Swarm mi?"

Swarm: Compose-uyumlu, Docker'da built-in, öğrenme eğrisi düşük, 2-10 node ölçeğinde mükemmel. Kubernetes: kurumsal ekosistem, Helm/ArgoCD/Istio entegre, 10+ node + uzman ekip gerektirir. Buyukweb VDS müşterilerinin %80'i için Swarm yeterli.

"Docker Compose'un v1 ve v2 farki nedir?"

v1 Python tabanlı standalone docker-compose komutu (deprecated). v2 Go tabanlı docker compose plugin (resmi). Yeni proje için her zaman v2. Compose dosya formatı uyumlu, sadece komut farklı.

"Docker icin minimum kac GB RAM lazim?"

Docker daemon kendisi 100-200 MB. Container'lar workload'a göre değişir. Tipik bir LEMP stack (nginx + php-fpm + MariaDB + redis) 1-2 GB RAM ile çalışır. Buyukweb VDS Başlangıç planı 2 vCPU + 4 GB RAM Docker'ı denemeye ideal.

"Docker container'lar arasinda nasil iletisim?"

Aynı Compose stack'ında servis adı ile (http://api:3000). Farklı stack'lar arası docker network connect ile aynı network'e ekle, sonra servis adı kullan.

"VDS reboot olunca container'larim baslar mi?"

Eğer restart: unless-stopped veya restart: always policy varsa otomatik başlar. docker compose ps ile durum kontrol edebilirsiniz.

Sonuc ve Sonraki Adimlar

Docker, modern web uygulamasının deploy modeline çoktan dönüşmüş durumda. VDS Docker çalıştırmak için tek doğru ölçektir: KVM tam sanallaştırma + virtio I/O paravirtualization native performans verir, root erişim daemon.json + sysctl + kernel modül yönetimini açar, dedicated kaynak (CPU/RAM/disk) cgroups limit'lerinin gerçek anlam kazanmasını sağlar. Paylaşımlı hosting bu kontrolü vermez; cPanel/Plesk kullanıcılarına Docker önerilmez.

Production Docker stack'i için tek formül yok ama temel kurallar var: daemon.json'da log driver max-size 10m max-file 5, live-restore: true, userns-remap: default, icc: false, no-new-privileges: true. Container'larda her zaman non-root user, read-only root FS, cap_drop ALL + cap_add minimum. Compose'da secrets kullan, env'de plain text DB şifresi tutma. Image'da multi-stage build + .dockerignore ile boyutu kucult. CI'da Trivy veya Grype ile vulnerability scan, deploy öncesi Docker Bench for Security raporu.

Buyukweb VDS sunucularımızda KVM + virtio + root erişim + Bursa Tier 3 datacenter + DDoS koruma + günlük Veeam yedek + 17+ yıl deneyim ile Docker stack'inizi güvenle çalıştırabilirsiniz. Karar matrisinde 5-15 container, 1-2M istek/gün altında tek VDS + Compose yeterli; üzerinde Docker Swarm cluster veya gelişmiş ihtiyaç için k3s self-host.

Ilgili Buyukweb Hizmetleri

VDS Sunucu — KVM tam sanallaştırma, root erişim, Docker için ideal platform
Dedicated Sunucu — 50+ container, cluster, k8s self-host için
Docker ile Web Uygulaması Deploy — Dockerfile, multi-stage, Compose, Traefik detay
Linux Sunucu İzleme — Prometheus + Grafana + Node Exporter kurulum
VDS Sunucu Güvenliği — Firewall, SSH key, Fail2Ban, sysctl hardening

VDS Docker kurulumu, Compose stack tasarımı, Swarm cluster mimarisi veya production güvenlik denetimi için 0850 302 60 70 numaralı destek hattımıza veya iletişim sayfamıza yazabilirsiniz. Bursa Tier 3 veri merkezimizden KVM tam sanallaştırmalı VDS sunucuları ile Docker stack'iniz native performansa yakın çalışır.