Use a DingTalk chatbot to receive notifications about GitOps application updates - Container Service for Kubernetes

When you use GitOps to release an application, you can configure a notification service, such as emails or DingTalk, to receive notifications about application updates. For example, you can receive notifications when application release exceptions occur and troubleshoot the exceptions at the earliest opportunity. This topic describes how to receive DingTalk notifications in GitOps.

Background information

The Argo CD Notifications feature introduces the following terms for configuring application notifications:

Triggers: define conditions that trigger the system to send notifications.
Templates: define the content of notifications.
Subscriptions: allow you to subscribe to applications or triggers and receive notifications sent from one or more notification services.
Notification Services: such as emails, Slack, GitHub, and webhooks.

DingTalk receives messages through exposed HTTP webhooks. You can configure Triggers, Templates, Notification Services, and Subscriptions in the argocd/argocd-notifications-cm section of a ConfigMap to enable DingTalk to automatically receive notifications about application updates.

Prerequisites

The Fleet management feature is enabled. For more information, see Enable Fleet management.
The kubeconfig file of the Fleet instance is obtained in the ACK One console and a kubectl client is connected to the Fleet instance. For more information, see Obtain the kubeconfig file of a cluster and use kubectl to connect to the cluster.

Step 1: Create a DingTalk chatbot

After you create a DingTalk chatbot, an exclusive webhook is generated. The webhook can be associated with other services, such as Argo Workflows, to receive notifications.

Start DingTalk and go to the DingTalk group in which you want to receive notifications.
Go to the chatbot page and add a custom chatbot.
1. Click the icon in the upper-right corner of the DingTalk group. Then, click Bot in the panel that appears.
2. In the Robot Management panel, click Add Robot and click the Custom card. In the dialog box that appears, click Add.
3. Specify Chatbot name and configure Security Settings, and click Finished.
  You must select at least one security setting. We recommend that you select at least one of the following security settings: Additional Signature and IP Address.
  Important
  To configure a workflow to send DingTalk messages, make sure that the virtual private cloud (VPC) of the workflow cluster has Internet access. To do this, you can configure an Internet NAT gateway for the workflow cluster and specify the elastic IP address (EIP) of the gateway in the IP Address parameter of the chatbot.
After you complete the configuration, copy and record the webhook of the chatbot.

Step 2: Configure application notifications

Use kubectl to connect to your Fleet instance and run the following command to add settings to argocd/argocd-notifications-cm.

kubectl edit cm argocd-notifications-cm -nargocd

Sample configuration:

Note

Replace url in service.webhook.dingtalk with the webhook of the chatbot you recorded in Step 1: Create a DingTalk chatbot.
Replace argocdUrl in context with the domain name of Argo CD Server. For more information about how to obtain the domain name, see Introduction to the domain name of the GitOps Argo CD server.
If you want to customize each trigger, add a Templates object for each trigger.
To customize the color of the notification content, specify <font color=>xxxx</font>.

apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-notifications-cm
  namespace: argocd
data:
  service.webhook.dingtalk: |
    url: https://oapi.dingtalk.com/robot/send?access_token=535a56d**********
    headers:
      - name: Content-Type
        value: application/json
  context: |
    argocdUrl: https://argocd.<your-fleet-id>.<region>.alicontainer.com
  template.app-sync-change: |
    webhook:
      dingtalk:
        method: POST
        body: |
          {
                "msgtype": "markdown",
                "markdown": {
                    "title":"Argo CD application status",
                    "text": "### Argo CD application status\n> - Application name: {{.app.metadata.name}}\n> - Status: {{ .app.status.operationState.phase}}\n> - Time:{{.app.status.operationState.finishedAt}}\n> - Application URL: [Click to access]({{.context.argocdUrl}}/applications/{{.app.metadata.name}}?operation=true) \n"
                }
          }
  template.app-sync-status-unknown: |
    webhook:
      dingtalk:
        method: POST
        body: |
          {
                "msgtype": "markdown",
                "markdown": {
                    "title":"Unknown Argo CD application",
                    "text": "### Unknown Argo CD application\n> - <font color=\"warning\">Application name</font>: {{.app.metadata.name}}\n> - <font color=\"warning\">Application status</font>: {{.app.status.sync.status}}\n> - <font color=\"warning\">Application health status</font>: {{.app.status.health.status}}\n> - <font color=\"warning\">Time</font>: {{.app.status.operationState.startedAt}}\n> - <font color=\"warning\">Application URL</font>: [Click to access the Argo CD UI]({{.context.argocdUrl}}/applications/{{.app.metadata.name}}?operation=true)"
                }
          }
  template.app-sync-failed: |
    webhook:
      dingtalk:
        method: POST
        body: |
          {
                "msgtype": "markdown",
                "markdown": {
                    "title":"Argo CD application release failure",
                    "text": "### Argo CD application release failure\n> - <font color=\"danger\">Application name</font>: {{.app.metadata.name}}\n> - <font color=\"danger\">Application status</font>: {{.app.status.operationState.phase}}\n> - <font color=\"danger\">Application health status</font>: {{.app.status.health.status}}\n> - <font color=\"danger\">Time</font>: {{.app.status.operationState.startedAt}}\n> - <font color=\"danger\">Application URL</font>: [Click to access the Argo CD UI]({{.context.argocdUrl}}/applications/{{.app.metadata.name}}?operation=true)"
                }
          }
  trigger.on-deployed: |
    - description: Application is synced and healthy. Triggered once per commit.
      oncePer: app.status.sync.revision
      send: [app-sync-change]
      # trigger condition
      when: app.status.operationState.phase in ['Succeeded'] and app.status.health.status == 'Healthy'
  trigger.on-health-degraded: |
    - description: Application has degraded
      send: [app-sync-change]
      when: app.status.health.status == 'Degraded'
  trigger.on-sync-failed: |
    - description: Application syncing has failed
      send: [app-sync-failed]
      when: app.status.operationState != nil and app.status.operationState.phase in ['Error',
        'Failed']
  trigger.on-sync-status-unknown: |
    - description: Application status is 'Unknown'
      send: [app-sync-status-unknown]
      when: app.status.sync.status == 'Unknown'
  trigger.on-sync-running: |
    - description: Application is being synced
      send: [app-sync-change]
      when: app.status.operationState != nil and app.status.operationState.phase in ['Running']
  trigger.on-sync-succeeded: |
    - description: Application syncing has succeeded
      send: [app-sync-change]
      when: app.status.operationState != nil and app.status.operationState.phase in ['Succeeded']
  subscriptions: |
    - recipients: [dingtalk]
      triggers: [on-sync-failed, on-sync-succeeded, on-sync-status-unknown,on-deployed]