持续集成与部署分享_持续集成平台开源-优快云博客

本文链接：https://blog.youkuaiyun.com/2301_78659329/article/details/143216297

简介

持续集成的核心目标是利用自动化工具来标准化日常的打包和发布流程，从而减少团队成员对复杂流程的理解负担，并降低手动操作导致的错误。

一些澄清点:

目前我们用的Jenkins只是一个开源抽象的工具平台，它不默认集成相关的业务场景构建和发布能力，需要我们基于自己的流程做一些配套的开发工作。
一个团队一般是先有流程，再有工具，量体裁衣才能取得最佳的效果。比如有时候我们可能会在对某个开源方案不太了解的情况下直接完全套用，导致的问题可能是包体积变大，在某些场景下性能变差，扩展性差。
一般来说基础l的构建和发布流程会根据技术栈和业务场景来做细分。比如: B端、C端、客户端。目前我们只考虑了B端。
持续集成与部署的生命周期，不止在构建和发布的时候。构建之前，发布之后也算。比如代码提交前的校验、自动生成tag号、发布后的自动监控产出性能指标报告等。
构建和发布的一般思考点（衡量点）:
- 更新是否方便，能否做版本管理。
- 扩展性，易用性。
- 能减少多少手动化的操作。
- 能减少自动避免多少问题。比如代码风格分支不规范，不让构建通过。
- 构建和发布速度的快慢。
- 流程覆盖率。

流程

暂时无法在飞书文档外展示此内容

灰色代表一些准备的流程
红色代表核心流程

说明:

准备:

我们的构建流程都维护在gitlab仓库里面（这个能力在Jenkins里面叫 Shared Libraries），目的是为了把开发不需要理解的放到集中的地方维护，这样便于集中管理，如果需要更新逻辑改一个地方即可。

说明:

以上默认使用的是 Groovy Script语法，它是一种基于JVM的动态语言。简单理解就是它比java更方便Faas平台语言，使用的时候基本不用引入库，因为Jenkins内置了这些库。
Jenkins的流程标识是 Stage 它可以串行也可以并行。
stage 内部可以运行shell命令也可以内部定义的函数

使用分支 + commitHash 作为镜像名称是为了保证唯一性，也方便追溯线上部署代码对应的提交，同时也保证了唯一性。

构建:

【Lint】是可选流程，主要进行代码规范、风格、编译错误等步骤的检查。
【构建】前端用的vue-cli 后端用的mvn，编译成对应的产物即可。
1. 前端的产物是， js/css/html 等这些静态文件。
2. 后端产物是， jar包。
【打包镜像】前后端分别结合自己的Dockerfile 定义怎么去消费构建后的产物，其目的最终是让外部流量，可以访问到这些静态文件或者服务接口。
1. 前端: 容器里面会启动一个nginx，来为这些静态文件提供一个服务。
2. 后端: 容器里面会启动一个tomcat，来提供一个server。spring boot都封装好了，默认集成了这些，所以不用像前端那样再去写个服务的配置文件。
【发布】k8s 里面有一个叫Deployment的概念，可以理解它是管理容器pod的一个抽象概念。以下就是一个Deployment常用配置，对我们来说关心image字段即可，因为我们最终就是希望更新它。而更新deployment我们只需要知道空间名、deployment的名称和 image 三个字段即可。目前jenkins是通过发布完成后调用一个运维平台的接口来完成这个操作，这个接口背后调用的是k8s api 来实现的更新 image操作。

【访问】部署好的容器，可以
1. 通过提供nodeport ip，对外暴露ip和端口支持外部访问。
2. 也可以通过ingress -> service -> 容器的方式

区别:

NodePort

定义：NodePort 是一种将服务暴露到每个节点（Node）上的配置，通过 <NodeIP>:<NodePort> 的方式可以访问服务。Kubernetes 会在所有节点上开放一个静态的端口（NodePort），流量会通过这个端口转发到后端的 Pod。
端口范围：NodePort 可以使用的端口范围通常是 30000-32767。
使用场景：NodePort 适用于开发和测试环境，或者小规模的生产部署，尤其是当你不需要复杂的路由规则，只需要简单地对外暴露服务时。
限制：每个服务需要独立的端口，且端口数量有限。对于访问控制和流量管理能力有限，不支持复杂的路由规则。

Ingress

定义：Ingress 是 Kubernetes 的一个API对象，它管理外部访问到集群内服务的 HTTP 和 HTTPS 路由。Ingress 允许你定义可访问的 URL、负载均衡、SSL 终止以及基于名称的虚拟托管等。
功能：Ingress 可以提供丰富的路由规则，比如基于请求路径或主机名转发流量到不同的服务，并且可以集中管理 SSL/TLS 证书，支持虚拟主机等。
使用场景：Ingress 适用于生产环境，尤其是需要复杂路由、安全性和高级流量管理时。如果你有多个服务需要通过 HTTP/HTTPS 对外提供，并且想要使用一个统一的入口点，Ingress 是更好的选择。
依赖：Ingress 需要一个 Ingress Controller 来实现，比如 nginx-ingress、HAProxy Ingress 或者 Traefik。Ingress Controller 负责实现 Ingress 规则。

对比

复杂性：NodePort 更简单，适合快速和简单的暴露服务；Ingress 更复杂，但提供了更多的功能和灵活性。
端口管理：NodePort 需要管理和跟踪端口使用；Ingress 通过路径和域名管理访问，不需要关心端口。
性能：NodePort 会在所有节点上开放端口，可能会导致不必要的开销；Ingress Controller 可以优化路由，提供更好的性能。
安全性：Ingress 支持更先进的安全特性，如 SSL/TLS 终止和基于路径的访问控制。

总结

简单来说，如果你只是想简单地暴露一个服务，并且不介意使用较高端口号，NodePort 是一个简单直接的选择。而如果你需要一个功能更强大的、可以处理 HTTP/HTTPS 流量、支持复杂路由规则的解决方案，Ingress 是更合适的选择。在实际的生产环境中，Ingress 通常是首选，因为它提供了更高的灵活性和控制能力。

持续集成与部署分享

流程

涉及知识点