Gerçek Sunucular İçin Docker Compose Komutları

Gerçekte kullandığınız Compose komutları

Docker Compose kırktan fazla alt komut sunar. Sunucudaki günlük çalışmalarda yaklaşık bir düzine komut kullanılır. Bu sayfada komutlar yapılan işe göre gruplandırılır, her biri için açık bir neden verilir ve bir komutun gizli bir soruna yol açabileceği durumlarda ayrıntılı açıklamaya yönlendirme yapılır.

Buradaki tüm örneklerde Compose V2 kullanılır: docker compose boşlukla yazılır; eski docker-compose betiği kullanılmaz. V2, Docker Engine ile birlikte kurulan bir Go eklentisidir. V1 güncel paketlerden kaldırıldığı için, Temmuz 2026 itibarıyla yeni bir Ubuntu sisteminde docker-compose: command not found çıktısının alınması beklenen bir durumdur ve hata anlamına gelmez. docker compose version ile kontrol edin. Bu komut hiçbir çıktı vermezse docker-compose-plugin paketini kurun.

Aşağıdaki her komut, compose.yaml dosyanızı içeren dizinden çalıştırılır. Bunun nedeni, Compose'un proje adını bu dizinden alması ve dosyayı bu dizine göre bulmasıdır. Aynı komutu bir üst dizinde çalıştırırsanız Compose no configuration file provided: not found ile durur. Dosya biçimi sizin için yeniyse VPS üzerinde ilk Compose dosyası ile başlayın ve komutlar için buraya dönün.

Yaşam döngüsü: yazılan dört komut ve container'ları kaldıran komut

docker compose up -d
docker compose up -d --wait
docker compose stop
docker compose start
docker compose restart web
docker compose down

up -d ağı oluşturur, container'ları oluşturur, başlatır ve geri döner. Container'lar oluşturulur oluşturulmaz geri döner. Bu nedenle, ardından curl denetimi çalıştıran bir dağıtım betiği ilk denemede çoğu zaman başarısız olur. up -d --wait, healthcheck tanımlayan her hizmetin sağlıklı durum bildirmesini bekler ve bir hizmet bu duruma hiç ulaşmazsa sıfır olmayan bir çıkış koduyla sonlanır. Bu flag'in güvenilirliği, arkasındaki denetimin güvenilirliğiyle sınırlıdır. Otomasyonda kullanmadan önce Compose'un güvenebileceği bir healthcheck yazılmalıdır.

stop container'ları durdurur ve korur. Böylece start aynı container'ları aynı yazılabilir katmanla yeniden başlatır. down container'ları durdurur, ardından container'ları ve project network'ünü kaldırır. Container içinde ve volume dışında yazılan her şey container'larla birlikte silinir. Compose'taki en maliyetli yanlış anlama budur. down ile stop arasındaki tüm fark hangi durumlarda sorun oluşturduğunu açıklar.

restart yeniden yükleme işlemi değildir. Aynı container'ı mevcut yapılandırmasıyla durdurup başlatır. Bu nedenle değiştirilen bir environment variable, yeni bir image tag'i veya düzenlenen bir port mapping hiçbir etki oluşturmaz. Bir dosya değişikliğini uygulamak için up -d yeniden çalıştırılır. Compose her hizmeti çalışan container'ıyla karşılaştırır ve yalnızca yapılandırması değişen container'ları yeniden oluşturur.

Değişiklik uygulama: yeniden oluşturma, çekme veya yeniden derleme

docker compose up -d --force-recreate
docker compose pull && docker compose up -d
docker compose build --no-cache web
docker compose up -d --build web

Hiçbir şey değişmediğinde up -d tek başına işlem yapmaz. Bu özellik, komutun güvenle tekrar tekrar çalıştırılmasını sağlar. --force-recreate bu karşılaştırmayı geçersiz kılar ve yapılandırma aynı olsa bile tüm container'ları değiştirir. Bu nedenle, container içindeki anormal durumu temizlemenin en hızlı yoludur.

Bir image'ı güncellemek için 2 komut gerekir. Çünkü bu komutlar farklı işlemler yapar. pull dosyada adı geçen her tag için güncel image'ı indirir. Ardından up -d, servisin image ID değerinin çalışan container ile artık eşleşmediğini algılar ve container'ı yeniden oluşturur. Pull işlemini atlarsanız up -d, geçen ayın latest değerini çalıştırmaya devam eder ve hata vermez.

build, image: yerine build: bölümü tanımlayan servisler için geçerlidir. up -d --build, tek adımda build işlemi gerçekleştirir ve servisi başlatır. Kod değiştirirken normal döngü budur. Önbelleğe alınmış bir katmanın açıkça güncel olmadığından emin olduğunuzda --no-cache kullanılmalıdır. Çünkü bu işlem her katmanı sıfırdan yeniden oluşturur.

Çalışanları görüntüleme

docker compose ps
docker compose ps -a
docker compose logs -f --tail=100
docker compose logs --since 15m --timestamps db
docker compose top
docker compose ls

ps yalnızca çalışan container'ları listeler. Başlangıç sırasında çöken bir servis, -a eklenene kadar burada görünmez. Bu nedenle ps içinde görünmeyen bir container'ın ps -a tarafından Exited (1) olarak gösterilmesi, başlangıç hatasının normal görünümüdür. Çıkış kodunu, ardından günlükleri okuyun.

logs -f tüm servisleri aynı anda izler ve her satırın başına servis adını ekler. Servisler birbiriyle iletişim kurduğunda ve olayların sırası önemli olduğunda gereken görünüm budur. Görünümü daraltmak için bir servis adı belirtin. Bir container bir aydır çalışıyorsa --tail=100 önemlidir. Bunun nedeni, varsayılan davranışın tüm geçmişi yazdırarak terminali doldurmasıdır. --since 15m genellikle gereken soruyu yanıtlar: az önce yaptığınız yeniden başlatma sırasında ne oldu?

top her container içindeki işlemleri listeler. Böylece "container çalışıyor" ile "içindeki işlem çalışıyor" durumları birbirinden ayrılır. ls geçerli dizinin dışına çıkar ve ana bilgisayardaki tüm Compose projelerini durumlarıyla birlikte listeler. Bu sayede üç ay önce başlattığınız yığını bulabilirsiniz.

Bir hizmet içinde kabuk açma

docker compose exec web sh
docker compose exec -u root web sh
docker compose run --rm web env
docker compose run --rm --no-deps web sh

exec, zaten çalışır durumda olan bir container içinde komut çalıştırır. run, aynı hizmet tanımından yeni bir container başlatır. Hizmet, içine exec ile girilebilecek kadar uzun süre çalışmıyorsa gereken yöntem budur. run her zaman --rm ile birlikte kullanılmalıdır. Aksi halde her çalıştırma durdurulmuş bir container bırakır. Bunlar birikerek docker compose ps -a çıktısının okunamaz hale gelmesine neden olur.

sh komutunu bash komutundan önce deneyin. Alpine tabanlı image'larda bash bulunmaz ve hata exec: "bash": executable file not found in $PATH şeklinde görüntülenir. --no-deps seçeneğinin run seçeneğine eklenmesi, hizmetin bağımlılıklarını atlar. Böylece hızlı bir yapılandırma denetimi için tüm veritabanının başlatılması önlenir.

run --rm web env, tüm .env dosyaları, environment: blokları ve kabuk değişkenleri birleştirildikten sonra, bir hizmetin gerçekte aldığı ortamı görmenin en hızlı yoludur. Bir değer yanlışsa bunun nedeni genellikle birleştirme sırasıdır. Compose'un env dosyalarını ve secrets değerlerini nasıl çözdüğü bölümünde hangi kaynağın öncelikli olduğu açıklanır.

Ağlar, bağlantı noktaları ve ad çözümleme

docker compose port web 80
docker compose exec web getent hosts db
docker compose config --networks

Compose, tüm hizmetleri tek bir proje ağına yerleştirir ve her hizmet adı bu ağda bir DNS adıdır. Çözümleme çalıştığında web içinde getent hosts db çalıştırılması konteyner IP adresini yazdırır; çalışmadığında hiçbir şey yazdırmaz. Böylece "bu konteynerler birbirini görebiliyor mu" sorusu iki saniyede yanıtlanır. Ad çözümleniyor ancak bağlantı reddediliyorsa db içindeki işlem 0.0.0.0 yerine 127.0.0.1 adresine bağlanmıştır. Bu nedenle başka bir konteynerden gelen paketi kabul etmez. Bu modelin geri kalanı Compose ağlarının ve hizmet DNS'inin çalışma şekli bölümünde açıklanır.

port web 80, bir konteyner bağlantı noktasının yayımlandığı ana bilgisayar adresini ve bağlantı noktasını yazdırır. Eşleme bir değişkenden geldiğinde tahmin yürütme gereğini ortadan kaldırır. Bir bağlantı noktasının yayımlanması, Docker'ın kendisinin yönettiği bir güvenlik duvarı kuralı da yazar. Bu kural sizin kurallarınızdan önce değerlendirilir. Bu nedenle özel olduğunu düşündüğünüz bir hizmet internete açık olabilir. Bu durum yayımlanmış Docker bağlantı noktalarının ufw kurallarını neden aştığı bölümünde ele alınır.

Birimler ve veriler

docker compose config --volumes
docker compose cp db:/etc/postgresql/pg_hba.conf ./pg_hba.conf
docker compose down -v

config --volumes, projenin tanımladığı adlandırılmış birimleri her satırda bir tane olacak şekilde listeler. Yedeklemeniz gereken liste budur. cp, bir kabuk açmadan bir dosyayı kapsayıcıya kopyalar veya kapsayıcıdan dışarı alır. Kapsayıcının bulunduğu tarafta service:path biçimi kullanılır.

down -v, kapsayıcılarla birlikte bu adlandırılmış birimleri de kaldırır. Test yığınını kaldırmak için doğru komuttur. Önem verdiğiniz verileri içeren herhangi bir yapı için ise yanlıştır; çünkü onay istemez ve geri alma işlemi yoktur. Bind mount'lar ana makinenin dosya sisteminde bulunduğu için bu işlemden etkilenmez. Etki alanındaki bu fark, bind mount'lar ve adlandırılmış birimler arasında bilinçli seçim yapılmasının nedenlerinden biridir.

Veri kaybı olmadan disk alanı açan temizlik

docker compose down --remove-orphans
docker system df
docker image prune -a
docker builder prune

--remove-orphans, projeye ait olan ancak artık dosyada bulunmayan container'ları siler. Bir servisi yeniden adlandırdıktan sonra elde edilen sonuç tam olarak budur. Bu seçenek kullanılmazsa bu container'lar çalışmaya devam eder ve docker compose ps tarafından görünmez.

docker system df, herhangi bir şeyi silmeden önce disk alanının nereye gittiğini gösterir. Images, container'lar, local volume'lar ve build cache için geri kazanılabilir alanı ayrı ayrı belirtir. image prune -a, hiçbir tag tarafından işaret edilmeyen tüm image'ları kaldırır. Büyük bir image'ın birden fazla sürümünü çekmiş bir sunucuda bu işlem genellikle en fazla alanı kazandırır. builder prune, kendi image'larını oluşturan her sunucuda zamanla sessizce büyüyen build cache'i temizler.

Bunların hiçbiri named volume'ları etkilemez. Yalnızca docker volume prune ve docker compose down -v named volume'ları etkiler.

Bir şeyi bozmadan önce dosyanın denetlenmesi

docker compose config --quiet
docker compose config --services
docker compose --dry-run up -d

config --quiet başarılı olduğunda doğrulama yapar ve hiçbir çıktı vermez. Bu nedenle bir dağıtım öncesi adımında veya git kancasının içinde kullanılmalıdır. Düz config, tamamen birleştirilmiş ve değişkenleri işlenmiş dosyayı yazdırır. Bu çıktı, bir değişkenin çözümlendiğini ve geçersiz kılma dosyasının beklendiği şekilde katmanlandığını doğrulamak için kullanılır. Ayarlanmamış bir değişken, The "X" variable is not set. Defaulting to a blank string. uyarısının yanında boş bir değer olarak görünür.

--dry-run, alt komut seçeneği değil, genel bir seçenektir. Bu nedenle up komutundan önce yazılmalıdır. Compose'un gerçekleştireceği her işlemi yazdırır ve hiçbir değişiklik yapmaz. Önemli bir yığında down çalıştırmadan önce harcanan bu otuz saniye yararlıdır.

Dosyalar, profiller ve projeler arasında çalışma

docker compose -f compose.yaml -f compose.prod.yaml up -d
docker compose --profile debug up -d
docker compose -p staging up -d

Birden fazla -f flag'i sırasıyla birleştirilir. Daha sonraki dosyalar, anahtar bazında önceki dosyaların üzerine yazılır. Bu, küçük bir production override dosyasıyla birlikte tek bir temel dosya kullanmanın standart yoludur. Ancak kurallar listeler ve map'ler için farklıdır. Bu nedenle beklenmeyen bir durumla ilgili hata ayıklamadan önce Compose'un birden fazla dosyayı nasıl birleştirdiğini okuyun.

--profile, bu profille etiketlenmiş servisleri etiketsiz servislerle birlikte başlatır. Böylece debug araçları normal bir up çalıştırmasına dahil edilmez. -p proje adını belirler. Bu sayede aynı stack'in iki kopyası, ayrı network'ler ve ayrı volume adlarıyla yan yana çalıştırılabilir. Stack'i yeniden başlatma sonrasında geri getirmek için yazılan bir komut yoktur. Bunun yerine, bu işlemi sizin için gerçekleştiren bir unit çalışır. Bu işlem Compose stack'lerini boot sırasında başlatma bölümünde açıklanır.

FAQ

docker-compose yerine kısa çizgi kullanımı ne zaman bırakıldı?

Compose V2, boşluk kullanılarak docker compose şeklinde çağrılır. Docker Engine ile birlikte sunulan bir eklentidir. V1 Python aracı artık güncel paketlerle kurulmaz. Boşluk kullanılan biçim hiçbir çıktı vermiyorsa dağıtımınız için docker-compose-plugin paketini kurun. Takma ad eklemek yerine eski betikleri boşluk kullanılan biçime güncelleyin. V2, V1'de bulunmayan seçeneklere sahiptir.

docker compose restart yapılandırma değişikliğimi neden algılamıyor?

restart mevcut container'ı oluşturulduğu yapılandırmayla durdurur ve yeniden başlatır. compose.yaml dosyasını yeniden okumaz. Ortam değişkenlerinde, portlarda, volume'larda veya image etiketinde yapılan değişiklikler için docker compose up -d gerekir. Bu komut her service'i çalışan container'ıyla karşılaştırır ve farklı olanları yeniden oluşturur. Dosyada hiçbir değişiklik olmamasına rağmen replacement işlemini zorlamak istediğinizde --force-recreate ekleyin.

Bir service'i daha yeni bir image'a nasıl güncelleyebilirim?

Önce docker compose pull, ardından docker compose up -d çalıştırın. pull işlemi, dosyada bulunan her etiket için güncel image'ı indirir. up -d, image ID'si container'ındaki image ID'siyle eşleşmeyen service'leri yeniden oluşturur. up -d tek başına çalıştırıldığında diskte zaten bulunan image yeniden kullanılır. Bu nedenle latest sürümüne sabitlenmiş bir stack, herhangi bir hata yazdırmadan aylar önce oluşturulmuş bir build'i kullanmaya devam edebilir.

Çalışan bir sunucuda hangi temizleme komutları güvenlidir?

docker system df, docker image prune -a ve docker builder prune yalnızca image'ları ve cache'i kaldırır. Bu nedenle çalışan service'ler çalışmaya devam eder ve adlandırılmış volume'lara dokunulmaz. Tehlikeli ikili docker compose down -v ve docker volume prune komutlarıdır. Bu komutlar adlandırılmış volume'ları onay istemeden siler. Risk altındaki kaynakları görmek için önce docker compose config --volumes çalıştırın.

Tüm stack'i başlatmadan tek bir komut çalıştırabilir miyim?

Evet. docker compose run --rm --no-deps web sh, web service tanımından tek bir container başlatır, bağımlılıklarını atlar ve çıkış yaptığınızda container'ı kaldırır. Container zaten çalışıyorsa bunun yerine exec kullanın. exec çalışan işleme katılır ve service'in gerçekte içinde bulunduğu durumu gösterir.