Docker Compose stop ve down farkı nedir?

Kısa yanıt

docker compose stop kapsayıcıları durdurur ve disk üzerinde bırakır. docker compose down kapsayıcıları durdurur, ardından kapsayıcıları ve Compose'un proje için oluşturduğu ağı siler. Her iki komut da adlandırılmış bir birime dokunmaz. Veritabanınız yalnızca -v eklediğinizde, docker compose down -v örneğinde olduğu gibi, Compose dosyasının volumes bölümünde tanımlanan adlandırılmış birimleri kaldırdığı için silinir.

Temel fark bir paragrafta budur. Bu kılavuzun geri kalanında, bir Postgres biriminin down sonrasında nasıl korunduğu ve down -v altında nasıl silindiği gözlemlenerek bu durum kanıtlanır. Ayrıca --force-recreate gerektiren iki durum açıklanır.

docker compose stop: kapsayıcılar çalışmaya devam ediyor

stop, her kapsayıcıdaki ana işleme SIGTERM gönderir ve bekler. İşlem hâlâ çalışıyorsa ardından SIGKILL gönderir. Varsayılan bekleme süresi 10 saniyedir. -t bu süreyi değiştirir. Hiçbir şey silinmez. Kapsayıcı kimliğini, yazılabilir katmanını, IP ayırmasını ve günlüklerini korur.

docker compose stop
docker compose ps -a

docker compose ps tek başına yalnızca çalışan kapsayıcıları gösterir. Bu nedenle stop komutundan sonra boş bir tablo yazdırır ve kapsayıcıların silindiği düşünülür. ps -a durdurulmuş kapsayıcıları da içerir. Her hizmetin yanında Exited (0) burada görülür. Kapsayıcıları, tamamen aynı kapsayıcıları yeniden kullanarak docker compose start ile yeniden başlatın.

Kapsayıcılar hâlâ mevcut olduğundan, bir volume dışında kapsayıcıların içine yazılan her şey korunur. Buna docker compose exec ile elle yüklenen bir paket ve kapsayıcının içinde düzenlenen bir yapılandırma dosyası da dahildir. Hata ayıklama sırasında stop tercih edilmesinin pratik nedeni budur: aynı durumla yeniden başlatma yapılabilir.

docker compose down: container'lar ve ağlar kaldırılır

down container'ları durdurur ve ardından bunları, Compose'un proje için oluşturduğu varsayılan ağla birlikte kaldırır. Docker belgelerinde bu işlem, up tarafından oluşturulan container'ları, ağları, volume'ları ve image'ları durdurma ve kaldırma olarak açıklanır. Ancak volume ve image işlemleri yalnızca -v ve --rmi seçenekleriyle açıkça istendiğinde gerçekleştirilir.

docker compose down
docker compose ps -a
docker network ls

down komutundan sonra ps -a proje için hiçbir çıktı vermez ve <project>_default ağı artık mevcut değildir. Proje adı, Compose dosyasında name: ayarlanmadığı veya -p ile belirtilmediği sürece dizin adından alınır. Bir container'ın yazılabilir katmanında yaptığınız tüm değişiklikler artık kurtarılamaz. Bu nedenle down komutunu container'ı silen, ancak volume'lara koyduğunuz verileri koruyan bir komut olarak değerlendirin.

Komutu yanlış dizinde çalıştırırsanız no configuration file provided: not found hatasını alırsınız. Compose hangi projeyi kastettiğinizi belirleyemez ve işlemi reddeder. Proje klasöründe olmadığınızda docker compose -f /srv/myapp/compose.yaml down kullanın.

docker compose down birimlerimi siler mi?

Hayır. Üst düzey volumes anahtarı altında tanımlanan adlandırılmış birim, down sonlandıktan sonra da varlığını sürdürür. Bağlandığı container silindikten sonra da varlığını sürdürür. Bu, komutla ilgili en yaygın endişedir. Yanıt, Compose v2 sürümlerinde değişmez.

Üzerinde test yapabileceğiniz bir yığın hazırlayın. Boş bir dizin olan voltest içinde compose.yaml dosyasına aşağıdakileri ekleyin.

services:
  db:
    image: postgres:16.4
    restart: unless-stopped
    environment:
      POSTGRES_PASSWORD: example
    volumes:
      - pgdata:/var/lib/postgresql/data

volumes:
  pgdata:

Yığını başlatın ve daha sonra tanıyabileceğiniz bir satır yazın.

docker compose up -d
sleep 10
docker compose exec -T db psql -U postgres -c "create table marker (note text);"
docker compose exec -T db psql -U postgres -c "insert into marker values ('survived');"

Şimdi container'ı silin ve birimi denetleyin.

docker compose down
docker volume ls

Çıktıda voltest_pgdata hâlâ listelenir. Container artık yoktur, ancak veriler durur. Yığını yeniden başlatın ve satırı okuyun.

docker compose up -d
sleep 10
docker compose exec -T db psql -U postgres -c "select * from marker;"

survived içeren tek bir satır elde edilir. Yeni container, farklı bir ID'ye sahip farklı bir container'dır ve aynı birime bağlanır. Daha geniş kapsamlı bilgi için Compose temelleri kılavuzu, adlandırılmış birimleri bind mount'larla ve her birinin host üzerinde gerçekte nerede bulunduğuyla karşılaştırır.

down -v komutunun tam olarak neyi sildiği

-v (uzun biçimiyle --volumes), Compose dosyasının volumes bölümünde tanımlanan adlandırılmış volume'ları ve container'lara bağlı anonim volume'ları kaldırır. Komutu aynı stack üzerinde çalıştırın.

docker compose down -v
docker volume ls

voltest_pgdata artık listelenmez. Stack'i yeniden başlatın. Postgres entrypoint'i boş bir veri dizini bulur ve yeni bir cluster başlatır. Container log'u bunu açıkça belirtir.

The files belonging to this database system will be owned by user "postgres".
PostgreSQL init process complete; ready for start up.

Aylarca çalışmış bir stack üzerinde bu bloğu görmek, volume'un kaldırıldığı anlamına gelir. marker tablonuz kaybolmuştur. Geri dönmenin tek yolu yedektir.

Bazı depolama alanları -v tarafından hiçbir zaman kaldırılmaz. Bind mount bir host yoludur. Bu nedenle Docker yalnızca mount'u kaldırır ve dosyalarınız yerinde kalır. external: true ile işaretlenmiş bir volume, bu projenin dışındaki bir öğeye ait olarak tanımlanır. Compose bu volume'u hiçbir zaman kaldırmaz. down -v çalıştırılmadan önce Compose dosyasından sildiğiniz adlandırılmış bir volume artık tanımlı değildir. Bu nedenle Compose onu kaldırmayı bilemez ve docker volume prune süresince orphan olarak geride bırakır.

Son durum, refactor sırasında sorun oluşturur. Bir servisi ve volume'unu dosyadan kaldırıp down -v çalıştırırsanız volume, dosyada artık belirtilmediği için varlığını sürdürür. Dosyayı düzenlemeden önce down -v çalıştırın; düzenledikten sonra çalıştırmayın.

--force-recreate seçeneğine gerçekten ihtiyaç duyulan durumlar

docker compose up -d her seferinde her şeyi yeniden oluşturmaz. Compose, her hizmetin çözümlenmiş yapılandırmasının bir özetini container üzerinde label olarak saklar. Özet ve image ID eşleşirse container olduğu gibi bırakılır ve Recreated yerine Container voltest-db-1 Running elde edilir. Bu davranış neredeyse her zaman istenir, çünkü up -d komutunun tekrar tekrar güvenle çalıştırılmasını sağlar.

Bazı düzenlemelerin etkisiz görünmesinin nedeni de budur. Compose, hizmet tanımının işaret ettiği dosyaların içeriğini değil, çözümlenmiş hizmet tanımını özetler. Container içine bağlanan ve başlangıçta bir kez okunan bir yapılandırma dosyasını düzenlemek recreate işlemini tetiklemez, çünkü bağlama yolu değişmemiştir. Hizmet, başlatma sırasında okuduğu değerlerle çalışmaya devam eder.

docker compose up -d --force-recreate

Bu işlem her container'ı durdurup kaldırır ve aynı tanımdan yeni bir container oluşturur. Bağlanmış bir yapılandırma dosyasını düzenledikten sonra ve bir container açıklanamayan bir duruma geçtiğinde kullanılmalıdır. Volume'lara dokunulmaz; bu nedenle bir veritabanı force recreate işleminden sonra korunur. Aynı tag için daha yeni bir image kullanmak üzere pull işleminin de yapılması gerekir.

docker compose pull
docker compose up -d

pull yeni image ID'sini alır. Ardından up -d, çalışan container'ın image ID'sinin farklı olduğunu görür ve container'ı kendisi yeniden oluşturur. pull olmadan --force-recreate eklenirse aynı eski image'dan yeni bir container oluşturulur. Bu nedenle "force recreate yaptım ama sürüm hâlâ eski" şikayeti oldukça yaygındır.

docker compose restart bunların hiçbirini yapmaz. Mevcut container'ları yeniden başlatır ve Compose dosyasını yeniden okumaz. Bu nedenle değiştirilen bir ortam değişkeni veya port eşlemesi uygulanmaz. Dosyayı düzenlediyseniz up -d kullanın.

Akılda tutulması gereken zihinsel model

Container'lar değiştirilebilir. Bir container, bir işlem ile ince bir yazılabilir katmandan oluşur ve Compose, dosyadaki tanımdan yaklaşık 1 saniye içinde aynı container'ı oluşturabilir. Volume'lar değiştirilemez, çünkü yalnızca depodaki hiçbir dosyanın yeniden oluşturamayacağı durum verisini barındırırlar.

Her Compose fiili bu ayrıma karşılık gelir. stop ve start container'ı korur. down ve up container'ı değiştirir ve volume'u korur. down -v, durumu kaldıran tek rutin komuttur; bu nedenle açık bir flag gerektirir. Bu komutu gerçek bir sistemde çalıştırmadan önce, en az bir kez geri yüklediğiniz bir yedeğiniz olduğunu doğrulayın.

Aynı mantık secret'lar için de geçerlidir. POSTGRES_PASSWORD aracılığıyla ayarlanan bir parola yalnızca veritabanı ilk kez başlatıldığında okunur. Bu nedenle ortam dosyanızdaki parolayı değiştirip up -d komutunu çalıştırırsanız password authentication failed for user "postgres" elde edersiniz. Container yenidir, volume eskidir ve eski volume hâlâ eski parolayı içerir. Compose env dosyalarını ve secret'ları nasıl çözümler, aynı değişken iki kez ayarlandığında hangi katmanın öncelikli olduğunu açıklar.

Hata türleri ve göreceğiniz dizeler

no configuration file provided: not found, Compose'un compose.yaml ve docker-compose.yml içermeyen bir dizinde çalıştığı anlamına gelir. Tam yolu -f ile belirtin.

down üzerindeki network voltest_default has active endpoints, bu projenin dışındaki bir container'ın proje ağına bağlandığı anlamına gelir. Bu container genellikle docker run --network ile elle başlatılmıştır. Bu container'ı kaldırın, ardından down komutunu yeniden çalıştırın.

Found orphan containers ([voltest-old-1]) for this project, bir service'i yeniden adlandırdıktan veya sildikten sonra görünür. Eski container hâlâ proje etiketini taşır. docker compose down --remove-orphans bu etiketleri temizler ve sağlıklı bir stack üzerinde çalıştırılması güvenlidir.

Elle çalıştırılan docker volume rm komutunda görülen Error response from daemon: remove voltest_pgdata: volume is in use, durmuş bir container da dahil olmak üzere bir container'ın hâlâ volume'a başvurduğu anlamına gelir. Önce docker compose down komutunu çalıştırın, ardından volume'u kaldırın veya doğrudan down -v kullanın. Daha büyük bir projede çok service'li bir Compose stack'i, tek bir projenin kaç volume biriktirebileceğini gösterir.

FAQ

docker compose down veritabanımı siler mi?

Veritabanı adlandırılmış bir volume içinde veya bind mount olarak tutuluyorsa silmez. down container'ları ve proje ağını kaldırır; volume, verileri korunmuş olarak diskte kalır. Sonraki docker compose up -d aynı volume'u yeni bir container'a bağlar ve veriler kullanılabilir olur. Yalnızca docker compose down -v adlandırılmış volume'ları kaldırır ve yalnızca Compose dosyasının volumes bölümünde tanımlananları siler.

Geri almak istediğim bir container için stop ile down arasındaki fark nedir?

stop container'ı korur. Bu nedenle docker compose start aynı yazılabilir katmana sahip aynı container'a geri dönülmesini sağlar. Container içinde elle yüklenen veya düzenlenen her şey korunur. down container'ı siler. Bu nedenle sonraki up -d image'dan yeni bir container oluşturur ve elle yapılan değişiklikler kaybolur. Hata ayıklama sırasında stop kullanılması gerekir.

Bir Compose projesinin oluşturduğu her şeyi nasıl kaldırırım?

docker compose down -v --rmi all --remove-orphans container'ları, proje ağını, dosyada tanımlanan adlandırılmış volume'ları, servislerin kullandığı image'ları ve proje adıyla etiketlenmiş tüm container'ları kaldırır. Bind mount'lara veya external: true olarak işaretlenmiş volume'lara dokunmaz. Çalıştırmadan önce neleri kaybedeceğinizi docker volume ls ile kontrol edin.

Container, bağlanmış bir yapılandırma dosyasında yaptığım değişikliği neden dikkate almıyor?

Compose, bir container'ın yeniden oluşturulup oluşturulmayacağına, çözümlenmiş servis tanımının hash değerini karşılaştırarak karar verir. Bu hash, bağlanmış bir dosyanın içeriğini içermez. Dosyanın yolu değişmediği için Compose container'ı çalışır durumda bırakır ve başlangıçta okuduğu değerleri kullanmaya devam eder. Dosyayı yeniden okuyacak yeni bir container oluşturmak için docker compose up -d --force-recreate çalıştırın.

Değiştirdiğim yeni POSTGRES_PASSWORD neden çalışmıyor?

Postgres image'ı POSTGRES_PASSWORD değerini yalnızca boş bir veri dizinini başlatırken okur. Volume zaten başlatılmış bir cluster içerdiği için değişken yok sayılır ve eski parola geçerli olmaya devam eder. password authentication failed for user "postgres" çıktısını görürsünüz. Çalışan veritabanının parolasını ALTER USER ile değiştirin veya verileri kaybetmeyi kabul edip docker compose down -v ile yeniden başlayın.