بازسازی container نباید دادهٔ برنامه را تصادفی حذف کند. امشب volume نام‌دار را از bind mount و لایهٔ writable جدا و بقای داده را با یک container جدید می‌سنجیم.

این جلسه بخشی از دورهٔ لینوکس ۳۰۵ در ۶۰ شب است.

جایگاه در دوره: هدف‌های 352.3 آزمون 305-300.

محیط: docker-a، alpine:3.23؛ نام data305 آزاد. دادهٔ آموزشی فاقد secret است.

sudo docker volume create data305
sudo docker run --rm --mount type=volume,src=data305,dst=/data \
  alpine:3.23 sh -c 'printf "survives\n" > /data/probe'
sudo docker run --rm --mount type=volume,src=data305,dst=/data,readonly \
  alpine:3.23 cat /data/probe
sudo docker volume inspect data305

container نویسنده حذف شده، ولی volume باقی است. readonly روی mount خواننده فقط همان اتصال را محدود می‌کند؛ نویسندهٔ دیگری با mount writable همچنان می‌تواند داده را عوض کند.

mkdir -p "$HOME/lpic305/bind"
printf 'host file\n' > "$HOME/lpic305/bind/probe"
sudo docker run --rm \
  --mount "type=bind,src=$HOME/lpic305/bind,dst=/data,readonly" \
  alpine:3.23 cat /data/probe

bind به مسیر واقعی host وابسته است؛ volume را daemon با driver آن مدیریت می‌کند. –mount برای مسیر source ناموجود خطا می‌دهد؛ برخی شکل‌های -v ممکن است directory بسازند و اشتباه مسیر را پنهان کنند.

permission و backup#

UID عددی داخل container، مالک فایل میزبان و user namespace mapping را ثبت کن. برنامهٔ UID 10001 برای نوشتن باید permission مناسب روی همان mount داشته باشد؛ root container الزاماً مدل مجوز rootless را دور نمی‌زند.

برای backup، نویسنده را متوقف یا backup سازگار برنامه تهیه کن؛ سپس volume را read-only در container ابزار mount و archive را در مقصد خصوصی خارج آن بنویس. برای database فعال، tar خام تضمین سازگاری transaction نیست. restore را در volume نام جدید امتحان کن.

بررسی: فایل probe در container جدید خوانده شود؛ نوشتن از mount readonly شکست بخورد. حذف image هیچ تضمینی دربارهٔ حذف دادهٔ volume نمی‌دهد.

بازگشت: volume را برای تمرین backup نگه دار؛ volume rm داده را از بین می‌برد و فقط پس از تأیید بی‌نیازی انجام شود. compose down -v نیز در بخش بعد اثر مخرب دارد.

منبع: volumeها ، bind mount .