Docker Desktop ۴.۹۵.۰ در ۱۲ اکتبر ۲۰۲۶ منتشر شد و تمرکز آن بیشتر روی پایداری محیط توسعه، رفع خطاهای ویندوز و قابلمشاهدهتر شدن وضعیت حساب Docker است. این نسخه برای تیمهایی مهم است که Docker را روی Windows با WSL یا Hyper-V اجرا میکنند، Kubernetes داخلی را برای آزمایش به کار میگیرند یا سیاست Enhanced Container Isolation را برای کاهش ریسک کانتینرها فعال کردهاند.
در Docker Desktop ۴.۹۵ چه چیزهایی اصلاح شده است؟
یادداشت رسمی Docker چند اصلاح مهم را ثبت میکند. در همهٔ پلتفرمها، مشکلی که باعث restart شدن Engine بلافاصله پس از اجرای Docker Desktop در شرایط فعال بودن Enhanced Container Isolation میشد برطرف شده است. همچنین شروع Kubernetes در حالتی که دریافت image از Registry Access Management با یک timeout موقت روبهرو میشد، پایدارتر شده است.
در ویندوز، سازگاری با WSL ۳.۰.۱ بهتر شده و خطایی که docker info را به نمایش «Docker Desktop (containerized)» و در نتیجه شکست docker debug میرساند، اصلاح شده است. خطاهای نصب و بهروزرسانی، Hyper-V، مدیریت symlinkهای WSL/MSYS2، exportهای sparse stream و راهاندازی VM نیز در فهرست اصلاحات هستند. برای استقرار سازمانی، installer ویندوز حالا در سناریوی نصب per-user از حساب SYSTEM خطای روشنتری نشان میدهد؛ این موضوع برای نصب با SCCM یا Intune مهم است.
قابلیت جدید برای بررسی وضعیت ورود
نسخهٔ ۴.۹۵ فرمان جدید docker desktop auth status را اضافه میکند. این فرمان میتواند وضعیت ورود به Docker Hub، نام کاربر، ایمیل، نوع پلن و عضویت سازمانی را نمایش دهد و خروجی pretty یا json ارائه کند. خروجی JSON برای health check، مستندسازی وضعیت دستگاههای تیم و بررسی پیشنیازهای استقرار خودکار مناسبتر است؛ بااینحال نباید خروجی آن را جایگزین سیاستهای واقعی دسترسی یا کنترل secrets دانست.
چکلیست پیش از ارتقا
قبل از نصب Docker Desktop ۴.۹۵، از وضعیت فعلی WSL، نسخهٔ Windows، backend فعال و محل disk image گزارش بگیرید. اگر Kubernetes داخلی استفاده میشود، فهرست imageهای موردنیاز و مسیر دسترسی registry را ثبت کنید و یک تست start/stop برای cluster داشته باشید. در محیطهایی که Enhanced Container Isolation فعال است، راهاندازی Engine، اجرای یک کانتینر آزمایشی و دسترسیهای مورد انتظار را در staging بررسی کنید.
در سازمانها، نصب را با همان روش واقعی—مانند Intune، SCCM یا installer محلی—آزمایش کنید. مخصوصاً اگر نصب per-user دارید، مطمئن شوید فرایند با حساب SYSTEM اجرا نمیشود. پس از ارتقا، docker info، وضعیت WSL و Hyper-V، شروع Kubernetes و دسترسی به registry را بررسی کنید. سپس چند workload واقعی را اجرا کنید و لاگهای Docker Desktop را برای خطای تکرارشونده زیر نظر بگیرید.
ارتقا را قابل بازگشت نگه دارید
برای سیستمهای توسعهٔ شخصی، پیش از نصب میتوان از پروژهها، فایلهای Compose، تنظیمات مهم و فهرست imageهای محلی خروجی گرفت. در محیطهای تیمی، همین اطلاعات را در یک runbook کوتاه ثبت کنید تا اگر نسخهٔ جدید با افزونهٔ امنیتی، backend مجازیسازی یا ابزار CI ناسازگار بود، بازگشت به نسخهٔ قبلی تصمیمی فوری و حدسی نباشد. وضعیت disk image و فضای خالی میزبان را نیز ثبت کنید؛ خطاهای ظاهراً مربوط به Docker گاهی از کمبود فضای دیسک یا توقف سرویس مجازیسازی ناشی میشوند.
فرمان docker desktop auth status برای مشاهدهٔ وضعیت حساب مفید است، اما خروجی آن را در لاگ عمومی یا تیکتهای قابلدسترسی برای همه ذخیره نکنید؛ نام کاربر، ایمیل و عضویت سازمانی ممکن است اطلاعات سازمانی محسوب شود. در health check خود فقط فیلدهای لازم را نگه دارید و دسترسی به خروجی JSON را محدود کنید. بعد از ارتقا، یک اجرای آزمایشی login، pull از registry خصوصی و build واقعی انجام دهید تا تفاوت میان «ورود حساب» و «دسترسی مؤثر به منابع» روشن باشد.
اگر Docker Desktop ۴.۹۵ روی چندین دستگاه سازمانی نصب است، ابتدا یک گروه کوچک از کاربران فنی را بهعنوان حلقهٔ آزمایشی انتخاب کنید. نتیجهٔ WSL، Kubernetes، build، pull و اجرای workload را ثبت کنید و سپس rollout را مرحلهای انجام دهید. این کار احتمال آن را کم میکند که یک اصلاح مفید در یک نسخه، همزمان باعث اختلال گسترده در محیط توسعه یا pipelineهای CI شود.
Docker Desktop ۴.۹۵ یک انتشار نگهداری است، اما اصلاحات Docker Desktop ۴.۹۵ میتواند برای محیطهای ویندوزی و تیمهایی که همزمان از WSL، Kubernetes و ایزولهسازی کانتینر استفاده میکنند ارزش عملی داشته باشد. بهترین مسیر، ارتقای مرحلهای، ثبت rollback و تأیید سلامت workloadها پیش از production است.
منبع رسمی: یادداشت انتشار Docker Desktop ۴.۹۵
برای مطالعهٔ راهنماهای مرتبط، مقالات فنی تکتاز مگ را ببینید.








