优化基于容器的（开发）环境的最佳实践

Question

OCI容器是一种为项目打包合适的工具链的便捷方法，这样开发环境就可以保持一致，并且新项目成员可以通过简单地检出项目并拉出相关容器来快速启动。

• 当然，我不是在谈论只需要C ++编译器或Node.JS的项目。我说的是需要特定的编译器软件包的项目，这些软件包不能与Fedora 22或更高版本一起使用；需要特殊工具的项目需要手动安装到陌生的地方；正在处理多个项目，这些项目具有无法共同安装的工具，例如。对于这种事情，拥有一个容器要比遵循二十个安装步骤要容易得多，然后祈祷上一个项目剩下的零碎东西不会为您带来麻烦。

但是，使用编译器启动容器来构建项目需要在docker（或podman）命令行上有很多选择。除了图像名称，通常：

• 项目工作目录的数量
• 用户ID（因为容器应以运行它的用户身份访问已挂载的文件）
• 如果该工具需要访问某些网络资源，则可能还需要
  • 一些凭证，通过环境还是其他方式
  • ssh代理套接字（安装和环境变量）
• 如果构建过程涉及构建docker容器
  • docker套接字（安装）； buildah可能无需特殊设置即可工作
• ，如果是图形工具（例如IDE）
  • X套接字安装和环境变量
  • --ipc host使共享内存正常工作

然后它可能会由于其他因素而变得更加复杂。例如。如果开发人员位于不同的部门并且无法访问相同的docker存储库，则它们的映像可能会以不同的方式调用，因为docker不支持存储库的符号名称（尽管podman支持）。 / p>

是否有某种标准的方式来处理这些选项，或者每个人都只是使用即席包装脚本？

Answer 1

我使用Visual Studio Code Remote - Containers extension将源代码连接到Docker容器，该容器包含构建代码所需的所有工具（例如npm模块，ruby gems，eslint ，Node.JS，java）。该容器包含用于开发/构建/测试源代码的所有“工具”。

此外，您还可以将VSCode扩展名放入Docker映像中，以帮助保持VSCode IDE工具的可移植性。  https://code.visualstudio.com/docs/remote/containers#_managing-extensions

您可以在源代码中提供一个Dockerfile，供新手使用build the Docker image themselves或将VSCode附加到existing Docker container。

如果出于测试目的需要在Docker容器中运行服务器，则可以通过VSCode expose a port on the container，然后使用浏览器或从主机上使用cURL来访问容器中的服务器。

请注意known limitations至Visual Studio Code Remote-容器扩展名。对我影响最大的是beta support for Alphine Linux。我经常注意到一些流行的Docker Hub映像基于Alphine。