Automation

In the computer world, automation has always been the magic buzzword. Oh! I’ve automated my backups yesterday, pat on the back, we’ve written our first useful script.

Fabric-chain automation doesn’t differ much from computer automation. There are hardware differences, but the software remains the same. Computer automation on the other hand has introduced a number of important layers, which today, are almost accessible to all.

Typical automation layers that we find in IT today:

• Configuration management a.k.a. SysConfig (a form of automation, see Puppet, Chef, Ansible, Tlaloc)
• Identity and ticket management (or in its lieu, distributed user replication, ADS, LDAP, Kerberos)
• Development and Application management, in the sense that its a form of manual automation to manage application deployments, source changes and quality control. Source-control solutions basically. Back by popular demand we also find source compilation automation being predominant in the crypto-currency world.
• Software Defined Networks (SDN), which allows automating network segmentation and integrates other automation tasks at the switch level. (security, filters, anti-virus, etc..)

And if your enterprise is, or is thinking of getting into this sort of thing;

• Job management, usually centralised on a Message Queue or Message Scheduling system of sort.
• IDE data exchanges, these are usually processed in a message queue format (either locally or through a VAN).
• Event-driven data automation, typically in brokerage firms, banks or trade networks.

As of this writing, Feb 2018, there exists software solutions and integrated packages for most of these elements, yet no enterprises have managed to capture the vertical market that encompasses all these elements, and no publisher has worked on an interoperable standard that might tie in cryptography across these different layers.

So, roll up your sleeves, I’ll teach you how to do all this, for free, and easily.

I’ll also attempt to detail as much of the software’s out there, for comparison and better understandings. And perhaps why my own code kicks ass in comparison.

Windows vs Linux

We do not wish to enter this debate within this book. The methodologies presented here actually function across both worlds thanks to some nifty programming if you’re re-using our distributed APIs. But it is true that under normal circumstances, a bridge must be made at different levels between these 2 environments. Cryptographic routines might differ between hardware platforms, time synchronisation can raise other issues, OS-bound database synchronisation (Users, Crons, etc) can be difficult to translate between systems, and so on. We attack this “problem” with 2 approaches in this book. Firstly, we use a language, PHP, which is equally accessible on all platforms and encapsulates many of the kernel functions behind PHP calls. And, using a System Configuration API (Tlaloc), we achieve to encapsulate several OS related objects such as System, File, Users, Packages and Services. So, using the recommended methodologies, language and classes presented in this book, you’ll save yourself a monster headache of integration.

Tlaloc vs Puppet, Ansible, Chef

The reason we’ll use Tlaloc as our reference for System Configuration is that it is written in PHP by the same author, integrates seamlessly in our current proposed framework, and can be executed within proper security guidelines, anywhere.

Puppet and Chef require that a master node be offering recipes and/or pushing system configuration to target nodes through the use of elevated privileges, remotely. This somewhat defeats the purpose of proper security, where an elevated account should be executing, locally, system configuration tasks and not be allowed remote access. Tlaloc works in the later way. It’s also a benefit for horizontal-scaling, as Tlaloc never depends on one central synchronisation node.

Furthermore, Tlaloc allows us to self-configure local execution nodes within our Bot environment. Something that can be done with other System Configuration systems, but in a very complicated fashion. (You either have to install everything every Bot will need on your cluster, or package its dependencies with each Bot, and even include Process distribution logic in your recipe making. Or figure a way to instruct your recipe server during Bot execution to make adjustments on the local node. Erk!).

Try the methods and objects detailed in this book, you might like it.

I’m really not trying to cross-sell my stuff, but honestly, I’ve been maintaining a lot of class objects of my own, for my own development, and I’ve always focused on security first. Coming from the Internet Hosting domain, I’ve always been fond of automating massive clusters of servers. Tlaloc was my way of doing it since the beginnings, and, to me, until proven contrary, remains the easiest method to manage server configurations; both bare metal and virtual.

Perhaps I’m getting old and biased, but every time I try to switch over from one of my personal APIs, I encounter blatant problems, for which the solutions are better designed in my own APIs. Of course, I’ve never taken to rewriting an SSH client or an entire cryptographic library, my APIs are mostly wrappers that force a proper use of said objects. But then again, why bother re-writing complex and proven stuff, when our focus can be turned to more lucrative ends. Tlaloc was my way of recovering a lucrative hosting business on my own, and with the advent of cloud computing, became my ally for managing deployments. Today, it’s libraries will prove more than useful for merging System Configuration, Monitoring and Automation together on baremetal systems. Something that no system takes into account today. 😉

Read on, we discuss the different mechanisms for automating systems in general