🔄 Yaşam Döngüsü & Debug

Yaşam Döngüsü & Debug: Bir container'ın hayatı otel misafirinin konaklamasına benzer: docker ps resepsiyondaki 'şu an içeride kim var' listesidir, stop/start odadan çıkıp geri dö

Bir container'ın hayatı otel misafirinin konaklamasına benzer: docker ps resepsiyondaki 'şu an içeride kim var' listesidir, stop/start odadan çıkıp geri dönmektir, rm kesin çıkış (check-out) yapmaktır — logs ve exec ise odanın güvenlik kamerası ile misafir hâlâ içerideyken odaya girmeni sağlayan ana anahtardır. Peki stop ve rm neden tek bir 'öldür' komutu değil de iki ayrı adım? Java'nın close() çağrısını nesnenin garbage-collect edilmesinden ayırmasıyla aynı sebepten: durdurulmuş bir container dosya sistemini — yani paha biçilmez kanıtı — korur, rm ise kalıcı olarak yok eder. Gerçek QA işinde bu sıra kritiktir: CI'da gece 3'te çöken test container'ında 'docker rm'den ÖNCE 'docker logs' çalıştıran mühendisin elinde stack trace vardır; önce temizlik yapanın bug raporuna ekleyecek hiçbir şeyi yoktur.

Container'ları listeleme

docker ps ile docker ps -a Arasındaki Fark Neden Kritik?

docker ps SADECE şu an ÇALIŞAN…

`docker ps` SADECE şu an ÇALIŞAN (running) container'ları listeler — durmuş bir container bu listede HİÇ görünmez, silinmiş de sanılabilir.

docker ps -a ise DURMUŞ ve…

`docker ps -a` ise DURMUŞ ve HİÇ başlatılmamış container'lar dahil TÜMÜNÜ gösterir — "container'ım nereye gitti?" sorusunun ilk cevabı GENELDE bu komuttur.

STATUS sütunundaki "Exited (1)"…

STATUS sütunundaki "Exited (1)" ifadesi, container'ın SIFIR olmayan bir hata koduyla KAPANDIĞINI gösterir — 0'dan farklı her sayı QA için bir ALARM'dır.

Sandbox'ta docker ps yaz — 3. görev bu şekilde tamamlanır ve çalışan container'ların tablosunu terminalde canlı görürsün.

Yaşam döngüsü — durdur, başlat, yeniden başlat

docker stop, Container'ı NEDEN ANINDA Öldürmez?

docker stop ÖNCE SIGTERM sinyali…

`docker stop` ÖNCE bir SIGTERM sinyali gönderir — uygulamaya "kapanmaya HAZIRLAN, açık bağlantıları TEMİZLE" demenin NAZİK yoludur.