نویسنده مهمان بن هال توسعهدهنده فنی پیشرو برای C#.NET در gov.uk (یک وبسایت اطلاعات بخش عمومی بریتانیا) و یکی از اعضای بنیاد NET است. او نه سال به عنوان معلم مدرسه، برنامه نویسی و علوم کامپیوتر را پوشش داد. بن از ساختن موضوعات پیچیده برای توسعه دهندگان پرمشغله در دسترس و کاربردی لذت می برد.
تصمیم گیری بین دسکتاپ Docker و راه حل DIY
در قلب تجربه Docker، Docker Engine است. راهحل آماده استفاده Docker Desktop برای ساخت برنامههای کانتینری شامل Docker Engine و همه ابزارها و راهاندازیهای دیگری است که برای شروع توسعه سریع نیاز دارید. برخی از سازمان ها ممکن است انعطاف پذیری و کنترل انجام آن را خودشان ترجیح دهند. اما انتخاب راه حل DIY Docker Engine به مهندسی، توسعه و راه اندازی بسیار بیشتری نیاز دارد. Docker و همراه ویندوز آن، WSL، نسبتاً پیچیده هستند، بنابراین رویکرد DIY برای همه مناسب نیست.
در این مقاله، ما به شما کمک خواهیم کرد تصمیم بگیرید کدام رویکرد برای شما و سازمانتان مناسب است. برای نشان دادن، مقایسههایی را بین آنچه Docker Desktop ارائه میدهد و راهاندازی Docker DIY در ویندوز انجام خواهیم داد. شامل ایجاد یک توزیع WSL 2، راه اندازی یک مخزن Docker، و نصب موتور Docker در تنظیمات اضافی توزیع WSL 2 است. این فرآیند کمی شکننده است، بنابراین قبل از راهاندازی برای عیبیابی آماده شوید. و این تنها راهنمایی برای شروع است. بیشتر موارد استفاده نیاز به راهاندازی بیشتری دارند، از جمله:
- پیکربندی Docker برای شروع در بوت
- Logging
- پذیرش اتصالات به Daemon Docker از میزبانهای راه دور
- پیکربندی مشکلات دسترسی از راه دور IP39919[09] راه اندازی Docker Desktop تجربه بسیار متفاوتی است. شما به سادگی آخرین نصب کننده Docker Desktop را دانلود و اجرا می کنید – به طور خودکار همه کارها را کامل می کند. ما ظرف چند دقیقه آماده میشویم و آماده استقرار کانتینرها هستیم.
Cutting Edge and Stable
Docker Desktop و پیادهسازی DIY که برای اشتراک پایه مشترک در زیرسیستم ویندوز برای لینوکس (WSL) 2 مرتبط کردیم. توسعه دهندگان را قادر می سازد تا یک محیط لینوکس را مستقیماً بر روی ویندوز اجرا کنند.
WSL 2 به طور قابل توجهی استفاده از حافظه، اجرای کد و سازگاری را بهبود بخشید. این امر از طریق یک تغییر معماری به یک هسته کامل لینوکس، که از کانتینرهای لینوکس در حال اجرا به صورت بومی، بدون شبیهسازی پشتیبانی میکند، به دست آورد. . سپس Docker یک پیشنمایش فنی بسیار قبل از دسترسی عمومی WSL 2 در ویندوز منتشر کرد. همچنین تمام تلاشها برای حفظ برابری ویژگیها با نسخه قبلی که از Hyper-V استفاده میکرد، انجام شد.
ما میتوانیم Docker Desktop را به ابزار توسعهدهنده خود اضافه کنیم، با اطمینان از اینکه همچنان از آخرین فناوری پشتیبانی میکند و در عین حال از ایجاد تغییرات در تجربه جلوگیری میکند. ما به آن عادت کردهایم.
بهروزرسانیهای نرمافزار
Docker Desktop همه چیز را مدیریت میکند، از راهاندازی تا وصلههای هسته آینده. و از آنجایی که این یک بسته کامل است، بهروزرسانیهای خودکار نرمافزار همه ابزارهای نصب شده روی آن را بهروز و ایمن نگه میدارند، از جمله خود Docker Engine. این یک تصویر کمتر از ماشین برای مدیریت داخلی است!
با راهاندازی Docker DIY، این به شما بستگی دارد که از همه وصلههای امنیتی و سایر بهروزرسانیها مطلع شوید. یک راه حل DIY همچنین مشکلات مداوم زیادی را در اختیار شما قرار می دهد که نیاز به حل دارند. بنابراین، هنگام محاسبه ROI برای Docker Desktop، مطمئن شوید که این ساعتهای توسعهدهنده را در یک سازمان بزرگ ضرب میکنید.
Networking
Docker Desktop بهطور خودکار تنظیمات پروکسی HTTP/HTTPS پیکربندیشده را در Docker منتشر میکند تا از آن در هنگام کشیدن کانتینر استفاده شود.[19659004]هنگامی که به VPN متصل شود نیز به درستی کار خواهد کرد. این کار را با رهگیری ترافیک از کانتینرها و تزریق آن به ویندوز به گونه ای انجام می دهد که گویی از خود برنامه Docker سرچشمه گرفته است. این بزرگترین ویژگی تا کنون نیست، اما یادآوری عالی دیگری است که Docker Desktop در حال توسعه فعال است. این به طور مداوم در پاسخ به بازخورد کاربران بهبود مییابد و با نسخههای ماهانه اجرا میشود.
کاربران اکنون میتوانند جلسه Docker Desktop را برای کاهش مصرف CPU و حفظ عمر باتری متوقف کنند. وقتی مکث میشود، وضعیت فعلی همه کانتینرهای شما در حافظه ذخیره میشود و همه فرآیندها ثابت میشوند.
مدیریت صدا
ولومها رویکرد استانداردی برای تداوم هرگونه دادهای است که کانتینرهای Docker با آنها کار میکنند، از جمله فایلهای به اشتراک گذاشته شده بین کانتینرها. برخلاف bind mount که مستقیماً با فایلهای ماشین میزبان کار میکند، حجمها توسط Docker مدیریت میشوند که چندین مزیت را ارائه میدهد. برای تشخیص اینکه هر جلد به کدام کانتینر تعلق دارد، بنابراین پاک کردن حجمهای قدیمی میتواند فرآیندی کند باشد.
- انتقال محتوا به داخل و خارج از حجمها پیچیدهتر از آن چیزی است که واقعاً نیاز دارد. با ارائه یک نمای در داشبورد برای کاوش حجم ها. در این نما، میتوانید:
- بهآسانی حجمهایی را که در حال استفاده هستند شناسایی کنید
- ببینید کدام کانتینرها از یک حجم استفاده میکنند
- ایجاد و حذف حجمها
- فایلها و پوشهها را در یک جلد، از جمله اندازه فایلها کاوش کنید. 19659009]دانلود فایلها از حجم
- جستجو و مرتبسازی بر اساس نام، تاریخ و اندازه
یکپارچهسازی Kubernetes
اگرچه ویژگیهای زیادی برای بررسی در یک مقاله وجود دارد، اما باید نگاهی به ادغام Kubernetes بیندازیم. Docker Desktop.
Kubernetes به استانداردی برای ارکستراسیون کانتینر تبدیل شده است، به طوری که 83 درصد از پاسخ دهندگان به نظرسنجی CNCF 2020 گزارش دادند که از آن در تولید استفاده می کنند. توسعه، مانند جداسازی از سیستم میزبان. به علاوه، ما حتی میتوانیم از Docker Compose 2.0 برای اجرای چندین کانتینر با برخی از ویژگیهای شبکهای بسیار خوب استفاده کنیم. اما اگر روی پروژهای کار میکنید که در تولید Kubernetes به کار میرود، استفاده از یک محیط مشابه به صورت محلی انتخاب عاقلانهای است. زمان برای برخی سود کافی نداشت. این احتمالاً هنوز برای یک راه حل Docker DIY صادق است.
Docker Desktop، در مقابل، با یک سرور و مشتری Kubernetes مستقل برای آزمایش محلی ارائه می شود. این یک خوشه بدون پیچیدگی، بدون پیکربندی و تک گره است. همانطور که تصویر زیر نشان میدهد، میتوانید از طریق رابط کاربری به آن تغییر دهید، همانطور که تصویر زیر نشان میدهد، یا به روش معمول با پیکربندی kubectl use-context. از آخرین تراشه M1 که در دسترس عموم قرار گرفته است استفاده کنید. در حال حاضر بیش از 145000 تصویر مبتنی بر ARM در Docker Hub وجود دارد. این نسخه سیلیکون اپل از تصاویر چند پلتفرمی پشتیبانی می کند، به این معنی که می توانید تصاویر را برای معماری های x86 و ARM بدون محیط های پیچیده کامپایل متقابل بسازید و اجرا کنید. Rosetta 2 که عملکرد قابل قبولی را برای بسیاری از برنامه های معمول ارائه می دهد، برای اجرای کانتینرها کافی نیست. به روز رسانی، وصله و عیب یابی محیط کانتینر. هر توسعه دهنده در یک سازمان، هر بار که در یک محیط تازه کار می کند، بیشتر این کار را به صورت جداگانه انجام می دهد.
این رویکرد به خوبی مقیاس پذیر نیست! این بدان معناست که توسعهدهندگان برای فعالیتهایی که مستقیماً برای کسبوکار مفید هستند، مانند ویژگیهای جدید، وقت صرف نمیکنند. هیچ یک از ما از بررسی سرعتی که در آن باید توضیح دهیم که ویژگیای را به دلیل مشکلات یا راهاندازی محیطهای توسعه ارائه نکردهایم، لذت نمیبریم.
کانتینرسازی باید به تسهیل تحویل محصول کمک کند. آنچه Docker Desktop قصد دارد به آن دست یابد، جدید نیست. ما همیشه روی برنامهنویسی IDEها و ابزارهای دیگر سرمایهگذاری کردهایم که عملکردها را در یک بسته کاربرپسند و واحد برای بهبود بهرهوری جمع میکند. برای کمک به ارزیابی ROI.
کار با محیط های چندگانه
توسعه دهندگان به طور گسترده می پذیرند که مصنوعات ساخت باید تغییر ناپذیر باشند – همان برنامه، ساخته شده، باید از طریق QA به تولید حرکت کند. سطح بعدی، اگر بخواهید، بسته بندی یک برنامه کاربردی و وابستگی های آن با هم است. این به حفظ سازگاری بیشتر بین محیطهای توسعه، آزمایش و تولید کمک میکند.
اگر فرآیند خیلی پیچیده باشد، خطر درک این مزیت را داریم. سازمانها ابزارها و فرآیندهای بسیار خوبی را به تیمها معرفی کردهاند، فقط برای این ابزارها گرد و غبار را جمعآوری میکنند زیرا نوار ورود برای مهارتهای مورد نیاز بسیار بالا است.
این وضعیت در تیمهای QA برجستهتر است. بسیاری از آزمایشکنندهها فنی هستند، اما به طور معمول، آنها مجموعه خاصی از مهارتها را برای تست کردن دارند. از آنجایی که QA گروهی است که از محیطهای آزمایشی ثابت بهره میبرد، در نظر بگیرید که احتمالاً از چه چیزی استفاده میکنند. ویژگی توسعه، که در حال حاضر در حال پیشنمایش است، به نام Dev Environments نامیده میشود.
تغییر شاخهها یا محیطهای git معمولاً نیاز به تغییرات دستی زیادی در پیکربندی، وابستگیها و سایر تنظیمات محیطی قبل از امکان اجرای کد دارد.
ویژگی جدید آن را ایجاد میکند. به راحتی می توان جزئیات محیط خود را در کنترل منبع با کد نگه داشت. با کلیک یک دکمه، یک توسعهدهنده میتواند کارهای در حال انجام و خود را از طریق Docker Hub به اشتراک بگذارد. این بدان معناست که توسعهدهندگان میتوانند به راحتی به نمونههای کاملاً کارآمد از کار یکدیگر سوئیچ کنند، برای مثال، یک درخواست کشش را بدون نیاز به تغییر از شعبه محلی خود تکمیل کنند و همه آن تغییرات محیطی را انجام دهند.
در محیطهای توسعه با اسناد پیش نمایش شروع کنید
نتیجه
شاید بزرگترین چالش یک راهحل DIY از دیدگاه ارزش تجاری باشد. توسعه دهندگان عاشق کشف چگونگی انجام این کارها هستند. بنابراین، یک توسعهدهنده لزوماً تعداد ساعتهایی را که در طول یک هفته صرف حفظ یک راهحل DIY صرف کردهاند، ردیابی نمیکند – کسبوکار هیچ گونه کاهش بهرهوری را نخواهد داشت.
اگر هنوز از یک راهحل DIY برای توسعه محلی استفاده میکنید. با Docker در Windows یا macOS، درباره Docker Desktop بیشتر بدانید و برای شروع آن را دانلود کنید.