Docker Ubuntu’da: Eksiksiz Kurulum ve Kullanım Kılavuzu

Docker, uygulamaları ve bağımlılıklarını konteyner adı verilen izole, taşınabilir birimlere paketleyen açık kaynaklı bir konteynerleştirme platformudur. Sanal makinelerin aksine, konteynerler ana işletim sistemi çekirdeğini paylaşır; bu da onları önemli ölçüde daha hafif, daha hızlı başlatılabilir ve daha kaynak verimli kılar — hesaplama kaynaklarının maliyet ve performansı doğrudan etkilediği bir VPS Hosting ortamında iş yükü çalıştıran herkes için kritik bir ayrımdır.

Bu kılavuz, Ubuntu 20.04, 22.04 ve 24.04 LTS üzerinde kurulum sonrası sertleştirme, Docker Compose iş akışları ve çoğu öğreticinin atladığı üretime yönelik komut kalıpları dahil olmak üzere tam Docker kurulum sürecini kapsamaktadır.

Ön Koşullar ve Sistem Gereksinimleri

Tek bir komut çalıştırmadan önce aşağıdakileri doğrulayın:

• Ubuntu sürümü: 20.04 LTS (Focal), 22.04 LTS (Jammy) veya 24.04 LTS (Noble). Depo kurulumu sırasında kullanılan `lsb_release -cs` komutu, kod adınızı otomatik olarak algılayacaktır.
• Mimari: `amd64`, `arm64` veya `armhf`’nin tamamı Docker’ın resmi deposu tarafından desteklenmektedir.
• Çekirdek sürümü: Docker, Linux çekirdek 3.10 veya üzerini gerektirir. Doğrulamak için `uname -r` komutunu çalıştırın.
• Kullanıcı ayrıcalıkları: Kurulum ve daemon yönetimi için `sudo` veya root erişimi zorunludur.
• Disk alanı: Docker’ın imajları, konteynerleri, hacimleri ve derleme önbelleğini depoladığı `/var/lib/docker` bölümünde en az 2 GB boş alan. Üretim sistemlerinde bu dizini ayrı bir bölüme veya hacme bağlayın.

Kritik kurulum öncesi adım: Daha önce Ubuntu’nun varsayılan `apt` deposundan Docker kurduysanız (`docker.io` paketi), resmi Docker CE paketleriyle çakışmaları önlemek için önce onu kaldırın:

“`bash

sudo apt remove docker docker-engine docker.io containerd runc

“`

Adım 1: Sistem Paketlerini Güncelleyin

Yeni bir depo eklemeden önce paket dizinini ve yüklü paketleri en son sürümlerine getirin:

“`bash

sudo apt update

sudo apt upgrade -y

“`

Bu, `apt`’ın bağımlılık çözücüsünün güncel paket meta verileriyle çalışmasını sağlar ve temel sistem kitaplıklarınızın güncel olmamasını önler — bu, konteynerleştirilmiş uygulamalarda ince çalışma zamanı hatalarının yaygın bir kaynağıdır.

Adım 2: Resmi Depodan Docker Engine Kurulumu

Ubuntu’nun varsayılan `apt` depoları, Canonical tarafından sürdürülen ve genellikle Docker’ın resmi sürümünün birkaç versiyon gerisinde kalan `docker.io` adlı bir paket içerir. Üretim kullanımı için her zaman Docker’ın kendi deposundan yükleyin.

2.1 Aktarım ve Doğrulama Bağımlılıklarını Yükleyin

“`bash

sudo apt install apt-transport-https ca-certificates curl software-properties-common gnupg lsb-release -y

“`

Neden `gnupg`? Ubuntu 22.04’ten itibaren `gpg` her zaman varsayılan olarak mevcut değildir. Açıkça dahil etmek, GPG anahtarı içe aktarımının sessizce başarısız olmasını önler.

2.2 Docker’ın Resmi GPG Anahtarını Ekleyin

“`bash

sudo install -m 0755 -d /usr/share/keyrings

curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg –dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg

sudo chmod a+r /usr/share/keyrings/docker-archive-keyring.gpg

“`

`chmod a+r` adımı öğreticilerde sıklıkla atlanır, ancak `apt`’ın kısıtlı bir kullanıcı bağlamında çalıştığı sistemlerde gereklidir — bu olmadan, paket yöneticisi anahtar halkasını okuyamaz ve `apt update` sırasında `NO_PUBKEY` hatası verir.

2.3 Docker Kararlı Deposunu Ekleyin

“`bash

echo

"deb [arch=$(dpkg –print-architecture) signed-by=/usr/share/keyrings/docker-archive-keyring.gpg]

https://download.docker.com/linux/ubuntu

$(lsb_release -cs) stable" |

sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

“`

`arch=$(dpkg –print-architecture)` değişikliği, ARM tabanlı sunucularda önemlidir. Buraya `amd64` sabit kodlamak, ARM örneklerinde sessiz paket çözümleme hatalarına neden olan yaygın bir hatadır.

2.4 Docker Engine, CLI ve Eklentileri Yükleyin

“`bash

sudo apt update

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

“`

Paket dökümü:

`containerd.io` hakkında not: Bu, Ubuntu’nun varsayılan deposundaki `containerd` paketiyle aynı değildir. Docker’ın `containerd.io`’ı, containerd çalışma zamanının belirli, test edilmiş bir sürümüdür. İkisini karıştırmak, daemon başlatma hatalarının bilinen bir kaynağıdır.

Adım 3: Kurulumu Doğrulayın

Daemon’ın etkin olduğunu ve önyüklemede başlayacak şekilde etkinleştirildiğini onaylayın:

“`bash

sudo systemctl status docker

sudo systemctl enable docker

“`

Yüklü sürümü kontrol edin:

“`bash

sudo docker –version

sudo docker info

“`

`docker info`, tek başına `–version`’dan daha bilgilendiricidir — kullanımdaki depolama sürücüsünü (genellikle `overlay2`), cgroup sürücüsünü (`systemd` ile `cgroupfs`) ve Docker’ın erişebildiği CPU ve bellek miktarını ortaya koyar.

Standart duman testini çalıştırın:

“`bash

sudo docker run hello-world

“`

Başarılı bir çalıştırma, “Hello from Docker!” mesajı yazdırır ve Docker daemon’ının, Docker Hub’dan imaj çekmenin ve konteyner yürütmenin tümünün doğru çalıştığını doğrular.

Adım 4: Root Olmayan Erişim için Docker’ı Yapılandırın

Varsayılan olarak, Docker soketi (`/var/run/docker.sock`) `root` ve `docker` grubu tarafından sahiplenilir. `docker` grubunda olmayan herhangi bir kullanıcı, her Docker komutu için `sudo` kullanmak zorundadır.

“`bash

sudo usermod -aG docker $USER

“`

Oturumu kapatmadan grup üyeliğini uygulayın:

“`bash

newgrp docker

“`

Doğrulayın:

“`bash

docker run hello-world

“`

Güvenlik uyarısı: `docker` grubuna üyelik, pratikte şifresiz `sudo` ile eşdeğerdir. `docker` grubundaki bir kullanıcı, ana dosya sistemini bir konteynere kolayca bağlayabilir ve tüm dosya sistemi düzeyindeki erişim kontrollerinden kaçabilir. Çok kiracılı sistemlerde veya paylaşılan sunucularda bunun yerine rootless Docker kullanmayı düşünün:

“`bash

dockerd-rootless-setuptool.sh install

“`

Rootless modu, Docker daemon’ını ve konteynerlerini ayrıcalıksız bir kullanıcı ad alanı altında çalıştırarak saldırı yüzeyini önemli ölçüde azaltır. Birden fazla kullanıcının aynı ana bilgisayarı paylaştığı herhangi bir ortam için önerilen yapılandırmadır.

Adım 5: Temel Docker Komutları Referansı

İmaj Yönetimi

“`bash

Pull a specific image version from Docker Hub

docker pull nginx:1.27-alpine

List locally cached images

docker images

Remove a specific image

docker rmi nginx:1.27-alpine

Remove all dangling (untagged) images to reclaim disk space

docker image prune

Remove all unused images (not just dangling)

docker image prune -a

“`

Üretim ipucu: Herhangi bir otomatik veya üretim iş akışında `latest` yerine her zaman sürümlü etiketler çekin (örn. `nginx:1.27-alpine`). `latest` etiketi değiştirilebilir — bir kayıt defteri push’undan sonra farklı bir imaja işaret edebilir ve yeniden üretilebilirliği bozabilir.

Konteyner Yaşam Döngüsü

“`bash

Run a container interactively with a pseudo-TTY

docker run -it ubuntu:22.04 /bin/bash

Run a container in detached mode with port mapping and a name

docker run -d -p 8080:80 –name my-nginx nginx:1.27-alpine

List running containers

docker ps

List all containers (including stopped)

docker ps -a

Stop a running container gracefully (SIGTERM, then SIGKILL after timeout)

docker stop my-nginx

Start a stopped container

docker start my-nginx

Remove a stopped container

docker rm my-nginx

Force-remove a running container (sends SIGKILL immediately)

docker rm -f my-nginx

View real-time logs

docker logs -f my-nginx

Execute a command inside a running container

docker exec -it my-nginx /bin/sh

“`

Kaynak ve Sistem İncelemesi

“`bash

Display real-time resource usage statistics

docker stats

Inspect detailed container metadata (JSON)

docker inspect my-nginx

Display disk usage by Docker objects

docker system df

Remove all stopped containers, unused networks, dangling images, and build cache

docker system prune

“`

`docker system prune`, uzun süreli çalışan sunucular için en önemli bakım komutlarından biridir. Periyodik temizlik yapılmadan, Docker’ın derleme önbelleği ve durdurulmuş konteynerleri aktif bir geliştirme veya CI ana bilgisayarında onlarca gigabayt tüketebilir.

Adım 6: Docker Compose — Çok Konteynerli Uygulama Orkestrasyonu

Docker Compose V2 (daha önce yüklenen `docker-compose-plugin`), eski `docker-compose` (tire ile) değil, `docker compose` (boşlukla) olarak çağrılır. Eklenti yüklüyse her iki sözdizimi de çalışır, ancak V2 mevcut standarttır.

6.1 Compose Dosya Yapısını Anlama

Bir proje dizini ve `compose.yml` dosyası oluşturun (Compose V2’de tercih edilen dosya adı; `docker-compose.yml` geriye dönük uyumluluk için desteklenmeye devam etmektedir):

“`bash

mkdir ~/my-web-app && cd ~/my-web-app

nano compose.yml

“`

Nginx ve bir arka uç servisiyle üretime yönelik gerçekçi bir örnek:

“`yaml

services:

web:

image: nginx:1.27-alpine

ports:

• "8080:80"

volumes:

• ./nginx.conf:/etc/nginx/nginx.conf:ro
• ./html:/usr/share/nginx/html:ro

depends_on:

• app

restart: unless-stopped

app:

image: node:20-alpine

working_dir: /usr/src/app

volumes:

• ./app:/usr/src/app

command: node server.js

environment:

• NODE_ENV=production

restart: unless-stopped

“`

Temel Compose direktifleri açıklandı:

• `restart: unless-stopped` — Konteyner, operatör tarafından açıkça durdurulmadıkça bir çökmeden veya sistem yeniden başlatmasından sonra otomatik olarak yeniden başlar. Bu, uzun süreli çalışan servisler için doğru politikadır; `always` kasıtlı olarak durdurulmuş konteynerleri bile yeniden başlatır.
• `depends_on` — Başlatma sırasını kontrol eder, ancak servisin *hazır* olmasını beklemez (örn. bağlantıları kabul eden bir veritabanı). Hazırlık kapısı için `condition: service_healthy` ile birlikte `healthcheck` kullanın.
• `:ro` ile `volumes` — Yapılandırma dosyalarını salt okunur olarak bağlamak, güvenliği ihlal edilmiş bir konteyner sürecinin kendi yapılandırmasını değiştirmesini önler.

6.2 Compose İş Akışı Komutları

“`bash

Start all services in detached mode

docker compose up -d

View logs for all services

docker compose logs -f

View logs for a specific service

docker compose logs -f web

List running Compose services

docker compose ps

Scale a specific service to multiple replicas

docker compose up -d –scale app=3

Stop services without removing containers

docker compose stop

Stop and remove containers, networks, and volumes

docker compose down –volumes

Rebuild images before starting (useful after code changes)

docker compose up -d –build

“`

6.3 Çalışan Servisi Doğrulayın

“`bash

curl -I http://localhost:8080

“`

`200 OK` yanıtı, Nginx’in doğru şekilde hizmet verdiğini onaylar. Uzak bir VPS Hosting örneğinde çalışan servisler için `localhost` yerine sunucunuzun genel IP adresini kullanın ve ilgili portun güvenlik duvarınızda açık olduğundan emin olun (`ufw allow 8080/tcp`).

Adım 7: Docker Ağ Temelleri

Docker’ın ağ modelini anlamak, güvenli bir şekilde iletişim kuran çok konteynerli uygulamalar oluşturmak için gereklidir.

Varsayılan ağ sürücüleri:

Özel bir köprü ağı oluşturma ve kullanma:

“`bash

Create an isolated network

docker network create my-app-network

Run containers attached to the custom network

docker run -d –name db –network my-app-network postgres:16-alpine

docker run -d –name api –network my-app-network my-api-image

Containers on the same custom bridge network can resolve each other by name

Inside 'api', you can connect to 'db' using the hostname 'db'

“`

Özel köprü ağları, konteynerler arasında konteyner adına göre otomatik DNS çözümlemesi sağlar. Varsayılan `bridge` ağı bunu sağlamaz — bu, geliştiricilerin varsayılan ağdaki konteynerlerin birbirlerine ada göre ulaşabileceğini varsayması durumunda bağlantı hatalarına neden olan kritik bir ayrımdır.

Adım 8: Docker Hacimleriyle Kalıcı Veri

Konteynerler tasarım gereği geçicidir. Bir konteynerin dosya sistemi içine yazılan tüm veriler, konteyner kaldırıldığında kaybolur. Kalıcı depolama için hacimler veya bağlama noktaları kullanın.

“`bash

Create a named volume

docker volume create pgdata

Use the volume with a container

docker run -d

–name postgres-db

-e POSTGRES_PASSWORD=securepassword

-v pgdata:/var/lib/postgresql/data

postgres:16-alpine

List volumes

docker volume ls

Inspect a volume (shows mount point on host)

docker volume inspect pgdata

Remove unused volumes

docker volume prune

“`

Hacimler ile bağlama noktaları karşılaştırması:

Adım 9: Docker’ı Güncel Tutma

Docker’ın resmi deposu, güncellemeleri standart `apt` mekanizması aracılığıyla yönetir:

“`bash

sudo apt update

sudo apt upgrade -y

“`

Tüm sistemi yükseltmeden yalnızca Docker ile ilgili paketleri güncellemek için:

“`bash

sudo apt install –only-upgrade docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

“`

Özellikle depolama sürücüsündeki değişiklikler, cgroup sürüm işleme veya mevcut `compose.yml` dosyalarını etkileyebilecek kullanımdan kaldırılmış API sürümleri için büyük sürüm yükseltmelerinden önce Docker sürüm notlarını kontrol edin.

Docker ile Alternatif Konteynerleştirme Yaklaşımları Karşılaştırması

Bare metal üzerinde ölçekli konteynerleştirilmiş iş yükleri çalıştıran ekipler için, bir Dedicated Servers ortamı, konteyner yoğunluğunu ve performansını doğrudan etkileyen çekirdek parametreleri, depolama G/Ç zamanlaması ve ağ yapılandırması üzerinde tam kontrol sağlar.

Üretim Sertleştirme Kontrol Listesi

Docker’ı bir üretim ortamında çalıştırmadan önce aşağıdakileri ele alın:

Daemon yapılandırması (`/etc/docker/daemon.json`):

“`json

{

"log-driver": "json-file",

"log-opts": {

"max-size": "10m",

"max-file": "3"

},

"storage-driver": "overlay2",

"userns-remap": "default",

"live-restore": true,

"no-new-privileges": true

}

“`

• `max-size` ve `max-file` ile `log-opts`: Log rotasyonu olmadan, Docker’ın JSON log dosyaları diskinizi dolduracaktır. Bu, konteynerleştirilmiş ana bilgisayarlarda beklenmedik sunucu kesintilerinin en yaygın nedenlerinden biridir.
• `userns-remap: "default"`: Kullanıcı ad alanı yeniden eşlemesini etkinleştirir, böylece konteyner root’u (UID 0) ana bilgisayarda ayrıcalıksız bir UID ile eşlenir.
• `live-restore: true`: Bir yükseltme sırasında Docker daemon çökerse veya yeniden başlatılırsa konteynerlerin çalışmaya devam etmesine izin verir — sıfır kesinti süreli bakım için kritiktir.
• `no-new-privileges: true`: Konteyner süreçlerinin `setuid` veya `setgid` ikilileri aracılığıyla ek ayrıcalıklar kazanmasını önler.

Ağ ve güvenlik duvarı değerlendirmeleri:

Docker, `iptables`’ı doğrudan değiştirir ve varsayılan olarak `ufw` kurallarını atlar. Yayımlanmış bir porta sahip bir konteyner (`-p 8080:80`), `ufw deny 8080` ayarlanmış olsa bile internetten erişilebilir olacaktır. `ufw` kurallarını Docker’ın `iptables` manipülasyonu üzerinde uygulamak için `daemon.json`’a `"iptables": false` ekleyin ve yönlendirmeyi manuel olarak yönetin ya da açık `ufw` kurallarıyla Docker’ın `–network host`’ını kullanın.

HTTPS sonlandırması gerektiren projeler için, konteynerleştirilmiş uygulamanızı düzgün yapılandırılmış bir ters proxy (Nginx veya Traefik) ve geçerli bir sertifikayla eşleştirin. SSL Certificates, konteynerleştirilmiş bir yığının arkasında çalışan herhangi bir üretim web servisi için ön koşuldur.

İş yükünüz konteynerler içinde makine öğrenimi çıkarımı, model sunumu veya GPU hızlandırmalı veri işlemeyi içeriyorsa, NVIDIA Container Toolkit doğrudan Docker Engine ile entegre olur. GPU Hosting, bu iş yükleri için gerekli temel donanımı sağlar.

Web tabanlı konteyner yönetimiyle birden fazla projeyi yöneten ekipler için, VPS with cPanel, daha basit uygulama yığınları için Docker tabanlı dağıtımları tamamlayabilecek yönetilen bir kontrol paneli ortamı sunar.

Temel Teknik Çıkarımlar ve Karar Matrisi

VPS ile dedicated server üzerinde Docker ne zaman kullanılır:

• Konteyner yoğunluğunun 10–50 konteyner olduğu geliştirme ortamları, hazırlık ve düşük-orta trafikli üretim iş yükleri için VPS kullanın.
• Konteyner yoğunluğu 50 örneği aştığında, öngörülebilir G/Ç performansına ihtiyaç duyduğunuzda (gürültülü komşu etkisi yok) veya iş yükünüz için çekirdek parametre ayarlaması (`sysctl`) gerektiğinde dedicated server kullanın.

Canlıya geçmeden önce operasyonel kontrol listesi:

• `daemon.json`’da log rotasyonunu yapılandırın (`max-size`, `max-file`)
• Konteyner kesintisi olmadan daemon yeniden başlatmalarından kurtulmak için `live-restore`’ı etkinleştirin
• Durumlu servis verileri için bağlama noktaları değil, adlandırılmış hacimler kullanın
• Tüm `compose.yml` dosyalarında imaj sürümlerini sabitleyin — üretimde asla `latest` kullanmayın
• Çok kiracılı ana bilgisayarlarda `userns-remap`’ı etkinleştirin veya rootless Docker çalıştırın
• Güvenlik duvarı politikasının atlanmadığını doğrulamak için Docker kurulumundan sonra `iptables` kurallarını denetleyin
• Tüm uzun süreli çalışan servislerde `restart: unless-stopped`’ı ayarlayın
• Disk tükenmesini önlemek için zamanlanmış bir cron işinde `docker system prune`’ı çalıştırın
• Tüm konteynerler arası iletişim için özel köprü ağları kullanın — servis keşfi için asla varsayılan köprüye güvenmeyin

SSS

Ubuntu’daki Docker varsayılan olarak cgroup sürücüsü olarak `systemd` mı yoksa `cgroupfs` mı kullanır?

Docker Engine 20.10’dan itibaren, `systemd` tabanlı sistemlerdeki (tüm modern Ubuntu LTS sürümleri dahil) varsayılan cgroup sürücüsü `systemd`’dır. Bu, Kubernetes gereksinimleriyle uyumludur ve iki cgroup yöneticisini aynı anda çalıştırmanın neden olduğu kararsızlıktan kaçınır. `docker info | grep -i cgroup` ile doğrulayabilirsiniz.

`docker compose down` ile `docker compose stop` arasındaki fark nedir?

`docker compose stop`, çalışan konteynerleri durdurur ancak onları ve ilişkili ağlarını korur. `docker compose down`, konteynerleri durdurur ve ardından Compose’un oluşturduğu ağlarla birlikte onları kaldırır. `down`’a `–volumes` eklemek, Compose dosyasında tanımlanan adlandırılmış hacimleri de kaldırır — bu bayrak üretimde dikkatli kullanılmalıdır, çünkü kalıcı verileri kalıcı olarak siler.

Docker neden Ubuntu’da `ufw` güvenlik duvarı kurallarını atlar?

Docker, `ufw`’ın `INPUT` zincir kurallarından önce değerlendirilen `DOCKER` ve `DOCKER-USER` zincirlerine kendi `iptables` kurallarını ekler. Bu, `-p` ile yayımlanan bir portun `ufw` politikasından bağımsız olarak internetten erişilebilir olduğu anlamına gelir. Doğru çözüm, `DOCKER-USER` zincirine doğrudan kural eklemek veya dış erişim gerekmediğinde yayımlanan portları belirli bir arayüze bağlamaktır (örn. `-p 127.0.0.1:8080:80`).

Bir Docker konteynerinin tüketebileceği CPU ve belleği nasıl sınırlandırırım?

Çalışma zamanında kaynak kısıtlama bayraklarını kullanın: `docker run –memory="512m" –cpus="1.5" my-image`. Compose’da bunları `deploy.resources` anahtarı (Compose V2) veya üst düzey `mem_limit` ve `cpus` anahtarları altında ayarlayın. Sınırlar olmadan, kontrolden çıkmış tek bir konteyner ana bilgisayar kaynaklarını tüketebilir ve aynı ana bilgisayardaki diğer tüm konteynerleri çökertebilir.

Docker konteynerinin içinde Docker çalıştırabilir miyim (Docker-in-Docker)?

Evet, ancak üretim kullanımı için kesinlikle önerilmez. CI boru hatları için yaygın kalıp, ana bilgisayarın Docker daemon’ı üzerinde konteynere tam kontrol veren — önemli bir güvenlik riski olan — ana bilgisayar Docker soketini (`-v /var/run/docker.sock:/var/run/docker.sock`) CI konteynerine bağlamaktır. Daha güvenli bir alternatif, BuildKit’in `–allow security.insecure` bayrağını veya Docker daemon gerektirmeden OCI imajları oluşturan Kaniko veya Buildah gibi özel araçları kullanmaktır.