现已推出!阅读关于 11 月份新功能和修复的详细信息。

开发容器技巧

本文包含一些技巧,用于在不同环境中启动和运行开发容器扩展。

安装 Docker 的其他方法

您可以通过多种方式将 Docker 与开发容器扩展一起使用,包括

  • 本地安装的 Docker。
  • 在远程环境中安装的 Docker。
  • 本地或远程安装的其他 Docker 兼容 CLI。

您可以在替代 Docker 选项文档中了解更多信息。

Docker Desktop for Windows 技巧

适用于 Windows 的 Docker Desktop在大多数设置中运行良好,但有一些“陷阱”可能会导致问题。以下是一些避免这些问题的技巧

  1. 考虑在 Windows 10 (2004+) 上使用新的 Docker WSL 2 后端。如果您正在使用Docker Desktop 的 WSL 2 后端,您可以使用它来打开 WSL 内以及本地的文件夹。容器也在 Windows 和 WSL 内部共享,并且这个新引擎不太容易受到文件共享问题的影响。有关详细信息,请参阅快速入门

  2. 切换出“Windows 上的 Linux 容器 (LCOW)”模式。虽然默认禁用,但最新版本的 Docker 支持Windows 上的 Linux 容器 (LCOW),这可以允许您同时使用 Windows 和 Linux 容器。但是,这是一个新功能,因此您可能会遇到问题,并且开发容器扩展目前仅支持 Linux 容器。您可以通过右键单击 Docker 任务栏项并从上下文菜单中选择切换到 Linux 容器...,随时切换出 LCOW 模式。

  3. 确保您的防火墙允许 Docker 设置共享驱动器。Docker 仅需要在两台机器本地 IP 之间连接,但某些防火墙软件可能仍然会阻止任何驱动器共享或所需的端口。有关解决此问题的后续步骤,请参阅此 Docker KB 文章

以下是一些适用于旧版本 Docker for Windows 的技巧,但现在应该已解决。如果您由于可能的回退而遇到奇怪的行为,这些技巧过去已解决过问题。

  1. 共享驱动器时使用 AD 域帐户或本地管理员帐户。不要使用 AAD(基于电子邮件)帐户。AAD(基于电子邮件)帐户存在众所周知的问题,如 Docker 问题 #132问题 #1352 中所述。如果您必须使用 AAD 帐户,请在您的机器上创建一个单独的本地管理员帐户,该帐户专门用于共享驱动器。请按照此博客文章中的步骤进行所有设置。

  2. 坚持使用字母数字密码以避免驱动器共享问题。当要求您在 Windows 上共享您的驱动器时,系统会提示您输入在机器上具有管理员权限的帐户的用户名和密码。如果您收到有关用户名或密码不正确的警告,这可能是因为密码中存在特殊字符。例如,![] 已知会导致问题。请将您的密码更改为字母数字字符以解决此问题。有关详细信息,请参阅有关 Docker 卷挂载问题 的此问题。

  3. 使用您的 Docker ID 登录 Docker(而不是您的电子邮件)。Docker CLI 仅支持使用您的 Docker ID,因此使用您的电子邮件可能会导致问题。有关详细信息,请参阅 Docker 问题 #935

如果您仍然遇到问题,请参阅适用于 Windows 的 Docker Desktop 故障排除指南

在 Docker Desktop 中启用文件共享

只有当您的代码位于与 Docker 共享的文件夹或驱动器中时,VS Code 开发容器扩展才能自动将您的源代码挂载到容器中。如果您从非共享位置打开开发容器,容器将成功启动,但工作区将为空。

请注意,使用Docker Desktop 的 WSL 2 引擎不需要此步骤。

要更改 Docker 的驱动器和文件夹共享设置

Windows

  1. 右键单击 Docker 任务栏项并选择设置
  2. 转到资源 > 文件共享,然后选中您的源代码所在的驱动器。
  3. 如果您看到有关本地防火墙阻止共享操作的消息,请参阅此 Docker KB 文章以了解后续步骤。

macOS

  1. 单击 Docker 菜单栏项并选择首选项
  2. 转到资源 > 文件共享。确认包含您的源代码的文件夹位于列出的共享文件夹之一下方。

解决容器中 Git 行尾问题(导致许多修改的文件)

由于 Windows 和 Linux 使用不同的默认行尾,因此 Git 可能会报告大量修改的文件,除了行尾之外没有任何差异。为了防止这种情况发生,您可以使用 .gitattributes 文件或在 Windows 端全局禁用行尾转换。

通常,在您的存储库中添加或修改 .gitattributes 文件是解决此问题的最可靠方法。将此文件提交到源代码管理将有助于其他人,并允许您根据需要按存储库更改行为。例如,将以下内容添加到存储库根目录下的 .gitattributes 文件会将所有内容强制为 LF,除了需要 CRLF 的 Windows 批处理文件

* text=auto eol=lf
*.{cmd,[cC][mM][dD]} text eol=crlf
*.{bat,[bB][aA][tT]} text eol=crlf

请注意,这适用于 Git v2.10+,因此如果您遇到问题,请确保已安装最新的 Git 客户端。您可以在此同一文件中添加存储库中其他需要 CRLF 的文件类型。

如果您仍然希望始终上传 Unix 样式的行尾 (LF),则可以使用 input 选项。

git config --global core.autocrlf input

如果您希望完全禁用行尾转换,请改为运行以下命令:

git config --global core.autocrlf false

最后,您可能需要再次克隆存储库,这些设置才能生效。

使用 Docker Compose 时,避免在容器中设置 Git

有关解决此问题的更多信息,请参阅主要容器文章中的与容器共享 Git 凭据

解决从容器执行 Git 推送或同步时挂起的问题

如果您使用 SSH 克隆 Git 存储库,并且您的 SSH 密钥有密码,则在远程运行时,VS Code 的拉取和同步功能可能会挂起。

要解决此问题,请使用没有密码的 SSH 密钥、使用 HTTPS 克隆,或者从命令行运行 git push

解决有关缺少 Linux 依赖项的错误

某些扩展依赖于某些 Docker 镜像中未找到的库。有关解决此问题的一些选项,请参阅容器文章。

加快 Docker Desktop 中容器的速度

默认情况下,Docker Desktop 仅为容器提供一小部分计算机容量。在大多数情况下,这已经足够了,但如果您正在执行需要更多容量的操作,则可以增加内存、CPU 或磁盘使用量。

首先,尝试停止任何不再使用的正在运行的容器

如果这不能解决您的问题,您可能需要查看 CPU 使用率是否确实是问题所在,或者是否存在其他问题。检查此问题的一种简单方法是安装资源监视器扩展。当安装在容器中时,它会在状态栏中提供有关容器容量的信息。

Resource use Status bar

如果您希望始终安装此扩展,请将其添加到您的 settings.json

"dev.containers.defaultExtensions": [
    "mutantdino.resourcemonitor"
]

如果您确定需要为容器提供更多计算机容量,请按照以下步骤操作

  1. 右键单击 Docker 任务栏项,然后选择设置 / 首选项
  2. 转到高级以增加 CPU、内存或交换空间。
  3. 在 macOS 上,转到磁盘以增加 Docker 允许在您的计算机上消耗的磁盘空间量。在 Windows 上,它与其他设置位于“高级”下。

最后,如果您的容器正在执行磁盘密集型操作,或者您只是在寻找更快的响应时间,请参阅提高容器磁盘性能以获取提示。VS Code 的默认设置针对便利性和通用支持进行了优化,但可以进行优化。

清除未使用的容器和映像

如果您看到 Docker 报告磁盘空间不足的错误,您通常可以通过清理未使用的容器和镜像来解决此问题。有几种方法可以做到这一点

选项 1:使用远程资源管理器

您可以通过选择远程资源管理器来删除容器,右键单击要删除的容器,然后选择删除容器

Remote Explorer screenshot

但是,这不会清理您可能已下载的任何镜像,这可能会使您的系统变得混乱。

选项 2:使用 Docker 扩展

  1. 在 VS Code 中打开一个本地窗口(文件 > 新建窗口)。

  2. 如果尚未安装,请从扩展视图安装Docker 扩展

  3. 然后,您可以转到 Docker 视图并展开容器镜像节点,右键单击并选择删除容器/镜像

    Docker Explorer screenshot

选项 3:使用 Docker CLI 选择要删除的容器

  1. 打开一个本地终端/命令提示符(或在 VS Code 中使用本地窗口)。
  2. 键入 docker ps -a 以查看所有容器的列表。
  3. 从该列表中键入 docker rm <容器 ID> 以删除容器。
  4. 键入 docker image prune 以删除任何未使用的镜像。

如果 docker ps 没有提供足够的信息来识别您要删除的容器,则以下命令将列出 VS Code 管理的所有开发容器以及用于生成它们的文件夹。

docker ps -a --filter="label=vsch.quality" --format "table {{.ID}}\t{{.Status}}\t{{.Image}}\tvscode-{{.Label \"vsch.quality\"}}\t{{.Label \"vsch.local.folder\"}}"

选项 4:使用 Docker Compose

  1. 打开一个本地终端/命令提示符(或在 VS Code 中使用本地窗口)。
  2. 转到包含 docker-compose.yml 文件的目录。
  3. 键入 docker-compose down 以停止并删除容器。如果您有多个 Docker Compose 文件,则可以使用 -f 参数指定其他 Docker Compose 文件。

选项 4:删除所有未运行的容器和镜像

  1. 打开一个本地终端/命令提示符(或在 VS Code 中使用本地窗口)。
  2. 键入 docker system prune --all

解决使用 Debian 8 的映像的 Dockerfile 构建失败问题

在构建使用基于 Debian 8/Jessie 的镜像(例如旧版本的 node:8 镜像)的容器时,您可能会遇到以下错误

...
W: Failed to fetch http://deb.debian.org/debian/dists/jessie-updates/InRelease  Unable to find expected entry 'main/binary-amd64/Packages' in Release file (Wrong sources.list entry or malformed file)
E: Some index files failed to download. They have been ignored, or old ones used instead.
...

这是一个众所周知的问题,由 Debian 8 被“存档”引起。较新版本的镜像通常通过升级到 Debian 9/Stretch 来解决此问题。

有两种方法可以解决此错误

  • 选项 1:删除任何依赖于该镜像的容器,删除该镜像,然后尝试再次构建。这应该会下载一个不受该问题影响的更新镜像。有关详细信息,请参阅清理未使用的容器和镜像

  • 选项 2:如果您不想删除容器或镜像,请在任何 aptapt-get 命令之前将此行添加到您的 Dockerfile 中。它为 Jessie 添加了所需的源列表

    # Add archived sources to source list if base image uses Debian 8 / Jessie
    RUN cat /etc/*-release | grep -q jessie && printf "deb http://archive.debian.org/debian/ jessie main\ndeb-src http://archive.debian.org/debian/ jessie main\ndeb http://security.debian.org jessie/updates main\ndeb-src http://security.debian.org jessie/updates main" > /etc/apt/sources.list
    

解决使用电子邮件时 Docker Hub 登录错误

Docker CLI 仅支持使用您的 Docker ID,因此使用您的电子邮件登录可能会导致问题。有关详细信息,请参阅 Docker issue #935

作为一种解决方法,请使用您的 Docker ID 而不是您的电子邮件登录 Docker。

macOS 上 Hyperkit 的高 CPU 利用率

有一个Docker for Mac 的已知问题,可能会导致 CPU 峰值过高。特别是,当监视文件和构建时,会出现高 CPU 使用率。如果在 Activity Monitor 中看到 com.docker.hyperkit 的 CPU 使用率很高,而您的开发容器中几乎没有进行任何操作,则您很可能遇到了此问题。请关注Docker 问题以获取更新和修复。

使用 SSH 隧道连接到远程 Docker 主机

在远程 Docker Machine 或 SSH 主机上的容器内进行开发文章介绍了在使用远程 Docker 主机时如何设置 VS Code。这通常就像在 settings.json 中设置Docker 扩展docker.environment 属性,或者将 DOCKER_HOST 环境变量设置为 ssh://tcp:// URI 一样简单。

但是,您可能会遇到由于 SSH 配置复杂或其他限制而导致这种情况在您的环境中无法工作的情况。在这种情况下,可以使用 SSH 隧道作为后备方案。

使用 SSH 隧道作为后备方案

您可以设置 SSH 隧道并将 Docker 套接字从远程主机转发到本地计算机。

请按照以下步骤操作

  1. 安装与 OpenSSH 兼容的 SSH 客户端

  2. 在您的用户或工作区 settings.json 中更新Docker 扩展docker.environment 属性,如下所示

    "docker.environment": {
        "DOCKER_HOST": "tcp://127.0.0.1:23750"
    }
    
  3. 从本地终端/PowerShell 运行以下命令(将 user@hostname 替换为远程用户的用户名和服务器的主机名/IP)

    ssh -NL localhost:23750:/var/run/docker.sock user@hostname
    

VS Code 现在将能够附加到远程主机上任何正在运行的容器。您还可以使用专门的本地 devcontainer.json 文件来创建/连接到远程开发容器

完成后,按终端/PowerShell 中的 Ctrl+C 关闭隧道。

注意:如果 ssh 命令失败,您可能需要在您的 SSH 主机上 AllowStreamLocalForwarding

  1. SSH 主机(而不是本地)上的编辑器(如 Vim、nano 或 Pico)中打开 /etc/ssh/sshd_config
  2. 添加设置 AllowStreamLocalForwarding yes
  3. 重新启动 SSH 服务器(在 Ubuntu 上,运行 sudo systemctl restart sshd)。
  4. 重试。

持久化用户配置文件

您可以使用 mounts 属性在重新构建时持久化开发容器中的用户配置文件(以保留诸如 shell 历史记录之类的东西)。

    "mounts": [
        "source=profile,target=/root,type=volume",
        "target=/root/.vscode-server,type=volume"
    ],

上面的代码首先创建一个名为 profile 的命名卷,该卷装载到 /root,它将在重新构建后继续存在。接下来,它创建一个装载到 /root/.vscode-server 的匿名卷,该卷会在重新构建时销毁,从而允许 VS Code 重新安装扩展和点文件。

高级容器配置技巧

有关以下主题的信息,请参阅高级容器配置文章

扩展技巧

虽然许多扩展都可以未修改地工作,但有一些问题可能会阻止某些功能按预期工作。在某些情况下,您可以使用其他命令来解决该问题,而在其他情况下,可能需要修改扩展。远程扩展提示部分提供了有关常见问题和解决提示的快速参考。您还可以参考有关支持远程开发的主要扩展文章,以获取有关修改扩展以支持远程扩展主机的深入指南。

问题和反馈

报告问题

如果您在使用开发容器扩展时遇到问题,请务必收集正确的日志,以便我们能够帮助诊断您的问题。您可以使用开发容器:显示容器日志获取开发容器扩展日志。

如果您在使用其他远程扩展时遇到问题(例如,其他扩展在远程环境中未正确加载或安装),则最好从远程扩展主机输出通道(输出:焦点在输出视图上)获取日志,然后从下拉列表中选择日志(远程扩展主机)

注意:如果您只看到日志(扩展主机),则这是本地扩展主机,而远程扩展主机未启动。这是因为日志通道仅在创建日志文件后创建,因此如果远程扩展主机未启动,则不会创建远程扩展主机日志文件,也不会在“输出”视图中显示。这仍然是有助于包含在您的问题中的信息。

远程问题和反馈资源

我们有各种其他远程资源