Amazon SQS source
Consumes events from an Amazon SQS queue.
apiVersion: sources.triggermesh.io/v1alpha1 kind: AWSSQSSource metadata: name: sqs-guide spec: arn: arn:aws:sqs:us-east-1:123456789012:triggermesh receiveOptions: visibilityTimeout: 30m auth: credentials: accessKeyID: valueFromSecret: name: awscreds key: access_key_id secretAccessKey: valueFromSecret: name: awscreds key: secret_access_key sink: ref: apiVersion: eventing.triggermesh.io/v1alpha1 kind: RedisBroker name: triggermesh
When TriggerMesh is running on Amazon EKS, you can use an IAM role for authentication rather than an access key and secret. In this case, TriggerMesh will generate a Kubernetes service account for you that will leverage this IAM role. You also have the option of specifying your own service account name, and if a service account with the same name already exists and it is already managed by the TriggerMesh controller, then it will be reused. By reusing the same serivce account in this way, you can avoid having to create many STS trust relationships for each generated service account.
For more details on authenticating with AWS, please take a look at our dedicated guide on AWS credentials.
Events produced have the following attributes:
- Schema of the
See the Kubernetes object reference for more details.
- An SQS Queue
- The queue's ARN
Create an SQS Queue
If you don't already have an Amazon SQS queue, create one by following the instructions in the Getting started with Amazon SQS guide.
Obtain the queue's ARN
A fully qualified Amazon Resource Name (ARN) is required to uniquely identify the Amazon SQS queue.
As shown in the above screenshot, you can obtain the ARN of a SQS queue from the AWS console. It typically has the following format:
Alternatively you can also use the AWS CLI. The following command retrieves the ARN of a SQS queue named
MyQueue in the
Guide to SQS source on Kubernetes
Creating a K8s secret
Create a secret called
awscreds which contains your access key and your secret key like so:
Writing and applying a YAML manifest
Then, write a YAML manifest for your SQS source similar to the one below. The following sample points to a SQS queue, referenced by its ARN and a secret called
apiVersion: sources.triggermesh.io/v1alpha1 kind: AWSSQSSource metadata: name: sqs-guide spec: arn: arn:aws:sqs:us-east-1:123456789012:triggermesh receiveOptions: visibilityTimeout: 30m auth: credentials: accessKeyID: valueFromSecret: name: awscreds key: access_key_id secretAccessKey: valueFromSecret: name: awscreds key: secret_access_key sink: ref: apiVersion: eventing.knative.dev/v1 kind: Broker name: default
Create this source with the
kubectl apply -f command.
Verify that your source is ready with:
Test the flow
You can go to the AWS SQS console and put a message in the queue as shown in the following screenshot:
The message will get consumed by the source.
Below is a screenshot of an example event shown using the Sockeye event display service as a target.