Question

我有一个dockerized项目，有三个应用程序和三个数据库。这三个应用程序是在节点中编写的，并照常使用npm。

我有一个克隆三个repos的脚本，docker-compose.yaml安装三个容器，并为三个项目中的每个项目使用Dockerfile基本上只执行npm install并运行它们。

这一切都运行正常，但本练习的重点是使项目集群易于设置和运行以用于开发目的。实际上处理项目代码不是问题，因为它被开发人员克隆，但是npm install是通过docker完成的，因此是root。这意味着回购中的node_modules由root拥有。

开发人员不能简单地npm install向repo添加新包，因为他们没有node_modules的权限，并且模块可能会根据其主机系统使用不同的体系结构构建

我考虑过创建一个在容器中运行npm install的脚本，但这有几点需要注意：

root将拥有package.json
这打破了典型的节点开发人员的流程......他们习惯于只做npm install

就像我上面所说的那样，这一点的重点是让它尽可能容易地进入和发展，所以我希望尽可能接近共同的开发经验。

有没有建议在docker容器中处理节点模块的安装以开发项目？

Answer 1

安装源文件夹的一个常见问题是，到目前为止我提出的最佳解决方案是简单地将主机用户的uid/gid与容器中的某个固定用户进行匹配。直到最近，必须使用一些外部工具和dockerfile / compose模板，使用最新的docker-compose版本（＆gt; = 1.6.0），您现在可以执行以下操作：

Dockerfile：

FROM busybox
ARG HOST_UID=1000
RUN adduser -D -H -u ${HOST_UID} -s /bin/sh npm
USER npm
RUN echo "i'm $(whoami) and have uid: ${HOST_UID}"

注意ARG指令。 HOST_UID的值在运行时通过docker build --build-arg HOST_UID=${UID}传递。然后，只需将npm的自定义HOST_UID用户添加为uid，并将其设置为默认USER以用于所有后续命令。

docker-compose和新版本2 yml格式现在也支持

--build-arg：

version: '2'
services:
  foo:
    build:
      context: .
      args:
        HOST_UID: ${UID}

如果在您的主机上设置了UID，则docker-compose up foo将使用与主机上的uid匹配的默认用户构建映像。我在那里学到的重要教训是，uid/gid对权限至关重要，实际的用户/组名称无关紧要。

我使用了几次的另一种技术是在容器启动时通过sed替换uid中固定用户的/etc/passwd/，如果设置了某个env。这样可以避免图像重建，并且适用于预期直接从某个存储库运行的图像。

最后，我建议完全接受docker哲学，这意味着你的开发人员只应该使用项目容器来完成npm install之类的任务。你可以避免不可避免的版本不匹配以及其他问题。

使用docker-compose项目进行npm安装

1 个答案: