یکی از موضوعاتی که کاربران Docker Desktop اغلب در مورد آن از ما می پرسند اشتراک گذاری فایل است. چگونه می توانم کد منبع خود را در داخل ظرف خود ببینم؟ تفاوت بین پایه ولوم و باند چیست؟ چرا به اشتراک گذاری فایل کندتر از لینوکس است و چگونه می توانم سرعت آن را افزایش دهم؟ در این پست وبلاگ، گزینه‌های شما، چند نکته و ترفند را پوشش می‌دهم و با یک پیش‌نمایش پنهانی از آنچه در حال حاضر روی آن کار می‌کنیم، پایان می‌دهم. با docker run -it ubuntu bash. شما به سرعت متوجه خواهید شد که (1) کانتینر بر اساس سیستم فایل موجود در تصویر اوبونتو، سیستم فایل خود را دارد. (2) می‌توانید فایل‌ها را ایجاد، حذف و اصلاح کنید، اما تغییرات شما در کانتینر محلی است و با حذف ظرف از بین می‌رود. (3) کانتینر به هیچ فایل دیگری در رایانه میزبان شما دسترسی ندارد.
بنابراین سؤالات طبیعی بعدی این است که چگونه می توانم فایل های دیگرم را ببینم؟ و چگونه ظرف من می تواند داده هایی را بنویسد که بعداً بخوانم و شاید در کانتینرهای دیگر استفاده کنم؟ این جایی است که پایه‌ها و ولوم‌های bind وارد می‌شوند. هر دوی اینها از پرچم -v تا docker run برای تعیین برخی فایل‌ها برای اشتراک‌گذاری با کانتینر استفاده می‌کنند.
اولین گزینه بیشتر است. افراد با آن مواجه می شوند، اتصال mount است، جایی که بخشی از سیستم فایل محلی شما با کانتینر به اشتراک گذاشته می شود. برای مثال، اگر
docker run -it -v /users/stephen:/my_files ubuntu bash
را اجرا کنید، فایل‌های /users/stephen[0][1945دردسترسخواهندبوددر/my_files در ظرف، و می‌توانید در آنجا برای آنها بخوانید و بنویسید. این بسیار ساده و راحت است، اما اگر از Docker Desktop استفاده می کنید، یک حجم نامگذاری شده ممکن است عملکرد بهتری داشته باشد، به دلایلی که در بخش بعدی توضیح خواهم داد. داکر. می توانید با دستوری مانند docker volume create new_vol یک حجم نامگذاری شده ایجاد کنید، و سپس با استفاده از پرچم -v دوباره آن را در ظرف به اشتراک بگذارید:
docker run - it -v new_vol:/my_files ubuntu bash
این حجم‌ها حتی پس از حذف ظرف باقی می‌مانند و می‌توان آنها را با کانتینرهای دیگر به اشتراک گذاشت. همچنین می‌توانید با استفاده از برگه Volumes که اخیراً اضافه کرده‌ایم، محتویات آنها را از رابط کاربری Docker Desktop مرور کنید (و اکنون برای همه کاربران از جمله Docker Personal رایگان است).
ملاحظات عملکرد
برای درک تفاوت‌های عملکرد بین گزینه‌ها ، ابتدا باید به طور خلاصه در مورد نحوه عملکرد Docker Desktop صحبت کنیم. بسیاری از مردم تصور می کنند که Docker Desktop فقط یک رابط کاربری در بالای برخی از ابزارهای منبع باز است، اما این تنها بخش کوچکی از آن چیزی است که هست. Docker Desktop اساساً محیطی برای توسعه و اجرای کانتینرهای لینوکس بر روی دستگاه مک یا ویندوز شما است، با ادغام یکپارچه در هاست به طوری که به نظر می رسد که آنها به صورت بومی در حال اجرا هستند. این کار را با راه‌اندازی یک VM لینوکس (یا به صورت اختیاری یک محیط WSL 2 در ویندوز) انجام می‌دهد که در آن موتور Docker و کانتینرهای شما را اجرا می‌کند و سپس دستورات CLI، شبکه و فایل‌ها را بین میزبان و VM ارسال می‌کند.
متاسفانه. در ماهیت مجازی سازی است که همیشه یک سربار کوچک اجتناب ناپذیر در عبور از مرز میزبان-VM وجود دارد. این فقط کوچک است، اما در یک محیط توسعه با درخت منبع عظیم و خواندن و نوشتن زیاد، اضافه می‌شود و می‌تواند به‌طور مشهودی بر عملکرد تأثیر بگذارد. و از آنجایی که Docker Desktop در مخفی کردن VM زیربنایی کار بسیار خوبی انجام می دهد، مشخص نیست که چرا این اتفاق می افتد. در لینوکس، کانتینر به سیستم فایل متصل شده دسترسی مستقیم دارد، و از آنجا که پیاده‌سازی در مک و ویندوز «احساس بومی» می‌کند، مردم به طور شهودی انتظار عملکرد یکسانی را در آنجا دارند. در داخل سیستم فایل خود ماشین مجازی ایجاد می شوند، بنابراین به سرعت یک ماشین لینوکس هستند. در WSL 2، ویندوز به‌جای مدیریت Docker، اشتراک‌گذاری فایل را مدیریت می‌کند، اما ملاحظات عملکردی مشابهی اعمال می‌شود: فایل‌های نصب‌شده از سیستم فایل ویندوز می‌توانند کند باشند، حجم‌های نامگذاری شده سریع هستند، اما در این مورد گزینه دیگری وجود دارد: فایل‌های ذخیره شده در سیستم فایل لینوکس نیز در داخل WSL VM قرار دارد، بنابراین سریع نیز هستند. در ابتدا استفاده از پایه‌های اتصال راحت است و ممکن است متوجه شوید که برای مورد استفاده شما مناسب هستند. اما اگر عملکرد مشکل ساز شد، (1) مطمئن شوید که فقط چیزهایی را که باید به اشتراک بگذارید را به اشتراک می گذارید، و (2) مواردی را که می تواند به روش دیگری به غیر از یک پایه اتصال به اشتراک گذاشته شود، در نظر بگیرید. شما چندین گزینه برای نگهداری فایل‌ها در داخل ماشین مجازی دارید، از جمله حجم نامگذاری شده، فایل‌های لینوکس در WSL و سیستم فایل خود کانتینر: استفاده از آنها به مورد استفاده بستگی دارد. به عنوان مثال:
- کد منبعی که فعالانه در حال ویرایش آن هستید، استفاده مناسبی از یک اتصال اتصال است
- درختان یا کتابخانه‌های وابستگی بزرگ و ایستا می‌توانند به یک جلد نامگذاری شده یا WSL منتقل شوند، یا حتی در تصویر ظرف پخت شوند. 19659018] پایگاه‌های داده در یک حجم نامگذاری شده یا WSL مناسب‌تر هستند
- فهرست‌های حافظه پنهان و فایل‌های گزارش باید در یک حجم نامگذاری شده یا WSL (در صورت نیاز به نگه‌داشتن آنها پس از توقف کانتینر) یا در سیستم فایل خود کانتینر (اگر آنها هستند) قرار داده شوند. زمانی که کانتینر ناپدید می‌شود.
- فایل‌هایی که کانتینر به آنها نیاز ندارد اصلاً نباید به اشتراک گذاشته شوند. به ویژه، کل فهرست اصلی خود را به اشتراک نگذارید. ما دیده‌ایم که برخی از افراد معمولاً این کار را انجام می‌دهند تا همیشه به هر فایلی که نیاز دارند دسترسی داشته باشند، اما برخلاف لینوکس، این «رایگان» نیست.
اگر واقعاً به یک پایه اتصال برای برخی بزرگ یا بالا نیاز دارید، یک گزینه باقی مانده است. -traffic directory یک راه حل کش/همگام سازی شخص ثالث است، به عنوان مثال Mutagen یا docker-sync. اینها اساساً فایل‌های شما را در داخل ماشین مجازی برای دسترسی سریع‌تر خواندن/نوشتن کپی می‌کنند و همگام‌سازی (در یک یا هر دو جهت) بین کپی و میزبان را انجام می‌دهند. اما شامل یک مؤلفه اضافی برای مدیریت است، بنابراین حجم های نامگذاری شده همچنان در صورت امکان ترجیح داده می شوند. و gRPC FUSE در مک؛ و ویندوز از 9P در WSL 2 استفاده می کند. ما در طول زمان بهبودهایی در عملکرد داشته ایم، اما هیچ یک از آنها نتوانسته اند عملکرد بومی را مطابقت دهند. اما ما در حال حاضر در حال آزمایش یک اجرای اشتراک گذاری فایل جدید بسیار امیدوارکننده بر اساس virtiofs هستیم. Virtiofs فناوری جدیدی است که به طور خاص برای به اشتراک گذاری فایل ها بین هاست و VM طراحی شده است. با استفاده از این واقعیت که VM و میزبان بر روی یک ماشین کار می کنند، نه در یک شبکه، می تواند عملکرد قابل توجهی را به دست آورد. در آزمایش‌های خود ما نتایج بسیار امیدوارکننده‌ای را دیده‌ایم.
ما قبلاً پیش‌نمایش این فناوری را برای Docker Desktop برای Mac منتشر کرده‌ایم که می‌توانید از نقشه راه عمومی ما دریافت کنید (این به macOS 12.2 نیاز دارد)، و همچنین در حال برنامه‌ریزی هستیم که از آن برای Docker Desktop برای لینوکس استفاده کنید. ما فکر می‌کنیم که می‌تواند اتصالات را بسیار سریع‌تر انجام دهد (اگرچه هنوز حجم‌های نامگذاری شده یا سیستم فایل خود کانتینر را برای موارد استفاده مناسب توصیه می‌کنیم). ما دوست داریم تجربیات شما را در مورد آن بشنویم.
مراحل بعدی
اگر می خواهید به عمق بیشتری در مورد این موضوعات بپردازید، توصیه می کنم یک سخنرانی که یکی از کاپیتان های Docker ما، Jacob Howard، در DockerCon 2021 ارائه کرد، با عنوان توری عملی از سیستم های فایل داکر. تعداد زیادی اطلاعات عالی و توصیه‌های کاربردی دارد که فقط در ۲۶ دقیقه جمع‌آوری شده‌اند!
برای دنبال کردن پیشرفت کار فعلی ما در مورد ویژگی‌ها، در نقشه راه عمومی ما مشترک شوید. اینجاست که ما ساخت‌های پیش‌نمایش را پست می‌کنیم، و خوشحال می‌شویم که آنها را امتحان کنید و نظرات خود را درباره آنها به ما ارائه دهید. رویداد مجازی روز که یک تجربه منحصر به فرد برای توسعه دهندگان و تیم های توسعه است که در حال ساختن نسل بعدی برنامه های مدرن هستند. اگر می خواهید در مورد چگونگی رفتن سریع از کد به ابر و نحوه حل چالش های توسعه خود بیاموزید، DockerCon 2022 محتوای زنده جذابی را ارائه می دهد تا به شما در ساخت، اشتراک گذاری و اجرای برنامه های کاربردی خود کمک کند. امروز در https://www.docker.com/dockercon/
ثبت نام کنید
