Caching Rails assets with NGinx

Nginx is a very popular high performance web server. It’s very easy to configure and many Ruby on Rails developers are using it as a load balancer for Rails applications. Usually the setup looks like this:

Screen Shot 2015-08-18 at 10.13.19

Typically the rails application is running on Mongrel, Unicorn or Puma. These ruby application servers can deliver static assets (.png, .jpg, .js, .css) as well, but there are not really optimised for that. Nginx is much faster in delivering static assets like images, javascript and css files. Ideally your ruby application server should only handle requests to ruby controllers and generate dynamic content.

This is the Nginx configuration for load balancing between 2 ruby application servers, or any other application servers:

 
upstream unicorns {
  server 192.168.1.11:8080;
  server 192.168.1.12:8080;
}
 
server {
  listen 80;
  location / {
        proxy_redirect off;
        proxy_set_header Host $http_host;
        proxy_set_header X-Forwarded-Proto https;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

        proxy_pass http://unicorns;
    }
}

At Rails all static assets are delivered under the route “/assets/”. Now we will tell Nginx to cache files from “/assets/” for 120 minutes. For that we need this 2 lines at the beginning of our nginx.conf file.

proxy_cache_path /tmp/nginx levels=1:2 keys_zone=veye_zone:10m inactive=120m;
proxy_cache_key "$scheme$request_method$host$request_uri";

The first line defines the directory where the files for the cached asserts should be stored. In this case it would be “/tmp/nginx”. We define the name space “veye_zone” with 10 MB for this cache. The 2nd line defines the structure of the cache key, which has to be unique.

Now we can add another location for “/assets” to our configuration.

server {
  listen 80;

  location /assets/ {
        proxy_redirect off;
        proxy_pass_header Cookie;
        proxy_ignore_headers Set-Cookie;
        proxy_hide_header Set-Cookie;
        
        proxy_cache veye_zone;
        proxy_cache_valid 200 302  120m;
        proxy_cache_valid 404      1m;

        proxy_pass http://unicorns;
  }

  location / {
        proxy_redirect off;
        proxy_set_header Host $http_host;
        proxy_set_header X-Forwarded-Proto https;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

        proxy_pass http://unicorns;
    }
}

The 3 most important lines for the caching are these here:

        proxy_cache veye_zone;
        proxy_cache_valid 200 302  120m;
        proxy_cache_valid 404      1m;

They reference to the “veye_zone” cache, which we defined in the top of our nginx.conf. The 2nd line tells Nginx to cache everything with a response code of 200 and 302 for 120 minutes. And everything with a response code of 404 for 1 minute.

All HTTP requests to “/assets/” first will go to one of the ruby application servers, but the responses will be cached at Nginx for 120 minutes. All further requests to “/assets/” will not hit the ruby app servers, because Nginx can deliver the content from the cache.

The beauty at this setup is that it’s seamless to the deployment of the ruby application. The deployment process doesn’t have to copy the assets files to the Nginx server. Nginx is just automatically caching all assets.

Displaying errors from the backend systems in the UI

VersionEye can monitor your project file (Gemfile, package.json and so on) on GitHub/Bitbucket and notify you about out-dated dependencies, license violations and security vulnerabilities.

The process of fetching a file from the GitHub API is very time consuming and many things can go wrong. Doing this inside of a HTTP request/response cycle would mean to block the web process for several seconds or even minutes. That’s why this job is done by background workers. In the project detail view a “re parse” job can be triggered by hitting the “Re Parse Now” button. Until the background job is running a loading bar is displayed like on this image.

Screen Shot 2015-06-07 at 08.22.18

If the job is done the page reloads.

By dealing with external APIs many things can go wrong. Maybe the API is not reachable or there is another error and the project file can not be parsed. The background worker is throwing some Exceptions, but they never show up in the UI because the workers are running on completely different machines. That problem is solved now!

Here is a drawing of the architecture. Every square on the image is a different machine with his own IP address. They can even be in different geographical regions.

RabbitMQ-Architecture

VersionEye is using heavily RabbitMQ to distribute work. If somebody hits the “Re Parse Now” button, the request goes to a Rails controller of one of the web application servers. The Rails controller sends a message with the project id to RabbitMQ and returns immediately the response to the Browser. That takes only a couple milli seconds and after the response is processed the user can see that the background job is running. See picture 1 for that.

The RabbitMQ server can receive messages from web app servers, but also from a scheduler, which is triggering re parse jobs for projects with daily, weekly and monthly period.

There are several workers who subscribed to a specific channel on RabbitMQ. Some workers are responsible for fetching a users list of repositories from the GitHub API. Some workers know how to search for “supported project files” in a given git repository. And other workers are responsible for fetching a given project file from the GitHub API, parsing it and updating an existing project at VersionEye with the re parsed dependencies.

Every worker is specialised in doing exactly 1 job. The code for a worker is usually less then 100 lines. You can think of it as micro services.

Assume worker1 will get the job which just was triggered by the user. The worker tries to fetch the file from the GitHub API but something goes wrong. The GitHub API returns a error code and the project file can not be fetched. Some Exceptions are thrown and logged somewhere in some log files. Normally the worker would response to RabbitMQ that the job is done. But now the worker is storing error messages in the project object itself. That is a known pattern from ActiveRecord. If you try to persist an object with ActiveRecord and the operation fails it stores the error messages inside of the object. The error messages can be displayed with this command:

.errors.full_messages.to_sentence

The workers at VersionEye are doing it similar. The workers are storing error messages in the “parsing_errors” array of the project model. If this array is not empty, the elements are displayed in the project detail view, like here for example.

Screen Shot 2015-07-14 at 17.56.43

In the project overview page the projects with errors are marked with a “warn” sign. Like the first project in this example.

Screen Shot 2015-07-14 at 17.56.19

Now the users are getting feedback from the background workers. Possible reasons for this errors are:

  • The given URL doesn’t exist anymore.
  • The project file was moved.
  • The git repository was renamed.
  • The credentials for the GitHub/Bitbucket API are not valid anymore.

The most common reasons are the last 2 ones. If the git repository was renamed the VersionEye project has be removed and created newly again. If the credentials for the GitHub/Bitbucket API are not valid anymore then it can be fixed by going to settings and disconnecting from GitHub/Bitbucket and then connecting again to GitHub/Bitbucket. That they VersionEye is getting new API tokens for the logged in user.

This feature is quiet new, just a couple hours old. Feedback is welcome 😉