Let’s review what has been deployed.
Jets leverages CloudFormation for deployment, so check the CloudFormation console. You should see something like this:
Jets creates a main parent
demo-dev stack that, in turn, creates nested CloudFormation stacks. This solves the CloudFormation quotas and limits.
It may seem overwhelming if this is your first time looking at it. A nested stack is created for each Job class definition in your Jets project. This allows you to create as many jobs for your project as you wish.
If you look at the CloudFormation stack
demo-dev-HardJob-* Resources tab, you’ll see the AWS resources Jets created for
Next, let’s check the AWS Lambda Console. You can click on the Physical ID link of the
demo-dev-hard_job-perform to take you there. You’ll see something like this:
The Lambda function is a handler shim generated by Jets as a part of the deployment. It provides the interface required by a Lambda function. The
Jets.process ultimately calls the
HardJob#process method. You can open
app/jobs/hard_job.rb and see the code we created earlier.
Test Lambda Function
Let’s test Lambda function manually with the Lambda Console built-in Test functionality. For the event, the example payload is fine. You can use anything. After you click Test, you’ll see an “Executing function: succeeded” message with a link to the logs.
Clicking on the logs link takes you to the CloudWatch Logs Console. It shows all the Log Streams for the Log Group for the Lambda Function. Clicking Search Log Group and filtering by 1m or 30m is an easy way to see the logs.
Next, we’ll make some updates and do more testing.