新的 Jenkins 代理容器将无法正常运行

Question

我们一直在设置一个新的 Jenkins 实例，并且随着我们启动了各种项目，我们创建了 Docker 映像，以在 K8s pod 中使用来执行各种管道。突然，我们遇到了一个问题，新代理会抛出以下错误：

cp: cannot create regular file '/home/jenkins/agent/workspace/Agents/Corretto-Maven@tmp/durable-5eb2af2f/script.sh.copy': Permission denied
11:23:55  sh: 1: cannot create /home/jenkins/agent/workspace/Agents/Corretto-Maven@tmp/durable-5eb2af2f/jenkins-log.txt: Permission denied
11:23:55  sh: 1: cannot create /home/jenkins/agent/workspace/Agents/Corretto-Maven@tmp/durable-5eb2af2f/jenkins-result.txt.tmp: Permission denied
11:23:55  touch: cannot touch '/home/jenkins/agent/workspace/Agents/Corretto-Maven@tmp/durable-5eb2af2f/jenkins-log.txt': Permission denied
11:23:55  mv: cannot stat '/home/jenkins/agent/workspace/Agents/Corretto-Maven@tmp/durable-5eb2af2f/jenkins-result.txt.tmp': No such file or directory
...
11:29:02  process apparently never started in /home/jenkins/agent/workspace/Agents/Corretto-Maven@tmp/durable-5eb2af2f

在 K8s 仪表板中，我们可以看到容器已启动，但在失败之前什么也看不到。当我们搜索错误时，出现了最相关的answer，我们检查了Durable Task Plugin，发现我们有最新版本577.v2a_8a_4b_7c0247。随后的搜索没有针对此错误产生任何有价值的结果。

更令人费解的是，因为8 月之前创建的每个 Docker 镜像代理仍然完美运行并且没有显示任何错误迹象。

更令人费解？我们使用 8 月之前使用的基本 Dockerfile 创建了一个新的 Docker 映像，虽然旧映像运行完美，但新映像表现出与任何新映像相同的错误情况。

我们的流程

1. 为镜像创建 Dockerfile。
   • 在本地测试图像，确保其正确构建并按预期运行
2. 使用 Jenkins 构建 Docker 镜像并将结果推送到 Artifactory。
3. 为 pod 镜像创建 YAML 文件
4. 将该 YAML 作为库加载到 Jenkinsfile 中
5. 从指定的镜像加载容器

Dockerfile

# Base Image to customize a Jenkins Remote Agent.
FROM ubuntu:20.04

# variables
ENV USERNAME jenkins
ENV USERDIR /var/$USERNAME

# add a user and group
RUN useradd -u 1001 -U -c $USERNAME -d /var/jenkins -m -s /bin/bash $USERNAME
RUN mkdir /home/$USERNAME
RUN chown $USERNAME:$USERNAME /home/$USERNAME
WORKDIR /home/$USERNAME 

# connection files required (connects to various services, such as Git, Artifactory, etc.)
COPY jen_files.tar /var/jenkins/
RUN tar xvf /var/jenkins/jen_files.tar --directory /var/jenkins/
RUN rm -f /var/jenkins/jen_files.tar

# install tools 
RUN apt-get update && apt-get install -y \
    jq \
    git \
    tar \
    zip \
    curl \
    wget \
    sudo

USER $USERNAME

CMD ["/bin/bash", "-c", "bash"]

Pod YAML

apiVersion: v1
kind: Pod
metadata:
  name: ubuntu-pod-yaml
spec:
  serviceAccountName: jenkins
  imagePullSecrets:
    - name: regcred
  containers:
    - name: ubuntu2004
      image: 'ourartifacts.jfrog.io/docker-local/jenkins-remote-agents:ubuntu2004'
      imagePullPolicy: Always
      command:
        - sleep
      args:
        - 99d
      tty: true

詹金斯文件

// load shared library via @Library or other methods
@Library('SCMLibraries@ubuntu-pod-tests')_ // Load External Libraries
def podDefs = libraryResource('./ubuntu-pod.yaml') 

pipeline {
    agent any
    stages {
        stage('Pipeline Start') {
            stages {
                stage('SCM Library') {
                    agent {
                        kubernetes {
                            defaultContainer 'jnlp'
                            yaml podDefs
                        }
                    }
                    steps {
                        sh 'ls -la'
                        sh 'whoami'
                        sh 'echo $UID'
                        container('ubuntu2004') { // this is when we start to see the errors shown
                            sh 'whoami'
                            sh 'cat /etc/os*'
                        }
                    }
                }
            }
        }
    }
}

此方法适用于我们截至 8 月份定义的每个代理图像。直到几周前我们再次开始该流程，为我们想要在新 Jenkins 实例上托管的项目构建新映像时，问题才出现。这里显示的 Dockerfile 与我们用来定义 8 月之前运行的镜像的 Dockerfile 相同。

我们检查过什么

• 我们构建这些镜像的“遗留”Jenkins 在过去几个月里没有发生任何变化，除了为了保持其运行而所做的事情之外。 Docker 20.10.6 是该机器上运行的版本（是的，它很旧），并且由于某些原因从未更新过。
• Dockerfiles 都是相当普通的，如此处所示。大多数都是基于 Ubuntu（带有较新版本的 Ubuntu）或基于 AmazonCorretto。
• 在新的 Jenkins 实例中调用容器的方法基于“一切皆代码”领域当前的最佳实践，我们使用 Helm 来部署/更新/维护 Jenkins。
• 我们已经检查了持久任务插件，如上面链接的其他答案所示。
• 我们运行

  org.jenkinsci.plugins.durabletask.BourneShellScript.LAUNCH_DIAGNOSTICS=true

  ，以便我们可以在控制台日志中看到其他输出。这就是我们可以看到各种权限问题的原因。
• 我们没有其他帖子建议的任何空环境变量。

导致这些错误的原因是什么？ 我们缺少什么？ 还有其他细节可以更清楚吗？

Answer 1

啊啊！ （也许是一种好的方式。）

我发现了答案/解决方法埋藏在这个问题中。我将

runAsUser

添加到 pod 定义中：

apiVersion: v1
kind: Pod
metadata:
  name: ubuntu-pod-yaml
spec:
  serviceAccountName: jenkins
  imagePullSecrets:
    - name: regcred
  containers:
    - name: ubuntu2004
      image: 'ourartifacts.jfrog.io/docker-local/jenkins-remote-agents:ubuntu2004'
      imagePullPolicy: Always
      command:
        - sleep
      args:
        - 99d
      tty: true
      securityContext:
        runAsUser: 0

错误消失了，管道现在正在运行。

但是，虽然这是一个很好的解决方法，但它并不能完全解决原来的问题。当容器启动时，所有正常工作的容器都会以用户 0 的身份运行，而无需干预 pod 容器定义。