最近我们构建和部署服务的方式与原来相比简直就是突飞猛进，像那种笨拙的、单一的、用于构建单体式应用程序的方式已经是过去式了。我们努力了这么久，终于达到了现在的效果。现在的应用为了提供更好的拓展性和可维护性，都会去拆解成各种相互依赖小、解耦性强的微服务，这些服务有各自的依赖和进度。如果你想去构建你所负责的服务，那么从一开始，就应该使用 CI/CD 的方式；当然，如果你走上了这条路， Jenkins 就是你的良师益友。
描述: 我们在使用Jenkins的时候一般都会分为server节点与agent节点(也可以叫 slave 节点)。
提到基于 Kubernetes 的 CI/CD，可以使用的工具有很多，比如 Jenkins、Gitlab CI、Drone 之类的，我们这里会使用大家最为熟悉的 Jenkins 来做 CI/CD 的工具。
Jenkins 2 image based on Red Hat Enterprise Linux的镜像
在kubernetes环境部署的jenkins集群，执行任务时会新建pod，任务完成后pod被销毁，架构如下：
要实现在 Jenkins 中的构建工作，可以有多种方式，我们这里采用比较常用的 Pipeline 这种方式。Pipeline，简单来说，就是一套运行在 Jenkins 上的工作流框架，将原来独立运行于单个或者多个节点的任务连接起来，实现单个任务难以完成的复杂流程编排和可视化的工作。
应对敏捷开发的需求，对CI(持续集成))/CD（持续交付）的提出了更高的标准，今天来讨论下，如何基于开源组件（gitlab/jenkins/harbor/kubernetes）使用CI/CD，赋能团队的开发、运维。
由于以上种种痛点，我们渴望一种更高效更可靠的方式来完成这个 CI/CD 流程，而 Docker 虚拟化容器技术能很好的解决这个痛点，下图是基于 Kubernetes 搭建 Jenkins 集群的简单示意图。
前面jenkins是搭建在docker容器里，运行job的时候默认会在容器内部运行代码，相关的依赖环境需要在docker容器重新安装一遍，这样很不方便。 如果宿主机已经安装好相关的运行环境了，docker容器我们搭建好jenkins就行了， 把宿主机设置为jenkins的一个slave节点
K8S目前是业界容器编排领域的事实标准，是几乎所有云原生架构的首选。目前随着云原生架构越来越流行，测试开发人员需要掌握K8S技术栈已经成为越来越迫切的需求。
随着Kubernetes的遍地开花，Kubernetes的优势可以说是深入人心，很多企业也是利用Kubernetes，来实现更高效的交付和更好地提高我们的资源使用率，推动标准化，适应云原生。
虽然云原生时代有了Jenkins X、Drone、Tekton 这样的后起之秀，但 Jenkins 这样一个老牌的 CI/CD 工具仍是各大公司主流的使用方案。
虽然云原生时代有了 JenkinsX[1]、Drone[2]、Tekton[3] 这样的后起之秀，但 Jenkins 这样一个老牌的 CI/CD 工具仍是各大公司主流的使用方案。比如我司的私有云产品打包发布就是用这老家伙完成的。然而传统的 Jenkins Slave 一主多从方式会存在一些痛点，比如：
之前写的Spinnaker自动化部署，部署复杂，依赖环境多，所以才有这一篇比较轻量级的自动化持续集成，需要用到的环境有Kubernetes-1.23、harbor、Jenkins、Helm、gitlab都是devops常见组件。
-参考：https://github.com/jenkinsci/kubernetes
本文是《K8S环境的Jenkin性能问题处理》的续篇，上一篇解决了Jenkins集群中的Master节点的性能问题，但是真正执行任务的并非Master节点，而是为每个任务临时创建的Pod，这些Pod的性能问题决定着任务的快慢甚至成败；
点击《系统管理》—>《Configure System》—>《配置一个云》—>《kubernetes》，如下：
有效的持续集成（CI）是任何成功开发团队的核心要求。由于CI不是一线服务，因此通常可以在中间层或多余硬件上运行。为拉取请求，自动部署，验收测试，内容上传以及许多其他任务添加构建可能会迅速淹没构建计算机的资源 - 尤其是在有大量提交和部署活动时即将启动。
今天突然就有了那么一个需求，记录一下：腾讯云的redis内网地址都是IP的方式。我们的服务注册在了nacos中。小伙伴本地测试链接上nacos(nacos开通了外网访问)，获取redis中redis配置都是内网的redis IP故无法加入注册到集群。同事问我能不能将Redis ip设置成域名的方式，那样他本地好歹能做个假的解析做一个欺骗把服务启动起来？（懒得改代码毕竟）
软件环境：Jenkins + Kubernetes + Gitlab + Harbor+helm
注: 本次示例使用的gitlab项目地址为：http://gitlab.hanker.com/colynn/hanker-hello.git
之前我们都是在物理机或者虚拟机上部署jenkins，但是这种部署方式会有一些难点，如下：
3、Jnekins Pipeline 介绍与动态生成 Jenkins Slave
随着微服务架构的流行，服务按照不同的维度进行拆分，一次请求往往需要涉及到多个服务。这些服务可能不同编程语言开发，不同团队开发，可能部署很多副本。因此，就需要一些可以帮助理解系统行为、用于分析性能问题的工具，以便发生故障的时候，能够快速定位和解决问题。全链路监控组件就在这样的问题背景下产生了。 全链路性能监控 从整体维度到局部维度展示各项指标，将跨应用的所有调用链性能信息集中展现，可方便度量整体和局部性能，并且方便找到故障产生的源头，生产上可极大缩短故障排除时间。
有赞 PaaS 团队自17年7月份开始投入测试资源，测试人员的加入意味着与测试相关的一系列东西产生，比如测试环境、测试工程、测试流程等等，这次分享的内容主要与测试环境有关，刚开始我们把测试环境部署在虚拟机上，从18年7月份开始，我们决定把测试环境从虚拟机迁移到 K8S 上，做这个决定主要出于以下几个方面考虑。
在前面一篇《Jenkins环境搭建&常见使用技巧》中，我们介绍了Jenkins的架构原理：
Java8 无论是Java运行时环境（JRE）还是Java开发工具包（JDK）都可以。安装JDK：yum -y install java
Java8 无论是Java运行时环境（JRE）还是Java开发工具包（JDK）都可以。 安装JDK：yum -y install java
Jenkins 安装完成了，接下来我们不用急着就去使用，我们要了解下在 Kubernetes 环境下面使用 Jenkins 有什么好处。
a、在实际生产环境中，由于某些历史原因我们或许不能完美的实现所谓的一切皆“云原生”，例如有传统的jenkins和执行专有任务的slave节点
下图来自rancher官方博客，在kubernetes环境下，jenkins任务被交给各个pod执行，这些pod在需要时被创建，任务结束后被销毁，这样既能合理利用资源，又能给每个任务提供一致的干净的初始化环境（也可以保留pod，如查问题的时候）
要在 Jenkins 中管理用户，您应该导航到管理 Jenkins 🡪 配置全局安全。理想的选择是让 Jenkins 拥有自己的用户数据库。您可以创建一个只有读取权限的匿名用户。为您打算在下一步中添加的用户创建条目。
我们利用 Kubernetes 来动态运行 Jenkins 的 Slave 节点，可以和好的来解决传统的 Jenkins Slave 浪费大量资源的缺点。之前的示例中我们是将项目放置在 Github 仓库上的，将 Docker 镜像推送到了 Docker Hub，这节课我们来结合我们前面学习的知识点来综合运用下，使用 Jenkins、Gitlab、Harbor、Helm、Kubernetes 来实现一个完整的持续集成和持续部署的流水线作业。
目前我厂 Jenkins CI 采用的是 Master-Slave 架构, Master 和 Slave 都是物理机搭建。主要用于跑单测,集成测试等。由于早期没有专人来管理 Jenkins ，随着业务的发展 Jenkins Job 越来越多，也带来了如下问题：
Jenkins的Master-Slave分布式架构主要是为了解决Jenkins单点构建任务多、负载较高、性能不足的场景。Master-Slave相当于Server和Agent的概念。
最近在制作给kubernetes jenkins plugin调用的jenkins slave(默认情况下，kubernetes jenkins插件使用的是jenkinsci/jnlp-slave)容器镜像，以供自动创建的pod使用。对这个镜像的需求是：希望在pod运行的容器内，执行docker命令，完成docker build, push等一些操作，即docker in docker。
小米的弹性调度平台（Ocean）以及容器平台主要基于开源容器自动化管理平台kubernetes（简称k8s）来提供服务，完善的监控系统提高容器服务的质量的前提。不同于传统物理主机，每个容器相当于一个主机，导致一台物理主机上的系统指标数量成本增长，总的监控指标规模相当庞大（经线上统计，每node指标达到10000+）。此外，为了避免重复造轮，需要最大限度的利用公司的监控报警系统，需要把k8s的监控和报警融入其中。在小米现有的基础设施之上，落地该监控，是一个不小的挑战。
Jenkins- 系统管理 - 全局安全配置， 把 SSH Server 设置为启用(默认是禁用)
JAVA JDK 1.7.0_13 (jdk-7u13-windows-i586.exe)
Tips ：个人理解 Jenkins 是一个调度平台，本身不需要处理任何事情，而是通过众多的插件来完成所有的工作;
WGCLOUD是一款开源运维监测平台，它有一个模块自定义监控项，可以执行一些我们自定义的指令或脚本，非常灵活实用
DevOps定义（来自维基百科）： DevOps（Development和Operations的组合词）是一种重视“软件开发人员（Dev）”和“IT运维技术人员（Ops）”之间沟通合作的文化、运动或惯例。透过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。
现有混合云平台的场景下，即有线下和线上的环境，又有测试与正式的场景，而且结合了Docker，导致打包内容有所区分，且服务的发布流程复杂起来，手工打包需要在编译阶段就要根据环境到处更改配置，因此纯手工发布增加了实施的难度，需要一个统一的适应各种环境部署的方案。
指定整个Pipeline或特定阶段是在Jenkins Master节点还是Jenkins Slave节点上运行。可在顶级pipeline块和每个stage块中使用（在顶层pipeline{}中是必须定义的 ，但在阶段Stage中是可选的）
训练营进行到 DevOps 部分了，上节课讲解 Jenkins 动态 Slave 的时候翻车了，我们知道 Jenkins 安装的时候会让我们选择安装一些推荐的插件，但是由于默认的官方源下载实在是太慢，对于我们直播这种场景来说实在是太不友好了。之前的版本中我反复测试过将 Jenkins 目录下面的 default.json 文件里面的源地址更改成清华大学的源，以及将 google 更改成 baidu，然后重启 Jenkins，安装插件的时候就非常快了。结果这一次直播的时候更改完成之后，重启就直接跳转到了 Jenkins 的主页去了，几乎就没有安装什么插件，所以在做试验的时候非常麻烦。最后是通过优先安装中文插件，然后使用中文社区的插件更新源来解决的，但是在获取插件列表的时候还是非常卡，安装的时候倒是快了不少，不知道是不是我使用的姿势不对，总之直播翻车了，浪费了很多时间，所以我们得重新讲解一次。
该命令直接拉取的最新版本（latest）的镜像，我们还可以选择下面几个推荐的版本：
Jenkins 是一个自动化服务器，在不断发展的 DevOps 环境中协调 CI/CD 管道方面发挥着至关重要的作用。然而，传统的 Jenkins 代理在可扩展性和灵活性方面存在局限性。这就是 Kubernetes 的用武之地。Kubernetes 是一个容器编排平台，正在改变部署和管理的方式。本文通过使用 Kubernetes Pod 作为 Jenkins 代理，深入探讨 Jenkins 和 Kubernetes 如何协同工作。这使团队能够动态扩展、优化资源利用率并简化其 CI/CD 工作流程。
java -jar slave.jar -jnlpUrl http://192.168.23.13:8080/jenkins/computer/IOS_Node/slave-agent.jnlp -secret62b5dc021bbf90e8207057760bf71fae93867c154add3963e5f9c3befee2df06
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
实时音视频
即时通信 IM
