Contents — find the section you need
Change parameters and verify
Open the panel, then press Run to load Python. You can stop execution and reset parameters. Results are computed on this device. No Python installation is required.
Local execution steps below are optional for reproducing the source results; they are not required for the browser experiment.
The experiment controls are in English.
Explore storage boundaries in the browser
The panel models storage ownership and container connections. It does not run Docker or access your files. Choose a storage location and operation, then compare the stage diagram and evidence table. Local Docker commands below are optional follow-up work.
Each run starts from the same prepared fixture: /data/note.txt contains saved in the selected store, and /tmp/note.txt contains temporary in the container's writable layer. The image has no initial files at /data; application startup creates no files. The selected mount's read-only setting is applied after preparation. At the end, the model attempts to write a different file, /data/probe.txt. That marker never recreates the original note.
The named volume uses the default project-scoped name alpha_data. The external volume is pre-existing shared_data; the bind mount always uses the same absolute daemon-host path /srv/demo-data. Both fixed sources remain the same when changing projects. No custom volume name, anonymous volumes, tmpfs, driver options, image-to-volume population, permissions beyond the read-only mount, or other containers are modeled.
“Switch project” means alpha is taken down without deleting volumes, then beta is started. “Switch back” repeats that operation to return to alpha. A new empty beta_data can hide access to the original note without deleting alpha_data. The diagram distinguishes retained data from a readable connection. The read-only control applies only to mounts and has no effect in the writable-layer case.
Try these comparisons: restart versus recreate for the writable layer; ordinary down versus down --volumes for a managed named volume; project switching versus switching back; and managed versus external volumes during cleanup. Each removal scenario includes starting the service again. Metrics are binary outcomes (1 = yes, 0 = no), not probabilities, timings, or recovery guarantees.
Rules were checked against Docker storage, volume lifecycle, bind mounts, Compose down and Compose volume names/external volumes on 2026-09-20. This is a documentation-based state model, not a live Engine conformance test. It models neither host failure nor application/database consistency. Continue to the restore Lab to examine separate recovery checks.
Bir konteynerin yeniden oluşturulması, verilerini otomatik olarak geri yüklemez. Depolama sınırlarını ve bir işlemin tam olarak neyi kaldırdığını belirleyin. Bu, 2026-09-07 tarihinde kontrol edilen, dokümantasyona dayalı bir alıştırmadır; test için üretim konteynerleri veya birimleri kullanılmamıştır.
Üç depolama konumu
| Konum | Sahiplik sınırı | Konteyner kaldırıldıktan sonra |
|---|---|---|
| Yazılabilir katman | Bireysel konteyner | Bu katmandaki değişiklikler kaybolur |
| Adlandırılmış birim | Bağımsız Docker tarafından yönetilen depolama | Birim kaldırılmadığı sürece kalır |
| Bağlama noktası | Belirtilen Docker ana bilgisayar yolu | Ana bilgisayar dosyaları olarak kalır |
Durdurma/yeniden başlatma, kaldırma/yeniden oluşturmadan farklıdır. Birim dokümantasyonu yaşam döngüsünü açıklar. Anonim birimlerin, --rm ile olan davranış da dahil olmak üzere farklı temizleme kuralları vardır; bu alıştırma adlandırılmış bir birim kullanır.
Tek kullanımlık adlandırılmış bir birim oluşturma alıştırması
Örnek, Docker Engine, Linux konteynerleri ve alpine:3.21 varsaymaktadır. Docker sürümünü ve indirilen gerçek imaj özetini kaydedin; etiketler değişebilir. Devam etmeden önce duskcoil-lifetime-demo'nun kullanılmadığını docker volume ls ile kontrol edin:
docker volume create duskcoil-lifetime-demo
docker run --rm --mount type=volume,source=duskcoil-lifetime-demo,target=/data alpine:3.21 sh -c 'echo saved > /data/note.txt; echo temporary > /tmp/note.txt'
docker run --rm --mount type=volume,source=duskcoil-lifetime-demo,target=/data,readonly alpine:3.21 sh -c 'cat /data/note.txt; test ! -e /tmp/note.txt'
Beklenen: ikinci konteyner, /data/note.txt'dan kaydedilenleri okurken, /tmp/note.txt'si mevcut değildir. İlk konteyneri kaldırmak, adlandırılmış birimi olduğu gibi bırakır. İkinci bağlama salt okunurdur. Bu alıştırmaya üretim servis adlarını veya verilerini eklemeyin.
Bağlama noktası hangi ana bilgisayarı kullanır?
Bağlama noktaları, Docker daemon'unun ana bilgisayarındaki yollara atıfta bulunur. Uzak bir arka plan programı, yerel bilgisayarınızın dosyalarını göremeyebilir. Docker Desktop ayrıca bir sanal makine sınırı da getirir.
docker inspect <container>'da Tür, Kaynak, Hedef ve RW için Bağlantıları inceleyin. Uygulama ayarlarını değiştirmeden önce yanlış bir /data bağlantısını çözün. Bir bağlantı, altındaki mevcut dosyaları gizleyebilir; eksik verileri, başka bir bağlı dizin tarafından gizlenen verilerden ayırt edin.
Compose temizleme semantiğini okuyun
docker compose down, docker compose down --volumes'den farklıdır. İkincisi ayrıca Compose'da bildirilen adlandırılmış birimleri de hedefler; harici birimler ayrı olarak yönetilir. Aşağıdaki referansı kontrol edin.
Bir Compose proje adını değiştirmek, yeni adlandırılmış bir birimi seçebilir ve uygulamanın boş görünmesine neden olabilir. Bozulmayı varsaymadan önce gerçek adları inceleyin. Artık gerekli olmadığını doğruladıktan sonra alıştırma birimini yalnızca belirli adıyla kaldırın; geniş birim temizliği bu prosedürün bir parçası değildir.
Kalıcılık yedekleme değildir
Birim, verileri konteyner yaşam döngüsünden ayırır, ancak disk arızasına veya uygulama silinmesine karşı mutlaka koruma sağlamaz. Ayrı bir kopya saklayın ve geri yüklemeyi test edin. Canlı veritabanı dosyalarının kopyalanması tutarsız olabilir: uygulama tarafından desteklenen yedekleme prosedürlerini veya uygun kapatma/anlık görüntü koşullarını kullanın.
Yalnızca Görüntüler ve Compose dosyaları, kullanıcı yüklemelerini ve veritabanlarını atlayabilir. Yalnızca bir veritabanı, gerekli yapılandırmayı, anahtarları veya uyumlu sürümleri atlayabilir. Geri yüklenen uygulamanın verilerini gerçekten okuyabildiğini doğrulayın.
Depolama envanteri oluşturun
Her hizmet için konteyner içi yolu, gerçek bağlama noktasını, sahipliği/izinleri, yedekleme yöntemini, geri yükleme hedefini ve son geri yükleme test tarihini kaydedin. Ardından, temel verilerin kapsandığını kontrol etmek için ana sunucu geri yükleme alıştırmasına devam edin.
Yorumlar
Lütfen önce giriş yapın.
Henüz veri yok.