版本:v1.3
管理应用工作流
本文详细介绍应用工作流的功能和使用场景,带你更全面的了解工作流。
在 交付 Kubernetes 原生资源 一文中,我们初识了工作流的一个重要使用场景,即人工介入多集群发布的过程,实现可控多集群发布。在本文中我们继续介绍以下话题:
- 进一步了解 Workflow 、Revision 和 Env 的关系,以及目前内置的 Workflow 步骤。
- 在工作流中实现通知。
- 在工作流中进行数据初始化。
本文介绍内容相对深入,在此之前,建议先参考 交付第一个应用, 交付容器镜像 等文章了解其他基础知识和流程。
应用进行部署的动作则为执行某一个工作流发布一个版本,版本状态跟随工作流的执行状态,也就是说工作流执行完成,则代表该版本处于完成发布的状态。工作流与应用发布的环境绑定,即应用的每一个环境都有独立的工作流。
对接 CI 系统后,版本可以与 Code Commit 关联,实现版本可追溯。在版本操作中后续会实现版本回退功能,你可在任何时候选择将某个环境回退到指定版本。
在 交付 Kubernetes 原生资源 文章中,我们使用了人工审核步骤 suspend
。我们再来了解一下其他内置的步骤分别是什么作用:
deploy2env
: 应用交付到指定 Target。该步骤 Vela 会根据环境中配置的 Target 自动生成。deploy-cloud-resource
: 云资源应用交付到指定 Target。该步骤 Vela 会为云资源应用,根据环境中配置的 Target 自动生成,需要注意的是,该类型步骤与 deploy2env 的区别在于控制云资源创建的 CR 资源是部署到管控集群的,服务创建完成生成访问密钥(Secret)后,将 Secret 分发到 Target 指定集群和 Namespace。share-cloud-resource
: 分发云服务生成的 Secret 到指定 Target,使用该步骤实现云服务多集群共享,即在多集群应用中只创建一个云服务,将其访问密钥分发到多个集群,实现服务共享。notification
: 通知,支持钉钉、邮件、Slack 三种通知模式,你可将其置于工作流的任何阶段实现消息通知。webhook
: Web 钩子,你可将其置于工作流任何阶段,实现对外部系统的调用。
使用 notification
步骤可实现钉钉、邮件和 Slack 三种通知模式。进入应用工作流管理页面,选择一个环境的工作流点击 Edit
按钮进入编辑状态。
选择左侧的 notification
类型的步骤拖入右侧画布,页面将自动弹出工作流步骤编辑窗口,在设置窗口中,你可以根据需要设置三种通知,在同一步骤中,如果设置了多种通知,它同时生效。
如果设置 Dingding
通知,点击 Dingding
窗口右侧的启用按钮,页面将出现两个输入框,一个是钉钉群通知机器人的 Webhook 地址,参考 Dingding 群机器人参考文档 获取。另外一个是通知内容输入框,你可以自定义任何需要发送的通知内容。
Slack
与 Dingding
配置方式类似,参考 Slack 中获取 Webhook 地址。
Email
相对配置数据更多,需要配置邮件服务器、邮件内容和发送目标邮件地址等。
配置完成点击 Submit
保存步骤配置,这时需要规划通知步骤的位置,默认它将添加到最后,如果你希望将其放置到中间步骤,需要断开原有步骤直接的连线,然后将通知步骤进行连线放置在中间。
工作流配置完成后注意点击工作流窗口右上方的 Save 按钮保存所有变更。保存完成后可以点击页面右上方的 Deploy
或右边的选择按钮选择执行该工作流,验证是否可以收到消息通知。
Last updated on 2022年11月1日 by Tianxin Dong