在 2.1.0-dev 版本中,我们尝试设置了 jenkins agent 的idle mins,意味着在分配到 agent 的任务执行完成时候,agent 不会同时被销毁。
这与之前 ks 当中的 agent 策略是不同的,在之前版本中每次运行都是一个全新的 agent。
相比之下两个方案都有不同的优缺点,所以我在这里发起一个投票,希望社区用户能够给我们一些建议,同时也希望能够满足大部分社区用户的需求。
2.1.0-dev 方案优势
复用 agent 可以加速流水线的启动
部分没有缓存到cache的资源也会被复用,将加速流水线的运行
2.1.0-dev 方案劣势
每次调度的agent执行环境不相同,需要用户的Jenkinsfile是幂等的。
一些旧的数据可能会导致用户遇到奇怪的流水线错误。
2.0.2 方案优势
每次执行环境相同,用户不会遭遇一些意外的问题。
2.0.2方案劣势
启动速度相对2.1.0-dev可能会较慢
执行速度-dev可能会较慢
以 kubesphere-java-sample 为例,结合后附 Jenkinsfile ,测试对比数据如下
复用 agent
- 平均总计时间 1 min
- agent 启动 3s
- 拉取源代码 3s
每次新 agent
- 平均总计时间 1min35s
- agent 启动 15s
- 拉取源代码 25s
两者对比平均每次流水线运行节省时间35-40s,此测试结果与k8s集群的资源状态、流水线脚本都相关,此处仅做参考
pipeline {
agent {
node {
label 'maven'
}
}
parameters {
string(name:'TAG_NAME',defaultValue: '',description:'')
}
environment {
DOCKER_CREDENTIAL_ID = 'dockerhub-id'
GITHUB_CREDENTIAL_ID = 'github-id'
KUBECONFIG_CREDENTIAL_ID = 'demo-kubeconfig'
REGISTRY = 'docker.io'
DOCKERHUB_NAMESPACE = 'zhuxiaoyang'
GITHUB_ACCOUNT = 'souleen'
APP_NAME = 'devops-java-sample'
SONAR_CREDENTIAL_ID= 'sonar-token'
}
stages {
stage ('checkout scm') {
steps {
checkout(scm)
}
}
stage ('unit test') {
steps {
container ('maven') {
sh 'mvn clean test'
}
}
}
stage ('build & push') {
steps {
container ('maven') {
sh 'mvn -Dmaven.test.skip=true clean package'
archiveArtifacts 'target/*.jar'
sh 'docker build -f Dockerfile-online -t $REGISTRY/$DOCKERHUB_NAMESPACE/$APP_NAME:SNAPSHOT-$BUILD_NUMBER .'
withCredentials([usernamePassword(passwordVariable : 'DOCKER_PASSWORD' ,usernameVariable : 'DOCKER_USERNAME' ,credentialsId : "$DOCKER_CREDENTIAL_ID" ,)]) {
sh 'echo "$DOCKER_PASSWORD" | docker login $REGISTRY -u "$DOCKER_USERNAME" --password-stdin'
sh 'docker push $REGISTRY/$DOCKERHUB_NAMESPACE/$APP_NAME:SNAPSHOT-$BUILD_NUMBER'
}
}
}
}
stage('push latest'){
steps{
container ('maven') {
sh 'docker tag $REGISTRY/$DOCKERHUB_NAMESPACE/$APP_NAME:SNAPSHOT-$BUILD_NUMBER $REGISTRY/$DOCKERHUB_NAMESPACE/$APP_NAME:latest '
sh 'docker push $REGISTRY/$DOCKERHUB_NAMESPACE/$APP_NAME:latest '
}
}
}
}
}