Docker Mount: Volumes, Bind Mounts ve tmpfs Açıklanıyor

Bir yapılandırma dosyasını güncellemek için Docker konteynerini durdurdunuz, ancak yeniden başlattığınızda tüm verilerin kaybolduğunu gördünüz. Bunu yaşadım.

Bu, konteynerlerin varsayılan olarak geçici olmasından kaynaklanır – kaldırıldıklarında yazılabilir katmanlarında saklanan tüm veriler kaybolur. Gerçek uygulamalar böyle çalışamaz. Yeniden başlatmalardan sağ çıkan veritabanlarına, kalıcı yapılandırma dosyalarına ve gerçekten erişebileceğiniz günlük dosyalarına ihtiyacınız var.

Docker mount, konteyner depolamasını harici konumlara bağlayarak bu sorunu çözer. Üç tür vardır: üretim verileri için volumes, geliştirme iş akışları için bind mounts ve bellekte tutulan geçici dosyalar için tmpfs.

Bu yazıda, kullanım senaryonuza uygun doğru bağlama türünü nasıl seçeceğinizi ve doğru şekilde nasıl uygulayacağınızı anlatacağım. Buradaki her şeyi anlayabilmek için Docker ve konteynerleştirme konusunda makul bir hakimiyet gerekir. Hızlıca ilerlemek için Intermediate Docker kursumuzu alın.

Docker Depolamayı Nasıl Ele Alır

Docker konteynerleri, varsayılan olarak her şeyi geçici sayan katmanlı bir dosya sistemi kullanır.

Bir Docker imajı oluşturduğunuzda, Dockerfile’ınızda yer alan her talimat yeni bir salt-okunur katman yaratır. Bu katmanlar iskambil destesindeki kartlar gibi üst üste yığılır. Python yüklü bir Ubuntu imajı çekerseniz, taban işletim sistemi için bir katman, Python için başka bir katman alırsınız.

Püf noktası şu ki bu katmanların hepsi salt-okunurdur. Onları değiştiremezsiniz.

Konteyner dosya sistemi ve yazılabilir katman

Bir konteyneri başlattığınızda, Docker en üste bir katman daha ekler – yazılabilir konteyner katmanı.

Tüm değişiklikler burada gerçekleşir. Oluşturduğunuz her dosya, değiştirdiğiniz her yapılandırma ve eklediğiniz her tablo kaydı burada yaşar.

Kulağa hoş gelse de sorun, bu katmanın konteynerin yaşam döngüsüne bağlı olmasıdır.

Konteyneri docker rm ile durdurup kaldırdığınızda, yazılabilir katman gider. Üzerinde çalıştığınız her şey silinir. Docker onay istemez. Her şeyi siler.

Bu tasarım, çalıştırmalar arasında hiçbir şeyi hatırlaması gerekmeyen durumsuz uygulamalar için mantıklıdır. Ama gerçek uygulamalar durumsuz değildir.

Neden mount’lara ihtiyaç var

Yazılabilir katmanın üretim ortamları için iki büyük sorunu vardır.

Birincisi, konteynerler durduğunda veriyi kaybedersiniz. Yeniden başlatmadan sonra tüm satırları unutan bir veritabanı konteynerinin ne anlamı var? Uygulamanız için tümleşik testler çalıştırmak dışında bir şey gelmiyor aklıma.

İkincisi, konteynerler arasında veri paylaşamazsınız. Diyelim bir web uygulaması ve aynı dosyalara erişmesi gereken bir arka plan işçisi çalıştırıyorsunuz. Bu dosyalar bir konteynerin yazılabilir katmanında yaşıyorsa, diğer konteyner onları göremez.

Docker mount’lar, konteynerleri konteyner yaşam döngüsünün dışında var olan depolamaya bağlayarak her iki sorunu da çözer. Ana makinenizden bir dizini veya Docker tarafından yönetilen bir volume’u bağlayabilirsiniz. Konteynerler kaldırıldığında bile verileriniz kalır. Birden fazla konteyner aynı konumu bağlayabilir ve dosyaları gerçek zamanlı paylaşabilir.

Bu yüzden mount kullanmanız gerekir. Şimdi mount türlerini ele alalım, ardından nasıl çalıştıklarını göstereceğim.

Docker Bağlama Türlerine Kısa Bakış

Docker kalıcı veriyi ele almak için üç yol sunar ve her biri farklı sorunları çözer. Her türün ne yaptığını ve ne zaman kullanmanız gerektiğini burada bulabilirsiniz.

Volumes

Volumes, Docker’ın kalıcı depolamaya varsayılan yanıtıdır.

Docker, ana makinenizde ayrılmış bir dizinde volume’ları sizin için oluşturur ve yönetir. Bu dizinin nerede olduğunu bilmenize gerek yok; her şey sizin yerinize halledilir. Bu, volume’ları farklı sistemler arasında taşınabilir ve üretimde güvenli kılar.

Bir konteyneri kaldırdığınızda volume olduğu gibi kalır. Yeni bir konteyner başlatıp aynı volume’u eklerseniz, tüm verileriniz bıraktığınız yerde olacaktır.

Volumes; üretim veritabanları, uygulama durumu ve kaybedemeyeceğiniz her tür veri için en iyi şekilde çalışır.

Bind mounts

Bind mount’lar, ana makinenizdeki belirli bir dizini doğrudan bir konteynere bağlar.

Ana makinede tam yolu seçersiniz – örneğin /home/user/project – ve Docker bunu konteynere eşler. Ana makinede bir dosyayı değiştirdiğinizde konteyner değişikliği anında görür. Konteynerde bir dosyayı değiştirirseniz, bu değişiklik ana makinenizde görünür.

Bu gerçek zamanlı eşitleme bind mount’ları geliştirme için ideal kılar.

Ancak bind mount’ların riskleri vardır. Ana makine yollarını konteynerlere açar ve diğer makinelerde olmayabilecek belirli dizin yapılarına bağımlıdır.

tmpfs mount’ları

tmpfs mount’lar verileri diskte değil, ana makinenizin belleğinde saklar.

Dosya sistemine hiçbir şey yazılmaz. Konteyner durduğunda veriler tamamen yok olur. Bu, tmpfs mount’larını kalıcı olmasını istemediğiniz geçici veriler için kullanışlı kılar – kimlik doğrulama belirteçleri, oturum verileri veya nasıl olsa yeniden oluşturacağınız önbellek dosyaları gibi.

Bununla birlikte, tmpfs mount’lar mevcut RAM ile sınırlıdır ve yalnızca Linux ana makinelerinde çalışır.

Kalıcı Veriler için Docker Volumes

Volumes, Docker’ın üretime hazır depolama çözümüdür ve aksi yönde belirli bir nedeniniz yoksa varsayılan olarak onları kullanmalısınız.

Tamamen Docker tarafından yönetilirler, farklı platformlarda tutarlı çalışırlar ve tasarım gereği konteyner kaldırıldığında bile varlığını sürdürürler. Veritabanları çalıştırıyor, uygulama durumu saklıyor veya tek bir konteynerden daha uzun yaşaması gereken herhangi bir veriyi işliyorsanız, çözüm volumes’tur.

Docker volume’lar nasıl çalışır

Docker volume’ları ana makinenizde ayrılmış bir dizinde saklar:

• Linux: /var/lib/docker/volumes/
• macOS: ~/Library/Containers/com.docker.docker/Data/vms/0/data/
• Windows: \\wsl$\docker-desktop-data\data\docker\volumes\, WSL2 arka ucu varsayılarak

Bu dizini doğrudan yönetmezsiniz. Docker, oluşturma, izinler ve temizlemeyi kendi API’siyle halleder. Bu ayrım, Linux, Mac veya Windows’ta olun, volume’ların aynı şekilde çalışması anlamına gelir; bu da konteyner kurulumunuzu geliştirme ve üretim ortamları arasında taşınabilir kılar.

Burada unutulmaması gereken, volume’ların herhangi bir konteynerden bağımsız olarak var olduğudur. Bir volume oluşturup bir konteynere eklediğinizde, uygulamanızı çalıştırıp sonra o konteyneri durdurup sildiğinizde, volume verilerinizle birlikte olduğu gibi kalır.

Yeni bir konteyner başlatıp aynı volume’u eklerseniz, verileriniz hâlâ orada olacaktır.

Volume oluşturma ve yeniden kullanma

Herhangi bir konteyneri başlatmadan önce adlı bir volume oluşturabilirsiniz:

docker volume create mydata

Ardından konteyneri çalıştırırken --mount bayrağını kullanarak ekleyin:

docker run -d \
  --name postgres-db \
  --mount source=mydata,target=/var/lib/postgresql/data \
  postgres:18

Bu, mydata volume’unu konteyner içinde Postgres’in veritabanı dosyalarını sakladığı /var/lib/postgresql/data yoluna bağlar.

Artık bu konteyneri durdurup kaldırabilir, ardından aynı volume ile yeni bir tane başlatabilirsiniz:

docker rm -f postgres-db

docker run -d \
  --name postgres-db-new \
  --mount source=mydata,target=/var/lib/postgresql/data \
  postgres:18

Veritabanınız tüm tablolar ve satırlarla geri gelir.

Volume’ların tüm amacı budur – konteyner yaşam döngüleri boyunca veri kalıcılığı.

Volume verilerini yönetme ve bakım

Sisteminizde hangi volume’ların olduğunu kontrol etmek için bu komutu çalıştırabilirsiniz:

docker volume ls

Ardından, belirli bir volume’un nerede saklandığını ve hangi konteynerlerin kullandığını görmek için şu komutu çalıştırarak inceleyebilirsiniz:

docker volume inspect mydata

Bu, ana makinenizdeki bağlama noktasını ve faydalı meta verileri gösterir. Ancak bu dizine doğrudan erişmeniz nadiren gerekir – bu, Docker’ın işidir.

Volume işiniz bittiyse ve kaldırmak istiyorsanız, şu komutu çalıştırın:

docker volume rm mydata

Docker, çalışan bir konteynere bağlı bir volume’u silmenize izin vermez. Önce konteyneri durdurun, sonra volume’u kaldırın.

Son olarak, kaynakları temizleyip disk alanı kazanmak isterseniz, kullanılmayan tüm volume’ları bir kerede kaldırmak için bu komutu çalıştırabilirsiniz:

docker volume prune

Üretim kurulumları için Docker, NFS, AWS EFS veya bulut blok depolama gibi harici depolama sistemlerine bağlanan volume sürücülerini destekler. Sürücüyü volume oluştururken belirtirsiniz, geri kalanını Docker halleder. Bu, verileri tamamen ana makinenizin dışında saklamanıza olanak tanır; bu da konteynerlerin sunucular arasında taşındığı yüksek kullanılabilirlik kurulumları için önemlidir.

Sırada bind mount’ları tartışalım.

Yerel Geliştirme için Bind Mount’lar

Bind mount’lar, bir konteynerin içinden ana makine dosya sisteminize doğrudan erişim sağlar ve geliştiricilerin onları sevmesinin nedeni tam olarak budur.

Yerel geliştirme için mükemmeldirler ancak üretim için riskli hale getiren ödünleşimler içerirler. Gerçek zamanlı dosya eşitlemesi ve sıfır derleme adımı elde edersiniz, ancak taşınabilirliği kaybeder ve güvenlik açıkları yaratabilirsiniz.

Bind mount’lar nasıl çalışır

Bir bind mount, ana makinenizdeki belirli bir dizini doğrudan bir konteynere eşler.

Tam yolu belirlersiniz – örneğin /home/user/myapp – ve Docker bunu konteyner içinde bir yolda kullanılabilir hale getirir. Kopyalama yok, Docker tarafından yönetilen depolama yok, soyutlama katmanı yok. Konteyner, ana makinenizdeki gerçek dosyaları görür.

Ana makinede bir dosyayı değiştirirseniz, konteyner bu değişikliği anında görür. Aynı şekilde, konteyner içinde bir dosyayı değiştirirseniz, ana makinede güncellenir. Her iki taraf da aynı dosyalarla gerçek zamanlı çalışır.

İşte bir bind mount örneği:

docker run -d \
  --name dev-app \
  --mount type=bind,source=/Users/dradecic/Desktop/app,target=/app \
  python:3.14

Bu, ana makinemdeki /Users/dradecic/Desktop/app yolunu konteyner içinde /app olarak bağlar. /Users/dradecic/Desktop/app içindeki bir Python dosyasını metin düzenleyicinizle düzenlediğimde, konteynerde çalışan uygulama değişikliği anında görür.

Daha kısa sözdizimini de kullanabilirsiniz:

Yaygın geliştirme iş akışları

En yaygın kullanım senaryosu, geliştirme sırasında kaynak kodunuzu bağlamaktır.

Diyelim bir FastAPI uygulaması geliştiriyorsunuz. Proje dizininizi konteynere bağlayabilir, sıcak yeniden yüklemeyi etkinleştirebilir ve tam bir geliştirme ortamı elde edebilirsiniz:

docker run -d \
  --name fastapi-dev \
  --mount type=bind,source=/Users/dradecic/Desktop/app,target=/app \
  -w /app \
  -p 8000:8000 \
  python:3.14 \
  sh -c "pip install fastapi uvicorn && uvicorn main:app --reload --host 0.0.0.0"

Referans olması için, main.py dosyam şudur:

from fastapi import FastAPI
from pydantic import BaseModel

app = FastAPI(
    title="FastAPI Docker Demo",
    description="A minimal FastAPI app running inside Docker",
    version="1.0.0",
)

class Item(BaseModel):
    name: str
    price: float
    in_stock: bool = True

@app.get("/")
def read_root():
    return {
        "message": "FastAPI is running",
        "docs": "/docs",
        "redoc": "/redoc",
    }

@app.get("/health")
def health_check():
    return {"status": "ok"}

@app.post("/items")
def create_item(item: Item):
    return {
        "message": "Item received",
        "item": item,
    }

Docker komutunu çalıştırdıktan sonra uygulama, ana makinemden 8000 portundan erişilebilir:

main.py dosyasını düzenleyicinizde düzenleyip kaydederseniz, FastAPI otomatik olarak yeniden yükler. İmajları yeniden oluşturma yok, konteynerleri yeniden başlatma yok. Kodunuzu yerelde yazar gibi yazarsınız, ancak uygulamanız tutarlı bir konteyner ortamında çalışır.

Riskler ve sınırlamalar

Bind mount’lar ana makine dosya sisteminizi konteynerlere açar ve bu güvenlik sorunları yaratabilir.

Bind mount’a sahip bir konteyner ana makinenizdeki dosyaları okuyup yazabilir. Varsayılan olan root olarak bir konteyner çalıştırırsanız, bağlanan dosyalara root erişimi olur. Kötü amaçlı kod veya ele geçirilmiş bir konteyner, bağlanan dizindeki her şeyi değiştirebilir veya silebilir.

Taşınabilirlik de başka bir sorundur.

Bind mount’lar, ana makinede belirli yolların var olmasına bağlıdır. /Users/dradecic/Desktop/app yolunuzda ya da bir üretim sunucusunda mevcut olmayabilir. Bu durum, konteynerlerin "her yerde çalışır" vaadini bozar.

Platform farklılıkları da söz konusudur. Windows ve Mac, Docker’ı çalıştırmak için bir VM kullanır, bu nedenle bind mount’lar ekstra bir çeviri katmanından geçer. Bu, dosya işlemlerini yavaşlatır ve dosya izleme ve sembolik bağlantılarla ilgili ince hatalara neden olabilir.

Üretim ortamları asla bind mount kullanmamalıdır.

Ana makineye özgü yollara fazlasıyla bağımlıdırlar, güvenlik açısından fazla risk taşırlar ve sürüm kontrolüne uygun değildirler. Volumes bu sorunların hepsini çözer; bu yüzden üretim standardıdırlar.

Bind mount’ları bir geliştirme aracı olarak görün – hızlı, kullanışlı ve güçlü, ancak üretime yaklaştırmak istemeyeceğiniz bir şey.

Geçici Veriler için tmpfs Mount’lar

tmpfs mount’lar verileri diske değil, ana makinenizin RAM’ine yazar. Bu da kalıcı olmasını istemediğiniz veriler için onları ideal kılar.

Bellek içi depolama davranışı

Bir tmpfs mount tamamen bellekte yaşar.

Docker, ana makinenizde RAM ayırır ve bunu konteyner içinde bir dosya sistemi olarak sunar. Bir tmpfs mount’una yazılan dosya asla diske dokunmaz. Veri, konteyner durana kadar bellekte kalır.

Konteyneri durdurduğunuzda, tmpfs mount içindeki her şey silinir. Gerekli bir temizlik yoktur, artık dosyalar yoktur, orada ne olduğuna dair bir iz yoktur. Konteyneri her yeniden başlattığınızda taze, boş bir tmpfs mount elde edersiniz.

Özetle, tmpfs mount’lar bilerek saklamak istemediğiniz veriler içindir – geçici hesaplamalar, oturum belirteçleri veya kullanımdan sonra kalıcı olmaması gereken hassas bilgiler.

Tipik kullanım alanları

En yaygın kullanım alanı sırları veya hassas verileri saklamaktır.

Diyelim bir konteynerin bir API anahtarına veya veritabanı parolasına ihtiyacı var. Bunu bir tmpfs mount’unda saklayın; böylece sır asla diskte depolanmaz. Konteyner durduğunda, sır bellekten kaybolur. Yanlışlıkla sürüm kontrolüne ekleyeceğiniz veya dosya sisteminde açık bırakacağınız bir dosya kalmaz.

Önbellekler de iyi bir seçenektir. Nasıl olsa yeniden oluşturacağınız derleme çıktıları, derlenmiş kod veya indirilen bağımlılıklar kalıcı olmak zorunda değildir. Bunları tmpfs’e koyarak konteynerin ömrü boyunca daha hızlı erişim sağlayın ve işiniz bittiğinde kaybolmalarına izin verin.

Geçici dosyalar da burada iyi çalışır – oturum verileri, kilit dosyaları veya yalnızca konteyner çalışırken anlamı olan ara işleme sonuçları gibi.

Temel yapılandırma

--tmpfs bayrağını kullanarak bir tmpfs mount oluşturmak için bu komutu çalıştırın:

docker run -d \
  --name temp-app \
  --tmpfs /tmp:rw,size=100m \
  python:3.14

Bu, konteyner içinde /tmp yolunda 100MB’lık bir tmpfs mount oluşturur. size seçeneği, mount’un ne kadar RAM kullanabileceğini sınırlar.

Ayrıca --mount sözdizimini de kullanabilirsiniz:

docker run -d \
  --name temp-app \
  --mount type=tmpfs,destination=/tmp,tmpfs-size=104857600 \
  python:3.14

tmpfs-size değeri bayt cinsindendir – 104857600 bayt 100MB eder.

Bir boyut sınırı belirtmezseniz, tmpfs sisteminizin RAM’inin yarısına kadarını kullanır. Bu bariz nedenlerle tehlikelidir. Her zaman açık boyut sınırları belirleyin.

Tek büyük dezavantaj, tmpfs mount’ların yalnızca Linux’ta çalışmasıdır.

Mac ve Windows Docker Desktop bunları desteklemez; çünkü Docker’ı bir Linux VM’i içinde çalıştırırlar ve tmpfs doğrudan çekirdek desteği gerektirir.

Docker Mount Sözdizimi ve Yapılandırma

Docker, mount’ları tanımlamak için iki yol sunar ve doğru sözdizimini seçmek komutlarınızın okunmasını ve hata ayıklanmasını kolaylaştırır.

Her iki yaklaşım da çalışır, ancak birden çok mount veya gelişmiş seçeneklere ihtiyaç duyduğunuzda biri daha iyi ölçeklenir.

-mount ve --volume

--mount bayrağı açık anahtar-değer çiftleri kullanırken, -v veya --volume iki nokta üst üste ile ayrılmış bir dize kullanır.

İşte aynı volume mount’unun her iki sözdizimiyle kullanımı:

# Using --mount
docker run -d \
  --mount type=volume,source=mydata,target=/app/data \
  python:3.14

# Using -v
docker run -d \
  -v mydata:/app/data \
  python:3.14

Her ikisi de mydata adlı bir volume oluşturur ve konteynerde /app/data yoluna bağlar.

--mount’u temel kurulumların ötesinde her şey için kullanın. Daha uzundur, ancak açık anahtarlar her kısmın ne yaptığını netleştirir. Salt-okunur erişim veya özel volume sürücüleri gibi seçenekler eklediğinizde okunabilir kalır; -v ise şifreli bir dize gibi görünebilir.

-v sözdizimi, komutları el ile yazdığınız basit geliştirme iş akışları için uygundur.

Yaygın mount seçenekleri

readonly seçeneği, konteynerlerin bağlanan veriyi değiştirmesini engeller:

docker run -d \
  --mount type=volume,source=mydata,target=/app/data,readonly \
  python:3.14

Bu, konteynerlerin okuması fakat asla değiştirmemesi gereken yapılandırma dosyaları veya referans verileri için kullanışlıdır. Salt-okunur mount’a yazmaya çalışan bir konteyner izin hatası alır.

Volume’lar için volume-nocopy seçeneği, konteyner imajındaki mevcut verilerin volume’a kopyalanmasını atlar:

docker run -d \
  --mount type=volume,source=mydata,target=/app/data,volume-nocopy \
  python:3.14

Varsayılan olarak Docker, imajda mount noktasında ne varsa yeni volume’a kopyalar. volume-nocopy ayarlandığında, imajda ne olduğundan bağımsız olarak boş bir volume elde edersiniz.

tmpfs mount’lar için tmpfs-size seçeneği bir bellek sınırı belirler:

docker run -d \
  --mount type=tmpfs,target=/tmp,tmpfs-size=104857600 \
  python:3.14

Bu, tmpfs mount’unu 100MB ile sınırlar. Bu olmadan bir tmpfs mount mevcut tüm RAM’i tüketebilir.

Mevcut verilerin üzerine mount etmek

Konteyner imajında zaten var olan bir dizine mount yaptığınızda, mount orada ne varsa tamamen gizler.

Diyelim imajınızda yerleşik yapılandırma dosyaları içeren bir /app/data dizini var. /app/data yoluna bir volume bağladığınızda, bu yapılandırma dosyaları kaybolur. Konteyner yalnızca volume içindekileri görür.

Bu, tüm mount türleri için geçerlidir – volumes, bind mounts ve tmpfs. Bağlanan içerik önceliklidir ve mount etkin olduğu sürece özgün dizine erişilemez.

Docker Compose ile Mount Kullanımı

Docker Compose, uygulama yığınınızdaki birden fazla konteyner arasında mount’ları tanımlamayı ve paylaşmayı kolaylaştırır.

docker run ile uzun mount bayrakları yazmak yerine her şeyi bir docker-compose.yml dosyasında tanımlarsınız. Nasıl yapacağınızı göstereyim.

Compose’ta volume ve bind mount tanımlama

İşte hem volume hem bind mount örnekleri içeren bir Compose dosyası:

services:
  service-1:
    image: ubuntu:latest
    command: sleep infinity
    volumes:
      - ./code:/app          # Bind mount for development
      - shared:/data         # Named volume shared with worker

  service-2:
    image: ubuntu:latest
    command: sleep infinity
    volumes:
      - shared:/data         # Same volume as service-1

volumes:
  shared:

volumes anahtarının her servisin altında tanımlanması, neyin bağlanacağını belirler. ./code gibi göreli yollar bind mount oluştururken, shared gibi isimler adlı volume’lara referans olur.

Üst düzey volumes bölümü, Compose’un oluşturup yöneteceği adlı volume’ları bildirir. Hem service-1 hem de service-2 aynı shared volume’u mount eder; böylece aynı dosyaları görürler. Bir konteynerden bir dosya yazın, diğeri anında okuyabilir.

sleep infinity komutu, yalnızca gösterim amacıyla konteynerleri çalışır durumda tutar; içlerine exec ile girebilirsiniz.

Verileri kalıcı kılma ve doğrulama

docker compose up -d ile yığınınızı başlatın, ardından mount’ların çalışıp çalışmadığını kontrol edin:

# Write data to the shared volume from app
docker compose exec service-1 sh -c "echo 'test' > /data/file.txt"

# Read it from worker
docker compose exec service-2 cat /data/file.txt

Her iki komut da çalışıyorsa, volume’larınız doğru yapılandırılmış demektir.

Şimdi her şeyi durdurup kaldırmak için bu komutu çalıştırabilirsiniz:

docker compose down

Adlı volume’larınız hâlâ mevcut olacaktır. Yığını tekrar docker compose up -d ile başlatırsanız, daha önce yazdığınız veriler yerinde kalır. Veritabanlarının dağıtımlar arasında kalıcı olmasının yolu budur – volume, konteynerden daha uzun yaşar.

Yığını durdururken volume’ları silmek için -v bayrağını ekleyin:

docker compose down -v

Bu, Compose dosyanızda tanımlanan tüm volume’ları kaldırır. Temiz bir başlangıç istediğinizde kullanın.

Volume’ları başlangıç verileriyle doldurma

En yaygın desen, paylaşılan volume’u tohumlamak için ayrı bir init konteyneri kullanmaktır:

services:
  init:
    image: ubuntu:latest
    command: sh -c "mkdir -p /source && echo 'initial data' > /source/seed.txt && cp /source/* /dest/"
    volumes:
      - shared:/dest

  service-1:
    image: ubuntu:latest
    command: sleep infinity
    depends_on:
      - init
    volumes:
      - shared:/data

  service-2:
    image: ubuntu:latest
    command: sleep infinity
    depends_on:
      - init
    volumes:
      - shared:/data

volumes:
  shared:

init konteyneri tohum verileri oluşturur ve shared volume’una kopyalar, sonra çıkar. service-1 ve service-2 bundan sonra başlar ve kullanıma hazır tohum verileri bulur.

Compose, birden çok konteyner ve paylaşılan depolamalarının koordinasyonuna ilişkin karmaşıklığı tek bir, sürüm kontrollü dosyada yönetir.

Docker Mount Performansı ve Güvenliği

Yanlış mount türünü seçmek konteynerlerinizi yavaşlatabilir veya farkında olmadığınız güvenlik açıkları yaratabilir. Bunun olmasını istemiyorsanız bu bölümü okuyun.

Mount türleri arasındaki performans ödünleşimleri

Volumes, Linux’ta en iyi performansı sunar; çünkü doğrudan ana makine dosya sisteminde, çeviri katmanı olmadan saklanırlar.

Mac ve Windows’ta Docker, bir Linux VM’i içinde çalışır. Volume’lar yine iyi performans gösterir; çünkü o VM içinde kalırlar. Öte yandan bind mount’lar, dosyaları ana işletim sistemi ile Linux VM arasında eşitlemek zorundadır; bu da ek yük getirir. Bind mount’larda dosya işlemleri, yerel Linux’a kıyasla Mac ve Windows’ta önemli ölçüde daha yavaş olabilir.

tmpfs okuma-yazma işlemleri için en hızlı seçenektir; çünkü her şey RAM’de gerçekleşir. Disk G/Ç yok, dosya sistemi ek yükü yok. Ancak mevcut bellekle sınırlısınız ve konteyner durduğunda veriler kaybolur.

Linux’taysanız ve maksimum performansa ihtiyacınız varsa volumes kullanın. Mac veya Windows’taysanız ve geliştirme sırasında yavaş dosya işlemleri fark ediyorsanız, muhtemelen bind mount ek yüküne takılıyorsunuz. Üretim iş yükleri için volumes’a geçin.

Mount’ların güvenlik etkileri

Her mount, konteynerlere izole dosya sistemlerinin dışında bir şeye erişim verir ve bu risk yaratır.

Bind mount’lar en büyük endişedir. /home/user yolunu bir konteynere bağlarsanız, ele geçirilmiş bir konteyner SSH anahtarlarınızı okuyabilir, kabuk yapılandırmanızı değiştirebilir veya tüm ana dizininiz boyunca dosyaları silebilir. O konteyneri root olarak çalıştırın – varsayılan budur – ve bu dosyalara root düzeyinde erişimi olur.

Volumes bu riski azaltır; çünkü Docker’ın depolama dizininde izole edilirler. Bir konteyner, volume’lar aracılığıyla rastgele ana makine yollarını bağlayamaz. Ancak volume’ları dikkatsizce paylaşırsanız, konteynerler arasında yine veri sızıntısı olabilir.

tmpfs mount’lar kalıcılık riskini en aza indirir – bellekte saklanan sırlar konteyner durduğunda kaybolur. Ancak çalışma zamanı saldırılarına karşı koruma sağlamazlar; ele geçirilmiş bir konteyner sırları bellekten okuyabilir.

Genel kural, mount’ların konteyner izolasyonunu bozduğudur, bu yüzden dikkatli kullanın.

Güvenli mount’lar için en iyi uygulamalar

Konteynerlerin yalnızca ihtiyaç duyduğu şeyleri ve daha fazlasını değil, sadece onları bağlayın.

Tüm proje dizininizi bağlamak yerine, konteynerin kullandığı alt dizini bağlayın. Yalnızca log okumak gerekiyorsa, /var/log’u yazma erişimiyle bağlamak yerine salt-okunur bağlayın.

Mümkün olan her yerde readonly seçeneğini kullanın:

docker run -d \
  --mount type=bind,source=/app/config,target=/config,readonly \
  ubuntu:latest

Bu, konteynerlerin bağlanan veriyi değiştirmesini engeller ve ele geçirilmeleri durumunda hasarı sınırlar.

Bind mount açıklarını azaltmak için konteynerleri root olmayan kullanıcılarla çalıştırın. Dockerfile’ınızda bir kullanıcı oluşturun ve konteyner başlamadan önce o kullanıcıya geçin:

RUN useradd -m appuser
USER appuser

docker volume prune ile kullanılmayan volume’ları düzenli olarak temizleyin. Eski volume’lar zamanla birikir; disk alanını tüketir ve silinen konteynerlerden hassas veriler tutabilir.

Belirli bir nedeniniz ve riskleri anladığınız durumlar dışında asla /, /etc veya /var gibi hassas ana makine dizinlerini bağlamayın. Her mount’un net bir amacı ve asgari kapsamı olmalıdır.

Docker Mount Sorunlarını Giderme

Mount sorunları genellikle izin hataları, kayıp dosyalar veya başlamayan konteynerler olarak kendini gösterir – ve neredeyse her zaman aynı sorunlar kümesinden kaynaklanır.

Karşılaşacağınız en yaygın sorunları nasıl teşhis edip düzelteceğiniz aşağıda.

İzin ve sahiplik hataları

İzin hataları, konteyner içindeki kullanıcının bağlanan dosyalara erişimi olmadığında oluşur.

Docker konteynerleri varsayılan olarak root olarak çalışır. Root, bir bind mount içinde bir dosya oluşturduğunda, o dosya ana makinenizde root’a ait olur. Bunu normal kullanıcı hesabınızla düzenlemeye çalışırsanız, izin reddedildi hatası alırsınız.

Tersi de olur. Size ait bir dizini root olmayan bir kullanıcıyla çalışan bir konteynere bağlarsanız, konteyner oraya yazamayabilir.

Bağlanan dizinde ls -la komutuyla dosya sahipliğini kontrol edebilirsiniz:

ls -la /path/to/mounted/directory

Dosyalar root’a aitse ancak konteyner farklı bir kullanıcı olarak çalışıyorsa bir uyumsuzluk var demektir. Konteyneri, dosyaların sahibiyle aynı kullanıcı olarak çalıştırarak düzeltin:

docker run -d \
  --user $(id -u):$(id -g) \
  -v ./data:/app/data \
  ubuntu:latest

Bu, konteyneri root yerine geçerli kullanıcınızla çalıştırır ve bind mount içindeki dosyaların sahipliğiyle eşleşir.

Volume’lar için, konteynerler dosya oluşturduğunda Docker izinleri otomatik olarak ele alır. Ancak hatalar görüyorsanız, konteyner içindeki uygulamanın hangi kullanıcıyla çalıştığını ve mount noktasına yazma izni olup olmadığını kontrol edin.

Yol ve yapılandırma hataları

En yaygın hata, ana makinede var olmayan bir yolu bağlamaktır.

/home/user/project yolunu bağlamaya çalışın ama bu dizin yoksa, Docker root’a ait boş bir dizin oluşturur. Konteyneriniz başlar, ancak yanlış şeyi – gerçek projeniz yerine boş bir dizini – bağlamıştır.

Bağlamadan önce yolların var olduğunu her zaman doğrulayın:

ls /home/user/project

Dizin yoksa önce oluşturun veya mount komutunuzdaki yolu düzeltin.

Docker Compose’ta, göreli yollar docker-compose.yml dosyanızın bulunduğu dizinden çözülür. Dosyanız /home/user/app/ içinde ve siz ./data kullanıyorsanız, Docker /home/user/app/data yolunu arar.

Compose dosyasını taşırsanız, mount bozulur.

Bir diğer yaygın hata, konteyner içinde yanlış hedef yoluna mount etmektir. Uygulamanızın /data beklediği yerde siz /app/data yoluna mount ederseniz, uygulama dosyalarını bulamaz. Verilerin nerede beklenmesi gerektiğini doğrulamak için uygulamanızın dokümantasyonunu veya Dockerfile’ını kontrol edin.

Platforma özgü tuhaflıklar

Linux’ta bind mount’lar doğrudan ana makine dosya sistemiyle çalışır.

Mac ve Windows’ta Docker, bir Linux VM’i içinde çalışır. Bind mount’lar, dosyaları ana işletim sistemi ile bu VM arasında eşitler; bu da zamanlama sorunları yaratır. Dosyalar değiştiğinde uygulamanızı yeniden yükleyen araçlar – dosya izleyiciler – bazen eşitleme gecikmeleri nedeniyle güncellemeleri kaçırır.

Mac ve Windows ayrıca dosya izinlerini farklı şekilde ele alır. VM, izinleri ana işletim sistemi ile Linux arasında çevirir; bu da konteyner içinde dosyaların hatalı sahiplikle görünmesine neden olabilir.

Mac ve Windows’ta bind mount’larda sembolik bağlantılar güvenilir şekilde çalışmaz. VM, bağlanan dizin dışını gösteren sembolik bağlantıları her zaman çözemediği için, dosyalar konteyner içinde eksik veya bozuk görünebilir.

tmpfs mount’lar, VM’nin tmpfs’i ana makineye sunmaması nedeniyle Mac ve Windows’ta hiç çalışmaz. Bir tmpfs mount kullanmayı denerseniz, Docker sürüme bağlı olarak bunu sessizce yok sayabilir veya bir hata verebilir.

Mac veya Windows’ta geliştiriyor ve garip dosya eşitleme sorunları yaşıyorsanız, daha iyi performans ve güvenilirlik için adlı volume’lara geçin. Gerçek zamanlı eşitlemenin kusursuz tutarlılıktan daha önemli olduğu geliştirme iş akışları için bind mount’ları saklayın.

Sonuç

Özetlemek gerekirse, veritabanları, yüklenen dosyalar, uygulama durumu gibi kalıcı olması gereken üretim verileri için volumes kullanın – kaybetmeyi göze alamayacağınız her şey için. Docker tarafından yönetilirler, platformlar arası taşınabilirler ve önemli veriler için en güvenli seçenektirler.

Bind mount’lar, ana makineniz ile konteynerler arasında gerçek zamanlı dosya eşitlemesine ihtiyaç duyduğunuz geliştirme iş akışlarına aittir. Düzenleyicide kodu değiştirirken, değişiklikleri konteynerde çalışan uygulamada anında görürsünüz. Ancak üretimden uzak tutun; çünkü ana makineye özgü yollara fazla bağımlıdırlar ve ihtiyaç duymadığınız güvenlik riskleri yaratırlar.

Konteynerleştirme ve sanallaştırmaya daha derinlemesine dalmaya hazırsanız, kursumuza göz atın: Docker ve Kubernetes ile Containerization and Virtualization.