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: container'lar kalır

stop, her container içindeki ana sürece SIGTERM sinyali gönderir, bekler ve süreç hala canlıysa SIGKILL gönderir. Varsayılan bekleme süresi 10 saniyedir ve -t bu süreyi değiştirir. Hiçbir şey silinmez. Container; ID'sini, yazılabilir katmanını, IP rezervasyonunu ve loglarını korur.

docker compose stop
docker compose ps -a

docker compose ps tek başına kullanıldığında yalnızca çalışan container'ları gösterir; bu nedenle stop komutundan sonra boş bir tablo yazdırır ve kullanıcılar container'ların silindiğini düşünebilir. ps -a durdurulmuş olanları da dahil eder; burada her servisin yanında, sürecin döndürdüğü çıkış koduyla birlikte Exited durumunu görürsünüz. Temiz bir kapatma işlemi Exited (0) sonucunu gösterir. Sıfırdan farklı bir kod, sürecin başarısız olduğunu veya zaman aşımı sonrası sonlandırıldığını belirtir. Aynı container'ları birebir yeniden kullanan docker compose start ile servisleri tekrar ayağa kaldırabilirsiniz.

Container'lar varlığını sürdürdüğü için, volume dışında içlerine yazılan her şey yerinde kalır. Buna docker compose exec ile elle yüklediğiniz bir paket ve container içinde düzenlediğiniz bir yapılandırma dosyası da dahildir. Hata ayıklama yaparken stop yöntemini tercih etmenin pratik nedeni budur: aynı durumda yeniden başlatma yapabilirsiniz.

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 komutu volume verilerimi siler mi?

Hayır. En üst düzey volumes anahtarı altında tanımlanan adlandırılmış bir volume, down işleminden sonra varlığını sürdürür ve bağlı olduğu container silinse dahi yaşamaya devam eder. Bu, komutla ilgili en yaygın endişedir ve yanıt, Compose v2 sürümünden güncel v5 sürümlerine kadar değişmemiştir.

Test edebileceğiniz bir stack hazırlayın. Bunu voltest adlı boş bir dizin içerisinde compose.yaml dosyasına yerleştirin.

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

volumes:
  pgdata:

Stack'i 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'ı yok edin ve volume durumunu kontrol edin.

docker compose down
docker volume ls

Çıktı hala voltest_pgdata öğesini listeler. Container silinmiştir ancak veriler durmaktadır. Stack'i tekrar ayağa kaldırı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 bir satır elde edersiniz. Yeni container, farklı bir ID'ye sahip, aynı volume'e bağlı yeni bir container'dır. Daha geniş bir perspektif isterseniz, Compose temel rehberi, adlandırılmış volume'ler ile bind mount'ları karşılaştırır ve her birinin ana makinede tam olarak nerede bulunduğunu açıklar.

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 modları ve karşılaşacağınız dizgeler

no configuration file provided: not found, Compose'un compose.yaml veya docker-compose.yml içermeyen bir dizinde çalıştığı anlamına gelir. -f bayrağını tam yol ile birlikte kullanın.

down üzerindeki network voltest_default has active endpoints, bu proje dışındaki bir container'ın proje ağına bağlı olduğunu gösterir; bu durum genellikle docker run --network ile manuel olarak başlatılan container'larda görülür. İlgili container'ı kaldırın ve ardından down komutunu tekrar çalıştırın.

Found orphan containers (voltest-old-1) for this project, bir servisi yeniden adlandırdıktan veya sildikten sonra görünür. Güncel Compose, isimleri virgülle ayrılmış şekilde listeler. Daha eski Compose v2 sürümleri, aynı uyarıyı ([voltest-old-1]) örneğinde olduğu gibi köşeli parantez içinde verir. Eski container hala proje etiketini taşımaktadır. docker compose down --remove-orphans bu etiketleri temizler; sağlıklı bir yığın üzerinde çalıştırılması güvenlidir.

Manuel docker volume rm üzerindeki Error response from daemon: remove voltest_pgdata: volume is in use, durdurulmuş olanlar da dahil olmak üzere herhangi bir container'ın ilgili volume'e hala referans verdiğini belirtir. Önce docker compose down komutunu çalıştırıp ardından volume'ü kaldırın veya doğrudan down -v kullanın. Daha büyük projelerde, çok servisli bir Compose yığını, bir projenin ne kadar çok 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.