我正在使用这个插件在Kubernetes集群中运行动态代理,jenkinsci / kubernetes-plugin到目前为止,除了我尝试使用可用于yaml格式定义从属pod的功能时,一切都很顺利。{{ 3}}
不幸的是,当我尝试使用此功能时,事情变得糟糕。我改变了我的Jenkins管道脚本:
def label = "kubernetes"
podTemplate(label: label,
containers: [containerTemplate(name: 'jnlp', image: 'artifactory.baorg.com:5001/sum/coreimage:1', ttyEnabled: true, label: label)],
imagePullSecrets: [ 'ad-artifactory-cred' ],
) {
node(label) {
stage('Core') {
container(name: 'jnlp') {
stage('building program') {
sh "echo hello world"
}
}
}
}
}
对此:
def label = "kubernetes"
podTemplate(label: label, yaml: """
apiVersion: v1
kind: Pod
metadata:
labels:
label: label
spec:
containers:
- name: jenkins-slave
image: artifactory.baorg.com:5001/sum/coreimage:1
tty: true
"""
) {
node(label) {
stage('Core') {
container(name: 'jnlp') {
stage('building program') {
sh "echo hello world"
}
}
}
}
}
当以前一种方式编写管道脚本时,一切都按预期工作。创建从属容器并运行作业。不幸的是,当我采用这些设置并尝试以YAML格式对它们进行编码时,似乎甚至没有读取配置或其他内容。当它正在工作时,如果图像在集群中不存在并且作业运行良好,则会拉出图像:
但是当我更改配置以便在YAML中完成时,作业尝试拉出名为“jenkins / jnlp-slave:alpine”的图像而不是我指定的图像并超时,因为我的集群无法访问到互联网(index.docker ...)。它拉这个图像的原因是由于插件中的一个错误,当奴隶的名字没有设置为“jnlp”时(这与我的问题无关)。
要做的重要观察是YAML信息由于某种原因未被接受或认可,我不确定原因。是因为一些糟糕的格式?或者这是这个插件的一些已知问题(我觉得很难相信)。我已经检查过代码中是否有任何额外的标签,但我没有。
答案 0 :(得分:1)
基于快速了解您的管道DSL和YAML规范。以下代码段是您的DSL直接翻译的样子(未经测试)。
apiVersion: v1
kind: Pod
metadata:
labels:
label: label
spec:
containers:
- name: jnlp
image: artifactory.baorg.com:5001/sum/coreimage:1
tty: true
imagePullSecrets:
- name: ad-artifactory-cred
在原始配置中,您指定了默认的" jnlp"不使用容器,而是使用您指定的容器。在您的YAML版本中,您使用了名称" jenkins-slave"从而向插件指示您希望默认的jnlp容器(jenkins/jnlp-slave:alpine
)与您的" jenkins-slave"一起在pod中启动。容器
至于拉动失败的原因,这可能是事件中指示的网络配置问题(防火墙或代理)。如果您有权访问该节点,请尝试手动执行docker pull jenkins/jnlp-slave:aline
以进行调试。