Argo Events Documentation

repository·master·Indexed 25 days ago

https://github.com/argoproj/argo-events

An event-driven workflow automation framework for Kubernetes that triggers actions—such as creating Kubernetes objects, invoking Argo Workflows, or starting serverless workloads—based on events from sources including webhooks, S3, AMQP, Azure Event Hubs, and message queues like Kafka, GCP PubSub, SNS, and SQS.

Tokens
102.6K
Snippets
202
Records
526
Agent score
80%

What's inside Argo Events

  1. Overview of Argo Events

    master
    Argo Events is an event-driven workflow automation framework for Kubernetes. It enables you to trigger various actions (such as creating Kubernetes objects, invoking workflows, or starting serverless workloads) based on events from diverse sources (such as webhooks, S3 drops, cron schedules, or messaging queues like Kafka, GCP PubSub, SNS, and SQS).
  2. Configure an EventSource to consume external events

    master

    An EventSource is a resource used to consume events from external providers (such as AWS SNS, SQS, GCP PubSub, Webhooks, etc.). The EventSource performs two primary functions:

    1. Consumes events from the external source.
    2. Transforms these events into the cloudevents format.
    3. Dispatches the transformed events to an EventBus.

    Supported event sources include:

    • Cloud Providers: AWS SNS, AWS SQS, Azure Events Hub, Azure Queue Storage, GCP PubSub.
    • Messaging/Streaming: AMQP, Kafka, NATS, NSQ, Pulsar, Redis, MQTT.
    • Web/SaaS: Bitbucket, Bitbucket Server, GitHub, GitLab, Slack, Stripe, Webhooks.
    • Storage/Files: HDFS, Minio, NetApp StorageGrid, File Based Events.
    • Other: Calendar, K8s Resources, Emitter, Generic EventSource.
  3. Understand the EventBus role in Argo Events

    master

    The EventBus serves as the transport layer in the Argo Events architecture. It facilitates communication by connecting EventSources to Sensors:

    1. EventSources publish events to the EventBus.
    2. Sensors subscribe to the EventBus to detect these events and execute triggers.

    When configuring your workflow, you must choose an EventBus implementation to act as the intermediary.

  4. Understand the Argo Events architecture components

    master

    Argo Events operates using four main architectural components that work together to enable event-driven workflows:

    1. Event Source: Listens for events from external sources (e.g., Webhooks, S3, Kafka, etc.) and produces them into the system.
    2. Eventbus: Acts as the communication backbone, providing a mechanism to transport events from Event Sources to Sensors.
    3. Sensor: Watches for specific events on an Eventbus and, when a match is found, executes a defined action.
    4. Trigger: Defines the specific action to be taken by a Sensor (e.g., starting an Argo Workflow, calling a Kubernetes Job, or sending an HTTP request).
  5. Understand the Sensor concept in Argo Events

    master

    A Sensor is the component in Argo Events responsible for managing the relationship between incoming events and outgoing actions. It functions by defining two main components:

    1. Event Dependencies (Inputs): The specific events the sensor listens for on an eventbus.
    2. Triggers (Outputs): The actions or workflows that are executed once the event dependencies are satisfied.

    Essentially, a Sensor acts as an event dependency manager that resolves incoming events and executes the configured triggers.

  6. Understand Argo Events Filters

    master

    Filters allow you to apply constraints to incoming events to determine their validity.

    • If a filter determines an event is valid, the action defined by the Sensor is triggered.
    • If a filter determines an event is not valid, no action is taken.

    Argo Events evaluates filter types in the following specific order:

    1. Expr Filter
    2. Data Filter
    3. Context Filter
    4. Time Filter
  7. Understand the Generic EventSource lifecycle and connection behavior

    master

    The Generic EventSource follows this operational flow:

    1. Connection: The Argo Events client connects to your server's url and sends the config via an RPC call.
    2. Initialization: Your server parses the configuration and establishes connections to any necessary external event providers.
    3. Streaming: Your server streams Event messages back to the Argo Events client.
    4. Dispatch: The client writes these events to the eventbus for Sensors to consume.

    Resiliency: The client performs indefinite retries to connect to the server. If your server goes down, the client will continuously attempt to reconnect and resume receiving the event stream once the server is available again.

  8. Quickstart: Trigger an Argo Workflow via Webhook

    master

    This guide demonstrates how to set up a complete event-driven pipeline: an EventBus, a Webhook EventSource, and a Sensor that triggers an Argo Workflow upon receiving an HTTP POST request.

    1. Deploy Argo Events components

    Apply the following manifests to set up the infrastructure:

    # Set up the eventbus
    kubectl -n argo-events apply -f https://raw.githubusercontent.com/argoproj/argo-events/stable/examples/eventbus/native.yaml
    
    # Create the webhook event source
    kubectl -n argo-events apply -f https://raw.githubusercontent.com/argoproj/argo-events/stable/examples/event-sources/webhook.yaml
    
    # Create the webhook sensor
    kubectl -n argo-events apply -f https://raw.githubusercontent.com/argoproj/argo-events/stable/examples/sensors/webhook.yaml

    2. Expose the EventSource

    To send requests to the event-source pod, use port-forwarding (or configure an Ingress/OpenShift Route):

    kubectl -n argo-events port-forward <event-source-pod-name> 12000:12000

    3. Trigger the Workflow

    Send an HTTP POST request using curl or Postman:

    curl -d '{"message":"this is my first webhook"}' -H "Content-Type: application/json" -X POST http://localhost:12000/example

    4. Verify the Result

    Check that a workflow was created and inspect its logs:

    # Check for the workflow
    kubectl -n argo-events get wf
    
    # Check the workflow logs
    argo logs -n argo-events @latest

    Note: The workflow logs will contain the event context and the event data. The data field is base64 encoded.

  9. Set up NSQ for Argo Events

    master

    To use NSQ as an event source, you must deploy the NSQ components (nsqlookupd, nsqd, and nsqadmin) to your Kubernetes cluster. The following manifest provides the necessary Services and Workloads (StatefulSet/Deployments) to run NSQ locally.

    Note: The nsqd configuration in this example assumes it is communicating with nsqlookupd.argo-events.svc:4160 and broadcasting via nsqd.argo-events.svc.

    apiVersion: v1
    kind: Service
    metadata:
      name: nsqlookupd
      labels:
        app: nsq
    spec:
      ports:
        - port: 4160
          targetPort: 4160
          name: tcp
        - port: 4161
          targetPort: 4161
          name: http
      clusterIP: None
      selector:
        app: nsq
        component: nsqlookupd
    ---
    apiVersion: v1
    kind: Service
    metadata:
      name: nsqd
      labels:
        app: nsq
    spec:
      ports:
        - port: 4150
          targetPort: 4150
          name: tcp
        - port: 4151
          targetPort: 4151
          name: http
      clusterIP: None
      selector:
        app: nsq
        component: nsqd
    ---
    apiVersion: v1
    kind: Service
    metadata:
      name: nsqadmin
      labels:
        app: nsq
    spec:
      ports:
        - port: 4170
          targetPort: 4170
          name: tcp
        - port: 4171
          targetPort: 4171
          name: http
      selector:
        app: nsq
        component: nsqadmin
    ---
    apiVersion: apps/v1beta1
    kind: StatefulSet
    metadata:
      name: nsqlookupd
    spec:
      serviceName: "nsqlookupd"
      replicas: 1
      updateStrategy:
        type: RollingUpdate
      template:
        metadata:
          labels:
            app: nsq
            component: nsqlookupd
        spec:
          containers:
            - name: nsqlookupd
              image: nsqio/nsq:v1.1.0
              imagePullPolicy: Always
              resources:
                requests:
                  cpu: 30m
                  memory: 64Mi
              ports:
                - containerPort: 4160
                  name: tcp
                - containerPort: 4161
                  name: http
              livenessProbe:
                httpGet:
                  path: /ping
                  port: http
                initialDelaySeconds: 5
              readinessProbe:
                httpGet:
                  path: /ping
                  port: http
                initialDelaySeconds: 2
              command:
                - /nsqlookupd
          terminationGracePeriodSeconds: 5
    ---
    apiVersion: apps/v1beta1
    kind: Deployment
    metadata:
      name: nsqd
    spec:
      replicas: 1
      selector:
        matchLabels:
          app: nsq
          component: nsqd
      template:
        metadata:
          labels:
            app: nsq
            component: nsqd
        spec:
          containers:
            - name: nsqd
              image: nsqio/nsq:v1.1.0
              imagePullPolicy: Always
              resources:
                requests:
                  cpu: 30m
                  memory: 64Mi
              ports:
                - containerPort: 4150
                  name: tcp
                - containerPort: 4151
                  name: http
              livenessProbe:
                httpGet:
                  path: /ping
                  port: http
                initialDelaySeconds: 5
              readinessProbe:
                httpGet:
                  path: /ping
                  port: http
                initialDelaySeconds: 2
              volumeMounts:
                - name: datadir
                  mountPath: /data
              command:
                - /nsqd
                - -data-path
                - /data
                - -lookupd-tcp-address
                - nsqlookupd.argo-events.svc:4160
                - -broadcast-address
                - nsqd.argo-events.svc
              env:
                - name: HOSTNAME
                  valueFrom:
                    fieldRef:
                      fieldPath: metadata.name
          terminationGracePeriodSeconds: 5
          volumes:
            - name: datadir
              emptyDir: {}
    ---
    apiVersion: extensions/v1beta1
    kind: Deployment
    metadata:
      name: nsqadmin
    spec:
      replicas: 1
      template:
        metadata:
          labels:
            app: nsq
            component: nsqadmin
        spec:
          containers:
            - name: nsqadmin
              image: nsqio/nsq:v1.1.0
              imagePullPolicy: Always
              resources:
                requests:
                  cpu: 30m
                  memory: 64Mi
              ports:
                - containerPort: 4170
                  name: tcp
                - containerPort: 4171
                  name: http
              livenessProbe:
                httpGet:
                  path: /ping
                  port: http
                initialDelaySeconds: 10
              readinessProbe:
                httpGet:
                  path: /ping
                  port: http
                initialDelaySeconds: 5
              command:
                - /nsqadmin
                - -lookupd-http-address
                - nsqlookupd.argo-events.svc:4161
          terminationGracePeriodSeconds: 5