Introducing the CloudEvents Player

In this tutorial, you use the CloudEvents Player to showcase the core concepts of Knative Eventing. By the end of this tutorial, you should have an architecture that looks like this:

The CloudEvents Player acts as both a Source and a Sink for CloudEvents

The above image is Figure 6.6 from Knative in Action.

Creating your first Source

The CloudEvents Player acts as a Source for CloudEvents by intaking the URL of the Broker as an environment variable, BROKER_URL. You will send CloudEvents to the Broker through the CloudEvents Player application.

Create the CloudEvents Player Service:

kn

  1. kn service create cloudevents-player \
  2. --image ruromero/cloudevents-player:latest \
  3. --env BROKER_URL=http://broker-ingress.knative-eventing.svc.cluster.local/default/example-broker

Expected Output

  1. Service 'cloudevents-player' created to latest revision 'cloudevents-player-vwybw-1' is available at URL:
  2. http://cloudevents-player.default.127.0.0.1.sslip.io

Why is my Revision named something different!

Because we didn’t assign a revision-name, Knative Serving automatically created one for us. It’s okay if your Revision is named something different.

YAML

  1. apiVersion: serving.knative.dev/v1
  2. kind: Service
  3. metadata:
  4.   name: cloudevents-player
  5. spec:
  6.   template:
  7.     metadata:
  8.       annotations:
  9.         autoscaling.knative.dev/min-scale: "1"
  10.     spec:
  11.       containers:
  12.         - image: ruromero/cloudevents-player:latest
  13.           env:
  14.             - name: BROKER_URL
  15.               value: http://broker-ingress.knative-eventing.svc.cluster.local/default/example-broker

Once you’ve created your YAML file, named something like cloudevents-player.yaml, apply it by running the command:

  1. kubectl apply -f cloudevents-player.yaml

Expected Output

  1. service.serving.knative.dev/cloudevents-player created

Examining the CloudEvents Player

You can use the CloudEvents Player to send and receive CloudEvents. If you open the Service URL in your browser, the Create Event form appears:

The user interface for the CloudEvents Player

What do these fields mean?

FieldDescription
Event IDA unique ID. Click the loop icon to generate a new one.
Event TypeAn event type.
Event SourceAn event source.
SpecversionDemarcates which CloudEvents spec you’re using (should always be 1.0).
MessageThe data section of the CloudEvent, a payload which is carrying the data you care to be delivered.

For more information on the CloudEvents Specification, check out the CloudEvents Spec.

  1. Fill in the form with whatever you data you want.
  2. Ensure your Event Source does not contain any spaces.
  3. Click SEND EVENT.

CloudEvents Player Send

Clicking the Introducing the CloudEvents Player - 图4 shows you the CloudEvent as the Broker sees it.

![Event_Details](images/event_details.

Want to send events via the command line instead?

As an alternative to the Web form, events can also be sent/viewed via the command line.

To post an event:

  1. curl -i http://cloudevents-player.default.127.0.0.1.sslip.io \
  2.     -H "Content-Type: application/json" \
  3.     -H "Ce-Id: 123456789" \
  4.     -H "Ce-Specversion: 1.0" \
  5.     -H "Ce-Type: some-type" \
  6.     -H "Ce-Source: command-line" \
  7.     -d '{"msg":"Hello CloudEvents!"}'

And to view events:

  1. curl http://cloudevents-player.default.127.0.0.1.sslip.io/messages

The Introducing the CloudEvents Player - 图5 icon in the “Status” column implies that the event has been sent to our Broker… but where has the event gone? Well, right now, nowhere!

A Broker is simply a receptacle for events. In order for your events to be sent anywhere, you must create a Trigger which listens for your events and places them somewhere. And, you’re in luck: you’ll create your first Trigger on the next page!