Spinnaker是一个开源的多云持续交付工具，最初由Netflix设计和开发。它有助于将应用程序部署到各种云提供商，例如GoogleCloudPlatform(GCP)、AmazonWebServices(AWS)和MicrosoftAzure。本博客的目的是帮助开发人员、架构师和业务从业者了解在采用Kubernetes环境时使用Spinnaker的重要性。您将了解：Spinnaker在Kubernetes环境中的作用在Kubernetes环境中使用Spinnaker了解Spinnaker的架构使用Spinnaker设计持续交付管道解释Spinnaker管道工作流程使用Spinnaker设计持续交付管道的最佳实践Spinnaker在Kubernetes环境中的作用由于组织各种各样的公司都在采用Kubernetes，因为它可以轻松管理多容器环境。然而，Kubernetes不是像Jenkins或Spinnaker这样的持续交付或部署工具。早期，Kubernetes生态系统缺乏一个简单的持续交付工具来自动构建Kubernetes清单、测试这些工件并部署这些工件。Jenkins支持在Kubernetes集群上持续交付应用程序，但增加了复杂性。Spinnaker支持在Kubernetes集群上部署应用程序。它简化了这个过程，并帮助组织在Kubernetes集群上部署生产级构建工件。Spinnaker还通过其图形用户界面(GUI)来管理部署在Kubernetes集群上的应用程序。可以编辑和更新Kubernetes清单文件，以提供动态编辑Kubernetes特定属性的能力。使用SpinnakerGUI，您还可以监控Kubernetes对象的运行状况。在Kubernetes环境中使用SpinnakerSpinnaker受到各种云提供商的支持，例如AppEngine、AmazonWebServices(AWS)、Azure、GoogleCloudPlatform(GCP)、CloudFoundry、Oracle和Kubernetes。当您在云端安装带有Kubernetes的Spinnaker时，它会提供Kubernetes原生的、基于清单的部署。Spinnaker使用一个帐户向Kubernetes集群进行身份验证。Spinnaker在Kubernetes环境中的关键功能是应用管理和应用部署。应用程序管理功能有助于管理和查看Kubernetes集群对象。使用Spinnaker可以对Kubernetes对象执行各种操作，例如放大、缩小、回滚和转发。Spinnaker的这一特性有助于从一个点（即SpinnakerGUI）管理多个Kubernetes集群。Spinnaker的应用程序部署功能用于在Kubernetes集群中部署各种对象。Spinnaker在Kubernetes集群中部署应用程序时支持各种部署策略，例如蓝/绿、滚动更新、金丝雀部署等。为了执行应用程序部署，Spinnaker使用管道和阶段。借助Spinnaker管道，您可以创建持续交付流程，以自动将代码从源代码控制工具部署到Kubernetes集群。您还可以使用Spinnaker阶段在生产Kubernetes集群上部署任何内容之前执行代码验证。了解Spinnaker的架构Spinnaker由独立的微服务组件组成。下面提到了其中一些组件：Deck：提供与Spinnaker工具交互的用户界面。Gate：充当API网关。它将所有API请求传递给服务。Orca：处理各种临时操作并管理管道及其阶段。Clouddriver：云提供商。作为Spinnaker和云提供商之间的集成点。Front50：保留应用程序、管道和项目的元数据。Rosco：烘焙图像，然后将它们部署在各种云提供商上。Igor：通过Jenkins和TravisCI等持续集成平台触发管道。Echo：通过电子邮件、短信和Slack发送通知。它还负责处理传入的webhook，例如Githubwebhook和Jenkinswebhook。Fiat：充当Spinnaker的授权服务。Kayenta：为Spinnaker提供自动金丝雀分析。Halyard：用于安装、更新和配置Spinnaker的配置服务。使用Spinnaker设计持续交付管道创建了一个持续交付管道，用于在两个不同的Kubernetes命名空间（即DEV和UAT）上部署Kubernetes清单和应用程序构建（docker镜像）。要创建持续交付管道，您需要一个HelmChart作为Kubernetes清单文件的模板，Spinnaker使用它来创建最终可部署的Kubernetes清单工件。您可以创建五个单独的Spinnaker管道，如下所述：DEV-Kubernetes集群YAML文件更改部署管道：此管道用于在Kubernetes集群的DEV命名空间上进行部署，由Kubernetes清单文件(dev.yaml)的更改触发。UAT-Kubernetes集群的YAML文件更改部署管道：此管道用于部署在Kubernetes集群的UAT命名空间上，由Kubernetes清单文件(uat.yaml)中的更改触发。DEV–DockerImage–ApplicationDeploymentPipeline：该流水线用于在代码变更后构建Docker镜像并部署到Kubernetes集群的DEV命名空间。UAT–DockerImage–ApplicationDeploymentPipeline：此管道用于在代码更改后构建Docker映像并将其部署到Kubernetes集群的UAT命名空间。UAT-Jenkins手动Docker镜像部署流水线：该流水线用于在代码变更后构建Docker镜像，并手动部署到Kubernetes集群的UAT命名空间上。它使用户能够在UAT命名空间上手动部署所需的应用程序代码（Docker镜像）。上面提到的两个Spinnaker流水线分别在DEV和UAT命名空间上自动部署代码。它让用户可以控制部署在UAT命名空间上的应用程序代码（Docker镜像）。说明计划部署的Spinnaker管道工作流程的Kubernetes清单文件和应用程序代码（Docker映像）现在应推送到GitHub存储库。在GitHub上配置一个webhook自动推送变更通知给Jenkins，Jenkins配置有作业自动检测GitHub中的应用程序代码变更。Jenkins作业获取最新的应用程序代码更改并构建Docker映像。使用Docker插件或本机dockerCLI命令，Jenkins将新创建的图像推送到DockerHub。相应的Spinnaker管道在自动触发器的帮助下持续监控DockerHub注册表。在DockerHubregistry中获取到最新的Docker镜像后，就可以执行Spinnakerpipelinetrigger，将相应的应用代码（Docker镜像）部署到Kubernetes集群的DEV/UAT命名空间上。让我们详细讨论每个管道。DEV和UAT部署管道的Kubernetes集群管道的YAML文件更改Spinnaker管道由四个阶段组成-Configure、Jenkins、Bake（清单）和Deploy（清单）。配置阶段是一个自动触发器，配置为检测dev.yml或uat.yml文件中的提交更改。如果这些文件有变化，这个流水线就会开始执行。Jenkins阶段向Jenkins作业发送触发器，该作业在现有Kubernetes集群上执行一组Linux命令（构建映像指令）以检测最近部署的Docker映像标签。此阶段确保现有的Docker映像不会被标记和更新为最新的Docker映像。之后，Jenkins阶段将现有的Docker镜像标签记录在一个文本文件中（例如，build_uat_yml.properties）。稍后，文本文件将传递到下一个Spinnaker阶段Bake(manifest)。这个阶段配置了一个模板，其中包含图像标签的变量“{{.Values.image.tag}}”。spinnaker将此变量值替换为build_uat_yml.properties/build_dev_yml.properties文件中存在的键值。然后，Spinnaker创建一个最终构建工件，其中包含Jenkins作业记录的清单值和Docker镜像标签值。部署（清单）阶段使用此最终工件并将此清单构建工件部署到DEV/UAT名称空间上，而不更新现有的Docker映像标签。DEV-DockerImage-应用程序部署管道此Spinnaker管道由三个阶段组成：配置、烹饪（清单）和部署（清单）。Configure阶段配置了自动触发器，以检测DockerHub注册表中新推送的Docker映像。Bake(Manifest)阶段用于基于现有的Helm模板和定义的dev.yml值文件创建Kubernetes清单文件。最终工件是使用带有“最新”标签的Docker映像创建的。最终工件由部署（清单）阶段使用，并部署在已配置的Kubernetes集群的DEV命名空间中。UAT-DockerImage-应用程序部署管道此管道使用与上述相同的过程从现有的Helm模板和定义的uat.yml值文件创建最终工件。唯一不同的是，这个阶段配置了一个自动触发器作为“DEV-DockerImage-ApplicationDeployment”流水线的执行结果。“DEV-DockerImage-ApplicationDeployment”管道的成功执行/完成将启动管道的执行。如果“DEV-DockerImage-ApplicationDeployment”流水线的执行进入失败状态，流水线将永远不会开始执行，这将阻止失败的工件被部署到Kubernetes集群的UAT命名空间中。UAT-Jenkins手动Docker镜像部署管道此管道可帮助用户根据需要在UAT命名空间中部署遗留Docker镜像工件。用户提供所需的Docker映像标签，该标签将通过参数化的Jenkins作业进行部署，该作业创建一个文本文件（例如build.properties），其中包含用户提供的Docker映像作为内容。例如–IMAGE_TAG=v15。这里，v15是用户提供的镜像标签。将build.properties文件作为输入传递给Spinnaker管道。烘焙（清单）阶段配置有一个模板，其中包含图像标签的变量“{{.Values.image.tag}}”。Spinnaker将该变量值替换为构建属性文件中存在的键值。Spinnaker随后会创建最终的构建工件，其中包含清单值和用户传递的Docker镜像标签值。部署（清单）阶段使用此最终工件，并通过使用上述标签拉取相应的Docker映像，在UAT命名空间上部署此清单构建工件。使用Spinnaker设计持续交付流水线的最佳实践Spinnaker提供的GUI允许用户进行应用程序管理，例如直接通过GUI编辑Kubernetes对象YAML定义文件。但大多数时候，源代码控制工具用于存储和控制Kubernetes对象YAML定义文件。在这种情况下，通过SpinnakerGUI完成的任何YAML文件更改都将在下一次管道部署期间被覆盖。因此，强烈建议更改存储在源代码管理工具中的YAML文件，而不是直接通过SpinnakerGUI编辑YAML文件。使用Docker图像推送而不是GitHub推送触发器或Jenkins作业触发器配置Spinnaker管道触发器。这种方法避免了构建和验证系统的重组。不要在Docker镜像中烘焙Secrets。应使用云提供商的密钥管理服务在运行时加载机密。使用审核日志来确定执行了哪些操作、执行时间以及执行者。最佳实践是通过将Spinnaker与GCPStackdriver和AWSCloudWatch等云监控服务集成来生成Spinnaker审计日志。通过Kubernetes对象YAML文件在Kubernetes集群上部署Docker镜像。在YAML文件中定义Docker镜像有两种方法，一种是定义镜像标签，另一种是定义镜像摘要。最佳实践是通过摘要在YAML文件中定义Docker镜像。这种方法将确保已部署的Docker映像始终指向相同的内容。Spinnaker是一个强大的持续交付工具，用于在Kubernetes集群上自动部署应用程序。Spinnaker管道还可以配置为在执行实际部署之前对构建工件执行单元和功能测试。因此，Spinnaker可以帮助组织更快地将代码投入生产。
