Jenkins + Docker:使用Image.inside命令时如何控制Docker用户 [英] Jenkins + Docker: How to control docker user when using Image.inside command

问题描述

尊敬的Stackoverflow社区，

Dear Stackoverflow Community,

我正在尝试使用docker映像作为构建过程的容器来设置Jenkins CI管道.我正在定义一个Jenkinsfile，以将构建管道作为代码.我正在做这样的事情:

I am trying to setup a Jenkins CI pipeline using docker images as containers for my build processes. I am defining a Jenkinsfile to have a build pipeline as code. I am doing something like this:

node {
  docker.withRegistry('http://my.registry.com', 'docker-credentials') {     
      def buildimage = docker.image('buildimage:latest');
      buildimage.pull();
      buildimage.inside("")
      {
        stage('Checkout sources') {
          git url: '...', credentialsId: '...'
        }

        stage('Run Build and Publish') {
            sh "..."
        }
      }
  }
}

不幸的是，我绊倒了Docker管道插件的怪异行为.在生成输出中，我可以看到Image.inside(...)命令使用一个

Unfortunately I am stumbling upon a weird behavior of the Docker pipeline plugin. In the build output I can see that the Image.inside(...) command triggers the container with a

docker run -t -d -u 1000:1000 ...

这使我的构建失败，因为Dockerfile中定义的用户没有UID 1000 ...实际上是另一个用户.我什至尝试指定应在Jenkinsfile中使用哪个用户

This makes my build fail, because the user defined in the Dockerfile does not have the UID 1000 ... another user is actually taken. I even tried specifying which user should be used within the Jenkinsfile

node {
  docker.withRegistry('http://my.registry.com', 'docker-credentials') {     
      def buildimage = docker.image('buildimage:latest');
      buildimage.pull();
      buildimage.inside("-u otheruser:othergroup")
      {
        stage('Checkout sources') {
          git url: '...', credentialsId: '...'
        }

        stage('Run Build and Publish') {
            sh "..."
        }
      }
  }
}

但这会导致生成的docker run命令中的-u开关重复

but this leads to a duplicate -u switch in the resulting docker run command

docker run -t -d -u 1000:1000 -u otheruser:othergroup ...

，显然只有第一个-u被应用，因为我的构建仍然失败.我还使用whoami进行调试以验证我的假设.

and obviously only the first -u is applied because my build still fails. I also did debugging using whoami to validate my assumptions.

所以我的问题是:我该如何改变这种行为?有没有可以关闭-u 1000:1000的开关?这甚至是个错误吗?我实际上喜欢使用Docker插件，因为它使用Jenkins中维护的凭据简化了自己的Docker注册表的使用.但是，如果无法使用Docker插件，还有另一种简单的方法可以实现我的目标吗?

So my questions: how can I change this behavior? Is there a switch where I can turn the -u 1000:1000 off? Is this even a bug? I actually like to work with the Docker plugin because it simplifies the usage of an own docker registry with credentials maintained in Jenkins. However, is there another simple way to get to my goal if the Docker Plugin is not usable?

提前感谢您的时间

推荐答案

您可以看到

As you can see here or here is hardcoded the fact of append the uid and gid of the user that is running Jenkins (in your case, the Jenkins user created inside the oficial docker image).

您可以更改在Jenkins映像中运行进程的用户，将--user(或-u)参数传递给docker run命令.也许这可以最大程度地减少您的问题.

You can change the user that runs the processes inside your Jenkins image passing the --user (or -u) argument to the docker run command. Maybe this can minimize your problems.

已编辑

如何更改此行为?有没有可以关闭-u 1000:1000的开关?

how can I change this behavior? Is there a switch where I can turn the -u 1000:1000 off?

您无法在实际版本中更改此行为，因为whoami是硬编码的.

You can't change this behaviour in the actual version because the whoami is hardcoded.

这甚至是错误吗?

Is this even a bug?

在此拉取请求中，他们似乎正在对此进行处理.

In this pull request seems that they are working on it.

但是，如果无法使用Docker插件，还有另一种简单的方法可以实现我的目标吗?

However, is there another simple way to get to my goal if the Docker Plugin is not usable?

Jenkins随附的新管道插件版本还使用docker-workflow-plugin运行容器.我不知道另一个插件可以简单地运行它.要解决此问题，您可以以root用户身份运行Jenkins，但这是一个非常丑陋的解决方案.

The new pipeline plugin version that comes with Jenkins also use the docker-workflow-plugin to run the containers. I don't know another plugin to run that in a simple way. To workaround this, you can run your Jenkins as root but is a very ugly solution.

这篇关于Jenkins + Docker:使用Image.inside命令时如何控制Docker用户的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！