ikura & nginx

N.B. This post is deprecated. For archival purposes, it remains here, but generally, it ought to be disregarded by readers.

At ikura, it’s rather important that our customers have many options when it comes time to white-list ikura’s service on their application servers. Your servers must only allow restricted access to your specified resources — access which ikura background jobs should solely be granted as wide-open endpoints could cause you unwanted trouble.

Continuing from our previous post about white-listing ikura at the application layer, we will now showcase how to restrict your endpoints when utilizing nginx.

ikura’s end

To start off, log-in to ikura, add your pool, channel(s), and select the timing options as needed. It only should take a minute. Do note that by default, your ikura background jobs will not begin until you’re good & ready.

Now, navigate over to ikura’s ‘dock’ page. From our FAQ, you can grab ikura’s current IP address which you’ll need in order to white-list our service in your nginx configuration.

Your nginx config

Usually, on a typical install of nginx, ‘/etc/nginx/sites-available’ is the directory that will host your server’s configuration file. For more on setting this up initially, check out this tutorial. For the purpose of configuring nginx so it works with ikura, here is a sample configuration named ‘all.config’ which you can refer to:

server {
  listen 80;
  server_name yoursite.com;

  location / {
    autoindex on;
    root /home/jimbo/var/www/yoursite.com;
  }

  location = /some/protected/path/dispatch.json {
    allow 127.0.0.1;
    allow XXX.XXX.XXX.XXX; # N.B.
    deny  all;

    proxy_pass http://127.0.0.1:8888;
    proxy_redirect   off;
    proxy_set_header Host            $host;
    proxy_set_header X-Real-IP       $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
  }
}

In the second ‘location’ Server Block clause, you’ll want to substitute XXX.XXX.XXX.XXX with the IP on-hand from a moment ago. And of course, take only the parts from ‘all.config’ that are pertinent to your situation.

With the ‘allow’ & ‘deny’ lines in place, everything you need for white-listing ikura is now configured. Simple.

You are just moments away from enabling ikura to dispatch SMS, perform daily email blasts, etc.

Testing & restart

After configuration is in place, you can test it & restart nginx to secure your changes. Usually $ sudo service nginx configtest and $ sudo service nginx restart, respectively, will get you where you need to be.

Then finally over at ikura, your channel will be raring to go. But by default, it’s inactive. You may activate it now to engage your service.