Update 12/21/2018: An improved way to run Rails on AWS Lambda is now supported that is effortless. This blog post covers it: Jets Afterburner: Serverless Rails on AWS Lambda in 5 Minutes. It is also documented here: Jets Rails Support. It is recommended you use Jets Afterburner for simple cases.

Jets allows you to run Rails applications on AWS Lambda via Mega Mode. The name reminds me of a few things:

• Mega Monolith: Rails applications can sometimes become a Majestic Monolith. Or sometimes it just becomes a Monolith 😁
• Power Rangers Mega Mode: The Power Rangers can combine their Zords.
• Mega Man: This superhero can change his arm to use different special weapons. One of the things that makes him Mega Man.

Mega Mode combines a Jets app and a Rack app together to allow you to run Rails on AWS Lambda with little effort. The docs for Rails Support are on the Ruby On Jets site. Here’s a Live Mega Mode Demo. We’ll go through an example of Mega Mode and get a Rails application running on AWS Lambda in this post.

Setup: New Jets App

To demonstrate Jets Rails Support, we’ll first create a brand new Jets app. Then we’ll add an existing Rails application to it. Here are the commands based on the Quick Start to generate a new Jets app.

gem install jets
jets new demo
cd demo
jets generate scaffold Post title:string
vim .env.development # edit with local db settings
jets db:create db:migrate
jets runner '3.times {|i| Post.create(title: "Title #{i+1}") }' # seed some data
jets server # starts server on localhost:8888

You should see a Jets welcome page on the localhost:8888 and simple CRUD actions under localhost:8888/posts. The Jets welcome page looks something like this:

And the CRUD posts index page like this:

Here’s the initial tongueroo/jets-mega-demo repo. It’s been tagged with before-megamode.

Add Rails App: jets import:rails

Zords Combine! -Power Rangers

Now it’s time to add a Demo Rails app to the Jets project. Jets provides a handy jets import:rails command that makes this a simple task.

jets import:rails http://github.com/tongueroo/demo-rails.git

The import command essentially copies the project to a rack folder within the demo Jets app. The import command also adds an example route to config/routes.rb to enable Mega Mode. It looks something like this:

Jets.application.routes.draw do
  # ...
  # Enables Mega Mode Rails integration
  any "*catchall", to: "jets/rack#process"
end

The newly added catchall route forwards requests to a special jets/rack#process controller. This controller forwards requests to the Rails application in the rack subfolder.

Here’s the Jets project after the Mega Mode has been set up: tongueroo/jets-mega-demo.

Local Testing

cd rack # in the imported Rails app
bundle exec rails db:create db:migrate # needed if you havent ran the demo app before
bundle exec rackup # starts Rails app on http://localhost:9292

First, it is good to check that the imported Rails app in the rack subfolder works locally.

The demo-rails app has a /info route that provides some info about the Rails application. You should see something like this:

Once the Rails app looks good, we can shut down the rack server and test the Jets app with Mega Mode. Let’s start the jets server:

jets server

Notice that 2 servers start up. The jets server starts up on localhost:8888 and the rack server starts on localhost:9292

Now hit the /info route again except this time on port 8888. It shows the same info page, but this time it's going through the Jets app via Mega Mode.

Let’s also visit localhost:8888 and localhost:8888/posts again. These urls are served by the Jets app as defined by config/routes.rb. Only when the routes hit the catchall Mega Mode route will it get forwarded to the Rails app. To make it clear we can adjust the app/views/posts/index.html.erb and replace <h1>Posts</h1> with <h1>Jets App: Posts</h1>. Now we can see the difference easily:

http://localhost:8888/posts:

http://localhost:8888/info:

Mega Mode is controlled via routing. You can selectively route requests to the Rails app by adding routes send to jets/rack#process.

Where to Find Logs

It is useful to know where logs are. The rack server will send Rails logs to whatever has been set up in the Rails app, usually a log file like rack/log/development.log. Here's an example:

$ tail -f rack/log/development.log

Started GET "/info" for 127.0.0.1 at 2018-11-03 21:18:34 +0000
Processing by DemoController#index as HTML
   (0.2ms)  SET NAMES utf8,  @@SESSION.sql_mode = CONCAT(CONCAT(@@sql_mode, ',STRICT_ALL_TABLES'), ',NO_AUTO_VALUE_ON_ZERO'),  @@SESSION.sql_auto_is_null = 0, @@SESSION.wait_timeout = 2147483
   (0.1ms)  SELECT version()
  Rendering demo/index.html.erb within layouts/application
  Rendered demo/index.html.erb within layouts/application (0.5ms)
Completed 200 OK in 13ms (Views: 10.0ms | ActiveRecord: 0.9ms)

The main Jets app sends the logs to stdout as part of the jets server command. Example:

$ jets s --host 0.0.0.0
* Environment: development
* Listening on tcp://localhost:9292
Use Ctrl-C to stop
I, [2018-11-03T21:28:51.363402 #18894]  INFO -- : Processing by PostsController#index
I, [2018-11-03T21:28:51.364730 #18894]  INFO -- :   Event: {"resource"=>"/posts", "path"=>"/posts", "httpMethod"=>"GET", ...}
I, [2018-11-03T21:28:51.364801 #18894]  INFO -- :   Parameters: {}
I, [2018-11-03T21:28:51.587102 #18894]  INFO -- : Completed Status Code 200 in 0.224176506s
104.220.39.135 - - [03/Nov/2018:21:28:51 +0000] "GET /posts HTTP/1.1" 200 - 0.4635

When the app is deployed to AWS Lambda, both Jets and Rails logs are streamed to CloudWatch Logs instead.

Deploy to AWS Lambda

We’re almost ready to deploy to AWS Lambda. You will need an RDS database set up for this. You can follow the AWS docs, Create an RDS DB Instance, wizard steps to set up an RDS database. For this tutorial, we’re using MySQL 5.7.23. Also for simplicity, we’ll make it publicly accessible and open up security group port 3306. This is a throwaway database and will have been deleted by the time this post has been published. It usually takes less than 5 minutes for the RDS database to be available. Once it’s available you can grab the RDS endpoint from the RDS console:

To set up the RDS endpoint with the app, create a .env.development.remote file at the top level of your project and updated it with the DATABASE_URL. The format of DATABASE_URL looks like this:

DATABASE_URL=mysql2://dbuser:dbpass@host/dbname?pool=5
DATABASE_URL=mysql2://dbuser:dbpass@demotest.cbuqdmc3nqvb.us-west-2.rds.amazonaws.com/dbname?pool=5 # another example with an rds host
vim .env.development.remote # edit and add DATABASE_URL

We’re using an env.development.remote file because we want this specific value for DATABASE_URL to be set remotely on AWS Lambda only. More info about Env Files and Remote Only Variables are available on the docs.

One way to test the RDS database locally is by using the JETS_ENV_REMOTE=1 flag. We'll also use this to create and migrate the database on RDS.

$ JETS_ENV_REMOTE=1 jets db:create db:migrate
$ JETS_ENV_REMOTE=1 jets console
>> ActiveRecord::Base.connection.tables
=> ["ar_internal_metadata", "posts", "schema_migrations"]
>>

We’re now ready to deploy AWS Lambda! Let’s run jets deploy:

$ jets deploy
...
10:15:26PM UPDATE_COMPLETE_CLEANUP_IN_PROGRESS AWS::CloudFormation::Stack demo-dev
10:15:27PM UPDATE_COMPLETE AWS::CloudFormation::Stack demo-dev
Stack success status: UPDATE_COMPLETE
Time took for stack deployment: 2m 1s.
Prewarming application.
API Gateway Endpoint: https://u3egh0sere.execute-api.us-west-2.amazonaws.com/dev/
$

After the deploy completes, you can check it out in the browser. Using your specific API Gateway endpoint, visit /dev/posts and /dev/info. You should see something like this:

https://api-gateway-endpoint/dev/posts:

https://api-gateway-endpoint/dev/info:

Explore the AWS Console

It is useful to check out the Lambda console because you can see the function code and even test it live in the editor. Lambda Functions:

Let’s take a look at the demo-dev-posts_controller-index function and test it with the Lambda Console:

Click on the “Test” button on the upper right-hand corner and configure a test event. For the test event payload, it does not matter what we use since the PostsController#index doesn't use the parameters so just use the provided example. After you've configured an event in hit "Test" again you should see something like this:

For other actions, the test event payload does matter. Controller Lambda functions expect a payload from API Gateway. So you need a similar payload structure to test with the Lambda Console. Adding a puts JSON.dump(event) in the controller is a great way grab a live API Gateway event payload for testing. Also here are some examples to help you get an idea of the minimal structure:

posts#new

{"path": "/posts/new"}

The new action uses the path to generate the new form.

posts#show

{"path": "/posts/123"}

The post id must be provided and exist in the database or you’ll get a “Couldn’t find Post without an ID” error. 123 is an example.

posts#edit

{"path": "/posts/123/edit", "pathParameters": {"id": "123"}}

You will also need pathParameters because that’s how the controller gets the id parameter.

jets/rack#process

The rack controller requires the path to be forwarded to the Rails app.

Notice how the jets/rack#process controller just needs a {"path": "/info"} payload since that's all the Rails app /info url requires.

CloudWatch Logs

As mentioned early in the “Where to Find Logs” section, when the app is deployed to AWS Lambda, the logs are streamed to Cloudwatch logs instead. Here’s what the CloudWatch Log groups look like:

If you click into the posts_controller-index log group and hit the /dev/posts url in the browser you should see something like this:

For Mega Mode requests, go to the jets-rack_controller-process log group and hit the /dev/info url, you'll notice both Rails and Jets logs:

Jets prepends “Rails: “ to the Rails logging output to distinguish them from the Jets app logging.

Live Demo

Here’s a Live Demo to see and use Mega Mode in action.

That’s it! You can run a Rails application on AWS Lambda today. Hope you like Mega Mode and give it try. Also if you find Jets interesting, please give it ⭐️ it on GitHub. 👍

More info

• For an Jets Introduction: Introducing Jets: A Ruby Serverless Framework.
• Also more info at: Jets documentation site.

Originally published at https://blog.boltops.com on November 3, 2018.

Jets Mega Mode: Run Rails on AWS Lambda was originally published in BoltOps on Medium, where people are continuing the conversation by highlighting and responding to this story.

Jets supports writing simple AWS Lambda functions with Ruby. You define them in the app/functions folder. A function looks like this:

app/functions/simple.rb:

def lambda_handler(event:, context:)
  puts "hello world"
end

The default handler is named lambda_handler. The lambda function shows up in the Lambda console like this:

You can run the function in the AWS Lambda console and see the results:

More than Simple Functions

Though simple functions are supported by Jets, aside from the ability to use Ruby they do not really add much value. Other classes like controllers and jobs add many conveniences and are more powerful to use. Here are a few quick examples:

Controllers

class PostsController < ApplicationController
  def index
    # renders Lambda Proxy structure compatiable with API Gateway
    render json: {hello: "world", action: "index"}
  end
end

Controllers are designed to handle web request and serve responses.

The public methods of a Controller class get deployed as separate AWS Lambda functions.

Jobs

class HardJob < ApplicationJob
  rate "10 hours" # every 10 hours
  def dig
    puts "done digging"
    {done: "digging"}
  end
end

Jobs are designed to handle background jobs and can process work outside the web request cycle. The rate declaration creates a CloudWatch rule and schedules the function to run periodically.

Once again, the public methods of a Job class get deployed as separate AWS Lambda functions.

So you’d probably benefit more from writing Controllers and Jobs since they add so many conveniences over the simple function.

Thanks for reading this far. If you found this article useful, I’d really appreciate it if you share this article so others can find it too! Thanks 😁 Also follow me on Twitter.

Got questions? Check out BoltOps.

Originally published at https://blog.boltops.com on October 26, 2018.

Jets Simple AWS Lambda Ruby Function was originally published in BoltOps on Medium, where people are continuing the conversation by highlighting and responding to this story.

In the previous post, AWS Config was introduced. We talked about how it can be used to obtain continuous compliance with your AWS account. In this post, we’ll implement a working example solution.

The typical architecture with AWS Config Rules looks like this:

Typical CloudFormation Implementation

To create AWS Config Rules, the typical approach is to codify your infrastructure with CloudFormation. If you’re new to CloudFormation, check out the Introduction to CloudFormation series. CloudFormation is one of the most powerful tools from AWS. CloudFormation allows you to create any AWS resource with simple YAML.

Let’s take a look at some Config Rules implemented in CloudFormation. It looks something like this:

Resources:
  CloudTrailLogIntegrityLambdaFunction:
    Type: AWS::Lambda::Function
    Properties:
      Code:
        ZipFile: |
          # ...
          def lambda_handler(event, context):
            # ...
                config.put_evaluations(
                  Evaluations = evaluations,
                  ResultToken = result_token
                )
      Role: !GetAtt IamRole.Arn
      Timeout: 20
      MemorySize: 1536
      FunctionName: rules-example-check_rule-cloud_trail_log_integrity
      Handler: index.lambda_handler
      Runtime: python3.6
  CloudTrailLogIntegrityConfigRule:
    Type: AWS::Config::ConfigRule
    Properties:
      ConfigRuleName: rules-example-check-cloud-trail-log-integrity
      Source:
        Owner: CUSTOM_LAMBDA
        SourceIdentifier: !GetAtt CloudTrailLogIntegrityLambdaFunction.Arn
        SourceDetails:
        - EventSource: aws.config
          MessageType: ConfigurationItemChangeNotification
        - EventSource: aws.config
          MessageType: OversizedConfigurationItemChangeNotification
      Description: CIS 2.2, 2.7 - Ensure CloudTrail log file validation is enabled
        (Scored), ensure CloudTrail logs are encrypted at rest using KMS CMKs (Scored)
      Scope:
        ComplianceResourceTypes:
        - AWS::CloudTrail::Trail
    DependsOn: CloudTrailLogIntegrityPermission
  CloudTrailLogIntegrityPermission:
    Type: AWS::Lambda::Permission
    Properties:
      FunctionName: !GetAtt CloudTrailLogIntegrityLambdaFunction.Arn
      Action: lambda:InvokeFunction
      Principal: config.amazonaws.com
  IncomingSshDisabledConfigRule:
    Type: AWS::Config::ConfigRule
    Properties:
      ConfigRuleName: rules-example-check-incoming-ssh-disabled
      Source:
        Owner: AWS
        SourceIdentifier: INCOMING_SSH_DISABLED
      Description: 'CIS 4.1: Ensure no security groups allow ingress from 0.0.0.0/0
        to port 22'
      Scope:
        ComplianceResourceTypes:
        - AWS::EC2::SecurityGroup

The full source code for this example project is at: tongueroo/config-rules-cloudformation. The command to launch the CloudFormation stack from the README is provided here for your convenience:

aws cloudformation create-stack --template-body file://config-rules.yml --stack-name config-rules --capabilities CAPABILITY_IAM

A few minutes after running the command, you’ll end up with 2 config rules:

1. Managed Config Rule: Restrict Incoming SSH
2. Custom Config Rule: Check CloudTrail Log Integrity

The Config Console should look something like this:

While the pure CloudFormation approach works, it can be improved.

Jets Serverless Framework Implementation

CloudFormation is described as “Infrastructure as Code.” Most programmers would not say that YAML is code though. YAML is really more like configuration. So in the above example, we are not really writing “Infrastructure as Code” but “Infrastructure as Configuration.”

With the Jets Serverless Framework we can truly write our the Config Rules as code. Here’s an example of how we would create the same Config Rules with Jets:

app/rules/check_rule.rb:

class CheckRule < ApplicationRule
  class_runtime "python2.7"

desc "CIS 4.1 - Ensure no security groups allow ingress from 0.0.0.0/0 to port 22"
  scope "AWS::EC2::SecurityGroup"
  managed_rule :incoming_ssh_disabled

desc "CIS 1.3 - Ensure credentials unused for 90 days or greater are disabled"
  scope "AWS::IAM::User"
  python :rotate_user_passwords
end

The code takes advantage of Jets Polymorphic support. It defines a Python Lambda function and neatly organize it in separate file. The source code is here python/rotate_user_passwords.py

With only those few lines of code, the entire CloudFormation implementation has been replaced. Except, in this case, we have access to a programming language, not just YAML constructs. This is “Infrastructure as Code.”

The AWS Config console looks something like this:

To deploy the application, it’s simple command:

Once you have access to the full power of a coding language, it becomes easier to add additional business logic like Daily Compliance Emails, Threshold Alarms, etc. You don’t have to write your code in one monolithic CloudFormation template.

Pricing

Note, running AWS Config Rules cost money and is not structured the same way you might be accustomed to. With EC2 pricing, you pay for usage on a per second basis. Once you turn off the instance, you stop paying.

With Config Rules, you pay $2/mo for each Config Rule once it reports compliance status for the very first time. Even if you destroy the Config Rule an hour later, you’ll still pay the $2 for that month. Pointing this out, so you are aware of it. This is why it is also nice that these example projects only have 2 rules to demonstrate working solutions without costing too much.

When you get to a higher number of rules, the pricing drops down to $1.50/mo/rule and then $1/mo/rule. You also pay $0.003 per configuration item recorded which can add up if you’re configuration changes often.

For more current prices refer to the AWS Config Rules Pricing.

Final Thoughts

In this post, we covered 2 ways to create AWS Config Rules:

1. CloudFormation Raw Implementation
2. Jets Framework Implementation

It’s interesting to note that ultimately Jets translates the code to CloudFormation anyway. A crude analogy is that we use compilers to convert a high-level programming language to machine code. Similarly, Jets translates the code to YAML. Additionally, Jets allows you access to more powerful programming language abilities that we’re accustomed to having.

It might not seem like there’s that not much that difference with only 2 AWS Config rules here. However, imagine having 10 or 20 Config Rules. We’re talking about 3 lines of code over the 20+ lines of YAML for each Config Rule here. The CloudFormation template gets pretty complicated quickly and leads to a ton of duplication. Coding with a tool like Jets that wraps CloudFormation makes for a cleaner and more maintainable experience.

Source code for both implementations are both on GitHub:

• Config Rules Example CloudFormation Project
• Config Rules Example Jets Project

Thanks for reading this far. If you found this article useful, I’d really appreciate it if you share this article so others can find it too! Thanks 😁 Also follow me on Twitter.

Got questions? Check out BoltOps.

Originally published at https://blog.boltops.com on September 29, 2018.

Continuous Compliance AWS Config Rules Implementation with Jets Serverless Framework was originally published in BoltOps on Medium, where people are continuing the conversation by highlighting and responding to this story.

AWS is one of the greatest things since sliced bread. It empowers engineers to get things done quickly by enabling them to take control of the steering wheel and drive. With a simple AWS account, engineers can create resources, update security groups, and deploy their applications in rapid-fire fashion. The ease and power of AWS might make it seem like a security nightmare, but it’s actually the opposite. AWS provides the tools and controls to ensure everyone is following best practices, allows to you achieve a hardened security posture, and take compliance to a level that was never even thought possible before AWS: continuously.

Blessing in Disguise

The dynamic nature of the AWS Cloud is a security blessing in disguise. I’ll explain.

The typical audit process can sometimes take months. By the time the process is completed, things have already changed 🤦🏻‍♂️ With AWS, things are so dynamically that the standard auditing process does not suffice. Instead, we need to ensure that our AWS account is compliant in real-time.

Let’s think about this for a moment. Isn’t better compliance something we want anyway? Or are we okay having our AWS account being compliant only briefly during the audit review? Or do we want to have our AWS account compliant all the time?

The answer is: of course all the time. Continuous compliance is a goal we should all strive for. We probably shy away from the goal because it sounds like an impossible feat. But is it?

It is entirely possible thanks to the powerful automation tools that AWS provides. The tools make continuous compliance not only possible but, dare I say, simple.

Meet AWS Config

AWS Config is a service that allows you to show that your AWS account is compliant and prove it, continuously. It evaluates “rules” that you define according to your business requirements and tells you when the AWS account is not following those rules immediately. The dashboard looks like this:

The architecture of AWS Config rules looks something like this:

There are two types of Config Rules:

1. AWS Config Managed Rules
2. AWS Config Custom Rules

AWS managed rules are prebuilt and managed by AWS themselves. AWS maintains and updates the rules for you, which is helpful. You can customize managed rules with input parameters.

Custom rules are associated with AWS Lambda function and can be fully customized to meet your needs. They are useful when the managed rules don’t do quite what you require. This is where you tap into the power of AWS Lambda and serverless. You can add any custom business logic and define your security and compliance posture.

In real life, you’ll use a combination of the two types of rules to achieve compliance according to your business requirements. AWS turns the compliance world upside on its head and puts it in the real-time world. Hope you found this brief introduction to AWS Config helpful. In the next article, Continuous Compliance AWS Config Rules Implementation, we’ll talk about how actually to implement AWS Config in a clean manner.

Thanks for reading this far. If you found this article useful, I’d really appreciate it if you share this article so others can find it too! Thanks 😁 Also follow me on Twitter.

Got questions? Check out BoltOps.

Originally published at https://blog.boltops.com on September 28, 2018.

Continuous Compliance: AWS Config Rules Introduction was originally published in BoltOps on Medium, where people are continuing the conversation by highlighting and responding to this story.

A quick way to test a Lambda function, is to add a little portion of code at the bottom of the script that tells it to run itself when it is the main script. The if statement means that the script will only run if it is ran directly vs being required as library.

hi.rb:

if __FILE__ == $0
  puts "this script was ran directly"
end

So this will run the if statement:

$ ruby hi.rb # run directly
this script was ran directly
$

And this will not run the if statement:

myfile.rb:

require_relative "hi" # being required, so not ran directly

See how running it now does not result in this script was ran directly being printed out.

$ ruby myfile.rb # will not run script since `hi.rb` is being required
$

Always forget the way to do it between languages, so writing it down for posterity.

Here are different ways to check if the script is being ran directly in: Ruby, Python, Node and Bash.

Code Examples

Ruby

def handle(event:, context:)
  p event
end

if __FILE__ == $0
  event = {hi: "world"}
  handle(event: event, context: {})
end

Output:

{:hi=>"world"}

Python

def lambda_handler(event, context):
  print(event)

if __name__ == "__main__":
  event = {'hi': 'world'}
  lambda_handler(event, {})

Output:

$ python hi.py
{'hi': 'world'}

Node

const handler = function(event, context, callback) {
  console.log(event);
}

if (require.main === module) {
  var event = {'hi': 'world'};
  var context = {'fake': 'context'};
  exports.handler(event, context);
}

Output:

$ node hi.js
{ hi: 'world' }

Bash

function handler () {
  EVENT_DATA=$1
  echo "$EVENT_DATA" 1>&2;
  RESPONSE="Echoing request: '$EVENT_DATA'"

echo $RESPONSE
}

if [[ "${BASH_SOURCE[0]}" == "${0}" ]]; then
  handler '{"test": 1}'
  # handler "$@"
fi

Output:

$ node hi.js
{ hi: 'world' }

Thanks for reading this far. If you found this article useful, I’d really appreciate it if you share this article so others can find it too! Thanks 😁 Also follow me on Twitter.

Got questions? Check out BoltOps.

Originally published at https://blog.boltops.com on September 17, 2018.

Quick AWS Lambda Testing If Main Script Trick: Ruby, Python, Node, Bash was originally published in BoltOps on Medium, where people are continuing the conversation by highlighting and responding to this story.

In this video, we continue the tutorials on the Jets Ruby Serverless Framework that adds Ruby support to AWS Lambda. We talk about a Jets concept called extra environments. With one environment variable JETS_ENV_EXTRA, we can create as many additional instances of environments as we wish. This helps when multiple people are asking to use the development, staging, or uat environment but cannot because it is currently used by someone else or another feature. Usually, you end up having to wait until the environment free. With this Jets concept you can create as many environments as required.

It is also interesting that AWS Lambda pricing is based on a usage, the extra environments pretty much are free. Usually, development environments get much less traffic or requests.

Summary of What We’ll Cover

• Explain JETS_ENV_EXTRA concept
• Provide a demo

Cleanup

To delete the extra environment:

JETS_ENV_EXTRA=2 jets delete

Note, you’ll be prompted with an ‘Are you sure?’ message.

More info

Thanks for reading this far. If you found this article useful, I’d really appreciate it if you share this article so others can find it too! Thanks 😁 Also follow me on Twitter.

Got questions? Check out BoltOps.

Originally published at https://blog.boltops.com on September 13, 2018.

Jets Tutorial Extra Environments Part 7: AWS Lambda Ruby was originally published in BoltOps on Medium, where people are continuing the conversation by highlighting and responding to this story.

In this video, we continue the tutorials on the Jets Ruby Serverless Framework that adds Ruby support to AWS Lambda. We’ll demonstrate how to customize the properties associated with the Lambda functions that Jets creates. There are 3 ways to set function properties with Jets: at the function level, class level or application level. We’ll also explore the AWS Lambda console and shows how the Lambda function properties connect with Jets.

Here’s a list of the properties you can adjust.

For more info, refer to the Function Properties docs.

Summary of What We’ll Cover

• What function properties are
• Take a look at function properties in the Lambda Console
• Take a look at helpful CloudFormation docs that list the properties
• Show how Jets allows you to customize any property
• Explain Jets function properties precedence
• Deploy and demo function properties in action with an example

More info

Thanks for reading this far. If you found this article useful, I’d really appreciate it if you share this article so others can find it too! Thanks 😁 Also follow me on Twitter.

Got questions? Check out BoltOps.

Originally published at https://blog.boltops.com on September 12, 2018.

Jets Tutorial Function Properties Part 6: AWS Lambda Ruby was originally published in BoltOps on Medium, where people are continuing the conversation by highlighting and responding to this story.

In this video, we continue the tutorials on the Jets Ruby Serverless Framework that adds Ruby support to AWS Lambda. We’ll demonstrate how to customize the IAM policies and roles associated with Jets Lambda functions. IAM policies are important because they handle securing access to your AWS resources so it’s worth learning them. Jets provides you with fine-grain control over the IAM permissions at the function, class, and application level.

Summary of What We’ll Cover

• Cover the 2 types of IAM Policies: Custom and Managed
• Show to define both IAM policy types with Jets
• Explain how the Jets shorthand IAM policy definition gets expanded
• Explore the roles and their policies in the IAM Console
• Show how the IAM Roles connect back to the Jets application
• Deploy custom IAM Policies
• Review the newly created IAM Policies

More info

Thanks for reading this far. If you found this article useful, I’d really appreciate it if you share this article so others can find it too! Thanks 😁 Also follow me on Twitter.

Got questions? Check out BoltOps.

Originally published at https://blog.boltops.com on September 11, 2018.

Jets Tutorial IAM Policies Part 5: AWS Lambda Ruby was originally published in BoltOps on Medium, where people are continuing the conversation by highlighting and responding to this story.

In this video, we continue the tutorials on the Jets Ruby Serverless Framework that adds Ruby support to AWS Lambda. We’ll cover background jobs in this video. Using background jobs is a typical pattern that offloads processing outside of the web request-response cycle. Users will not wait for web pages to load if it takes too long, so background jobs are an excellent technique to keep slower work outside of the request cycle.

Summary of What We’ll Cover

• Explain What A Background Job Is
• Create a Background Job
• Deploy the App to AWS Lambda
• Explore the AWS CloudWatch Event Rule Console
• See how to check how many times the Job has Ran
• Check out CloudWatch Logs

More info

Thanks for reading this far. If you found this article useful, I’d really appreciate it if you share this article so others can find it too! Thanks 😁 Also follow me on Twitter.

Got questions? Check out BoltOps.

Originally published at https://blog.boltops.com on September 10, 2018.

Jets Tutorial Background Jobs Part 4: AWS Lambda Ruby was originally published in BoltOps on Medium, where people are continuing the conversation by highlighting and responding to this story.

In this video, we continue the tutorials on the Jets Ruby Serverless Framework that adds Ruby support to AWS Lambda. We’ll cover something that is pretty important to know as a software developer: debugging. With Jets it’s pretty straightforward to look at the debugging logs both locally and remotely. Locally, the logs show up with the local running server. Remotely, the logs show up in CloudWatch Logs: available both on the AWS CloudWatch Logs console and the AWS Lambda console.

Lambda Console

Here’s what an error looks like in the Lambda console:

Summary of What We’ll Cover

• Breaking the App Locally by calling raise "the roof"
• Checking out the log output locally
• Breaking the App Remotely by calling raise "my kids"
• Deploy the App
• Checking out the log output on AWS CloudWatch logs and the AWS Lambda console

More info

Thanks for reading this far. If you found this article useful, I’d really appreciate it if you share this article so others can find it too! Thanks 😁 Also follow me on Twitter.

Got questions? Check out BoltOps.

Originally published at https://blog.boltops.com on September 9, 2018.

Jets Tutorial Debugging Logs Part 3: AWS Lambda Ruby was originally published in BoltOps on Medium, where people are continuing the conversation by highlighting and responding to this story.