Tarantool Queues (Part 2): Authenticate This

DZone 's Guide to

Tarantool Queues (Part 2): Authenticate This

Learn about the practical nuances in Tarantool queues by implementing a Tarantool-based authentication server using queues.

· Database Zone ·
Free Resource

Image title

In this article, we’re going to implement a Tarantool-based authentication server using queues. It will solve a variety of tasks: maintain a user base, register new users (including confirmation code generation), authenticate users, delete accounts, etc. Its mission is to interact with many web applications (both services and microservices). That is to say, there will be no web server in it — as is usually the case in real working systems (especially miсroservices-oriented ones). As requests come to our service from all over the place, our web server can become a bottleneck in such a high-load system. So, to avoid any problems, we’ll place the queue server between an authentication service and the web services addressing it. The former appears as yet another Tarantool instance. You may learn the setup process from our previous article.

Step 1: Installation

We need a Linux-based virtual server (we used Ubuntu 16.04, though any distro may be used) and the latest stable Tarantool from the official repository. We’ve already mentioned how to configure and set it up but the complete documentation is available on the Tarantool downloads page.

To implement an authentication server, we will use the open-source tarantool-authman software provided by Mail.Ru (the repo has docs on how to install and launch it, so we won’t go into further detail about that). The repository has packages for CentOS and Ubuntu.


Using tarantoolctl:

$ tarantoolctl rocks install authman

Also available are .rpm and .deb packages:

# CentOS:

$ yum install tarantool-authman

# Ubuntu:

$ apt-get install tarantool-authman

There is also a third way to install it using the package manager LuaRocks, but we'll come back to this method in our next article.

Let’s proceed with making our authentication server. As we said before, there’s no need to add a web server. Web services (applications) typically work outside and can be designed using a variety of programming languages, which have connectors to Tarantool (in Python, for example). Web servers that these services run on, too, can vary (Apache, NGINX, etc.). Anyway, it doesn’t matter to us at this point; today’s task is to make a simple authentication server and to add a queue server to it. In our example, we'll run them on the same virtual Linux server, although in real life, they are likely to work on different hosts with the possibility of scaling (sharding, etc.).

Step 2: Implementing a Tarantool-authman-based Authentication Server

After installing and connecting the module, we will need to make an instance. For this, create a file like /etc/tarantool/instances.available/tarantool-authman.lua (or use the path where your distro is):

box.cfg {
    listen = 3302,
local config = {
   -- configuration table, please read tarantool-authman documentation for more details
auth = require('authman').api(config)

Then, as usual, let’s create a symlink in /etc/tarantool/instances.enabled, run an instance, and enter it:

$ ln -s /etc/tarantool/instances.available/tarantool-authman.lua /etc/tarantool/instances.enabled/tarantool-authman.lua

$ tarantoolctl start tarantool-authman
$ tarantoolctl enter tarantool-authman

Our authentication server at this stage is already working, although real projects will require some extra scripting. But as long as we do everything interactively, our authentication server will run together with the queue. It’s much easier to write complex software once.

Let’s see how tarantool-authman works. To begin, we register a user via their email address with confirmation code generation (in practice, this code is to be sent to the specified new user’s address). There are two API methods for this: auth.registration(email) and auth.complete_registration (email, code, password).

The authentication process itself also looks simple. Here, the auth.auth(email, password) method is used.

It is possible, for example, to fill in the user profile without any session via the auth.set_profile(user_id, profile_table) method.

With the auth.check_auth(session) method, you can use session data and get a user table with all of their information, while auth.drop_session(session) kills the user session.

The last interesting method here is auth.delete_user(user_id). It removes the account from the database.


This description of the tarantool-authman module's capabilities is far from complete. For instance, it can also recover the password generating the verification code (token) or perform authentication through social networks. This module can hardly be called a full-fledged authentication server — rather, it is a set of basic primitives (with a built-in database) that allows us to create and use such a server in our projects. Besides, it just helps make things "meatier" — it would be really hard to create the same software from scratch. As for Tarantool, it not only has advanced tools for us to develop complex distributed systems (combining a fast in-memory database with an application server, as we regularly remind you guys in our articles) but also a strong community supported by Mail.Ru where you can get a bunch of ready-made blocks for free to design and develop your own projects. In the next article, we will integrate the tarantool-authman and tarantool-queue capabilities so that our high-load authentication server won’t be choked by the flood of incoming requests.

authentication, database, queue management, queues, tarantool, tutorial

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}