看看Docker Desktop WSL2 backend |
您所在的位置：网站首页 › wsl2和vmware共存 › 看看Docker Desktop WSL2 backend |
看看Docker Desktop WSL2 backend
|
一、前言
这篇文章将通过"Docker Desktop 最新版以 WSL2 作后端"、"VirtualBox 和 VMware 最新版能和 Hype-V 共存"等方面来表达笔者对微软重新认识。实际上笔者对 Docker 的使用也没多长时间，而且还是桌面版，但不可否认它正在变得更加友好。从只能挂载（共享）磁盘，到能挂载具体的目录，到默认推荐以 WSL2 作后端，相信这其中也少不了微软开发者的投入。 二、Docker Desktop WSL 2 backend 相关文档：适用于 Linux 的 Windows 子系统文档 Docker Desktop WSL 2 backend WSL2简介（谷歌翻译）： 用于Linux的Windows子系统（WSL）2引入了重大的体系结构更改，因为它是由Microsoft构建的完整Linux内核，允许Linux容器在没有仿真的情况下本机运行。通过在WSL 2上运行的Docker Desktop，用户可以利用Linux工作区，而不必同时维护Linux和Windows构建脚本。此外，WSL 2改进了文件系统共享，启动时间，并允许Docker Desktop用户访问一些很酷的新功能。 Docker Desktop使用WSL 2中的动态内存分配功能来大大改善资源消耗。这意味着，Docker Desktop仅使用所需数量的所需CPU和内存资源，同时使CPU和内存密集型任务（如构建容器）运行得更快。 此外，使用WSL 2，冷启动后启动Docker守护程序所需的时间明显更快。与之前版本的Docker Desktop几乎要花一分钟相比，启动Docker守护程序所需的时间不到10秒。 WSL2 的开启方式：第一种： 控制面板 / 程序/程序和功能 / 启用或关闭 Windows 功能：勾选"适用于 Windows 的 Linux 子系统" 第二种： set-ExecutionPolicy RemoteSigned Enable-WindowsOptionalFeature -Online -FeatureName $("VirtualMachinePlatform","Microsoft-Windows-Subsystem-Linux") 最新版安装时的截图：PS 可以很明显的看出有不少的地方都使用了难得的圆角风格。
新版不再自动开启 Hype-V功能，因此无论使用 WSL2还是 Hype-V，都需要手动去开启。 尽管官网说明"最新版本的 WSL 使用 Hyper-V 体系结构来实现其虚拟化"，但 Hype-V 和 WSL2 并不需要同时开启。 新版的安装包只有 300 多兆。 开启 WSL2 后，还需要再安装 Linux 发行版才能挂载容器卷。简而言之：将开发环境迁移到Linux 子系统中。 关于容器卷挂载（谷歌翻译）： 将源代码和其他数据绑定安装到Linux容器（即带有docker run -v :）的Linux容器中，而不是Windows文件系统中。 如果原始文件存储在Linux文件系统中，则Linux容器仅接收文件更改事件（“ inotify事件”）。 当文件从Linux文件系统绑定安装而不是从Windows主机远程安装时，性能会更高。因此，请避免 docker run -v /mnt/c/users:/users（/mnt/c从Windows安装在哪里）。 相反，在Linux Shell中，使用诸如docker run -v ~/my-project:/sources where ~由Linux Shell扩展为的命令$HOME。 三、VirtualBox 和 VMware 和 Hype-V 并存记得之前在知乎上看过一篇文章：hyper-v 和 vmware 不兼容，是技术的原因？还是商业原因？。关于如何同时使用两者百度到的解决方案千篇一律为"二者舍其一"，现如今两种虚拟机软件都已能和Hype-V兼容，可见技术的伟大。 可以在WSL 2 常见问题解答中看到： 我是否能够运行 WSL 2 和其他第三方虚拟化工具（例如 VMware 或 VirtualBox）？ 当使用 Hyper-V 时，某些第三方应用程序无法工作，这意味着当启用了 WSL 2 时，这些应用程序（如 VMware 和 VirtualBox）将无法运行。 但最近，VirtualBox 和 VMware 都发布了支持 Hyper-V 和 WSL2 的版本！ 可在此处了解有关 VirtualBox 的更改的详细信息，并可在此处了解有关 VMware 的更改的详细信息。 我们一直在开发解决方案以支持 Hyper-V 的第三方集成。 例如，我们向第三方虚拟化提供商公开了一组称为虚拟机监控程序平台的 API，可以用来使其软件与 Hyper-V 兼容。 这使得应用程序可以将 Hyper-V 体系结构用于其模拟，例如，现在都与 Hyper-V 兼容的 Google 安卓模拟器和 VirtualBox 6 及更高版本。 四、继续使用Hype-V笔者并没有选择使用 WSL2 而是继续使用 Hype-V，因此上面安装 Docker Desktop 的截图里并没有勾选"Use the WSL 2 based engine"。主要原因有以下几个方面： VirtualBox 能和 Hype-V 同时使用了。这意味着笔者能在保证本地环境不变的情况下去使用虚拟机了。 微软建议将开发环境迁移到 WSL2 中，然而笔者并不是很习惯待在虚拟机里。事实上 WSL2 的主要诟病还是文件系统相互访问的效率太低。 虽然Docker文档中说使用Hype-V启动要一分钟，但笔者的实际体验是，无论是现在还是之前，除了第一次启动和改配置时重启会要好长时间之外，启动起来感觉还真不到1分钟，而且使用 WSL2 也是同样的效果。 笔者对 Docker 的使用目前还局限在 compose 或 stack 一组本地的数据库服务，也仅仅是为了替代本地安装。而且容器券挂载时可以使用相对路径，也不必迁移到 WSL2 中。 使用 WSL2 同时还意味着使用 Windows-Terminal，毕竟原生的 Powershell 或者 Cmd 并不是特别好看。笔者折腾过Windows-Terminal的美化，最终还是觉得 GitBash 作终端就很舒服，原生、简单、启动方便、响应快、路径格式好看、能在 IDEA 和 VSCode 里使用… 五、Windows 背着历史的包袱负重前行想必大家最开始对 Windows 以及对整个微软的印象都是闭源、反人类设计、各种不友好吧。除了Excel、“微软雅黑”、VSCode、Ts等屈指可数的几个感觉用起来特别舒服以外，别的产品真的很难说是好用，这其中笔者认为最反人类的设计就是万年的GBK编码和反斜杠的路径分隔符，笔者目前的解决办法是使用 Beta 版的 UTF-8 字符集 + GitBash，然而实际上反而有点因小失大。 引用文章： 各大公司在GitHub上开源投入排名分析 从相杀到相爱，微软为什么会爱上Linux？微软收购了 GitHub，不久后GitHub的界面变成圆角风格，各种新Windows概念图层出不穷，且不论真假，但可以肯定的是无论是微软本身还是大众对微软的态度都在潜移默化的发生着变化，不然也不会花精力去制作概念版的PPT。 曾看到一篇文章，题目大致叫"现在都是64位了，为什么软件还装在ProgramFiles(x86)里"，忘了名字也没找到。文章里大概分析了开发者不愿重新编译发布的现象以及Windows 兼容升级的为难。还有一句印象非常深刻的话：兼容升级的被喷各种不兼容（如Windows），不兼容升级的大家连连叫好（如Py）。倘若Windows能真正放下历史的包袱，把Windows设计的如VSCode那般友好该有多好！ |
【本文地址】