banzaicloud/pipeline

Pipeline

Pipeline 是一个功能丰富的应用平台，构建于Kubernetes之上，专为容器设计，用于自动化DevOps体验、持续应用开发和部署生命周期。它通过将Kubernetes转变为集成CI/CD、集中式日志、监控、企业级安全和自动扩展的功能丰富应用平台，使开发者能够在几分钟内从代码提交实现应用扩展。

核心功能与特性

• 集群配置：在所有支持的云提供商、本地环境或混合配置中，配置高可用Kubernetes集群
• 应用聚焦：专注于构建优秀应用，将运维、故障转移、构建流水线、补丁和安全等复杂工作交给Banzai Pipeline处理
• 扩展能力：支持SLA规则，实现弹性、故障转移和自动扩展
• 可观测性：提供基础设施、Kubernetes集群和已部署应用的集中式日志收集、追踪和高级监控支持
• 快速集成：使用容器原生CI/CD工作流引擎，几分钟内从代码提交实现应用扩展
• 开发指南：使用您喜爱的开发框架，让Pipeline自动处理其余工作

云提供商支持

Banzai Cloud支持在所有主要云提供商上运行Kubernetes和基于容器的应用平台Pipeline，实现供应商之间的无缝、自动化移植。

当前支持的云提供商：

• 阿里云ACK
• 亚马逊EKS
• 谷歌GKE
• 微软AKS
• Oracle OKE

Pipeline支持"BYOC（自带集群）"模式，也可以采用和管理现有的Kubernetes集群。

即将支持的云提供商：

• Digital Ocean DOK

架构概述

Pipeline采用典型的云原生架构，充分利用按需交付、全球部署、弹性和高级服务的优势。它显著提高了开发者生产力、业务敏捷性、可扩展性、可用性、资源利用率和成本节约。

Pipeline使用Golang编写，基于公有云提供商API、Kubernetes、Helm、Prometheus、Grafana、Docker、Vault以及CNCF生态系统中的其他开源技术构建——但所有这些都通过安全的REST API、UI或CLI为最终用户抽象化。

控制平面

Pipeline控制平面是Pipeline平台所有组件的集中装配位置，运行所有提供的服务，如CI/CD、认证、日志收集、监控、仪表板、应用注册中心、开发指南定义、安全扫描等。控制平面本身也是Kubernetes部署，且与云无关——目前提供AWS、Azure、Google Cloud和Minikube（用于本地/开发目的）的开箱即用部署。

默认控制平面部署结构如下：

（此处应有控制平面架构图，原文档中为"docs/images/multi.png"）

要在支持的提供商上启动Pipeline控制平面，请遵循此https://github.com/banzaicloud/pipeline-cp-launcher/blob/master/README.md%E3%80%82

已配置集群

使用Pipeline部署的典型集群/应用（例如使用Spark/Zeppelin开发指南部署）结构如下：

（此处应有集群架构图，原文档中为"docs/images/spark-cluster-aws.png"）

安装

要试用API，请遵循此安装指南。

依赖管理

管理所有依赖项对于获得可通过go get获取的包至关重要。有关详细信息，请遵循我们的依赖管理指南。

API规范

Pipeline API使用OpenAPI 3.0规范（前身为Swagger）描述。获取规范请访问此https://github.com/banzaicloud/pipeline/blob/master/docs/openapi/pipeline.yaml%E3%80%82

生成的API客户端

基于OpenAPI 3.0描述符，我们为不同语言生成了语言客户端：

• https://github.com/banzaicloud/pipeline/blob/master/client/README.md

创建Kubernetes集群

Kubernetes集群可以显式创建（通过调用API直接触发）、作为CI/CD流程的一部分（集群作为流程的一部分按需创建）或通过部署创建。

使用API创建

在支持的云提供商上创建Kubernetes集群的最简单方法是使用REST API，可作为Postman集合使用。集群可以被创建、更新或删除。

使用CI/CD创建

Pipeline内置CI/CD系统。一旦GitHub仓库配置了提交钩子，Pipeline可以自动克隆、构建和部署应用。目标Kubernetes集群作为CI/CD流程的一部分按需创建（或重用）。有关CI/CD示例，请遵循此CI/CD指南。CI/CD流程还会进行静态代码分析和镜像安全扫描。

（此处应有CI/CD流程图，原文档中为"docs/images/clair-flow.png"）

有关创建集群的其他方法，请遵循创建集群指南。

应用部署

Pipeline启动后，可以使用任何Helm仓库的RESTful API或内置CI/CD引擎部署应用。

使用API部署

我们引入了一项新功能，除了Helm CLI和gRPC外，还可以使用RESTful API部署用Helm打包的应用。

（此处应有部署流程图，原文档中为"/docs/images/tiller-rest-flow.png"）

部署应用的最简单方法是通过以下Postman示例。

使用CI/CD部署

有关更多CI/CD示例，请遵循此CI/CD指南。

有关应用部署的其他方法，请遵循部署指南。

安全

认证

Pipeline的"认证"使用OAuth2，通过将用户认证委托给托管用户账户的服务实现。有许多OAuth2身份提供商：GitHub、Google、**、Azure Active Directory、和Salesforce等。目前Pipeline支持GitHub，主要因为我们的CI/CD组件由GitHub事件触发，但我们使用非常灵活的github.com/qor/auth包，该包通过"插件"机制支持许多主要提供商，因此只需更改配置即可支持上述提供商（除传统用户名/密码外）。此解决方案的主要优势是我们无需存储任何用户凭据，用户可以使用其在这些站点的现有账户访问我们的服务。OAuth2流程在此图中突出显示。当用户访问https://github.com/banzaicloud/pipeline%E6%97%B6%EF%BC%8C%E4%BB%96%E4%BB%AC%E5%BF%85%E9%A1%BB%E9%A6%96%E5%85%88%E4%BD%BF%E7%94%A8GitHub%E7%99%BB%E5%BD%95%EF%BC%8C%E4%BB%A5%E4%BE%BF%E5%9C%A8RDBMS%E4%B8%AD%E5%88%9B%E5%BB%BA%E7%94%A8%E6%88%B7%E8%AE%B0%E5%BD%95%E2%80%94%E2%80%94%E7%9B%B8%E5%85%B3REST%E7%AB%AF%E7%82%B9%E4%B8%BA%EF%BC%9A%60https://$HOST/auth/login%60%E3%80%82

（此处应有认证流程图，原文档中为"/docs/images/authn-vault-flow.png"）

Bearer令牌 - JWT

JWT令牌是Bearer令牌的理想选择。请注意，JWT基于RFC 7519标准。JWT的主要优势是"自包含"，因此支持无状态认证。服务器的受保护路由将检查Authorization头中的有效JWT，如果存在，用户将基于令牌的"scopes"字段被允许访问受保护资源。除非您希望允许用户立即"撤销"生成的令牌（而不是等待令牌过期），否则JWT是无状态的。要能够撤销JWT令牌，您必须维护一个黑名单或白名单，存储所有已撤销或有效的令牌。

Vault

为了存储令牌，我们选择了HashiCorp的Vault。然而，决定标准化Vault的另一个主要因素是Vault与Kubernetes认证API的良好集成。Vault启动后，必须启用和配置Kubernetes认证后端，这样Vault可以基于ServiceAccount JWT令牌"租赁"令牌以使用其API。这使在同一Kubernetes集群中运行的其他应用能够调用Vault，从而可以使用具有各种TTL的"严格范围令牌"。

（此处应有令牌请求流程图，原文档中为"/docs/images//token-request-vault-flow.png"）

动态密钥

Vault支持动态密钥，因此我们决定添加支持并使其成为所有支持部署的开箱即用解决方案。为了加强安全性，每个应用都获得针对请求服务的专用凭证，此凭证仅属于请求应用且具有固定过期时间。由于凭证是专用的，可以跟踪哪个应用在何时访问了服务，并且由于它们在中央位置（Vault）管理，因此易于撤销。由于Pipeline在Kubernetes上运行，我们可以应用基于Kubernetes Service Account的认证来首先获取Vault令牌，然后可以基于我们配置的Vault角色将其交换为凭证（用户名/密码）。有关事件序列的更多详细信息，请参见此图：

（此处应有动态密钥流程图，原文档中为"/docs/images/vault-dynamic-secrets.gif"）

如您所见，通过此解决方案，https://github.com/banzaicloud/pipeline%E8%83%BD%E5%A4%9F%E8%BF%9E%E6%8E%A5%E5%88%B0%EF%BC%88%E4%BE%8B%E5%A6%82%EF%BC%89MySQL%EF%BC%8C%E5%8F%AA%E9%9C%80%E5%9C%A8%E9%85%8D%E7%BD%AE%E7%9A%84**Kubernetes Service Account**中运行，无需在应用配置期间输入任何用户名/密码。

实现数据库连接动态密钥分配和上述Vault配置的代码可以在我们的开源项目https://github.com/banzaicloud/bank-vaults/tree/master%E4%B8%AD%E6%89%BE%E5%88%B0%E3%80%82

监控

Pipeline默认监控基础设施、Kubernetes集群和已部署的应用。我们使用Prometheus并部署联邦Prometheus集群（使用TLS）来安全监控基础设施。我们基于集群布局和已配置的应用部署默认Grafana仪表板和警报。有关监控的更多信息，请关注这些文章。

（此处应有监控架构图，原文档中为"docs/images/prometheus-federation.png"）

集中式日志

我们使用fluentd和fluent-bit将应用日志移至集中位置。为了收集所有日志，我们将fluent-bit部署为DaemonSet。这些pod将从主机挂载Docker容器日志，并传输到Fluentd服务进行进一步转换。有关日志收集的更多信息，请关注这些文章。

（此处应有日志架构图，原文档中为"docs/images/pipeline-log.png"）

操作器

Pipeline安装和运行Kubernetes操作器，将人工操作知识转化为代码。有（云无关的）操作器支持部署、存储管理、自动扩展等。

• https://github.com/banzaicloud/logging-operator
• https://github.com/banzaicloud/pvc-operator
• https://github.com/banzaicloud/hpa-operator
• https://github.com/banzaicloud/prometheus-jmx-exporter-operator

快速指南

要快速启动和运行Banzai Cloud控制平面实例，请遵循这些安装步骤。

报告错误

如果遇到问题，请在GitHub上打开https://github.com/banzaicloud/pipeline/issues%E3%80%82

贡献

感谢您的贡献并成为我们社区的一部分。请阅读https://github.com/banzaicloud/.github/blob/master/CONTRIBUTING.md%E4%BA%86%E8%A7%A3%E8%A1%8C%E4%B8%BA%E5%87%86%E5%88%99%E5%92%8C%E6%8F%90%E4%BA%A4%E6%8B%89%E5%8F%96%E8%AF%B7%E6%B1%82%E7%9A%84%E6%B5%81%E7%A8%8B%E3%80%82%E5%BD%93%E6%82%A8%E9%A6%96%E6%AC%A1%E5%90%91Pipeline%E6%8F%90%E4%BA%A4PR%E6%97%B6%EF%BC%8C%E6%88%91%E4%BB%AC%E5%B0%86%E8%A6%81%E6%B1%82%E6%82%A8%E7%AD%BE%E7%BD%B2%E6%A0%87%E5%87%86CLA%E3%80%82

许可证

Copyright (c) 2017-2019 Banzai Cloud, Inc.

根据Apache License 2.0许可（"许可证"）授权；除非符合许可证，否则您不得使用此文件。您可以在以下位置获取许可证副本：

[***]

除非适用***要求或书面同意，否则根据许可证分发的软件按"原样"分发，不提供任何明示或暗示的保证或条件。有关许可证下权限和限制的具体语言，请参见许可证。