Jenkins

linux环境配置1 安装Javayum install java-1.8.0-openjdk.x86_642 安装mavenyum install maven3 安装gityum install git4 安装tomcat下载最新的tomcat包，放到/root目录下，运行tar zxvf tomcat-*.tgz5 安装运行Jenkins点击这里下载Jenkins最新的war包，并放到/root/apache-tomcat-7.0.86/webapps/目录下。6 运行命令 cd apache-tomcat-7.0.86/webapps/ 进入war包所在目录，运行命令nohup java -jar jenkins.war –httpPort=8080 & 启动Jenkins。8080为默认端口，如果和其他服务冲突可改变为其他端口7 浏览器访问 服务器地址:端口号（例如192.168.0.100:8080）即可访问JenkinsJenkins配置1 安装必需的插件Deploy to container Plugin; GitLab Plugin；Maven Integration2 配置jenkins工具环境配置jdk配置Git配置Maven3 新建任务，选择构建maven项目4 source Code Management选择Git需要先点击add添加一个账号，打开这个页面填写你在gitlab的账号密码即可选择刚添加的账号，下面的分支记得改成自己需要的5 勾选一下构建快照6 Build这个pom文件不用修改，下面的语句可添加也可不添加7 配置到这一步已经可以自动打包了，我们构建看一下第一次运行会下载很多jar包，等待下载完成即可，打包成功后如下图所示报错1 [ERROR] Failed to execute goal on project : Could not resolve dependencies for project 🫙1.0-SNAPSHOT: The following artifacts could not be resolved: com.alibaba:dubbo🫙2.8.4, com.cloopen:sms-rest-sdk🫙2.6.3, com.taobao.pamirs.schedule:tbschedule🫙3.3.3.2: Could not find artifact com.alibaba:dubbo🫙2.8.4 in central (http://jcenter.bintray.com)缺少对应的jar包，可以直接从其他测试环境下复制过来 ...

一、Jenkins配置1.安装NodeJS Plugin 在插件管理界面 搜索Node 找到NodeJS，安装、重启，成功后如下图：2.配置NodeJS Server 在全局工具配置中，如下配置：二、项目配置选择"构建一个自由软件风格的项目" ，配置如下：1.配置git项2.Build Environment3.Build配置项其中echo $PATH 、which node、 node -v、npm -v 可选，只是打印一下信息4.Build后的操作执行的命令，根据自己情况自由发挥三、遇到问题“env node not found” 遇到这个问题，jenkins一直无法打包。 找到解决问题的过程很曲折，这里直接贴结果：https://stackoverflow.com/que…在第二个回到中：$ docker exec -u 0 -it jenkins-1 bashbash-4.3# apk add –no-cache nodejsbash-4.3# node –versionv6.9.5bash-4.3# npm –version5.6.0其实就是 进入docker的命令行，然后执行apk add –no-cache nodejs ，自己手动安装nodejs ， 问题就解决了。

前排提示下面几个工具运行都需要基于jdk，请大家自行百度安装jdk，并配置好环境变量安装jmeter下载包，解压，配置JMeter_home点击这里下载最新的jmeter的tar包，直接放到服务器的/root目录中输入命令tar zxvf apache-jmeter-5.1.1.tgz解压2.配置JMeter_HOME打开/root下的.bash_profile文件，下面的代码写入文件最后export JMETER_HOME=/root/apache-jmeter-5.1.1 export CLASSPATH=$JMETER_HOME/lib/ext/ApacheJMeter_core.jar:$JMETER_HOME/lib/jorphan.jar:$JMETER_HOME/lib/logkit-2.0.jar:$CLASSPATH export PATH=$JMETER_HOME/bin:$PATH:$HOME/bin保存后运行 source /root/.bash_profile （让配置文件立马生效）运行 jmeter -v，成功后如下图所示3.jmeter自带的报告模板内容不够详细，我这提供一个网上的更加详细的模板，点此下载，放到/root/apache-jmeter-5.1.1/extras/目录下4.点击这里下载jmeter的插件jar包，放到/root/apache-jmeter-5.1.1/lib/ext/目录下安装ANT1.点击这里下载最新的ANT tar包，同一解压到/root目录下2.编辑/etc/profile,把下面的代码添加到文件末尾ANT_HOME=/root/apache-ant-1.10.5CLASS_PATH=.:$JRE_HOME/libPATH=$JRE_HOME/bin:$ANT_HOME/binexport ANT_HOME CLASS_PATH PATH3.保存后运行 source /etc/profile，使配置立即生效4.运行ant -version看一下配置成功没有，成功的话如下图所示安装运行Jenkins0 Jenkins需要放在tomcat中运行，tomcat下载后解压到/root目录下几个，参考上面jmeter安装步骤第1步即可1 点击这里下载Jenkins最新的war包，并放到/root/apache-tomcat-7.0.86/webapps/目录下。2 运行命令 cd apache-tomcat-7.0.86/webapps/ 进入war包所在目录， 运行命令nohup java -jar jenkins.war –httpPort=8080 & 启动Jenkins。8080为默认端口，如果和其他服务冲突可改变为其他端口3.浏览器访问 服务器地址:端口号（例如192.168.0.100:8080）即可访问Jenkins4.Jenkins中创建任务和在win环境下没有什么区别，只是需要改变路径路径配置1 在全局工具配置中添加ant2 build.xml中的报告生成路径下面三个步骤是针对 HTML report和performance 和E-mail插件的3 把任务中的html报告路径和build.xml中的路径匹配起来4 把任务中的jtl路径修改为build.xml中的路径（这里的时间变量是我自定义的，具体原因可看这篇文章）5 配置邮件提醒的附件路径

昨天把Jenkins部署好了，但是用了之后发现performance插件有问题，如果按下面这样设置统计所有的jtl文件，会导致文件夹过于臃肿，于是，而且生成的Performance Trend 比较混乱，不是很直观，于是思考修改一下试验了一下发现如果多次构建后生成在同一个jtl文件里，解析出的Performance Trend是正确的，但是我原本的设置中，jtl文件名是精确到分钟的，需要修改成精确到天的，这样正好一天的结果能看的很直观。 修改不是很难，总共修改3个地方即可 1.build.xml文件中的时间戳精度 原来是这样的，，jtl和html用的是同一个时间变量，咱们需要把这两个分开来修改后如下，也就是多建立一个精确到天的时间变量2.在Jenkins系统设置中建立一个精确到天的时间变量，TimeStamp插件提供了新建时间变量的功能，咱们只要把时差设置为0即可，注意，负号和0之间有空格3.修改任务中performance插件的jtl路径，使用新的时间变量设置好了，运行看一下

FAQ什么是持续交付（CD）？CD是一种软件工程方法，团队在短周期内生成软件，确保软件可以随时可靠地发布。微服务、云原生架构的兴起引发了持续交付实践的必然结果。这与CI/CD有关，其中包括持续集成（CI） - 将所有开发者工作副本一天多次合并到共享主线的做法。宣布了什么？CDF（Continuous Delivery Foundation，持续交付基金会）是一个新的、中立的组织，将发展和维持一个开放的持续交付生态系统。它将提供统一的治理和与供应商中立的管理，以及对资金和运营的监督。CD基金会的第一批项目是Jenkins、Jenkins X、Spinnaker和Tekton。为什么CD社区组成基金会。为什么需要？整个行业都迫切需要围绕管道、工作流程和其他CI/CD领域合作定义行业规范，并为CI/CD工具提供基础支持。例如，Jenkins社区正在寻求一个“全方位服务”的基金会来托管Jenkins（最受欢迎的CI/CD项目之一），并构建一个增强协作的平台。还需要一个全行业的中立DevOps/CD会议。这是否代表了云原生态系统的转变？是的，市场已转向容器化和云原生技术，因此CI/CD系统、DevOps和相关工具的生态系统发生了根本性的变化。CNCF云原生互动景观展示了CI/CD领域的多样性，以及在该领域中活跃的众多项目和供应商。通过建立供应商中立的持续交付基金会，业界顶级开发者、最终用户和供应商可以将CI/CD作为方法，定义/记录最佳实践以及创建培训材料，以使全球任何软件开发团队能够交付代码更改更快、更可靠、无论它们是否为云原生。开发者为何要关心？CI/CD项目目前面临的挑战，包括工具复杂性和管道和其他CI/CD工具缺乏行业标准化，正在抑制增长和创新。由于缺乏中立的法律实体和强有力的治理，项目很难吸引新开发者和组织的宝贵支持。项目维护者和开发者花费大量时间和金钱处理安全程序和监督等方面的变通方法。这使人们不再关注新的发展和创新。拥有广泛行业支持的基金会将能够更快地定义行业规范，并为跨项目协作创造更多机会，以改善开发者的工具。谁用CD？CD广泛应用于云计算、企业IT，并且正在迅速扩展到其他顶级行业垂直领域。例如，在网络运营商与供应商并肩工作，开发CI/CD工具，使开发者能够直接与上游项目的分支合作 - 大幅缩短实施新功能的时间，并解决数月到数天的错误。使用云原生技术（如Kubernetes）时，设置CI/CD管道将加快发布生命周期。这使开发者每天可以多次发布；让团队灵活到足以快速迭代。CDF如何与渐进式交付相关？渐进式交付（Progressive delivery）是现代持续交付技术的一种形式，例如灰度发布、功能标记、A/B测试、经过验证的部署组等。渐进式交付技术和技术与持续交付密切相关。有关渐进式交付的更多信息，请阅读James Governor关于此主题的Redmonk博客：https://redmonk.com/jgovernor…这将如何影响开源软件的开发？持续交付可提高软件开发团队的速度、生产力和可持续性。CDF促进行业顶级开发者、最终用户和供应商之间的合作，以确保CD方法的软件工程充分发挥其潜力，推进开源软件开发。哪些项目将包含在CDF中？CDF正在推出四个项目：Jenkins、Jenkins X、Spinnaker和Tekton，还有更多感兴趣的项目正在筹备中。我们邀请人们关注CDF技术监督委员会（“TOC”），该委员会将在未来做出项目决策：https://github.com/cdfoundati…。我是否必须是成员才可以贡献到CDF项目？绝对不是，CDF中的开源项目或任何Linux基金会计划的技术贡献都不需要成员资格。组织作为成员加入CDF，因为它们希望在持续交付模型和最佳实践的增长和发展中扮演积极的角色，而不只是支持CDF中的开放源码项目。如果你有兴趣加入，请参阅https://cd.foundation/members…。什么是Jenkins？Jenkins是领先的开源自动化服务器，由大量不断增长的开发者、测试者、设计者和其他对持续集成、持续交付和现代软件交付实践感兴趣的人提供支持。它基于Java虚拟机（JVM），提供超过1,500个插件，可将Jenkins扩展为几乎所有技术软件交付团队使用的自动化服务器。2019年，Jenkins有超过了200,000个已知安装，使其成为部署最广泛的自动化服务器。什么是Jenkins X？Jenkins X是Kubernetes上现代云应用程序的开源CI/CD解决方案。Jenkins X提供管道自动化、内置GitOps和预览环境，以帮助团队协作并加速他们的软件交付。Jenkins X使用最好的OSS工具自动化Kubernetes的CI + CD，如Jenkins、Tekton、Prow、SkaffoldKaniko和Helm。为什么Jenkins和Jenkins X成为CDF的一员？Jenkins和Jenkins X将成为与技术兴趣相关的中立社区的一部分，并在构建开发者社区和项目治理方面获得帮助。CD基金会还将协助Jenkins和Jenkins X的营销和文档工作。这对现有Jenkins用户有何影响？将Jenkins和Jenkins X捐赠给CD基金会将促进行业内开发者、最终用户和供应商之间的更多合作。有关详细信息，请参阅此电子邮件和与Jenkins社区的对话：https://groups.google.com/for…什么是Tekton？Tekton是一组用于构建CI/CD系统的共享开源组件。它使持续交付控制平面现代化，并将软件部署的大脑转移到Kubernetes。Tekton的目标是通过供应商中立的开源基金会为CI/CD管道、工作流程和其他构建模块提供行业规范。Tekton的代码在https://github.com/tektoncd/p…。为什么Tekton成为CDF的一员？为什么Google会捐赠代码？作为CDF的创始成员，谷歌正在捐赠Tekton。正如Kubernetes通过提供一组标准的API在云中进行交互而彻底改变了应用程序开发，Google的目标是通过CD基金会为DevOps从业者提供相同的优势。CDF将提供行业规范、安全、实用和可扩展的持续交付构建块，可用于在任何地方部署代码。Tekton对knative build的影响是什么？从第1天开始，可插拔性一直是knative的核心功能。将Build与Serving分离的目标是强化这种可插拔性概念。已经对构建系统感到满意的用户可以将其与Knative Serving一起使用。Tekton将继续支持Knative生态系统作为一流的目标环境。Tekton管道将部署到Knative环境。在可预见的未来，Knative Build将继续作为Knative的一部分，专注于无服务器环境的源到容器工作流程。这两个项目将在标准和界面上保持紧密联系。什么是Spinnaker？Spinnaker是云端优先的持续交付平台，最初由Netflix创建，目前由Netflix和Google共同领导。它支持所有主要的云平台和Kubernetes，并得到各个供应商的贡献。Spinnaker通常用于大规模组织，DevOps团队通过提供“黄金路径”（golden path）应用程序部署管道来支持许多开发者。为什么Google/Netflix将Spinnaker捐赠给CDF？随着Spinnaker最近将其治理正式化，将其转移到基金会是社区自然的下一步。Spinnaker设计为持续交付平台，通常与Jenkins结合使用，因此CDF真的是项目的理想之家。Spinnaker也是一个多组件系统，在概念上与Tekton分享了许多想法 - 看到两个项目在一个基金会上聚集在一起，是将持续交付向前推进的巨大机会。这对Spinnaker用户有何影响？Spinnaker作为CDF的一员，社区将有更多机会创建更简单、更强大的端到端体验，并就CI/CD的一套通用标准进行协作。Spinnaker用户在持续交付领域拥有丰富的经验，加入CDF提供了一个与更广泛的社区分享专业知识的绝佳机会。Spinnaker用户还将受益于CDF社区中广泛的CI/CD知识，他们使用的各种工具之间的一致性，当然还有不断改进的生态系统！未来的CI/CD项目进入CDF的过程是怎样？其他项目预计将通过其即将成立的技术监督委员会（TOC）加入CDF：https://github.com/cdfoundati…，重点是将CD生态系统整合在一起，围绕可移植性和互操作性构建规范和项目。CDF的下一步是什么？接下来的步骤是启动治理结构。将成立一个理事会、技术和外联/营销委员会。我们计划在未来几个月内实现这一目标，并邀请新成员加入我们的社区。如果你有兴趣加入社区推进CD，请到https://cd.foundation/members…。CNCF的参与程度，为什么需要一个单独的基金会？首先要注意的是，CD适用于整个软件行业，而不仅仅适用于现代云原生应用程序。CNCF（Cloud Native Computing Foundation，云计算本地计算基金会）是CDF的姐妹基金会，拥有自己的治理结构和使命。每个基金会都有不同的使命，由其创始成员和技术专家定义。CNCF认为大多数与CD相关的工具超出了他们专注的云原生定义的范围，后者主要关注容器化、微服务、服务网格和编排。CDF超越云和容器，包括传统基础设施、移动、物联网、裸机等。CNCF和CDF都属于较大的Linux基金会旗下，计划在许多领域进行合作，包括同场会议。例如，CDF将于5月20日在西班牙巴塞罗那的KubeCon + CloudNativeCon Europe 2019举办持续交付峰会（CDS）活动。CDF如何支持或与DevOps领域的其他玩家合作？CDF的使命是为开发者、最终用户和供应商提供一个中立的家庭，以便在CI/CD方法上进行协作。在这方面，CDF将通过发布关注可移植性的最佳实践、培训材料和行业指南来支持DevOps从业者。有兴趣成为这个新基金会成员并制定治理方案的组织应到CDF加入的页面。开发者可以在此处注册CD基金会邮件列表：info@lists.cd.foundation。任何有兴趣加入CDF的项目都可以联系技术监督委员会（TOC）：https://github.com/cdfoundati…。KubeCon + CloudNativeCon + Open Source Summit大会日期：会议日程通告日期：2019 年 4 月 10 日会议活动举办日期：2019 年 6 月 24 至 26 日KubeCon + CloudNativeCon + Open Source Summit赞助方案KubeCon + CloudNativeCon + Open Source Summit多元化奖学金现正接受申请KubeCon + CloudNativeCon和Open Source Summit即将首次合体落地中国KubeCon + CloudNativeCon + Open Source Summit购票窗口，立即购票！CNCF邀请你加入最终用户社区 ...

3月12日，在加州Half Moon Bay举行的开源领导者峰会（Open Leadership Summit 2019 ）上，CDF（Continuous Delivery Foundation )持续交付基金会正式宣告成立。灵雀云以全球首批创始成员身份获邀加入，也是中国区三大创始成员之一，另外两家为华为和阿里。CDF基金会隶属于Linux基金会，Linux基金会是一个通过开源实现大规模创新的非营利组织，为多样化的持续集成和交付（CI / CD）领域奠定了新的基础。CDF基金会将作为一个中立的家园，为最重要的开源项目提供持续交付和规范，以加快发布流程。CDF创始成员包括灵雀云、阿里巴巴、Anchore、Armory.io、Atos、Autodesk、Capital One、CircleCI、CloudBees、DeployHub、GitLab、Google、HSBC、华为、IBM、JFrog、Netflix、Puppet、Rancher、Red Hat、SAP、Snyk和SumoLogic等。入驻CDF基金会的第一批项目将包括Jenkins、Jenkins X、Spinnaker以及Tekton。其他项目将通过即将成立的技术监督委员会（TOC）加入CDF基金会，其重点是将CD持续交付生态系统整合在一起，以围绕可移植性和源代码库建立规范和项目。CDF基金会将促进行业顶级开发人员，最终用户和供应商之间的协作，以传播CI / CD方法论，定义/记录最佳实践，并创建培训材料，以使全球任何软件开发团队能够实施CI / CD最佳实践。灵雀云是以容器技术为基础的新一代PaaS平台领军企业，是国内推动云原生落地的重要力量。围绕应用的全生命周期管理，帮助企业客户快速构建云原生应用，实现微服务架构改造及 DevOps 落地。在云原生DevOps领域，灵雀云致力于打造开放式的DevOps工具链集成与编排平台。平台可以灵活兼容客户的工具选型，通过集成将各类工具串联起来，形成一套工具链，通过编排实现DevOps工具链与容器平台联动，形成一个完整系统。同时，不断结合自身的经验，提炼DevOps落地最佳实践，将最佳实践自动化，作为服务进行输出。灵雀云CTO陈恺表示：“寻求持续创新的现代组织需要高度自动化、灵活性和一致性的软件交付流程。我们很高兴看到CDF基金会的成立。它将培育一个充满活力的社区，促进文化转变、方法论、最佳实践以及工具链生态的建设，使组织能够持续地交付价值。我们期待为这一使命作出贡献。“

本文作者： CODING 用户 - 何健这次实战篇，我们借助「CODING 持续集成」，实现一个简单的 Spring Boot 项目从编码到最后部署的完整过程。本教程还有 B 站视频版，帮助读者更好地学习理解。思路在线上环境构建、测试、部署这种情况，通常会将 jenkins 安装在服务器上，确保构建测试等操作环境和线上环境一致。此时通常会在 jenkins 中配置好需要持续集成的仓库，以及具体流程。这种方式非常简单粗暴，也非常有效，但是缺点也很明显。可能 jenkins 会成为线上环境的旁站漏洞，这是非常不安全的。那么，我们就需要更高级的方式，可以线上环境之外的构建测试，最终部署到线上环境。「CODING 持续集成」正是提供这类持续集成模式的平台。不在实际部署服务器上构建、测试为了避免占用线上服务器的资源，也为了避免安全问题，我们可以使用单独的 jenkins (或者其它此类软件)完成构建、测试、分发，实际部署通过单独的 webhook 实现。这样就可以避免在线上环境安装 Jenkins，还可以避免更复杂的系统安全维护。这样做的优点：不会影响在线服务；缺点：部署地机器最好是可以公网访问的，否则会无法完成后续分发步骤。终极解决方案：使用 SaaS 化的 JenkinsSoftware as a Service，软件即服务。「CODING 持续集成」集成了 SaaS 化的 Jenkins 等主流企业开发流程工具，实现了 DevOps 流程全自动化。开箱即用，直接用它就好！捋一下思路我们这次实战针对后一种思路检出代码构建测试分发触发部署实战实际体验，还是很不错的。视频地址：CODING 持续集成 - Spring Boot 项目第一步：初始化一个持续集成1、首先，我们需要进入准备持续集成的项目。这里我用 start.spring.io 初始化一个 demo 示例项目，并推送到仓库。为了方便大家，亲自体验，我准备了一个现成的仓库，可以直接 git clone 下来再 git push 到自己账户下使用。仓库地址：demoForCI2、解压 demo 项目，进入 demo 目录，初始化仓库。 cd g:\demo\ git init git set remote giturl git add ./ git commit -m ‘init repo’ git push -u origin master别忘了 git config user.name yourname 和 git config user.email youremail3、开始体验仓库准备好后，就可以开始体验「CODING 持续集成」。第一次的使用，需要先创建一个 Jenkinsfile，很多小伙伴会说，第一次用，不知道是啥。没关系，「CODING 持续集成」已经给我们准备好了模板，非常容易理解，可以认为是特定格式语法写一套 task 流程。点击一下 “简易模板”，更具实际情况修改一下就可以。第二步：编写 Jenkinsfile为了方便理解，我们从简易模板开始，分别修改对应阶段的任务。1、配置构建环境，「CODING 持续集成」目前支持 java-8、python-3.5、ruby-2.3、go-1.11 等等。在 Jenkinsfile 的 pipeline 里添加: agent { // 此处设定构建环境，目前可选有 // default, java-8, python-3.5, ruby-2.3, go-1.11 等 // 详情请阅 https://dev.tencent.com/help/knowledge-base/how-to-use-ci#agents label “java-8” }2、检出这里不得不说，「CODING 持续集成」这里做的还是很方便的，提供了适用于好几种不同场景的模板。默认简易模板是带有检出部分的，我们可以根据实际情况进行修改。默认情况下，env.GIT_BUILD_REF 的值就是 master 主分支，实际上我们可以定制为其它专门用于构建发的分支。这里，大家可以自己修改具体要检出的分支。 stage(“检出”) { steps { sh ‘ci-init’ checkout( [$class: ‘GitSCM’, branches: [[name: env.GIT_BUILD_REF]], userRemoteConfigs: [[url: env.GIT_REPO_URL]]] ) } }3、构建 stage(“构建”) { steps { echo “构建中…” sh ‘java -version’ sh ‘mvn package’ echo “构建完成.” archiveArtifacts artifacts: ‘/target/.jar’, fingerprint: true // 收集构建产物 } }这里需要注意，Spring Boot 的 pom 中需要添加一个插件。修改后： <plugins> <plugin> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-maven-plugin</artifactId> </plugin> <!– 下面是添加的插件 –> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-surefire-plugin</artifactId> <version>2.6</version> <configuration> <skipTests>true</skipTests> </configuration> </plugin>4、测试这里我偷个懒，只做了单元测试，没有提取测试报告，大家可以根据实际项目定制这个流程。 stage(“测试”) { steps { echo “单元测试中…” sh ‘mvn test’ echo “单元测试完成.” //junit ’target/surefire-reports/.xml’ // 收集单元测试报告的调用过程 } }5、分发 jar 包到目标服务器这里比较无奈，我没有单独针对这次演示写部署 jar 包和上传 jar 包的 webhookApi，但是构建好的 jar 包需要要放置到待部署的服务器。于是有了这个过程，借助 scp 和私钥来上传构建好的jar包。这里千万记着提前部署好密钥。并且将密钥放到仓库一份，用于分发jar包。 stage(“分发jar包”) { steps { echo “分发中…” echo “chmod 600 pkey” sh ‘chmod 600 authorized_keys.pem’ echo “upload” sh ‘scp -i authorized_keys.pem ./target/*.jar root@yourip:/root/’ echo “准备部署” } }6、部署前面有提到，这里部署仍然需要触发一个钩子，否则只能手动部署了。这里我写了一个最简单的，实际上我们可以写细致一点，判断一下接口返回的结果再根据结果输出部署情况。 stage(“部署”) { steps { sh ‘curl http://youapi’ echo “部署完毕” } }第三步：保存 Jenkinsfile 并运行修改好 Jenkinsfile 和 pom.xml。我们要保存 Jenkinsfile，编辑框可以直接编辑内容，编辑好可以直接提交到仓库下的 ./Jenkinsfile 接下来， 平台会自动读取 Jenkinsfile 并开始走持续集成的流程：持续集成的流程是可以看到的：每个阶段都对应 Jenkinsfile 一个 stage， 我们可以点击查看对应阶段的构建结果。第四步：排查持续集成的报错如果某个过程出错，「CODING 持续集成」的流程会停止，并提示失败。此时我们可以进入具体节点查看具体失败原因。比如现在是提示“分发 jar 包失败”，那么我们可以点击对应节点展开看看日志，排查具体分发失败的原因。现在可以清晰地看到，报错原因是我没有填写正确的主机 ip。文中涉及的文件及代码Jenkinsfilepipeline { agent { // 此处设定构建环境，目前可选有 // default, java-8, python-3.5, ruby-2.3, go-1.11 等 // 详情请阅 https://dev.tencent.com/help/knowledge-base/how-to-use-ci#agents label “java-8” } stages { // 检出仓库 stage(“检出”) { steps { // 这里sh调用ci-init 初始化 sh ‘ci-init’ // 这里检出仓库，默认检出分支为环境变量中的GIT_BUILD_REF checkout( [$class: ‘GitSCM’, branches: [[name: env.GIT_BUILD_REF]], userRemoteConfigs: [[url: env.GIT_REPO_URL]]] ) } } // 构建jar包 stage(“构建”) { steps { echo “构建中…” // 输出java版本 sh ‘java -version’ // 调用maven 构建jar包 sh ‘mvn package’ echo “构建完成.” //收集构建产物，这一步成功，我们就可以在平台上看到构建产物 archiveArtifacts artifacts: ‘/target/.jar’, fingerprint: true // 收集构建产物 } } // 测试 stage(“测试”) { steps { echo “单元测试中…” // 做单元测试 sh ‘mvn test’ echo “单元测试完成.” } } // 分发jar包，这里只是简单的通过scp分发jar包到目标机器指定目录 stage(“分发jar包”) { steps { echo “分发中…” echo “chmod 600 pkey” sh ‘chmod 600 authorized_keys.pem’ echo “upload” sh ‘scp -i authorized_keys.pem ./target/.jar root@youip:/root/’ echo “准备部署” } } // 部署jar包 stage(“部署”) { // 这里需要触发一个部署的webhook，可以是一个很简单的重启java进程的操作 steps { // 用curl 来触发hook sh ‘curl http://baidu.com’ echo “请登录服务器手动部署” } } }}pom.xml文中所用 Spring Boot 示例项目的 pom.xml实际上，大家可以直接去 start.spring.io 参考照这份 pom 来创建一个 demo。<?xml version=“1.0” encoding=“UTF-8”?><project xmlns=“http://maven.apache.org/POM/4.0.0" xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation=“http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> <modelVersion>4.0.0</modelVersion> <parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>2.1.2.RELEASE</version> <relativePath/> <!– lookup parent from repository –> </parent> <groupId>tech.hejian</groupId> <artifactId>codingj8</artifactId> <version>0.0.1-SNAPSHOT</version> <name>codingj8</name> <description>coding project for Spring Boot</description> <properties> <java.version>1.8</java.version> </properties> <dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-devtools</artifactId> <scope>runtime</scope> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-test</artifactId> <scope>test</scope> </dependency> </dependencies> <build> <plugins> <plugin> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-maven-plugin</artifactId> </plugin> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-surefire-plugin</artifactId> <version>2.6</version> <configuration> <skipTests>true</skipTests> </configuration> </plugin> </plugins> </build></project>总结CODING 是一个面向开发者的云端开发平台，提供 Git/SVN 代码托管、任务管理、在线 WebIDE、Cloud Studio、开发协作、文件管理、Wiki 管理、提供个人服务及企业服务，其中「CODING 持续集成」集成了 SaaS 化的 Jenkins 等主流企业开发流程工具，实现了 DevOps 流程全自动化，为企业提供软件研发全流程管理工具，打通了从团队构建、产品策划、开发测试到部署上线的全过程。 ...

目的对于小组内部PHP代码进行定期检测及分发1. 需要定期从svn 或者git拉取指定代码2. 对代码库内部门模块进行隔离或者删除，不参与检测3. 为小组内人员定期发送邮件，4. 可分配具体bug 给具体小组内人员jenkins安装及安装插件1. sonar搭建可以参考 [之前文章：sonarqube For PHP 代码质量管理][1]2. jenkins环境搭建：略过3. jenkins 插件安装：略过 - SonarQube Scanner for Jenkins - Localization: Chinese (Simplified) - Email Extension Template Plugin效果图首页有任务视图视图执行 定时邮件发送 指定bug分配通知到指定人 sonar notify系统管理-系统设置（全局设置和路径）sonar配置基本配置邮件插件配置默认邮件配置我的视图-具体项目配置构建选项及工作空间等设置源码管理（git svn 等任君配）定时功能（可以点击蓝问号）pull代码后剔除无关代码执行sonar配置，与cli 执行sonar的properties文件一致，-X为debug模式邮件内容配置，我此处只是把固定项目的sonar 地址写在邮件里，可以选择增加附件（attachments），也可以增加模版（templates）sonarqube中通知（notification）配置创建用户（组）分配项目，提醒 设置关注项目及事件分配给具体人自动化rm -rf /cd /var/lib/jenkins/workspace/sonar_svn_trunk/cctrunkrm -rf assetsrm -rf cssrm -rf jsrm -rf templaterm -rf imagesrm favicon.icorm robots.txtcd /var/lib/jenkins/workspace/sonar_svn_trunk/trunk/app/librariesls |grep -v platform | xargs rm -rfcd /var/lib/jenkins/workspace/sonar_svn_trunk/trunk/apprm -rf third_partyrm -rf viewsrm -rf languagefind . -name ‘index.html’ | xargs rm -rffind . -name ‘.pem’ | xargs rm -rffind . -name ‘.conf’ | xargs rm -rf ...

背景公司的前端项目部署方式比较简单，整个过程基本上是手动的；目标通过工具实现以下几个任务：编译、部署自动化；选择指定版本进行回滚；区分不同的分支（环境）；技术方案选用 jenkins 作为部署工具；也便于后续 CI 的接入；使用 docker 进行编译，确保每次编译的环境的稳定；步骤步骤一：搭建 Jenkins搭建 Jenkins 有很多方案，这里选择使用 docker 搭建。docker-compose.yml 的内容如下：version: ‘3’services: fejenkins: user: root image: jenkinsci/blueocean ports: - “8080:8080” - “50000:50000” volumes: - /data/jenkins_home:/var/jenkins_home - /data/nm_cache:/var/nm_cache - /var/run/docker.sock:/var/run/docker.sock通过 docker-compose up 命令启动；启动后通过初始密码进行第一个用户的创建和 Jenkins 初始化的一些列操作，初始密码会打印在 jenkins docker 启动命令行的输出中，注意查看。当然也可以不使用 docker-compose：docker run –rm -u root -v /data/jenkins_home:/var/jenkins_home -v /data/nm_cache:/var/nm_cache -v /var/run/docker.sock:/var/run/docker.sock -p 8080:8080 -p 50000:50000 jenkinsci/blueocean稍做解释：/data/jenkins_home:/var/jenkins_home /var/jenkins_home 是 jenkinsci image 的默认数据存放路径，这里将路径映射到宿主机的指定文件夹；/data/nm_cache:/var/nm_cache nm_cache 涵义是 node_modules cache，顾名思义，这里是想对编译所需的 node_modules 做缓存，将缓存文件夹也映射到宿主机；/var/run/docker.sock:/var/run/docker.sock 这里是将宿主机运行 docker 后产生的 sock 文件映射到了 jenkins container 中。这样，jenkins 中使用 docker 进行编译时，其实是使用宿主机的 docker 来运行的，而不是在 docker container 中又启动了 docker。这里稍微有点绕，若是暂时看不明白，需要找一些深入介绍 docker 的文章阅读；步骤二：配置 Jenkins添加 Credentials通过 Jenkins 进行 git 操作需要对应 git repo 的权限，这里需要用到有 git repo 权限的密钥文件。同样，通过 Jenkins 将编译产物 scp 到服务器上的时候，也需要服务器的密钥文件。这两类密钥文件需要配置在 Jenkins 中，在：Jenkins > Credentials > System > Global credentials (unrestricted) 里进行 Add Credentials 的操作。添加 Jenkins ItemJenkins > New Item，然后选择 Pipeline，在下面的 Pipeline 配置区域的 Definition 中选择 Pipeline script，Script 如下：pipeline { environment { SERVER_IP_1 = “11.22.33.44” SERVER_CREDENTIALSID = “abcd1234-abcd-abcd-abcd-abcd1234abcd” SERVER_DEPLOY_DIR = “/your/www/path/” CACHE_DIR = “/var/nm_cache/your_project_name/” GIT_URL = “git@github.com:example/example.git” GIT_BRANCH = “master” GIT_CREDENTIALSID = “abcd1234-abcd-abcd-abcd-abcd1234abcd” } agent none stages { stage(‘Checkout code’) { agent any steps { git ( branch: “${GIT_BRANCH}”, credentialsId: “${GIT_CREDENTIALSID}”, url: “${GIT_URL}”, changelog: true ) sh ’’’ ls -al cache_dir="${CACHE_DIR}" cache_nm="${CACHE_DIR}node_modules" cache_lock="${CACHE_DIR}yarn.lock" if [ ! -d “$cache_dir” ]; then mkdir ${cache_dir}; fi if [ ! -d “$cache_nm” ]; then mkdir ${cache_nm}; fi if [ -d “$cache_nm” ]; then ln -sf ${cache_nm} ./; fi if [ -f “$cache_lock” ]; then mv -n ${cache_lock} .; fi ls -al ’’’ } } stage(‘Build’) { agent { docker { image ’node:8-alpine’ args ’’ } } steps { sh ’’’ npm config set registry https://registry.npm.taobao.org yarn install yarn build tar -cvf build.tar build ls -al mv ./yarn.lock ${CACHE_DIR} rm -rf ./node_modules ls -al ’’’ archiveArtifacts artifacts: ‘build.tar’, fingerprint: true } } stage(‘Deploy’) { agent any steps { unarchive mapping: [‘build.tar’: ‘build.tar’] echo ‘— Deploy —’ sshagent(["${SERVER_CREDENTIALSID}"]) { sh “scp -o StrictHostKeyChecking=no build.tar root@${SERVER_IP_1}:${SERVER_DEPLOY_DIR}” sh “ssh -o StrictHostKeyChecking=no root@${SERVER_IP_1} "rm -rf ${SERVER_DEPLOY_DIR}build; tar -xvf ${SERVER_DEPLOY_DIR}build.tar -C ${SERVER_DEPLOY_DIR}"” } } } }}稍做解释：这个部署脚本分为三个步骤：Checkout code（在指定 git 仓库通过指定证书文件获取代码）Build（通过指定命令进行编译，将编译后的产物存档）Deploy（通过指定命令部署）在 Build 阶段前后，我们各做了一些工作，以求每次部署可以复用 node_modules，因为下载 node_modules 的时间可能很长，而并不是每次都会修改 package.json，所以其实 node_modules 大概率可以复用；编译前：看指定 node_modules 缓存文件夹是否存在，不存在则新建该文件夹；看缓存文件夹中是否有 node_modules 文件夹，如果没有则新建该文件夹；并且将该文件夹软连接到当前目录；看缓存文件夹中是否有 yarn.lock 文件，如果有则移动到当前文件夹；编译后：移除 node_modules 文件夹的软连接；将 yarn.lock 文件移动到缓存文件夹中；这里使用了 yarn install 的某些特性：没有 node_modules 或者 yarn.lock 时会安装全量依赖；有 node_modules 和 yarn.lock 但是 yarn.lock 和 package.json 不匹配时，会安装所需依赖；有 node_modules 和 yarn.lock，且 yarn.lock 和 packge.json 配置时，跳过安装依赖；使用编译和部署编译和部署直接点击 Build Now 即可；回滚回滚的本质其实是：重新部署某个历史版本。在 Build History 找到想要重新部署的版本，点击 Restart from Stage，在新页面中选择 Stage Name 为 Deploy。其他若是想要进入 docker container 交互，可以通过以下命令docker exec -i -t [dockername] /bin/bash ...

配置Jenkins可选插件时插件列表显示为空，并提示如下报错解决办法如下：1.在同页面打开“advance”标签；2.设置“Update Site”为“http://mirror.xmission.com/je…”3.点击“check now”；再回到“available”标签页，就会看到可选插件列表不再为空了。

随着项目进展接近尾声，服务端自动化部署也逐渐提上日程。按照初期想法，采用 Jenkins 实现自动化部署。Jenkins 是开源 CI/CD 软件领导者， 提供超过1000个插件来支持构建、部署、自动化， 满足任何项目的需要。顺便插播一句广告，欢迎参与 Jenkins 中文本地化建设。配置需求1c 2g 服务器 1 台尝试 Vultr、Amazon aws 和阿里云 ECS 后，得出结论：若 Git Provider 为 GitHub，由于网络原因，应选用 Vultr 等 VPS 或 aws 等国外服务器。但价格相对较国内云提供商较贵，若使用 1c 1g 服务器在构建中服务器容易崩溃。Gitee 是国内连接速度最快的 Git Provider，但 Jenkins 对于 Gitee 的插件支持少。所以采用 GitLab + 阿里云 Ecs 解决方案。在明确需求之后，则需要参考官方文档着手部署 Jenkins 服务器。服务器准备gitJenkins 需要从 GitLab 向 Jenkins 服务器拉取代码。jdk1.8Jenkins 需要运行在 Java 8 环境下maven该项目需要使用 Maven 打包Jenkins 插件Maven IntegrationJenkins 需要创建一个 Maven ItemPublish Over SSH在 mvn 打包后需要部署到目标服务器上GitLab Plugin需要从 GitLab 拉取项目GitLab Hook Plugin配置 GitLab 触发器Jenkins 配置配置好插件后，需要对 Jenkins 进行一定的配置。Publish Over SSH 配置Manage Jenkins->Configure System 找到 Publish Over SSH 。在 SSH Servers 中 Add 一个 SSH Server，正确填写项目部署服务器信息。点击 Advanced，勾选 Use password authentication, or use a different key，正确填写密码，测试并保存。项目配置新建项目选择 Maven Project，Source Code Management 选择 Git，填入项目地址，账户信息以及目标分支。配置触发器。在 Build Triggers 中选择 Build when a change is pushed to GitLab，记下后面 GitLab webhook URL，根据需求配置 Advanced 中信息。配置构建后动作。在 Post-build Actions 中选择已配置好的服务器，根据实际情况填写 Transfers 中信息。e.g. Source files ： */workhelper.jar，Jenkins 会找到目录下符合该正则表达式的文件。Remove prefix ： target/，通常 Maven 打包后文件都会在 target 目录下。Remote directory： 空，该目录相对于 Publish Over SSH 中配置的 Remote Directory 。Exec command：/root/project/startup.sh，部署后命令，是项目传输后运行的脚本。GitLab 配置GitLab 项目中 Settings->Integrations，URL 填写上文记录的 GitLab webhook URL，根据需求选择触发器，点击 Add webhook Jenkins 中 Manage Jenkins->Configure System 找到 GitLab，取消 Enable authentication for ‘/project’ end-pointJenkinsfile 样例Jenkins 需要找到项目中的 Jenkinsfile 才能按照需求工作，Jenkinsfile 位于项目根目录下。node { checkout scm echo “current branch: $BRANCH_NAME” if (BRANCH_NAME.startsWith(“jenkins”)) { sh “mvn clean install” }}这里 Jenkinsfile 使用 Groovy 语法。脚本样例在项目通过 Publish Over SSH 传输到服务器上之后，需要一定的操作才能正确部署。#!/usr/bin/env bashkill -9 $(netstat -nlp | grep :8848 | awk ‘{print $7}’ | awk -F"/" ‘{ print $1 }’)# cd targetnohup java -jar workhelper-0.0.1-SNAPSHOT.jar > log.file 2>&1 &这里使用 shell 脚本运行服务。 ...

前言Jenkins就不用做多余的介绍了，作为CI/CD首选的开源解决方案，持续集成 (Continous Intergration)/ 持续交付 (Continous Delievery)，本文只是用于记录使用Jenkins的一些基本操作，Jenkins官方文档也率先支持中文，相信对大家的学习热情会有积极地促进作用。Jenkins学习使用实践更新历史2019年02月12日 - 初稿阅读原文 - https://wsgzao.github.io/post…扩展阅读Jenkins - https://jenkins.io/zh/Jenkins简介构建伟大，无所不能Jenkins 是开源 CI&CD 软件领导者， 提供超过 1000 个插件来支持构建、部署、自动化，满足任何项目的需要。Jenkins 用户手册 - https://jenkins.io/zh/doc/Jenkins 训练营之基础篇 - https://ke.qq.com/course/265167Jenkins 训练营之带你玩转 Pipeline - https://ke.qq.com/course/252785https://ke.qq.com/webcourse/i...https://ke.qq.com/webcourse/i...Jenkins安装Jenkins 项目产生两个发行线，长期支持版本 (LTS) 和每周更新版本。 根据你的组织需求，一个可能比另一个更受欢迎。两个版本都以 .war 文件，原生包，安装程序，和 Docker 容器的形式分发。https://jenkins.io/zh/download/这里推荐下载使用LTS长期支持版本，以 CentOS 7 作为演示环境# Java 8yum install java# Jenkins stable versionsudo wget -O /etc/yum.repos.d/jenkins.repo https://pkg.jenkins.io/redhat-stable/jenkins.reposudo rpm –import https://pkg.jenkins.io/redhat-stable/jenkins.io.keyyum install jenkins# start jenkinsservice jenkins start# 初始化配置向导http://192.168.56.103:8080/cat /var/lib/jenkins/secrets/initialAdminPassword5224fc83b6d84cc2be69a18c53309ea4Install suggested plugins是否创建管理员账户或者跳过Jenkins入门主要的Job类型Freestyle project 自由风格项目，Jenkins最主要的项目类型Maven Project Maven项目专用，类似 Freestyle，更简单Multi-configuration project 多配置项目，适合需要大量不同配置(环境，平台等)构建Pipeline 流水线项目，适合使用pipeline(workflow)插件功能构建流水线任务，或者使用Freestyle project不容易实现的复杂任务Multibranch Pipeline 多分支流水线项目，根据SCM仓库中的分支创建多个Pipeline项目Freestyle 项目General项目基本配置项目名字，描述，参数，禁用项目，并发构建，限制构建默认node等等Source code Management代码库信息，支持Git，Subversion等Build Triggers构建触发方式周期性构建，Poll SCM，远程脚本触发构建，其他项目构建结束后触发等Build Environment构建环境相关设置构建前删除workspace，向Console 输出添加时间戳，设置构建名称，插入环境变量等Build项目构建任务添加 1个或者多个构建步骤Post-build Actions构建后行为Artifact 归档，邮件通知，发布单元测试报告，触发下游项目等等规范项目必要配置本规范尤其适用于较多项目共用同一Jenkins的场景项目命名规范设置项目描述设置历史构建清理规则设置构建节点Label邮件通知常用插件注意Jenkins备份策略，建议结合rsync备份远端Jenkins定时的备份:ThinBackup邮件发送插件: Email Extension Plugin空间清理扩展插件: Distributed Workspace Clean pluginJenkins常用插件 – https://vwin.github.io/2019/0…创建第一个Job安装Timestamper插件系统管理-插件管理-可用插件，搜索到timestamper点击Install without restart新建一个Freestyle类型的JobGeneral 项目名称: My-first-freestyle-demoBuild Environment 构建环境:勾选 Add timestamps to the Console OutputBuild 构建:屏幕打印出 “这是我的第一个Jenkins Job, oops “Post-build Actions 构建后操作:无点击立刻构建找到控制台输出Console Output14:40:59 Started by user admin14:40:59 Building in workspace /var/lib/jenkins/workspace/My-first-freestyle-demo14:41:00 [My-first-freestyle-demo] $ /bin/sh -xe /tmp/jenkins3737737887278720679.sh14:41:00 + echo ‘这是我的第一个Jenkins Job, oops ‘14:41:00 这是我的第一个Jenkins Job, oops 14:41:00 Finished: SUCCESSJenkins Pipeline介绍Pipeline，简而言之，就是一套运行于Jenkins上的工作流框架，将原本独立 运行于单个或者多个节点的任务连接起来，实现单个任务难以完成的复杂流程编排与可视化。Pipeline 是Jenkins2.X最核心的特性，帮助Jenkins实现从CI到CD与DevOps的转变什么是Jenkins Pipeline?Jenkins Pipeline是一组插件，让Jenkins可以实现持续交付管道的落地和实施。持续交付管道(CD Pipeline)是将软件从版本控制阶段到交付给用户或客户的完 整过程的自动化表现。软件的每一次更改(提交到源代码管理系统)都要经过一个复杂的过程才能被发布。Pipeline提供了一组可扩展的工具，通过Pipeline Domain Specific Language(DSL) syntax可以达到Pipeline as Code的目的Pipeline as Code:Jenkinsfile 存储在项目的源代码库Jenkins Pipeline核心概念Stage– 阶段，一个Pipeline可以划分为若干个Stage，每个Stage代表一组操作，例如: “Build”, “Test”, “Deploy” 。– 注意，Stage是一个逻辑分组的概念，可以跨多个Node。 Node– 节点，一个Node就是一个Jenkins节点，或者是Master，或者是Agent，是执行Step的具体 运行环境。Step– 步骤，Step是最基本的操作单元，小到创建一个目录，大到构建一个Docker镜像，由各类 Jenkins Plugin提供，例如: sh ‘make’为什么要用Pipeline?代码:Pipeline以代码的形式实现，通常被检入源代码控制，使团队能够编辑，审查和迭代其CD流程。可持续性:Jenkins重启或者中断后都不会影响Pipeline Job。停顿:Pipeline可以选择停止并等待人工输入或批准，然后再继续Pipeline运行。多功能:Pipeline支持现实世界的复杂CD要求，包括fork/join子进程，循环和 并行执行工作的能力。可扩展:Pipeline插件支持其DSL的自定义扩展以及与其他插件集成的多个选项。Pipeline和Freestyle的区别Freestyle:– 上游 / 下游Job调度，如 BuildJob ->TestJob -> DeployJob– 在DSL Job里面调度多个子Job(利用Build Flow plugin)Pipeline:– 单个Job中完成所有的任务编排– 全局视图Pipeline 会取代Freestyle么?Pipeline一定会取代Build Flow插件会，当你希望做到Pipeline as code的时候会，当你独立运行一组Job没有特殊价值或者意义的时候会，当你可以从Multibranch Pipeline受益的时候会，当你希望获取类似于TravisCI风格的工作流的时候Jenkins Pipeline入门Pipeline脚本是由Groovy语言实现 – 无需专门学习GroovyPipeline支持两种语法– Declarative 声明式(在Pipeline plugin 2.5中引入)– Scripted Pipeline 脚本式如何创建基本的Pipeline– 直接在Jenkins Web UI 网页界面中输入脚本– 通过创建一个Jenkinsfile可以检入项目的源代码管理库最佳实践– 通常推荐在 Jenkins中直接从源代码控制(SCM)中载入Jenkinsfile Pipeline快速创建一个简单的 Pipeline新建Job: Jenkins -> 新建 -> 输入 Job名称: “My-first-pipeline-demo” -> 选择 Pipeline -> 点击 “OK"配置: 在Pipeline -> Script 文本输入框中输入下列语句，点击 ”保存”立即构建pipeline { agent any stages { stage(‘Build’) { steps { echo ‘Build’ } } stage(‘Test’) { steps { echo ‘Test’ } } stage(‘Deploy’) { steps { echo ‘Deploy’ } } }}Jenkins忘记密码怎么办如果权限设置错误，或者忘记密码，导致admin自己都无法登陆Jenkins怎么办?命令行停止Jenkins;先备份$JENKINS_HOME中的config.xml;用编辑器打开$JENKINS_HOME中的config.xml;将<useSecurity>true</useSecurity>元素中的true改为false;将<authorizationStrategy>和<securityRealm>元素的内容删掉;命令行启动Jenkins。Ansible Jenkins API Token 使用技巧Jenkins REST API 提供了 API token，使得可以在程序中使用 API token 进行认证（而不是使用你真实的密码）。API token 可以在用户个人设置界面查看到用户→用户 id→设置页面，在 API Token 区域点击 Show API token 按钮，便可查看 API token，同时还可以更改 API token相应的 URL 是 http://&lt;JENKINS_URL>/user/<userid>/configureManage Jenkins jobs by using Jenkins REST APIjenkins_job_facts – Get facts about Jenkins jobshttps://docs.ansible.com/ansi…jenkins_job – Manage jenkins jobshttps://docs.ansible.com/ansi…# python-jenkins packagepip install python-jenkins# ansble playbook example—- hosts: all gather_facts: no tasks: - name: Get host info local_action: module: jenkins_job_facts url: https://xxx user: xxx token: xxx glob: ‘mh_kg’ register: my_jenkins_job_facts - debug: msg: “{{my_jenkins_job_facts}}“参考内容官方手册永远是你的最佳参考内容Jenkins 用户手册 - https://jenkins.io/zh/doc/ ...

有了前几篇的基础后，我们现在已经能docker 篇：构建 docker 镜像上传私有仓库拉取私有镜像启动容器jenkins 篇：配置 pipeline触发 pipeline接下来就可以结合两者，用 jenkins + docker 来自动化部署我们的项目。配置 Jenkinsjenkins 的配置思路为构建机（IP: xx.xx.xx.xx）拉取代码构建机安装依赖构建机运行测试构建机打包并上传镜像至私有镜像仓库部署机（IP: yy.yy.yy.yy）拉取镜像部署机重启服务对应 pipeline 配置如下pipeline { agent any stages { stage(‘Update’) { steps { sh """ npm install """ } } stage(‘Test’) { steps { sh “npm test” } } stage(‘Build’) { steps { sh """ docker build -t localhost:5000/wool-digger-api:$BUILD_NUMBER . docker push localhost:5000/wool-digger-api:$BUILD_NUMBER """ } } stage(‘Deploy’) { steps { sh """ ssh -o stricthostkeychecking=no root@xx.xx.xx.xx " source /etc/profile docker pull yy.yy.yy.yy:5000/wool-digger-api:$BUILD_NUMBER docker rm -f wool-digger-api docker run -d –name=wool-digger-api –network host yy.yy.yy.yy:5000/wool-digger-api:$BUILD_NUMBER " """ } } }}BULID_NUMBER在 Build 和 Deploy 环节里，使用了 $BUILD_NUMBER 这个变量来作为镜像的 tag，这个变量是 jenkins 的系统变量之一，代表当前的构建号，每次构建这个号会加一，所以可以作为我们镜像的 tag。其他系统变量可 在此查看。Network这里使用 docker run 命令的时候，加入了 –network 参数，这个参数用来指定 Docker 容器运行的网络，默认为 bridge，即桥接模式。这种模式下在容器内通过 localhost 是访问不到宿主机的。如果指定为 host 则容器与宿主机共用网络，就无需使用 -p 命令映射端口了。这种模式下会破话隔离性，这里是为了在容器内方便地连接宿主机的 mysql 和 redis，推荐将 mysql 和 redis 也使用 docker 运行，host 值可作为一种临时解决方案。配置 Dockerdocker 的配置无需做太多修改FROM node:10.15.0-alpineMAINTAINER sunhengzhe@foxmail.comCOPY . /app/WORKDIR /appRUN npm install pm2 -gEXPOSE 1337CMD [“pm2-runtime”, “pm2/production.json”]这里的基本镜像使用了 node 的 alpine 版本，alpine 是面向安全的轻型 Linux 发行版，它的体积非常小。目前 Docker 官方已开始推荐使用 Alpine 替代之前的 Ubuntu 做为基础镜像环境。这样会带来多个好处。包括镜像下载速度加快，镜像安全性提高，主机之间的切换更方便，占用更少磁盘空间等。其他删除镜像如果需要批量删除镜像，可以使用docker rmi $(docker images | grep ‘镜像名’ | awk ‘{print $3}’) 持久化日志如上篇提到的，可以通过 -v 挂载容器内日志目录到宿主机。 ...

Syncd是一款开源的代码部署工具，它具有简单、高效、易用等特点，可以提高团队的工作效率。项目地址(Github) 项目地址(Gitee) 下载地址 v1.1.0 使用文档特性：Go语言开发，编译简单、运行高效Web界面访问，交互友好灵活的角色权限配置支持Git仓库分支、tag上线部署hook支持完善的上线工作流邮件通知机制更新内容安装脚本通过go env获取GOPATH #8utf8 to utf8mb4 #13支持go modules #4压缩登录背景图 #5添加服务器支持填入域名 #3解决没有添加集群的时候添加项目出错 #7提供二进制安装包

流水线视图可以很直观地看到每一步执行的时间和进度，方便追踪部署过程中的每一个环节。搭建 jenkins 参考 上一篇文章工作流本文目的是搭建一个简单的 pipeline，当 git 仓库有提交时，builder server 进行构建和测试，完成之后 deploy server 进行部署。本地 -> SCM: 提交代码SCM -> Build Server: 触发 jenkins 任务Build Server: 启动 pipelineBuild Server -> Deploy Server: 部署服务SCM Source Code Management，如 githubBuild Server jenkins 所在机器，负责构建Deploy Server 线上服务所在机器新建 Task首先创建一个 Task，然后选择流水线模板配置Pipeline在这里可以配置 pipeline 的脚本，definition 可以选择 Pipeline script 或 Pipeline script from SCM。选择前者后，jenkins 脚本需要在下方填写，当任务启动后，jenkins 会执行这里配好的命令；选择后者后，任务启动后，jenkins 会去执行 SCM 仓库下配置的 script path 下的脚本。一句话说，两者区别在于脚本是写在 jenkins 配置里，还是写在你的代码仓库里。所以修改脚本的时候在 jenkins 里配就行，方便调试，没问题之后使用 SCM 管理更好。编写 pipeline script以 node 服务举例，部署过程分为四步：Build: 在 build server 上 npm installTest: 在 build server 上进行测试Deploy: 在 deploy server 上部署这个脚本如下，需要将 [user] 和 [ip] 替换成 deploy server 的登录用户和 ip：pipeline { agent any stages { stage(‘Build’) { steps { sh “npm install” } } stage(‘Test’) { steps { sh “npm test” } } stage(‘Deploy’) { steps { sh """ ssh -o stricthostkeychecking=no [user]@[ip] " source /etc/profile cd /root/projects/my-api-server git pull npm install pm2 reload wool-digger-api " """ } } }}当然这是一个很粗糙的构建方式，我们下次使用 docker 进行改造。主要概念有agent 指示 Jenkins 分配一个执行器和工作空间来执行下面的Pipelinestage 表示这个 Pipeline 的一个执行阶段，对应流水线中各个环节steps 表示在这个 stage 中每一个步骤sh 命令用来执行一条 shell 语句。 这个配置文件被执行后：首先 jenkins 会在工作区（一般来说在 ~/.jenkins/workspace/）下拉取配置仓库指定分支的代码pull 成功后进行 npm install（Build）build 成功之后进行 npm test（Test）test 成功后远程执行一段脚本，即登录 deploy server 并 cd 到服务目录，然后进行服务的更新重启操作。npm/pm2 not found 的问题注意上面 Deploy 中有一行 source /etc/profile，这是 login shell 和 no-login shell 的不同。如果使用 ssh 登录再执行命令和脚本，用户会获得 login shell，shell 首先会加载 /etc/profile 文件，然后依次尝试 /.bash_profile、/.bash_login 和 ~/.profile。而如果直接使用 ssh 远程执行命令和脚本，如上面的 ssh -o，它不会去执行 /etc/profile 文件，而会去用户的 HOME 目录检查 .bashrc 并加载。所以在 /etc/profile 中设置的 path 不会生效。如果 nvm 在此文件中，那么 node、npm、pm2 等等就找不到了。解决方法可以在 shell 脚本中先手动加载配置文件。Build Triggers在这里可以配置 pipeline 触发的类型Github hook trigger fro GITScm polling启动该项后可以通过 GitHub 的 webhook 来触发，参考 Github Plugin 文档这里说一下最简单的配置，即手动配置。在 Jenkins -> 系统管理 -> 系统设置中，可以找到 Git 配置，点击右边的问号按钮，可以看到默认的 jenkins hook 地址。一般来说默认都是 $JENKINS_BASE_URL/github-webhook/。拿到这个地址后，添加到 github 的 webhook 中。注意 这个地址是没有项目信息的，因为 github 调用这个 hook 地址时，会把仓库信息传过去，所以就只剩在 jenkins 中把 pipeline 和这个 git 仓库关联起来。这需要在 pipeline 中选择 Pipeline script from SCM 并填写 git 地址。轮询 SCM启动该项后，jenkins 将定时对 SCM 仓库进行轮询，当仓库有新提交时，会自动触发 pipeline。Schedule 填写规则与 crond 类似，如 H/5 * * * * 代表每 5 分钟查询一次。详细规则可以点击右边的问号。启动点击 立即构建，或去仓库提交一个 commit（如果配置了 github hook），或提交一个 commit 并等待（如果配置了轮询 SCM），然后就能看到我们的第一个 pipeline 启动了！ ...

本文在 centos 版本 7.4.1708 与 7.6.1810 中验证查看 centos 版本# lsb_release命令用来查看当前系统的发行版信息lsb_release -a# 或查看 centos-release 文件cat /etc/centos-release安装 java 8本地下载，然后传到服务器访问 oracle jdk 下载地址，同意协议后点击下载地址下载完成后，登录服务器，新建 /usr/java 目录，然后在本地 scp 过去# 服务器mkdir /usr/java# 本机scp [jdk所在目录]/jdk-8u192-linux-x64.tar.gz [user]@[ip]:/usr/java/直接在服务器上下载因为下载 jdk 需要同意协议，所以不能用 wget 直接下载，需要添加 header。下面命令适用于下载上图中 jdk 版本。需要根据版本替换下面的 download 页面和 jdk 下载地址。参考 stackoverflow上图版本地址为: https://download.oracle.com/o...mkdir /usr/javacd /usr/javawget –no-cookies –no-check-certificate –header “Cookie: gpw_e24=http%3a%2F%2Fwww.oracle.com%2Ftechnetwork%2Fjava%2Fjavase%2Fdownloads%2Fjdk8-downloads-2133151.html; oraclelicense=accept-securebackup-cookie;” “https://download.oracle.com/otn-pub/java/jdk/8u192-b12/750e1c8617c5452694857ad95c3ee230/jdk-8u192-linux-x64.tar.gz"安装1. 解压cd /usr/javatar zxvf jdk-8u192-linux-x64.tar.gz2. 配置环境变量vim /etc/profile添加以下内容，需要把内容中的 jdk1.8.0_192 替换为自己的安装版本名JAVA_HOME=/usr/java/jdk1.8.0_192JRE_HOME=/usr/java/jdk1.8.0_192/jreCLASS_PATH=.:$JAVA_HOME/lib/dt.jar:$JAVA_HOME/lib/tools.jar:$JRE_HOME/libPATH=$PATH:$JAVA_HOME/bin:$JRE_HOME/binexport JAVA_HOME JRE_HOME CLASS_PATH PATH重新生效环境配置source /etc/profile测试 java 是否安装成功java -version安装 jenkins可以直接参考 官方教程下载最新稳定版：wget http://mirrors.jenkins.io/war-stable/latest/jenkins.war启动java -jar jenkins.war –httpPort=8080.然后访问服务器 8080 端口，按界面操作即可。第一次访问需要输入密码，界面上会有提示，一般存放在 ~/.jenkins/secrets/initialAdminPassword注意这个过程可能比较长，所以后台运行 jenkins 会比较好nohup java -jar jenkins.war –httpPort=8088 >/root/jenkins/logs/out.log & ...

持续集成的定义大师 Martin Fowler 是这样定义持续集成的: 持续集成是一种软件开发实战, 即团队开发成员经常集成他们的工作. 通常, 每个成员每天至少集成一次, 也就意味着每天可能发生多次集成.持续集成并不能消除Bug, 而是让它们非常容易发现和改正.根据对项目实战的理解, 持续集成中的 “持续” 是指不间断的; “集成” 可分为广义和狭义, 广义的集成指软件各个过程的集成, 包括开发、部署、测试等. 狭义的集成即代码和代码之间的集成, 从而保证代码合并不冲突.每次集成都通过自动化的构建 (包括编译、发布和自动化测试) 来验证, 从而尽快的发现集成错误. 许多团队都发现这个过程可以大大减少代码集成的问题, 让团队更快的开发内聚的软件. 请注意, 持续集成不等于持续编译.当前软件开发过程存在的问题在没有应用持续集成之前，传统的开发模式是这样的：项目一开始是先划分好模块，分配模块给相应的开发人员；开发人员开发好一个模块就进行单元测试；等所有的模块都开发完成之后，由项目经理对所有代码进行集成；集成后的项目由项目经理部署到测试服务器上，被交由测试人员进行集成测试；测试过程中出现 Bug 就提把问题记录进行 Bug 列表中；项目经理分配 Bug 给相应的责任人进行修改；修改完成后，项目经理再次对项目进行集成，并部署到测试服务器上；测试人员在下一次的集成测试中进行回归测试；通过通过之后就部署到生产环境中；如果测试不通过，则重复上述“分配 Bug -> 修改 Bug -> 集成代码 -> 部署到测试服务器上 -> 集成测试”工作。这个过程中可能会出现如下问题:Bug 总是在最后才发现随着软件技术的发展, 软件规模也在扩大, 软件需求越来越复杂, 软件已经不能简单地通过划分模块的方式来开发, 往往需要在项目内部互相合作, 模块之间存在一定的依赖关系, 那么早期就存在的 Bug 往往会在最后集成的时候才被发现.越到项目后期, 问题越难解决很多开发者需要在集成阶段花费大量的时间来寻找 Bug 的根源, 加上软件的复杂性, 问题的根源很难定位. 而且我们都清楚, 间隔的时间越久, Bug 修复的成本越高, 因为连开发人员自己都忘了当初写得是什么鬼代码, 从而不得不从头阅读代码、理解代码.软件交付时机无法保障正是因为我们无法及时修复 Bug, 或者是没能在早期就修复 Bug, 从而令整个修复 Bug 的周期拉长了. 不管怎么样, 我们不可能把明知存在 Bug 的软件交付给客户.而且, 大量没有在前期预估到的工作量产生了——开发人员不得不花费大把时间在查找 Bug 上; 测试人员不断的需要进行回归测试; 项目经理不得不疲命于该死的代码的集成、部署这些重复性工作——最终导致整个项目的周期拉长, 交付时间点往后拖.程序经常需要变更某些项目, 程序会经常需要变更. 由于产品经理在与客户交流过程中, 往往实际的软件就是最好的原型, 所以软件会被当作原型作为跟客户交流的工具. 当然, 客户最希望的当然是客户的想法能够马上反映到原型上, 这会导致程序会经常被修改的. 那么也就意味着“分配 Bug -> 修改 Bug -> 集成代码 -> 部署到测试服务器上 -> 集成测试”工作无形又爆增了.无效的等待变多有可能开发在等集成其他人的模块; 测试人员在等待开发人员修复 Bug; 产品经理在等待新版本上线好给客户做演示; 项目经理在等待其他人提交代码. 不管怎么样, 等待意味低效.用户的满足度低这里的用户是广义的, 可以指最终的客户, 也可以是产品经理、公司领导、测试人员, 甚至可能是开发人员自己. 你想想看, 本来三个月做完的项目被拉长到了九个月甚至一年, 用户能满意吗! 产品经理、公司领导经常需要拿项目作为演示的原型, 结果告诉我在演示前一刻发现还有很多 Bug 没有解决, 项目启动不了无法访问, 这叫人情何以堪.怎么样才算是“持续”对于一天需要集成多少次数, 并没有一个明确的定义. 一般就是按照自己项目的实际需要来设置一定的频率, 少则可能几次, 多则可能达几十次. 可以设置按照代码的变更来触发集成, 或者设置一个固定时间周期来集成, 也可以手工点击集成的按钮来 “一键集成”.持续集成的工作流程当开始更改代码时，开发人员会从代码库（如 SVN、Git 等）获取当前代码库的副本.当其他开发人员将更改的代码提交到代码库时, 此副本将逐渐停止反映代码库中的代码. 代码分支保持检出的时间越长, 当开发人员分支重新集成到主线时, 多个集成冲突和故障的风险就越大.当开发人员向代码库提交代码时, 他们必须首先更新他们的代码, 以反映代码库中的最新更改.当存储库与开发人员的副本不同, 他们必须要花时间来先处理冲突.持续集成的好处解放了重复性劳动自动化部署工作可以解放了集成、测试、部署等重复性劳动, 而且机器集成的频率明显可以比手工的高很多.更快地修复问题由于持续集成更早的获取变更, 更早的进入测试, 也就能更早的发现问题, 解决问题的成本显著下降.更快地交付成果及早集成、及早测试减少了缺陷遗留到部署环节的机会. 在某些情况下, 更早地查找错误还会减少解决错误所需的工作量.如果集成服务器对代码进行构建过程中发现错误, 可以及时发送邮件或者短信提供给开发人员进行修复.如果集成服务器在部署环节发现当前版本有问题不可用, 集成服务器会将部署回退到上一个版本. 这样服务器上始终都会有一个可用的版本.减少手工的错误人与机器的一个最大的区别是, 在重复性动作上, 人容易犯错, 而机器犯错的几率几乎为零. 所以, 当我们搭建完成集成服务器后, 以后的事就交给集成服务器来打理吧.减少了等待时间持续集成缩短了从开发、集成、测试、部署各个环节的时间, 从而也就缩短了中间可以出现的等待时间. 持续集成, 意味着开发、集成、测试、部署也得以持续.更高的产品质量集成服务器往往提供 Code review、代码质量检测等功能. 对代码不规范或者有错误的地方会进行标识, 也可以设置邮件、短信等进行告警. 而开发人员通过 Code review 也可以持续提高编程的能力. ...

基于kubernetes+docker+jenkins的DevOps实践之前自己的项目开发就搭了个cicd的环境，那时候是在本就小的可怜的服务器上搭了一套 jenkins + docker registry + docker 见之前的笔记 docker学习下面 总的差不多这样: 之后对kubernetes的接触后，就在之前的基础上加入kubernetes,其实也就是在服务器拉取镜像docker run的时候改变为通知kubernetes的apiServer对提前配置好的项目配置文件xx.yaml进行更新kubectl appply -f xx.yaml，它会对配置里的镜像拉取在多个pod里运行，当然还需要对应的service，如果需要暴露给外部还可以添个ingress。 一个小服务器加本地一个闲置从机撑进去这么多东西很显然爆了，于是把jenkins , docker registry拆出来，用上了公共的ali云服务CodePipeline,容器镜像服务。 这里记录一下。docker搭建ubuntu安装docker官方教程kubernetes搭建之前写的kubernetes学习下面有使用ali云CodePipeline替代jenkins创建任务配置->项目名称：最好为github上代码的demo项目名称,这里以bootshiro为例配置->源码管理->Git：URL为github上的项目clone url,下面默认master分支配置->构建触发器->填写代码分支：eg:master 点击生成触发器地址留下备用(github webhook配置会用到)配置->构建项目类型可选maven项目 node python等(按自己需求改编译打包册测试脚本)eg: maven项目 编译打包: mvn package -B -DskipTests 用例测试: mvn test配置->镜像构建和发布: 这里使用ali云的免费docker镜像仓库镜像版本号最好用jenkins环境变量标记,registry地址证书等就是自己开通的ali云registry地址和账户,docker路径是相对于当前代码仓库的Dcokerfile文件路径,用这个Dockefile文件来生成镜像。eg: bootshiro的Dockefile#VERSION 1.1.0#基础镜像为openjdk:12-alpineFROM openjdk:12-alpine#签名MAINTAINER tomsun28 “tomsun28@outlook.com"RUN rm -rf /opt/running/bootshiro*ADD ./target/bootshiro.jar /opt/running/bootshiro.jarEXPOSE 8080WORKDIR /opt/running/CMD [“java”, “-jar”, “bootshiro.jar”,”–spring.profiles.active=prod"]配置->部署Kubernetes(新): 这里配置对搭建好的k8s环境的apiServer连接,之后好使用apiServer对kubernetes操作认证方式：选择认证证书API服务器地址：为apiServer通讯地址证书：使用docker授权模式,客户端Key(key.pem)和客户端证书(cert.pem)在/etc/kubernetes/admin.conf,服务端CA证书(ca.pem)在/etc/kubernetes/pki/ca.crt部署配置文件：为k8s部署这个项目的配置文件位置，也是以当前项目代码仓库为相对路径,eg :bootshiro.yaml# ———————-bootshiro——————— ## ——bootshiro deployment—— #kind: DeploymentapiVersion: apps/v1beta2metadata: name: bootshiro-deployment labels: app: bootshirospec: replicas: 1 selector: matchLabels: app: bootshiro template: metadata: labels: app: bootshiro spec: containers: - name: nginx image: registry.cn-hangzhou.aliyuncs.com/tomsun28/bootshiro:${BUILD_NUMBER} ports: - containerPort: 8080—# ——-nginx-service——— #apiVersion: v1kind: Servicemetadata: name: bootshiro-servicespec:# type: NodePort ports: - name: server port: 8080 targetPort: 8080 selector: app: bootshiro# !———————-bootshiro——————— #这里配置部署文件创建了一个pod实例，创建了与其想对应的service在集群内部暴露服务。如果部署的应用需要对集群外提供服务，这里还要创建对应的暴露服务的方式，如ingress, nodeport等-到此cicd就差不多了，我们开发代码push到github仓库上，跟着DevOps流程走，最后项目就会自己运行到kubernetes集群里面了，pod挂了或者从机挂了，k8s会重新启保证设定数量的pod。使用ingress对集群外暴露服务这里使用的是traefik-ingress,在kubernetes中部署traefik有官方部署手册，基本按着走一遍就能部署上去了。 整合部署的traefik.yaml:—kind: ClusterRoleapiVersion: rbac.authorization.k8s.io/v1beta1metadata: name: traefik-ingress-controllerrules: - apiGroups: - "" resources: - services - endpoints - secrets verbs: - get - list - watch - apiGroups: - extensions resources: - ingresses verbs: - get - list - watch—kind: ClusterRoleBindingapiVersion: rbac.authorization.k8s.io/v1beta1metadata: name: traefik-ingress-controllerroleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: traefik-ingress-controllersubjects:- kind: ServiceAccount name: traefik-ingress-controller namespace: kube-system—apiVersion: v1kind: ServiceAccountmetadata: name: traefik-ingress-controller namespace: kube-system—kind: DaemonSetapiVersion: extensions/v1beta1metadata: name: traefik-ingress-controller namespace: kube-system labels: k8s-app: traefik-ingress-lbspec: template: metadata: labels: k8s-app: traefik-ingress-lb name: traefik-ingress-lb spec: serviceAccountName: traefik-ingress-controller terminationGracePeriodSeconds: 60 containers: - image: traefik name: traefik-ingress-lb ports: - name: http containerPort: 80 hostPort: 80 - name: admin containerPort: 8080 securityContext: capabilities: drop: - ALL add: - NET_BIND_SERVICE args: - –api - –kubernetes - –logLevel=INFO—apiVersion: v1kind: Servicemetadata: name: traefik-web-ui namespace: kube-systemspec: selector: k8s-app: traefik-ingress-lb ports: - name: web port: 80 targetPort: 8080—apiVersion: extensions/v1beta1kind: Ingressmetadata: name: traefik-web-ui namespace: kube-system annotations: kubernetes.io/ingress.class: traefik traefik.frontend.rule.type: PathPrefixStripspec: rules: - host: tom.usthe.com http: paths: - path: /ingress backend: serviceName: traefik-web-ui servicePort: web使用traefik来暴露service:apiVersion: extensions/v1beta1kind: Ingressmetadata: name: chess namespace: default annotations: kubernetes.io/ingress.class: traefik traefik.frontend.rule.type: PathPrefixStripspec: rules: - host: tom.usthe.com http: paths: - path: /usthe backend: serviceName: usthe-service servicePort: http - path: /nginx backend: serviceName: nginx servicePort: http转载请注明 from tomsun28 ...

本文以部署 Spring boot + Maven 项目为例，使用码云作为代码托管仓库，在 CentOS 7 上搭建 Jenkins 持续集成环境。1. 准备工作1.1 安装 Java 环境Jenkins 是基于 Java 开发的持续集成工具，需要在 Java 环境下运行。用下面命令查看系统是否已安装 Java：yum list installed | grep jdk如果没有，使用 yum search 命令查找 openjdk 版本，选择合适的 jdk 进行安装：yum search openjdk yum -y install java-1.8.0-openjdk-devel验证 Java 是否安装成功：java -version1.2 安装 Maven依次运行以下两条命令：wget http://repos.fedorapeople.org… -O /etc/yum.repos.d/epel-apache-maven.repo yum -y install apache-maven验证 Maven 是否安装成功：mvn -v1.3 安装 Git直接通过 yum 安装，安装完成后查看版本验证是否安装成功：yum -y install git git –version2. 安装和配置 Jenkins：2.1 安装 Jenkins依次运行以下三条命令：sudo wget https://pkg.jenkins.io/redhat… -O /etc/yum.repos.d/jenkins.repo sudo rpm –import https://pkg.jenkins.io/redhat… yum -y install jenkins如果之前从 Jenkins 导入过 key，那么 rpm –import 将失败，因为已经有一个 key 了。忽略它，继续执行 install 即可。2.2 启动 Jenkins启动 Jenkins，并且设置开机自启动：systemctl start jenkins.service chkconfig jenkins onJenkins 默认使用8080端口，访问以下链接即可看到 Jenkins 的 Web 界面：http://&lt;服务器地址>:8080如果无法访问，检查一下防护墙，是否有开放端口，或使用命令 netstat -ntulp 查看端口是否被占用。2.3 进入 Jenkins首次进入 Jenkins 需要输入管理员密码，使用以下命令查看初始密码：cat /var/lib/jenkins/secrets/initialAdminPassword选择默认的 install suggested plugins 安装插件，等待安装完成后依照步骤创建用户，创建完成后即可登入。2.4 配置 Jenkins进入 Manage Jenkins -> Global Tool Configuration，依次配置 JDK、Git 和 Maven 路径。2.4.1 查看 JDK 路径使用 yum 安装的软件不会帮我们配置环境变量，直接使用命令echo $JAVA_HOME 是看不到路径的。 先用以下命令查看路径：which java看到的结果是 /usr/bin/java ，但实际上这只是个软连接，并不是 JDK 真正的所在目录。 继续使用以下命令查看：ls -l /usr/bin/java看到 /usr/bin/java 指向了 /etc/alternatives/java，很遗憾，还不是我们要找的真正路径。 继续追踪：ls -l /etc/alternatives/java结果指向了 /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.191.b12-1.el7_6.x86_64/jre/bin/java，不同版本的 JDK 目录名可能有些不同，这就是 JDK 真正所在的地方。 同理可获得 Maven 的所在路径。2.4.2 安装和配置插件进入 Manage Jenkins -> Manage Plugins，搜索并安装 Publish Over SSH 和 Maven Integration 两个插件， Git Plugins 插件已经默认安装上了，我们无需再安装。配置 SSH 免密码登录 在配置插件之前，我们先在 Jenkins 服务器上生成密钥对。运行以下命令切换到 jenkins 用户：sudo su jenkins如果无法切换，则打开 /etc/passwd 文件，找到 jenkins 那一行，将 /bin/fasle 改成 /bin/bash。 切换成功后，命令提示符的用户名可能是 bash-4.2$，想要正常显示用户名的话，先切换回 root 用户，执行以下操作：编辑文件 vi /.bash_profile 加入语句 export PS1=’[u@h W]&dollar;’ 立即生效 source /.bash_profile再切换到 jenkins 用户，就显示正常了。接下来运行以下命令生成密钥对：ssh-keygen -t rsa一路按回车完成，会在 /var/lib/jenkins/.ssh/ 目录下生成 id_rsa 和 id_rsa.pub两个文件。 将 id_rsa.pub 文件里的内容追加到应用服务器上的 /root/.ssh/authorized_keys 文件末尾，每行一个 key，注意是应用服务器。重启应用服务器上的 ssh 服务：systemctl restart sshd.service现在 Jenkins 可以免密码登录应用服务器了，以 jenkins 用户身份运行命令来测试一下：ssh root@<应用服务器地址>首次连接会有确认提示，输入 yes 即可。这步很重要，如果第一次没有手动连接确认，Jenkins 会连不上。配置 Public over SSH 插件 进入 Manage Jenkins -> Configure System，填写 Publish over SSH 设置。Path to key：填写刚刚生成的 id_rsa 密钥文件的路径。 Name：服务名，随意填写。 HostName：应用服务器的 IP 地址或域名。 Username：登录应用服务器的用户身份。 Remote Directory：远程目录， 应用服务器上存放应用的目录，Jenkins 会把应用拷贝至此目录下。请确保此目录存在。save3. 部署 Maven 项目点击 New Item 新建任务，随意输入任务名，选择 Maven project, ok。 在General，勾选 Discard old builds，可以设置最多保留构建文件多少天，和最多保留多少个构建文件，不然每次构建生成的文件都会保留，占用磁盘空间。 配置远程代码仓库地址，Jenkins 会从该地址拉取代码。注意此处如果提示无法读取仓库，有可能是：公钥没有添加到远程代码服务器的 authorized_keys 文件里，上面配置 SSH 免登录是 Jenkins 访问应用服务器的，Jenkins 访问代码服务器也同样需要配置，除非应用服务器和代码服务器是同一台机器。如果使用码云或 GitHub 等代码托管平台，会有相应的 SSH key 设置页。公钥已添加到相应文件里，但没有手动连接第一次。解决方法很简单，以 jenkins 用户身份手动 clone 一次仓库，确认 yes 即可。勾选 Add timestamps to the Console Output，在控制台输出构建过程。填写 Maven 打包指令，-DMaven.test.skip=true 表示跳过测试。勾选 Run only if build succeeds，选择 Send files or execute commands over SSH。接下来就是设置 build 完之后，把 jar 包从 Jenkins 服务器拷贝到应用服务器上，并运行。Name：选择之前创建的服务。 Source files：maven 打包后生成的 jar 包，即要拷贝到应用服务器运行的程序，可填多个，英文逗号分隔。 Remove prefix：忽略前缀，我们只需要拷贝 target 下的 jar 包，不需要在应用服务器上生成 target 目录。 Remote directory：目标文件夹，会继承全局设置，例如此处会把 jar 包拷贝到 /usr/local/app/demo 目录下。 Exec command：拷贝完成后，在应用服务器上执行的命令或脚本。save -> build now，构建成功后，打开浏览器访问你的站点吧4. 总结其实整个流程不是很复杂，Jenkins 从远程代码库拉取代码 -> 调用 maven 指令将项目打包 -> Jenkins 将打包好的文件拷贝到远程应用服务器 -> 在远程应用服务器上执行 shell 指令，启动程序。其中 Jenkins 两次远程操作都是通过 SSH 完成的。 通过 yum 安装 Jenkins 和 Java 比较方便，但是在配置的时候相对麻烦，安装路径要自己找，配置 SSH 的时候也是要用 jenkins 用户身份，而不是 root，如果采用解压缩包的方式就比较自由一些。 ...

概要Code Coverage API plugin 是 Jenkins 在 GSoC 2018 中的一个子项目。GSoC 是一个由谷歌举办的，帮助在校学生进入开源社区，为开源组织贡献代码的活动。 在这个项目中，我的 mentor 是 Steven Christou, Supun Wanniarachchi, Jeff Pearce 和 Oleg Nenashev。 目前在Jenkins中，有很多插件都实现了代码覆盖率工具的接入，例如 Cobertura Plugin, Jacoco Plugin, Clover Plugin…但是这些插件的配置项，结果页展示的图表和显示的内容都是类似的。 因此，相对于现在的为每一个代码覆盖率工具都从头编写一个新的插件，我们能提供一个 API 插件将会大大减少开发者的工作量。这个 API 插件将处理那些最重复的工作，将其封装成不同的抽象层，并提供易于使用的 API 接口让其它插件去实现。 支持的代码覆盖率工具 内置 JaCoCo 其它实现了 Code Coverage API plugin 的插件 Cobertura (Cobertura Plugin) llvm-cov (llvm-cov Plugin)Features现代化的图表 代码覆盖率变化趋势图 支持源代码浏览 支持 Pipeline 和 Parallel Pipeline 支持 Report combining 提供 REST API 灵活的 Failed Conditions现代化的图表在概要表中我们可以看到当前位置的代码覆盖率概况。在子概要表中，看到每一个子项的代码覆盖率情况。同时，使用右上角的 range handler 可以筛选出我们想要看到的项来减小表的大小。通过点击节点的名字可以进入子项的详情页，来看到更多的关于子项代码覆盖率的信息。代码覆盖率变化趋势图我们也支持代码覆盖率趋势图，来显示 Build 之间的代码覆盖率变化趋势。源代码浏览通过设置 Source File Storing Level 为 save last build source files(将会在当前和上一次Build的结果页中显示源码) 或者 save all build source files (在所有Build的结果页中显示源码) 来启用源代码浏览。 之后我们就可以在 File 元素的节点中看到源代码以及与之相关联的代码覆盖率信息。Pipeline 和 Parallel PipelineAPI 插件提供 Pipeline 和 Parallel Pipeline 的支持，你可以在不同的 Branch 中调用插件: node { parallel firstBranch: { publishCoverage adapters: [jacocoAdapter(’target/site/jacoco/jacoco.xml’)] }, secondBranch: { publishCoverage adapters: [jacocoAdapter(‘jacoco.xml’)] } }Reports Combining通过给 publishCoverage 设置 tag，把含有相同 tag 的报告结合为一个报告。 node { parallel firstBranch: { publishCoverage adapters: [jacocoAdapter(’target/site/jacoco/jacoco.xml’)], tag: ‘t’ }, secondBranch: { publishCoverage adapters: [jacocoAdapter(‘jacoco.xml’)], tag: ‘t’ } } REST API我们提供 REST API 供其它应用获取覆盖率信息。 覆盖率: …/{buildNumber}/coverage/…/result/api/{json|xml} 覆盖率变化: …/{buildNumber}/coverage/…/trend/api/{json|xml} 上一次Build的覆盖率: …/{buildNumber}/coverage/…/last/result/api/{json|xml} 上一次Build的覆盖率变化: …/{buildNumber}/coverage/…/last/trend/api/{json|xml}灵活的 Failed Conditions我们可以在 Global 和 Adapter 级别为不同的元素设置失败条件来控制 Build 的结果。假如代码覆盖率符合失败的条件，插件将会使当前的 Build 失败。其他功能我们也支持其它一些像是自动检测报告，筛选覆盖率这样的功能，在插件的文档中可以找到 更多的信息。架构插件在运行过程中主要会做下面几个事情: 根据用户的配置找到代码覆盖率报告文件 使用 Adapter 将报告文件转化为统一的标准格式 解析标准格式的报告文件并并合并它们 显示解析后的结果 所以，我们可以简单编写一个 Adapter 来实现一个新的代码覆盖率工具。这个 Adapter 只需要做一件事，将其它格式的代码覆盖率报告转化为我们插件的标准格式。Adapter的实现方式基于 ExtensionPoint，所以我们可以将 adapter 的实现分离到不同的插件中，插件将会自动发现它们。 同时，为了简化转化的过程，我们也提供了一系列的抽象层。The below diagram show the architecture of Code Coverage API plugin实现一个新的代码覆盖率插件我们通过实现CoverageReportAdapter这个 extension point 来实现一个新的插件。通过使用我们插件提供的抽象层，我们可以像下面这样的简单来实现 JaCoCo: public final class JacocoReportAdapter extends JavaXMLCoverageReportAdapter {@DataBoundConstructorpublic JacocoReportAdapter(String path) {super(path);}/{@inheritDoc}*/@Overridepublic String getXSL() {return “jacoco-to-standard.xsl”;}/{@inheritDoc}*/@Overridepublic String getXSD() {return null;}@Symbol(“jacoco”)@Extensionpublic static final class JacocoReportAdapterDescriptor extends JavaCoverageReportAdapterDescriptor {public JacocoReportAdapterDescriptor() {super(JacocoReportAdapter.class);}@Nonnull@Overridepublic String getDisplayName() {return Messages.JacocoReportAdapter_displayName();}}复制代码} 在这里我们只做了两件事，实现了为 Java XML 报告编写的抽象层，提供了一个将 JaCoCo 报告转化为我们标准格式的 XSL 文件。 假如你想要实现一个我们没有提供抽象层的代码覆盖率工具，你还需要注册 CoverageElement 并实现一个简单的 Parser。可参考 llvm-cov Plugin，更多的信息参见插件的 GitHub wiki page。 附文中链接： Code Coverage API plugin：jenkins.io/projects/gs… Steven Christou：github.com/christ66 Supun Wanniarachchi：github.com/Supun94 Jeff Pearce：github.com/jeffpearce Oleg Nenashev：github.com/oleg-nenash… Cobertura Plugin：github.com/jenkinsci/c… llvm-cov Plugin：github.com/jenkinsci/l… repo：github.com/jenkinsci/c… ...

运行环境CentOS 6.5ansible 2.6.8系统自带python2.6用户为 root问题/解决最近试用了一下 ansible 的 jenkins_job 模块，在这里整理一下我遇到的问题和解决方法。首先是模块的官方文档 https://docs.ansible.com/ansi…根据官方文档，需要运行 jenkins_job 的目标机器需要安装2个依赖，分别是：python-jenkins >= 0.4.12lxml >= 3.3.3首先说 lxml ，如果直接使用系统默认 python 的 pip 安装，安装过程中会报错:error: command ‘gcc’ failed with exit status 1在网络上查询一般的解决办法都会告知需要安装 libxml2 和 libxslt 的开发套件，也就是yum install -y libxml2-devel libxslt-devel但是如果你的系统是新的系统或者非常的“干净”的话，你会发现安装完成之后仍然不能 pip install lxml ，这时还需要安装 python-develyum install -y python-devel安装完成之后就可以正常使用 pip 安装 lxml 了pip install lxml下面说 python-jenkins ，直接使用 pip 安装上 python-jenkins 后并不能使用，调用 ansible 的 jenkins_job 模块或者直接在目标主机上的 python 中 import jenkins 会报语法错误，像这样：Traceback (most recent call last): File “<stdin>”, line 1, in <module> File “/usr/lib/python2.6/site-packages/jenkins/init.py”, line 59, in <module> import requests File “/usr/lib/python2.6/site-packages/requests/init.py”, line 43, in <module> import urllib3 File “/usr/lib/python2.6/site-packages/urllib3/init.py”, line 8, in <module> from .connectionpool import ( File “/usr/lib/python2.6/site-packages/urllib3/connectionpool.py”, line 92 _blocking_errnos = {errno.EAGAIN, errno.EWOULDBLOCK} ^SyntaxError: invalid syntax在网络上查询到报错的原因是 python-jenkins 最新版本并不支持 python2.6 ，解决方法就是安装旧版本的 python-jenkins ，这里就选 jenkins_job 要求的最低版本 0.4.12 就好：pip uninstall python-jenkinspip install python-jenkins==0.4.12这时再在目标主机的 python 中 import jenkins 不会报语法错误了，只会提示一个 “UserWarning: Support for python 2.6 is deprecated and will be removed.” 即将不再支持 python2.6 ，这个版本能支持那么就一直使用这个版本好了。使用方法解决了 jenkins_job 模块的问题使之可以调用了之后，下面我们来看看如何使用这个模块。根据官网文档的描述，可以使用这个模块对 jenkins 的 job 进行 创建/删除/禁用/启用 的操作，认证方式可以使用 jenkins 的用户名加密码/token 的方式。下面放个简单的例子用于禁用某项目：—- hosts: localhost gather_facts: no vars: tasks: - name: “disable jenkins job” jenkins_job: url: http://you.jenkins.domainname:port user: yourusername password: yourpassword name: “jenkins_job_name” enabled: False启用/禁用/删除 和选择密码还是 token 登录都非常好理解，下面看一下官方创建项目的例子：# Create a jenkins job using basic authentication- jenkins_job: config: “{{ lookup(‘file’, ’templates/test.xml’) }}” name: test password: admin url: http://localhost:8080 user: admin其他字段都非常好理解，只有 config 字段是获得了 templates/test.xml 这个文件的内容，而对于这个文件里的内容，并没有更多的解释。这部分应该属于 jenkins 定义的范围。不知道是很少人使用还是我搜索的方法不对，我并没有很容易的找到关于这个 xml 文件怎么定义的文档，但是我查到其实这个 xml 就是你的 jenkins 目录下的 jobs/yourJobName/config.xml 。所以最简单的方法就是在 jenkins 上创建好需要的 job 然后复制出这个 config.xml 文件，这样你就得到了你需要的 config 字段中的内容，也可以在其中修改一些值，改一个现有的配置文件总比从零开始写要容易。config 字段除了使用 “{{ lookup(‘file’,‘xxxx.xml’) }}” 的形式之外，还可以使用 “{{ lookup(’template’, ‘xxxx.xml.j2’) }}” 将 xml 文件改成 jinja2 模板，这样就可以使用 ansible 的变量动态生成 job 了。 ...

Jenkins 非常灵活，如今已成为实现 CI/CD 的事实标准，同时拥有一个活跃的社区来维护几乎所有工具和用例的插件。但是灵活也是要付出代价的：除了 Jenkins 核心之外，许多插件需要一些系统级别的设置才能正常工作。在某些情况下，“Jenkins 管理员”是一个全职职位。Jenkins 管理员在负责维护基础设施的同时，还要为一个巨大的 Jenkins master 提供数百个已安装的插件和数千个托管作业。维护最新的插件版本是一项挑战，故障转移（failover）也会是一场噩梦。这就像几年前系统管理员必须要为每个服务管理特定的机器一样。在 2018 年，通过使用基础架构自动化工具和虚拟化，一切都可以作为代码进行管理。需要一个新的应用服务器作为你的应用的暂存环境吗？那你只需要部署一个 Docker 容器。基础设施缺少资源吗？那就在你喜欢的云服务上分配更多资源来使用 Terraform。在这种情况下，Jenkins 管理员的角色怎么样？他们是否还要花费数小时来点击网页表单上的复选框？也许他们已经采用了一些自动化、依赖于 Groovy 脚本或一些自己写的 XML 模板。今年早些时候我们发布了第一个 alpha 版本的 “Jenkins Configuration-as-Code” （JCasC），它是一种基于 YAML 配置文件和自动模型发现的 Jenkins 配置管理新方法。Jenkins 已经升级为 Jenkins 顶级项目。 同时，对应的 Jenkins 增强提案已经被接受。JCasC 能为 Jenkins 管理员做些什么？JCasC 允许我们在启动时或通过 web UI 按需在 Jenkins master 上应用一组 YAML 文件。与 Jenkins 用于实际储存配置的详细 XML 文件相比，这些配置文件非常简洁易读。这些文件还有用户友好的命名约定，使管理员能够轻松地配置所有 Jenkins 组件。下面是一个例子：jenkins: systemMessage: “Jenkins managed by Configuration as Code"securityRealm: ldap: configurations:server: ldap.acme.comrootDN: dc=acme,dc=frmanagerPasswordSecret: ${LDAP_PASSWORD}cache: size: 100ttl: 10userIdStrategy: CaseInsensitivegroupIdStrategy: CaseSensitive如你所见，不需要很长的解释你就可以理解这个 YAML 文件如何配置你的 Jenkins master。优点JCasC 最直接的好处就是可重复性。管理员现在可以使用完全相同的配置通过一个简单的设置来引导新的 Jenkins master。这允许他们创建一个测试实例并检查升级插件在沙盒环境中的影响。这也使他们对故障转移和灾难恢复方案更有信心。当管理员开始在源代码管理中管理 Jenkins 的 YAML 配置文件时，他们也会感受到类似使用 Terraform 一样的好处。这样做可以让他们对 Jenkins master 配置进行审核，使其具有可逆性。他们可以建立一个合理的配置改变运行 Jenkins 实例的工作流，并确保在实际应用任何修改到他们的 Jenkins master 之前配置是健康的。最后也是最重要的是，由于能够快速设置 Jenkins master 并且能用一组共享的 YAML 配置文件控制它们，管理员现在可以给每个团队提供一个 Jenkins 实例，并且在安装插件有更高的灵活性。只要他们还在使用 Jenkinsfiles 管理构建定义（build definition），master 就会或多或少地成为你们团队的短期的基础架构。使用 Configuration-as-Code，我们可以不再像对待宠物那样对待我们的 Jenkins master，而像对待牛那样管理它们，你也可以毫不费力地替换它们。欢迎来到 “as-code” 的世界。他们仍然很可爱，对吧?Ok, 那么之后呢?你可以在项目中阅读有关 Jenkins Configuration-as-Code 插件的更多信息。与社区和贡献者们交流，加入我们的 gitter 频道，或者来我们的 Jenkins World 一起讨论 JCasC 项目及其未来！另外，不要错过 Configuration-as-Code 系列的下一篇文章，我们将会了解 JCasC 如何处理密码及其他凭据等敏感数据。 ...

今天，我打算给 Jenkins 管理员和开发者们介绍一个新的工具 Custom WAR Packager。该工具可以打包 Jenkins 的自定义 WAR 发行版、 Docker 镜像以及 Jenkinsfile Runner 包。它可以打包 Jenkins、插件以及配置为开箱即用的发行版。 Custom WAR Packager 是我们曾在一篇博客– A Cloud Native Jenkins –中介绍过的无状态 Jenkins master 工具链的一部分。这个工具链已在 Jenkins X 中被用于构建 serverless 镜像。在这篇文章中，我将会介绍几种 Custom WAR Packager 常见的使用场景。历史正如 Jenkins 本身一样，Custom WAR Packager 开始于一个小的开发工具。在 Jenkins 内运行集成测试很长时间以来都是一个难题。对此，我们有三个主要的框架： Jenkins Test Harness, Acceptance Test Harness, 和 Plugin Compatibility Tester。这些框架都需要一个 Jenkins WAR 文件来运行测试。但是，假如你想在类似 AWS 一样的自定义环境中进行 Jenkins 测试呢？ 或者，你希望基于 Pluggable Storage 的环境也可以复用 Jenkins 流水线测试，来确保没有回归缺陷，又如何呢？这并不是没有意义的问题。云原生 Jenkins、Jenkins Evergreen 以及 Jenkins X, 这些 Jenkins 项目中正在进行的主要活动，都需要大量的集成测试来实现持续交付流程。为了复用已有的框架，我们需要打包一个自带配置的 WAR 文件，以便可以在现有的框架中运行集成测试。这正是 Custom WAR Packager 于 2018年4月 创建的原因。到 2018年9月，它相继支持了 Docker 镜像和 Jenkinsfile Runner，后者由 Kohsuke Kawaguchi 创建并由 Nicolas de Loof 完善。揭开面纱Custom WAR Packager 是一个工具，可以作为命令行、Maven 插件或者 Docker 程序包来用。该工具可以从用户处获取配置，并根据用户请求进行打包。所有内容都由一个 YAML 配置文件管理：该工具支持多种输入类型。插件列表可以来自 YAML,pom.xml 或一个 BOM(jep:309[] 提出的 Bill of Materials) 文件。Custom WAR Packager 不仅支持发布版本，还可以构建部署到 增量仓库 (Jenkins 核心及插件的 CD 流程 - jep:305[])，甚至直接从 Git 或指定目录中构建。它允许从任何来源构建包，而无需等待官方版本。由于插件已经通过 Commit ID 缓存到了本地的 Maven 仓库中，因此其构建过程也非常快。自定义Custom WAR Packager 还支持下面的配置选项：Jenkins 配置即代码 的 YAMl 文件Groovy Hooks （例如：预配置的 init hooks）系统属性WAR打包每当这个库构建时会打包出来一个 WAR 文件。通常，Custom WAR Packager 会根据下面对 Jenkins 核心和 JCasC 的配置把所有内容打包的一个 WAR 文件中。样例配置：bundle: groupId: “io.jenkins.tools.war-packager.demo"artifactId: “blogpost-demo"vendor: “Jenkins project"description: “Just a demo for the blogpost"war: groupId: “org.jenkins-ci.main"artifactId: “jenkins-war"source: version: 2.138.2plugins:groupId: “io.jenkins"artifactId: “configuration-as-code"source: # Common releaseversion: 1.0-rc2groupId: “io.jenkins"artifactId: “artifact-manager-s3"source: # Incrementalsversion: 1.2-rc259.c9d60bf2f88cgroupId: “org.jenkins-ci.plugins.workflow"artifactId: “workflow-job"source: # Gitgit: https://github.com/jglick/wor...commit: 18d78f305a4526af9cdf3a7b68eb9caf97c7cfbcetc.systemProperties: jenkins.model.Jenkins.slaveAgentPort: “9000"jenkins.model.Jenkins.slaveAgentPortEnforce: “true"groovyHooks:type: “init"id: “initScripts"source: dir: src/main/groovycasc🆔 “jcasc"source: dir: casc.ymlDocker 打包为了打包 Docker，Custom WAR Packager 使用官方的 Docker 镜像 jenkins/jenkins 或同样格式的其他镜像。在构建期间，WAR 文件会被该工具构建的文件所替换。这也就意味着镜像的 所有 特色在该自定义构建中都可用： plugins.txt, Java 选项, Groovy hooks 等等。…## WAR configuration from above## …buildSettings: docker: build: trueBase imagebase: “jenkins/jenkins:2.138.2"Tag to set for the produced imagetag: “jenkins/custom-war-packager-casc-demo"例如：示例 展示了打包带有将构建日志存储到 Elasticsearch 的 Docker 镜像。 尽管这些已经作为了 jep:207 和 jep:210 的一部分，你还是可以查看这个示例，了解该 Docker 镜像是如何配置、连接到 Elasicsearch、然后启动外部的日志存储，而不需要改变日志的界面。一个 Docker Compose 文件对于运行整个集群是必要的。Jenkinsfile Runner 打包这可能是 Jenkinsfile Runner 最微妙的模式。三月，在开发者列表中 宣布了一个新的项目 Jenkinsfile Runner。大体的思路是，支持在单一 master 上只运行一次并打印输出到控制台的 Jenkins 流水线。 Jenkinsfile Runner 作为命令或一个 Docker 镜像来运行。虽然只推荐 Docker 的形式，但是 Custom WAR Packager 都能够生成。使用 Jenkinsfile Runner ，你可以像下面的方式来运行流水线：docker run –rm -v $PWD/Jenkinsfile:/workspace/Jenkinsfile acmeorg/jenkinsfile-runner当我们开始在云原生特别兴趣小组（Cloud Native SIG）中研究无状态（也就是“一次”）时，有一个想法就是使用 Custom WAR Packager 和其他已有的工具（Jenkinsfile Runner, Jenkins Configuration as Code 等）来实现。也许只是替换 Jenkinsfile Runner 中的 Jenkins 核心的 JAR 以及插件，但这还不够。为了高效，Jenkinsfile Runner 镜像应该启动得 很快。在构建流程实现中，我们使用了 Jenkins 和 Jenkinsfile Runner 一些实验性的选项，包括：类加载预缓存、插件解压等等。有了这些后，Jenkins 使用 configuration-as-code 和几十个插件可以在几秒钟内启动。那么，如何构建自定义 Jenkinsfile Runner 镜像呢？尽管目前还没有发布，但这不会影响我们继续实现上文提到的内容。…## WAR Configuration from above##…buildSettings: jenkinsfileRunner: source: groupId: “io.jenkins"artifactId: “jenkinsfile-runner"build: noCache: truesource: git: https://github.com/jenkinsci/j … r.gitcommit: 8ff9b1e9a097e629c5fbffca9a3d69750097ecc4docker: base: “jenkins/jenkins:2.138.2"tag: “onenashev/cwp-jenkinsfile-runner-demo"build: true你可以从 这里 找到用 Custom WAR Packager 打包 Jenkinsfile Runner 的例子。更多信息还有很多其他的特色没有在本文中提到。例如：它还可以修改 Maven 构建配置或增加、替换 Jenkins 核心中的库（例如：Remoting）。请查看 Custom WAR Packager 文档 获取更多信息和示例。如果你有兴趣对这个库做贡献，请创建 PR 并抄送 @oleg-nenashev 和 Raul Arabaolaza。（编者注：Raul Arabaolaza 是第二位正在研究 Jenkins 自动化测试流程的维护者。）下一步还有很多值得改进的地方可以使这个工具更加高效：增加对插件依赖传递的检查以便在构建过程中发现冲突允许在 YAML 配置文件中设置各种系统属性和 Java 选项改进 Jenkinsfile Runner 的性能集成到 Jenkins 集成测试流程中，(查看 Jenkins 流水线库中的 essentialsTest())即使目前，该工具已经能够让 Jenkins 用户构建他们自己的发行版，从理论上来讲，仍有许多其他任务可以在 Custom WAR Packager 中实现。 ...

jenkins自动化项目部署实战简介以下文章只是从入门来说明jenkins的部署过程，仅供新手入门，高手勿喷。安装命令如下：拉镜像，无需解释docker pull jenkins创建挂载路径mkdir /mnt/jenkinschown -R 1000 /mnt/jenkins8080： 访问网页；50000： 配置主从，在slave上构建需映射50000docker run –name jenkins -p 8080:8080 -p 50000:50000 -v /mnt/jenkins:/var/jenkins_home jenkins注：暴露端口根据需要自定义修改。初始密码cat /mnt/jenkins/secrets/initialAdminPassword安装推荐插件（前提：服务器配置安全组，开放暴露端口）访问网页，输入密码，默认以admin进入，会显示推荐插件安装。另外，Maven项目需要另外下载一个插件方能支持（主要体现在创建项目时，出现Maven选项）：Maven Integration plugin坑点：自备梯子，有时网络不佳会导致下载安装失败，可自行截图记住插件，以便之后进入插件管理页面重新下载配置系统管理配置Jenkins主页 - 系统管理 - 管理插件安装如下插件：Maven Integration pluginJenkins主页 - 系统管理 - Global Tool ConfigurationAdd Mavenssh连接1：服务器本地 && docker容器进入Docker容器，生成 ssh keycopy id_rsa.pub 到服务器本机~/.m2/authorized_keysdocker exec -it jenkins bashssh-keygencat ~/.ssh/id_rsa.pubecho " id_rsa.pub " >> ~/.m2/authorized_keysssh连接2：与Git版本管理工具连接（常见如：Gitlab，Github）以本人配置的Github举栗子：进入Github，添加 ssh key （docker容器里的 id_ras.pub ）项目基础配置配置Credentials常见问题问题一：No valid crumb was included in the request.解决方案去掉“防止跨站点请求伪造”选项。问题二：Host key verification failed.解决方案进入docker容器，执行如下命令：root@IP注：IP依脚本而定。结语至此，整个docker安装和项目发布过程就描述到这里了，希望对大家有所帮助。俊龙-广州芦苇科技Java工程师

使用jenkins作为打包的工具，主机上的磁盘空间总是被慢慢被占满，直到jenkins无法运行。本文从几个方面来清理docker垃圾。批量删除已经退出的容器docker ps -a | grep “Exited” | awk ‘{print $1 }’ | xargs docker rm批量删除带有none字段的镜像$3一般就是取出每一行的镜像id字段# 方案1： 根据镜像id删除镜像docker images| grep none |awk ‘{print $3 }’|xargs docker rmi# 方案2: 根据镜像名删除镜像docker images | grep wecloud | awk ‘{print $1":"$2}’ | xargs docker rmi方案1，根据镜像ID删除镜像时，有写镜像虽然镜像名不同，但是镜像ID都是相同的，这是后往往会删除失败。所以根据镜像名删除镜像的效果会更好。删除镜像定时任务脚本#!/bin/bash# create by wangduanduan# when current free disk less then max free disk, you can remove docker images#GREEN=’\033[0;32m’RED=’\033[0;31m’NC=’\033[0m’max_free_disk=5 # 5G. when current free disk less then max free disk, remove docker imagescurrent_free_disk=df -lh | grep centos-root | awk '{print strtonum($4)}'df -lhecho “max_free_disk: $max_free_disk G"echo -e “current_free_disk: ${GREEN} $current_free_disk G ${NC}“if [ $current_free_disk -lt $max_free_disk ]then echo -e “${RED} need to clean up docker images ${NC}” docker images | grep none | awk ‘{print $3 }’ | xargs docker rmi docker images | grep wecloud | awk ‘{print $1”:"$2}’ | xargs docker rmielse echo -e “${GREEN}no need clean${NC}“fi注意事项为了加快打包的速度，一般不要太频繁的删除镜像。因为老的镜像中的某些不改变的层，可以作为新的镜像的缓存，从而大大加快构建的速度。 ...

本文有以下假设和要求：你的项目源代码的根目录已经存在Jenkinsfile你的项目是一个Maven项目你的Jenkins能够从公网访问本文参考自官方文档使用Jenkins构建Coding项目【Jenkins】新建文件夹【Jenkins】配置SSH key pair运行下列命令生成SSH key pair，生成两个文件deploykey和deploykey.pub：ssh-keygen -f deploykey进入刚刚创建的文件夹，按下图添加SSH Username with private key凭据：把deploykey的内容贴到下面这个页面里：把deploykey.pub的内容贴到Coding项目的部署公钥里：【Jenkins】配置Maven settings.xml根据创建Jenkins Pipeline流水账 - 配置Maven settings.xml操作【Coding】创建个人访问令牌创建个人访问令牌是为了能够让Coding Webhook plugin反馈构建结果到Coding。把令牌复制下来，注意这个页面是你能够复制令牌的唯一一次机会，如果把这个页面关了，那只能重新创建令牌了：【Jenkins】新建流水线到刚才创建的文件夹里创建流水线：接下来做这么几件事情：把Webhook地址复制下来设置Webhook令牌，这个相当于密码，你自己随便输。把之前创建的个人访问令牌贴到【访问令牌】输入框。然后按照下图方式配置。点击下图所示问号能看到以下帮助文档，注意我们是私有项目看红框内容：在Pipeline部分配置仓库：Credential使用之前创建的SSH keyName和Refspec是根据前面帮助文档里要求的填写的在Branches to build里添加两项：refs/remotes/origin/refs/remotes/origin/merge/其实这两个值是帮助文档里提到的而来，注意两个refspec里冒号后面的部分：如果是私有项目, 设置 refspec 为 +refs/heads/:refs/remotes/origin/ +refs/merge/*/MERGE:refs/remotes/origin/merge/*添加两个Additional Behaviours：去掉Lightweight checkout的勾：在Pipeline Maven Configuration部分选择刚才创建的Maven settings.xml：【Coding】配置Webhook到项目的 设置 -> WebHook 页面，添加Webhook：按下图配置：效果至此大功告成。你可以通过提交commit的方式触发Jenkins构建，然后可以在项目的这个页面看到构建结果：你也可以创建合并请求，Coding会触发Jenkins构建并且把构建结果添加到合并请求里：

注：本文的例子基于搭建Jenkins集群流水账搭建的集群所写。注：本文是一个Maven项目流水线的例子。创建流水线利用Blueocean创建流水线。填写GIT仓库信息。将Blueocean生成的SSH key添加到GIT server里。点击创建流水线后Jenkins会拉取GIT仓库，并且尝试寻找存在Jenkinsfile的分支，然后构建。不过不管构建是否成功，都不要管它，我们回到经典页面做进一步配置。配置Maven settings.xml我们先配置一下私有Maven仓库的用户名密码。按照下图的顺序进入凭据管理页面添加凭据输入用户名密码有了用户名密码还不够，还得提供Maven的settings.xml。进入Config Files管理页面添加新的Config选择Global Maven settings.xml在Server Credentials新增，ServerId填写的是pom.xml里的 project > distributionManagement > repository > id 的值。Credential选择之前创建的凭据。如果你有多个repository那么就添加多个Server Credential。配置流水线最后还要配置一下流水线，因为默认配置还有点问题。点击Configure进入配置页面。点击分支源Tab，点击Add property，添加“不通过SCM自动化触发”，它的意思是Branch indexing（扫描多分支流水线）不会触发构建。点击“扫描多分支流水线Triggers“Tab，启用Periodically if not otherwise run，Interval选择15分钟，这是为了让该流水线能够感知到分支的删除/新建。点击“Pipeline Maven Configuration“，配置Global Settings file，选择我们刚刚新建的Config file。点击“JIRA”，勾选“Enable project-based security“，如下图所示配置。保存。创建Jenkinsfile在你的源代码的根目录里创建Jenkinsfile，参考Pipeline文档。然后提交到GIT仓库。然后点击“扫描多分支流水线Now”。查看结果点击打开Blue Ocean然后就能看到每个分支的构建情况了

硬件要求不论是master还是slave，都要安装：操作系统：Ubuntu 16.04 Server LTSDocker-CEDocker安装方法：根据文档：https://yq.aliyun.com/article… 安装docker-cecurl -fsSL https://get.docker.com | bash -s docker –mirror Aliyunsudo usermod -aG docker $USER我在安装的时候碰到Jenkins无法从Update center下载metadata的问题，经发现是docker的mtu比服务器网卡mtu大的问题，解决办法如下：新建或者修改文件：/etc/docker/daemon.json，添加mtu的设置比如：{ “mtu”: <服务器网卡的mtu>, …}你可以配置docker registry mirror，同样修改/etc/docker/daemon.json：{ “registry-mirrors”: ["…"], …}然后重启docker：sudo systemctl restart docker部署master创建目录：mkdir $HOME/jenkins-home启动Jenkins：sudo docker run \ -u root \ -d \ -p 8080:8080 \ -p 50000:50000 \ -v $HOME/jenkins-home:/var/jenkins_home \ -v /var/run/docker.sock:/var/run/docker.sock \ –name jenkins \ jenkinsci/blueocean创建ssh密钥对：ssh-keygen初始配置Jenkins浏览器访问Jenkins：http://<jenkins-master-ip>:8080/选择安装社区推荐插件设置管理员用户安全配置配置LDAP如果要配置LDAP，那么一定要记住，配置完之后不要注销。系统管理 -> 全局安全设置，访问控制，选择LDAP，然后根据情况配置即可。注意配置完之后一定要Test。配置授权策略系统管理 -> 全局安全设置，授权策略，项目矩阵授权策略。打开浏览器隐私窗口，用一个账号登录，这个账号将替代当前使用的管理员账号。下面为了方便理解，下面吧当前浏览器称为A窗口，隐私窗口浏览器称为B窗口。回到A窗口，添加刚才登录的用户，如果正常添加，用户名上不会有删除线。然后在全部这一栏勾选Administer，点击应用。此时A窗口的管理员账号应该就不能做任何操作了，而且再也不能登录了。到B窗口，刷新一下，继续后面的管理员动作。下图是推荐的配置方法：添加Slave节点前期准备准备Slave的机器安装Docker-CE安装openjdk：sudo apt install -y openjdk-8-jdk新建工作目录：mkdir $HOME/jenkins-workdir把master的pub key添加到slave上：把master的$HOME/.ssh/id_rsa.pub内容添加到slave的$HOME/.ssh/authorized_keys里。到 系统管理 > 节点管理，新建节点名字：slave-1并发构建数：2（cpu核数）远程工作目录：<jenkins-workdir的绝对路径>用法：尽可能的使用这个节点启动方式：Launch agent agents via SSHHost：<slave的ip>Credentials：这个时候要创建一个平局，方法如下：Domain，全局凭据类型：SSH username with private keyusername: <slave的操作系统用户名>private key: 把master $HOME/.ssh/id_rsa 的内容贴上去Passphrase: <blank>ID: <blank>描述：For slave connectionHost Key Verification Strategy：Non verifying Verification Strategy保存修改master节点，执行者数量设置为0，这样就能避免Job分配到master上。安装其他插件系统管理 -> 插件管理，安装下列插件：Config File ProviderPipeline MavenCoding PluginRancher PluginTestNG ResultsSonarQube Scanner配置工具系统管理 -> 全局工具配置，都选择自动安装，下面列出的是工具的名字JDK：JDK6、JDK7、JDK8，要输入oracle网站账号密码Maven：Maven3Docker：Docker配置时区用Docker启动Jenkins时区是GMT+0见wiki：https://wiki.jenkins.io/displ…系统管理 -> 脚本命令行System.setProperty(‘org.apache.commons.jelly.tags.fmt.timeZone’, ‘Asia/Shanghai’)清理重装方法如果你配置错误搞砸了，想从头开始，那么这么做，只需要这么几步：ssh到master上：sudo docker stop jenkinssudo rm -rf $HOME/jenkins-home/* ...