使用 Remote Docker 构建干净的开发环境及 Remote SSH + Remote Container 双重 Buff

<h1 id="vscode-">VSCode 容器开发环境</h1>
作为从没有插件的 v0.x 年代开始使用 VSCode 的铁杆用户，所有的开发几乎全都使用 VSCode 进行。 
由于 VSCode 本身只是一个编辑器，要实现各种功能需要大量的插件支持，想要达到 100 个插件并不是一个复杂的事情。 
而实际上并非所有环境都需要所有的插件，让 VSCode 保持一个功能刚好够用的 “IDE” 是很有必要的。
<h2 id="heading">自动启用/禁用插件</h2>
最简单的想法是，每个文件夹/工作区可以配置启用哪些插件。 
目前 VSCode 存在该功能，但是对用户黑盒。通过右键插件可以控制在当前工作区禁用（不影响其他工作区），所有工作区级别的禁用/启用并没有一个对用户可见的文件存储，也就无法像 <code>settings.json</code> 或 <code>extensions.json</code> 那样放置在文件夹内。 
虽然对于同一台电脑，用户并没有手动维护的必要性，但是如果文件夹路径修改，可能就需要重新配置
在 Github 上，有人提出了 <a href="https://github.com/microsoft/vscode/issues/40239">这个问题</a>，希望可以在 <code>extensions.json</code> 中添加 <code>disabled</code> 字段来控制禁用哪些插件，但 VSCode 团队认为 <code>extensions.json</code> 存在副作用，由于其是存放在 <code>.vscode</code> 文件夹内，原则上是和代码绑定的，用户 A 使用哪些插件不应该影响用户 B。 
（看上去很有道理，但是 <code>settings.json</code> 实际上已经存在这个问题了，而且用户可以通过配置 <code>.gitignore</code> 来规避）
最近，官方推出了 settings-profile，可以把上面提到的 “黑盒配置” 共享出来。但是这并没有完美解决问题，仍然不是一个比较优雅的解决方案（甚至可以认为完全没有解决）。
<h2 id="remote-container">Remote Container</h2>
VSCode 最有名的功能是 Remote SSH，图形界面远程开发怎么想都很跨时代。和这个功能一起推出的是 Remote WSL 和 Remote Container，前者由于经常在 WSL 开发，所以用得很多，而后者则由于存在一定的学习门槛因此没用过。
首先简单描述下 Remote Container 的大致思路，用户通过预先配置开发环境容器（可以是一个镜像，也可以是一个 Dockerfile，亦或是 Docker Compose），VSCode 会自动拉取/构建对应的镜像文件，并按照配置启动容器，并将代码挂载入容器内进行开发
这里以 golang 开发为例，我们希望容器包含如下内容
<ul>
<li>go 二进制</li>
<li>go 的相关插件</li>
<li>go 的基本配置</li>
<li>一些个人习惯的配置</li>
</ul>
为了方便在基础 Golang 镜像的基础上进行配置，使用 Dockerfile 来生成镜像。 
镜像本身没有需要特别注意的地方，唯一可能会有问题的是用户权限，vscode 会自动绑定当前用户/用户组和容器内的用户/用户组，因此需要确保容器内拥有对应的配置
<pre style="background-color:#fff">ARG USERNAME=vscode
ARG USER_UID=1000
ARG USER_GID=$USER_UID

RUN groupadd --gid $USER_GID $USERNAME \
 &amp;&amp; useradd -s /bin/bash --uid $USER_UID --gid $USER_GID -m $USERNAME
USER ${USERNAME}
</pre>接下来就是控制如何启动容器。 
对于端口映射，这里有两种不一样的实现，但是效果差别不大
<ul>
<li>容器本身的端口映射：在容器创建前通过 <code>-p</code> 指定，容器只要运行就会自动映射</li>
<li>VSCode 转发：类似 ssh 的端口转发，只要会话连接存在，转发就可用。但是如果连接关闭（ssh 断开/vscode 关闭，那么转发就会停止，即使服务器/容器还在运行）</li>
</ul>
前者不支持修改，创建容器时配置了哪些，就只能是哪些，“几乎”不能修改（参考“如何为已经启动的容器添加映射端口”）；而后者则支持动态转发。 
前者的配置通过 <code>&quot;appPort&quot;: [ 3000, &quot;8921:5000&quot; ]</code>，后者则是 <code>&quot;forwardPorts&quot;: [3000, 3001]</code> 
如果需要指定映射的端口，可以通过 <code>&quot;forwardPorts&quot;: [3000, 3001]</code> 来配置，也可以在容器启动后手动指定。
容器默认会挂载代码目录，但是如果有特殊的需要也可以通过 <code>&quot;mounts&quot;: [&quot;source=${localWorkspaceFolder}/app-scripts,target=/usr/local/share/app-scripts,type=bind,consistency=cached&quot;]</code> 指定挂载其他目录。 
为了保持开发环境的“干净”，不建议加这些东西
对于一些特殊功能，可以使用官方的 <code>feature</code> 来进行配置，比如 Docker in Docker、<code>git</code> 或是一些基础的开发环境。不过这部分完全可以写在 Dockerfile 里，可控性更高一点。
大部分常用的配置就这些，如果不希望容器名过于随机，可以使用 <code>&quot;runArgs&quot;: [&quot;--name=dev-go-example&quot;]</code> 强行指定
在 vscode 关闭后，容器会自动停止，可以通过配置 <code>&quot;shutdownAction&quot;: &quot;none&quot;</code> 禁用
下面给出一份 golang 的简单开发环境
<pre style="background-color:#fff">{
 &#34;name&#34;: &#34;golang&#34;,
 &#34;build&#34;: {
 &#34;dockerfile&#34;: &#34;Dockerfile&#34;
 },
 &#34;runArgs&#34;: [
 &#34;--name=dev-go-example&#34;
 ],
 &#34;extensions&#34;: [
 &#34;golang.go&#34;,
 &#34;ms-azuretools.vscode-docker&#34;
 ]
}
</pre><pre style="background-color:#fff">FROM golang:1.17.0

ARG USERNAME=vscode
ARG USER_UID=1000
ARG USER_GID=$USER_UID

RUN groupadd --gid $USER_GID $USERNAME \
 &amp;&amp; useradd -s /bin/bash --uid $USER_UID --gid $USER_GID -m $USERNAME
USER ${USERNAME}

RUN go install github.com/cweill/gotests/gotests@latest
RUN go install github.com/fatih/gomodifytags@latest
RUN go install github.com/josharian/impl@latest
RUN go install github.com/haya14busa/goplay/cmd/goplay@latest
RUN go install github.com/go-delve/delve/cmd/dlv@latest
RUN go install honnef.co/go/tools/cmd/staticcheck@latest
RUN go install golang.org/x/tools/gopls@latest

RUN curl -o ${HOME}/.bashrc \
 -k \
 &#34;https://proxy.ohyee.cc/gist.githubusercontent.com/OhYee/87228bbce831b4b7027e3d6407e7b2f8/raw/.bashrc&#34; 

</pre><h2 id="remote-ssh--remote-container">Remote SSH + Remote Container</h2>
值得一提的是，到现在位置，实际上大部分开发并不在本地进行，服务器开发往往可以获得更高配置。而值得一提的是，VSCode 支持通过 remote ssh 使用 remote container，也即使用服务器上的 Docker 进行开发。
这一切对于大部分场景而言，完全和本机一致，用户完全无感。特殊情况下可能会存在下面的问题
<ul>
<li>用户没有 docker 执行权限，需要确保用户在 docker 用户组，并且 docker 允许同组用户读写
<pre style="background-color:#fff"># 将当前用户添加至用户组
usermod -a -G docker &lt;当前用户&gt;

# 查看 docker socket 文件权限（应该是 srw-rw----）
ls -l /var/run/docker.sock 
</pre></li>
<li>服务器上有多个用户，而且大家都在用 remote-container。由于临时文件可能存在权限冲突，可以考虑把不同的用户临时文件放在不同的文件夹内，比如在 <code>/etc/profile.d/</code> 添加一个 <code>tmp.sh</code> 文件并写入下下面的内容
<pre style="background-color:#fff">export TMPDIR=/tmp/${USER}
mkdir -p ${TMPDIR}
</pre>当然，如果只想修改自己用户的临时文件夹，也可以加入到 <code>~/.bashrc</code>
</li>
</ul>
就目前而言，微软和 Docker 的合作出的内容可谓是非常贴心的，从 WSL + Docker 到 Remote SSH + Docker，存在很多非常细节上的正向优化，完全不像是那个开发 Windows 的微软。
<h2 id="heading-1">后记</h2>
为不同的项目配置不同的容器开发环境，一方面可以保证开发环境的干净。虽然 vscode 的插件存在启动触发判断，但是这取决于开发者的自觉，一个 python 插件完全可以申请 java 的触发。而即使同样是同一种语言，有时插件间也可能存在冲突，不同的项目需要选择不同的插件使用。
另一方面，一个可移植的开发环境有助于别人环境搭建。开源或是公司项目自不必说，保持开发环境一致至关重要。而即使是个人项目，时间长了环境部署也可能会存在问题，而且在同时多个项目开发时，由于不同项目环境可能存在冲突，有存在引入玄学 bug 的可能。
<h2 id="heading-2">参考资料</h2>
<ul>
<li><a href="https://github.com/microsoft/vscode/issues/40239">microsoft/vscode Issue #4023 Feature Request: Enable/disable extensions from config file 9</a></li>
<li><a href="https://github.com/microsoft/vscode-remote-release/issues/2347#issuecomment-996888780">microsoft/vscode-remote-release Issue #2347 EACCES: permission denied, mkdir '/tmp/vsch</a></li>
<li><a href="https://code.visualstudio.com/docs/remote/containers">Developing inside a Container using Visual Studio Code Remote Development</a></li>
<li><a href="https://code.visualstudio.com/docs/remote/devcontainerjson-reference">devcontainer.json reference</a></li>
<li><a href="https://www.ooordinary.com/post/wsldockerdl">【环境搭建】WSL下基于Docker的深度学习环境配置</a></li>
<li><a href="/post/note_docker">如何优雅地使用 Docker</a></li>
</ul>