VPS'te Docker: nereden başlamalı

Konteyner, tüm kütüphaneleri ve ayarlarıyla birlikte bir imaja paketlenmiş bir uygulamadır. Sunucuda tek komutla başlatılır ve her Linux'ta aynı şekilde çalışır. VPS açısından bu şu anlama gelir: Python, Node.js veya PostgreSQL sürümlerini sisteme göre ayarlamak gerekmez, birkaç proje aynı sunucuda sorunsuz bir arada yaşar ve compose.yaml dosyası tüm hizmet setini, yeni bir sunucuda dakikalar içinde ayağa kaldırılabilecek şekilde tanımlar.

Docker için nasıl bir VPS gerekir

Sanallaştırma: KVM. Docker, Linux çekirdeğinin olanaklarını kullanır: ad alanları (namespaces), cgroups, kendi ağ kuralları. KVM'de sunucunun kendi çekirdeği vardır ve Docker kısıtlamasız çalışır. OpenVZ ve LXC'de çekirdek diğer müşterilerle ortaktır; Docker orada ya hiç başlamaz ya da sağlayıcıya bağlı kısıtlamalarla çalışır. Ayrıntılar KVM mi, OpenVZ mi yazısında.

Bellek ve çekirdekler. Docker'ın kendisi az yer kaplar, belleği konteynerler tüketir. Başlangıç değerleri:

• 1 GB — bir iki hafif konteyner: bot, küçük bir API, izleme;
• 2 çekirdek ve 2 GB — veritabanlı ve ters vekil sunuculu bir site, birkaç küçük hizmet;
• 2–4 çekirdek ve 4 GB — birkaç proje, PostgreSQL, Redis, imajların doğrudan sunucuda derlenmesi;
• 8 GB ve üzeri — GitLab, çok sayıda iş akışı olan n8n, Elasticsearch ve diğer ağır hizmetler.

Disk. İmajlar yer kaplar: Python veya Node.js içeren bir temel imaj yüzlerce megabayttır ve her güncellemede eski sürümler birikir. NVMe üzerinde en az 30 GB alın, imajları sunucuda derleyecekseniz daha fazla.

1 Kasım 2026 tarihli accsly kataloğuna göre 2 çekirdek ve 2 GB bellekli bir KVM paketinin piyasa ortancası ayda yaklaşık 15 dolar, bu paketlerin dörtte biri 9 dolardan ucuz. 2 çekirdek ve 4 GB için ortanca yaklaşık 20 dolar, dörtte biri 12 dolardan ucuz. Katalog fiyatları rubleyle tutulduğu için tutarlar yuvarlanmış yaklaşık değerlerdir. Seçkiler: Docker için VPS, KVM VPS, 4 GB VPS. Denemek için saatlik faturalama kullanışlıdır: bir akşamlık sunucu birkaç sente mal olur.

Kurulumdan önce

Temiz bir Ubuntu 22.04 veya 24.04 LTS ya da Debian 12 alın ve önce temel korumayı yapın: güncellemeler, anahtarla giriş, ayrı bir kullanıcı, güvenlik duvarı. Hepsi VPS satın aldıktan sonra ilk 10 adım yazısında. Konteynerli bir sunucuda site kontrol paneline genellikle gerek yoktur; nedeni Sunucu kontrol panelleri yazısında.

Resmi depodan kurulum

Ubuntu deposundaki docker.io paketi çoğu zaman güncel sürümün gerisinde kalır ve her zaman Compose içermez. Docker'ın kendi deposundan kurmak daha güvenilirdir. Resmi belgelere göre Ubuntu için komutlar:

sudo apt update
sudo apt install ca-certificates curl
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc

sudo tee /etc/apt/sources.list.d/docker.sources <<EOF
Types: deb
URIs: https://download.docker.com/linux/ubuntu
Suites: $(. /etc/os-release && echo "${UBUNTU_CODENAME:-$VERSION_CODENAME}")
Components: stable
Architectures: $(dpkg --print-architecture)
Signed-By: /etc/apt/keyrings/docker.asc
EOF

sudo apt update
sudo apt install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

Debian için komutlar aynıdır; yalnızca adreslerdeki linux/ubuntu yerine linux/debian yazılır ve UBUNTU_CODENAME yerine VERSION_CODENAME kullanılır. Kurulumu kontrol edin:

sudo docker run hello-world
docker compose version

get.docker.com adresinde tek komutlu bir kurulum aracı da var, ancak Docker'ın kendi belgeleri onu üretim sunucuları için önermiyor: onay istemeden çok sayıda paket kurar ve her zaman en son sürümü alır.

docker grubu. Her komutun önüne sudo yazmamak için kullanıcı docker grubuna eklenir: sudo usermod -aG docker $USER, ardından oturumu kapatıp yeniden açın. Bunun root yetkisi demek olduğunu unutmayın: grubun bir üyesi, sunucunun tüm dosya sistemine erişimi olan bir konteyner başlatabilir. Gruba yalnızca kendi çalışma hesabınızı ekleyin.

Docker Compose ile ilk proje

Onlarca parametreli ayrı docker run komutları çabuk unutulur. Projeyi ayrı bir klasördeki, örneğin /opt/app içindeki compose.yaml dosyasında tanımlamak daha kullanışlıdır. Örnek: PostgreSQL veritabanlı bir web uygulaması:

services:
  app:
    image: ghcr.io/example/app:1.4.2
    restart: unless-stopped
    environment:
      DATABASE_URL: postgres://app:${DB_PASSWORD}@db:5432/app
    ports:
      - "127.0.0.1:8080:8080"
    depends_on:
      - db
  db:
    image: postgres:16
    restart: unless-stopped
    environment:
      POSTGRES_USER: app
      POSTGRES_PASSWORD: ${DB_PASSWORD}
    volumes:
      - db-data:/var/lib/postgresql/data

volumes:
  db-data:

Parolayı yanına, DB_PASSWORD=... satırını içeren bir .env dosyasına koyun ve diğer kullanıcıların okumasını kapatın: chmod 600 .env. Başlatma: docker compose up -d, log: docker compose logs -f app, durdurma: docker compose down.

Bu örnekte üç şey önemli:

• restart: unless-stopped — konteynerler sunucu yeniden başladıktan sonra ayağa kalkar;
• veritabanının ports bölümü yok: uygulama onu projenin iç ağında db adıyla görür, dışarıdan ise erişilemez;
• uygulamanın portu yalnızca 127.0.0.1 üzerinde yayımlanmış, dışarıya onu TLS sertifikalı nginx veya Caddy sunuyor.

Portlar ve güvenlik duvarı

Yeni başlayanlar için en büyük tuzak budur. Bir konteyner portu "5432:5432" olarak yayımladığında Docker kendi iptables kurallarını ekler ve bu port ufw veya firewalld kurallarından bağımsız olarak dışarıya açılır. Docker belgeleri bu konuda açıkça uyarır: yayımlanan konteyner portları güvenlik duvarı kurallarına tabi olmaz. PostgreSQL, MongoDB ve Redis veritabanları parolasız olarak internete en sık bu şekilde açılır.

Kural basit: dışarıya yalnızca herkesin erişmesi gerekenleri yayımlayın; genellikle ters vekil sunucunun 80 ve 443 portları. Geri kalanlar ya ports bölümü olmadan ya da 127.0.0.1 adresine bağlanarak çalışmalı. Sunucunun gerçekte neyi dinlediğini ss -tlnp komutuyla, dışarıdan ise başka bir bilgisayardan nc -zv SUNUCU-IP 5432 komutuyla kontrol edebilirsiniz.

Loglar ve disk alanı

Docker varsayılan olarak konteynerlerin çıktısını boyut sınırı olmadan JSON dosyalarına yazar. Çok log üreten bir uygulama birkaç ayda diski doldurur ve sunucu durur. Tüm konteynerler için logları /etc/docker/daemon.json dosyasında sınırlayın:

{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  }
}

Ardından sudo systemctl restart docker. Bu ayar yalnızca sonradan oluşturulan konteynerlere uygulanır, bu yüzden projeleri yeniden oluşturun: docker compose up -d --force-recreate.

Disk alanını tüketen ikinci şey eski imajlardır. Ne kadar yer kaplandığını docker system df gösterir, kullanılmayan imajları docker image prune -a siler. docker system prune --volumes komutunu ne yaptığını bilmeden çalıştırmayın: durdurulmuş projelerin birimlerini de verileriyle birlikte siler.

Veriler nerede durur ve nasıl yedeklenir

Uygulamanın konteyner içine yazdığı her şey, konteyner yeniden oluşturulduğunda kaybolur. Yalnızca birimlerde (volumes) veya bağlanmış sunucu klasörlerinde duranlar korunur. Herhangi bir imajı çalıştırmadan önce belgelerinde hangi klasörlerin birime alınması gerektiğine bakın: PostgreSQL için bu /var/lib/postgresql/data, diğer uygulamalar için kendi yollarıdır.

Veritabanı dosyalarını çalışırken kopyalamak güvenilir değildir. Dökümü konteynerin kendisi üzerinden alın:

docker compose exec -T db pg_dump -U app app | gzip > /backup/app-$(date +%F).sql.gz

Bu komutu cron'a ekleyin ve yedekleri compose.yaml ve .env ile birlikte sunucunun dışına gönderin. Harici depolamanın ve yedek kontrolünün nasıl kurulacağı VPS yedekleri yazısında.

Konteynerlerin güncellenmesi

compose.yaml içinde latest yerine imajın belirli bir sürümünü yazın (postgres:16, app:1.4.2): böylece güncelleme rastgele bir yeniden başlatmada değil, sizin planladığınız zaman gerçekleşir. Güncelleme sırası:

1. veritabanının dökümünü alın;
2. compose.yaml içindeki sürümü değiştirin;
3. docker compose pull ve docker compose up -d;
4. logu ve uygulamanın çalışmasını kontrol edin, ardından eski imajı silin.

Veritabanlarının ana sürümleri, örneğin PostgreSQL 16 → 17, bu şekilde güncellenmez: yeni sürüm, verilerin döküm alıp yükleyerek taşınmasını gerektirir. Sunucunun sistemini ve Docker'ın kendisini olağan apt upgrade ile güncelleyin.

Sonraki adımlar

Sunucuda birkaç proje olduğunda sertifikaları kendisi alan bir ters vekil sunucu ve erişilebilirlik izleme kurmak işinizi kolaylaştırır. Konteynerde çalışan Python veya Node.js botu için küçük bir sunucu yeterlidir; ayrıntılar Telegram botu için VPS yazısında. Konteyner sayısı artar ve tek sunucu yetmez hale gelirse sonraki adım bir orkestratör altında birkaç sunucudur; paketler Kubernetes için VPS seçkisinde. Konteynerlerde otomasyon ve CI için n8n için VPS ve GitLab için VPS seçkileri var.