com.sun.deploy.net.FailedDownloadException: Unable to load resource: http://127.0.0.1:8080/jnlpJars/remoting.jar     at com.sun.deploy.net.DownloadEngine.actionDownload(Unknown Source)     at com.sun.deploy.net.DownloadEngine.downloadResource(Unknown Source)     at com.sun.deploy.cache.ResourceProviderImpl.getResource(Unknown Source)     at com.sun.deploy.cache.ResourceProviderImpl.getResource(Unknown Source)     at com.sun.javaws.LaunchDownload$DownloadTask.call(Unknown Source)     at java.util.concurrent.FutureTask.run(Unknown Source)     at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)     at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)     at java.lang.Thread.run(Unknown Source)

在Jenkins上设置邮件提醒可以使我们在定时执行完任务之后，随时查看运行情况。本文以QQ邮箱为例，其他邮箱的话大同小异。话不多说，直接上流程，按照流程一步步来，绝对没问题。1. 在jenkins首页点击manage jenkins, 忽略页面顶部的提示信息，然后选择manage plugins2. 点击"Available', 搜索并安装邮件相关插件，选择install without restart 即可（如果是已安装的话可以在installed里搜一下，有就行）HTML publisherEmail ExtensionEmail Extension Template3. 等待插件安装完成，然后点击manage jenkins，再选择configure system4. 在系统管理员邮件地址中，输入发件箱的地址 5. 发件箱需要授权，先讲一下授权操作：首先登录发件箱的QQ邮箱，如何点击设置，选择账户。然后在下面找到POP3/IMAP/SMTP/Exchange/CardDAV/CalDAV服务，开启IMAP/SMTP服务，第一次开启的时候会提示你用密码手机发送一份短信，在验证通过之后就会在页面上获取授权码，妥善保存好授权码（当然如果弄丢了，点击下面的生成授权码可以重新生成一个新的）点击“什么是IMAP，它又是如何设置”，在跳出的页面底部可以找到SMTP服务器地址6. 找到Extended E-mail Notification，在SMTP server中输入smtp.qq.com，在SMTP Port中输入465  7. 点击Advanced，点击Add，选择Jenkins 8. 在弹出的窗口中，输入：Username：发件箱的地址Password：发件箱的授权码！！切记，这个填的不是邮箱的密码其他可以不填最后点击Add然后Credentials看一下有没有选择刚刚添加的邮箱，如果没有就选择一下。 9. 勾选“Use SSL”  10. Default user e-mail suffix 输入@qq.com 11. 点击上述图中Advanced，查看Charset默认是UTF-812. Default Content Type选择HML(text/html): 发送有格式的邮件13. Default Recipients 填一个默认的收件人地址（可以和发件箱同一个，不过建议用另一个号） 14. 勾选Enable Debug Mode：这时如果发送不出邮件，日志中会包含详细的错误信息 15. 点击按钮Default Triggers(按需求勾选)勾选Always：不论测试是否执行失败，总是发送邮件勾选Failure - Any：任何一条测试用例失败，都发送邮件16. 其他没有提到的可不填，维持默认就好，Default Content是默认的邮件模板，可以在项目中填写，所以这里就不填了。17. 在E-mail Notification下，SMTP server输入smtp.qq.com，Default user e-mail suffix输入@qq.com。 18. 点击Advanced，然后勾选Use SMTP Authentication用户名：输入发件箱密码：输入发件箱的授权码！！！19. 勾选Use SSL20. SMTP Port 输入46521. 测试：勾选Test configuration by sending test e-mail，输入收件箱，然后点击Test configuration，如果看到“Email was successfully sent” 说明前面的配置成功了。点击Save. 22. 打开创建的项目，点击Configure 23. 在Post-build Actions中选择Publish HTML report，点击AddHTML directory to archive：输入测试报告所在的文件夹路径Index page[s]：输入测试报告的名字 24. 在Post-build Actions中选择Editable Email NotificationProject Recipient List：填写收件人Content Type：选择HTML(text/html)Default Subject：输入邮件的默认标题Default Content：复制进邮件的模板(是一大段html代码)25. 到此，所有的配置就完成了，点击save。去运行项目然后登录收件箱收邮件。26. 如果收到的邮箱格式不对劲，可以在Manage Jenkins-->Script Console 中运行命令：System.setProperty("hudson.model.DirectoryBrowserSupport.CSP","") 然后重新运行一下项目应该就好了。

本篇收集在Jenkins中出现的问题，及处理办法。There were errors checking the update sites: UnknownHostException: updates.jenkins.io#基于jenkinsci/blueocean:latest镜像的jenkins2.222.3当我在将服务器的jenkins容器迁移到本地虚拟机中后，在插件管理中遇到了这个问题：原因可能是你本地的网络环境无法访问外网.......解决办法：在插件中心的高级选项中，下拉升级站点，将原地址https://updates.jenkins.io/update-center.json改为https://mirrors.tuna.tsinghua.edu.cn/jenkins/updates/update-center.json，然后点击保存:重启你的jenkins，不能行的话重启虚拟机吧。直到如上图右下角没有报错为止。此时，你也能下载插件了：总之，你要考虑的是你的网络问题！不过，要是网络环境下载国外的插件没啥问题的，搞jenkins也没这么多事儿了HTTP ERROR 403 No valid crum was included in the request#基于jenkinsci/blueocean:latest镜像的jenkins2.222.3有的时候，你在使用jenkins提交数据的时候，可能会遇到：解决办法：打开管理▶全局安全配置，下拉选择CSRF Protection：完事点击保存。see also:Jenkins -> 403 No valid crumb was included in the request出现一个错误：无法连接到Jenkins#环境：centos7.4 + Jenkins 2.222.3在初始化的时候，遇到上述错误，可能的原因是，配置文件权限出了问题......解决办法：关闭Jenkins服务：[root@r ~]# sudo systemctl stop jenkins 备份一下配置文件：[root@r ~]# cp /var/lib/jenkins/config.xml /var/lib/jenkins/config.xml.bak20200519 [root@r ~]# ls /var/lib/jenkins/config.xml* /var/lib/jenkins/config.xml /var/lib/jenkins/config.xml.bak20200519 修改配置文件，参考下图修改。重启Jenkins服务，然后在浏览器访问即可。[root@r ~]# sudo systemctl start jenkins 参考：enkins出现一个错误 无法连接到Jenkins如何解决安装过程中出现一个错误： No such plugin: cloudbees-folder#环境：win10 + tomcat8.5.54 + jenkins 2.222.3在初始化安装推荐插件的时候，报了如上错误，我怀疑是我之前中断过安装插件过程......whatever，来看解决办法：打开http://ftp.icm.edu.pl/packages/jenkins/plugins/cloudbees-folder/，下拉选择latest版本，找到其中cloudbees-folder.hpi，并将其下载到本地。将cloudbees-folder.hpi文件拷贝到你tomcat的安装目录中的\webapps\jenkins\WEB-INF目录内。重启Tomcat服务，然后重新访问Jenkins即可。参考：安装jenkins时出现 No such plugin: cloudbees-folder的解决办法Error 403 No valid crumb was included in the request#解决办法是：管理Jenkins(Manage Jenkins)▶配置全局安全(Configure Global Security)选项，下拉选择取消防止跨站点请求伪造(Prevent Cross Site Request Forgery exploits)：参考：https://blog.csdn.net/wanglin_lin/article/details/73849146 | Jenkins Error: 403 No valid crumb was included in the requestPlease wait while Jenkins is getting ready to work#环境：docker中的Jenkins一般在启动后出现如上的提示时，一直在准备，然后就一直等，可能的原因是，国内访问某些网站总会遇到各种问题。解决办法：打开Jenkins的工作目录的hudson.model.UpdateCenter.xml文件, 修改文件中的url部分，将默认的国外的地址改为国内的清华大学的源（如果遇到vim没有安装，就先apt-get update一下，然后再apt-get install vim即可）：<?xml version='1.1' encoding='UTF-8'?> <sites> <site> <id>default</id> <url>https://updates.jenkins.io/update-center.json</url> </site> </sites> 修改为：<?xml version='1.1' encoding='UTF-8'?> <sites> <site> <id>default</id> <url>https://mirrors.tuna.tsinghua.edu.cn/jenkins/updates/update-center.json</url> </site> </sites> 然后重启Jenkins镜像即可。参考：Jinkins 启动时 Please wait while Jenkins is getting ready to work ... | 部署jenkins服务器出现Please wait while Jenkins is getting ready to work ...一直进不去该怎么办？Jenkins提示：反向代理设置有误#解决办法就是配置上正确的URL。管理Jenkins(Manage Jenkins)▶系统设置(Configure System)▶Jenkins Location:参考：Jenkins提示反向代理设置有误apt-get无法安装vim等工具#原因是需要更新apt-get，即同步 /etc/apt/sources.list 和 /etc/apt/sources.list.d 中列出的源的索引，这样才能获取到最新的软件包。然后正常的使用apt-get install vim -y即可。参考：docker容器中安装vimFailed to connect to repository : Command "git ls-remote -h -- https://github.com/xxx/xxxx.git HEAD" returned status code 128:#jenkinsci/blueocean:latest在部署项目时，遇到无法连接Git仓库的情况，网上有说是因为git版本太低， 还有说需要配置公钥和私钥来解决问题的。这里就以配置公钥私钥来解决问题。参考：配置GitHub SSH key参考：Jenkins 部署项目出现 Failed to connect to repository : Command "git ls-remote -h http://gitlab. 128Jenkins执行shell命令提示"命令未找到"#centos7.3 + jenkins2.176.1在一次构建中，在执行shell命令时，我执行了python3 -V发现找不到Python环境：经查询，问题原因是Jenkins默认情况下执行shell脚本是使用非登录方式，然而非登录方式不会加载 /etc/profile 文件。解决办法在 Execute shell 中 添加如 #!/bin/sh -l 命令修改为登录方式即可解决问题：#!/bin/sh -l 参考：Jenkins 执行脚本说未找到命令问题ERROR: Step ‘Allure Report’ aborted due to exception:#centos7.3 + jenkins2.176.1在全局工具配置中，为allure commandline配置的自动下载，结果在构建的过程中，发现自动下载貌似失败了：解决办法，手动配置allure commandline。

【功能模块】writer.commit()【操作步骤&问题现象】from mindspore.mindrecord import FileWriterfrom mindspore import dataset as dsds.config.set_num_parallel_workers(8)# 定义一个schema,为双重字典的嵌套，file_name对{"type": "string"}，label对{"type": "int32"}# data对{"type": "bytes"}，我们需要将写入的数据data按照schema的格式给出cv_schema_json = {"file_name": {"type": "string"}, "label": {"type": "int32"}, "data": {"type": "bytes"}}# data为要写入MindRecord的数据，可以将其与cv_schema_json比较验证它的格式，图片以二进制流给出data = [{"file_name": "1.jpg", "label": 0, "data": b"\x10c\xb3w\xa8\xee$o&<q\x8c\x8e(\xa2\x90\x90\x96\xbc\xb1\x1e\xd4QER\x13?\xff\xd9"}, {"file_name": "2.jpg", "label": 56, "data": b"\xe6\xda\xd1\xae\x07\xb8>\xd4\x00\xf8\x129\x15\xd9\xf2q\xc0\xa2\x91YFUO\x1dsE1\x1ep"}, {"file_name": "3.jpg", "label": 99, "data": b"\xaf\xafU<\xb8|6\xbd}\xc1\x99[\xeaj+\x8f\x84\xd3\xcc\xa0,i\xbb\xb9-\xcdz\xecp{T\xb1\xdb"}]# 添加索引indexes = ["file_name", "label"]# 创建4个MindRecod文件，又含有索引，所以最后又8个MindRecord文件，分别为test.mindrecord0、# test.mindrecord0.db、test.mindrecord1、test.mindrecord1.db、test.mindrecord2、# test.mindrecord2.db、test.mindrecord3、test.mindrecord3.db# 它被称为MindSpore数据集，test.mindrecord0为数据文件，test.mindrecord0.db为索引文件writer = FileWriter(file_name="test.mindrecord", shard_num=2)writer.add_schema(cv_schema_json, "test_schema")writer.add_index(indexes)writer.write_raw_data(data)# 将最终内存写入磁盘writer.commit()最后一步报错    writer.commit()  File "E:\ProgramData\Anaconda3\envs\mindspore\lib\site-packages\mindspore\mindrecord\filewriter.py", line 391, in commit    self._generator.build()  File "E:\ProgramData\Anaconda3\envs\mindspore\lib\site-packages\mindspore\mindrecord\shardindexgenerator.py", line 54, in build    ret = self._generator.build()RuntimeError: Unexpected error. Failed to open file, file path: E:\大三上\深度学习\models-master\official\cv\ssd\MindRecord_COCO\test.mindrecord0Line of code : 66File         : D:\jenkins\agent-working-dir\workspace\Compile_CPU_Windows\mindspore\mindspore\ccsrc\minddata\mindrecord\meta\shard_header.ccProcess finished with exit code 1【截图信息】

 Jenkins Pipeline是一套插件，支持在Jenkins中实现集成和持续交付管道。Pipeline通过特定语法对简单到复杂的传输管道进行建模；• 声明式：遵循与Groovy相同语法。pipeline { }• 脚本式：支持Groovy大部分功能，也是非常表达和灵活的工具。node { }• Jenkins Pipeline的定义被写入一个文本文件，称为Jenkinsfile。下面示例一个pipline的web页面创建：1.进入Jenkins平台，点击新建Item2.点击配置，进入流水线配置页面3.写入脚本4.立即构建

docker run -u root --rm -d -p 8080:8080 -p 50000:50000 -v jenkins-data:/var/jenkins_home -v /var/run/docker.sock:/var/run/docker.sock \ jenkinsci/blueocean 也可以先把镜像下载到本地，然后再执行docker run docker pull jenkinsci/blueocean容器安装的好处是简单，不容易出错。root@ecs-385f:~# docker run  -u root  --rm  -d  -p 8080:8080  -p 50000:50000  -v jenkins-data:/var/jenkins_home  -v /var/run/docker.sock:/var/run/docker.sock  jenkinsci/blueocean Unable to find image 'jenkinsci/blueocean:latest' locallylatest: Pulling from jenkinsci/blueocean540db60ca938: Pull complete 2a961b9363b0: Pull complete d6a479880c83: Pull complete 8eaeff69d97a: Pull complete 351ca2eaf86b: Pull complete f6c722701e33: Pull complete 2e4f785df836: Pull complete d3df0c4abbde: Pull complete bc5608b67244: Pull complete 3f8e7265de76: Pull complete b43472033709: Pull complete 8c8d6280a0e7: Pull complete a1ce0802fc1d: Pull complete 8fe1c5ba0c97: Pull complete d29f411ffa58: Pull complete 0bf0f39d44a7: Pull complete Digest: sha256:38bcb5122b85482dec0c3dfd6ba29bdc3e8c9a2eb43258f670096e0b4cbfcb2eStatus: Downloaded newer image for jenkinsci/blueocean:latest164454a8906fe71a35467704f161813f198860f8f878870aa3a60ae68e7b6a1broot@ecs-385f:~# docker psCONTAINER ID        IMAGE                                COMMAND                  CREATED             STATUS                  PORTS                                              NAMES164454a8906f        jenkinsci/blueocean                  "/sbin/tini -- /usr/…"   13 seconds ago      Up 11 seconds           0.0.0.0:8080->8080/tcp, 0.0.0.0:50000->50000/tcp   distracted_bartikroot@ecs-385f:~# curl 114.115.168.136:8080<html><head><meta http-equiv='refresh' content='1;url=/login?from=%2F'/><script>window.location.replace('/login?from=%2F');</script></head><body style='background-color:white; color:white;'>Authentication required<!----></body></html>                                                                                                                                                                                                                                                                                                            root@ecs-385f:~# 浏览器访问EIP：8080root@ecs-385f:~# cat /var/jenkins_home/secrets/initialAdminPasswordcat: /var/jenkins_home/secrets/initialAdminPassword: No such file or directory没有这个文件是因为Jenkins并没有部署在ecs上，而是部署在容器里。root@ecs-385f:~# docker exec -it 164454a8906f sh/ # cat /var/jenkins_home/secrets/initialAdminPassword8f92c205facbxxxx11849b1a13e655/ # 复制上述字段到Jenkins登录页面。提示安装插件的界面：

背景虽然云原生时代有了 JenkinsX、Drone、Tekton 这样的后起之秀，但 Jenkins 这样一个老牌的 CI/CD 工具仍是各大公司主流的使用方案。比如我司的私有云产品打包发布就是用这老家伙完成的。然而传统的 Jenkins Slave 一主多从方式会存在一些痛点，比如：每个 Slave 的配置环境不一样，来完成不同语言的编译打包等操作，但是这些差异化的配置导致管理起来非常不方便，维护起来也是比较费劲资源分配不均衡，有的 Slave 要运行的 job 出现排队等待，而有的 Slave 处于空闲状态资源有浪费，每台 Slave 可能是物理机或者虚拟机，当 Slave 处于空闲状态时，也不会完全释放掉资源。正因为上面的 Jenkins slave 存在这些种种痛点，我们渴望一种更高效更可靠的方式来完成这个 CI/CD 流程，而 Docker 虚拟化容器技术能很好的解决这个痛点，又特别是在 Kubernetes 集群环境下面能够更好来解决上面的问题：Jenkins Master 时以 docker-compose 的方式运行在一个节点上。Jenkins Slave 以 Pod 形式运行在 Kubernetes 集群的 Node 上，并且它不是一直处于运行状态，它会按照需求动态的创建并自动删除。这种方式的工作流程大致为：当 Jenkins Master 接受到 Build 请求时，会根据配置的 Label 动态创建一个运行在 Pod 中的 Jenkins Slave 并注册到 Master 上，当运行完 Job 后，这个 Slave 会被注销并且这个 Pod 也会自动删除，恢复到最初状态。那么我们使用这种方式带来了以下好处：动态伸缩，合理使用资源，每次运行 Job 时，会自动创建一个 Jenkins Slave，Job 完成后，Slave 自动注销并删除容器，资源自动释放，而且 Kubernetes 会根据每个资源的使用情况，动态分配 Slave 到空闲的节点上创建，降低出现因某节点资源利用率高，还排队等待在该节点的情况。扩展性好，当 Kubernetes 集群的资源严重不足而导致 Job 排队等待时，可以很容易的添加一个 Kubernetes Node 到集群中，从而实现扩展。上面的大半段复制粘贴自 基于 Jenkins 的 CI/CD (一)kubernetes 集群关于 kubernetes 集群部署，使用 kubeadm 部署是最为方便的了，可参考我很早之前写过的文章《使用 kubeadm 快速部署体验 K8s》，在这里只是简单介绍一下：使用 kubeadm 来创建一个单 master 节点的 kubernets 集群root@jenkins:~ # kubeadm init --pod-network-cidr=10.244.0.0/16 --apiserver-advertise-address=192.168.20.11集群成功部署完成之后会有如下提示：Your Kubernetes control-plane has initialized successfully!To start using your cluster, you need to run the following as a regular user:  mkdir -p $HOME/.kube  sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config  sudo chown $(id -u):$(id -g) $HOME/.kube/config查看节点状态和 pod 都已经正常root@jenkins:~ # kubectl get pod -ANAMESPACE     NAME                              READY   STATUS    RESTARTS   AGEkube-system   coredns-f9fd979d6-9t6qp           1/1     Running   0          89skube-system   coredns-f9fd979d6-hntm8           1/1     Running   0          89skube-system   etcd-jenkins                      1/1     Running   0          106skube-system   kube-apiserver-jenkins            1/1     Running   0          106skube-system   kube-controller-manager-jenkins   1/1     Running   0          106skube-system   kube-proxy-8pzkz                  1/1     Running   0          89skube-system   kube-scheduler-jenkins            1/1     Running   0          106sroot@jenkins:~ # kubectl get nodeNAME      STATUS   ROLES    AGE    VERSIONjenkins   Ready    master   119s   v1.19.8去除 master 节点上的污点，允许其他的 pod 调度在 master 节点上，不然后面 Jenkins 所创建的 pod 将无法调度在该节点上。kubectl taint nodes $(hostname) node-role.kubernetes.io/master:NoSchedule-Jenkins master至于 Jenkins master 的部署方式，个人建议使用 docker-compose 来部署。运行在 kubernetes 集群集群中也没什么毛病。但从个人运维踩的坑来讲，还是将 Jenkins master 独立于 kubernetes 集群部署比较方便 。docker-compose.yamlversion: '3.6'services:  jenkins:    image: jenkins/jenkins:2.263.4-lts-slim    container_name: jenkins    restart: always    volumes:      - ./jenkins_home:/var/jenkins_home    network_mode: host    user: root    environment:      - JAVA_OPTS=-Duser.timezone=Asia/Shanghai使用 docker-compose up 来启动，成功启动后会有如下提示，日志输出的密钥就是 admin 用户的默认密码，使用它来第一次登录 Jenkins。jenkins    | 2021-03-06 02:22:31.741+0000 [id=41] INFO jenkins.install.SetupWizard#init:jenkins    |jenkins    | *************************************************************jenkins    | *************************************************************jenkins    | *************************************************************jenkins    |jenkins    | Jenkins initial setup is required. An admin user has been created and a password generated.jenkins    | Please use the following password to proceed to installation:jenkins    |jenkins    | 4c2361968cd94323acdde17f7603d8e1jenkins    |jenkins    | This may also be found at: /var/jenkins_home/secrets/initialAdminPasswordjenkins    |jenkins    | *************************************************************jenkins    | *************************************************************jenkins    | *************************************************************登录上去之后，建议选择 选择插件来安装，尽可能少地安装插件，按需安装即可。在 Jenkins 的插件管理那里安装上 kubernetes 插件接下来开始配置 Jenkins 大叔如何与 kubernetes 船长手牵手 ‍‍ :-)。配置 kubernets 的地方是在 系统管理 > 节点管理 > Configure Clouds。点击 Add a new cloud，来添加一个 kubernetes 集群。配置连接参数参数值说明名称kubernetes也是后面 pod 模板中的 cloud 的值凭据kubeconfig 凭据 id使用 kubeconfig 文件来连接集群Kubernetes 地址默认即可Use Jenkins Proxy默认即可Kubernetes 服务证书 key默认即可禁用 HTTPS 证书检查默认即可Kubernetes 命名空间默认即可WebSocket默认即可Direct Connection默认即可Jenkins 地址http://jenkins.k8s.li:8080Jenkins pod 连接 Jenkins master 的 URLJenkins 通道50000Jenkins JNLP 的端口，默认为 50000Connection Timeout默认即可Jenkins 连接 kubernetes 超时时间Read Timeout默认即可容器数量默认即可Jenkins pod 创建的最大数量Pod Labels默认即可Jenkins pod 的 lables连接 Kubernetes API 的最大连接数默认即可Seconds to wait for pod to be running默认即可等待 pod 正常 running 的时间在 Jenkins 的凭据那里添加上 kubeconfig 文件，凭据的类型选择为 Secret file，然后将上面使用 kubeadm 部署生成的 kubeconfig 上传到这里。点击连接测试，如果提示 Connected to Kubernetes v1.19.8 就说明已经成功连接上了 kubernetes 集群。关于 pod 模板其实就是配置 Jenkins Slave 运行的 Pod 模板，个人不太建议使用插件中的模板去配置，推荐将 pod 的模板放在 Jenkinsfile 中，因为这些配置与我们的流水线紧密相关，把 pod 的配置存储在 Jenkins 的插件里实在是不太方便；不方便后续的迁移备份之类的工作；后续插件升级后这些配置也可能会丢失。因此建议将 pod 模板的配置直接定义在 Jenkinsfile 中，灵活性更高一些，不会受 Jenkins 插件升级的影响。总之用代码去管理这些 pod 配置维护成本将会少很多。Jenkinsfile流水线 Jenkinsfile，下面是一个简单的任务，用于构建 webp-server-go项目的 docker 镜像。// Kubernetes pod template to run.def JOB_NAME = "${env.JOB_NAME}"def BUILD_NUMBER = "${env.BUILD_NUMBER}"def POD_NAME = "jenkins-${JOB_NAME}-${BUILD_NUMBER}"podTemplate(# 这里定义 pod 模版){ node(POD_NAME) {    container(JOB_NAME) {      stage("Build image") {        sh """#!/bin/bash          git clone https://github.com/webp-sh/webp_server_go /build          cd /build          docker build -t webps:0.3.2-rc.1 .        """      }    }  }}pod 模版如下，将模板的内容复制粘贴到上面的 Jenkinsfile 中。在容器中构建镜像，我们使用 dind 的方案：将 pod 所在宿主机的 docker sock 文件挂载到 pod 的容器内，pod 容器内只要安装好 docker-cli 工具就可以像宿主机那样直接使用 docker 了。podTemplate(  cloud: "kubernetes",  namespace: "default",  name: POD_NAME,  label: POD_NAME,  yaml: """apiVersion: v1kind: Podspec:  containers:  - name: ${JOB_NAME}    image: "debian:buster-docker"    imagePullPolicy: IfNotPresent    tty: true    volumeMounts:    - name: dockersock      mountPath: /var/run/docker.sock  - name: jnlp    args: ["\$(JENKINS_SECRET)", "\$(JENKINS_NAME)"]    image: "jenkins/inbound-agent:4.3-4-alpine"    imagePullPolicy: IfNotPresent  volumes:  - name: dockersock    hostPath:      path: /var/run/docker.sock""",)构建 debian:buster-docker 镜像，使用它来在 pod 的容器内构建 docker 镜像，使用的 Dockerfile 如下：FROM debian:busterRUN apt update \    && apt install -y --no-install-recommends \        vim \        curl \        git \        make \        ca-certificates \        gnupg \    && rm -rf /var/lib/apt/lists/*RUN curl -fsSL "https://download.docker.com/linux/debian/gpg" | apt-key add -qq - >/dev/null \    && echo "deb [arch=amd64] https://download.docker.com/linux/debian buster stable" > /etc/apt/sources.list.d/docker.list \    && apt update -qq \    && apt-get install -y -qq --no-install-recommends docker-ce-cli \    && rm -rf /var/lib/apt/lists/*定义好 jenkinsfile 文件并且构建好 pod 模板中的镜像后，接下来我们开始使用它来创建流水线任务。流水线在 Jenkins 上新建一个任务，选择任务的类型为 流水线将定义好的 Jenkinsfile 内容复制粘贴到流水线定义 Pipeline script 中并点击保存。在新建好的 Job 页面点击 立即构建 来运行流水线任务。在 kubernetes 集群的机器上使用 kubectl 命令查看 pod 是否正常 Runningroot@jenkins:~ # kubectl get podNAME                              READY   STATUS    RESTARTS   AGEjenkins-webps-9-bs78x-5x204   2/2     Running   0          66sJob 正常运行并且状态为绿色表明该 job 已经成功执行了。在 kubernetes 集群机器上查看 docker 镜像是否构建成功root@jenkins:~ # docker images | grep webpswebps                                0.3.2-rc.1          f68f496c0444        20 minutes ago      13.7MB踩坑pod 无法正常 RunningRunning in Durability level: MAX_SURVIVABILITY[Pipeline] Start of Pipeline[Pipeline] podTemplate[Pipeline] {[Pipeline] nodeCreated Pod: kubernetes default/debian-35a11b49-087b-4a8c-abac-bd97d7eb5a1f-fkmzq-9wm0r[Normal][default/debian-35a11b49-087b-4a8c-abac-bd97d7eb5a1f-fkmzq-9wm0r][Scheduled] Successfully assigned default/debian-35a11b49-087b-4a8c-abac-bd97d7eb5a1f-fkmzq-9wm0r to jenkins[Normal][default/debian-35a11b49-087b-4a8c-abac-bd97d7eb5a1f-fkmzq-9wm0r][Pulling] Pulling image "debian:buster"[Normal][default/debian-35a11b49-087b-4a8c-abac-bd97d7eb5a1f-fkmzq-9wm0r][Pulled] Successfully pulled image "debian:buster" in 2.210576896s[Normal][default/debian-35a11b49-087b-4a8c-abac-bd97d7eb5a1f-fkmzq-9wm0r][Created] Created container debian[Normal][default/debian-35a11b49-087b-4a8c-abac-bd97d7eb5a1f-fkmzq-9wm0r][Started] Started container debian[Normal][default/debian-35a11b49-087b-4a8c-abac-bd97d7eb5a1f-fkmzq-9wm0r][Pulling] Pulling image "jenkins/inbound-agent:4.3-4-alpine"Still waiting to schedule task‘debian-35a11b49-087b-4a8c-abac-bd97d7eb5a1f-fkmzq-9wm0r’ is offline[Normal][default/debian-35a11b49-087b-4a8c-abac-bd97d7eb5a1f-fkmzq-9wm0r][Pulled] Successfully pulled image "jenkins/inbound-agent:4.3-4-alpine" in 3.168311973s[Normal][default/debian-35a11b49-087b-4a8c-abac-bd97d7eb5a1f-fkmzq-9wm0r][Created] Created container jnlp[Normal][default/debian-35a11b49-087b-4a8c-abac-bd97d7eb5a1f-fkmzq-9wm0r][Started] Started container jnlpCreated Pod: kubernetes default/debian-35a11b49-087b-4a8c-abac-bd97d7eb5a1f-fkmzq-qdw4m[Normal][default/debian-35a11b49-087b-4a8c-abac-bd97d7eb5a1f-fkmzq-qdw4m][Scheduled] Successfully assigned default/debian-35a11b49-087b-4a8c-abac-bd97d7eb5a1f-fkmzq-qdw4m to jenkins[Normal][default/debian-35a11b49-087b-4a8c-abac-bd97d7eb5a1f-fkmzq-qdw4m][Pulled] Container image "debian:buster" already present on machine[Normal][default/debian-35a11b49-087b-4a8c-abac-bd97d7eb5a1f-fkmzq-qdw4m][Created] Created container debian[Normal][default/debian-35a11b49-087b-4a8c-abac-bd97d7eb5a1f-fkmzq-qdw4m][Started] Started container debian[Normal][default/debian-35a11b49-087b-4a8c-abac-bd97d7eb5a1f-fkmzq-qdw4m][Pulled] Container image "jenkins/inbound-agent:4.3-4-alpine" already present on machine[Normal][default/debian-35a11b49-087b-4a8c-abac-bd97d7eb5a1f-fkmzq-qdw4m][Created] Created container jnlp[Normal][default/debian-35a11b49-087b-4a8c-abac-bd97d7eb5a1f-fkmzq-qdw4m][Started] Started container jnlp这是因为 Jenkins pod 中的 jnlp 容器无法连接 Jenkins master。可以检查一下 Jenkins master 上 系统管理 > 节点管理 > Configure Clouds 中 Jenkins 地址 和 Jenkins 通道 这两个参数是否配置正确。结束到此为止，我们就完成了让 Jenkins 大叔与 kubernetes 船长手牵手 ‍‍ 啦！上面使用了一个简单的例子来展示了如何将 Jenkins 的 Job 任务运行在 kubernetes 集群上，但在实际工作中遇到的情形可能比这要复杂一些，流水线需要配置的参数也要多一些。那么我将会在下一篇博客中再讲一下高级的用法：使用 Jenkins 完成 kubespray 离线安装包打包。

https://mirrors.huaweicloud.com/jenkins/plugins/matrix-project/https://mirrors.cloud.tencent.com/jenkins/plugins/matrix-project/1.17版本 看一下腾讯的

第一个项目故事：基于 docker+k8s+jenkins+gitlab 的持续集成项目实现效果：开发人员把自己分支的代码从 gitlab合并到 master 分支，触发jenkins job 执行代码编译打包和部署到测试环境操作服务器数量：两台jenkins做高可用，十八台服务器做docker容器的web服务器。架构运行思路：gitlab上更新了代码以后，通过webhook检测到gitlab上有变动，然后将给本机的jenkins传送一个回执，执行任务，任务内容是进行代码pull到本机中然后通过脚本命令把代码转移到本机的nfs目录中，然后通过jenkins上的nfs挂载到所有web容器的宿主机上，并将宿主机的挂载目录映射到容器里面的网页根目录中实现了一键自动部署环境。架构生存时间：jenkins做了高可用实现了不间断工作，docker使用脚本造成了容器自启的效果。架构图：项目过程：记得这个项目大概是2017年上半年做的，当时对于 k8s jenkins 了解的还停留在听说的阶段，但是接到这个项目需求当时自己非常的紧张和兴奋，紧张是因为有好多的未知技术需要探索，兴奋是可以了解更多的新技术；经过大量的查阅文档实践测试终于通过两个星期的没有昼夜的努力实现了需求。交付的那一刻非常的激动。总结：当时自己工作经验不足，实战经验也少，回想起来自己3年前做的项目依然可以看到自己的成长之路，现在回头看之前做过的项目有好多可以改进和提升的地方

能否提供基于jenkins File的jenkins构建支持？coding就采用了这一方式，这个方式灵活，便于迁移，而且还支持构建环境的docker化。

１ JENKINS简介Jenkins是一个开源软件项目，是基于Java开发的一种持续集成工具，用于监控持续重复的工作，旨在提供一个开放易用的软件平台，使软件的持续集成变成可能。２ 环境信息2.1 环境信息类别子项版本获取地址OSCentOS7.6 Aarch64https://www.centos.org/download/服务器配置16U16GB50GB软件jenkins2.190.1https://prodjenkinsreleases.blob.core.windows.net/redhat-stable/jenkins-2.190.1-1.1.noarch.rpm ３ 软件移植3.1 环境准备：OS安装类型：CentOS-7-aarch64-Everything-1810。 注：操作系统安装使用最小简化版安装(如上图)，其余步骤安装一般安装操作系统步骤即可。3.1.1 相关软件下载上传：1、 上传jenkins-2.190.1-1.1.noarch.rpm源码包至服务器目录下下载地址：https://prodjenkinsreleases.blob.core.windows.net/redhat-stable/jenkins-2.190.1-1.1.noarch.rpm2、 上传CentOS-7-aarch64-Everything-1810.iso至服务器目录下下载地址：https://www.centos.org/download/3.2 软件安装脚本执行指导下载附件脚本至服务器。赋予脚本执行权：限chmod +x jenkins_install.sh执行Jenkins安装脚本：sh jenkins_install.sh４ 软件运行4.1 测试已完成编译的软件4.1.1 通过浏览器访问以下网址http://[ECS IP]:8080浏览器返回如下信息，表明Jenkins正常工作。    ５ 参考信息 ６ FAQ

对Jenkins镜像来说，一定要独占域名，在域名根目录下。这样只修改hosts就能使用。否则，几乎不可用，要通过自建代理的复杂手段才行。建议：申请一个子域名，比如jenkins.mirrors.huawei.com。把镜像内容挪到这个子域名下，或者内部自建子域名反向代理到原位置。这样用起来会方便许多。

--20181012 华为HC全连接大会引言：一切优秀理念和方法论的大规模普及，都有赖于先进技术的发展以及对应工具的发明创造来承载，DevOps持续交付理念亦不例外。软件开发是截止目前为止，人类最复杂、最不可控的工程技术工作，一次代码提交到上线，会涉及数十、数百、乃至数千个步骤、命令、服务、应用和环境，如果我们没有自动化交付流水线来不断提升自动化率，实施可重复且可靠的交付运作，而按照传统的以流程文档和操作规范指引、通过手工操作来进行交付活动的话，其工作效率之低、错误率之高已经和正在被诸多没有采用DevOps开发模式和持续交付工具链的企业所验证。2018年华为全连接大会HC，KK（Kohsuke Kawaguchi）与华为专家同台演讲，共同展望持续交付流水线关键技术和实践。KK：《Super Powers Coming to Your Jenkins》主题演讲KK（Kohsuke Kawaguchi）作为Jenkins的创始人、CloudBees公司CTO，是将DevOps持续交付理念进行工具工程化实践的第一人，更是推动DevOps理念大规模普及的灵魂人物之一。作为软件开发端到端持续交付系统，Jenkins用户量达200+万，在持续交付流水线专业工具领域市场占有率超90%，是事实上的流水线工具标准。在本次华为HC大会上，KK带来主题为《Super Powers Coming to Your Jenkins》的精彩演讲，内容涉及DevOps CI/CD持续交付理念和方法论，以及Jenkins流水线Jenkins 2、Blue Ocean、Cloud Native Jenkins、Jenkins Evergreen、Jenkins X等面向不同场景的产品解决方案及关键技术。例如，有了Cloud Native Jenkins，通过云化和弹性扩容降低单点故障，用户就不会在周五晚上接到Jenkins服务宕机需要修复的连环夺命call，也无需做资源的预留以降低运维成本和前期投资，未来也将会有更高的性能表现。Jenkins Evergreen提供了预置模板，用户仅需几次点击，在几分钟内即可生成一条可持续工作的流水线，大大简化流水线的配置步骤，有效降低配置门槛。Evergreen所有的配置均由Jenkins管理，可在线升级，用户只需专注于自己的业务开发和交付即可，无需关注各种复杂的流水线配置和组件管理。Jenkins configuration as code实践一切配置即代码，用户可通过编写YAML脚本来对接插件、安全工具、检查工具、文档服务等，任何工具或者服务均可以通过脚本来实现对接。基于此，用户可以对版本控制、代码审计、滚动部署等环节跟踪查看，精确追溯插件集及其版本，使用户对各种更改更有信心。随着新型云操作系统kubernetes的兴起，用户需要跟进学习一大堆新知识、工具与和服务，比如如何往容器迁移，如何安装和实施k8s，如何将容器安装到k8s，k8s的生态系统和工具链对比选型等等，总而言之，适配Kubernetes绝非易事。Jenkins X致力于提供持续交付云原生应用的最佳实践，涵盖构建、测试、审查、变更、协作等各种最优产品。除此之外，Jenkins通过可工作的默认配置，高频特性推荐等大幅增强产品易用性和使用体验。华为专家周宇：《基于Pipeline的DevOps核心实践》主题演讲华为研发模式先后经历了手工作坊、IPD、测试自动化工厂、CI、CD、DevOps等各种研发模式的变迁，随之进行了对应的组织和流程变革，并产生了相应的工具平台来承载这些模式的落地和运行。随着研发模式、组织、流程、工具的不断变革，产品交付效率大幅提升，TTM时长从过去的1~1.5年缩短至2~6周。一些偏互联网化的产品，迭代周期缩短至1周，每天可以并行发布多个微服务。在这个过程中，自动化的持续交付流水线平台/服务，是最核心的工程实践。基于流水线，以代码提交到上线的端到端交付周期的缩短作为目标驱动，使得各服务自动化能力和并发效率实现大幅提升改进，比如手工转自动化测试、容器化构建、基础设施即代码、容器化部署、灰度发布服务等，确保产品最终的可重复、可靠的快速迭代发布。华为内部8万研发员工，最初使用的基本都是商用开发工具，而这些工具很难满足产品敏捷交付的需求，毕竟产品的敏捷和快速迭代，有赖于工具平台的敏捷和快速迭代能力的支撑。因而全面转向了开源，并在保证100%兼容原生开源系统的同时，进行云化、服务化、单点登录、多region、高并发、高可靠、高安全、面向不同行业和解决方案场景等方面持续强化，构筑产品核心竞争力。当华为意识到，华为内部面临的软件持续交付工具链搭建、运维的核心痛点，其他企业也会面临时，便将工具链对外提供服务。希望通过可视化、灵活编排的自动化持续交付流水线及DevOps工具链，实现不中断业务升级，产品分钟级发布上线，助力企业大幅缩短交付周期，提升交付效率和产品质量。从产品角度来看，华为产品团队和代码规模跨度极大，一些典型的大产品，代码量达1000+万行，团队规模也达1000+人，不仅组件多，团队也多，相互依赖更多。同时，华为大平台战略带来一个现象，就是产品通常依赖于另外一个独立BG下的一个大平台产品，且业务BG内部还会有自己的小平台产品，这样导致一个产品会依赖于好几个不同团队交付的不同平台。而由于产品规模太大，业务特性达数千个，模块也往往达到数十上百个。不同部门使用的环境和组网也会存在极大差异。在这种复杂的环境下，华为构建了分层分级持续交付流水线，分为个人级、项目级、子系统级、产品级（版本级）、解决方案级等数级流水线，通过流水线编排工作流、触发下一级流水线的执行来保障产品团队和组件之间的协同交付、价值流转。在这个过程中，配套L1-L4分级测试模型，在不同层级流水线执行不同的自动化测试策略，并设置每个阶段任务对应的质量门禁来判断是否允许流水线继续执行。通过多级流水线的层层防护，使得缺陷发现前移，有效保障了产品质量。对应于最新的微服务化的产品形态，配套提供了微服务持续交付流水线模板。区别于传统产品持续交付流水线，微服务流水线在角色权限上匹配全功能团队全栈工程师的角色权限模型，SDE可以提交代码并端到端执行流水线直至微服务发布上线。同时，构建出镜像，并实施容器化部署、灰度发布策略、失败自动回滚策略，微服务可按天、按小时甚至分钟级灰度发布上线。针对静态资源提供了持续部署流水线，流水线从软件包变更开始执行，到跨多region并行部署，实现多区多服务器的静态资源包自动更新。在相关配套技术和服务中，灰度发布能力、极速构建、基础设施即代码、配置即代码、Docker、K8s、自动部署、自动化测试、CloudPipeline CDDL（Continious Deliver Domain Language）描述文件等尤为关键。灰度发布、蓝绿部署等策略可以确保不中断服务升级。增量构建、并行构建、依赖预读与缓存、容器化slave等不断提升构建速度，从小时级进入分钟级。通过容器化技术使得环境标准化，有效消除DTAP四大环境间的差异，减少环境配置、部署和问题定位成本。CDDL描述语言定义流水线的编排和各服务接入标准。人工审核可以在自动化能力未达到完全保障质量的情况下，增加评审人来把控下发布质量。自动化一切、代码化一切、服务化一切、版本化一切、数据化一切、可视化一切，是流水线和DevOps平台的基本方向。未来还会包括智能化一切。同时，DevCloud流水线支持百万级并发调度能力，提供可视化看板，和任务健康度（执行成功率）、及流水线整体、阶段、任务三级执行时长直观展示，主动呈现价值流中的主要阻塞点。在DevCloud on DevCloud的dogfooding吃狗粮实践中，提及在传统自动化测试理念上，探索在线测试的新方法和理念、实践，并逐步加大在线测试比重，以便进一步缩短TTM、提升产品质量。在演讲后期，华为专家基于现网进行了“一次修改如何快速上线”的实战演示，这种基于现网生产环境的现场演示，是需要十分的底气和自信的，也彰显了DevCloud华为软件开发云服务的质量可信度。 十分钟互动论坛：现场观众踊跃提问，涉及微服务流水线和AI在流水线上如何应用，数据安全，以及Jenkins开源社区与DevClou战略合作等方面。KK和华为专家都分享了自己的独特思考，对自动化持续交付流水线未来的演进方向做了深入的设想和阐述。未来，围绕持续交付产生的海量研发数据，必然成为AI驱动研发乃至企业商业转型的核心要素之一，特别对于高科技公司而言，这一点尤为重要。 双方合作：华为正致力于Jenkins网站的中文本地化工作， DevCloud Cloudpipeline流水线服务基于Jenkins2，以及未来双方进一步共同探索在社区更深层次的合作，希望Jenkins和DevCloud华为软件开发云服务能够共同为大家提供更好的持续交付流水线服务。最后，“The more you build quality into systems — through automation & shorter cycle times — the more you increase throughput & stability”，让我们用流水线所承载的快速、可靠、可重复的持续交付使命作为结束，仗剑而行吧！官方公众号链接：https://mp.weixin.qq.com/s/KKKOLfMB3H62z6JCbEuQiA

 Jenkins目前主要应用在自动化构建，持续集成/发布，持续交付等场合，受到了越来越多的企业追捧。而其插件也各式各样，囊括了代码管理，自动化构建，自动化代码扫描，自动化测试，制品管理等多个软件相关的工程领域，同时和多款开源工具结合，为日常工作带来了诸多方便。现介绍几个常用的插件：用户及权限Jenkins用户权限管理是Jenkins Administration中非常重要的环节，由于大部分企业都会有自己的域控管理，因此和LDAP集成并基于用户组实现权限模型设计与管理是企业级Jenkins实践的重要内容.1)  LDAP（https://plugins.jenkins.io/ldap），这个插件允许使用LDAP对用户进行认证，LDAP服务器可以是Active Directory或者OpenLDAP。2) Active Directory（https://plugins.jenkins.io/active-directory），这个插件允许使用Active Directory对用户进行认证，同时结合诸如Matrix Authorization Strategy等插件，可以识别用户所在的所有用户组，对用户授权进行灵活配置。基于Windows Active Directory进行域管理的企业，推荐采用Active Directory。3) GitHub Authentication（https://plugins.jenkins.io/github-oauth），这个插件提供了使用GitHub进行用户认证和授权的方案。4) Matrix Authorization Strategy（https://plugins.jenkins.io/matrix-auth），这个插件提供了基于矩阵的授权策略，支持全局和项目级别的配置。5) Role-based Authorization Strategy（https://plugins.jenkins.io/role-strategy），这个插件提供了一种基于角色（Role）的用户权限管理策略，支持创建global角色、Project角色、Slave角色，以及给用户分配这些角色。这款插件是最常用的Jenkins权限策略和管理插件。代码管理在Jenkins项目中，通过配置Source Code Management去下载代码进行构建任务，是比较普遍的应用场景，最常见的是Git和SVN。1) Git（https://plugins.jenkins.io/git），支持使用Github、GitLab、Gerrit等系统管理代码仓库。2) Subversion（https://plugins.jenkins.io/subversion），支持使用Subversion系统管理源代码。项目及视图Jenkins中对Project和view的管理是用户日常工作中经常使用的功能。1) Folder（https://plugins.jenkins.io/cloudbees-folder），这个插件支持用户使用目录管理项目，目录支持嵌套，并且支持在目录中创建视图。2) List view Jenkins默认支持List类型的视图，用户可以创建List视图来过滤所关心的项目。3)Sectioned View（https://plugins.jenkins.io/sectioned-view），这个插件支持一种新的视图，视图可以分为多个部分。构建触发Jenkins支持多种Build触发方式，其中的一些自动化触发方式非常有用。 1)Build periodically，Jenkins内置功能，可以设置类似crontab时间，实现周期性地自动触发构建。 2)Poll SCM，Jenkins内置功能，类似Build periodically，可以设置类似crontab时间，不同之处在于，不是直接进行构建，而是周期性地在后台检查所配置的SCM有没有更新，只有当有代码更新时才触发构建。 3)Trigger builds remotely (e.g., from scripts)，Jenkins内置功能，远程触发构建，通过设置token可以支持远程脚本触发Jenkins构建。 4) Gerrit Trigger（https://plugins.jenkins.io/gerrit-trigger），这个插件将Jenkins集成到Gerrit code review中，支持Jenkins配置Gerrit服务器等信息，实现Gerrit event 触发Jenkins构建。构建任务及环境 1) Workspace Cleanup（https://plugins.jenkins.io/ws-cleanup），支持在构建前后删除或者部分删除workspace 2) description setter（https://plugins.jenkins.io/description-setter），支持正则表达式匹配构建log输出，设置构建的描述。 3) build-name-setter（https://plugins.jenkins.io/build-name-setter），支持设置构建的显示名字，而不是只能使用默认的#1，#2，……，#buildnum。 4) Environment Injector（https://plugins.jenkins.io/envinject），支持在构建任务的不同阶段**环境变量，并且在构建结束时导出所有的环境变量等功能。构建通知把构建状态及时地通知到用户，是Jenkins的一个必不可少的功能。Jenkins支持多种主动和被动的通知方式。 1)  Mailer（https://plugins.jenkins.io/mailer），这个插件支持基本的邮件通知功能，比如构建失败和构建恢复成功可以给相关人员发送邮件通知。Admin相关插件 1)  Configuration Slicing（https://plugins.jenkins.io/configurationslicing）:支持批量修改项目配置。 2) Mask Passwords（https://plugins.jenkins.io/mask-passwords）:支持遮挡构建log输出的password等敏感信息。 3) Backup（https://plugins.jenkins.io/backup）:负责将备份功能添加到Jenkins management中。如下是我们目前使用的相关部分插件：

求jenkins镜像，造福广大人民。