Amazon SQS source
Consumes events from an Amazon SQS queue.
With tmctl
:
tmctl create source awssqs --arn <arn> --auth.credentials.accessKeyID <access key> --auth.credentials.secretAccessKey <secret key>
On Kubernetes:
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:
- type
com.amazon.sqs.message
- source
<arn>
- Schema of the
data
attribute: com.amazon.sqs.message.json
See the Kubernetes object reference for more details.
Prerequisites
- 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 us-west-2
region.
$ aws --region us-west-2 sqs get-queue-attributes --queue-url $(aws --region us-west-2 sqs list-queues --queue-name MyQueue | jq -r .QueueUrls[0]) --attribute-names QueueArn
{
"Attributes": {
"QueueArn": "arn:aws:sqs:us-west-2:123456789012:MyQueue"
}
}
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:
kubectl create secret generic awscreds \
--from-literal=access_key_id=<ACCESS_KEY_ID> \
--from-literal=secret_access_key=<SECRET_ACCESS_KEY>
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 awscreds
.
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:
$ kubectl get awssqssource
NAME READY REASON SINK AGE
sqs-guide True http://sockeye.sebgoa.svc.cluster.local 3m57s
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.