Docker tmpfs Mount ve Image Mount: Geçici ve Salt Okunur Bağlamalar

tmpfs mount nedir?

Docker'ı Linux üzerinde çalıştırıyorsanız volume ve bind mount'a ek olarak tmpfs mount kullanabilirsiniz. tmpfs mount ile container, yazılabilir katmanının dışında dosya oluşturabilir, ama bu dosyalar yalnızca host belleğinde tutulur. Container durduğunda tmpfs mount kaldırılır ve oraya yazılan dosyalar korunmaz. Belgelere göre veri container durduğunda ya da yeniden başlatıldığında ve host yeniden başladığında kaybolur.

Belgeler tmpfs'in iki temel kullanım sebebini sayıyor: verinin ne host'ta ne de container içinde kalıcı olmasını istemediğiniz güvenlik gerekçeleri ve uygulamanızın büyük miktarda kalıcı olmayan durum verisi yazdığı durumlarda container performansını korumak. Örnekler arasında ara verileri önbelleğe almak, kimlik bilgileri gibi hassas verileri işlemek ve disk G/Ç'sini azaltmak var. Yazılabilir katmana yazmanın storage driver üzerinden geçtiğini ve bunun ek maliyet getirdiğini düşünürseniz, sık değişen geçici dosyaları tmpfs'e yönlendirmek o katmanı da küçük tutar.

tmpfs ve container bellek limiti

tmpfs veriyi bellekte tuttuğu için bu kullanım container'ın bellek cgroup limitine sayılır; bu limit docker run tarafında --memory, Compose tarafında mem_limit ile verilir. Belgeler burada önemli bir yanılgıya dikkat çekiyor: büyük bir tmpfs-size değeri vermek container'a bu limitin dışında ek bellek kazandırmaz. tmpfs'i doldurmak container'ın bellek yetersizliği (OOM) nedeniyle sonlandırılmasına yol açabilir. Container'ın bellek metrikleri de tmpfs kullanımını içerir.

Pratik sonuç şudur: 512 MB bellek limiti olan bir container'a 1 GB'lık tmpfs tanımlarsanız uygulamanız tmpfs'e 512 MB'a yaklaşan veri yazdığında, uygulamanın kendi belleğiyle birlikte limit aşılır. tmpfs boyutunu, uygulamanın normal bellek kullanımını da hesaba katarak limitin altında tutun. Bellek limitlerinin ve OOM davranışının ayrıntısı Docker CPU ve bellek limiti, metriklerin nasıl okunacağı ise docker stats ve container metrikleri yazısında.

tmpfs kısıtları

• Volume ve bind mount'tan farklı olarak tmpfs mount container'lar arasında paylaşılamaz.
• Yalnızca Docker Linux üzerinde çalışırken kullanılabilir.
• tmpfs üzerindeki veri container bellek limitine sayılır; büyük bir size değeri limiti yükseltmez.
• tmpfs üzerinde ayarlanan izinler container yeniden başladığında sıfırlanabilir; bazı durumlarda uid ve gid ayarlamak geçici bir çözüm olabilir.

Var olan dosyaların üstüne bağlama kuralı burada da geçerlidir: container içinde dosya bulunan bir dizine tmpfs bağlarsanız o dosyalar örtülür. Bağlamayı kaldırıp onları yeniden göstermenin kolay bir yolu yoktur; container'ı bağlama olmadan yeniden oluşturmanız gerekir. Bu yüzden imajın içinde gerçekten bulunması gereken dosyaların olduğu bir dizine değil, uygulamanın çalışma sırasında yazdığı boş ya da önemsiz bir dizine tmpfs bağlayın.

--tmpfs ile --mount arasındaki fark

docker run ile tmpfs bağlamak için --mount ya da --tmpfs kullanılır. Belgeler genel olarak --mount öneriyor, çünkü daha açık. Öte yandan --tmpfs daha kısadır ve daha fazla bağlama seçeneği ayarlamanıza izin verdiği için daha esnektir. --tmpfs Swarm servislerinde kullanılamaz; orada --mount zorunludur. tmpfs'in bir kaynağı (source) yoktur, yalnızca hedef yol verilir.

docker run --mount type=tmpfs,dst=<mount-path>
docker run --tmpfs <mount-path>

--tmpfs iki nokta üst üste ile ayrılmış iki alandan oluşur: container içindeki yol ve isteğe bağlı bağlama seçenekleri. Sunucuda en çok işinize yarayacak seçenekler şunlardır:

Tabloda olmayanlar arasında sync, async, dirsync, atime, noatime, diratime ve nodiratime de var. Güvenlik açısından noexec ve nosuid özellikle değerlidir: geçici dosya dizinine yazılan bir dosyanın çalıştırılmasını ya da yetki yükseltmede kullanılmasını zorlaştırır. Belgelerdeki örnek:

docker run --tmpfs /data:noexec,size=1024,mode=1777

Linux mount komutundaki her tmpfs özelliği --tmpfs ile desteklenmez. Belgeler daha ileri seçenekler için ayrıcalıklı bir container kullanmayı ya da bağlamayı Docker dışında yapmayı öneriyor, ama --privileged ile çalışmanın container'a yükseltilmiş izinler verdiğini ve host'u güvenlik risklerine açabileceğini de ayrıca uyarıyor; bunu yalnızca kesinlikle gerekli olduğunda ve güvenilir ortamlarda yapın.

--mount type=tmpfs tarafında ise yalnızca hedef ve iki seçenek vardır: bayt cinsinden tmpfs-size ve sekizlik tabanda tmpfs-mode. tmpfs-size verilmezse bir tmpfs'in varsayılan en büyük boyutu host'un toplam RAM'inin yüzde 50'sidir. tmpfs-mode verilmezse varsayılan 1777, yani herkesin yazabildiği moddur. Bu iki varsayılan, sunucuda neden açıkça boyut ve mod vermeniz gerektiğini gösteriyor.

docker run --mount type=tmpfs,dst=/app,tmpfs-size=21474836480,tmpfs-mode=1770

tmpfs mount'u doğrulamak

Belgelerdeki örnek bir Nginx container'ında /app dizinine tmpfs bağlar ve bunu docker inspect ile doğrular. İlginç bir ayrıntı, iki bayrağın Mounts çıktısında farklı görünmesidir. --mount ile:

docker run -d \
  -it \
  --name tmptest \
  --mount type=tmpfs,destination=/app \
  nginx:latest

docker inspect tmptest --format '{{ json .Mounts }}'
[{"Type":"tmpfs","Source":"","Destination":"/app","Mode":"","RW":true,"Propagation":""}]

--tmpfs /app ile oluşturulan container için ise belgelerin gösterdiği çıktı {"/app":""} biçimindedir. Yani --tmpfs ile verilen bağlamayı Mounts listesinde tür ve hedef alanlarıyla aramayın; doğrulama betiği yazıyorsanız bu farkı hesaba katın.

Compose'da tmpfs: salt okunur container'a yazılabilir dizin

Compose'da tmpfs için iki yol vardır. Servis düzeyindeki tmpfs alanı tek bir değer ya da liste alır; her öğe bir yol ve isteğe bağlı olarak mode, uid, gid seçeneklerinden oluşur. Bu alan, container'ın kök dosya sistemini read_only: true ile salt okunur yaptığınızda uygulamanın yazması gereken birkaç dizini açmak için çok kullanışlıdır:

services:
  app:
    image: nginx:latest
    read_only: true
    mem_limit: 512m
    tmpfs:
      - /var/cache/nginx:mode=755,uid=101,gid=101
      - /run

Bu dosya doğrulamadan geçti. Burada kök dosya sistemi salt okunurdur, ama /var/cache/nginx ve /run bellekte tutulan yazılabilir dizinlerdir. uid=101,gid=101 yalnızca örnek değerlerdir; kendi imajınızda sürecin hangi kullanıcı ve grup kimliğiyle çalıştığını kontrol edip bu değerleri ona göre yazın, aksi halde süreç dizine yazamayabilir. config çıktısında mem_limit: 512m değerinin bayta çevrilerek "536870912" olarak yazıldığı da görülüyor.

İkinci yol, servisin volumes alanındaki uzun sözdiziminde type: tmpfs kullanmaktır. Bu biçimde tmpfs alt alanı size (sayı ya da bayt birimiyle) ve sekizlik mode kabul eder; belgelere göre mode Compose 2.14.0 ile eklendi. tmpfs bağlamasında source alanı kullanılmaz.

services:
  app:
    image: alpine:3.20
    command: ["sleep", "infinity"]
    mem_limit: 256m
    volumes:
      - type: tmpfs
        target: /scratch
        tmpfs:
          size: 64m
          mode: 1770

Bu dosyayı doğruladığımızda Compose boyutu bayta çevirdi:

docker compose -p uygulama -f compose.yaml config
...
    volumes:
      - type: tmpfs
        target: /scratch
        tmpfs:
          size: "67108864"
          mode: 1770

Örnekte 64 MB'lık tmpfs, 256 MB'lık bellek limitinin içinde kalıyor; tmpfs dolduğunda uygulamanın kendi belleği de bu limitten pay alacağı için oranı buna göre seçmelisiniz. Compose'daki kaynak limitlerinin deploy tarafındaki karşılığı için Compose deploy ve kaynak limitleri yazısına bakabilirsiniz.

Image mount nedir?

Volume, bind mount ve tmpfs container'a okuyup yazacağı bir alan verir. Image mount farklıdır: bir dizin ya da bellek tabanlı bir dosya sistemi yerine ikinci bir imajın dosya sistemini container içinde seçtiğiniz bir yola bağlar. Container bu imajın dosyalarını kendi dosya sisteminin yanında okuyabilir, ama bu dosyalar container'ın kendi imajının parçası olmaz. Image mount her zaman salt okunurdur; bağlanan imaj hiçbir zaman değiştirilmez ve container bağlamaya yazamaz.

Engine 29 sürüm notlarına göre image bağlama türü 29.7.0 sürümünde deneysel olmaktan çıktı. Belgelerin saydığı kullanım alanları şunlardır:

• İçinde kabuk ya da yaygın araçlar bulunmayan minimal veya sertleştirilmiş bir imajı hata ayıklamak için busybox gibi araç dolu bir imajı bağlamak ve özgün imajı değiştirmeden bu araçları çalıştırmak.
• İmaj olarak dağıtılan veri setleri, modeller ya da statik içerik gibi salt okunur varlıkları farklı imajlarla çalışan container'lara vermek.
• İsteğe bağlı araçları ayrı bir imajda paketleyip yalnızca gerektiğinde bağlayarak uygulama imajlarını küçük tutmak.

Image mount gereksinimleri ve kısıtları

• containerd image store gerekir. Klasik storage driver'larla (örneğin overlay2) image mount kullanılamaz. Hangi depolamayı kullandığınızı Docker containerd image store yazısındaki yöntemle kontrol edebilirsiniz.
• Kaynak imaj yerelde bulunmalıdır. Docker bağlamayı oluştururken imajı otomatik çekmez; imaj yoksa komut hata verir. Önce docker pull ile çekin.
• Yalnızca --mount ile oluşturulur. -v karşılığı yoktur.
• Çalıştırılabilir dosyalar uyumlu bir çalışma ortamı ister. Dinamik bağlı bir ikili dosya ancak container uygun dinamik bağlayıcıyı ve paylaşılan kütüphaneleri sağlıyorsa çalışır; örneğin glibc tabanlı bir ikili, Alpine gibi musl tabanlı bir imajda çalışmaz. Statik bağlı ikililer ya da yalnızca veri bağlamak bu kısıtı ortadan kaldırır.

Kaynak imaj yokken belgelerin gösterdiği hata şöyledir:

docker run --mount type=image,source=busybox:musl,destination=/dbg alpine
docker: Error response from daemon: No such image: busybox:musl

Image mount kullanımı

--mount type=image üç seçenek alır: imaj referansı için source (src), container içindeki mutlak yol için destination (dst, target) ve imajın kökü yerine içindeki bir yolu bağlamak için image-subpath. Belgelerdeki örnek bir Alpine container'ına musl tabanlı BusyBox imajını bağlar; musl seçilmesinin sebebi, ikililerin musl tabanlı Alpine ile uyumlu olmasıdır:

docker pull busybox:musl
docker run -d \
  -it \
  --name imgtest \
  --mount type=image,source=busybox:musl,destination=/dbg \
  alpine:latest

docker exec imgtest /dbg/bin/echo "hello from busybox"
hello from busybox

docker inspect imgtest --format '{{ json .Mounts }}' çıktısında belgelere göre "Type":"image", "Name":"busybox:musl" ve "RW":false görünür; yani bağlama bir image mount'tur ve salt okunurdur. Yalnızca imajın bin dizinini /tools altına bağlamak için image-subpath=bin eklersiniz. Engine 29.0.0 sürüm notları, aynı imajı farklı hedeflere birden çok kez bağlarken --mount type=image komutunun başarısız olduğu bir sorunun düzeltildiğini kaydediyor.

Compose'da image mount, servis volumes alanında type: image ile yazılır. İmajın bir alt yolunu bağlamak için image altında subpath kullanılır; belgelere göre bu seçenek Compose 2.35.0 ve sonrasında vardır. Aşağıdaki dosya doğrulamadan geçti:

services:
  app:
    image: alpine:latest
    command: ["sleep", "infinity"]
    volumes:
      - type: image
        source: busybox:musl
        target: /dbg
      - type: image
        source: busybox:musl
        target: /tools
        image:
          subpath: bin

Compose dosyasının geçerli olması, çalışma anında daemon'ın containerd image store kullandığı ve kaynak imajın yerelde bulunduğu anlamına gelmez; bu iki koşul docker compose up sırasında ayrıca sağlanmalıdır.

Dört bağlama türünün karşılaştırması

Sık yapılan hatalar

• tmpfs'i ek bellek sanmak: tmpfs kullanımı container bellek limitine sayılır; dolması OOM'a yol açabilir.
• tmpfs boyutunu ve modunu vermemek: --mount ile varsayılan boyut host RAM'inin yarısı, varsayılan mod 1777'dir.
• tmpfs verisinin diske hiç yazılmadığını varsaymak: Swap etkinse veri swap alanına yazılabilir.
• Swarm servisinde --tmpfs kullanmak: Servislerde --mount type=tmpfs gerekir.
• Image mount'ta imajı çekmeyi unutmak: Docker kaynak imajı otomatik çekmez.
• Uyumsuz ikili çalıştırmak: glibc tabanlı bir imajın ikililerini musl tabanlı bir container'da çalıştıramazsınız.

Sık Sorulan Sorular

tmpfs'teki veri container yeniden başlatılınca kalır mı?

Hayır. Belgelere göre tmpfs verisi container durduğunda ya da yeniden başlatıldığında ve host yeniden başladığında kaybolur. Yeniden başlatmada korunması gereken veri için volume kullanın.

İki container aynı tmpfs'i paylaşabilir mi?

Hayır, tmpfs mount container'lar arasında paylaşılamaz. Bellekte tutulan ortak bir alana ihtiyacınız varsa bunun için Docker'ın tmpfs özelliği uygun değildir.

Image mount Docker Desktop dışında da çalışır mı?

Evet, ancak daemon'ın containerd image store kullanması gerekir. Engine 29.0 ve sonrasında yeni kurulumlarda bu varsayılandır; eski bir sürümden yükselttiyseniz klasik storage driver kullanıyor olabilirsiniz.

Image mount ile bir container'ın içine nasıl araç eklerim?

Araçları içeren imajı çekip --mount type=image,source=...,destination=/dbg ile bağlarsınız; ardından docker exec ile /dbg altındaki aracı çalıştırırsınız. İkililerin container'ın C kütüphanesiyle uyumlu olması gerekir.

Marka adları sahiplerine aittir. Bu yazı bağımsız bir teknik rehberdir; adı geçen kuruluşlarla bayilik veya ortaklık ilişkisi bulunduğu anlamına gelmez.

İlgili içerikler: Docker öğrenme rehberi · Docker volume kullanımı · Bind mount · CPU ve bellek limiti · containerd image store · docker stats