Bir kapsayıcıda bir veritabanı başlatırsınız, biraz veri eklersiniz, kapsayıcıyı çıkarırsınız ve yeni bir tane başlatırsınız. Veriler gitti. Hemen hemen herkes bu dersi zor yoldan öğrenir. Docker birimleri ve bağlama bağlantıları, verileri herhangi bir konteynerin ömrü boyunca canlı tutmak için mevcuttur.

Bu kılavuz her birinin nasıl çalıştığını ve nasıl seçileceğini açıklamaktadır. Buradaki komutlar ve dosyalar, Docker’ın belgelenmiş davranışına dayanan standart örneklerdir ve bunları bu makale için çalıştırmadık, bu nedenle bunları ilk önce tek kullanımlık veriler üzerinde deneyin. Ayrıntılar Docker sürümleri arasında ve Docker Masaüstünde farklılık gösterebilir. Container’lar konusunda yeniyseniz Yeni başlayanlar için Docker eğitimimiz ile başlayın.

Kapsayıcı verileri neden kayboluyor?

Docker görüntüsü salt okunur katmanlardan oluşur. Bir konteyner başladığında, Docker üstüne ince bir yazılabilir katman ekler ve tüm değişiklikler oraya gider. Bu katman durma ve yeniden başlama durumunda hayatta kalır, ancak kapsayıcı silindiğinde kaldırılır.

docker run -d --name db -e POSTGRES_PASSWORD=devonly postgres:17
# ... create tables and add data ...
docker rm -f db
docker run -d --name db -e POSTGRES_PASSWORD=devonly postgres:17
# The data you added is not there

Bu tasarım gereğidir, çünkü kapları serbestçe değiştirmenize olanak sağlar. Bu, saklamanız gereken her şeyin konteynerin dışında yaşaması gerektiği anlamına gelir. Bunu yapmanın üç yolu vardır:

Docker birimleri ve bağlama bağları yan yana

Adlandırılmış ciltler

Birim, Docker tarafından oluşturulan ve yönetilen depolama alanıdır. Ona ismiyle hitap edersiniz ve fiziksel olarak nerede yaşadığını umursamanıza gerek yoktur.

docker volume create pgdata

docker run -d --name db \
  -e POSTGRES_PASSWORD=devonly \
  -v pgdata:/var/lib/postgresql/data \
  postgres:17

Artık veritabanı dosyaları pgdata‘de bulunmaktadır. Kabı silin ve aynı hacimde yeni bir kap başlatın; verileriniz hâlâ orada olacaktır. Linux’ta birimler genellikle /var/lib/docker/volumes/ altında bulunur, ancak bu dosyaları doğrudan düzenlememelisiniz. Docker Desktop’ta normal bir klasörde değil, sanal bir makinenin içinde yaşarlar.

Kabın içindeki yol resme bağlıdır; bu nedenle resmin belgelerini kontrol edin. Yanlış yola montaj yapmak klasik bir hatadır: Her şey çalışıyor gibi görünür ancak veriler hala konteyner katmanına yazılmaktadır. Bir görüntünün daha yeni ana sürümleri de bu yolu değiştirebilir; bu nedenle, yükseltme yapmadan önce sürüm notlarını okuyun.

Docker, eğer mevcut değilse otomatik olarak adlandırılmış bir birim oluşturacaktır. İsimsiz olarak oluşturulan anonim bir birim de çalışır, ancak uzun, rastgele bir kimlik alır ve izini kaybetmesi kolaydır. Her zaman birimlerinize ad verin.

Bağlama bağlantıları

Bağlama montajı, belirli bir ana bilgisayar yolunu doğrudan kapsayıcıya eşler. Her iki taraf da aynı dosyaları anında görür. Bu, düzenleyicinizdeki düzenlemelerin yeniden oluşturma gerekmeden çalışan kapsayıcıda etkili olması nedeniyle onu geliştirme için mükemmel kılar:

docker run -d --name web \
  -p 8080:80 \
  -v "$(pwd)/site:/usr/share/nginx/html:ro" \
  nginx:1.27

site/‘de bir dosyayı düzenleyin, tarayıcıyı yenileyin, değişikliği göreceksiniz. :ro, kabın içindeki montajı salt okunur hale getirir; bu, kabın oraya yazmaya gerek olmadığı durumlarda iyi bir alışkanlıktır.

Bağlama montajları bazı ödünleşimlerle birlikte gelir:

• Sizi ana makineye bağlarlar. Yolun her makinede mevcut olması gerekir, dolayısıyla kurulumlar daha az taşınabilirdir.
• Görselin içeriğini gizlerler. Eğer /app‘nin üzerine montaj yaparsanız, görüntünün içinde ne varsa görünmez hale gelir. Yaygın bir örnek, node_modules‘ün kaybolmasıdır.
• Ana makineyi açığa çıkarırlar. Yazılabilir bağlantıya sahip bir kapsayıcı, gerçek ana makine dosyalarını değiştirebilir veya silebilir. Riski tam olarak anlamadığınız sürece asla / gibi hassas yolları veya Docker soketini monte etmeyin.
• Performans farklılık gösterebilir. MacOS ve Windows için Docker Desktop’ta dosya paylaşımı, sanallaştırma sınırlarını aşar ve Linux’a göre daha yavaş olabilir.

tmpfs bağlar

Bir tmpfs montajı ana bilgisayarın belleğinde bulunur ve hiçbir zaman konteyner katmanına yazılmaz. Konteyner durduğunda kaybolur, dolayısıyla geçici dosyalara, önbelleklere ve kısa ömürlü hassas verilere uygundur:

docker run -d --tmpfs /app/cache:size=64m myapp:1.0

tmpfs Linux ana bilgisayarlarında mevcuttur. Ayrıca, verileri saklamayı umursamadığınız tek kullanımlık test ortamlarında veritabanlarını da hızlandırabilir.

-v veya –mount?

Her iki bayrak da çalışıyor. --mount daha uzundur, ancak daha açıktır ve birçok kişi bunu komut dosyalarında tercih eder:

# Short form
docker run -v pgdata:/var/lib/postgresql/data postgres:17

# Explicit form
docker run --mount type=volume,source=pgdata,target=/var/lib/postgresql/data postgres:17

# Bind mount, read-only
docker run --mount type=bind,source="$(pwd)"/site,target=/usr/share/nginx/html,readonly nginx:1.27

Anlamlı bir fark var. -v ile sizin için boş bir klasör olarak eksik bir ana bilgisayar yolu oluşturulur ve bu, bir yazım hatasını gizleyebilir. --mount ve bir bağlama türüyle Docker bunun yerine bir hata bildirir. Ayrıca, -v ile sol taraf türe karar verir: ad, birim anlamına gelir ve yol, bağlama montajı anlamına gelir. Yani -v data:/x ve -v ./data:/x çok farklı şeyler yaparlar.

Docker Compose’daki birimler

Çoğu gerçek proje, depolamayı bir Compose dosyasında bildirir. Bu, her biri kendi görevi için her iki türü de kullanır:

services:
  web:
    build: .
    ports:
      - "3000:3000"
    volumes:
      - ./src:/app/src      # bind mount: live code
    depends_on:
      - db

  db:
    image: postgres:17
    environment:
      POSTGRES_PASSWORD: devonly
    volumes:
      - pgdata:/var/lib/postgresql/data   # named volume: data

volumes:
  pgdata:

Adlandırılmış birimler üst düzey volumes bölümünde bildirilmelidir. Gerçek adın ön ekini proje adıyla birlikte oluşturun. Tam bir açıklama için Docker Compose eğitimimize bakın.

Yararlı ses seviyesi komutları

Bu işlem geri alınamayacağından onaylamadan önce prune‘in neyi kaldıracağını kontrol edin. Şu anda hiçbir kapsayıcının kullanmadığı birimler hâlâ önemli verileri barındırıyor olabilir.

Bir birimi yedekleme ve geri yükleme

Bir birim, hem birimi hem de ana klasörü bağlayan kısa ömürlü bir kapsayıcı çalıştırılarak yedeklenebilir:

# Back up
docker run --rm \
  -v pgdata:/data:ro \
  -v "$(pwd)":/backup \
  alpine tar czf /backup/pgdata.tar.gz -C /data .

# Restore into a new volume
docker volume create pgdata_restored
docker run --rm \
  -v pgdata_restored:/data \
  -v "$(pwd)":/backup \
  alpine tar xzf /backup/pgdata.tar.gz -C /data

Canlı bir veritabanı için bunun gibi dosyaların kopyalanması tutarsız bir durumu yakalayabilir. Önce konteyneri durdurun veya daha iyisi PostgreSQL için pg_dump gibi veritabanının kendi aracını kullanın. Ve asla geri yüklemediğiniz bir yedekleme aslında sadece bir umuttur, bu nedenle geri yüklemeyi test edin.

Dosya izinleri

Bağlamalarda en sık karşılaşılan sorun “İzin reddedildi” sorunudur. Dosyalar, sayısal kullanıcı ve grup kimliklerini Linux’ta tutar; dolayısıyla bir kapsayıcı, kullanıcı 1000 olarak çalışırsa ve ana bilgisayar klasörü başka bir kullanıcıya aitse, yazma işlemleri başarısız olur. Bunu düzeltmenin bazı yolları:

• Kapsayıcıyı eşleşen bir kullanıcıyla çalıştırın: docker run --user "$(id -u):$(id -g)" ...
• Dockerfile en iyi uygulamalarımızda açıklandığı gibi, görüntünüzde doğru sahipliği ayarlayın.
• Yeni bir birim ilk kullanıldığında görüntü klasörünün sahipliğini üstlendiğinden, veriler için adlandırılmış birimleri tercih edin.
• SELinux kullanan sistemlerde bağlama bağlantılarının :z veya :Z etiketine ihtiyacı olabilir.

Linux komutları kılavuzumuzun açıkladığı gibi, chmod 777‘in cazibesinden kaçının.

Hangisini kullanmalısınız?

Bu son satır önemli. Üretimde kod görüntüye aittir, böylece test ettiğiniz şey çalıştırdığınız şeydir. Kümelerde veri depolama, daha geniş Kubernetes belgelerinde ele alınan kalıcı birimler aracılığıyla yine farklı şekilde çalışır. Docker ve Kubernetes kılavuzumuz bu ikisinin nasıl bir ilişki içinde olduğunu açıklıyor.

Yaygın hatalar

• Yanlış yola montaj. Veriler hâlâ konteyner katmanında bulunuyor ve daha sonra kayboluyor.
• down -v‘yi rastgele çalıştırıyorum. Bu, adlandırılmış birimlerinizi siler.
• Göreceli yolları -v ile kullanmak. -v data:/x gibi formlar, klasör eşlemesi yerine bir birim oluşturur.
• Gizli dizileri yazılabilir bağlama bağlantılarına yerleştirme. Bunları salt okunur olarak ekleyin veya bir gizli dizi özelliği kullanın.
• İki veritabanı kapsayıcısını bir birime yönlendirme. Bu, verileri bozabilir.
• Yedeği yok. Birim, yedek değildir. Aynı diskte yaşıyor.

Son sözler

Temel kural kısadır: veriler için adlandırılmış birimler, düzenlediğiniz kod için bağlama bağlantıları ve uzun sürmemesi gereken şeyler için tmpf’ler. Tek kullanımlık bir veritabanında deneyin. Adlandırılmış bir birim oluşturun, bir satır ekleyin, kapsayıcıyı silin, yeni bir birim başlatın ve satırınızın hayatta kaldığını doğrulayın. Daha sonra ihtiyaç duymadan önce yedekleme ve geri yükleme işlemleri yapın.

Sık sorulan sorular

Öğrenmeye devam et