pull/457/head
Jimmy Song 2022-01-18 10:29:07 +08:00
parent a92d07c750
commit 6f4aad3a14
No known key found for this signature in database
GPG Key ID: CBA666E6EF8B2C3A
6 changed files with 90 additions and 111 deletions

View File

@ -198,7 +198,7 @@
* [服务编排管理](practice/services-management-tool.md)
* [使用 Helm 管理 Kubernetes 应用](practice/helm.md)
* [构建私有 Chart 仓库](practice/create-private-charts-repo.md)
* [持续集成与发布](practice/ci-cd.md)
* [持续集成与发布CI/CD](practice/ci-cd.md)
* [使用 Jenkins 进行持续集成与发布](practice/jenkins-ci-cd.md)
* [使用 Drone 进行持续集成与发布](practice/drone-ci-cd.md)
* [更新与升级](practice/update-and-upgrade.md)

Binary file not shown.

Before

Width:  |  Height:  |  Size: 244 KiB

BIN
images/gitops.png 100644

Binary file not shown.

After

Width:  |  Height:  |  Size: 38 KiB

View File

@ -1,110 +1,91 @@
# 持续集成与发布
# 持续集成与发布CI/CD
持续集成与发布简称CI/CD是微服务构建的重要环节也是DevOps中推崇的方法论。如何在kubernetes中使用持续构建与发布工具?可以既可以与企业内部原有的持续构建集成,例如Jenkins也可以在kubernetes中部署一套新的持续构建与发布工具例如Drone。
持续集成与发布,简称 CI/CD是微服务构建的重要环节也是 DevOps 中推崇的方法论。如何在 Kubernetes 中使用持续构建与发布工具?可以既可以与企业内部原有的持续构建集成,例如 Jenkins也可以在 Kubernetes 中部署一套新的持续构建与发布工具,例如 Drone、ArgoCD、Tekton 等
众所周知Kubernetes并不提供代码构建、发布和部署所有的这些工作都是由CI/CD工作流完成的最近TheNewStack又出了本小册子117页介绍了Kubernetes中CI/CD的现状。下载本书的PDF请访问https://thenewstack.io/ebooks/kubernetes/ci-cd-with-kubernetes/
众所周知 Kubernetes 并不提供代码构建、发布和部署,所有的这些工作都是由 CI/CD 工作流完成的TheNewStack 推出过一本专门介绍 Kubernetes 中的 CI/CD 的白皮书 [CI/CD with Kubernetes](https://thenewstack.io/ebooks/kubernetes/ci-cd-with-kubernetes/),本书共 117 页,介绍了 Kubernetes 中 CI/CD 的现状。
![CI/CD with Kubernetes](../images/00704eQkgy1fsaxszh01vj30da0j2jvn.jpg)
> **CI/CD with Kubernetes 简介 **
>
> 主要作者
> - Rob ScottReactiveOps 公司的 SRE
> - Janakiram MSVJanakiram & Associates 的首席分析师
> - Craig MartinKenzan 的高级副总裁
> - Container Solutions
>
> 主要内容
> - DevOps 模式
> - 云原生应用模式
> - 使用 Spinnaker 做持续交付
> - 云原生时代的监控
本书的作者有:
节本分内容引用自本书。
- Rob ScottReactiveOps公司的SRE
- Janakiram MSVJanakiram & Associates 的首席分析师
- Craig MartinKenzan的高级副总裁
- Container Solutions
### DevOps 模式
这本小册子里主要主要介绍了以下几点:
在云原生应用诞生之前,就已经有很多流行的自动化运维工具,比如 Chef、Puppet 等,后来又诞生了 CI/CD 流水线Docker 和 DevOps 使用容器解除开发和运维之间的隔阂但同时也带来了一些挑战比如频繁的发布变更如何控制如何控制容器集群的行为如何拆分应用到容器之中等。这是一个专门用于容器编排调度的工具呼之欲出Kubernetes 的出现彻底改变了局面,可以说它直接改变了应用的基础架构。
- DevOps模式
- 云原生应用模式
- 使用Spinnaker做持续交付
- 云原生时代的监控
![Kubernetes 改变了应用的基础架构](../images/00704eQkgy1fsayashxz3j31c00w6aed.jpg)
### DevOps模式
Kubernetes 细化的应用程序的分解粒度,同时将服务发现、配置管理、负载均衡和健康检查等作为基础设施的功能,简化了应用程序的开发。
这一章从一些流行的自动化运维工具讲起比如Chef、Puppet等引申出CI/CD流水线进而引出Docker和DevOps将容器如何解除开发和运维之间的隔阂但同时也带来了一些挑战比如频繁的发布变更如何控制如何控制容器集群的行为如何拆分应用到容器之中等。这是一个专门用于容器编排调度的工具呼之欲出Kubernetes的出现彻底改变了局面可以说它直接改变了应用的基础架构
而 Kubernetes 这种声明式配置尤其适合 CI/CD 流程,况且现在还有如 Helm、Draft、Spinnaker、Skaffold 等开源工具可以帮助我们发布 Kuberentes 应用
![Kubernetes改变了应用的基础架构](../images/00704eQkgy1fsayashxz3j31c00w6aed.jpg)
![Kubernetes 中的 CI/CD](../images/00704eQkgy1fsayfzk3ezj31bu0tkdky.jpg)
Kubernetes细化的应用程序的分解粒度同时将服务发现、配置管理、负载均衡和健康检查等作为基础设施的功能简化了应用程序的开发
有了基于 Kubernetes 的 CI/CD 流程后,又出现了 GitOps 和 DevSecOps
而Kubernetes这种声明式配置尤其适合CI/CD流程况且现在还有如Helm、Draft、Spinnaker、Skaffold等开源工具可以帮助我们发布Kuberentes应用。
## GitOps
![Kubernetes中的CI/CD](../images/00704eQkgy1fsayfzk3ezj31bu0tkdky.jpg)
GitOps 是一套使用 Git 来管理基础设施和应用配置的实践。对于 Kubernetes 来说,这意味着任何 GitOps 操作者都需要依次自动完成以下步骤:
有了基于Kubernetes的CI/CD流程后又诞生了GitOps<https://www.weave.works>的博客中有很多相关文章和SecOpsSecurity Operation
1. 通过克隆或拉取更新 Git 仓库(如 GitHub、GitLab从 Git 中检索最新的配置清单
2. 使用 `kubectl diff` 将 Git 配置清单与 Kubernetes 集群中的实时资源进行比较
3. 最后,使用 `kubectl apply` 将更改推送到 Kubernetes 集群中
Kubernetes 中 GitOps 的流程如下图所示。
![Kubernetes 中的 GitOps 流程示意图](../images/gitops.png)
该流程虽然看上去很简单,但是有很多隐藏的细节在其中,真正实施起来还是比较复杂的。
### 云原生应用模式
> 云原生是通过构建团队、文化和技术利用自动化和架构来管理系统的复杂性和解放生产力。——Joe BedaHeotio CTO联合创始人
这一章的重点是给出了云原生应用的10条关键属性。
云原生应用的 10 条关键属性。
1. 使用轻量级的容器打包
2. 使用最合适的语言和框架开发
3. 以松耦合的微服务方式设计
4. 以API为中心的交互和协作
4. 以 API 为中心的交互和协作
5. 无状态和有状态服务在架构上界限清晰
6. 不依赖于底层操作系统和服务器
7. 部署在自服务、弹性的云基础设施上
8. 通过敏捷的DevOps流程管理
8. 通过敏捷的 DevOps 流程管理
9. 自动化能力
10. 通过定义和策略驱动的资源分配
作者然后将应用程序架构中的不同组件映射到云原生的工作负载中,如下图所示:
将应用程序架构中的不同组件映射到云原生的工作负载中,如下图所示:
![云原生工作负载](../images/00704eQkgy1fsayrk6vppj31bu0w0gsd.jpg)
这也是DevOps需要关注的部分如何将云原生的组件映射为Kubernetes的原语即Kubernetes里的各种资源对象和概念组合如下图所示。
这也是 DevOps 需要关注的部分,如何将云原生的组件映射为 Kubernetes 的原语(即 Kubernetes 里的各种资源对象和概念组合)呢?如下图所示。
![云原生工作负载映射到Kuberentes原语](../images/00704eQkgy1fsaytbabxgj31c00w2n4r.jpg)
![云原生工作负载映射到 Kuberentes 原语](../images/00704eQkgy1fsaytbabxgj31c00w2n4r.jpg)
总结概括为以下10条
在 Kubernetes 中发布应用时,需要注意的点总结概括为以下 10 条:
1. 不要直接部署裸的Pod。
2. 为工作负载选择合适的Controller。
3. 使用Init容器确保应用程序被正确的初始化。
4. 在应用程序工作负载启动之前先启动service。
5. 使用Deployment history来回滚到历史版本。
6. 使用ConfigMap和Secret来存储配置。
7. 在Pod里增加Readiness和Liveness探针。
8. 给Pod设置CPU和内存资源限额。
9. 定义多个namespace来限制默认service范围的可视性。
10. 配置HPA来动态扩展无状态工作负载。
1. 不要直接部署裸的 Pod。
2. 为工作负载选择合适的 Controller。
3. 使用 Init 容器确保应用程序被正确的初始化。
4. 在应用程序工作负载启动之前先启动 service。
5. 使用 Deployment history 来回滚到历史版本。
6. 使用 ConfigMap Secret 来存储配置。
7. 在 Pod 里增加 Readiness Liveness 探针。
8. 给 Pod 设置 CPU 和内存资源限额。
9. 定义多个 namespace 来限制默认 service 范围的可视性。
10. 配置 HPA 来动态扩展无状态工作负载。
### 使用Spinnaker进行持续交付
## 参考
作者首先讲到了Spinnaker的各种特性比如面向微服务啦云原生的交付工具啦可视化的交付和基础设施啦支持多个region支持容器和Kubernetes等等不一而足感兴趣大家可以自己看下报告或者登陆Spinnaker官网<https://www.spinnaker.io>查看。
下图是Spinnaker中的组件和角色的交互关系。
![spinnaker中的组件及角色交互关系](../images/00704eQkgy1fsaz2wirz9j31bs0vygsb.jpg)
下图是Spinnaker的几种不同环境的流水线。
![Spinnaker部署流水线](../images/00704eQkgy1fsaz3yo227j31c60mgdim.jpg)
![Spinnaker的预发布流水线](../images/00704eQkgy1fsaz50k2atj31bs0mitbn.jpg)
![Spinnaker的生产流水线](../images/00704eQkgy1fsaz5n5qs9j31by0motbm.jpg)
总之作者就是想说Spinnaker很好很强大啦足以满足您对云原生应用CI/CD的需求。
### 云原生时代的监控
监控是为了实现系统的可观察性,不要以为监控就是简单的出个监控页面,监控其实包括以下部分:
- 日志收集
- 监控和指标度量
- 追踪
- 告警和可视化
要把其中任何一个方面做好都不容易。
![可观察性](../images/00704eQkgy1fsazabn0b9j31by0w6791.jpg)
作者主要讲述的Prometheus和Grafana的开源监控方案。
![Prometheus生态系统中的组件](../images/00704eQkgy1fsazcclee6j31c20w6n5y.jpg)
这一章我不详述,感兴趣大家可以查看报告原文。
- [CI/CD with Kubernetes - thenewstack.io](https://thenewstack.io/ebooks/kubernetes/ci-cd-with-kubernetes/)

View File

@ -1,30 +1,30 @@
# 使用Drone进行持续构建与发布
# 使用 Drone 进行持续构建与发布
[Drone](https://drone.io)是一个用Go语言开发的基于容器运行的持续集成软件。
[Drone](https://drone.io) 是一个用 Go 语言开发的基于容器运行的持续集成软件。
## 配置GitHub
## 配置 GitHub
使用Drone对GitHub上的代码进行持续构建与发布需要首先在GitHub上设置一个OAuth如下
使用 Drone GitHub 上的代码进行持续构建与发布,需要首先在 GitHub 上设置一个 OAuth如下
**1. 在Github上创建一个新的OAtuh应用**
**1. 在 Github 上创建一个新的 OAtuh 应用 **
访问[此頁面](https://github.com/settings/applications/new)创建新的OAuth应用。
访问 [此页面](https://github.com/settings/applications/new),创建新的 OAuth 应用。
![OAuth注册](../images/github-oauth-register.jpg)
![OAuth 注册](../images/github-oauth-register.jpg)
填写应用程序的地址,因为是在本地与行,所以我们都填`http://localhost`。
填写应用程序的地址,因为是在本地与行,所以我们都填 `http://localhost`
**2. 获取OAtuh Client ID和Client Secret**
**2. 获取 OAtuh Client ID Client Secret**
在注册完成后就可以获得如下图所示的OAuth Client ID和Client Secret保存下来我们后面要用到。
在注册完成后就可以获得如下图所示的 OAuth Client ID Client Secret保存下来我们后面要用到。
![OAuth key](../images/github-oauth-drone-key.jpg)
## 使用docker-compose单机运行
## 使用 docker-compose 单机运行
我们在本地环境使用docker-compose按照[Drone官方安装文档](http://docs.drone.io/installation/)安装配置Drone。
我们在本地环境,使用 docker-compose按照 [Drone 官方安装文档](http://docs.drone.io/installation/) 安装配置 Drone。
我们将代码托管在GitHub上需要Drone可以持续集成和发布GitHub的代码因此需要修改`docker-compose.yaml`文件中的GitHub配置。
我们将代码托管在 GitHub 上,需要 Drone 可以持续集成和发布 GitHub 的代码,因此需要修改 `docker-compose.yaml` 文件中的 GitHub 配置。
```yaml
version: '2'
@ -61,32 +61,31 @@ services:
- DRONE_SECRET=${DRONE_SECRET}
```
- `/var/lib/drone`是在本地挂载的目录请确保该目录已存在且可以被docker访问到Mac下可以在docker的共享目录中配置。
- `DRONE_SECRET`可以是一个随机的字符串,要确保`drone-server`与`drone-client`的`DRONE_SECRET`相同。
- `DRONE_GITHUB_CLIENT`和`DRONE_GITHUB_SECRET`即在前面申请的OAuth的Client ID和Client Secret。
- `/var/lib/drone` 是在本地挂载的目录,请确保该目录已存在,且可以被 docker 访问到Mac 下可以在 docker 的共享目录中配置。
- `DRONE_SECRET` 可以是一个随机的字符串,要确保 `drone-server` `drone-client` `DRONE_SECRET` 相同。
- `DRONE_GITHUB_CLIENT` `DRONE_GITHUB_SECRET` 即在前面申请的 OAuth Client ID Client Secret。
### 启动Drone
### 启动 Drone
使用下面的命令在本地启动drone
使用下面的命令在本地启动 drone
```bash
docker-compose up
```
这样是在前台启动,加上`-d`参数就可以在后台启动。
这样是在前台启动,加上`-d` 参数就可以在后台启动。
访问 `http://localhost` 可以看到登陆画面。
![Drone登陆界面](../images/drone-login-github.jpg)
![Drone 登陆界面](../images/drone-login-github.jpg)
授权后可以看到GitHub repo设置。
授权后可以看到 GitHub repo 设置。
![Github启用repo设置](../images/drone-github-active.jpg)
![Github 启用 repo 设置](../images/drone-github-active.jpg)
![Github单个repo设置](../images/drone-github-repo-setting.jpg)
![Github 单个 repo 设置](../images/drone-github-repo-setting.jpg)
## 参考
- [Drone Installation](http://docs.drone.io/installation/)
- [Github - Drone](https://github.com/drone/drone)
- [harness/drone - github.com](https://github.com/harness/drone)
- [Drone 搭配 Kubernetes 升級應用程式版本 - blog.wu-boy.com](https://blog.wu-boy.com/2017/10/upgrade-kubernetes-container-using-drone/)

View File

@ -1,20 +1,19 @@
# 使用Jenkins进行持续集成与发布
# 使用 Jenkins 进行持续集成与发布
我们基于Jenkins的CI/CD流程如下所示。
我们基于 Jenkins CI/CD 流程如下所示。
![基于Jenkins的持续集成与发布](../images/kubernetes-jenkins-ci-cd.png)
![基于 Jenkins 的持续集成与发布](../images/kubernetes-jenkins-ci-cd.png)
## 流程说明
应用构建和发布流程说明。
1. 用户向Gitlab提交代码代码中必须包含`Dockerfile`
1. 用户向 Gitlab 提交代码,代码中必须包含 `Dockerfile`
2. 将代码提交到远程仓库
3. 用户在发布应用时需要填写git仓库地址和分支、服务类型、服务名称、资源数量、实例个数确定后触发Jenkins自动构建
4. Jenkins的CI流水线自动编译代码并打包成docker镜像推送到Harbor镜像仓库
5. Jenkins的CI流水线中包括了自定义脚本根据我们已准备好的kubernetes的YAML模板将其中的变量替换成用户输入的选项
6. 生成应用的kubernetes YAML配置文件
7. 更新Ingress的配置根据新部署的应用的名称在ingress的配置文件中增加一条路由信息
8. 更新PowerDNS向其中插入一条DNS记录IP地址是边缘节点的IP地址。关于边缘节点请查看[边缘节点配置](edge-node-configuration.md)
9. Jenkins调用kubernetes的API部署应用
3. 用户在发布应用时需要填写 git 仓库地址和分支、服务类型、服务名称、资源数量、实例个数,确定后触发 Jenkins 自动构建
4. Jenkins 的 CI 流水线自动编译代码并打包成 docker 镜像推送到 Harbor 镜像仓库
5. Jenkins 的 CI 流水线中包括了自定义脚本,根据我们已准备好的 kubernetes 的 YAML 模板,将其中的变量替换成用户输入的选项
6. 生成应用的 Kubernetes YAML 配置文件
7. 更新 Ingress 的配置,根据新部署的应用的名称,在 ingress 的配置文件中增加一条路由信息
8. 更新 PowerDNS向其中插入一条 DNS 记录IP 地址是边缘节点的 IP 地址。关于边缘节点,请查看 [边缘节点配置](edge-node-configuration.md)
9. Jenkins 调用 kubernetes 的 API部署应用