diff --git a/SUMMARY.md b/SUMMARY.md index a1f5bdbea..e609d0b9a 100644 --- a/SUMMARY.md +++ b/SUMMARY.md @@ -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) diff --git a/images/00704eQkgy1fsaxszh01vj30da0j2jvn.jpg b/images/00704eQkgy1fsaxszh01vj30da0j2jvn.jpg deleted file mode 100644 index 69fcf3cb3..000000000 Binary files a/images/00704eQkgy1fsaxszh01vj30da0j2jvn.jpg and /dev/null differ diff --git a/images/gitops.png b/images/gitops.png new file mode 100644 index 000000000..610f9f62d Binary files /dev/null and b/images/gitops.png differ diff --git a/practice/ci-cd.md b/practice/ci-cd.md index fa0c0d418..59d380f11 100644 --- a/practice/ci-cd.md +++ b/practice/ci-cd.md @@ -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 Scott：ReactiveOps 公司的 SRE +> - Janakiram MSV：Janakiram & Associates 的首席分析师 +> - Craig Martin：Kenzan 的高级副总裁 +> - Container Solutions +> +> 主要内容 +> - DevOps 模式 +> - 云原生应用模式 +> - 使用 Spinnaker 做持续交付 +> - 云原生时代的监控 -本书的作者有： +本节本分内容引用自本书。 -- Rob Scott：ReactiveOps公司的SRE -- Janakiram MSV：Janakiram & Associates 的首席分析师 -- Craig Martin：Kenzan的高级副总裁 -- 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（的博客中有很多相关文章）和SecOps（Security Operation）。 +1. 通过克隆或拉取更新 Git 仓库（如 GitHub、GitLab），从 Git 中检索最新的配置清单 +2. 使用 `kubectl diff` 将 Git 配置清单与 Kubernetes 集群中的实时资源进行比较 +3. 最后，使用 `kubectl apply` 将更改推送到 Kubernetes 集群中 + +Kubernetes 中 GitOps 的流程如下图所示。 + +![Kubernetes 中的 GitOps 流程示意图](../images/gitops.png) + +该流程虽然看上去很简单，但是有很多隐藏的细节在其中，真正实施起来还是比较复杂的。 ### 云原生应用模式 > 云原生是通过构建团队、文化和技术，利用自动化和架构来管理系统的复杂性和解放生产力。——Joe Beda，Heotio 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官网查看。 - -下图是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/) diff --git a/practice/drone-ci-cd.md b/practice/drone-ci-cd.md index 3d2e70586..623c5358d 100644 --- a/practice/drone-ci-cd.md +++ b/practice/drone-ci-cd.md @@ -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/) diff --git a/practice/jenkins-ci-cd.md b/practice/jenkins-ci-cd.md index 0a647b254..fa58aef8b 100644 --- a/practice/jenkins-ci-cd.md +++ b/practice/jenkins-ci-cd.md @@ -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，部署应用 \ No newline at end of file