Introducing ikura workers
What’s important when coming to ikura for the first time, is understanding some terms & getting comfortable with the basics.
First, in order to talk about things, let’s get to know names.
To use ikura, your web application needs resources — URI end-points that execute the work you want to be performed at some interval.
So, let’s say you have a script that lives at ‘https://foobar.net/cohort-new.json’; the following is what ikura digests that as:
- ‘https://foobar.net’ is the pool;
- ‘/cohort-new.json’ is one of that pool’s channels.
The relationship between the two isn’t complicated, but there is some things to know about both parts.
Quite simply, a valid pool is just the protocol (‘http’
or ‘https’) & host (minus any path like ‘/’). It can be an IP,
a domain with any number of sub-domains, and of course you can
specify any ports. Once a pool has been created, it can have
as many channels as you’d like. You can think of a pool as the
parent, with the children being the channels. For anyone
familiar with Rails conventions, a pool
and a channel
belongs_to a pool.
The valid structure of a channel is quite liberal; so long as a channel leads with a forward-slash (e.g. ‘/path/baz.d’), then you’re in the clear. Channels require a timing component assigned to them. For example, you may want your channel to be called every five minutes; or randomly within each hour from nine-to-five in order to simulate a slight human-like behavior. It’s up to you.
So, a pool combined with a channel comprises one of your web-application’s resources.
By default, once a channel & parental pool is created, the ikura worker is inactive for your protection. The ikura worker won’t be started until you activate it via toggling the obvious ‘checkbox’ next to it. Once you do, ikura will call that resource reliably, forever, until you toggle it inactive once more.
So, that’s the breakdown of the most basic ikura set-up. This shouldn’t be difficult to get correct, but we wanted to spell it all out, here, nonetheless.