在蔚蓝管道中运行container-job,我使用了一个码头映像( conan ),它期望build命令在conan下运行。
虽然我可以使用--user root在蔚蓝中引导容器,但是使用options没有问题
resources:
containers:
- container: builder
image: conanio/clang8
options: --user root当我执行一项任务
jobs:
- job: do_that
container: builder
steps:
- task: Bash@3
inputs:
targetType: inline
script: whoami
noProfile: false
noRc: false我看到用户是1001,它已经被蔚蓝引导所支持。我不能使用sudo / su,因为不允许用户使用sudo。我问自己,作为一个不同的用户,我将如何运行?由于conan的python、~/.conan中的特殊设置以及诸如此类的东西,用户有一个特定的ENV设置。
在使用docker create的az中,在“容器初始化”(紧接docker exec之后)期间,azp中的这个确切步骤自动运行:
# Grant user 'conan' SUDO privilege and allow it run any command without authentication.
groupadd azure_pipelines_sudo
usermod -a -G azure_pipelines_sudo conan
su -c "echo '%azure_pipelines_sudo ALL=(ALL:ALL) NOPASSWD:ALL' >> /etc/sudoers"
# Allow user 'conan' run any docker command without SUDO.
stat -c %g /var/run/docker.sock
bash -c "cat /etc/group"
groupadd -g 117 azure_pipelines_docker
usermod -a -G azure_pipelines_docker conan语义概念是:
conan / 1000 )azure_pipelines_sudosudo权限conan权限以访问停靠套接字,即运行docker in docker命令看到这个设置,我真的很想知道,为什么有效地运行docker exec语句时使用了如下代码
docker exec -u 1001 ..因此,当实际作业运行时,它没有使用用户conan (1000) --因此配置为拥有sudo / docker访问之类的所有功能--如果这是设计的,那么为什么要执行安装2-4呢?
在某种程度上,这看起来要么是设计缺陷,要么是bug,或者只是我这方面的一个巨大误解。
我见过这个问题,但是即使标题是假设的,这是一个完全不同的问题。
发布于 2020-01-04 08:36:27
现在这是不可能的。我不知道这整个概念是关于什么的,但对我来说,这不仅是一个问题,它是一个展示,因为一个人无法解决这个问题。
尽管这是一个简单的答案--至少是一个答案。
发布于 2019-12-31 15:14:51
更新:
目前还没有这方面的资料。
请注意:
因此,当实际作业运行时,它没有使用用户conan (1000) --因此配置为拥有sudo / docker访问之类的所有功能--如果这是通过设计完成的,那么为什么要执行安装2-4呢?
在我们的官方文档中有一些相关信息可能与此相关: Azure管道将创建一个等待容器,而docker将创建一系列命令,期望容器始终处于启动和运行状态。https://learn.microsoft.com/en-us/azure/devops/pipelines/process/container-phases?view=azure-devops&tabs=yaml#linux-based-containers
代理使用三种不同的身份验证令牌:
即使这个链接问题与你无关。但有一条评论是正确的:
代理本身设置为以用户身份运行。当构建运行时,它以用户“容器管理员”(Root)的身份在容器中运行,后者是一个码头用户。
您想要的似乎是将Docker容器作为非根用户运行。这实际上与Azure DevOps服务端无关,更与Docker有关。
请检查这是否有助于以用户身份连接到停靠容器,而不是根用户。 &这个博客。
https://stackoverflow.com/questions/59544762
复制相似问题