Spinnaker 基于判断的条件分支流水线

Manual Judgment Stage “Manual Judgment Stage” 是 Spinnaker Pipeline 中的一种阶段 (“Stage”) 类型,该类型可以作为流水线的门户,作为带外 (Out-of-Bound) 流水线检查,等待手动检查,并且判断结果会终止或继续流水线的执行。 创建一个基于Manual Judgment的流水线 创建一个流水线,添加一个新的 Stage,选择 “Manual Judgment” 图:Manual Judgment创建页面 Jugement Inputs 部分添加对应的选项,选项可以带入变量 $judgment 中 图:Manual Judgment 在执行时 Jugement Inputs Option 的展示 或者是不添加任何选项,那么这个时候就会只有 Stop 和 Continue 两个按钮 图:当 Manual Judgment 没有配置Jugement Inputs Option 的展示 如果添加了选项,可以根据 “选项” 来判断执行的分支 判断可以使用每个阶段内的条件表达式 ”Conditional on Expression“,或者 Check Precondition 类型的阶段 图:根据 “Stage Conditional on Expression” 来定义的选项 “Check Precondition” 是 Spinnaker 流水线中的一个阶段,它可以先前条件并且判断是否继续,这里主要检查该流水线之前所有的流水线你定义要检查的内容,并继续执行接下分支或者阶段 图:“Check Precondition” 的三种类型 图:“Check Precondition” 选择添加表达式的页面 这里选择使用 表达式 (Expression) 来判断前置条件,例如我判断前置 Stage 的选择是否为 “aaaa”...

 ·  · 

Spinnaker 自定义Pipeline模板思路

流水线模板组合思路 官方流水线示例中没有给出完整的流水线模板和完整的字段,只给出了一个大致的 schema [1],如下所示 json 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 { "schema": "v2", "variables": [ { "type": "<type>", "defaultValue": <value>, "description": "<description>", "name": "<varName>" } ], "id": "<templateName>", # The pipeline instance references the template using this "protect": <true | false>, "metadata": { "name": "displayName", # The display name shown in Deck "description": "<description>", "owner": "example@example....

 ·  · 

使用Spinnaker进行金丝雀分析

2018 年,Kayenta(一种用于自动化金丝雀分析的开源工具)作为 Spinnaker 项目的一部分推出。在本文中,我们描述了如何将 Kayenta 集成到我们现有的部署设施中,极大地提高了部署管道的可靠性并为自动化生产部署创造了先决条件。 概念理解 什么是金丝雀分析? 金丝雀分析 (canary analysis) 是一个两步的过程,分析将根据选定的指标和日志评估金丝雀,以推断我们是否要升级或回滚新版本。因此,我们需要确保在测试过程中收集正确的信息(指标和日志)并进行可靠的分析。 金丝雀分析的执行步骤 指标选择 指标评估 指标选择 该步骤涉及选择正确的指标来监控应用程序和金丝雀健康状况。因此我们需要确保创建一套平衡的指标来评估指标。最后,需要根据彼此的相关性对指标进行分组。 对于指标的选择,根本不需要选择所有指标,因为目前流行的基于微服务的应用程序通常会生成大量监控指标数据,因此我们不能简单地分析所有指标。 指标评估标准 选择重要的业务指标 最重要的指标是值对 可以反应服务 “成功/失败” 最重要的指标。例如,在在线购物结帐系统中,一定要测量每分钟的交易次数、失败率等。如果这些指标中的任何一个超出基线,您可能会决定回滚金丝雀。再例如,可以检测服务的数据库连接状态,初始化状态等指标,一旦指标超出基线则表示服务异常,这时候需要回滚。 平衡一组慢速与快速指标 一个有意义的金丝雀流程来说,单个指标是不够的。一些要监控的重要指标是立即生成的,而另一些则需要一些时间才能生成,因为它们依赖于负载,网络流量,高内存使用率或其他因素。在快速指标和慢速指标之间平衡您选择的指标非常重要。例如,服务器查询时间和延迟检查可以分别是慢度量和快度量的示例。因此选择一组平衡的指标,是对金丝雀的健康状况有全面的了解。 冒烟测试 从平衡组测试中,我们必须确保我们拥有直接表明金丝雀中存在问题的指标。所以冒烟测试很适合在这里使用,尽管我们的目标是找出金丝雀的健康状况,但使用此类指标找出金丝雀是否存在潜在问题也同样重要。例如,404 响应或其他意外的 HTTP 返回代码(200 秒、300 秒)可能意味着您的测试应立即停止并进行调试。CPU 使用率、内存占用、HTTP 响应码(200 秒、300 秒等)、响应延迟、正确性是一组很好的指标,但 HTTP 返回代码和响应延迟表明影响用户和服务的实际问题。 metrics 标准范围 这些公制选择需要有一个可接受的发挥范围,通过商定的可接受的指标行为,这样将能够消除那些被错误评估为好金丝雀的坏金丝雀。 金丝雀判断 执行金丝雀分析的最后一步是评估指标的值。通过这个步骤,将能够评估金丝雀实例是否应该升级到生产环境。 在提出每个假设之前,我们将定义两个假设,并根据我们的数据证明其中一个假设是错误的。 Unacceptable:回滚 Acceptable:部署到生产 Kayenta 比较两个时间序列,并在偏差超过某个阈值时发出警报。作为这些应用程序指标的来源,我们使用 New Relic Insights。对于这个后端,我们还将代码作为开源代码贡献给Kayenta ³。还可以支持其他后端(Datadog、Prometheus 等)。有关自动金丝雀分析的一般信息,请参阅Google和Netflix的优秀文章。 Reference [1] Install Halyard on Docker [2] ERROR Could not load “versions.yml” from config bucket: 403 #3920...

 ·  · 

初识Argo cd - 注册/删除k8s集群

登录argo cd bash 1 argocd login argocd_server:argocd_port_here 执行后输入admin/sercert bash 1 2 3 4 5 6 $ argocd login 10.0.0.5:30908 WARNING: server certificate had error: x509: cannot validate certificate for 10.0.0.5 because it doesn't contain any IP SANs. Proceed insecurely (y/n)? y Username: admin Password: 'admin:login' logged in successfully Context '10.0.0.5:30908' updated argocd cli 登录后的文件保存在 ~/.argocd/config 中 注册一个新集群 argocd 通过 kubectl 来获取集群的信息,所以 argocd 的主机上必须有 kubeconfig 文件 Note: KUBECONFIG 文件地址必须为实际路径,比如 ~/ 这种方式不可以...

 ·  · 

深入Argo - Application resources

在安装和注册集群完成后,就需要引入第一个概念 “Application”(如何管理所有我的应用程序?) 什么是 Application 什么是 ArgoCD “Application”? 对于 ArgoCD “Application”的快速解释:它是托管 ArgoCD 部署的 Kubernetes 集群 CRD 包含了应用程序的所有设置,如: 要部署到哪个集群? 与哪个 Git 存储库进行同步? 其他部署设置 应用程序的 YAML 包含了部署您的存储库资源所需的所有信息,充当了在 ArgoCD 中管理应用程序的关键控制点。 Reference [1] docs/operator-manual/argocd-cm.yaml [2] Getting started with multi-cluster K8S deployments using Argo CD [3] https://medium.com/notive/managing-argocd-application-resources-1b2b4742ab90

 ·  ·