Integrate AWS Services Into Rancher Workloads With TriggerMesh
Here's how to trigger a workload on Rancher when events happen in your AWS service using Triggermesh.
Join the DZone community and get the full member experience.Join For Free
Many businesses use cloud services on AWS and also run workloads on Kubernetes and Knative. Presently, it is difficult to integrate events from AWS to workloads on a Rancher cluster, and this can prevent you from taking full advantage of your data and applications. To trigger a workload on Rancher when events happen in your AWS service, you need an event source that can consume AWS events and send them to your Rancher workload.
My company, TriggerMesh, provides a real-time cloud-native integration platform that allows you to connect services to automate workflows and accelerate the flow of information across your organization. One way we do this is with our open-source TriggerMesh Sources for Amazon Web Services (SAWS) - which are event sources for AWS services. You can get these on GitHub and, through our partnership with Rancher, they are also now available in the Rancher catalog. For Rancher customers, SAWS allows you to quickly and easily consume events from your AWS services and send them to your workloads running in your Rancher clusters.
SAWS currently provides event sources for the following Amazon Web Services:
In this post, we’ll walk through installing SAWS in your Rancher cluster and demonstrate how to consume Amazon SQS events in your Knative workload.
To get you started, we’ll walk you through the installation of SAWS in your Rancher cluster followed by a quick demonstration of consuming Amazon SQS events in your Knative workload.
TriggerMesh SAWS requires the Knative serving component. Follow the Knative documentation to install the Knative serving component in your Kubernetes cluster. Optionally, you may also install the Knative eventing component for the complete Knative experience. We used:
kubectl --namespace kong get service kong-proxy
We created a cluster from the GKE provider. A LoadBalancer service will be assigned an external IP, which is necessary so that the services are accessible over the internet.
With Knative serving installed, search for aws-event-sources from the Rancher applications catalog and install the latest available version from the helm3-library. You can install the chart at the Default namespace
Remember to update the Knative Domain and Knative URL Scheme parameters during the chart installation. For example, in our demo cluster, we used Magic DNS (xip.io) for configuring the DNS in the Knative serving installation step, so we specified 126.96.36.199.xip.io and HTTP as the values of Knative Domain and Knative URL Scheme respectively.
That's it! Your cluster is now fully equipped with all the components to consume events from your AWS services.
To demonstrate the functionality of the TriggerMesh SAWS package, we will set up an Amazon SQS queue and visualize the events occurring in the queue in a service running on our cluster. You’ll need to have access to the SQS service on AWS to be able to create the queue. The not specific role is required. However, make sure you have all the permissions on the queue (see details here).
Step 1: Create a SQS Queue
Log in to the Amazon management console and create a queue.
Step 2: Create AWS Credentials Secret
Create a secret named awscreds containing your AWS credentials:
Update the values of aws_access_key_id and aws_secret_access_key in the above command.
Step 3: Create the AWSSQSSource Resource
Create the AWSSQSSource resource that will bring the events that occur on the SQS queue to the cluster using the following snippet. Remember to update the arn field in the snippet with that of your queue.
Check the status of the resource using:
Step 4: Create a Sockeye Service
Sockeye is a WebSocket-based CloudEvents viewer. Our my-queue resource created above is set up to send the cloud events to a service named sockeye as configured in the sink section. Create the sockeye service using the following snippet:
Next, get the URL of the sockeye service and load it in the web browser.
Step 5: Send Messages to the Queue
We now have all the components set up. All we need to do now is to send messages to the SQS queue.
The cloud events should appear in the sockeye events viewer.
As you can see, using TriggerMesh Sources for AWS makes it easy to consume cloud events that occur in AWS services. Our example uses Sockeye for demonstration purposes: you can replace sockeye with any of your Kubernetes workloads that would benefit from consuming and processing events from these popular AWS services.
The TriggerMesh SAWS package supports several AWS services. Refer to the README for each component to learn more.
You can find sample configurations here.
To learn more about TriggerMesh, check out our web site at www.triggermesh.com and you can also request to access our Beta program.
Published at DZone with permission of Sameer Naik. See the original article here.
Opinions expressed by DZone contributors are their own.