Tines - Docker compose architecture

Architecture overview 

Basic architecture 

Tines is a Rails application that uses a PostgreSQL database for its persistent data storage and Redis for its cached data storage and message queuing.

It features two core application containers: tines-app and tines-sidekiqtines-app runs the Rails server for web application hosting/receiving webhooks. tines-sidekiq runs background worker processes. Both containers read and write to and from the PostgreSQL database and Redis cache - they don't communicate directly, instead, they swap data and messages through PostgreSQL/Redis.

Both the tines-app and tines-sidekiq containers use the same tines-app Docker image with different entry points (start-tines-app and start-tines-sidekiq respectively).

The tines-app and tines-sidekiq containers both make requests to external services to run your automation stories.

The tines-sidekiq container may be optionally configured to periodically load new Action templates from Tines (at template-data.tines.com) and to send basic version and feature usage information back to Tines (at hq.tines.io).

tines-nginx container is usually deployed in front of the tines-app container to terminate SSL. Alternatively, any load balancer, load balancer service, or reverse proxy can fill this role.

Serving the web application 

A user's browser connects via HTTPS to the Tines web application via the tines-nginx container or an LB/reverse proxy, which terminates the SSL connection and connects to the tines-app container over HTTP.

Running Actions on tines-sidekiq 

The Tines product features 7 different types of automation "Actions", 3 of which cause Tines to connect to external services: IMAP, Email (SMTP), HTTP Request.

When a user "runs" an Action via the web application, a task is enqueued in the Redis cluster by the tines-app container. The tines-sidekiq container reads from this queue, reads related data from the PostgresSQL database and performs the Action, which may result in a HTTP, SMTP or IMAP request to an external server.

The data gathered from these requests is stored in an "event" in the PostgresSQL database.

Actions can also run as a result of an upstream Action running successfully, or on a schedule. When this happens, a task is enqueued in the Redis cluster by the tines-sidekiq container for each Action that will run.

Testing Actions on tines-app 

When "test" mode is invoked via the web application, the tines-app container directly executes the Action (rather than enqueuing it via the Redis instance for later execution by the tines-sidekiq container).

When this happens, the tines-app container may itself make a HTTP, SMTP or IMAP request to an external server.

Receiving webhooks 

An external service may post webhooks to the tines-app container through the same tines-nginx container or LB/reverse proxy used to host the web application.

When a webhook is received, the data is stored in an event in the PostgresSQL database. Further downstream Actions may be executed in turn by the tines-app container enqueuing tasks in the Redis cluster.

Was this helpful?