云原生DevOps运维【免费下载链接】devtronThe only Kubernetes dashboard you need项目地址https://gitcode.com/gh_mirrors/dev/devtron点击查看免费下载本文是 Devtron 平台Notifications通知集成的完整使用与原理指南。通过该集成你可以在构建CI与部署CD流水线的触发、成功、失败三个事件节点将告警实时推送到指定的 Slack 频道或邮箱支持 AWS SES 与 SMTP 两种邮件通道从而第一时间获知流水线状态并采取行动。读完本文你将掌握 Notifications 集成的安装流程、四种通知渠道的配置参数、事件与过滤规则的选择方式以及该功能在仓库中的底层实现与验证证据。功能概览Notifications 集成围绕 CI/CD 流水线提供以下告警能力与官方文档描述一致为指定的构建流水线CI接收触发、成功、失败三类事件的告警为指定的部署流水线CD接收触发、成功、失败三类事件的告警通过 Webhook 将告警推送到指定的 Slack 频道将告警发送到指定邮箱邮件通道支持SESAmazon Simple Email Service与SMTP两种配置。从源码看告警事件类型与流水线类型在 util/event/Event.go 中被明确定义const Trigger EventType 1 const Success EventType 2 const Fail EventType 3 const CI PipelineType CI const CD PipelineType CD const ( Slack Channel slack SES Channel ses SMTP Channel smtp Webhook Channel webhook )即事件类型为 Trigger触发、Success成功、Fail失败三种流水线类型为 CI / CD 两种通知渠道共四种slack、ses、smtp、webhook。这四种渠道在 pkg/notifier 目录下各有独立的服务实现文件对应关系如下通知渠道服务实现文件用途SlackSlackNotificationService.go通过 Slack Incoming Webhook 推送频道消息SESSESNotificationService.go通过 AWS SES 发送邮件SMTPSMTPNotificationService.go通过自建/第三方 SMTP 服务器发送邮件WebhookWebhookNotificationService.go向任意 HTTP 端点发送自定义 Webhook 请求前置条件安装 Build and Deploy (CI/CD) 集成使用 Notifications 前必须先在 Devtron 中安装Build and Deploy (CI/CD)集成。因为告警面向的对象是构建与部署流水线没有 CI/CD 集成就没有可供订阅告警的流水线实体。安装方式见 Build and Deploy (CI/CD) 集成文档其本身提供 Kubernetes 上的自动化构建、多种部署策略Blue/Green、Rolling、Canary、Recreate、GitOps 与 ArgoCD 持续部署等能力是通知告警的数据来源。安装步骤打开Devtron Stack Manager Discover页面点击Notifications在Discover Integrations/Notifications页面点击Install按钮开始安装。安装过程中集成状态会经历若干阶段每个状态的含义如下表所示完整继承官方文档安装状态说明Install集成尚未安装Initializing安装正在初始化Installing安装进行中可通过日志跟踪进度Failed安装失败可查看日志排查问题并可重试安装或联系技术支持Installed集成安装成功此时会出现在Installed页面中Request timed out安装请求达到最大重试次数后超时可重试安装或联系技术支持所有已安装的集成可在Devtron Stack Manager Installed页面统一查看。如果平台有新版本已安装的集成会随 Devtron 升级而更新具体请参考 升级 Devtron UI 指南。通知渠道配置四种通道的参数详解安装完成后需要在“全局配置”中为各渠道创建通知配置即“接收端”的定义。每种渠道的配置字段对应仓库 pkg/notifier/beans/beans.go 中的 DTO 结构下面逐一说明。Slack 渠道配置Slack 渠道通过 Webhook URL 推送消息。对应结构SlackConfigDto字段含义必填webhookUrlSlack 应用的 Incoming Webhook 地址形如https://hooks.slack.com/...是configName配置名称用于在 UI 中标识该接收端是teamId所属团队 ID是description配置描述否userId创建者用户 ID是从 SlackNotificationService.go 的实现可以看到Slack 配置支持新增与编辑通过SaveOrEditNotificationConfig保存时若传入的id不为 0 则走更新逻辑UpdateSlackConfig否则走新增逻辑SaveSlackConfig删除时若该配置仍被某些通知规则引用服务会拒绝删除并返回 “Please delete all notifications using this config before deleting” 的提示避免产生悬挂引用。SES 渠道配置邮件SES 渠道使用 AWS 凭证发送邮件。对应结构SESConfigDto字段含义必填regionAWS SES 服务区域是accessKeyAWS Access Key是secretKeyAWS Secret Key是fromEmail发件人邮箱是须为合法邮箱格式toEmail收件人邮箱否sessionTokenAWS 临时会话 Token使用临时凭证时填写否configName配置名称是description配置描述否default是否为默认配置否SES 配置支持设置一个默认配置当把某个配置标记为默认时服务会先将其他配置的默认标记清除UpdateSESConfigDefault若尝试把已有的默认配置改为非默认服务会直接报错cannot update default config to non default。当系统需要自动选择发件配置时会回退到该默认配置。SMTP 渠道配置邮件SMTP 渠道面向自建或第三方邮件服务器。对应结构SMTPConfigDto字段含义hostSMTP 服务器地址portSMTP 服务器端口authType认证方式authUser认证用户名authPassword认证密码fromEmail发件人邮箱configName配置名称description配置描述default是否为默认配置deleted是否已删除标记SMTP 与 SES 的默认配置逻辑一致见 SMTPNotificationService.go同样禁止将默认配置直接改为非默认。Webhook 渠道配置Webhook 渠道可以将告警以自定义 HTTP 请求的形式发送到任意端点。对应结构WebhookConfigDto字段含义必填webhookUrl目标 HTTP 端点地址以https://开头是configName配置名称是header请求头map[string]interface{}类型例如{Content-type: application/json}否payload请求体模板支持变量占位符见下文否description配置描述否WebhookNotificationService_test.go 中的测试用例Test_buildWebhookNewConfigs验证了 Webhook 配置的构造逻辑例如WebhookUrl: dfcd nmc dc、Payload: {\text\: \final\}、Header: {Content-type: application/json}会被原样转换为底层WebhookConfig模型说明header与payload由用户完全自定义、不做改写。Webhook 支持的变量占位符在配置 Webhook 的payload时可以引用以下模板变量定义于 beans.go由 WebhookNotificationService.go 的GetWebhookVariables对外提供变量含义{{devtronContainerImageTag}}容器镜像 Tag{{devtronContainerImageRepo}}容器镜像仓库地址{{devtronAppName}}应用名称{{devtronAppId}}应用 ID{{devtronEnvName}}环境名称{{devtronEnvId}}环境 ID{{devtronCiPipelineId}}CI 流水线 ID{{devtronCdPipelineId}}CD 流水线 ID{{devtronTriggeredByEmail}}触发者的邮箱{{devtronBuildGitCommitHash}}构建所用的 Git Commit Hash{{devtronPipelineType}}流水线类型CI / CD{{eventType}}事件类型Trigger / Success / Fail这些变量会在告警发送时被替换为实际值例如一个最简单的 Slack 兼容 payload 可配置为{text: {{devtronAppName}} 构建 {{eventType}}镜像: {{devtronContainerImageRepo}}:{{devtronContainerImageTag}}}创建通知规则事件、范围与接收端的组合渠道配置只是“发往哪里”通知规则Notification Setting则定义“什么事件、哪些流水线、发给谁”。从 NotificationConfigService.go 与 NotificationConfigBuilder.go 的实现看一条通知规则包含三类要素事件类型EventTypeIds从 Trigger、Success、Fail 中勾选对应util/event/Event.go中的 1、2、3过滤范围可基于团队teamId、应用appId、环境envId、集群clusterId或流水线pipelineId精确圈定告警范围CI 与 CD 通过pipelineType区分接收端providers选择上面配置好的 Slack / SES / SMTP / Webhook 接收端可同时选择多个。多选过滤条件的笛卡尔积展开当同时勾选多个团队、多个应用、多个环境时规则会按笛卡尔积展开为多条具体设置。以 NotificationBuilder_test.go 中的注释为例teams: [1,2] apps: [3,4] envs: [5,6,7]会生成(1,3,5), (1,3,6), (1,3,7), (1,4,5) ... (2,4,7)全部组合每条组合再与勾选的每个事件类型、每个接收端相乘生成最终的NotificationSettings记录。代码中通过GenerateSettingCombinations的递归展开实现对应 beans.go这样无论选择多少个维度团队/应用/环境/集群都能以统一逻辑生成全组合无需为每种组合写嵌套循环。该行为有 NotificationBuilder_test.go 中的TestGenerateSettings用例做等价性验证它随机组合空/非空的选择器集合断言新旧两种组合生成算法的结果完全一致。另外beans 中还定义了两个特殊的环境分组常量All non-prod environments所有非生产环境与All prod environments所有生产环境在 UI 中选择环境范围时可直接选用。通知规则的增删改查通知规则的维护通过以下 REST API 完成路由定义见 NotificationRouter.go统一挂在/orchestrator/notification前缀下见 router.go方法与路径功能POST /orchestrator/notification创建通知规则兼容旧 CLI 调用/v2为同一处理器的显式路径PUT /orchestrator/notification更新通知规则支持仅更新事件events或仅更新接收端recipientsGET /orchestrator/notification?sizeoffset分页查询通知规则列表DELETE /orchestrator/notification删除通知规则POST /orchestrator/notification/channel保存/编辑各渠道的接收端配置GET /orchestrator/notification/channel查询全部接收端配置GET /orchestrator/notification/channel/ses/{id}等按 ID 查询某渠道配置GET /orchestrator/notification/variables获取 Webhook 可用变量列表GET /orchestrator/notification/recipient?value接收端联想搜索按名称/邮箱模糊匹配GET /orchestrator/notification/channel/autocomplete/{type}某类型渠道的自动补全列表POST /orchestrator/notification/search获取通知设置页的可选过滤项团队/应用/环境/集群/流水线其中“更新”操作通过UpdateType区分更新维度events只更新事件类型recipients只更新接收端定义见 util/event/Event.go。接收端联想搜索会同时匹配 Slack 配置名、Webhook 配置名、用户邮箱以及既有规则中使用的 recipient见 SlackNotificationService.go 的RecipientListingSuggestion并依据地址前缀自动判断其属于 slack / webhook / ses 哪种渠道。底层实现与测试保障该模块的代码结构清晰pkg/notifier下按渠道拆分了四个服务加上统一的 NotificationConfigService.go规则编排与 NotificationConfigBuilder.go规则构建通过adapter/目录完成 DTO 与数据库模型之间的转换API 层由 NotificationRestHandler.go 处理请求并做参数校验。配套测试包括 NotificationBuilder_test.go规则组合生成与 WebhookNotificationService_test.goWebhook 配置保存与构造可据此确认各核心逻辑的行为预期。总结Devtron 的 Notifications 集成把 CI/CD 流水线的生命周期事件与多种消息渠道连接起来形成一条“事件 → 过滤 → 路由 → 送达”的完整告警链路先安装Build and Deploy (CI/CD)集成再在 Stack Manager 中安装Notifications在全局配置中按需创建 Slack、SES、SMTP、Webhook 接收端Webhook 可自定义 header 与带变量占位符的 payload创建通知规则选择 CI/CD 流水线类型、Trigger/Success/Fail 事件、团队/应用/环境/集群/流水线过滤范围与接收端规则按笛卡尔积自动展开流水线状态变化时即向所选接收端推送告警。按上述步骤你即可在数分钟内为团队的构建与部署流水线建立起可告警、可追踪的通知体系。赞分享云原生DevOps运维【免费下载链接】devtronThe only Kubernetes dashboard you need项目地址https://gitcode.com/gh_mirrors/dev/devtron点击查看免费下载相关推荐Argo CD Webhook集成CI/CD流水线的自动化触发Argo CD Webhook集成CI/CD流水线的自动化触发 概述 在现代云原生应用部署中实现快速、自动化的持续交付是每个开发团队的核心需求。Argo C云原生CI/CD容器编排DevOps后端如何构建SymPy的持续集成流水线从测试到发布的完整指南如何构建SymPy的持续集成流水线从测试到发布的完整指南 SymPy作为一个用纯Python编写的计算机代数系统其持续集成CI/CD流水线是保障代码质量科学计算符号运算MetaGPT持续集成CI/CD流水线配置MetaGPT持续集成CI/CD流水线配置 你是否在为MetaGPT项目的自动化测试、构建和部署而烦恼本文将详细介绍如何为MetaGPT配置完整的CI/CD上一篇AI-Infra-Guard aig-agent-redteam Mutation-Attack 模块深度实战统一变异引擎与 L1/L2 双层攻击面测试指南下一篇MiniMax H3 在摩尔线程 MUSA 平台上的视频与音频联合生成部署指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考