KubeSphere创建DevOps工程

最新推荐文章于 2024-10-11 14:06:34 发布

~Rookie~Newbie~Noob~

最新推荐文章于 2024-10-11 14:06:34 发布

阅读量1.1k

点赞数 2

分类专栏： KubeSphere DevOps CI/CD 文章标签：运维 jenkins

本文链接：https://blog.csdn.net/weixin_32196893/article/details/118682767

版权

KubeSphere 同时被 3 个专栏收录

5 篇文章 0 订阅

订阅专栏

DevOps

1 篇文章 0 订阅

订阅专栏

CI/CD

1 篇文章 0 订阅

订阅专栏

参考资料：https://v2-1.docs.kubesphere.io/docs/zh-CN/quick-start/devops-online/

DevOps

DevOps: Development 和 Operation的组合。

DevOps 可以被认为是开发（软件工程）、技术运营和质量保障（QA）三者的交集。
突出重视软件开发人员和运维人员的沟通合作，通过自动化流程来使得软件构建、测试、发布更加快捷、频繁和可靠
DevOps希望做到的是软件产品交付过程中IT工具链的打通，使得各个团队减少时间损耗，更加高效地协同工作。

CI/CD

持续集成（Continuous Integration）

持续集成式指软件个人研发的部分向软件整体部分交付，频繁进行集成以便更快地发现其中的错误。
CI需要具备这些：
- 全面的自动化测试：这是时间持续集成&持续部署的基础，同时，选择合适的自动化测试工具也极其重要。
- 灵活的基础设施：容器，虚拟机的存在让开发人员和QA人员不必再大费周折。
- 版本控制工具：如Git，CVS，SVN等。
- 自动化的构建和软件发布流程工具：如Jenkin
- 反馈机制：如构建/测试的失败，可以快速地反馈到相关负责人，以尽快解决达到一个更稳定的版本。

持续交付（Continuous Delivery）

持续交付再持续集成的基础上，将集成后的代码部署到更贴近真实运行环境中【类生产环境（produ ction-like environment）】。持续交付优先于整个产品生命周期的软件部署，建立再高水平自动化持续集成之上。
持续交付和持续集成的优点非常相似：

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

持续部署（Continuous Deployment）

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

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

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

Jams Bowman 绘制的持续交付工具链图：

KubeSphere构建流水线

流水线工作的完整过程：

在这里插入图片描述流程说明：

阶段一：Checkout SCM，拉取GitHub仓库代码。
阶段二：Unit test，单元测试，如果测试通过才继续下面的任务。
阶段三：SonarQube analysis，代码质量检测、
阶段四：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环境

用文章《kubesphere多租户管理》中创建的project-regular用户登录KubeSphere，进入DevOps工程创建凭证。
1. 创建DockerHub凭证
  - 凭证 ID：必填，此 ID 将用于仓库中的 Jenkinsfile，此示例中可命名为 dockerhub-id
  - 类型：选择账户凭证
  - 用户名：填写您个人的 DockerHub 的用户名
  - token / 密码：您个人的 DockerHub 的密码
  - 描述信息：介绍凭证，比如此处可以备注为 DockerHub 登录凭证
2. 创建GitHub凭证，由于网络的原因，国内可以gitee替代。由于Jenkins拉取GitHub代码可能会失败，在国内使用gitee更可靠一些。
3. 创建kubeconfig凭证，填写用户名，选择kubeconfig的凭证类型，点击确定即可。
  说明：kubeconfig 类型的凭证用于访问接入正在运行的 Kubernetes 集群，在流水线部署步骤将用到该凭证。注意，此处的 Content 将自动获取当前 KubeSphere 中的 kubeconfig 文件内容，若部署至当前 KubeSphere 中则无需修改，若部署至其它 Kubernetes 集群，则需要将其 kubeconfig 文件的内容粘贴至 Content 中。
4. 创建sonar凭证。
  找到sonarqube服务，找到端口号，查看web页面
  
  创建sonar-qube凭证
使用devops-java-sample工程构建，修改工程目录下Jenkinsfile-online文件
创建项目，创建两个资源型项目，如图：kubesphere-sample-dev和kubesphere-sample-prod

两个项目的名称保持要与deploy目录下中yaml文件中的namespace的值保持一致。
构建流水线
1. 进入devops工程
2. 创建流水线
  
  开始构建
  
  此步骤真正分析代码
  
  这里显示代码已经分析完成
  
  我们可以去snoarqube的web界面查看代码分析结果
  
  再回来查看，等待确认发布到开发环境中
  
  点击Processed，发布生成环境成功，并且
  
  后面由于项目中Jenkinsfile-online脚本（上传tag的地址问题）的问题，没有发布tag成功，并且发布到生产环境跳过了。
3. 现在我们可以访问dev环境，测试发布到dev环境的结果。
  从日志中找到端口号30861
  
  访问devops-java-sample项目api成功