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

rekjcdws  于 2023-01-08  发布在  Linux
关注(0)|答案(1)|浏览(127)

我有一个应用程序与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

这是官方Backstage CLI(https://github.com/backstage/backstage/issues/15421)生成的停靠文件的一部分。
当我在Mac和同事的Windows机器上运行docker build时,构建工作正常。
然而,当我们尝试在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

我在Google上搜索了一下,发现在tar操作之前创建并更改目录以使其归上面的“node”USER所有可以解决这个问题。
事实上,这个Dockerfile在我的机器和GitHub Actions上都能用,注意前两行--这就是Dockerfile的全部区别:

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 Actions版本需要在文件夹级别上进行额外的所有者更改,而Mac/Windows版本不需要?也许这与Docker版本有关?

4nkexdtk

4nkexdtk1#

我非常肯定这个问题只会发生在Linux上,因为在Windows和macOS上,它是在虚拟机中运行的。之所以会发生在“真实的的Linux”机器上,而不是在虚拟机中,是因为用户ID和组ID在“Docker主机”和Docker容器之间共享(请参阅更多here
GitHub Actions可能为tar.gz中包含的uid/gids以及tar.gz本身指定了权限,而在您的本地macOS/Windows上,Docker的专用虚拟机没有任何使用Linux的“真实的”用户管理。
当我使用Bitbucket的CI时,我遇到了类似的问题,它在uids/gids.周围有一些奇怪的策略。

相关问题