Cloud Events - .NET Core

    1. The default mode has the app reply to your input events with the output event, which is simplest for demonstrating things working in isolation, but is also the model for working for the Knative Eventing concept.

    2. K_SINK mode has the app send events to the destination encoded in $K_SINK, which is useful to demonstrate how folks can synthesize events to send to a Service or Broker when not initiated by a Broker invocation (e.g. implementing an event source)

    Do the following the steps to create the sample code and then deploy the app to your cluster. You can also download a working copy of the sample, by running the following commands:

    • A Kubernetes cluster with Knative installed and DNS configured. Follow the installation instructions if you need to create one.
    • installed and running on your local machine, and a Docker Hub account configured (we’ll use it for a container registry).
    1. If you look in controllers\CloudEventsController.cs, you will see two key functions for the different modes of operation:
    1.   // This is called whenever an event is received if $K_SINK is set, and sends a new event
    2.   // to the url in $K_SINK.
    3. }
    6.   // This is called whenever an event is received if $K_SINK is NOT set, and it replies with
    7.   // the new event instead.
    8. }
    1. If you look in Dockerfile, you will see a method for pulling in the dependencies and building an ASP.NET container based on Alpine. You can build and push this to your registry of choice via:
    1. kubectl apply -f service.yaml

    Get the URL for your Service with:

    1. $ curl -X POST \
    3.     -H "ce-specversion: 1.0"  \
    4.     -H "ce-source: curl-command"  \
    5.     -H "ce-type: curl.demo"  \
    6.     -H "ce-id: 123-abc"  \
    7.     -d '{"name":"Dave"}' \
    8.     <service-URL>

    Where <service-URL> is the URL from the kubectl get ksvc command.

    You will get back: