در این پرونده انتظار حجم دارم./USR/SRC/APP دستورالعمل برای نصب محتویات فهرست کار فعلی در میزبان برای نصب در پوشه کانتینر/USR/SRC/APP.

لطفاً به من اطلاع دهید که آیا این روش صحیح است؟

7 پاسخ 7

به طور خلاصه: نه ، دستورالعمل حجم شما صحیح نیست.

حجم Dockerfile یک یا چند جلد با داده های سمت کانتینر را مشخص می کند. اما به نویسنده تصویر اجازه نمی دهد مسیر میزبان را مشخص کند. از طرف میزبان ، حجم ها با نام بسیار طولانی شناختی در داخل ریشه Docker ایجاد می شوند. در دستگاه من این/var/lib/docker/volumes است.

توجه: از آنجا که نام اتوژنه شده بسیار طولانی است و از دیدگاه انسان معنی ندارد ، این حجم ها اغلب به عنوان "نامشخص" یا "ناشناس" گفته می شوند.

مثال شما که از "." استفاده می کند. شخصیت حتی روی دستگاه من اجرا نمی شود ، مهم نیست که من نقطه اول یا دوم را ایجاد کنم. من این پیام خطا را دریافت می کنم:

Docker: پاسخ خطا از Daemon: OCI Runtime Error: Container_Linux. Go: 265: فرآیند شروع کانتینر باعث "Process_Linux. go: 368: Container Init ایجاد شده است" باز /dev /ptmx: چنین پرونده یا دایرکتوری "".

من می دانم که آنچه به این نکته گفته شده است احتمالاً برای کسی که سعی در درک حجم و-V دارد ، بسیار ارزشمند نیست و مطمئناً راه حلی برای آنچه شما سعی می کنید انجام دهید ارائه نمی دهد. بنابراین ، امیدوارم که مثالهای زیر نور بیشتری را در مورد این موضوعات ایجاد کند.

minitutorial: مشخص کردن حجم

با توجه به این dockerfile:

(برای نتیجه این minitutorial ، هیچ فرقی نمی کند اگر Vol1 Vol2 یا /Vol1 /Vol2 را مشخص کنیم - این به این دلیل است که فهرست کار پیش فرض در یک dockerfile است /)

در داخل کانتینر ، LS را در خط فرمان اجرا کنید و متوجه خواهید شد که دو دایرکتوری وجود دارد./Vol1 و /Vol2.

اجرای کانتینر همچنین دو دایرکتوری یا "جلد" را در سمت میزبان ایجاد می کند.

در حین اجرای کانتینر ، Docker Volume LS را در دستگاه میزبان اجرا کنید و چیزی شبیه به این را مشاهده خواهید کرد (من قسمت میانی نام را با سه نقطه برای کوتاه بودن جایگزین کرده ام):

در داخل کانتینر ، Touch /Vol1 /Weird-Ass-File را اجرا کنید (یک پرونده خالی را در مکان مذکور ایجاد می کند).

این پرونده اکنون در یکی از جلد های بی نام LOL در دستگاه میزبان موجود است. این دو تلاش برای من طول کشید زیرا من برای اولین بار اولین جلد ذکر شده را امتحان کردم ، اما در نهایت پرونده خود را در جلد دوم ذکر شده ، با استفاده از این دستور در دستگاه میزبان پیدا کردم:

به همین ترتیب ، می توانید این پرونده را در میزبان حذف کنید و در ظرف نیز حذف می شود.

توجه: پوشه _data نیز به عنوان "نقطه کوه" گفته می شود.

از کانتینر خارج شوید و جلدهای میزبان را لیست کنید. آنها از بین رفته اند. ما هنگام اجرای کانتینر از پرچ م-RM استفاده کردیم و این گزینه به طور مؤثر نه تنها ظرف در خروجی ، بلکه حجم را نیز از بین می برد.

یک ظرف جدید را اجرا کنید ، اما یک حجم را با استفاده ا ز-V مشخص کنید:

این یک جلد سوم را اضافه می کند و کل سیستم با سه جلد بی نام به پایان می رسد. اگر ما فق ط-V Vol3 را مشخص کنیم ، این فرمان خراب می شد. استدلال باید یک مسیر مطلق در داخل ظرف باشد. از طرف میزبان ، جلد سوم جدید ناشناس است و همراه با دو جلد دیگر در/var/lib/docker/volumes/.

پیش از این بیان شده بود که Dockerfile نمی تواند در یک مسیر میزبان نقشه بکشد که در هنگام تلاش برای ورود پرونده ها از میزبان به ظرف در زمان اجرا ، مشکلی را برای ما ایجاد کند. یک نحو متفاو ت-V این مشکل را حل می کند.

تصور کنید که من یک زیر پوشه در فهرست پروژه خود دارم ./src که می خواهم با /SRC داخل ظرف همگام سازی کنم. این دستور ترفند را انجام می دهد:

هر دو طرف: شخصیت انتظار یک مسیر مطلق را دارد. سمت چپ یک مسیر مطلق در دستگاه میزبان است ، سمت راست یک مسیر مطلق در داخل ظرف است. PWD یک دستور است که "چاپ فهرست فعلی/کار" را چاپ می کند. قرار دادن دستور در $ () فرمان را در پرانتز می گیرد ، آن را در زیر زیر زیر آب اجرا می کند و مسیر مطلق را به فهرست پروژه ما باز می گرداند.

با هم قرار دادن همه اینها ، فرض کنید که ما در پوشه پروژه خود در دستگاه میزبان با محتویات زیر قرار داریم.

ما این dockerfile را می سازیم:

ما این دستور را اجرا می کنیم:

این چاپ "سلام ، جهان!" است.

بهترین قسمت این است که ما کاملاً آزاد هستیم که پرونده . java را با یک پیام جدید برای خروجی دیگر در یک اجرا دوم تغییر دهیم - بدون نیاز به بازسازی تصویر =)

سخنان نهایی

I am quite new to Docker, and the aforementioned "tutorial" reflects information I gathered from a 3-day command line hackathon. I am almost ashamed I haven't been able to provide links to clear English-like documentation backing up my statements, but I honestly think this is due to a lack of documentation and not personal effort. I do know the examples work as advertised using my current setup which is "Windows 10 > Vagrant 2.0.0 >Docker 17. 09. 0-CE ".

این آموزش مشکل را حل نمی کند "چگونه می توانیم مسیر کانتینر را در Dockerfile مشخص کنیم و اجازه دهیم دستور RUN فقط مسیر میزبان را مشخص کند". ممکن است راهی وجود داشته باشد ، من فقط آن را پیدا نکرده ام.

سرانجام ، من یک احساس روده دارم که مشخص کردن حجم در dockerfile فقط غیر معمول نیست ، اما احتمالاً بهترین روش برای استفاده هرگز از حجم است. به دو دلیلاولین دلیلی که قبلاً مشخص کرده ایم: ما نمی توانیم مسیر میزبان را مشخص کنیم - که چیز خوبی است زیرا Dockerfiles باید نسبت به مشخصات یک دستگاه میزبان بسیار آگنوستیک باشد. اما دلیل دوم این است که افراد ممکن است هنگام اجرای کانتینر از گزین ه-RM استفاده کنند. ممکن است کسی به یاد داشته باشید که ظرف را بردارید اما فراموش کردن حجم آن را فراموش کنید. بعلاوه ، حتی با بهترین حافظه انسان ، ممکن است این کار دلهره آور باشد که بفهمیم کدام یک از همه حجم ناشناس برای حذف آن بی خطر است.

martin بسیار متشکرمHackathon و آموزش حاصل از آن در اینجا بسیار مورد تأیید است.

"من نتوانسته ام پیوندهایی را برای مستندات شفاف انگلیسی ارائه دهم. صادقانه فکر می کنم این به دلیل عدم مستندات است."من می توانم تأیید کنماین کاملترین و به روزترین مستنداتی است که من پیدا کردم و ساعت ها به دنبال آن بوده ام.

می توان از هرس حجم داکر برای تمیز کردن حجم باقیمانده که به ظروف در حال اجرا وصل نشده اند ، استفاده کرد. نه اینکه بگوییم که فقط با شناسه فقط شناسه مهم است که به طور بالقوه مهم باشد.

"برای نتیجه این minitutorial ، هیچ فرقی نمی کند اگر Vol1 Vol2 یا /Vol1 /Vol2 را مشخص کنیم - از من نپرسید که چرا". Martinandersson به این دلیل است که فهرست کار فعلی / ، بنابراین VOL1 نسبت به / ، که به / Vol1 برطرف می شود. اگر از WorkDir برای مشخص کردن یک فهرست کار غیر از / ، Vol1 و / Vol1 استفاده می کنید ، دیگر به همان فهرست اشاره نمی کند.

آموزش رسمی Docker می گوید:

• حجم ها هنگام ایجاد یک ظرف اولیه می شوند. اگر تصویر پایه کانتینر حاوی داده هایی در نقطه کوه مشخص شده باشد ، داده های موجود پس از اولیه سازی حجم در حجم جدید کپی می شوند.(توجه داشته باشید که این کار هنگام نصب دایرکتوری میزبان صدق نمی کند.)

• حجم داده ها را می توان در بین ظروف به اشتراک گذاشته و استفاده مجدد کرد.

• تغییرات در حجم داده به طور مستقیم انجام می شود.

• هنگام به روزرسانی یک تصویر ، تغییر در حجم داده گنجانده نمی شود.

• حجم داده ها حتی اگر خود ظرف حذف شود ، ادامه دارد.

در Dockerfile می توانید فقط مقصد یک حجم داخل یک ظرف را مشخص کنید. به عنوان مثال،/USR/SRC/APP.

هنگامی که یک ظرف را اجرا می کنید ، به عنوان مثالdocker ru n-volume =/opt:/usr/src/app my_image ، شما ممکن است اما لازم نیست نقطه نصب آن (/opt) را در دستگاه میزبان مشخص کنید. اگر آرگوما ن-ولتاژ را مشخص نکنید ، نقطه کوه به طور خودکار انتخاب می شود ، معمولاً در زیر/var/lib/docker/volumes/.

در Dockerfile می توانید فقط مقصد یک حجم داخل یک ظرف را مشخص کنید. به عنوان مثال،/USR/SRC/APP. این خط دقیقی است که من برای خواندن آن برای متوقف کردن سرمایه گذاری بیشتر در این راه حل نیاز داشتم

با عرض پوزش برای احیای این موضوع قدیمیدر اسناد Docker در مورد حجم آمده است: "-v یا-Volume: [.] قسمت دوم مسیری است که پرونده یا دایرکتوری در ظرف نصب شده است."بشرطبق توضیحات شما ، آیا نباید این خوانده شده "نصب شده در میزبان" باشد؟

این به Dockerfile اشاره دارد ، شما ب ه-v در Docker CLI مراجعه می کنید. SYNTAX CL I-v Source_Path_on_localohst است: Destination_Path_in_Container ، حجم دستورالعمل Dockerfile در عوض Volume Destination_Path_in_Container است (و سپس شما را با Docker Run مشخص می کنید) source_path_on_localohst را مشخص کنید)

مشخص کردن یک خط حجم در یک Dockerfile کمی ابرداده را روی تصویر شما پیکربندی می کند ، اما نحوه استفاده از ابرداده از اهمیت برخوردار است.

اول ، این دو خط چه کاری انجام دادند:

خط WorkDir در آنجا دایرکتوری را ایجاد می کند در صورت وجود ، و برخی از ابرداده های تصویر را به روز می کند تا تمام مسیرهای نسبی را مشخص کند ، به همراه دایرکتوری فعلی برای دستوراتی مانند Run در آن مکان خواهد بود. خط حجم در آنجا دو جلد را مشخص می کند ، یکی مسیر نسبی.، و دیگری/usr/src/app ، هر دو فقط یک دایرکتوری هستند. بیشتر اوقات خط حجم فقط شامل یک دایرکتوری واحد است ، اما می تواند مانند شما انجام شود ، یا می تواند یک آرایه با فرمت JSON باشد.

شما نمی توانید یک منبع حجم را در Dockerfile مشخص کنید: یک منبع مشترک سردرگمی هنگام مشخص کردن حجم در یک dockerfile در تلاش است تا با نحو زمان اجرا یک منبع و مقصد در زمان ساخت تصویر مطابقت داشته باشد ، این کار نخواهد کرد. Dockerfile فقط می تواند مقصد حجم را مشخص کند. اگر کسی بتواند منبع یک حجم را تعریف کند ، این یک سوء استفاده از امنیت بی اهمیت خواهد بود زیرا می تواند یک تصویر مشترک را در توپی Docker به روز کند تا دایرکتوری ریشه را در ظرف سوار کند و سپس یک فرآیند پس زمینه را در داخل ظرف به عنوان بخشی از یک ورودی راه اندازی کند کهورود به سیستم به /etc /passwd ، SystemD را برای راه اندازی یک ماینر بیت کوین در راه اندازی مجدد بعدی تنظیم می کند ، یا سیستم فایل را برای کارت های اعتباری ، SSN ها و کلیدهای خصوصی جستجو می کند تا به یک سایت از راه دور ارسال شود.

خط حجم چه کاری انجام می دهد؟همانطور که گفته شد ، برخی از ابرداده های تصویر را برای گفتن دایرکتوری در داخل تصویر تنظیم می کند. این ابرداده چگونه استفاده می شود؟هر بار که یک ظرف از این تصویر ایجاد می کنید ، Docker آن دایرکتوری را مجبور می کند که یک حجم باشد. اگر در دستور RUN یا فایل آهنگسازی یک حجم ارائه نمی دهید ، تنها گزینه Docker ایجاد یک حجم ناشناس است. این یک حجم محلی به نام با یک شناسه منحصر به فرد برای نام است و هیچ نشانه دیگری برای ایجاد آن یا چه داده هایی در آن وجود ندارد (حجم ناشناس این است که داده ها از بین می روند). اگر حجم را نادیده بگیرید و به حجم نامگذاری شده یا میزبان اشاره کنید ، به جای آن داده های شما به آنجا می روند.

Volume Breaks Things: شما نمی توانید یک حجم را که یک بار در یک dockerfile تعریف شده است غیرفعال کنید. و مهمتر از همه ، فرمان اجرا در Docker با ظروف موقت با سازنده کلاسیک اجرا می شود. آن ظروف موقت حجم ناشناس موقت را دریافت می کنند. این حجم ناشناس با محتوای تصویر شما آغاز می شود. هرگونه نوشتن در داخل ظرف از دستور اجرای شما به آن جلد ساخته می شود. هنگامی که فرمان اجرا به پایان رسید ، تغییرات در تصویر ذخیره می شود و تغییر در حجم ناشناس دور می شود. به همین دلیل ، من به شدت توصیه می کنم که یک حجم را در داخل Dockerfile تعریف کنید. این منجر به رفتار غیر منتظره برای کاربران پایین دست تصویر شما می شود که مایل به گسترش تصویر با داده های اولیه در مکان حجم هستند.

چگونه باید یک جلد را مشخص کنید؟برای مشخص کردن جایی که می خواهید حجم را با تصویر خود درج کنید ، یک docker-compose. yml را تهیه کنید. کاربران می توانند این مسئله را برای تنظیم مکان حجم در محیط محلی خود تغییر دهند و سایر تنظیمات زمان اجرا مانند انتشار پورت ها و شبکه را ضبط می کند.

کسی باید این را مستند کند! آنها دارند. Docker شامل هشدارهایی در مورد استفاده از حجم در مستندات خود در Dockerfile به همراه مشاوره برای مشخص کردن منبع در زمان اجرا است:

• تغییر حجم از درون dockerfile: در صورت انجام هر مرحله ساخت ، داده های موجود در حجم را پس از اعلام آن تغییر دهید ، این تغییرات دور ریخته می شوند.

• دایرکتوری میزبان در زمان اجرای کانتینر اعلام می شود: فهرست میزبان (MountPoint) به دلیل ماهیت آن ، وابسته به میزبان است. این برای حفظ قابلیت حمل تصویر است ، زیرا یک فهرست میزبان داده شده نمی تواند تضمین شود که در همه میزبان ها در دسترس باشد. به همین دلیل ، شما نمی توانید یک فهرست میزبان را از درون Dockerfile سوار کنید. دستورالعمل حجم از مشخص کردن یک پارامتر میزبان DIR پشتیبانی نمی کند. هنگام ایجاد یا اجرای کانتینر ، باید MountPoint را مشخص کنید.

رفتار تعریف یک جلد و به دنبال آن مراحل اجرا در یک Dockerfile با معرفی BuildKit تغییر کرده است. در اینجا دو مثال آورده شده است. ابتدا Dockerfile:

بعد ، ساختمان بدون ساخت و ساز. توجه داشته باشید که چگونه تغییرات از مرحله اجرا از بین می رود:

و سپس ساخت با BuildKit. توجه داشته باشید که چگونه تغییرات از مرحله اجرا حفظ می شود: