DEV Community: Jalerson Lima

Be careful when using error reporting services and serverless functions

Jalerson Lima — Sat, 31 Aug 2019 07:13:22 +0000

First, a disclaimer: the problem presented by this blog post happened when using AWS Lambda, Honeybadger, and Ruby. If you're using a different cloud provider, error reporting service and/or programming language, this might not be a problem, which doesn't mean you shouldn't be aware of it.

That said, let's start.

Honeybadger is a popular service for monitoring errors and application uptime like many others. We use it in production for a long time and it's taking care nicely, however, when we started using Honeybadger to report eventual problems in our AWS Lambda functions, a very interesting and unexpected situation happened.

We started to notice that Honeybadger eventually failed to report errors from our lambda functions, which is very tricky because we rely on it to notifies us when something goes wrong. If there are no notifications, there are no problems, right? We have more important things to do rather than watching the logs in Cloudwatch all over the day.

This week I was intentionally provoking errors in one particular lambda function, just to check if Honeybadger would report errors, but it didn't.

According to the Honeybadger documentation (Architecture Deep-Dive), the Worker, which is responsible for pulling Notice from the Queue, runs in a different thread to not block the execution of your application while reporting errors. This is great, however, it represents a problem when running in serverless functions.

The AWS Lambda Execution Context page says:

Background processes or callbacks initiated by your Lambda function that did not complete when the function ended resume if AWS Lambda chooses to reuse the execution context. You should make sure any background processes or callbacks in your code are complete before the code exits.

Which means, when your lambda function finishes the execution, the Worker, which runs in a different thread, might not have finished sending the error notification.

Fortunately, the solution is simple. However, it took me some time to find it because, until the moment I'm writing this post, it's not available in Honeybadger documentation (yes, I needed to dive into their code).

When using the Honeybadger.notify method, make sure to set sync: true:

Honeybadger.notify(error, sync: true)

When using sync: true, Honeybadger will send the notification immediately, and not pushing it into the queue to be processed by the worker: https://github.com/honeybadger-io/honeybadger-ruby/blob/master/lib/honeybadger/agent.rb#L161

Alternatively, you can also call Honeybadger.flush after calling Honeybadger.notify to force Honeybadger to send all the notifications: https://github.com/honeybadger-io/honeybadger-ruby/blob/master/lib/honeybadger/agent.rb#L314

If you want to know more about this matter, take a look at this nice article in DZone: Multi-Threaded Programming With AWS Lambda

Hello Serverless with Jets and Dynamoid

Jalerson Lima — Tue, 15 Jan 2019 11:09:10 +0000

Jets is a Ruby framework which allows us to easily create and deploy serverless applications to AWS. Jets is adopting several concepts and patterns from Rails, which makes much easier the adoption of serverless architectures by Rails developers.

Jets is in early stages of maturity, however, its creator, Tung Nguyen, is making a lot of effort to improve the framework and the community around it is growing.

The application we'll be using as an example is the same previously used in Building AWS Lambdas for Real World using Ruby and Serverless Framework: a simple app which will consume data posted by Github. This sample project is available clicking here.

Like Leeroy Jenkins would say: Alright, time's up! Let's do this!

Prerequisites

Obviously, have Jets installed is necessary. If you don't have, go to your terminal and install it:

$ gem install jets

In order to deploy your app to AWS, you'll need to have your AWS keys set up in ~/.aws/credentials. In case you don't have, please refer to Configuration and Credential files.

Creating our Jets app

Since we're not interested in assets serving, let's create our app using API mode:

$ jets new jetsapp --mode=api
$ cd jetsapp

By default, Jets supports ActiveRecord and DynamoDB via Dynomite. However, I'm interested in something different here: I want to use Dynamoid, which is a stable and mature Ruby ORM for AWS DynamoDB.

That said, let's update our Gemfile to add Dynamoid and remove mysql2.

# gem "mysql2", "~> 0.5.2"
gem 'dynamoid', '~> 3.1.0'

Don't forget to update your dependencies by executing bundle install in your terminal.

Dynamoid requires AWS credentials in order to properly connect to DynamoDB. If we were in Rails, we could easily do it using initializers. Fortunately, initializers are one of the cool stuff adopted by Jets from Rails.

So, we just need to create config/initializers/dynamoid.rb and add the following:

We're configuring the namespace, which is optional (default is dynamoid) and it's a prefix for our DynamoDB tables. We're also setting our AWS access key id, secret key and region. Obviously, we're keeping all these data in our environment variables.

Last but not least, we're creating DynamoDB tables based on the models we have in app/models. Don't worry about the recreation of these tables when you perform a redeploy: Dynamoid takes care of it.

Now, let's update our .env file:

ACCESS_KEY_ID=<your_access_key_id>
SECRET_ACCESS_KEY=<your_secret_access_key>
REGION=<region>

Important: while writing this article, I figured out that are some environment variable names reserved by AWS, for instance, AWS_REGION. So take care to not use them :D

Models

Let's continue updating the app/models/application_item.rb, which is intended to be the parent class of all DynamoDB models. The default ApplicationItem generated by Jets looks like this:

Since we're not using Dynomite, we can remove it and include the Dynamoid::Document.

After that, let's build our GithubEvent model.

As you can see, we're defining the table name, fields names and types (the default is string), as well as some validation rules. Dynamoid automatically creates three fields: id (string), created_at (datetime) and updated_at (datetime).

Dynamoid also allows use to use: default field values, custom field types, associations, validations, callbacks, STI (Single Table Inheritance), record creation, querying and much more.

Controller

Using Jets, we can create a simple lambda function, or we can build our controller and each action will be transformed into an AWS lambda function. Let's use the second approach just because we can!

The github action will be responsible for receiving Github events data. The implementation couldn't be simpler! As you can see, even though we're not implementing a lambda function (which has the event and context arguments), the event variable is available. Btw, params is also available!

Finishing

Let's add the route to our config/routes.rb file:

And finally, execute jets deploy in our terminal to deploy our application. If you don't want to use the default profile to deploy, simply execute AWS_PROFILE=<profile_name> jets deploy.

Final considerations

I really like the idea of Jets framework: to bring concepts and patterns from Rails world to make our lives easier while migrating to serverless. Although the framework is still not mature for critical applications, I will definitely give it a try.

Special thanks to Tung Nguyen for the awesome support!

Looking for a job?

If you're looking for a job and are willing to relocate to Frankfurt (Germany), consider to take a look on the positions available at creditshelf.

Automating code checks with overcommit

Jalerson Lima — Sun, 30 Dec 2018 12:22:21 +0000

A few months ago, I was looking for something to prevent me to commit/push code with a debugger call, byebug for example. Then I found something that I didn't know at the moment: Git Hooks. Git Hooks allow running custom scripts when certain actions occur, for example: commit, push, merge, checkout, etc.

You can put whatever you want in these custom scripts, including to check if you did something not so clever, for example, push code with a byebug call. And if you search in Google, you'll find a couple of Git hook scripts to prevent you from doing that.

But then, as a Ruby developer, I thought: Hey, there's always a gem, right!?. Right! And it's called overcommit. Overcommit is a Ruby gem which allows you to easily manage and configure your Git hooks.

To start using overcommit is very simple:

$ gem install overcommit
$ overcommit --install

The overcommit --install command will create a .overcommit.yml settings file in the current folder and also back up existing hooks. The default settings file includes the following hooks:

CapitalizedSubject: Ensures commit message subject lines start with a capital letter
EmptyMessage: Checks that the commit message is not empty
SingleLineSubject: Ensures commit message subject lines are followed by a blank line
TextWidth: Ensures the number of columns the subject and commit message lines occupy is under the preferred limits
TrailingPeriod: Ensures commit message subject lines do not have a trailing period
AuthorEmail: Checks the format of an author's email address
AuthorName: Ensures that a commit author has a name with at least first and last names
BrokenSymlinks: Checks for broken symlinks
CaseConflicts: Checks for files that would conflict in case-insensitive filesystems

Of course, you can easily disable any of these hooks:

  CapitalizedSubject:
    enabled: false

Every time you perform changes in the settings file, you also need to update the signature running overcommit --sign. You can also disable signature checking by setting verify_signatures: false in your .overcommit.yml file. However, please read the security implications before doing that.

Recommended built-in hooks

The hooks described in this section are the ones I'm currently using and recommend. You can also find, between parenthesis in the hook title, in which action the hooks are being executed.

RuboCop (PreCommit)

Runs RuboCop against any modified Ruby files.

  RuboCop:
    enabled: true
    on_warn: fail
    problem_on_unmodified_line: ignore
    command: ['bundle', 'exec', 'rubocop']

on_warn: fail: blocks the commit in case of warnings
problem_on_unmodified_line: ignore: ignore problems in lines of code you did not add/change

BundleAudit (PreCommit)

Checks for vulnerable versions of gems in Gemfile.lock.

  BundleAudit:
    enabled: true
    flags: ['--update']

flags: ['--update']: force BundleAudit to update before checking

BundleCheck (PreCommit)

Check if local Gemfile.lock matches Gemfile when either changes, unless Gemfile.lock is ignored by git.

  BundleCheck:
    enabled: true

ForbiddenBranches (PreCommit and PrePush)

Prevents commits to branches matching one of the configured patterns.

  ForbiddenBranches:
    enabled: true
    branch_patterns: ['master']

Fasterer (PreCommit)

Runs fasterer against any modified Ruby files.

  Fasterer:
    enabled: true
    exclude:
      - 'vendor/**/*.rb'
      - 'db/schema.rb'

CustomScript (PreCommit)

Runs a custom command/script before commit.

  CustomScript:
    quiet: true
    enabled: true
    command: ['i18n-tasks', 'normalize']

The previous hook will run i18n-tasks normalize before commit. normalize is a task of the i18n-tasks gem.

BundleInstall (PostCheckout, PostMerge and PostRewrite)

Runs bundle install when a change is detected in the repository's dependencies.

  BundleInstall:
    enabled: true

Other (probably) useful built-in hooks

These are the hooks I'm not currently using but I'm willing to give a try.

Foodcritic: linting tool for writing better and safer code
RailsBestPractices: code metric tool to check the quality of Rails code
RailsSchemaUpToDate: Check to see whether the schema file is in line with the migrations
Reek: Code smell detector for Ruby
Brakeman: Vulnerability scanner designed for Rails applications. It statically analyzes code to find security issues
FixMe: Check for "token" (TODO, FIXME, etc.) strings before commit
BundleOutdated: List installed gems with newer versions available

Looking for a job?

If you're looking for a job and you live around Frankfurt am Main or you're willing to move, we have positions available at creditshelf. All positions available for English speakers.

Building AWS Lambdas for Real World using Ruby and Serverless Framework

Jalerson Lima — Sun, 09 Dec 2018 12:08:02 +0000

You may be wondering: "Why AWS Lambdas for Real World?". Well, since Amazon announced Ruby support for AWS Lambdas on November 29th, I've been reading about it because I'm a Ruby enthusiastic.

Currently, you can easily find several blog posts and tutorials explaining how to build your own Lambda functions in Ruby, most of them using the famous Hello World as example, which is good as a starting point, but, let's be honest, you won't need to build something as simple as a Hello World. You will need to face real-world issues regarding automated testing, using other services, building/deploying, handling dependencies, etc.

In this post, I'd like to share some ideas with those who, like me, started to reach a bit deeper in this matter, and discuss how to tackle these real-world issues using Ruby and Serverless Framework. Be aware that I'm not claiming that these are the best practices. My goal here is, as I mentioned, share some ideas and start a discussion about them.

The application that I'll be using as an example to illustrate these ideas is a GitHub App which will consume data from Github and calculate some metrics. The first step, which will be the focus of this post, is to receive data sent from the Github Webhook and store it in a DynamoDB table.

Application structure

The first topic we'll tackle is how to organize your application. Many guides I've found put everything in the root project folder and it's done. Particularly I don't like this approach, I tend to take care on how to organize my projects in multiple subfolders, so, in a long-term, this organization can persist and avoid some headaches. In addition, since you may have several projects, keeping a similar structure will help you to find what you're looking for. If you don't care about it, feel free to jump this section.

As far as I can see, there are three way to organize your application.

A single project with all functions and a single serverless framework settings file
Multiple projects, divided into application modules, each one with its own serverless framework settings file
Multiple projects, one per function, each one with its own serverless framework settings file

Particularly I choose the option 2. I believe the first option will result in a big single project, which may be a bit confusing to newcomer developers to start to contribute, however, may be the easiest option to build integration test across different functions. The third option, in the other hand, may turn these integration tests harder to implement, however, newcomer developers would have a smaller project to understand. The option 2 is a bit of both worlds.

I decided this first module will be called "webhooks". Currently, I'm integrating my application with Github, but in the future, I may decide to integrate it with something else. That said, the Webhooks project has the following structure.

├── app
    └── functions
        └── github.rb
    └── lib
        └── log.rb
    └── models
        └── github_event.rb
├── spec
    └── functions
        └── github_spec.rb
    └── support
        └── fixtures
            └── github
                └── events
                    └── push.json
    └── spec_helper.rb
├── serverless.yml
├── Gemfile and Gemfile.lock
├── Rakefile
├── Other files like .gitignore, .editorconfig, etc.

As you can see, I didn't lie about organizing my project in several subfolders. If you're a Rails developer, you may notice that I'm using a similar structure of Rails projects. I like the way Rails organize the projects and it's also familiar to me, which make it even easier for me to find something.

As I mentioned before, most of Hello World examples hold all files in a single root project folder, which makes very easy to the Serverless Framework settings file (serverless.yml) references the lambda function.

functions:
  myFunctionName:
    handler: <filename_without_extension>.<lambda_function_name>

However, in my case, the file which contains my lambda function (app/functions/github.rb) is inside multiple subfolders and, in addition, is a class method of Webhooks::Github.

To reference the handler class method inside Webhooks::Github, I needed to set it this way:

functions:
  github:
    handler: app/functions/github.Webhooks::Github.handler

Which corresponds to the following pattern: path/to/<filename_without_extension>.<module_name>::<class_name>.<method_name>

Automated testing

Next step: automated tests! Serverless is a new way of thinking about how to design applications, so, honestly, took me a while to really understand that a lambda function is as simple to test as a Ruby method. Once again, most of the blog post I found didn't tackle testing. In fact, I believe the only one I found discussing something about it was this one. But here we'll be working with RSpec!

As you can see in the lines 23 and 29, I'm mocking the response from Aws::DynamoDB::Client. This is needed because the save! method of the Webhooks::Github class is calling the DynamoDB client, and, because I don't have DynamoDB running locally, that's the easiest way to mock success and failure responses.

Building and deploying

Ok, let's say your application is ready to be deployed and you're excited to use your lambda functions. Once you have your Serverless framework settings file properly configured, you can deploy your app running sls deploy.

But, let's be curious and take a look at the file built by the framework: it's a zip file inside the .serverless folder with the name you set to service in serverless.yml. You will see that Serverless framework basically zip all the content of your project, including your tests, which are not needed in a production environment, and, since the dependencies of your project are not inside it, this zip file doesn't contain your project dependencies. So, basically, your lambda function will be successfully deployed but, won't work.

So, before deploying our project, we need to execute bundle install --deployment to switch Bundler to deployment mode. This way, Bundler will create a vendor folder inside your project with all dependencies. Great! Wait... All dependencies? We don't need development and test dependencies. No problem: bundle install --deployment --without test development.

Great, thanks Bundler! Wait again. As soon as you try to perform changes in the Gemfile, Bundler won't allow you to do it because you're in the deployment mode. So let's execute bundle install --no-deployment to switch back to development mode. Once you try to execute bundle install, you'll notice that Bundler is not taking care of the development and test dependencies anymore. Damn it Bundler!

Instead of executing just bundle install --no-deployment, we need to execute bundle install --no-deployment --with test development to make Bundler take care of test and development dependencies again.

Three commands to perform a single deploy. That's unacceptable! I really want to execute something similar to app deploy, and this looks very much like a rake task!

Now I can simply execute rake deploy. As you may notice, the first command of my deploy rake task is rm -Rf vendor, and I'm doing this because I don't want gems that were removed from Gemfile to be there. For a brief moment I tried to use --clean, but then Bundler started to warn me that's very dangerous, so it scared me a bit.

Please leave a comment if you know a smarter way to do it. I really appreciate that! I had hope that Serverless framework team would take care of that, but, apparently, they won't.

Last but not least, let's take care of the files that shouldn't be included in the deployment package. In this matter, Serverless framework team did a good job because, in the settings file (serverless.yml), you can set the paths that should be included and excluded from the packaging process.

package:
  exclude:
    - Gemfile
    - Gemfile.lock
    - Rakefile
    - spec/**

Logging

Not a big deal here but I was getting too many logging outputs while testing my code using rspec, which was messing a bit my testing outputs: I just want to see green dots. So, I needed to build something that (a) is simple as logging should be, (b) I don't want to initialize it (Logger.new(STDOUT)) every time I need to use it, (c) I want to silence it when running tests and (d) I want to see the logs in CloudWatch. That said, I built the following solution.

In order to log something, I just need to call Log.info "Something to log".

Next step

Obviously, my next steps are to continue working in my lambda functions, however, I already know that I will need to share some code across different functions, and I want to work on that before building new functions. Fortunately, AWS also provided a solution for that: AWS Lambda Layers. But this topic will be the subject of a future post.

Looking for a job?

If you're a Ruby on Rails Developer, DevOps Engineer, Python Developer or a Fullstack Java/Python Developer (all positions available for English speakers), and you live around Frankfurt am Main or you're willing to move, we have positions available at creditshelf.