- Konu sahibi
- #1
Container yeniden oluşturulunca veriler neden kaybolur?
Eski container kaldırılıp yenisi oluşturulduğunda eski yazılabilir katman da kaldırılır; yeni container aynı image temeline dayanan yeni bir katmanla başlar. Uygulamanın verileri bu geçici katmana yazıldıysa dosyalar kaybolur. Verilerin kalıcı olması için uygulamanın veri dizinini bir Docker volume’una veya ana makinedeki bir bind mount dizinine bağlamanız gerekir.
Container depolama modeli nasıl çalışır?
Bir image salt okunur temel katmanlardan oluşur. Container başlatıldığında bunun üzerine container’a özel, yazılabilir bir katman eklenir. Uygulamanın container içindeki
/var/lib/app veya /data gibi bir dizine yazdığı dosyalar normalde bu katmanda tutulur.Container yalnızca durdurulursa bu katman genellikle korunur. Ancak container silinip yeniden oluşturulursa, yeni container eski yazılabilir katmanı kullanmaz.
docker compose up --force-recreate, image değişikliği, yapılandırma değişikliği veya bir orkestratörün yeniden dağıtımı gibi işlemler yeni bir container oluşturabilir.Mevcut veriyi taşımadan eski container’ı kaldırmayın. Sonradan mount eklemek, eski container’ın kullanıcı verilerini otomatik olarak yeni depolamaya taşımaz. Önce uygulamaya uygun tutarlı yedeği alın, hedef depolamaya aktarımı ve geri yüklemeyi doğrulayın. Volume ve bind mount kullanıldığında ilgili dizin container’ın geçici katmanından ayrılır. Container silinse bile volume veya ana makinedeki bağlama dizini korunur; yeni container aynı depolamaya bağlanır.
Somut örnek
Bir uygulama veritabanını
/var/lib/app altında tutuyor ve bu dizin için hiçbir kalıcı depolama tanımlanmıyorsa, container içine yazılan users.db dosyası eski container’a aittir. Yeni container aynı image ile oluşturulsa bile image içinde sonradan oluşturulmuş bu dosya bulunmaz.Aşağıdaki deneme, gerçek uygulamadan ayrı ve boş bir klasörde compose.yaml dosyasıyla yapılır. BusyBox yalnızca test dosyasını tutan bir container’dır; veritabanı kurulumu değildir:
Kod:
services:
app:
image: busybox:stable
command: ["sleep", "3600"]
volumes:
- app-data:/data
volumes:
app-data:Burada /data örnek hedeftir. Gerçek uygulamada belgelenen veri dizinini kullanın; image dosyalarının bulunduğu bir yolu rastgele bağlamayın. Var olan dosyaların üstüne volume bağlamak o dosyaları görünmez kılabilir. Boş volume’un ilk bağlamada image içeriğiyle doldurulması, eski container’ın sonradan oluşan verisinin taşınmasıyla aynı şey değildir.
Hangi depolama türü ne zaman kullanılmalı?
Seçim, verinin kimin tarafından yönetileceğine ve yedekleme yöntemine bağlıdır.
| Depolama | Veri nerede tutulur? | Uygun kullanım |
|---|---|---|
| Container katmanı | Container’ın geçici yazılabilir katmanında | Geçici dosyalar, önbellek |
| Named volume | Docker’ın yönettiği kalıcı depolamada | Veritabanı ve uygulama verisi |
| Bind mount | Ana makinede seçilen dizinde | Host tarafından doğrudan yönetilecek dosyalar |
Yeniden oluşturma testinin adımları
Docker Engine ve Compose’un çalıştığı test ortamında, aynı klasörde aşağıdaki sırayı izleyin. Örnek bir saat uyuyan container kullanır; test boyunca çalışır durumda olmalıdır.
- Test projesini başlatın:
docker compose -p persistence-demo up -d. - Mount eşlemesini kontrol edin:
docker inspect persistence-demo-app-1çıktısındaki Mounts bölümünde hedef /data ve volume türü bulunmalı. - Test dosyasını yazın:
docker compose -p persistence-demo exec app sh -c 'echo kalici-test > /data/persistence-test.txt'. - Aynı proje adıyla container’ı yeniden oluşturun:
docker compose -p persistence-demo up -d --force-recreate. - Dosyayı okuyun:
docker compose -p persistence-demo exec app cat /data/persistence-test.txt.
Beklenen çıktı kalici-test olur. Bu, dosyanın aynı named volume üzerinden yeni container’a ulaştığını gösterir; yedek alındığını veya gerçek uygulama veritabanının tutarlı olduğunu kanıtlamaz. Dosya yoksa önce Mounts alanındaki kaynak adı/hedef yolu, proje adını ve komut hatalarını karşılaştırın.
Named volume kullanımı container yaşam döngüsünden bağımsızlığı kolaylaştırır. Bind mount ise dosyaların host üzerinde açıkça görülmesini ve başka araçlarla yönetilmesini sağlar; ancak izinler, sahiplik ve yol bağımlılığı yöneticiye aittir.
Sık yapılan hatalar
Volume’u yanlış hedefe bağlamak: Uygulama
/var/lib/app/data dizinine yazarken volume’u yalnızca /var/lib/app yerine başka bir konuma bağlamak beklenen sonucu vermez. Uygulamanın gerçek veri yolunu doğrulayın.Image içine veri yazılacağını sanmak: Çalışan container’da oluşturulan dosyalar otomatik olarak image’a eklenmez. Kalıcı uygulama verisi image güncellemesiyle korunmaz; image yalnızca uygulamanın temel dosyalarını taşır.
Volume ile volume içindeki veriyi karıştırmak: Container’ı silmek ile volume’u silmek aynı işlem değildir. Fakat volume silinirse içeriği de gider. Yeniden oluşturma öncesinde önemli volume’lar için ayrıca yedek alın.
Veritabanını yalnızca dosya kopyasıyla yedeklemek: Çalışan veritabanı dosyasını kopyalamak tutarsız bir yedek oluşturabilir. Veritabanının kendi dump veya yedekleme yöntemini kullanın; volume yedeği bunun yerine her zaman geçmez.
Sık sorulan sorular
Aynı Compose dosyasıyla farklı klasörde çalıştırınca neden boş veri görüyorum?
Varsayılan named volume adları Compose proje adıyla kapsamlanır; proje adı değişirse farklı bir volume oluşturulabilir. Eski verinin silindiğini varsaymadan önce eski/yeni volume adlarını ve Mounts alanını karşılaştırın. Testteki -p persistence-demo değeri proje adını açıkça sabitler.
