How does keptn service provide integration with event API?

[afzal442]

Keptn service implementation running outside the Keptn control plane

I understood here outside as Keptn service runs in a remote "execution plane after creating the service.

events are fetched from Keptn's public event API

Does this mean events described inside the shipyard file like dev.delivery.finished within the sequence which gets subscribed to cloudevent or defined in the keptn event API like "sh.keptn.event.dev.delivery.triggered" are fetched?

[afzal442]

Hi @agardnerIT, I tried to map it with keptn docs, let me know if I misunderstood here. Thanks

[afzal442]

Thanks much Adam. You answered it in a well informed way, even better to capture things around the keptn operator.

So again, do you mean things you described in the answer as below?

running on a different cluster

Execution plane where heavy workloads are run like jmeter service etc.

Services can connect to keptn core ...

keptn create service SERVICENAME --project=PROJECTNAME
How does this work? Sorry!
Here Ig, Services subscribe to the task events.

you want the job executor service to react to the deployment task

Why not distributor service here?
Is that because A distributor subscribes a Keptn service with Keptn event API service?

[agardnerIT]

running on a different cluster simple services (yes like jmeter service) running on a different cluster to the one that the core components (eg. shipyard controller) is running on. To illustrate, imagine you want to do global deployments via a single keptn deploy command. You have a central keptn control plane. You have multiple clusters located around the world. You've written your own deployment service that listens for the deployment.triggered event and only reacts when the region matches for that cluster. In this way, you can ask keptn to do a deployment and pass:

{
  "type": "sh.keptn.event.dev.deployment.triggered",
  "deployment": {
    "region": "FR"
  }
}

All clusters will receive the deployment.triggered event but you have coded your service to only actually respond if the region matches - so your workload is deployed in France.

Keptn Create Service

Almost everything that happens in keptn is ultimately backed by a cloudevent so that CLI command uploads the provided JSON shipyard to Git and formulates a cloudevent like this. The code for the CLI command is here.

Why not distributor service here?

The distributors job is to listen for connections from Keptn core (either via NATS or HTTPS) and when "heard" those events start the actual workload container. Every keptn service is deployed as a pod with two containers: a distributor and the "actual" workload. So to answer your question, the distributor doesn't do any real work, it is just a prewritten way to interact with Keptn core so that service authors don't have to re-code the boilerplate plumbing logic every time. Indeed if this (currently draft) PR works, we may move away from using a distributor sidecar altogether.

Zooming into the diagram above, the "Your Deployment Service" pod actually looks like this:

[agardnerIT]

Hi Afzal, I think you're correct but I'll rephrase to make sure I understand the question fully. I know you know some of this stuff already so sorry for going over old ground :)

Keptn core is a bunch of microservices. Then you add other services (like the job executor service). If the other services are running on the same cluster as the core microservices, the service is said to be running inside the control plane. In this example, if the job executor service is running on a different cluster then it is running remotely or outside the control plane.

Services can connect to keptn core in (currently) one of two ways:

• Using NATS
• Using HTTPS (via the API)

If your service is running locally, it will use NATS. If your service is running remotely, it will use HTTPS.

Given a shipyard (partial example) like this:

stages:
    - name: "dev"
      sequences:
        - name: "delivery"
          tasks:
            - name: "deployment"

In order to trigger the delivery sequence in dev from an external tool, we would craft a JSON payload cloudevent with a type set as follows and send in via the /api/v1/event Keptn API endpoint.

"type": "sh.keptn.event.dev.delivery.triggered"

When you run keptn trigger delivery, in effect the CLI generates that cloudevent payload for you and sends it to the API endpoint as above. Whether you use the CLI or directly trigger the API, the result is the same.

Services subscribe to the task events. So in the example above, you want the job executor service to react to the deployment task. So the job executor service listens for:

"type": "sh.keptn.event.deployment.triggered"

Note the lack of stage in the event type, because the important metadata is actually held inside the cloudevent body so we don't need to duplicate in the type.

To reiterate, if the JES is running locally, this "listening" would occur via NATS pubsub and if installed remotely, would be via API. In both cases, the distributor sidecar would handle this listening complexity for you.

Hope that helps!