Docker Disk Alanı Neden Dolar? Güvenli Temizlik ve Log Yönetimi

Docker kullanılan bir Linux sunucusunda disk alanının hızla dolması, ilk bakışta uygulamanın çok fazla veri ürettiğini düşündürebilir. Ancak asıl neden çoğu zaman uygulamanın kendisi değil, arka planda biriken Docker imajları, build cache, kullanılmayan container’lar veya büyümeye devam eden log dosyalarıdır.

Üstelik bu dosyalar her zaman kolay fark edilmez. Sunucudaki uygulamalar normal çalışırken disk kullanımı giderek artabilir. Bir süre sonra yeni container oluşturulamaz, veritabanı yazma işlemleri başarısız olur veya uygulamalar No space left on device hatası vermeye başlar.

Bu noktada ilk akla gelen çözüm genellikle Docker temizleme komutlarıdır. Ancak hangi verinin silineceği bilinmeden çalıştırılan bir komut, birkaç gigabayt alan açarken önemli uygulama verilerini de ortadan kaldırabilir.

Doğru yaklaşım, önce disk alanını neyin tükettiğini belirlemek, ardından yalnızca güvenle kaldırılabilecek kaynakları temizlemektir. Kalıcı çözüm içinse özellikle log yönetiminin doğru yapılandırılması gerekir.

Docker Disk Alanı Neden Dolar?

Docker, container tabanlı uygulamaların çalışması için çeşitli dosya ve veri katmanları oluşturur. Bu yapı sayesinde uygulamalar birbirinden izole edilebilir, kolayca dağıtılabilir ve güncellenebilir.

Ancak container silindiğinde Docker ile ilişkili bütün veriler her zaman otomatik olarak ortadan kalkmaz.

Örneğin bir uygulamanın yeni sürümü dağıtıldığında eski imajlar sistemde kalabilir. Build işlemleri geçici katmanlar oluşturabilir. Durdurulmuş container’lar ve artık kullanılmayan ağlar birikmeye devam edebilir.

Bunların yanında uygulamaların standart çıktı ve hata akışlarına yazdığı loglar da önemli miktarda disk alanı tüketebilir.

Docker ortamlarında disk tüketimi genellikle şu kaynaklardan oluşur:

Özellikle sık deployment yapılan sunucularda eski imajlar ve build cache zaman içinde büyüyebilir. Yoğun log üreten uygulamalarda ise tek bir container bile beklenenden çok daha fazla alan tüketebilir.

Burada önemli bir ayrım bulunur: Docker’ın kullandığı disk alanının tamamı gereksiz veri değildir. Çalışan uygulamaların ihtiyaç duyduğu imajlar, aktif container katmanları ve kalıcı volume’lar korunmalıdır.

Docker Disk Kullanımı Nasıl Kontrol Edilir?

Temizlik işlemine başlamadan önce sunucunun genel disk durumunu incelemek gerekir.

Linux sistemlerinde bunun için kullanılabilecek temel komut:

df -h

df -h

Bu komut dosya sistemlerinin toplam kapasitesini, kullanılan alanı ve boş disk miktarını gösterir.

Özellikle Docker veri dizininin bulunduğu dosya sistemi kontrol edilmelidir. Standart rootful Linux kurulumlarında Docker verileri çoğunlukla /var/lib/docker altında tutulur. Ancak rootless kurulumlarda, Docker Desktop ortamlarında veya özel data-root yapılandırmalarında konum farklı olabilir.

Docker’ın veri dizinini görmek için:

docker info --format '{{.DockerRootDir}}'

docker info --format '{{.DockerRootDir}}'

Bu komut, mevcut Docker Engine yapılandırmasında kullanılan veri dizinini gösterir.

Ardından Docker’ın kendi disk kullanım raporu incelenebilir.

docker system df

docker system df

Komut, Docker kaynaklarının disk üzerindeki kullanımını özetler.

Çıktıda genellikle imajlar, container’lar, local volume’lar ve build cache için toplam kullanım ile geri kazanılabilir alan bilgileri bulunur.

Daha ayrıntılı rapor için:

docker system df -v

docker system df -v

Bu seçenek, kaynakları daha detaylı görüntüler.

Docker system df çıktısı nasıl yorumlanır?

Raporun en önemli alanlarından biri RECLAIMABLE değeridir. Bu alan, Docker’ın belirli kaynaklar için geri kazanılabilir olarak değerlendirdiği alanı gösterir.

Ancak bu değer, ilgili verilerin işletme açısından gereksiz olduğu anlamına gelmez.

Örneğin kullanılmayan bir imaj, olası bir geri dönüş işleminde gerekli olabilir. Herhangi bir container tarafından kullanılmayan volume ise silinmiş bir uygulamanın hâlâ ihtiyaç duyulan verilerini barındırabilir.

Dolayısıyla geri kazanılabilir alan miktarı, otomatik silme kararı için değil, araştırmanın hangi kaynaklara odaklanacağını belirlemek için kullanılmalıdır.

Docker İmajları Güvenli Şekilde Nasıl Temizlenir?

Docker imajları, container oluşturmak için kullanılan dosya sistemi katmanlarını ve uygulama bileşenlerini içerir.

Yeni uygulama sürümleri dağıtıldığında eski imajlar sistemde kalabilir. Özellikle sürekli entegrasyon ve dağıtım süreçlerinde bu birikim belirgin hale gelir.

Mevcut imajları listelemek için:

docker image ls -a

docker image ls -a

Burada imaj adları, etiketleri, kimlikleri ve boyutları görüntülenebilir.

Kullanılmayan ve herhangi bir etiketle ilişkilendirilmemiş dangling imajları temizlemek için:

docker image prune

docker image prune

Komut, silinecek kaynaklara ilişkin onay ister.

Daha kapsamlı temizlik için kullanılan:

docker image prune -a

docker image prune -a

komutu ise herhangi bir container tarafından kullanılmayan imajları kaldırabilir.

Dikkat: -a seçeneği yalnızca dangling imajları değil, mevcut container’larla ilişkili olmayan diğer imajları da kapsar. Bunlar arasında ileride kullanılmak üzere tutulan veya geri dönüş amacıyla saklanan imajlar bulunabilir.

Üretim ortamlarında bu nedenle imaj temizliği öncesinde deployment ve rollback ihtiyaçları kontrol edilmelidir.

Temizlikten sonra kaldırılan imajların tekrar kullanılabilmesi için yeniden indirilmesi veya oluşturulması gerekebilir.

Docker Container Temizleme İşlemi

Container durdurulduğunda yazılabilir katmanı otomatik olarak silinmeyebilir. Zaman içinde çok sayıda durdurulmuş container birikebilir.

Bunları görüntülemek için:

docker ps -a

docker ps -a

Çıktıdaki STATUS alanı, container’ların çalışıp çalışmadığını gösterir.

Artık kullanılmayan durdurulmuş container’ları temizlemek için:

docker container prune

docker container prune

Bu komut çalışan container’ları hedeflemez; durdurulmuş container’ları kaldırır.

Ancak durdurulmuş olması bir container’ın gereksiz olduğu anlamına gelmez.

Örneğin bakım amacıyla durdurulan bir container’ın yazılabilir katmanında daha sonra ihtiyaç duyulacak veriler bulunabilir. Kalıcı veriler volume veya bind mount üzerinde tutulmuyorsa container’ın kaldırılması bu verilerin kaybına yol açabilir.

Bu nedenle işlemden önce container’ın hangi uygulamaya ait olduğu, yeniden oluşturulup oluşturulamayacağı ve kalıcı verilerin nerede tutulduğu kontrol edilmelidir.

Docker Build Cache Nasıl Temizlenir?

Docker imajlarının oluşturulması sırasında kullanılan önbellek katmanları, sonraki build işlemlerini hızlandırır.

Ancak özellikle sık build yapılan sistemlerde bu önbellek büyüyebilir.

Build cache kullanımını değerlendirmek için:

docker system df

docker system df

Daha sonra kullanılmayan build cache kaynaklarını temizlemek için:

docker builder prune

docker builder prune

Komutun daha kapsamlı temizlik yapan seçeneği:

docker builder prune -a

docker builder prune -a

olarak kullanılabilir.

Bu işlem uygulamanın kalıcı verilerini temizlemek için tasarlanmamıştır. Ancak silinen önbellek katmanlarının sonraki build işlemlerinde yeniden oluşturulması gerekebilir.

Sonuç olarak sonraki imaj oluşturma işlemi daha uzun sürebilir ve ek ağ trafiği oluşabilir.

Build cache temizliği, özellikle CI/CD sunucularında periyodik bakımın bir parçası olabilir. Fakat her deployment sonrasında bütün önbelleği silmek, Docker’ın performans avantajlarından birini ortadan kaldırabilir.

Docker Volume Temizliğinde Neden Dikkatli Olunmalı?

Docker disk temizliği sırasında en fazla dikkat gerektiren kaynaklardan biri volume’lardır.

Volume’lar container yaşam döngüsünden bağımsız olarak veri saklamak için kullanılır.

Bir PostgreSQL veritabanının dosyaları, WordPress medya yüklemeleri veya uygulamanın kalıcı depolama alanı Docker volume üzerinde tutulabilir.

Bu nedenle bir volume’un aktif bir container tarafından kullanılmaması, içindeki verilerin önemsiz olduğu anlamına gelmez.

Mevcut volume’ları listelemek için:

docker volume ls

docker volume ls

Belirli bir volume hakkında bilgi almak için:

docker volume inspect VOLUME_ADI

docker volume inspect VOLUME_ADI

Buradaki VOLUME_ADI gerçek volume adıyla değiştirilmelidir.

İnceleme sırasında volume’un hangi uygulamaya ait olduğu, hangi container’larda kullanıldığı ve yedek durumunun ne olduğu belirlenmelidir.

Docker volume prune ne yapar?

Kullanılmayan volume’ları temizlemek için Docker’da şu komut bulunur:

docker volume prune

docker volume prune

Bu komut, varsayılan olarak kullanılmayan anonim local volume’ları kaldırır. İsimlendirilmiş volume’ları da kapsayan daha geniş bir temizleme davranışı için desteklenen sürümlerde --all seçeneği kullanılabilir.

Ancak her iki durumda da kaldırılan volume’lardaki veriler kaybolabilir.

Önemli: Veritabanı veya kullanıcı dosyası içerebilecek volume’lar, güncel ve geri yüklenebilir bir yedek doğrulanmadan temizlenmemelidir.

Volume temizliği, yalnızca disk alanı kazanma amacıyla rutin ve kontrolsüz çalıştırılacak bir işlem olarak değerlendirilmemelidir.

Docker Log Dosyaları Neden Çok Fazla Yer Kaplar?

Docker’da disk tüketiminin daha az fark edilen nedenlerinden biri container loglarıdır.

Uygulamalar standart çıktı (stdout) ve standart hata (stderr) akışlarına bilgi yazabilir. Docker, kullanılan logging driver’a bağlı olarak bu kayıtları saklar veya başka bir log sistemine iletir.

Docker Engine’in varsayılan logging driver’ı json-file sürücüsüdür.

Bu sürücü, log kayıtlarını JSON biçiminde saklar. Varsayılan yapılandırmada log rotasyonu etkin değildir.

Dolayısıyla sürekli log üreten bir uygulama, uzun süre çalıştığında oldukça büyük dosyalar oluşturabilir.

Örneğin her isteğin ayrıntılı olarak kaydedildiği bir API uygulaması, yoğun trafik altında çok fazla log satırı üretebilir.

Bu durum özellikle debug seviyesindeki kayıtların üretim ortamında açık bırakıldığı sistemlerde belirginleşir.

Docker’ın resmî logging driver dokümantasyonu, disk alanının tükenmesini önlemek için log rotasyonu yapan local sürücüsünü önerir.

Container logları nasıl görüntülenir?

Bir container’ın loglarını incelemek için:

docker logs CONTAINER_ADI

docker logs CONTAINER_ADI

Son 100 satırı görüntülemek için:

docker logs --tail 100 CONTAINER_ADI

docker logs --tail 100 CONTAINER_ADI

Belirli bir zaman aralığındaki kayıtları incelemek için --since ve --until parametreleri kullanılabilir.

Ancak burada iki farklı log türünü ayırmak gerekir.

docker logs komutu uygulamanın container üzerinden toplanan loglarını görüntüler.

Docker daemon’unun kendi kayıtları ise işletim sistemi yapılandırmasına göre farklı bir konumda tutulabilir.

Systemd kullanan Linux sistemlerinde Docker daemon kayıtları şu komutla incelenebilir:

sudo journalctl -u docker.service

sudo journalctl -u docker.service

Docker daemon logları, container uygulama loglarından farklı sorunları teşhis etmek için kullanılır.

Docker Log Rotation Nasıl Yapılandırılır?

Log dosyalarının kontrolsüz büyümesini önlemek için en etkili yöntemlerden biri log rotasyonudur.

Log rotasyonu, kayıt dosyalarının belirli boyut veya saklama kurallarına göre döndürülmesini sağlar.

Böylece logların sonsuza kadar aynı dosyada birikmesi önlenebilir.

Docker’da bu işlem kullanılan logging driver’a göre farklı şekilde yapılandırılır.

Yöntem 1: Docker local logging driver kullanmak

Docker’ın önerdiği seçeneklerden biri local logging driver’dır.

Bu sürücü logları Docker tarafından yönetilen bir biçimde saklar ve varsayılan olarak log rotasyonu uygular.

Linux üzerinde Docker Engine’in genel yapılandırması çoğunlukla şu dosyada bulunur:

/etc/docker/daemon.json

Yeni container’lar için varsayılan logging driver’ı local olarak ayarlamak amacıyla şu yapılandırma kullanılabilir:

{
  "log-driver": "local"
}

{
  "log-driver": "local"
}

Bu örnek mevcut daemon.json dosyasının üzerine doğrudan yazılmamalıdır. Dosyada başka ayarlar bulunuyorsa yeni seçenekler mevcut JSON yapısına uygun şekilde eklenmelidir.

Değişiklikten önce yapılandırmanın yedeği alınmalıdır.

Ayrıca mevcut Docker daemon yapılandırmasının geçerli olduğundan emin olmak gerekir.

Yapılandırma değişikliği tamamlandıktan sonra Docker Engine’in yeniden başlatılması gerekebilir.

Systemd kullanılan Linux sistemlerinde:

sudo systemctl restart docker

sudo systemctl restart docker

komutu kullanılabilir.

Ancak bu işlem üretim ortamlarında kesinti riski taşıyabilir. Docker daemon’unun yeniden başlatılması, kullanılan yapılandırmaya ve container çalışma koşullarına bağlı olarak servisleri etkileyebilir.

Bu nedenle bakım penceresi planlanmadan çalıştırılmamalıdır.

Bir başka önemli ayrıntı da yeni varsayılan logging driver ayarlarının mevcut container’lara otomatik olarak uygulanmamasıdır.

Mevcut container’ların yeni logging driver ayarlarını kullanması için uygun yapılandırmayla yeniden oluşturulmaları gerekir.

Yöntem 2: json-file için log boyutu sınırı belirlemek

Mevcut sistemde json-file logging driver kullanılmaya devam edilecekse log rotasyonu bu sürücü için de yapılandırılabilir.

Örnek yapılandırma:

{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  }
}

{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  }
}

Bu örnekte:

• max-size, tek bir log dosyasının rotasyon eşiğini belirler.
• max-file, tutulacak log dosyası sayısını sınırlar.
• 10m, 10 megabaytlık boyut eşiğini ifade eder.
• 3, en fazla üç döndürülmüş/aktif log dosyası tutulmasını sağlar.

Bu değerler örnektir. Uygulamanın log üretim miktarına ve kayıt saklama ihtiyacına göre değiştirilmelidir.

Docker yapılandırmasında log-opts değerlerinin karakter dizisi olarak yazılması gerekir. Bu nedenle max-file değeri sayısal görünmesine rağmen tırnak içinde belirtilmiştir.

Bu yapılandırma da mevcut container’lara otomatik uygulanmaz. Yeni ayarların etkili olması için ilgili container’ların yeniden oluşturulması gerekir.

Log rotasyonu, disk kullanımını sınırlandırmaya yardımcı olurken eski kayıtların zamanla silinmesine neden olabilir. Denetim veya güvenlik nedeniyle uzun süre log saklanması gereken sistemlerde merkezi log toplama altyapısı ayrıca değerlendirilmelidir.

Docker Log Dosyalarını Manuel Silmek Güvenli mi?

Disk alanı tamamen dolduğunda büyük log dosyalarını doğrudan silmek cazip görünebilir.

Ancak Docker’ın yönettiği json-file log dosyalarına harici araçlarla doğrudan müdahale edilmesi önerilmez.

Docker’ın resmî belgelerinde bu dosyaların daemon tarafından yönetildiği ve dışarıdan değiştirilmesinin beklenmeyen davranışlara yol açabileceği belirtilir.

Bu nedenle Docker veri dizini altında bulunan log dosyalarını rastgele silmek veya boşaltmak, kalıcı bakım yöntemi olarak kullanılmamalıdır.

Daha sağlıklı yaklaşım şu sırayı izlemektir:

1. Disk kullanımının gerçekten container loglarından kaynaklandığını doğrulamak.
2. İlgili container’ın neden yoğun log ürettiğini belirlemek.
3. Gereksiz debug kayıtlarını uygulama seviyesinde azaltmak.
4. Logging driver ve rotasyon politikasını düzenlemek.
5. Mevcut container’ları kontrollü şekilde yeni yapılandırmayla oluşturmak.

Diskin tamamen dolduğu acil durumlarda uygulanacak müdahale, sistemin veri saklama gereksinimleri ve mevcut Docker yapılandırması dikkate alınarak planlanmalıdır.

Docker System Prune Komutu Ne İşe Yarar?

Docker’ın en çok kullanılan disk temizleme komutlarından biri:

docker system prune

docker system prune

komutudur.

Bu işlem kullanılmayan Docker kaynaklarını temizlemek için tasarlanmıştır.

Varsayılan davranışında durdurulmuş container’lar, kullanılmayan ağlar, dangling imajlar ve kullanılmayan build cache kaynakları temizlenebilir.

Ancak her ortamda doğrudan çalıştırılması doğru değildir.

Özellikle durdurulmuş container’ların yeniden kullanılması planlanıyorsa veya mevcut imajların geri dönüş amacıyla saklanması gerekiyorsa temizlik öncesinde kontrol yapılmalıdır.

docker system prune -a ne yapar?

Daha kapsamlı temizlik için:

docker system prune -a

docker system prune -a

komutu kullanılabilir.

-a seçeneği, herhangi bir container tarafından kullanılmayan imajları da temizleme kapsamına alır.

Bu durum disk alanı kazandırabilir ancak sonraki deployment işlemlerinde imajların yeniden indirilmesini gerektirebilir.

docker system prune –volumes tehlikeli mi?

Volume temizliği kapsamını genişletmek için:

docker system prune --volumes

docker system prune --volumes

seçeneği bulunur.

Bu komut kullanılmayan anonim volume’ları da temizleme kapsamına alabilir.

Ancak volume’ların uygulama verileri barındırabileceği unutulmamalıdır. Container tarafından kullanılmayan bir volume, eski bir veritabanının tek kopyasını içeriyor olabilir.

Bu nedenle volume temizliği, yedek kontrolü ve uygulama bağımlılıkları doğrulanmadan yapılmamalıdır.

Docker’ın resmî system prune açıklaması, hangi kaynakların temizlendiğini ve seçeneklerin kapsamını ayrıntılı biçimde belirtir.

Docker Disk Temizleme Komutları Karşılaştırması

Aşağıdaki tablo, temel Docker temizleme komutlarının kapsamını özetler.

Buradaki temel ilke, en kapsamlı temizleme komutuyla başlamak yerine hangi kaynakların gereksiz olduğunun belirlenmesidir.

Örneğin disk tüketiminin büyük bölümü build cache kaynaklıysa yalnızca build cache temizliği yeterli olabilir.

Buna karşılık sorunun nedeni log dosyalarıysa imaj temizlemek geçici olarak alan kazandırsa bile asıl problem devam eder.

Docker Dışındaki Disk Kullanımı da Kontrol Edilmeli

Docker disk kullanım raporu düşük görünmesine rağmen sunucunun diski dolu olabilir.

Bu durumda sorun Docker dışındaki dosyalardan kaynaklanıyor olabilir.

Sistem logları, veritabanı yedekleri, uygulama dosyaları, geçici dosyalar ve diğer servislerin oluşturduğu kayıtlar ayrıca incelenmelidir.

Linux üzerinde genel disk kullanımını kontrol etmek için:

df -h

df -h

komutu kullanılabilir.

Dosya sistemi inode kullanımını kontrol etmek içinse:

df -i

df -i

komutu yararlıdır.

Bazı sistemlerde disk üzerinde boş alan bulunmasına rağmen inode sınırına ulaşılması nedeniyle yeni dosya oluşturulamayabilir.

Bu durum özellikle çok sayıda küçük dosya üreten uygulamalarda önem kazanır.

Docker’ın kendi raporuyla işletim sisteminin disk kullanım raporu arasında fark varsa, kullanılan depolama sürücüsü, volume yapısı ve Docker dışındaki dosyalar birlikte değerlendirilmelidir.

Docker Disk Alanının Tekrar Dolması Nasıl Önlenir?

Disk temizliği, sorunun nedenini ortadan kaldırmadığında yalnızca geçici rahatlama sağlar.

Kalıcı çözüm için Docker ortamının veri üretim ve saklama davranışı kontrol altında tutulmalıdır.

Log rotasyonu varsayılan hale getirilmeli

Yeni container’lar için uygun logging driver ve rotasyon ayarları belirlenmelidir.

Özellikle üretim ortamlarında debug seviyesindeki kayıtların sürekli açık bırakılması önlenmelidir.

Disk kullanımı düzenli izlenmeli

Sunucunun toplam disk alanı, Docker kaynaklarının kullanımı ve kritik volume’ların büyüklüğü izlenmelidir.

Disk doluluk oranı kritik seviyeye ulaşmadan önce uyarı oluşturulması, hizmet kesintisi riskini azaltır.

Deployment süreçleri gözden geçirilmeli

Sık imaj oluşturulan sistemlerde eski imajların ve build cache kaynaklarının birikmesi normaldir.

Ancak bu kaynakların ne kadar süre tutulacağı ve hangi koşullarda temizleneceği belirlenmelidir.

Kalıcı veriler yedeklenmeli

Özellikle veritabanı ve kullanıcı dosyası içeren volume’lar düzenli olarak yedeklenmelidir.

Yedekleme işleminin başarılı görünmesi tek başına yeterli değildir. Gerektiğinde geri yükleme yapılabildiği de doğrulanmalıdır.

Otomatik temizlik dikkatle planlanmalı

Zamanlanmış temizleme komutları bazı ortamlarda yararlı olabilir. Ancak bütün Docker kaynaklarını belirli aralıklarla kontrolsüz temizlemek, üretim sistemleri için uygun bir yaklaşım değildir.

Otomasyon kullanılacaksa kapsamı açıkça tanımlanmalı, gerekli kaynaklar korunmalı ve işlem sonuçları kayıt altına alınmalıdır.

Sık Sorulan Sorular

Docker system prune çalışan container’ları siler mi?

Varsayılan docker system prune işlemi çalışan container’ları kaldırmak için tasarlanmamıştır. Ancak durdurulmuş container’ları ve bazı kullanılmayan Docker kaynaklarını temizleyebilir. Bu nedenle komutun kapsamı çalıştırılmadan önce kontrol edilmelidir.

Docker volume prune veritabanını silebilir mi?

Evet. Bir veritabanının verileri, temizleme kapsamına giren kullanılmayan bir volume üzerinde bulunuyorsa veri kaybı yaşanabilir. Bu nedenle volume temizliği öncesinde yedek ve uygulama bağımlılıkları doğrulanmalıdır.

Docker log rotation mevcut container’lara uygulanır mı?

Docker daemon yapılandırmasındaki varsayılan logging driver değişiklikleri mevcut container’lara otomatik olarak uygulanmaz. İlgili container’ların yeni yapılandırmayla yeniden oluşturulması gerekir.

Docker disk temizleme işlemi ne sıklıkla yapılmalı?

Sabit bir süre bütün sistemler için uygun değildir. Temizlik sıklığı deployment yoğunluğuna, log üretimine, disk kapasitesine ve veri saklama gereksinimlerine göre belirlenmelidir.

Docker loglarını tamamen kapatmak doğru mu?

Bazı özel senaryolarda log toplama kapatılabilir ancak genel olarak önerilen ilk çözüm değildir. Loglar hata teşhisi, güvenlik incelemesi ve uygulama davranışını anlamak için önemlidir. Çoğu sistemde uygun rotasyon ve saklama politikası daha dengeli bir yaklaşımdır.

Sonuç: Önce Disk Tüketimini Ölçün, Sonra Temizleyin

Docker kullanılan sunucularda disk alanının dolması, tek bir nedene bağlı değildir. Eski imajlar, durdurulmuş container’lar, build cache, volume’lar ve log dosyaları farklı oranlarda disk tüketebilir.

Bu nedenle güvenli disk yönetimi, doğrudan temizleme komutlarını çalıştırmak yerine mevcut kullanımın analiz edilmesiyle başlamalıdır.

docker system df ve ilgili inceleme komutları, hangi kaynakların alan tükettiğini belirlemeye yardımcı olur. Ardından yalnızca gereksiz olduğu doğrulanan kaynaklar temizlenebilir.

Özellikle log rotasyonu, uzun vadeli disk yönetiminin önemli bir parçasıdır. Uygun logging driver seçimi, düzenli izleme ve kontrollü kaynak temizliği bir arada uygulandığında disk alanının beklenmedik biçimde tükenmesi daha kolay önlenebilir.

Docker ortamlarında karşılaşılan disk tüketimi sorunları ve işe yarayan çözüm yöntemleri, benzer altyapıları yöneten geliştiriciler için değerli deneyimlerdir. Özellikle hangi kaynağın beklenmedik şekilde büyüdüğünü belirten teknik paylaşımlar, diğer kullanıcıların sorunları daha hızlı teşhis etmesine yardımcı olabilir.