谷粒商城-集群-88-K8S 之 DevOps
一、项目开发需要考虑的维度
- Dev:怎么开发?
- Ops:怎么运维?
- 高并发:怎么承担高并发?
- 高可用:怎么做到高可用?
二、什么是DevOps
微服务、服务自治。
DevOps:Development 和 Operations 的组合
- DevOps 看作开发(软件工程)、技术运营和质量保证(QA)三者的交集
- 突出重视软件开发人员和运维人员的沟通合作,通过自动化流程使得软件构建、测试、发布更加快捷、频繁和可靠。
- DevOps 希望做到的是软件产品交付过程中 IT 工具链的打通,使得各个团队减少时间损耗,更加高效的协同工作。专家们总结出了DevOps 能力圈,良好的闭关可以大大增加整体的产出。
三、什么是CI&CD
1、持续集成(Continuous Integration)
CI的英文名称是Continuous Integration,中文翻译为:持续集成。
CI中,开发人员将会频繁地向主干提交代码,这些新提交的代码在最终合并到主干前,需要经过编译和自动化测试流进行验证。
持续集成(CI)是在源代码变更后自动检测、拉取、构建和(在大多数情况下)进行单元测试的过程。持续集成的目标是快速确保开发人员新提交的变更是好的,并且适合在代码库中进一步使用。CI的流程执行和理论实践让我们可以确定新代码和原有代码能否正确地集成在一起。
2、持续交付(Continuous Delivery)
CD可对应多个英文名称,持续交付Continuous Delivery和持续部署Continuous Deployment ,一下分别介绍。
完成 CI 中构建及单元测试和集成测试的自动化流程后,持续交付可自动将已验证的代码发布到存储库。为了实现高效的持续交付流程,务必要确保 CI 已内置于开发管道。持续交付的目标是拥有一个可随时部署到生产环境的代码库。
在持续交付中,每个阶段(从代码更改的合并,到生产就绪型构建版本的交付)都涉及测试自动化和代码发布自动化。在流程结束时,运维团队可以快速、轻松地将应用部署到生产环境中或发布给最终使用的用户。
3、持续部署(Continuous Deployment)
对于一个成熟的CI/CD管道(Pipeline)来说,最后的阶段是持续部署。作为持续交付——自动将生产就绪型构建版本发布到代码存储库——的延伸,持续部署可以自动将应用发布到生产环境。
持续部署意味着所有的变更都会被自动部署到生产环境中。持续交付意味着所有的变更都可以被部署到生产环境中,但是出于业务考虑,可以选择不部署。如果要实施持续部署,必须先实施持续交付。
持续交付并不是指软件每一个改动都要尽快部署到产品环境中,它指的是任何的代码修改都可以在任何时候实施部署。
持续交付表示的是一种能力,而持续部署表示的则一种方式。持续部署是持续交付的最高阶段
持续部署主要好处是,可以相对独立地部署新的功能,并能快速地收集真实用户的反馈。
"You build it you run it" 这是 Amazon 一年可以完成 5000 万次部署,平均每个工程师每天部署超过50次的核心秘籍。
四、构建流水线
基于Spring Boot项目构建流水线
Jenkinsfile in SCM 意为将 Jenkinsfile 文件本身作为源代码管理 (Source Control Management) 的一部分,根据该文件内的流水线配置信息快速构建工程内的 CI/CD 功能模块,比如阶段 (Stage),步骤 (Step) 和任务 (Job)。因此,在代码仓库中应包含 Jenkinsfile。
本示例演示如何通过 GitHub 仓库中的 Jenkinsfile 来创建流水线,流水线共包括 8 个阶段,最终将演示示例部署到 KubeSphere 集群中的开发环境和生产环境且能够通过公网访问。 仓库中的 dependency 分支为缓存测试用例,测试方式与 master 分支类似,对 dependency 的多次构建可体现出利用缓存可以有效的提升构建速度。
流水线概览
下面的流程图简单说明了流水线完整的工作过程:
流程说明:
- 阶段一. 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 环境。
创建凭证
凭证 (Credential)是包含了敏感数据的对象,例如用户名密码、SSH 密钥和一些 Token 等。流水线运行中,会与很多外部环境交互,如拉取代码,push/pull 镜像,SSH 连接至相关环境中执行脚本等,此过程中需提供一系列凭证,而这些凭证不应明文出现在流水线中,尤其是代码仓库管理 Jenkinsfile 文件的情况,用户需统一管理这些凭证,在流水线中只需要提供凭证的 ID。目前支持以下四种凭证类型:
- 账户凭证:常用于用户名和密码验证登录的代码仓库
- SSH:通过用户名、密码和私钥的方式
- 秘密文本:通过秘钥的方式连接
- kubeconfig:常用于配置跨集群认证,页面将自动获取当前 Kubernetes 集群的 kubeconfig 文件内容。
创建 DockerHub、GitHub 和 kubeconfig (kubeconfig 用于访问接入正在运行的 Kubernetes 集群) 等一共 3 个凭证 (credentials) ,参考 创建凭证 依次创建这三个凭证。
创建SonarQube Token:
访问 SonarQube 并创建 Token,创建一个 Java 的 Token 并复制。
查看SonarQube暴露的端口:
# 获取开启的服务
[root@master ~]# kubectl get svc -A
可以看到 SonarQube 开放的端口为32245,所以,需要在青云控制台添加端口转发规则和开放该端口防火墙。
防火墙:
登录到 SonarQube 服务,默认账号密码为:admin/admin
gulimall-analyze: 00e44e7ca60c3b96508790e65219a05a3cbac9bf
至此,我们的四个凭证创建OK了。
DevOps流水线:
相关文章:
DevOps漫谈之一:DevOps、CI、CD都是什么鬼?
DevOps到底是什么意思?
基于Spring Boot项目构建流水线
Jenkins详细教程
为者常成,行者常至
自由转载-非商用-非衍生-保持署名(创意共享3.0许可证)