本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# 三角帆
<a name="spinnaker"></a>

尽管 Spinnaker 并不是专门设计为一种 GitOps 工具，但你可以对其进行配置以实现 GitOps 原则，尤其是在将其用于云原生和 Kubernetes 部署时。

## GitOps 支持
<a name="spinnaker-gitops"></a>


| 区域图 | 工具功能 | 
| --- | --- | 
| 声明式配置 | Spinnaker 使用声明式管道定义，这些定义通常存储为 JSON 或 YAML 文件。根据惯例，这些管道定义可以在 Git 存储库中进行 GitOps 版本控制。 | 
| IaC | Spinnaker 支持将基础架构和部署配置定义为代码。这些定义可以存储在 Git 存储库中，并且可以作为单一事实来源。 | 
| 多云部署 | Spinnaker 旨在跨多个云提供商和 Kubernetes 集群运行。它可以在不同的环境中实现一致的 GitOps实践。 | 
| 管道即代码 | Spinnaker 管道可以定义为代码并存储在 Git 存储库中。这允许进行版本控制和审查部署过程。 | 
| 自动部署 | 您可以将 Spinnaker 配置为根据 Git 存储库中的更改自动启动部署。该工具支持持续部署实践，这些实践是其中的核心 GitOps。 | 
| 不可变的基础架构 | Spinnaker 提倡使用不可变基础架构，这是中的一个关键概念。 GitOps它鼓励部署新实例，而不是修改现有实例。 | 
| 回滚和版本控制 | Spinnaker 提供了强大的回滚功能，可以快速恢复到之前已知的良好状态。它支持根据可追溯性 GitOps 原则对部署进行版本控制。 | 
| 批准工作流程 | Spinnaker 在管道中包括手动判断阶段，以支持环境之间的受控推广。这支持将部署和版本分开的 GitOps 做法。 | 
| Canary 和 blue/green 部署 | Spinnaker 支持高级部署策略，这些策略与安全和受控版本的 GitOps 实践保持一致。 | 
| 与版本控制系统集成 | Spinnaker 可以与各种 Git 提供程序集成，根据仓库事件启动管道。 | 
| Kubernetes 集成 | Spinnaker 为 Kubernetes 提供原生支持，并支持 Kubernetes 资源的 GitOps样式管理。 | 
| Artical 管理 | Spinnaker 支持工件管理和版本控制，这对于维护工作流程至关重要。 GitOps | 
| 可观察性和监测 | Spinnaker 提供与监控工具的集成，以支持可观察性方面。 GitOps | 
| 审计跟踪 | Spinnaker 提供了详细的部署日志和历史记录，这些日志和历史记录支持的可审计性原则。 GitOps | 
| 基于角色的访问控制 (RBAC) | 该工具实现了 RBAC，可根据安全惯例对谁可以执行哪些操作进行精细控制。 GitOps  | 
| 模板化和参数化 | Spinnaker 支持在管道定义中进行模板化，以实现可重复使用和参数化的部署。 | 
| 环境促进 | Spinnaker 以受控的方式促进了不同环境（例如，从暂存到生产）之间的应用程序推广。 | 
| 与 CI 工具集成 | Spinnaker 可以与各种持续集成 (CI) 工具集成，以提供符合原则的完整 CI/CD 管道。 GitOps  | 
| 自定义舞台和扩展 | 该工具支持自定义阶段和扩展，因此团队可以实施根据其需求量身定制 GitOps 的工作流程。 | 
| 集中管理 | Spinnaker 提供了一个集中式平台，用于管理跨多个环境和云提供商的部署。 | 

尽管Spinnaker主要不是作为一种 GitOps 工具销售的，但其灵活性和强大的功能集使其能够实现 GitOps 工作流程，尤其是在复杂的多云环境中。Spinnaker与Argo CD或Flux等专用 GitOps 工具的主要区别在于，Spinnaker提供了更全面的持续交付平台，具有高级部署策略和多云支持。

Spinnaker的优势在于它能够处理各种云提供商的复杂部署场景以及对高级部署策略的支持。当 Spinnaker 配置得当时，它可以有效地实现 GitOps 原理。这使其成为想要在多样和复杂环境中采用 GitOps 实践的组织的强大工具。

有关更多信息，请参阅 [Spinnaker 文档。](https://spinnaker.io/docs/)

## 架构
<a name="spinnaker-architecture"></a>

[下图说明了使用 Spinnaker 和 Jenkins X 的 GitOps驱动型 CD 工作流程。有关详细信息，请参阅 Spinnaker 文档。](https://spinnaker.io/docs/concepts/)

![Spinnaker 架构和工作流程已开启。 AWS](http://docs.aws.amazon.com/zh_cn/prescriptive-guidance/latest/eks-gitops-tools/images/spinnaker-on-aws.png)


其中：
+ **步骤 1：提交代码**。开发人员将应用程序代码更改提交到 Git 存储库。这些更改可能包括对应用程序本身、Dockerfiles 或 Kubernetes 清单的更新。
+ **第 2 步：Jenkins 构建和镜像创建**。Jenkins 由 Git 存储库通过 webhook 或轮询自动触发。Jenkins 构建应用程序，创建 Docker 镜像，然后将构建的映像推送到已配置的 Docker 注册表（例如 Amazon ECR 或 Docker Hub）。
+ **第 3 步：三角帆图像监控和管道触发。**Spinnaker 会持续监控 Docker 注册表中是否有新镜像。当检测到新的映像版本时，Spinnaker 会自动触发管道以启动部署过程。
+ **步骤 4：部署到目标命名空间**。Spinnaker 将新的 Docker 镜像部署到亚马逊 EKS。根据管道配置，映像将部署到集群中的目标命名空间。Spinnaker 确保部署最新的应用程序版本，同时遵守已定义的部署策略，例如 blue/green 或 canary 部署。