一、项目开发需要考虑的维度
二、什么是 DevOps ?
三、什么是 CI&CD
四、落地方案
五、基于 Spring Boot 项目构建流水线
- 1. 流水线概览
- 2. 创建凭证
- - ① 凭证
  - ② Token
  - ③ 密文
- 3. 修改 Jenkinsfile
- - ① Fork项目
  - ② 修改 Jenkinsfile
- 4. 创建项目
- - ① 创建第一个项目
  - ② 邀请成员
  - ③ 创建第二个项目
- 5. 创建流水线
- - ① 填写基本信息
  - ② 添加仓库
  - ③ 高级设置
  - ④ 运行流水线
  - ⑤ 审核与查看流水线

一、项目开发需要考虑的维度

Dev：怎么开发？

Ops：怎么运维？

高并发：怎么承担高并发?

高可用：怎么做到高可用?

二、什么是 DevOps ?

DevOps是产品开发过程中开发（Dev）和运营（Ops）团队之间的灰色区域。DevOps是一种在产品开发周期中强调沟通，集成和协作的文化。因此，它消除了软件开发团队和运营团队之间的孤岛，使他们能够快速，连续地集成和部署产品。

DevOps 就是开发（Development）、测试（QA）、运维（Operations）这三个领域的合并。DevOps是一种软件开发方法，涉及软件在整个开发生命周期中的持续开发，持续测试，持续集成，持续部署和持续监控。

编码 ——> 打包 ——> 测试 ——> 发布 ——> 部署 ——> 运维 ——> 监控

微服务实现服务自治：服务注册与发现等等。。。

DevOps：Development 和 Operations 的组合

DevOps 希望做到的是软件产品交付过程中 IT 工具链的打通，使得各个团队减少时间损耗，更加高效地协同工作。专家们总结出了上面这个 DevOps 能力图，良好的闭环可以大大增加整体的产出。

三、什么是 CI&CD

A、持续集成 (Continuous Integration)

持续集成是指软件个人研发的部分向软件整体部分交付，频繁进行集成以便更快地发现其中的错误。" 持续集成 " 源自于极限编程 (XP)，是 XP 最初的 12 种实践之一。

CI 需要具备这些：

全面的自动化测试。这是实践持续集成&持续部署的基础，同时，选择合适的自动化测试工具也极其重要。
灵活的基础设施。容器，虚拟机的存在让开发人员和 QA 人员不必再大费周折。
版本控制工具。如 Git，CVS，SVN 等。
自动化的构建和软件发布流程的工具，如 Jenkins，flow.ci；
反馈机制。如构建/测试的失败，可以快速地反馈到相关负责人，以尽快解决达到一个更稳定的版本。

B、持续交付（Continuous Delivery）

持续交付在持续集成的基础上，将集成后的代码部署到更贴近真实运行环境的「类生产环境」(production-like environments) 中。持续交付优先于整个产品生命周期的软件部署，建立在高水平自动化持续集成之上。

发布应用场景：

蓝绿发布：两套环境交替升级，旧版本保留一定时间便于回滚。
灰度发布：根据比例将老版本升级，例如80%用户访问是老版本，20%用户访问是新版本。
滚动发布：按批次停止老版本实例，启动新版本实例。

蓝绿发布：

项目逻辑上分为AB组，在项目系统时，首先把A组从负载均衡中摘除，进行新版本的部署。B组仍然继续提供服务。当A组升级完毕，负载均衡重新接入A组，再把B组从负载列表中摘除，进行新版本的部署。A组重新提供服务。最后，B组也升级完成，负载均衡重新接入B组，此时，AB组版本都已经升级完成，并且都对外提供服务。

灰度发布：

灰度发布只升级部分服务，即让一部分用户继续用老版本，一部分用户开始用新版本，如果用户对新版本没什么意见，那么逐步扩大范围，把所有用户都迁移到新版本上面来。

持续交付和持续集成的优点非常相似：

快速发布。能够应对业务需求，并更快地实现软件价值。
编码 —> 测试 —> 上线 ----> 交付的频繁迭代周期缩短，同时获得迅速反馈。
高质量的软件发布标准。整个交付过程标准化、可重复、可靠。
整个交付过程进度可视化，方便团队人员了解项目成熟度。
更先进的团队协作方式。从需求分析、产品的用户体验到交互设计、开发、测试、运维等角色密切协作，相比于传统的瀑布式软件团队，更少浪费。

C、持续部署（Continuous Deployment）

持续部署是指当交付的代码通过评审之后，自动部署到生产环境中。持续部署是持续交付的最高阶段。这意味着，所有通过了一系列的自动化测试的改动都将自动部署到生产环境。它也可以被称为 “Continuous Release”。

开发人员提交代码，持续集成服务器获取代码，执行单元测试，根据测试结果决定是否部署到预演环境，如果成功部署到预演环境，进行整体验收测试，如果测试通过，自动部署到产品环境，全程自动化高效运转。

持续部署主要好处是，可以相对独立地部署新的功能，并能快速地收集真实用户的反馈。

“You build it, you run it”，这是 Amazon 一年可以完成 5000 万次部署，平均每个工程师每天部署超过 50 次的核心秘籍。

四、落地方案

使用：Maven + Github + Jenkins + Docker

自动化部署：我们主要使用 Jenkins 来完成。。。

五、基于 Spring Boot 项目构建流水线

1. 流水线概览

下面的流程图简单说明了流水线完整的工作过程：

阶段一：Checkout SCM: 拉取 GitHub 仓库代码
阶段二：Unit test: 单元测试，如果测试通过了才继续下面的任务
阶段三： SonarQube analysis：sonarQube 代码质量检测
阶段四. Build & push snapshot image: 根据行为策略中所选择分支来构建镜像，并将 tag 为SNAPSHOT-$BRANCH_NAME-$BUILD_NUMBER 推送至 Harbor (其中 $BUILD_NUMBER为 pipeline 活动列表的运行序号)。
阶段五：Push latest image: 将 master 分支打上 tag 为 latest，并推送至 DockerHub。
阶段六： Deploy to dev: 将 master 分支部署到 Dev 环境，此阶段需要审核。
阶段七： Push with tag: 生成 tag 并 release 到 GitHub，并推送到 DockerHub。
阶段八： Deploy to production: 将发布的 tag 部署到 Production 环境。

2. 创建凭证

注意：
GitHub 账号或密码带有 “@” 这类特殊字符，需要创建凭证前对其进行 urlencode 编码，可通过一些第三方网站进行转换，然后再将转换后的结果粘贴到对应的凭证信息中。这里需要创建的是凭证（Credential），不是密钥(Secret)。

在多租户管理快速入门中已给项目普通用户 project-regular 授予了 maintainer 的角色，因此使用 project-regular 登录 KubeSphere，进入已创建的 devops-demo 工程，开始创建凭证。

① 凭证

本示例代码仓库中的 Jenkinsfile 需要用到 DockerHub、GitHub 和 kubeconfig (kubeconfig 用于访问接入正在运行的 Kubernetes 集群) 等一共 3 个凭证 (credentials) ，请依次创建这三个凭证。

以项目 project-regular 登录 KubeSphere，在 devops-demo 的 DevOps 工程点击凭证，进入凭证管理界面，以下说明几个在 DevOps 工程中常用的凭证。

A、创建 DockerHub 凭证

点击创建，创建一个用于 DockerHub 登录的凭证；

凭证 ID：必填，此 ID 将用于仓库中的 Jenkinsfile，此示例中可命名为 dockerhub-id
类型：选择账户凭证
用户名：填写您个人的 DockerHub 的用户名
token / 密码：您个人的 DockerHub 的密码
描述信息：介绍凭证，比如此处可以备注为 DockerHub 登录凭证

完成后点击确定。

B、创建 GitHub 凭证

同上，创建一个用于 GitHub 的凭证，凭证 ID 可命名为 github-id，类型选择账户凭证，输入您个人的 GitHub 用户名和密码，备注描述信息，完成后点击确定。

注意：

若用户的凭证信息如账号或密码中包含了 @，$这类特殊符号，可能在运行时无法识别而报错，这类情况需要用户在创建凭证时对密码进行 urlencode 编码，可通过一些第三方网站进行转换 (比如http://tool.chinaz.com/tools/urlencode.aspx)，然后再将转换后的输出粘贴到对应的凭证信息中。

C、创建 kubeconfig 凭证

同上，在凭证下点击创建，创建一个类型为 kubeconfig 的凭证，凭证 ID 可命名为 demo-kubeconfig，完成后点击确定。

说明：

kubeconfig 类型的凭证用于访问接入正在运行的 Kubernetes 集群，在流水线部署步骤将用到该凭证。注意，此处的 Content 将自动获取当前 KubeSphere 中的 kubeconfig 文件内容，若部署至当前 KubeSphere 中则无需修改，若部署至其它 Kubernetes 集群，则需要将其 kubeconfig 文件的内容粘贴至 Content 中。

② Token

参考访问 SonarQube 并创建 Token，创建一个 Java 的 Token 并复制。

A、使用默认账号 admin/admin登入 sonar，然后点击右上角加号下的 Create new project。

B、然后输入 name，然后点击 Generate。

C、即可获取 token，然后点击 Continue。

D、然后选择 Language Java，选择 build technology 为 Maven，复制 token。点击 Finish this tutorial即可。

③ 密文

最后在 KubeSphere 中进入 devops-demo的 DevOps 工程中，与上面步骤类似，在凭证下点击创建，创建一个类型为秘密文本的凭证，凭证 ID 命名为 sonar-token，密钥为上一步复制的 token 信息，完成后点击确定。

3. 修改 Jenkinsfile

① Fork项目

② 修改 Jenkinsfile

Fork 至您个人的 GitHub 后，在根目录进入 Jenkinsfile-online。

在 GitHub UI 点击编辑图标，需要修改如下环境变量 (environment) 的值。

修改项	值	含义
DOCKER_CREDENTIAL_ID	dockerhub-id	填写创建凭证步骤中的 DockerHub 凭证 ID，用于登录您的 DockerHub
GITHUB_CREDENTIAL_ID	github-id	填写创建凭证步骤中的 GitHub 凭证 ID，用于推送 tag 到 GitHub 仓库
KUBECONFIG_CREDENTIAL_ID	demo-kubeconfig kubeconfig	凭证 ID，用于访问接入正在运行的 Kubernetes 集群
REGISTRY	docker.io	默认为 docker.io 域名，用于镜像的推送
DOCKERHUB_NAMESPACE	your-dockerhub-account	替换为您的 DockerHub 账号名(它也可以是账户下的 Organization 名称)
GITHUB_ACCOUNT	your-github-account	替换为您的 GitHub 账号名，例如 https://github.com/kubesphere/则填写 kubesphere(它也可以是账户下的 Organization 名称)
APP_NAME	devops-java-sample	应用名称
SONAR_CREDENTIAL_ID	sonar-token	填写创建凭证步骤中的 SonarQube token凭证 ID，用于代码质量检测

注：master 分支 Jenkinsfile 中 mvn命令的参数 -o，表示开启离线模式。本示例为适应某些环境下网络的干扰，以及避免在下载依赖时耗时太长，已事先完成相关依赖的下载，默认开启离线模式。

修改以上的环境变量后，点击 Commit changes，将更新提交到当前的 master 分支。

4. 创建项目

CI/CD 流水线会根据示例项目的 yaml 模板文件，最终将示例分别部署到 kubesphere-sample-dev和 kubesphere-sample-prod这两个项目 (Namespace) 环境中，这两个项目需要预先在控制台依次创建，参考如下步骤创建该项目。

① 创建第一个项目

使用项目管理员 project-admin账号登录 KubeSphere，在之前创建的企业空间 (demo-workspace) 下，点击项目 → 创建，创建一个资源型项目，作为本示例的开发环境，填写该项目的基本信息，完成后点击下一步。

名称：固定为 kubesphere-sample-dev，若需要修改项目名称则需在 yaml 模板文件中修改 namespace
别名：可自定义，比如开发环境
描述信息：可简单介绍该项目，方便用户进一步了解

本示例暂无资源请求和限制，因此高级设置中无需修改默认值，点击创建，项目可创建成功。

② 邀请成员

第一个项目创建完后，还需要项目管理员 project-admin邀请当前的项目普通用户 project-regular进入 kubesphere-sample-dev项目，进入「项目设置」→「项目成员」，点击「邀请成员」选择邀请 project-regular并授予 operator角色。

③ 创建第二个项目

同上，参考以上两步创建一个名称为 kubesphere-sample-prod的项目作为生产环境，并邀请普通用户 project-regular进入 kubesphere-sample-prod 项目并授予 operator角色。

说明：当 CI/CD 流水线后续执行成功后，在 kubesphere-sample-dev和 kubesphere-sample-prod项目中将看到流水线创建的部署 (Deployment) 和服务 (Service)。

5. 创建流水线

① 填写基本信息

进入已创建的 DevOps 工程，选择左侧菜单栏的流水线，然后点击创建。

在弹出的窗口中，输入流水线的基本信息。

名称：为创建的流水线起一个简洁明了的名称，便于理解和搜索
描述信息：简单介绍流水线的主要特性，帮助进一步了解流水线的作用
代码仓库：点击选择代码仓库，代码仓库需已存在 Jenkinsfile

② 添加仓库

点击代码仓库，以添加 Github 仓库为例。
点击弹窗中的获取 Token。

在 GitHub 的 access token 页面填写 Token description，简单描述该 token，如 DevOps demo，在 Select scopes 中无需任何修改，点击 Generate token，GitHub 将生成一串字母和数字组成的 token 用于访问当前账户下的 GitHub repo。

复制生成的 token，在 KubeSphere Token 框中输入该 token 然后点击保存。

验证通过后，右侧会列出此 Token 关联用户的所有代码库，选择其中一个带有 Jenkinsfile 的仓库。比如此处选择准备好的示例仓库 devops-java-sample，点击选择此仓库，完成后点击下一步。

③ 高级设置

完成代码仓库相关设置后，进入高级设置页面，高级设置支持对流水线的构建记录、行为策略、定期扫描等设置的定制化，以下对用到的相关配置作简单释义。

分支设置中，勾选丢弃旧的分支，此处的保留分支的天数和保留分支的最大个数默认为 -1。

说明：

分支设置的保留分支的天数和保持分支的最大个数两个选项可以同时对分支进行作用，只要某个分支的保留天数和个数不满足任何一个设置的条件，则将丢弃该分支。假设设置的保留天数和个数为 2 和 3，则分支的保留天数一旦超过 2 或者保留个数超过 3，则将丢弃该分支。默认两个值为 -1，表示将会丢弃已经被删除的分支。

丢弃旧的分支将确定何时应丢弃项目的分支记录。分支记录包括控制台输出，存档工件以及与特定分支相关的其他元数据。保持较少的分支可以节省 Jenkins 所使用的磁盘空间，我们提供了两个选项来确定应何时丢弃旧的分支：

保留分支的天数：如果分支达到一定的天数，则丢弃分支。

保留分支的个数：如果已经存在一定数量的分支，则丢弃最旧的分支。

行为策略中，KubeSphere 默认添加了三种策略。由于本示例还未用到从 Fork 仓库中发现 PR 这条策略，此处可以删除该策略，点击右侧删除按钮。

说明：

支持添加三种类型的发现策略。需要说明的是，在 Jenkins 流水线被触发时，开发者提交的 PR (Pull Request) 也被视为一个单独的分支。

发现分支：

排除也作为 PR 提交的分支：选择此项表示 CI 将不会扫描源分支 (比如 Origin 的 master branch)，也就是需要被 merge 的分支

只有被提交为 PR 的分支：仅扫描 PR 分支

所有分支：拉取的仓库 (origin) 中所有的分支

从原仓库中发现 PR：

PR 与目标分支合并后的源代码版本：一次发现操作，基于 PR 与目标分支合并后的源代码版本创建并运行流水线

PR 本身的源代码版本：一次发现操作，基于 PR 本身的源代码版本创建并运行流水线

当 PR 被发现时会创建两个流水线，一个流水线使用 PR 本身的源代码版本，一个流水线使用 PR 与目标分支合并后的源代码版本：两次发现操作，将分别创建两条流水线，第一条流水线使用 PR 本身的源代码版本，第二条流水线使用 PR 与目标分支合并后的源代码版本

默认的脚本路径为 Jenkinsfile，请将其修改为 Jenkinsfile-online。

注：路径是 Jenkinsfile 在代码仓库的路径，表示它在示例仓库的根目录，若文件位置变动则需修改其脚本路径。

在扫描 Repo Trigger 勾选如果没有扫描触发，则定期扫描，扫描时间间隔可根据团队习惯设定，本示例设置为 5 minutes。

说明：

定期扫描是设定一个周期让流水线周期性地扫描远程仓库，根据行为策略查看仓库有没有代码更新或新的 PR。

Webhook 推送：

Webhook 是一种高效的方式可以让流水线发现远程仓库的变化并自动触发新的运行，GitHub 和 Git (如 Gitlab) 触发 Jenkins 自动扫描应该以 Webhook 为主，以上一步在 KubeSphere 设置定期扫描为辅。在本示例中，可以通过手动运行流水线，如需设置自动扫描远端分支并触发运行。

完成高级设置后点击创建。

④ 运行流水线

流水线创建后，点击浏览器的刷新按钮，可见两条自动触发远程分支后的运行记录，分别为 master 和 dependency 分支的构建记录。

A、点击右侧运行，将根据上一步的行为策略自动扫描代码仓库中的分支，在弹窗选择需要构建流水线的 master分支，系统将根据输入的分支加载 Jenkinsfile-online (默认是根目录下的 Jenkinsfile)。

B、由于仓库的 Jenkinsfile-online 中 TAG_NAME: defaultValue没有设置默认值，因此在这里的 TAG_NAME可以输入一个 tag 编号，比如输入 v0.0.1。

C、点击确定，将新生成一条流水线活动开始运行。

说明: tag 用于在 Github 和DockerHub 中分别生成带有 tag 的 release 和镜像。注意: 在主动运行流水线以发布 release 时，TAG_NAME不应与之前代码仓库中所存在的 tag名称重复，如果重复会导致流水线的运行失败。

至此，流水线已完成创建并开始运行。

注：点击分支切换到分支列表，查看流水线具体是基于哪些分支运行，这里的分支则取决于上一步行为策略的发现分支策略。

⑤ 审核与查看流水线

当流水线执行至 input步骤时状态将暂停，需要手动点击继续，流水线才能继续运行。注意，在 Jenkinsfile-online 中分别定义了三个阶段 (stage) 用来部署至 Dev 环境和 Production 环境以及推送 tag，因此在流水线中依次需要对 deploy to dev, push with tag, deploy to production这三个阶段审核 3次，若不审核或点击终止则流水线将不会继续运行。

点击流水线中活动列表下当前正在运行的流水线序列号，页面展现了流水线中每一步骤的运行状态，注意，流水线刚创建时处于初始化阶段，可能仅显示日志窗口，待初始化 (约一分钟) 完成后即可看到流水线。黑色框标注了流水线的步骤名称，示例中流水线共 8 个 stage，分别在 Jenkinsfile-online 中被定义。

当前页面中点击右上方的查看日志，查看流水线运行日志。页面展示了每一步的具体日志、运行状态及时间等信息，点击左侧某个具体的阶段可展开查看其具体的日志。日志可下载至本地，如出现错误，下载至本地更便于分析定位问题。

谷粒商城集群篇 (五) --------- DevOps相关推荐

谷粒商城集群篇 (四) --------- KubeSphere
目录一.简介二.安装 1. 前提条件 2. 安装前提环境 ① 安装 helm (master 节点执行) ② 安装 Tiller (master 执行) ③ 安装 OpenEBS (master ...
谷粒商城集群篇 (六) --------- MySQL 集群
目录前言一.MySQL 集群原理 1. MySQL-MMM 2. MHA 3. InnoDB Cluster 二.Docker 安装模拟 MySQL 主从复制集群 1. 创建 Master 实例 ...
谷粒商城集群篇爬坑笔记--Gitee拉取项目报错、项目target文件不存在（部分项目不全）、SonarQube报错
Gitee拉取项目报错问题描述 Gitee拉取可能会报错: ERROR: Error cloning remote repo 'origin' hudson.plugins.git.GitExcep ...
谷粒商城电商项目高可用集群篇
更多视频,JAVA收徒 QQ:987115885谷粒商城电商项目高可用集群篇339.k8s-简介.mp4340.k8s-架构原理&核心概念.mp4341.k8s-集群搭建-环境准备.mp43 ...
高可用集群篇（五）-- K8S部署微服务
高可用集群篇(五)-- K8S部署微服务一.K8S有状态服务 1.1 什么是有状态服务 1.2 k8s部署MySQL 1.2.1 创建MySQL主从服务 1.2.2 测试主从配置 1.2.3 k8s ...
Zookeeper+Hadoop+Hbase+Hive+Kylin+Nginx集群搭建五(Hive篇)
Zookeeper+Hadoop+Hbase+Hive+Kylin+Nginx集群搭建五(Hive篇) 七.Hive安装配置 1.准备工作 2.安装hive 全文请看:https://blog.csd ...
基于Docker运行弹性集群的五个关键点第一篇：运行高可用模式
原文来源:Rancher Labs 类似Rancher这种的容器管理和编排工具,它可以很快地让每个组织获得高效的弹性集群管理能力.当前技术世界的发展形势就是让开发人员从繁琐的应用配置和管理中解放出来, ...
谷粒商城-分布式高级篇【业务编写】
谷粒商城-分布式基础篇[环境准备] 谷粒商城-分布式基础[业务编写] 谷粒商城-分布式高级篇[业务编写]持续更新谷粒商城-分布式高级篇-ElasticSearch 谷粒商城-分布式高级篇-分布式锁与 ...
PostgreSQL集群篇——PostgreSQL的配置文件解析
PostgreSQL集群篇--postgresql.conf配置文件解析正文日常中我们进行安装PostgreSQL后都需要对其进行配置基础配置,以便其能有效发挥出服务器的性能,下面是我进行整理后的 ...

谷粒商城集群篇 (五) --------- DevOps