为什么Docker文件系统权限在GitHub Actions上表现不同(在服务器上拒绝权限)

Question

我有一个应用程序与Dockerfile:

# From here on we use the least-privileged `node` user to run the backend.
USER node
WORKDIR /app

# This switches many Node.js dependencies to production mode.
ENV NODE_ENV production
# Copy repo skeleton first, to avoid unnecessary docker cache invalidation.
# The skeleton contains the package.json of each package in the monorepo,
# and along with yarn.lock and the root package.json, that's enough to run yarn install.
COPY --chown=node:node yarn.lock package.json packages/backend/dist/skeleton.tar.gz ./
RUN tar xzf skeleton.tar.gz && rm skeleton.tar.gz

这是官方后台命令行(https://github.com/backstage/backstage/issues/15421)生成的dockerfile的一部分。

当我在我的Mac和我同事的Windows机器上运行docker构建时，构建工作正常。

但是，当我们在GitHub Actions或Microsoft ADO上尝试相同的构建时，docker构建失败并出现文件系统权限错误:

Step 7/11 : RUN tar xzf skeleton.tar.gz && rm skeleton.tar.gz
---> Running in b20314a0495a
tar: packages: Cannot mkdir: Permission denied
tar: packages/app/package.json: Cannot open: No such file or directory
tar: packages: Cannot mkdir: Permission denied
tar: packages/backend/package.json: Cannot open: No such file or directory
tar: Exiting with failure status due to previous errors

我搜索了一下，发现创建和更改目录为"节点"所有。上面的USER在tar操作之前解决了问题。

所以事实上这个Dockerfile工作在我的机器和GitHub的动作。注意前两行——这是Dockerfiles之间的全部区别:

RUN mkdir -p /app
RUN chown node /app
# From here on we use the least-privileged `node` user to run the backend.
USER node
WORKDIR /app

# This switches many Node.js dependencies to production mode.
ENV NODE_ENV production
# Copy repo skeleton first, to avoid unnecessary docker cache invalidation.
# The skeleton contains the package.json of each package in the monorepo,
# and along with yarn.lock and the root package.json, that's enough to run yarn install.
COPY --chown=node:node yarn.lock package.json packages/backend/dist/skeleton.tar.gz ./
RUN tar xzf skeleton.tar.gz && rm skeleton.tar.gz

我不明白的是:为什么第一个Dockerfile构建在Mac/Windows上成功，而在GitHub Actions (Linux)上失败?为什么GitHub操作版本需要额外的所有者更改文件夹级别，而Mac/Windows版本没有?也许这和Docker版本有关?

Answer 1

我很确定这个问题特别发生在Linux上，因为在Windows和macOS上它是在VM中运行的。为什么它会发生在"真正的linux"中?这是因为用户id和组id是在"docker主机"之间共享的。和docker容器(查看更多)

GitHub Actions可能对包含在tar.gz中的uid/gid以及tar.gz本身有指定的权限，而在您本地的macOS/Windows上，docker的专用虚拟机没有任何"real";

我有一个类似的问题，当我使用Bitbucket的CI有一些奇怪的政策围绕ids/gid。这可能是一个类似的情况。