Tlaloc : Server and Cloud Management

Aztec God of the clouds, fertility and water.

In Aztec cosmology, the four corners of the universe are marked by "the four Tlalocs" (Classical Nahuatl: Tlaloquê [t?a?'lo?ke?]) which both hold up the sky and functions as the frame for the passing of time.

I thought this was an appropriate name for a Cloud Manager Application. :)

Tlaloc is being developped by me, Stéphane Paquin, in the context of my work at Kopel inc. This documentation should serve primarily to educate my co-workers and future replacements as to how things are auto-configured in our server room using this system.

Tlaloc at a glance

Tlaloc is a server and cloud management application, like Puppet, Chef, Nagios and Shinken, but somewhat different, all in one, without the complexities.

I think it's a bit more versatile than the average solution, it allows the integration with other programming languages on the Nodes (you can even develop your own recipes in your favorite language, if you wrap them in a Tlaloc recipe.). It's also a monitoring tool in the works, a message queue processing system and it's built from the grounds with security in mind.

For a detailed comparison with other server/cloud management solutions, see our own detailed picture

Oh ! And it's exploit-free. We went through great pains to design a system that couldn't be fooled, exploited or deliberately broken.

Tlaloc and it's components

Cluster Runner

The node agent responsible for running Recipes, either manually bootstrapping it, bootstrapping through a virtual environment, or through a cron/install job.

Repository(ies)

Storage space for recipes, packages, OS, installation files, source datafiles and some more. Tlaloc can use any kind of repository (sftp,ssh,ftp,http,https,S3, but it favors rsync for lighter transfers)

Recipes

Node installation recipes, for bare metal installations, Job recipes, Monitoring recipes, and Queued recipes.

Uniform class object model

Designed to support any platform through simple PHP class objects. Objects can be used in recipes, or anywhere else you seem fit.

Development plan

Started way back in the 90s, Tlaloc is currently developed by me, in my spare and work time. It has evolved much from an assortment of library tools to a fully encrypted automation system for cluster nodes.

History Log

  • Planned; Monitoring plugins derived from Nagios and OpenBSD's own Nagios plugins.
  • Planned; integration with the Crypto Chocolate Bot Automation system.
  • 2018-2019; many improvements in the internal libraries, real UTF8 handling, filename conversions, general code improvements and tighter cryptographic routines.
  • 2018; this website has been rebuilt from the grounds up.
  • Finalize the Amazon bootstrap testing using OpenBSD nodes. (thanks to Antoine Jacoutot for his helpful article; OpenBSD on AWS : An Unexpected Journey)
  • 2017.Q2; Complete revision of the Crypto implementation in the Message Queue system using HKDF and master keysets
  • 2017.Q1; Development of the Crypto class module, integration and adaptation for PHP 7.0+
  • 2016.Q4; Integration of the Queue class object and the Queue-Runner client API
  • 2016.Q1-Q3; Merging of the Queue System with the Tlaloc System
  • 2013; Development of some monitoring class prototypes (System, currently still incomplete)
  • 2012; implementation of the tri-state return values for indempotency scripting
  • 2006; Integration of a basic administrative website for managing Nodes, Messages, Monitoring and Assets.
  • 2002-2006; Recipe making using PHP, Q/A of the base objects
  • Add support for Linux-based OS flavors (always in progress, we don't use much Linux)
  • 2001; File object developed with redundant repository logic
  • 2000; User & Group objects developed for OpenBSD
  • 2000; QueryDB object borrowed from another project (of mine)
  • 1998-1999; Re-write of the whole engine for Unix shell and PHP. (I thought Perl is a bit too obscure for the common sysadmin)
  • 1995-1997; R&D Server automation through Queued messaging. First prototypes in Perl.