Jenkins Pipeline 使用 Docker 作为 Agent 时注意事项

文章讲述了在JenkinsPipeline使用Docker作为Agent时遇到的无效参数问题,原因是string类型的参数在容器环境中被误作为Docker参数。解决方案是移除string参数,仅保留gitParameter,从而修复了报错。

jenkins-logo


先来看一段报错信息:

image-20230406173903914

上图报错:invalid argument(无效参数)。再看看我的 PipelineAgent

pipeline{
    agent {  // 工作节点
        docker {
            image '172.17.16.102/maven/maven:102'
            args '-v /data/jenkins/workspace/Biliard/maven:/root/.m2 -v /data/mavenRepository:/usr/repository'
        }
    }
    ...
    ...
    parameters {  // 参数化构建
        string(name: '',
        defaultValue: '------------------------------------------------------------------------------- 项目版本发布 ------------------------------------------------------------------------------------',
        description: '')
        gitParameter (name: 'BRANCH_TAG',
                        type: 'PT_BRANCH_TAG',
                        branchFilter: 'origin/(.*)',
                        defaultValue: 'master',
                        selectedValue: 'DEFAULT',
                        sortMode: 'DESCENDING_SMART',
                        description: '⚠ 选择发布版本(分支)')
        ...
        ...
    }
    ...
    ...
}

案例中加了 string 参数的原因是为了界面好看,从语法上来讲是没有问题的,但是在 agent 代理节点为 Docker 时就存在问题了,首先我们要清楚 Agent 有什么作用,Agent 指的是 Pipeline 的运行环境,可以是 Host 环境,也可以是容器环境,而在容器环境中时,string 参数会作为 Docker 参数传入,因此报 Docker 无效参数(在 agent 为 any 时,以上案例是没有问题的)。

因此,解决方案就是去掉 string 类型的参数变量:

pipeline{
    agent {  // 工作节点
        docker {
            image '172.17.16.102/maven/maven:102'
            args '-v /data/jenkins/workspace/Biliard/maven:/root/.m2 -v /data/mavenRepository:/usr/repository'
        }
    }
    ...
    ...
    parameters {  // 参数化构建
        gitParameter (name: 'BRANCH_TAG',
                        type: 'PT_BRANCH_TAG',
                        branchFilter: 'origin/(.*)',
                        defaultValue: 'master',
                        selectedValue: 'DEFAULT',
                        sortMode: 'DESCENDING_SMART',
                        description: '⚠ 选择发布版本(分支)')
        ...
        ...
    }
    ...
    ...
}

此时,问题得到解决!

### 使用 Jenkins Pipeline 实现 Containerd、Kubernetes 和 Docker 的集成 #### 背景介绍 Jenkins 是一种流行的 CI/CD 工具,支持通过其 Pipeline 功能实现复杂的自动化流程。Containerd 是一个轻量级的容器运行,通常用于替代传统的 Docker 容器运行。Kubernetes 提供了一个强大的编排平台来管理和调度容器化的应用程序。而 Docker 则是一个广泛使用的容器技术栈的一部分。 为了在 Jenkins Pipeline 中利用这些技术,可以通过以下方法完成它们之间的集成: --- #### 1. **准备环境** - 确保 Kubernetes 集群已正确配置并能够访问。 - 在集群中启用 `containerd` 并将其作为默认容器运行[^3]。 - 安装必要的插件,例如 Kubernetes Plugin 和 Docker Plugin[^4]。 --- #### 2. **创建 Kubernetes Pod Template** 使用 Kubernetes Plugin,在 Jenkins 中定义一个 Pod 模板,该模板指定所需的容器镜像和其他资源配置。以下是 YAML 文件的一个例子: ```yaml apiVersion: v1 kind: Pod metadata: name: jenkins-agent-containerd spec: containers: - name: maven-builder image: maven:3-jdk-8 command: - cat tty: true - name: kubectl image: bitnami/kubectl:latest command: - cat tty: true ``` 此模板包含两个容器:一个是 Maven 构建工具,另一个是带有 `kubectl` 的容器,以便于与 Kubernetes API 进行交互[^1]。 --- #### 3. **编写 Declarative Pipeline** 下面展示了一种声明式的 Jenkins Pipeline 示例,它集成了 Containerd、Kubernetes 和 Docker: ```groovy pipeline { agent { kubernetes { label 'mypod' yaml """ apiVersion: v1 kind: Pod metadata: name: jenkins-agent-containerd spec: containers: - name: maven-builder image: maven:3-jdk-8 command: - cat tty: true - name: kubectl image: bitnami/kubectl:latest command: - cat tty: true """ } } environment { KUBECONFIG = '/home/jenkins/.kube/config' } stages { stage('Checkout Code') { steps { git url: 'https://github.com/example/repo.git', branch: 'main' } } stage('Build Application') { steps { container('maven-builder') { sh 'mvn clean package' } } } stage('Deploy to Kubernetes') { steps { container('kubectl') { script { echo "Using kubeconfig file at ${env.KUBECONFIG}" sh 'kubectl version' sh 'kubectl apply -f deployment.yaml' } } } } } post { always { deleteDir() } } } ``` 在此脚本中: - 使用了 `kubernetes` 代理类型指定了自定义的 Pod 模板。 - 将不同的阶段分配给特定的容器(如 Maven 或 kubectl)。 - 设置了 `KUBECONFIG` 环境变量以允许访问 Kubernetes 集群[^2]。 --- #### 4. **配置 Containerd 支持** 如果目标是在 Kubernetes 上使用 `containerd` 替代 Docker,则需调整节点上的 CRI(容器运行接口)。这涉及修改 `/etc/containerd/config.toml` 文件并将 `plugins.cri.containerd.runtimes.untrusted` 字段更新为适合的目标运行[^3]。 随后重启 `containerd` 服务以使更改生效,并验证新设置是否正常工作。 --- #### 5. **测试和调试** 最后一步是对整个流水线进行全面测试,确保各组件之间无缝协作。可以尝试模拟失败场景以评估恢复机制的有效性[^4]。 --- ### 总结 上述过程展示了如何借助 Jenkins Pipeline 来连接 Containerd、Kubernetes 和 Docker 技术栈,从而构建高效的 CI/CD 流程。这种方法不仅提高了灵活性还增强了系统的稳定性。 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

云计算-Security

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值