谷歌云自动化高级教程（一）

原文：Pro Google Cloud Automation

协议：CC BY-NC-SA 4.0

一、GCP 自动化简介

本章涵盖了 GCP(谷歌云平台)的自动化构建模块，并解释了如何建立一个 GCP 帐户。本章涵盖的主题如下:

• GCP 简介

• GCP 的自动化积木

• 注册谷歌云

GCP 简介

谷歌云平台(GCP)是谷歌的公共云产品，它根据需求向最终用户提供一系列 IaaS 和 PaaS 服务。他们的服务非常适合现代应用开发用户。GCP 在大数据分析、人工智能和容器化领域有一些独特的产品。

谷歌首次涉足云计算是通过谷歌应用引擎，它于 2008 年 4 月作为平台即服务(PaaS)产品推出。它使开发者能够在谷歌的基础设施上构建和托管应用。2011 年 9 月，App Engine 走出预览版，2013 年正式采用 Google 云平台名称。该公司随后发布了各种工具，如其数据存储层、云 SQL、BigQuery、计算引擎以及组成今天谷歌云平台的其余工具。

GCP IaaS 资源包括物理硬件基础设施——计算机、硬盘驱动器、固态驱动器和网络——包含在谷歌的全球分布式数据中心中。这种硬件以虚拟化资源的形式提供给客户，比如虚拟机 (VMs)。

为了构建云应用，GCP 提供了各种产品。下面介绍了一些比较流行的服务:

|

服务

|

描述

|
| — | — |
| 谷歌计算引擎 | 帮助创建虚拟机来运行操作系统，并允许在云中创建不同的计算机。 |
| 谷歌库比厄引擎 | 帮助管理容器编排器；使用 Kubernetes 作为托管服务来帮助部署、扩展和发布。 |
| 谷歌云功能 | 有助于实现事件驱动的无服务器云平台，有助于创建代码形式的基础设施(即由代码设计和实现的基础设施)。 |
| 谷歌容器注册 | 在 GCP 上提供安全、私有的 Docker 图像存储。它为团队提供了一个单一位置来管理 Docker 映像、执行漏洞分析，并通过细粒度的访问控制来管理谁可以访问什么。 |
| Google Stackdriver(现在的 Google Operations) | 帮助向公共云用户提供性能和诊断数据。提供对 Google 云和 AWS 云环境的支持，使其成为混合云解决方案。 |

GCP 的自动化积木

许多新的应用正在被创建和开发，以便在云原生环境中运行。其中一些利用了容器化的架构，并部署在容器上。每个云提供商都有围绕 Kubernetes 的产品——谷歌有 GKE，Azure 有 Azure Kubernetes 服务，亚马逊有亚马逊 EKS 和亚马逊 Fargate。

容器化和云原生架构的整体理念以可用性、可伸缩性、自动化和开发运维为中心。Docker 和 Kubernetes 为开发人员和管理员提供了轻松部署和管理容器化应用的选项。

在容器化的环境中有许多发布和部署选项。其中最流行的是金丝雀部署、蓝绿部署和 A/B 测试。开发人员和发布/部署团队现在可以使用与 Kubernetes 生态系统完美集成的新型工具，轻松直观地开发/管理应用。在本书中，我们将介绍四种重要的工具，它们可用于持续部署和支持基于 Kubernetes 的应用部署。我们将讨论 Google 部署管理器、Spinnaker、Tekton 和 Jenkins。此外，我们还将介绍如何利用这四种解决方案的原生 GCP 服务来自动化 GCP 上的应用生命周期管理。

这些系统中的一些公共元素有助于开发人员和部署团队自动化他们的持续部署版本，这些元素将在下面的章节中进行解释。

支持简化部署

前面提到的大多数工具都允许开发人员简化云环境中应用的部署。它们通过提供易于使用的标准和模板以及应用部署的声明式格式来实现这种简化。一些工具支持 YAML 格式，并支持 Python 和 Jinja 模板来提供配置的参数化。

这些工具支持标准化，只需创建一个模板，然后允许它在类似的部署和不同的应用中重用。支持应用的核心基础设施元素包括自动扩展组、负载平衡器、节点、pod 等。它们都可以作为模板项或资源提供，通过模板进行配置，然后以标准化、可重复的方式进行部署。

可重复的部署流程

由于这些工具提供了一种创建声明性模板的方法，模板和部署策略在整个组织中的可重用性得到了增强。团队可以标准化处理不同类型发布的方式，以及定义和执行在容器化环境中运行应用所需的跨基础架构组件的标准。这可以节省部署工作和时间，并减少错误。

应用焦点

连续部署工具帮助团队专注于应用，选择适当的部署策略，并在将来的修改中重用模板，而不是专注于 Kubernetes 平台和相关基础设施元素的部署，然后重新定义部署策略。这使得应用开发/发布团队能够通过抽象特定于平台(如操作系统、数据库、Web 服务器)和云(私有云或公共云)的底层组件供应和配置过程的复杂性，专注于应用本身。

自动发布

这些工具支持端到端 CI/CD，因此可以与 CI 中的现有工具很好地集成。一些流行的 CI 工具有 Jenkins、Travis CI 等等。CD 工具与它们无缝集成，支持端到端的管道自动化和部署。因此，通过利用这些集成，实现了在容器化或云环境中完全自动化交付管道的端到端自动化愿景。

启用最佳实践

持续部署工具通过确保部署流程的标准化、模板的可重用性、不可变映像的部署、完全自动化和快速的应用部署，以及在出现问题时执行回滚的能力，在整个组织中实现最佳实践。这些工具还通过为深入诊断提供简单直观的界面和相关日志，使调试更容易，并有助于更快地解决与部署相关的事件。

零停机部署

在推出新的应用版本时，应用和业务所有者已经开始期望没有应用停机时间，或者至少是最小的停机时间。利用 Jenkins、Spinnaker 和 Google Deployment Manager 等解决方案，并使用 blue-green/canary/dark releases 等部署策略，运营团队能够以自动化方式管理 GCP 上的发布，最大限度地减少停机时间。虽然 GCP 本地和第三方工具在自动化发布中起着重要作用，但部署模式在实现最小或零停机时间方面也起着至关重要的作用。以下小节将介绍一些更常见的零停机部署策略。

蓝绿色部署

使用蓝绿色部署策略，有两个相同应用版本的生产实例(蓝色和绿色)，它们相互隔离。只有蓝色实例接收所有生产流量。在发布过程中，新的代码版本部署在绿色实例中，并执行各种测试(如负载、功能和安全测试)。如果成功通过所有测试，绿色实例将被提升为接收所有生产流量(使用负载平衡器、DNS、反向代理等解决方案)。在使用这种方法时，应用团队必须记住长时间运行的数据库事务和应用会话带来的复杂性。

在 GCP 上使用这种方法(如图 1-1 所示)将需要应用的蓝色和绿色实例在 GCP 上运行，这会产生成本。通过利用 Google Deployment Manager 旋转蓝色和绿色实例，这变得相当简单，并有助于控制成本。绿色环境仅在与蓝色环境具有相同规格的版本中部署，使用 infra as code 原则。Jenkins X 和 Spinnaker 等解决方案在 CI/CD 管道中模拟蓝绿色模式。

图 1-1

蓝绿色部署

滚动更新

这种部署策略(也称为渐变部署策略)包括通过逐渐替换旧实例来推出新版本。虽然这种方法可以解决长期运行的事务问题，或者在推出新版本时维护状态，但是总的部署时间可能相当长(取决于要执行的总体测试和要替换的组件)。如图 1-2 所示，通过滚动更新部署，旧版本将被批量更新的实例所取代，流量将通过 GCP 负载均衡器进行管理。

图 1-2

滚动更新方法

金丝雀

金丝雀方法(也称为金丝雀或增量部署)与蓝绿方法类似，唯一的区别是新版本的应用逐渐接收生产流量(如新旧版本之间的 90-10、75-25 和 50-50)，而不是完全的流量切换(如图 1-3 所示)。

图 1-3

金丝雀部署

如果在测试过程中检测到问题，所有流量都将转移到旧的稳定版本。利用 GCP 本地负载平衡器有助于实现逐步流量切换功能，然后可以与部署管理器一起利用该功能来设置新环境。

这种方法与 A/B 测试密切相关，通过这种方法，可以在一部分用户中测试新特性(通常用于测试 UX 或应用级别的功能)。除了用于 A/B 测试和 canary 部署的负载平衡器的流量分配功能之外，应用开发人员还可以使用各种条件，如浏览器 cookies 或版本、地理位置等。

注册谷歌云

让我们从 GCP 开始吧。第一步是报名 GCP。以下部分包含注册所需的步骤，适用于初次用户。

注册该平台的首要先决条件是一个谷歌账户。GCP 使用谷歌账户进行访问管理和认证。如图 1-4 所示，您只需在浏览器窗口中输入 https://cloud.google.com/free# 网址。

图 1-4

谷歌云平台

点击免费开始按钮。然后你会看到登录界面，如图 1-5 所示。

图 1-5

GCP 登录屏幕

系统会提示您输入一个 Google 帐户。如果您没有帐户，请按照创建帐户流程创建一个帐户。

Note

如果您已经登录到您的 Google，您将被重定向到图 1-6 所示的 GCP 云控制台。选择适当的国家，然后单击协议复选框。然后点击同意并继续。

图 1-6

GCP 云平台

如果您符合免费层的条件，系统会提示您输入帐户详情，如图 1-7 所示。

图 1-7

GCP 自由层注册，步骤 1

选择您的国家，同意服务条款，然后单击同意并继续按钮。这将带您进入第二步，如图 1-8 所示，在这里您可以创建并选择您的支付模式。提供所需的账单详情；但是，请放心，除非您手动请求，否则自动借记不会发生。

图 1-8

GCP 自由层注册，步骤 2

当您创建付款资料并登录时，右侧面板会显示详细信息，如图 1-9 所示。

图 1-9

GCP 自由层信息

如图 1-9 所示，谷歌向所有用户提供 300 美元的信用额度，可以在 12 个月内使用。这不仅足以探究书中所有的练习，也足以进一步评价 GCP。一旦您指定了所有的细节，点击开始我的免费试用按钮。

注册需要一段时间才能完成。一旦必要的验证完成，你将被重定向到谷歌控制台，你就可以开始了。

使用虚拟机创建控制台

点击创建按钮，创建一个新的虚拟机选项，如图 1-10 所示。

图 1-10

虚拟机创建控制台

单击页面右上角的激活按钮。它会提示你升级。点击升级，如图 1-11 所示。

图 1-11

虚拟机创建控制台

根据提示刷新页面(参见图 1-12 )。

图 1-12

当询问您时，选择刷新

一旦激活过程完成，将显示图 1-13 中的屏幕。

图 1-13

激活屏幕后

为谷歌 GKE 设置环境

本节描述了为谷歌 GKE 设置环境的步骤。

创建项目

首先，您需要创建一个项目，如下所示:

图 1-15

新项目视图

1. 转到云控制台中的管理资源页面。

2. 在页面顶部的选择组织下拉列表中选择您的组织。

   注意如果您使用的是免费试用版，此列表不会出现。

3. 单击新建项目。

4. In the New Project window, enter your project name, as shown in Figure 1-14.

   

   图 1-14

   新项目详细信息屏幕

   项目 ID 是所有 Google Cloud 项目的唯一名称(我们选择的名称不适合您)。这是本书其余部分使用的PROJECT_ID。

5. 输入完新项目的详细信息后，单击创建。新项目将被选中并出现，如图 1-15 所示。

发射云壳

使用右上角工具栏上的 GCP 控制台云壳图标激活 Google 云壳，如图 1-16 所示。

图 1-16

云壳按钮

将出现图 1-17 所示的屏幕。单击继续。

图 1-17

云壳屏

接下来，点击启动云壳按钮，如图 1-18 所示，启动云壳会话。

图 1-18

云壳开始屏幕

配置和连接到环境应该需要一些时间。这是一次性活动；下次点击云壳按钮，将会看到图 1-19 中的屏幕。

图 1-19

云壳屏

这个虚拟机提供了一个持久的 5GB 主目录，它运行在 Google Cloud 上。你已经通过认证了。请注意，项目被设置为您的PROJECT_ID。

在云 Shell 中运行以下命令，以确认您已经过身份验证:

gcloud config list project

1
2

该命令的输出如图 1-20 所示。

图 1-20

list project 命令的输出

摘要

本章包括 GCP 服务和支持自动化构建模块的简要概述。您还了解了如何创建 GCP 帐户，这将在后续章节的实践练习中用到。下一章从 GCP 部署管理器服务开始，并向您展示如何使用它来自动化设置 GCP 服务的过程。

二、GCP 开发管理器入门

在本章中，我们将介绍 GCP 部署管理器服务的核心概念，并解释如何使用它来实现基础设施即代码(IaC ),以管理和供应 Google 云基础设施。本章涵盖以下主题:

• 部署管理器简介

• 了解部署管理器的组件

• 部署管理器的实践用例

部署管理器简介

DevOps 和基础设施即代码(IaC)正在获得全球开发者、管理员、架构师和云工程师的青睐。DevOps 是一种包含人员、流程和工具的哲学。它的目标是加速软件开发以及相关的发布和部署过程。在 DevOps 的总体框架中，IaC 是一个重要的组件，它从基础设施方面提供敏捷性和可伸缩性，以满足开发团队的需求。IaC 还支持稳定、安全和一致的平台来托管应用。

市场上有许多工具可用于实现 IaC。如今，Terraform 和 Ansible 在 DevOps 和开发人员社区中越来越受欢迎。同样，公共云托管平台提供原生解决方案，这些解决方案被打包为公共云服务产品的一部分，如 AWS 的 Amazon Cloud Formation 和 Azure 的 Azure Resource Manager。

在 GCP，云原生 IaC 原生产品被称为部署管理器。部署管理器提供了一种使用声明性语言定义 Google 云基础设施资源的机制。Deployment Manager 使用户能够使用 IaC 原则来设计和构建他们的 GCP 资源，以便他们可以使用软件开发的源代码控制和版本控制机制来维护对所提供内容的粒度控制，并自动执行提供过程。

部署管理器使您能够使用声明性配置(使用 Jinja 和 Python 语言)管理您的 GCP 基础设施。它帮助您编写灵活的模板和配置文件，然后使用它们来创建各种 GCP 服务，如 GKE、虚拟机、VPC、网络等等。

部署管理器的主要特性

作为 Google 部署管理器中的一个概念，部署只不过是 GCP 的另一个资源。通过更新部署文件和运行 update 命令对部署配置所做的任何修改，都只会通过将新配置与早期部署进行比较来引发所需的更改。这确保了通过有限的努力，从配置中移除的任何资源也从 GCP 基础设施中移除。图 2-1 总结了部署管理器的主要特性。

图 2-1

部署管理器功能

Python 和 Jinja

要理解 Python 和 Jinja 的关系，我们需要理解什么是模板引擎。开发人员使用模板作为中间格式，以编程方式生成不同的所需输出格式，如 HTML 或 XML。这个活动是在模板引擎的帮助下执行的，模板引擎接受输入标记化的字符串，并生成一个呈现的字符串，用一个值代替标记作为输出。模板引擎通过使用一些数据和编程结构(如条件和循环)来操作输出。由开发人员创建然后由模板引擎处理的模板文件由预先编写的标记和插入数据的模板标记块组成。

Python 使用了几个模板引擎，比如可比、Django、string。模板，还有 Jinja2。这些模板引擎在允许代码执行和使用模板标签授予有限的功能集方面是不同的。

Jinja 或 jinja2 是最广泛使用的 Python 模板引擎，它是作为开源项目编写的。其流行的原因是其他模板引擎，如 Django 模板，可以作为大型 web 框架的一部分使用，这使得在项目之外使用它们很麻烦，因为它们与它们的库紧密耦合。许多 Python 开源应用，如配置管理工具 Ansible 和 SaltStack，默认使用 Jinja 模板来生成输出文件。

要了解关于 Python 和 Jinja 的更多信息，请参考以下链接:

• 忍者！忍者

• pythonhttps://docs.python.org/3/tutorial/

了解部署管理器组件

部署管理器 GCP 服务是管理谷歌云环境的一种非常有效的方式。在使用部署管理器管理 GCP 资源生命周期之前，您需要首先理解它的关键概念。

部署管理器的工作原理是，一组 GCP 资源形成一个逻辑单元，称为*部署，*一起部署。部署单元可以是任何 GCP 资源，如 GKE 集群、虚拟机、数据库、网络、IPs 等等。Deployment Manager 借助于使用声明性语句设置的模板，通过部署、更新和删除云资源来管理云基础设施。部署管理器在以下组件的帮助下执行部署的实施活动:

• 配置文件

• 资源

• 类型

• 模板

• 显示

• 部署

配置文件

配置文件是一起创建和管理的 GCP 资源的集合。配置文件以 YAML 模板的形式编写，包含要部署的资源的定义。部署管理器使用单个配置文件来管理多个资源。YAML 格式的配置文件的基本结构如图 2-2 所示。

图 2-2

配置文件示例

典型的配置文件包含以下部分:

• Type: 表示要作为虚拟机、IP 地址等进行配置的 GCP 资源的类型。

• Name: 一个名称字段，用于标识使用部署管理器设置的资源。这将作为将来对 GCP 资源集进行任何修改或删除操作的关键。

• **属性:**定义将要创建的 GCP 资源的参数和属性，如机器类型、网络接口、启动盘等。这些值与从 GCP 控制台或云外壳手动创建服务时所需的值相同。

配置文件还包含一个类似这样的部分:

• Import: 包含配置所需的所有模板文件的列表，最终由部署管理器扩展。

配置文件的其他可选部分包括:

• **输出:**当需要将一个模板和配置中的数据输出到另一个模板供最终用户使用时使用。

• **元数据:**用于设置资源之间的显式依赖关系。

部署管理器施加了以下限制:

• 配置的大小。原始格式和扩展格式都不能超过 1MB。

• 执行配置文件所花费的时间或处理能力也是有限的。如果超过这些，解决方案是将配置文件分成多个配置。

• Python 模板不能进行任何系统或网络调用。如果他们尝试，他们将被拒绝。

让我们使用 YAML 文件创建一个简单的部署，如图 2-3 所示，其中我们在 Google 计算引擎服务中创建一个虚拟机。

图 2-3

简单配置文件

资源部分

配置文件中的资源部分描述了单个 API 资源。当我们编写配置文件时，我们可以选择使用 Google 管理的基本类型提供的 API 资源，或者使用第三方类型提供者提供的 API 资源。计算引擎实例和云 SQL 实例是 Google 云服务资源的例子。

类型

您必须为每个资源定义一个类型。描述资源需要类型。该类型可以是基类型或复合类型，如下所述。

基本类型

当您必须创建单个原始 Google Cloud 资源时，您可以选择基本类型。基本类型使用 RESTful APIs 对资源执行 CRUD(创建、读取、更新和删除)操作。常用的 Google owned base 类型有compute.v1.instance和storage.v1.bucket。可以分别使用compute.v1.instance API 和storage.v1.bucket API 来访问它们。

要获得受支持资源类型的完整列表，包括 alpha 中的资源，请在gcloud中运行这个 types list 命令:

gcloud deployment-manager types list

1
2

示例输出如图 2-4 所示。

图 2-4

部署管理器类型列表

复合类型

当您必须创建一组原始的 Google Cloud 资源时，您需要多个模板作为一个单元一起工作，这可以使用 Python 或 Jinja 来完成。复合类型通常用于定义模板的一部分，可以很容易地重用。例如，您可以为网络创建负载平衡器资源。

每个资源都必须在配置文件中定义为一个类型。该类型可以是 Google 托管类型、复合类型、类型提供者或导入类型。这些类型可以在配置文件中定义。

Google 托管类型

这些类型与 Google 自己的托管基础云资源类型相关，如云存储桶或计算实例。在配置文件中定义它的语法如图 2-5 所示。

图 2-5

Google 管理的类型模板片段

Example: For Compute Engine instance type and Cloud Storage
                 bucket type

type: compute.v1.instance
type: storage.v1.bucket

1
2
3
4
5
6

复合或类型提供程序

在配置文件中定义复合和类型提供者的语法如图 2-6 和 2-7 所示。

模板:复合

图 2-6

复合提供程序模板片段

模板:类型提供者

图 2-7

类型提供程序模板片段

导入的模板

在配置文件中定义导入模板的语法如图 2-8 所示。模板导入一个名为my_vm_template.jinja的模板来创建一个名为my-first-virtual-machine的计算引擎实例。

图 2-8

导入的模板片段

模板:模板导入

模板

模板是配置文件的一部分。这些是包含一组资源详细信息的单个文件。对于复杂的部署，我们可以创建包含资源集信息的不同模板，从而在不同的部署之间提供一致性。部署管理器以内嵌的方式扫描和解释每个模板。

让我们创建一个基本模板。考虑下面的配置文件，它用于创建一个名为vm-created-by-deployment-manager的计算引擎虚拟机，如图 2-9 所示。

图 2-9

配置文件基本模板片段

现在我们将为这个配置创建一个模板，方法是取出相关的部分并创建一个新的 Jinja 文件。参见图 2-10 所示的模板片段。

图 2-10

Jinja 文件中的基本模板

部署管理器还创建包含部署信息的预定义环境变量。当我们在模板中使用这些环境变量时，部署管理器设置这些变量并替换它们的值。例如，project_number是一个保存部署的项目编号的环境变量。当在模板中使用它时，它被替换为该部署的实际project_number值。用于声明环境变量的语法如图 2-11 所示。

图 2-11

环境变量模板片段

图 2-11 显示了 GCP 提供的内置环境变量，该变量在代码中用于自动获取项目 ID。(参见表 2-1 。)图 2-12 显示了 Jinja 模板中环境变量的使用示例。

图 2-12

Jinja 模板片段中的环境变量示例

表 2-1 列出了部署管理器使用的环境变量集。

表 2-1

环境变量列表和描述

|

环境变量名

|

描述

|
| — | — |
| Deployment | 部署的名称 |
| Name | 使用此模板的配置文件中声明的名称 |
| project | 本次部署的Project_Id |
| project_number | 本次部署的project_number |
| current_time | 此部署开始扩展时的 UTC 时间戳 |
| type | 顶级配置中声明的资源类型 |
| username | 当前部署管理器用户 |

显示

每个部署都有相应的清单。清单是描述部署中所有资源的只读属性，并且是在每次新部署时自动创建的。清单创建后不能修改。清单不同于配置文件，而是基于配置文件创建的。您可以通过清单的惟一 ID 来识别它，ID 的格式是manifest-TIMESTAMP。例如，查看图 2-13 中所示的例子。

图 2-13

清单 ID 示例

清单提供了部署的三个视图，即初始配置视图、完全评估的配置视图和部署布局。我们将在接下来的章节中逐一讨论。

初始配置视图

原始配置是您在任何模板扩展之前提供给部署的配置。初始配置由config属性表示，如图 2-14 所示。

图 2-14

清单的初始配置视图

完全评估的配置视图

该视图在所有模板和导入展开后显示。扩展配置是对您的部署的完整描述，包括处理所有模板后的所有资源及其属性。这是您配置的最终状态。清单的扩展配置部分由expandedConfig属性表示，如图 2-15 所示。

图 2-15

清单的扩展配置

部署的布局

该视图以分层结构描述了部署的所有资源。布局是您的部署及其资源的概要，并显示资源名称和类型。您可以使用布局来可视化您的展开结构、在初始展开期间设置的视图样板属性以及展开前有关您的配置的其他信息。在您的 manifest 中，您可以看到layout属性中的布局，如图 2-16 所示。

图 2-16

清单的布局视图

部署

一个部署是作为一个单元一起部署和管理的 GCP 资源的集合。我们可以使用配置文件和 GCP 云 Shell 的 create 命令来创建部署。用于执行部署的命令如图 2-17 所示。

图 2-17

在 GCP 创建新部署的命令

要定义配置文件，您必须使用--config选项，后跟配置文件的名称。当部署完成后，您可以使用图 2-18 中所示的命令来查看是否配置正确。

图 2-18

描述部署的命令

部署管理器的实际使用案例

既然我们已经介绍了 GCP 部署管理器的基本概念，那么让我们进入代码开发部分，开始在部署管理器的帮助下创建云基础设施。在开始之前，我们必须设置 GCP 环境以使用部署管理器。您可以通过以下链接访问本教程中使用的所有文件:

https://github.com/dryice-devops/GCPAutomation

步骤 1:为了使用部署管理器，您需要一个 Google 项目。我们为本教程创建了一个名为LearnDMProject的项目，因此我们将选择该项目，如图 2-19 所示。您可以通过单击屏幕右上角的“新建项目”选项来创建新项目。

图 2-19

选择 LearnDMProject 项目

第二步:第一次点击部署管理器时，如图 2-20 所示，会提示您启用云部署管理器 V2 API，如图 2-21 所示。

图 2-20

选择部署屏幕

点击启用按钮，如图 2-21 所示，启用部署管理器 API。

图 2-21

启用部署管理器 API 屏幕

单击 Enable 按钮后，该 API 将可用于该项目。您将看到部署管理器屏幕，如图 2-22 所示。

图 2-22

部署管理器控制台

第三步:作为先决条件，你也可以安装名为gcloud的 Cloud SDK 命令行工具，或者你可以使用 Google Cloud Shell，它默认启用了gcloud。在本教程的剩余部分，我们将使用 Google Cloud Shell。

一旦满足了先决条件，就可以使用部署管理器来配置 GCP 资源。我们将首先处理一个用例，在这个用例中，我们将配置一个由虚拟机组成的部署。

步骤 1:第一步是激活云 Shell，它提供对 Google 云资源的命令行访问。在云控制台中，点击右上方工具栏中的激活云壳按钮，如图 2-23 所示。

图 2-23

激活云壳

点击激活云壳图标后，您将看到如图 2-24 所示的屏幕。单击继续按钮继续。

图 2-24

云壳信息屏幕

云壳终端现已可用，项目设置为PROJECT_ID，如图 2-25 所示。

图 2-25

云壳终端

步骤 2:为了开始为配置文件编写代码，我们将使用云外壳编辑器。点击打开编辑器按钮，如图 2-26 所示。

图 2-26

云 Shell 终端中的“打开编辑器”按钮

可以查看云编辑器和云终端，如图 2-27 所示。

图 2-27

云壳编辑器和终端视图

步骤 3:正如您之前看到的，我们将通过创建一个配置文件来定义我们的基础设施。我们将首先创建网络和子网配置。

创建网络和子网

在本节中，我们将使用部署管理器创建 GCP 网络和子网。这些网络和子网的一般表示如图 2-28 所示。

图 2-28

通用 VPC 网络

这个 VPC 网络在us-west1区域将subnet1定义为10.240.0.0/24，在us-east1区域将subnet2定义为10.2.0.0/16。Subnet1在Subnet1的可用地址范围内有两个 IP 为10.240.0.2和10.240.0.3的虚拟机。类似地，Subnet2有两个虚拟机，其 IP10.2.0.2和10.2.0.3位于定义的子网范围内。

对于本教程，我们将创建以下三个配置文件:

• networkconfig.yaml:配置 YAML 文件，我们在其中定义资源(网络和子网)类型和属性。

• network.py:这将被导入到配置文件中，包含网络/子网定义以及特定的环境变量。

• network.py.schema:描述了部署管理器的规范。它包含部署管理器在使用network.py模板时将强制执行的一组规则。

对于这个用例，实施解决方案架构可以如图 2-29 所示。

图 2-29

实现架构

现在，按照以下步骤进行实施:

1. Create a file called networkconfig.yaml in the Cloud Shell Editor by navigating to File ➤ New ➤File, as shown in Figure 2-30.

   

   图 2-30

   新文件视图

   Once it’s created, the file will appear in the Explorer along with the text editor, as shown in Figure 2-31.

   

   图 2-31

   创建网络配置文件

   Now paste the following code into the networkconfig.yaml file and save the file, as shown in Figure 2-32.

   

   图 2-32

   网络配置代码

2. Create another file called network.py in the Cloud Shell Editor by choosing File ➤ New ➤ File, as shown in Figure 2-33.

   

   图 2-33

   新文件视图

   Now paste the following code into the network.py file and save the file. This file is used to describe the network and subnetwork configuration and is imported by the networkconfig.yaml file to create the network setup, as shown in Figure 2-34.

   

   图 2-34

   网络配置代码

3. Create another file called network.py.schema in the Cloud Shell Editor by choosing File ➤ New ➤ File, as shown in Figure 2-35.

   

   图 2-35

   新文件视图

   Now paste the following code into the network.py.schema file and save it, as shown in Figure 2-36.

   

   图 2-36

   网络配置模式代码

4. 现在我们已经创建了配置文件，我们将使用以下命令执行部署:

   gcloud deployment-manager deployments
   
   1
   2

         create networsubnetworkdm –config networkconfig.yaml

1
2

该命令将执行网络和子网的部署，并将产生如图 2-37 所示的输出。

图 2-37

部署命令 CLI

您可以在 GCP 控制台上通过导航到主➤ VPC 网络来验证部署。这样做将显示如图 2-38 所示的屏幕。

图 2-38

VPC 网络屏幕

1. 最后，您可以从 CLI 使用以下命令删除创建的网络和子网:

         gcloud deployment-manager deployments delete networsubnetworkdm

1
2

此命令将删除您创建的网络和子网。在删除过程中，系统会提示您“是否要继续(y/N)？”键入y以产生如图 2-39 所示的输出。

图 2-39

删除部署 CLI

可以在谷歌云控制台验证 learndmproject-network 被删除，如图 2-40 。

图 2-40

VPC 网络控制台

创建虚拟机

在本节中，我们将使用部署管理器创建一个 VM 实例。我们将编写包含虚拟机创建定义的createVMConfig.yaml配置文件。

实施方案如图 2-41 所示。

图 2-41

实现架构

现在，按照以下步骤进行实施

图 2-45

编辑器中的 createVMConfig.yaml 代码片段

图 2-44

createVMConfig.yaml 代码片段

1. Create a file called createVMConfig.yaml in the Cloud Shell Editor by going to File ➤ New ➤ File, as shown in Figure 2-42.

   

   图 2-42

   新文件视图

   Once it’s been created, the file will appear in the Explorer along with text editor, as shown in Figure 2-43.

   

   图 2-43

   新文件视图

2. 现在将下面的代码粘贴到createVMConfig.yaml文件中并保存，如图 2-44 和 2-45 所示。

在进入下一步之前，您需要理解前面代码中使用的参数和值。我们通过声明提到的资源 VM 实例类型及其名称来启动配置文件，如图 2-46 所示。

图 2-46

资源配置

name是一个用户定义的字符串，它可以是任何有意义的名称，以后会被引用。接下来，我们将实例的类型定义为compute.v1.instance。我们可以通过运行以下命令来检查哪些类型可用:

gcloud deployment-manager types list

1
2

该命令将列出部署管理器的所有类型。它将产生如图 2-47 所示的输出。

图 2-47

DM 类型列表

我们可以使用下面的命令来过滤结果以找到实例类型。输出将如图 2-48 所示。

图 2-48

过滤的 DM 类型列表

gcloud deployment-manager types list | grep instance

1
2

现在让我们看看在tutorialConfig.yaml文件中为虚拟机定义的属性。

• Zone:描述虚拟机将驻留在哪里。我们可以通过运行以下命令来检查哪些类型可用:

         gcloud compute zones list

1
2

前面的命令将列出所有可用的区域并产生输出，如图 2-49 所示。

图 2-49

区域列表

• machineType:您可以使用以下命令检查machineType。由于本例中的区域是us-central1-a，我们可以在这个区域上过滤我们的列表搜索。

        gcloud compute machine-types list | grep us-central1-a

1
2

该命令将列出us-central1-a中所有可用的机器类型，并将产生如图 2-50 所示的输出。

图 2-50

在区域上过滤的机器类型

从前面的列表中选择机器类型后(本例中为f1-micro，我们需要在配置文件中定义f1-micro机器类型的selfLink URL。为了获得selfLink URL，我们将使用之前在配置文件中定义的相同区域选择(即us-central1-a)来执行以下命令。

         gcloud compute machine-types describe f1-micro --zone us-
         central1-a | grep selfLink

1
2
3

该命令将显示配置文件中使用的selfLink URL，并将产生如图 2-51 所示的输出。

图 2-51

机器类型自链接

• disk:disk配置将具有以下值:

• initializeParams:这将有启动盘的初始化参数。您可以使用以下命令检查图像列表:

             - deviceName: boot
             - type: PERSISTENT
             - boot: true
             - autoDelete: true

1
2
3
4
5

gcloud compute images list

1
2

该命令将显示可用图像列表，并将产生如图 2-52 所示的输出。

图 2-52

计算图像列表

在这个例子中，我们将创建一个 Linux 实例，因此我们将过滤 Debian-9 映像上的搜索列表。我们可以使用以下命令获得图像列表:

gcloud compute images list | grep debian

1
2

该命令将显示可用的 Debian 映像列表，并将产生如图 2-53 所示的输出。

图 2-53

过滤的计算图像列表

它显示了两个 Debian 映像，所以我们将获得 Debian-9 映像的selfLink URL，并将其放在我们的配置文件中。

gcloud compute images describe debian-9-stretch-v20200714 --project debian-cloud | grep selfLink

1
2

该命令将显示配置文件中使用的selfLink URL，并将产生如图 2-54 所示的输出。

图 2-54

计算机图像自动链接

• network:要列出项目可用的网络，使用以下命令。

gcloud compute networks list

1
2

该命令将显示配置文件中使用的网络列表，并将产生如图 2-55 所示的输出。

图 2-55

网络列表

我们有一个默认网络可用，所以我们现在将为默认网络生成selfLink,以便在配置文件中使用它。

gcloud compute networks describe default | grep selfLink

1
2

该命令将为默认网络生成selfLink，并将产生如图 2-56 所示的输出。

图 2-56

默认网络自动链接

配置文件中的最后一个条目将accessConfigs添加到默认网络。有两个参数，定义如下:

• name : External NAT

• type : ONE_TO_ONE_NAT

有关更多属性，请参考以下链接:

https://cloud.google.com/compute/docs/reference/rest/v1/instances

现在我们已经创建了配置文件，我们可以继续下一步并部署它。

gcloud deployment-manager deployments create my-first-deployment --config createVMConfig.yaml

1
2

该命令将部署我们创建的配置文件，并将产生如图 2-57 所示的输出。

图 2-57

虚拟机部署 CLI

在图 2-57 中可以看到，名为createfirstvm的配置文件已经被部署管理器成功执行。此外，您还可以验证配置文件的执行和 Linux 虚拟机的创建，如图 2-58 所示。

图 2-58

部署管理器控制台

导航到谷歌云控制台➤部署经理➤仪表板控制台。它将显示名为my-first-deployment的部署列表，如图 2-58 所示。

您还可以验证 Debian-9 Linux VM 是否已经创建。导航到谷歌云控制台➤计算引擎➤虚拟机实例。它将显示一个用名称createfirstvm创建的虚拟机，如图 2-59 中的配置文件所定义。

图 2-59

计算引擎控制台

在配置文件中，我们将网络定义为默认网络。我们可以通过单击createfirstvm来验证这一点，这将显示所创建虚拟机的详细信息，如图 2-60 所示。

图 2-60

计算引擎网络详细信息

删除部署

如果部署不是根据您的要求创建的，或者其中有错误，您可以使用以下命令将其删除:

gcloud deployment-manager deployments delete  my-first-deployment

1
2

此命令将删除部署。在删除过程中，您会得到一个提示，“您要继续吗(y/N)？”。键入y以查看如图 2-61 所示的输出。

图 2-61

删除部署 CLI

现在让我们在 Google Cloud 控制台中验证部署管理器和 VM 实例控制台，以确认部署和 VM 已经被删除。见图 2-62 。

图 2-62

部署管理器控制台

类似地，我们可以验证虚拟机已经从计算引擎控制台中删除，如图 2-63 所示。

图 2-63

计算引擎控制台

摘要

本章详细介绍了部署管理器的主要概念，并解释了如何定义配置文件，以便在代码的帮助下执行环境供应和维护。您还进行了创建网络、子网和 GCP 单实例虚拟机的实践练习。下一章将介绍 Spinnaker，它是一个强大而灵活的 Kubernetes-native 开源框架，用于创建持续集成和交付(CI/CD)系统。

三、GCP Spinnaker 入门

Spinnaker 是一个流行的持续部署工具，它支持主要的云提供商在 Kubernetes、Function as a Service (FaaS)等平台上部署应用。本章涵盖了 Spinnaker 架构、组件和用例。您还将学习如何在 GCP 上安装和配置 Spinnaker。

本章涵盖以下主题:

• 三角帆的特点

• 三角帆的建筑

• GCP 大三角帆

• 在 GCP 上安装三角帆

• 使用 Spinnaker

• Spinnaker 的金丝雀部署用例

三角帆的特点

Spinnaker 是一个开源的持续部署工具，它本身支持将应用部署到主要的云提供商，如 GCP、AWS 等。Spinnaker 由谷歌和网飞联合开发，旨在加速他们的软件交付。Spinnaker 现在是开源的，其不断增长的社区正在积极开发新功能，并推动产品向前发展。主要贡献者是谷歌、网飞、微软、亚马逊和其他公司。Spinnaker 的源代码可以在 GitHub 的 https://github.com/spinnaker 获得。

Spinnaker 是 GCP 的一个市场解决方案，只需点击几下就可以安装。Spinnaker 不支持持续集成；但是，它提供了与 Jenkins 等市场领先 CI 工具的集成。市场上还有提供 CI/CD 实施的其他工具。表 3-1 是 Jenkins、JenkinsX 和 Spinnaker 的功能比较。

表 3-1

特征比较

|

特征

|

Jenkins

|

Jenkins

|

大三角帆

|
| — | — | — | — |
| 图像使用者界面 | | | |
| 管道作为代码 | 宣言的 | 亚姆 | 数据 |
| kubernetes-本地(基于控制器) | | | |
| 海峡群岛 | | | |
| 激光唱片 | | | |
| WebHook 触发 | | | |
| Git 轮询触发 | | | |
| 模板支持 | | 通过脚本 DIY | |

可用

不可用

现在让我们看看 Spinnaker 的主要特性:

• 多云支持 : Spinnaker 支持主要的云提供商，如 Google、Amazon 等等。

• 连续交付工具 : Spinnaker 是一个连续交付工具，因为它以安全和自动化的方式部署应用。

• 开源:Spinnaker 得到了大型开发者社区的支持，包括谷歌、网飞、亚马逊等等。

• 支持主要部署策略 : Spinnaker 支持许多部署策略，包括 blue-green、滚动更新、canary 和具有轻松回滚功能的 highlander。

三角帆建筑

Spinnaker 是一个基于微服务的架构，其中有 11 个独立的微服务。以下是这些微服务的列表:

• Deck:Spinnaker 基于浏览器的 UI 和前端服务。

• Gate :一个 API 网关；Spinnaker 的所有微服务都通过这个网关相互通信。

• Orca :负责所有特别操作的编排引擎。这个微服务还负责保存有关管道执行的信息。

• CloudDriver :负责建立与云提供商的连接，缓存所有部署的资源。它是与云提供商集成的主要服务。

• Front50 :负责在应用、管道、项目、通知中持久化元数据。

• Rosco :负责烘焙不可变的 VM 镜像，比如 GCE 镜像、AWS AMI 等等，它们将被部署到特定的云。它使用打包工具来创建虚拟机映像。

• Igor :用于连接像 Jenkins 或 Travis CI 这样的 CI 工具。它允许在自己的管道中使用 Jenkins/Travis CI 阶段。没有这项服务，您就无法与任何 CI 工具集成。

• Echo :用于通过 Slack、email 或者 SMS 发送通知，负责所有传入的 WebHooks，比如 GitHub 到 Spinnaker。

• Fiat :负责 Spinnaker 中的用户授权。它用于查询应用和服务帐户的用户权限。

• Kayenta :负责 spinnaker 的自动金丝雀分析。

• Halyard:Spinnaker 的配置服务，在 Spinnaker 启动、更新和回滚期间维护这些服务的生命周期。

图 3-1 显示了哪些微服务相互依赖。绿框代表“外部”组件，包括在浏览器中运行的 Deck UI。黄色框表示 Halyard 组件，它们仅在启动、更新和回滚期间配置 Spinnaker 时运行。

图 3-1

Spinnaker 微服务架构

应用管理和部署是 Spinnaker 的两个主要组件。让我们来详细了解一下这些组件。

应用管理

应用管理用于查看和管理云资源。它表示需要由用户部署的服务。应用、集群和服务器组是 Spinnaker 用来描述服务的关键概念。负载平衡器和防火墙描述了服务是如何暴露给外部用户的，如图 3-2 所示。

图 3-2

Spinnaker 应用管理

应用管理包括托管服务的以下基础架构。

• 集群:Spinnaker 中服务器组的逻辑分组。例如，在 GCP，它将是 GKE 集群节点。

• 服务器组:基础资源，即服务器组，标识可部署的工件，例如 VM 镜像、Docker 镜像和源位置，以及基本的配置设置，例如实例数量、自动伸缩策略等等。部署时，服务器组是运行软件实例的集合。例如，在 GCP，这将是虚拟机。

• 防火墙:通过一组防火墙规则定义网络流量访问，这些规则由具有通信协议和端口/端口范围的 IP 范围定义。

• 负载平衡器:与入口协议和端口范围相关。它平衡其服务器组中实例之间的流量。

应用部署

Spinnaker 用于通过管道和阶段执行应用的连续部署。管道由一系列动作组成，称为阶段，可以按任何顺序组合。阶段又包含任务，任务是具体的行动，如图 3-3 所示。

Spinnaker 提供了许多阶段，比如部署、禁用、手动判断等等。基于某些事件，可以手动或自动触发管道。例如，一旦 Jenkins 构建了代码并放置了可部署单元，就会触发 Spinnaker 管道进行部署。Spinnaker 支持广泛使用的云本地部署策略，包括蓝绿色、滚动红/黑和金丝雀部署。

图 3-3

三角帆管道流

GCP 大三角帆

GCP 的 Spinnaker 平台带有内置的部署最佳实践，用户可以利用 Google 托管服务，如 Google Kubernetes 引擎、Google 计算引擎、合规性、安全性等。

表 3-2 列出了 Spinnaker 在 GCP 的优势。

表 3-2

三角帆在 GCP 的优势

| **安全安装** | Spinnaker for GCP 提供一键式 HTTPS 配置和云身份感知代理(IAP)，后者控制谁可以访问 Spinnaker 安装。 | | **自动备份** | Spinnaker 安装的配置会自动安全备份，这有助于用户进行审计和快速恢复。 | | **集成审计和监控** | Spinnaker for GCP 集成了 Spinnaker 和 Google Stackdriver，用于监控、故障排除和审计应用和 Spinnaker 本身的更改、部署和整体健康状况。 | | **易于维护** | 面向 GCP 的 Spinnaker 提供了许多助手来自动维护 Spinnaker 安装，其中包括面向 GKE 的 Spinnaker 配置。 |

Google 在 GKE 集群上提供了一个生产就绪的 Spinnaker 实例。基于云 Shell 的安装工具遵循推荐的做法，如防火墙、服务帐户、实例组和 bucket 来存储在 Google 云平台上运行 Spinnaker 的 Spinnaker 相关数据。该解决方案还与谷歌提供的其他服务(如谷歌云平台)进行了很好的集成，包括 Stackdriver(现为谷歌运营)、云构建、容器注册、谷歌 Kubernetes 引擎、谷歌计算引擎、谷歌应用引擎和云身份感知代理。

在 Google 云平台上安装 Spinnaker

现在让我们从在 GCP 上设置 Spinnaker 开始:

第一步:使用您在第一章中创建的 https://accounts.google.com/ 链接和凭证登录 GCP。

步骤 2:在本练习中，我们将创建一个新项目。使用以下步骤在 GCP 创建项目。点击新建项目，如图 3-4 所示。

图 3-4

GCP 上的三角帆装置

在下一个屏幕中提供项目名称。在这种情况下，我们将项目命名为mylearndmproject。点击创建按钮，如图 3-5 所示。

图 3-5

为 GCP 的 Spinnaker 装置创建新项目

第三步:选择新建的名为mylearndmproject的项目，如图 3-6 所示。

图 3-6

选择项目

第四步:导航到市场，如图 3-7 所示。

图 3-7

GCP 市场

第五步:搜索“用于 Google 云平台的 Spinnaker”，如图 3-8 所示。

图 3-8

用于谷歌云平台的 Spinnaker

第六步:点击 Spinnaker for Google Cloud Platform，如图 3-9 。

图 3-9

单击 Spinnaker for Google Cloud Platform，选择它

第 7 步:它将打开 Spinnaker for Google Cloud Platform 页面。点击转到 Spinnaker For Google 云平台选项，如图 3-10 所示。

图 3-10

转到 Spinnaker for Google 云平台

第八步:点击链接后，会得到云壳提示，确认将 GitHub repo https://github.com/GoogleCloudPlatform/spinnaker-for-gcp.git 克隆到云壳中。点击确认，如图 3-11 所示。

图 3-11

在云外壳中克隆 Spinnaker 代码

Cloud Shell 显示了一个文件树，其中包含了 Spinnaker 存储库中的文件，如图 3-12 所示。

图 3-12

Spinnaker 为云壳中的 GCP 代码

步骤 9:在终端上使用以下命令配置 Git。将[EMAIL_ADDRESS]替换为您的 Git 电子邮件地址，将[USERNAME]替换为您的 Git 用户名。

git config --global user.email 
    "[EMAIL_ADDRESS]"
git config --global user.name 
    "[USERNAME]"

1
2
3
4
5

步骤 10:现在通过在终端上执行以下命令，在您的项目中提供 Spinnaker(在我们的例子中，它是mylearndmproject)。

PROJECT_ID=mylearndmproject
    ~/cloudshell_open/spinnaker-for-gcp/scripts/install/setup_properties.sh

1
2
3

该命令的输出如图 3-13 所示。

图 3-13

我的学习项目 GCP 大三角帆

步骤 11:通过执行以下命令，将安装 Spinnaker。此安装命令可能需要大约 20 分钟才能完成。当输出显示Installation complete时，安装完成。观察云壳命令行，看看什么时候完成。

~/cloudshell_open/spinnaker-for-gcp/scripts/install/setup.sh

1
2

该命令的输出如图 3-14 和 3-15 所示。

图 3-15

用于 GCP 安装脚本执行的 Spinnaker

图 3-14

用于 GCP 设置的三角帆

步骤 12:重启云壳加载新的环境设置，如图 3-16 所示。

图 3-16

重启 GCP 云外壳

进入三角帆

安装 Spinnaker 后，您可以执行一个命令来转发端口以访问 Deck UI 并开始使用 Spinnaker。使用以下步骤访问 Spinnaker UI。

第一步:在云壳终端执行以下命令:

~/cloudshell_open/spinnaker-for-gcp/scripts/manage/connect_unsecured.sh

1
2

该命令将本地端口 8080 转发到端口 9000，供 Deck UI 使用。见图 3-17 。

图 3-17

GCP 港转运用三角帆

第二步:点击高亮显示的预览按钮，选择 8080 端口预览，如图 3-18 所示。

图 3-18

查看 GCP GUI 的 Spinnaker

这将打开 Spinnaker UI，如图 3-19 所示。

图 3-19

Spinnaker GUI

Spinnaker UI 将显示各种选项，例如搜索、项目、应用等等。在下一节中，您将了解 Spinnaker 中的一些关键选项；见图 3-20

图 3-20

Spinnaker GUI 选项

三角帆导航

让我们探索 Spinnaker UI 中的一些可用选项，并看看它们的相关性。

应用

要查看应用，点击应用选项，如图 3-21 所示。

图 3-21

Spinnaker GUI 应用选项

由于 GCP 的 Spinnaker 运行在 Kubernetes 集群上，该集群是在 GCP 安装 Spinnaker 期间创建的，因此在您再次登录到 Spinnaker UI 后，您将看到该应用显示为“Kubernetes”。要查看更多详情，请点击 Kubernetes，如图 3-22 所示。

图 3-22

Spinnaker 应用页面

在特定的应用页面(在本例中是 Kubernetes)上，单击 Config 选项可以深入到与应用相关的信息，比如应用属性、通知、特性等等。见图 3-23 。

图 3-23

Spinnaker 应用详细信息

通知

Spinnaker 可以向管道事件发送通知。它使用各种渠道发送通知，如电子邮件、SMS 和 Slack。

特征

您可以禁用任何不需要的主要功能，如图 3-24 所示。

图 3-24

Spinnaker 应用功能

链接

在“链接”部分，您可以包含自定义链接，这些链接是常用功能的快捷方式，如日志、健康状况等。

交通警卫集群

这种集群总是至少有一个活动实例。如果 Spinnaker 知道尝试删除、禁用或调整服务器组大小的用户或进程会使集群没有活动的实例，则该操作将被停止。表 3-3 显示了相关字段。

表 3-3

流量防护集群字段详细信息

|

田

|

必需的？

|

描述

|
| — | — | — |
| 账户 | 是 | 您正在为其设置流量监控的帐户。 |
| 地区 | 是 | 列表中的适用区域，或*代表所有区域。 |
| 堆 | 不 | 要应用此流量保护的堆栈。将此项留空，以便仅将保护应用于没有堆栈的集群。 |
| 详述 | 不 | 通过应用堆栈详细信息命名约定标识该集群所需的详细信息字符串。 |

应用创建

您必须在中创建应用，才能创建部署管道。要创建应用，请使用以下步骤。

第一步:点击操作，然后创建应用，如图 3-25 所示。

图 3-25

Spinnaker 应用创建

将出现新的申请单，如图 3-26 所示。

图 3-26

Spinnaker 创建表单

申请表包含各种需要填写的选项。有些是强制的，比如名字。表 3-4 列出了更多细节。

表 3-4

Spinnaker 应用表单字段详细信息

|

田

|

需要

|

描述

|
| — | — | — |
| 名字 | 是 | 用于标识该应用的唯一名称。 |
| 所有者电子邮件 | 是 | 在您安装的 Spinnaker 中，该应用所有者的电子邮件地址。 |
| 回购类型 | 不 | 承载此应用的代码库的平台。可能是 Stash，Bitbucket，GitHub，Google Storage，AWS S3 桶，Kubernetes 对象，Oracle 对象。 |
| 描述 | 不 | 如有必要，使用此文本字段描述应用。 |
| 仅考虑云提供商的健康状况 | 布尔，默认值 = 否 | 如果启用，云提供商报告的实例状态被认为足以确定任务完成。禁用时，任务需要由其他健康提供者(负载平衡器或发现服务)报告健康状态。 |
| 显示健康覆盖选项 | 布尔，默认值 = 否 | 如果启用，用户可以切换每个任务的先前选项。 |
| 实例端口 | 不 | 该字段用于生成从 Spinnaker 实例详细信息到正在运行的实例的链接。实例端口可以用于或覆盖为应用配置的特定链接(通过配置屏幕)。 |
| 启用重新启动正在运行的管道 | 布尔，默认值 = 否 | 如果启用，用户可以在管道仍在运行时重新启动管道阶段。不推荐这种行为。 |

在本章的后面，你会学到更多关于创建应用的知识。

管道模板

管道控制如何通过一系列阶段部署应用，这些阶段映射到应用部署/发布过程步骤。Pipeline 既可以手动执行，也可以自动执行，通过广泛的外部输入(比如 WebHook，在 Jenkins 作业完成后触发，基于从 Google 云存储上传工件的触发等等)。

创建管道

使用下列步骤创建管线:

步骤 1:选择要在其中创建管道的应用。

第二步:导航到 Spinnaker UI 中的 Pipelines 选项卡，如图 3-27 所示。

图 3-27

Spinnaker 管道选项

第三步:点击管道页签右上角的新建，如图 3-28 所示。

图 3-28

Spinnaker 管道创建

第 4 步:从下拉菜单中选择 Pipeline 并命名管道。然后点击创建按钮，如图 3-29 所示。

图 3-29

Spinnaker 新的管道创建选项

管道的配置信息作为一个 JSON 文件存储在 Spinnaker 中。当 Spinnaker 保存管道时，您使用 UI 对管道所做的任何更改都会被转换为 JSON 文件。创建管道后，您可以根据管道的需要添加任意多个阶段。我们将在“Spinnaker 的 CI/CD 用例”一节中详细介绍这一点。

第五步:要手动触发管道，在管道页签中点击开始手动执行，如图 3-30 和 3-31 所示。然后，Spinnaker 会显示一个确认对话框，您可以在其中添加任何必要的参数。

图 3-31

Spinnaker 管道执行参数

图 3-30

Spinnaker 管道手动执行

管道管理

管道管理用于在管道中执行与管理相关的活动，如重命名、删除、锁定等。您可以在管道管理中执行下列操作。

• 重命名管道:这个动作负责重命名管道。

• 删除管道:该操作允许您删除现有的管道。

• 禁用管道:如果想阻止管道执行，可以将其禁用。

• 锁定管道:锁定管道可以防止所有用户使用 Spinnaker UI 修改它。

• 将管道编辑为 JSON :无论您在 Spinnaker 上为创建应用或管道做了什么更改，Spinnaker 都会将它们转换为 JSON 格式。您可以根据需要编辑 JSON 文件，这些更改将会反映在 UI 中。

• 查看和恢复修订历史:每次保存管道，当前版本被添加到修订历史中。您可以使用不同版本管线的修订历史，或恢复较旧版本的管线。

• 将管道导出为模板:这个特性有助于在团队中标准化和分发可重用的管道。这些管道模板可以在单个应用中使用，也可以跨不同应用使用，甚至可以跨 Spinnaker 的不同部署使用。

管道表达式

通过管道表达式，开发人员可以通过设置变量并在管道执行期间动态使用它们来参数化管道。Spinnaker 提供了各种文本字段来提供这样的输入(例如，端口名、集群 IP 等。)在可以使用这些表达式的流水线阶段。管道表达式的一些用例可能是获取当前阶段名称、禁用特定阶段、检查另一个阶段的状态或获取内部版本号。开发人员也可以将 Java/Groovy 逻辑写入管道表达式。管道表达式语法基于 Spring 表达式语言(SpEL) 。

管道表达式以$开始，后跟开/闭括号:${ }。比如:${buildnumber}

Spinnaker 在某个阶段开始时计算该阶段的表达式。管道表达式不能在管道配置阶段使用，因为 Spinnaker 直到配置阶段完成后才开始计算表达式。

密码

Spinnaker 允许在管道表达式中执行 Java 代码。这对于高级的定制逻辑很有用，比如字符串操作。

操作员

Spinnaker 支持关系运算符，如==、<>、!=等等。这些运算符可用于比较表达式中的值。例如，您可以使用关系运算符检查实例大小是否大于 200(参见 https://docs.spring.io/spring/docs/current/spring-framework-reference/html/expressions.html ):

 ${instance["size"] > 200}

1
2

列表

Spinnaker 还支持可以在表达式中使用的列表。Spinnaker 提供了一个名为 stages 的列表，您可以使用它通过索引访问每个阶段。例如，${execution["stages"][0]}返回管道中第一阶段的值。

地图

您还可以使用映射从管道的 JSON 表示中访问数据。例如，${trigger["properties"]["example"]}计算出示例触发器属性的值。

数学

可以在表达式中使用算术运算，比如${trigger["buildInfo"]["number"] * 4}。

用线串

字符串对自己求值:${"Spinnaker"}比如变成了“Spinnaker”。

助手功能

Spinnaker 提供了内置的助手函数 ¹ ，帮助创建常见用途的管道表达式，例如通过名称访问特定阶段、解析 JSON 等等。以下是一些有用的表达方式:

• #fromUrl(String)。以字符串形式返回指定 URL 的内容。

• #currentStage().返回当前阶段。

• #toInt(String)。将值转换为整数。

• #alphanumerical(String)。返回传入字符串的字母数字值。

您可以通过在管道中添加一个井号(#)来获得管道表达式。它显示所有可用的助手功能列表，如图 3-32 所示。

图 3-32

Spinnaker 辅助函数

Note

https://spinnaker.io/reference/pipeline/expressions/#helper-properties亦见。

条件表达式

Spinnaker 管道表达式流程允许您使用条件表达式来触发特定条件下的任何事件。例如，假设您想在演习期间跳过某个特定阶段。您可以使用以下条件表达式trigger["dryRun"] == false。

前往 https://spinnaker.io/reference/pipeline/expressions/ 获取更多关于帮助器功能及其属性的详细信息。

项目

您会在 Spinnaker UI 的标题中找到项目选项，如图 3-33 所示。项目选项提供了各种应用的聚合视图。一个应用可以是许多项目的一部分，反之亦然。项目将有助于根据应用的性质对其进行隔离。如果 Spinnaker 正在为多个项目(基于 Java 的、基于 Python 的等等)执行交付管道，您可以在 Spinnaker 中隔离这些项目，以便于管理，并通过基于角色的访问控制来限制用户访问。

图 3-33

Spinnaker 项目选项

要创建项目，请单击项目菜单，然后导航至操作。选择创建项目，如图 3-34 所示。

图 3-34

Spinnaker 项目创建

单击 Create Project 选项后，需要用应用项目名称、所有者名称等填充一个表单。添加应用、集群和管道的详细信息，然后点击保存按钮创建项目，如图 3-35 所示。

图 3-35

Spinnaker 项目配置

带 Spinnaker 的 CI/CD 用例

在本节中，您将学习如何使用 Spinnaker 执行应用部署。在这个练习中，我们将使用一个基于微服务架构的袜子商店应用。使用以下步骤在 GKE 集群上部署 sock-shop 应用，如图 3-36 所示。

图 3-36

三角帆管道流

在 Spinnaker 管道中，我们检查袜子商店应用代码，它本质上是一个清单文件(complete-demo.yaml)，基于来自 GitHub 的 Kubernetes，位于 https://github.com/dryice-devops 。然后，我们将连接到 GKE 集群(我们使用 Google 创建的相同集群和服务帐户来部署 Spinnaker。).最后，我们将袜子商店应用部署到同一个 GKE 集群。现在让我们看看袜子商店应用架构。

袜子商店应用架构

sock-shop 应用是一个容器化的云原生应用，其中前端服务构建在 Node.js 上。

支付、用户和目录微服务运行在前端服务之后，使用 Go 语言构建。

订单、购物车、运输和队列管理微服务都是基于 Java 语言的。

MySQL 被用作持久性存储数据库，而 MongoDB 被用作服务数据存储。这两个数据库都作为 pods 下的一个容器运行，并在 Kubernetes 集群内部公开。

RabbitMQ 是一个开源消息队列框架，用于订单队列。它也作为一个容器运行，并在 Kubernetes 集群内部公开。图 3-37 显示了袜子店应用架构设计图。

图 3-37

袜子商店应用架构

Sock-shop 应用被打包成一个 Docker 映像，使用一个 Docker 文件，该文件包含如何构建映像的说明。我们使用complete-demo.yaml文件，这是该应用基于 Kubernetes 的部署。以下部分解释了应用的节点池和其他组件。

节点池选择

sock-shop 应用使用在创建 Kubernetes 集群时创建的默认节点池。

节点选择

我们在 YAML 文件中定义了节点选择，该文件用于在 Kubernetes 集群上部署应用。以下是在 Kubernetes 中将 pod 分配给节点的各种方法。

• nodeSelector:通过匹配用户定义的节点标签来选择部署特定 pod 的节点的最流行、最简单的方法。

• 节点关联:这个特性是在 Kubernetes 1.4 中引入的。它是节点选择器的增强版本。它提供了更具表现力的语法来控制如何将 pod 部署到特定节点。

• Pod 间关联:Pod 间关联通过将 Pod 调度到已经运行特定 Pod 的节点上，而不是基于节点上的标签，来实现共存。

在 sock-shop 应用中，我们使用nodeSelector在特定节点上部署 pod，如图 3-38 所示。

图 3-38

配置文件中的节点选择器片段

袜子商店应用中的服务

Kubernetes 中的服务是 pod 的逻辑集合/组。每个服务都有一个选择器部分，其中包含要连接的 pod 标签。这些是 Kubernetes 中的服务类型:

• ClusterIP(默认):在集群中的内部 IP 上公开服务，使服务只能从集群内部访问。

• NodePort :每个节点上的一个静态端口，服务在该端口上公开，并且可以从集群外部使用。

• 负载平衡器:在当前云中创建一个外部负载平衡器，并将固定的外部 IP 分配给服务。

按照袜子商店应用架构，前端与终端用户交互，这就是为什么前端服务是使用 GCP 外部负载平衡器公开的。

为了将前端服务公开为外部负载均衡器，我们在complete-demo.yaml文件中将其定义为type:LoadBalancer，如图 3-39 所示。在这种情况下，GKE 将通过调用适当的 Google Cloud API 并将其附加到前端服务来创建一个区域性的非代理外部网络负载平衡器。

图 3-39

作为负载平衡器的前端服务类型

sock-shop 应用的其他服务作为集群 IP 公开，这些服务在 GKE 集群内部，不能通过互联网访问(它们都是后端服务)。

下面是对complete-demo.yaml文件的简要说明:

• apiVersion :定义 Kubernetes 的apiVersion，与 Kubernetes API 服务器交互，创建对象。apiVersion根据用于容器平台的 Kubernetes 版本的不同而不同。

• kind :定义 Kubernetes 对象的类型，如 clusterRole、deployment、service、pods 等。在本例中，我们将其定义为部署和服务。

• 元数据:定义对象，如name as carts-db。

• 命名空间:定义将要创建 Kubernetes 对象的命名空间名称，比如sock-shop。

• 副本:要创建的 pod 的副本。

• 选择器:客户/用户用来识别一组对象。

• 模板:待复制对象的定义——在其他情况下可以自己创建的对象。

• 容器:定义容器的特性。

  • 名称:容器的名称。

  • 图像:哪个 Docker 图像用于创建容器。

  • Ports:Docker 容器运行的端口。

  • Env : env在 Docker 图像中使用的变量来运行容器。

• securityContext:管理 Kubernetes 集群上运行的 pod 或容器的权限和特权。该功能通过添加控制(如限制运行 pod 的用户的访问权限)、捕获流程系统调用或使用 AppArmor 功能限制程序执行权限(如读/写权限)来保护容器部署。

容器的安全设置如下:

• volumeMounts:这是容器中将要进行卷安装的路径。

• volume:这定义了我们将要使用的体积定义。

在 Spinnaker 中创建连续的交付管道

现在，我们将在 Spinnaker 中创建管道，为袜子商店应用执行连续交付。首先，我们将通过 Halyard 在 Spinnaker 中配置 GitHub 工件。它将从 GitHub ( https://github.com/dryice-devops/spinnaker )获取清单文件。使用以下步骤来配置 GitHub 工件。

配置一个 GitHub 工件

第一步:通过升降索执行以下命令。

hal config features edit –artifacts true
hal config artifact github enable

1
2
3

这些命令的输出将是**“成功启用 GitHub”**，如图 3-40 所示。

图 3-40

Spinnaker 上的 GitHub 配置

步骤 2:执行以下命令来添加 GitHub 帐户。在这种情况下，我们添加了dryice-devops帐户。如果您想添加您的 GitHub 帐户，请用该帐户名称替换dryice-devops。

hal config artifact github account add dryice-devops

1
2

你应该得到"Successfully added artifacts account dryice-devops for artifact"消息，如图 3-41 所示。

图 3-41

GitHub 帐户添加到 Spinnaker

步骤 3:执行以下命令，在 Spinnaker 上应用更改:

hal deploy apply

1
2

输出如图 3-42 、 3-43 和 3-44 所示。

图 3-44

GitHub 配置更改在 Spinnaker 上成功部署

图 3-43

GitHub 配置更改了 Spinnaker 上的部署进度

图 3-42

Spinnaker 上部署的 GitHub 配置更改

一旦配置了 GitHub 帐户，就可以在 Spinnaker 中创建应用了。

在 Spinnaker 中创建应用

按照以下步骤在 Spinnaker 中创建应用。

步骤 1:打开 Spinnaker GUI 并单击 Actions 下拉选项，该选项位于 Spinnaker GUI 屏幕的右上角。选择创建应用选项，如图 3-45 所示。

图 3-45

在 Spinnaker 上为 CI/CD 创建应用

第二步:打开新的应用窗口，如图 3-46 所示。

图 3-46

申请表格选项

填写行内必填字段，这些字段标有星号(*):

• 名称:输入应用名称。在这种情况下，我们称之为sock-shop-application 。

• 所有者电子邮件:提供 Spinnaker 将向其发送通知的所有者电子邮件。

• 回购类型:选择回购类型。在本例中，我们选择 GitHub 来获取袜子商店应用清单文件(一个基于 Kubernetes 的 YAML 文件)。

在 Repo Project 字段中，提供您的 GitHub 项目名称。在这种情况下，我们使用了名称dryice-devops。在 Repo Name 字段中，提供 GitHub 存储库名称。在这种情况下，我们使用spinnaker作为存储库名称，如图 3-47 所示。

图 3-47

申请表详情

保持其余选项不变，然后点击创建按钮，如图 3-48 所示。

图 3-48

保存申请表格

创建管道

Spinnaker 将按照给定的名称创建应用。现在可以创建管道来获取袜子商店应用清单文件(Kubernetes YAML 文件)。

步骤 1:打开新创建的应用页面，并导航到 Pipelines 页面。点击位于管道页签右上角的创建管道按钮，如图 3-49 所示。

图 3-49

为袜子店应用的 CI/CD 创建管道

步骤 2:在您点击 Create New Pipeline 按钮(一个+号)之后，一个表单将会打开。提供一个管道名称(在本例中，我们使用sock-shop-pipeline ) **。**保持其他选项不变，单击 Create 按钮在 Spinnaker 中创建管道。见图 3-50 。

图 3-50

袜子店应用的管道创建表单 CI/CD

第三步:新管道创建完成后，将打开配置页面，如图 3-51 所示。

图 3-51

袜子商店管道配置

第四步:对于配置，首先选择添加工件，可以在配置的预期工件部分找到，如图 3-52 所示。这些工件将被用于管道中的 Kubernetes 集群。

图 3-52

添加工件

步骤 5:单击 Add Artifacts 选项后，会打开一个包含更多选项的菜单。首先，您必须选择用于从各种来源获取工件的帐户，例如 Docker 图像的 Docker 注册表、Kubernetes 等等。您也可以定义您的定制工件。当我们从 GitHub 获取清单文件时，我们选择了在“配置 GitHub 工件”一节中配置的dryice-devops帐户。见图 3-53 。

图 3-53

添加工件帐户

接下来，提供在 GitHub 中dryice-devops项目下提交的清单文件 ( complete-demo.yaml ) 的文件路径，并提供显示名称。在这种情况下，显示名称是sock-shop-github。点击保存按钮，如图 3-54 所示。

图 3-54

添加工件帐户详细信息

现在，我们将在管道中添加执行所需操作的阶段，以便在 GKE 集群上部署工件(complete-demo.yaml)文件。使用以下步骤在管道中添加阶段:

第一步:点击添加阶段选项，在配置的下方，如图 3-55 所示。

图 3-55

添加工件帐户详细信息

第二步:点击添加阶段将显示图 3-56 中的选项。

图 3-56

添加部署阶段

步骤 3:单击类型以获得 Spinnaker 支持的用于应用部署的各种选项。选择 Deploy (Manifest)选项部署一个 Kubernetes 清单 YAML 文件，如图 3-57 所示。

图 3-57

选择部署清单选项

选择 Deploy 之后，Spinnaker 将在基本设置下显示与部署(清单)配置相关的选项。选择spinnaker-install-account账户，如图 3-58 所示。这是 GCP 在 GKE 集群上安装 Spinnaker 时创建的服务帐户。

图 3-58

选择服务帐户

现在选择sock-shop-application我们在应用部分创建的应用，如图 3-59 所示。

图 3-59

选择应用

步骤 4:在清单配置选项中，我们必须选择部署 GKE 集群所需的 Kubernetes 工件。有两个选项——一个是文本，您可以按原样粘贴清单文件，第二个是您可以在工件选项中选择清单文件。在这种情况下，我们将选择 Artifact 选项，它将显示其他子选项，如图 3-60 所示。现在选择sock-shop-github作为我们在管道的配置部分创建的清单工件，并保留其他选项。

图 3-60

清单配置

点击保存修改按钮，如图 3-61 所示。

图 3-61

保存更改

第五步:点击开始手动执行选项，现在手动运行sock-shop-pipeline，如图 3-62 所示。

图 3-62

流水线执行

第 6 步:你会看到流水线执行的进度，如图 3-63 所示。

图 3-63

管道执行进度

如果所有定义的阶段的状态都显示为SUCCEEDED，那么 sock-shop 应用在 GKE 集群上的部署是成功的。

在下一步中，您将学习如何验证 sock-shop 应用是否部署在 GKE 上，并获取前端 UI IP 地址，以便您可以在任何浏览器上打开 sock-shop 应用。

您可以获得关于 Spinnaker 执行的步骤的更多细节，并获得关于已部署的 Kubernetes 工作负载的特定信息(例如，部署、pods 等。)从正在运行的流水线状态的执行细节部分，如图 3-64 所示。

图 3-64

管道阶段详细信息

要获得关于特定 Kubernetes 对象的更多详细信息，请单击相应的详细信息链接，如图 3-65 所示。

图 3-65

袜子店部署详情

一旦你点击详细信息选项，Spinnaker 将显示状态、创建类型、种类和其他详细信息，如图 3-66 所示。

图 3-66

袜子店应用组件详细信息

从 Load Balancers 部分，您将获得根据 sock-shop 应用的清单文件创建的服务和入口的详细信息，如图 3-67 所示。

图 3-67

袜子店负载平衡器详细信息

第 7 步:导航到 GCP 控制台页面并选择 Kubernetes 引擎。点击集群选项，如图 3-68 所示。

图 3-68

GKE 集群

步骤 8:选择工作负载，查看与 sock-shop 应用相关的 Kubernetes 部署和 pod，如图 3-69 所示。

图 3-69

袜子店应用工作负载详细信息

您也可以通过执行下面的kubectl命令从云 Shell 中验证这些:

kubectl get namespace

1
2

这验证了 sock-shop 名称空间已创建。现在执行下面提到的其他命令来查看部署在sock-shop名称空间下的 pod 和服务。

kubectl get pods -n sock-shop
kubectl get service -n sock-shop

1
2
3

你会看到命令的输出，如图 3-70 、 3-71 和 3-72 所示。

图 3-72

GKE 集群中的袜子店服务列表

图 3-71

GKE 集群中的袜子店列表

图 3-70

GKE 集群中的 sock-shop 命名空间

步骤 9:现在我们将获取袜子商店应用前端组件端点，以在浏览器中打开袜子商店应用。导航到 Kubernetes 引擎页面，然后单击服务和入口。您将能够查看部署在 GKE 集群上的服务。现在查找前端服务，然后注意外部负载平衡器的详细信息，如图 3-73 中突出显示的。

图 3-73

袜子商店前端端点

第十步:打开任意浏览器，按照上一步粘贴复制的 IP 地址(如 http://34.75.85.135 )。按下输入按钮。你将看到袜子店应用，如图 3-74 所示。

图 3-74

袜子商店应用 web 界面

Spinnaker 的金丝雀部署用例

在本节中，我们将使用 Google 云组件(如 Google Kubernetes Engine (GKE)、Spinnaker 以及云构建和云源存储库)创建一个持续交付管道。我们将利用 Google 提供的一个样例应用，并配置这些 GCP 服务来建立一个自动化的构建、测试和部署过程。任何代码修改都将触发新代码变更的自动构建、测试和部署，以展示连续交付。连续输送管道流程如图 3-75 所示。

图 3-75

canary 部署的 CI/CD

此使用案例的主要目标如下:

• 创建一个名为app-cluster的新 GKE 集群来部署示例应用。

• 下载一个示例应用，创建一个 Git 存储库，并将其上传到一个云资源存储库。

• 建立你的码头工人形象。

• 创建触发器，以便在应用代码更改时创建 Docker 图像。

• 配置一个 Spinnaker 管道，使用 canary 部署策略在 GKE 集群上部署示例应用。

• 手动执行 Spinnaker 管道，并在 Docker 图像标签改变时自动触发。把它推到容器注册处。

创建新的 GKE 集群

在部署示例应用之前，按照以下步骤创建一个名为app-cluster的新 GKE 集群。

步骤 1:使用 Cloud Shell，我们将创建一个名为app-cluster的新 GKE 集群来部署示例应用。在云 Shell 中执行内联命令。

ZONE=us-east1-c
gcloud config set compute/zone $ZONE
gcloud container clusters create app-cluster 
--machine-type=n1-standard-2

1
2
3
4
5

这些命令的输出如图 3-76 、 3-77 和 3-78 所示。

图 3-78

GKE 应用-集群已创建

图 3-77

GKE 应用-集群创建开始

图 3-76

GKE app-集群创建命令

您可以在 GCP 控制台中通过导航到 Kubernetes 引擎➤集群来验证这一点。您可以查看新创建的集群，如图 3-79 所示。

图 3-79

GCP 控制台上的 GKE 应用集群验证

步骤 2:通过执行以下命令，将新的 GKE 集群添加到 Spinnaker 中。

~/cloudshell_open/spinnaker-for-gcp/scripts/manage/add_gke_account.sh

1
2

该命令的输出如图 3-80 所示。

图 3-80

将 GKE 应用集群添加到 Spinnaker

步骤 3:现在通过执行以下命令，将 Kubernetes 上下文改回到名为spinnaker1的 Spinnaker 集群:

kubectl config use-context gke_mylearndmproject_us-east1-c_spinnaker-1

1
2

我们这样做是为了创建管道，以便在 GKE 集群上部署示例应用。该命令的输出如图 3-81 所示。

图 3-81

将 Kubernetes 上下文从 app-cluster 更改为 Spinnaker

步骤 4:现在，我们将通过执行以下命令，将配置更改推送并应用到 Spinnaker。

~/cloudshell_open/spinnaker-for-gcp/scripts/manage/push_and_apply.sh

1
2

该命令的输出如图 3-82 所示。

图 3-82

将更改应用到 Spinnaker

第五步:为了让 Cloud Build 检测到你的应用源代码的变化，你必须构建一个 Docker 镜像，然后把它推送到容器注册中心。在 Cloud Shell 中执行以下命令来下载示例源代码。

cd ~
wget https://gke-spinnaker.storage.googleapis.com/sample-app-v4.tgz

1
2
3

该命令的输出如图 3-83 所示。

图 3-83

下载示例应用源代码

步骤 6:通过执行下面的命令来解包源代码。

tar xzfv sample-app-v4.tgz

1
2

该命令的输出如图 3-84 所示。

图 3-84

解包示例应用源代码

步骤 7:现在通过执行下面的命令来改变目录。

cd sample-app

1
2

该命令的输出如图 3-85 所示。

图 3-85

进入示例应用

步骤 8:让我们通过执行下面的 Git 命令对源代码库进行初始提交。

git init
git add .
git commit -m "Initial commit"

1
2
3
4

这些命令的输出如图 3-86 所示。

图 3-86

进入示例应用

步骤 9:通过执行以下命令，创建一个存储库来存放这段代码。

gcloud source repos create sample-app

git config credential.helper gcloud.sh

1
2
3
4

这些命令的输出如图 3-87 和 3-88 所示。

图 3-88

在存储库中配置凭据

图 3-87

在 GCP 上创建知识库

步骤 10:添加新创建的存储库作为remote。

export PROJECT=$(gcloud info --format='value(config.project)')

git remote add origin https://source.developers.google.com/p/$PROJECT/r/sample-app

1
2
3
4

该命令的输出如图 3-89 所示。

图 3-89

存储库作为远程添加

步骤 11:现在通过执行下面的命令将代码推送到新存储库的主分支。

git push origin master

1
2

该命令的输出如图 3-90 所示。

图 3-90

将代码推入新的存储库

第 12 步:导航到 https://console.cloud.google.com/code/develop/browse/sample-app/master?ga 链接，可以在控制台看到签入的源代码，如图 3-91 所示。

图 3-91

将代码推入新的存储库

在接下来的步骤中，我们将构建 Docker 映像，运行单元测试，并将 Docker 映像推送到 Google 容器注册表，如图 3-92 所示。

图 3-92

谷歌代码构建管道

现在，我们将配置 Cloud Build，以便每当我们将 Git 标签推送到源存储库时，构建并推送 Docker 映像。Cloud Build 自动检查源代码，从存储库中的 Docker 文件构建 Docker 映像，并将该映像推送到容器注册中心。

使用以下步骤执行这些任务。

第一步:在云控制台中，导航到云构建部分，点击触发器，然后点击创建触发器，如图 3-93 和 3-94 所示。

图 3-94

Google 代码构建触发器

图 3-93

谷歌代码构建

步骤 2:在触发器表单中设置以下触发器设置:

• 姓名 : sample-app-tags

• 事件:选择推送新标签

• 储存库 : sample-app

• 标签(regex) : v.*(用于触发)

• 构建配置 : /cloudbuild.yaml这个文件附带了示例代码，用于在每次将 Git 标签推送到源存储库时构建和推送 Docker 映像。

完成后，点击创建按钮，如图 3-95 所示。

图 3-95

Google 代码构建触发器表单

一旦新的触发器被创建，你可以在同一个触发器上看到它，如图 3-96 所示。

图 3-96

触发器创建的 Google 代码版本

现在，每当我们将前缀为字母v的 Git 标签推送到源代码库时，Cloud Build 会自动构建应用，并将它作为 Docker 映像推送到容器注册表。

现在我们将准备 Kubernetes 清单，Spinnaker 将使用它来部署 GKE 集群。

本节创建一个云存储桶，在云构建中的 CI 过程中，将使用清单填充该桶。清单存储在云存储中后，Spinnaker 将在管道执行期间下载并应用它们。

步骤 1:通过执行以下命令在 GCP 创建 bucket。

export PROJECT=$(gcloud info --format='value(config.project)')
gsutil mb gs://$PROJECT-kubernetes-manifests

1
2
3

这些命令的输出如图 3-97 所示。

图 3-97

GCP 的水桶创作

导航到存储➤浏览器，可以看到新的存储桶已经创建，如图 3-98 所示。

图 3-98

GCP 的水桶创作

步骤 2:在存储桶上启用版本控制，这样您就可以维护清单的历史。

gsutil versioning set on gs://$PROJECT-kubernetes-manifests

1
2

该命令的输出如图 3-99 所示。

图 3-99

GCP 的水桶创作

步骤 3:在 Kubernetes 部署清单中设置正确的 Google Cloud 项目 ID:

sed -i s/PROJECT/$PROJECT/g k8s/deployments/*

1
2

该命令的输出如图 3-100 所示。

图 3-100

在 Kubernetes 部署中设置云项目 ID

步骤 4:将变更提交给存储库。

git commit -a -m "Set project ID"

1
2

该命令的输出如图 3-101 所示。

图 3-101

将更改提交到存储库

在下一部分中，我们将在 Spinnaker 中创建一个持续部署管道，如图 3-102 所示。

图 3-102

将更改提交到存储库

第 1 步:使用命令行界面spin创建一个名为sample的应用。Spinnaker 附带了用于 GCP 的 Spinnaker 包，所以没有必要在 GCP 明确地安装它。

spin application save --application-name sample 
                      --owner-email example@example.com 
                      --cloud-providers kubernetes 
                      --gate-endpoint http://localhost:8080/gate

1
2
3
4
5

该命令的输出如图 3-103 所示。

图 3-103

在 Spinnaker 中创建应用

步骤 2:在云 Shell 上，从sample-app根目录运行以下命令，为示例应用创建 Kubernetes 服务。

     kubectl apply -f k8s/services

1
2

该命令的输出如图 3-104 所示。

图 3-104

为示例应用创建的服务

第三步:导航到 Spinnaker UI ➤应用➤样例，如图 3-105 所示。

图 3-105

为示例应用创建的服务

现在我们将在sample应用中创建新的管道deploy，点击创建按钮，如图 3-106 所示。

图 3-106

创建部署管道

步骤 4:在 Cloud Shell 中，在源代码目录下运行下面的命令，创建一个新的 spinnaker 管道模板作为updated-pipeline-deploy.json。这是基于当前的 Google 项目，带有名为pipeline-deploy.json的现有管道模板，附带示例代码。

export PROJECT=$(gcloud info --format='value(config.project)')
sed s/PROJECT/$PROJECT/g spinnaker/pipeline-deploy.json > updated-pipeline-deploy.json

1
2
3

执行完这些命令后，点击打开的编辑器查看新创建的updated-pipeline-deploy.json文件，如图 3-107 所示。

图 3-107

打开编辑器

你会看到项目文件夹➤大三角帆➤ updated-pipeline-deploy.json。复制updated-pipeline-deploy.json文件的内容，如图 3-108 所示。

图 3-108

updated-pipeline-deploy.json 文件

步骤 5:在 Spinnaker 中，导航到我们刚刚创建的部署管道的配置页面，并选择管道操作➤编辑为 JSON，如图 3-109 所示。

图 3-109

编辑管道

在 JSON 编辑器中，复制updated-pipeline-deploy.json文件的内容，点击更新管道按钮，如图 3-110 所示。

图 3-110

编辑管道的 JSON

第 6 步:您将看到更新后的管道配置，如图 3-111 所示。

图 3-111

部署管道流

手动运行管道

我们刚刚创建的配置包含一个触发器，每当推送一个包含前缀v的新 Git 标记时，该触发器就会启动管道。现在，您将通过手动运行来测试管道。

第一步:在部署管道页面，点击开始手动执行选项，如图 3-112 所示。

图 3-112

手动执行管道

您将在 pipeline execution 页面上看到管道的进度，在这里您可以验证 Spinnaker 管道采用了新的 Docker 镜像版本v1.0.0，如图 3-113 所示。

图 3-113

管道的手动执行

从执行细节部分还可以看到流水线流程图，如图 3-114 所示。

图 3-114

管道执行细节

步骤 2:管道执行将暂停，等待人工批准将 Kubernetes 清单部署到 GKE 集群上。点击继续按钮，提供手工审批，如图 3-115 所示。

图 3-115

人工批准

点击继续按钮后，流水线执行剩余阶段，如图 3-116 和 3-117 所示。

图 3-117

生产部署进度

图 3-116

生产部署

当所有阶段运行成功后，管道状态为SUCCEEDED，如图 3-118 所示。

图 3-118

Spinnaker 部署管道状态

第三步:导航到 Google 控制台➤ Kubernetes 引擎➤工作负载，查看示例应用 Kubernetes 工作负载，如图 3-119 所示。

图 3-119

Spinnaker 管道状态

现在点击服务和入口来查看sample-frontend-canary和sample-frontend-production **的端点。**要导航至应用 GUI，请在浏览器中打开它。复制端点并粘贴到浏览器中，如图 3-120 、 3-121 和 3-122 所示。

图 3-122

示例应用生产前端 GUI

图 3-121

示例应用金丝雀前端 GUI

图 3-120

示例应用前端端点

通过代码更改自动触发管道

现在，让我们通过更改代码、推送 Git 标记并观察管道的响应执行来测试管道的端到端。通过推送一个以v开头的 Git 标签，我们将触发容器构建器构建一个新的 Docker 映像，并将其推送到容器注册中心。Spinnaker 自动检测到新的图像标签以v开始，并触发管道将图像部署到 canaries，运行测试，并将图像部署到部署中的所有 pod。

第一步:在sample-app目录下执行以下命令，将 app 的颜色从橙色改为黄色。

sed -i 's/orange/yellow/g' cmd/gke-info/common-service.go

1
2

该命令的输出如图 3-123 所示。

图 3-123

更改示例应用的背景颜色

步骤 2:现在我们将标记变更，并将其推送到源代码存储库。为此，请执行以下命令。

git tag v1.0.1
git push --tags

1
2
3

该命令的输出如图 3-124 所示。

图 3-124

新标签

一旦这个命令被执行，我们将看到新的构建出现在 Google Cloud 构建中。导航到 https://console.cloud.google.com/cloud-build/builds 。

然后你会看到新的标签V1.0.1，如图 3-125 所示。

图 3-125

创造历史

步骤 3:观察金丝雀部署。当部署暂停，等待推广到生产时，开始刷新包含应用的选项卡。九个后端运行应用的前一版本，而只有一个后端运行金丝雀。参见图 3-126 。

图 3-126

自动触发部署管道

步骤 4:当管道完成时，如图 3-127 所示，你会看到由于代码的改变，颜色变成了黄色，版本字段现在显示为v1.0.1。

图 3-127

自动触发部署管道成功完成

现在单击服务和入口来确定sample-frontend-canary的端点。要在浏览器中打开它并查看 GUI，只需复制端点 IP 地址并将其粘贴到浏览器中。您将看到图形用户界面更新为黄色，如图 3-128 和 3-129 所示。

图 3-129

黄色淡黄色 GUI

图 3-128

canary 部署的端点

摘要

在本章中，您学习了 Spinnaker 连续部署工具。我们讨论了 Spinnaker 架构及其在 Google 云平台(GPC)上的安装步骤。您还了解了如何使用 Spinnaker 在 GKE 上部署应用，以及可以使用 Spinnaker 轻松配置的各种部署策略。在下一章中，我们将介绍如何利用 Tekton 实现 GCP 自动化。

Footnotes 1

https://spinnaker.io/reference/pipeline/expressions/#helper-functions