Faster than Light

An ansible is any one fictional device which allows instantaneous communication across interstellar distances, coined by the author Ursula K. Le Guin in the 1966 science-fiction novel Rocannon’s World.

While there are ways to create effects that move faster than light, even just regular-speed dissemination of information can be quite tedious. Have you ever wondered what needs to be done before a computer can serve a website? Have you ever wondered what needs to happen before something brings The Final Outpost to your browser?

  • The domain “finaloutpost.net” needs to be registered with a registrar (or, more commonly, a third-party provider that will register the domain with the registrar).
  • Domain name services need to be configured for “finaloutpost.net” which will then be able to serve information about where “finaloutpost.net” actually is on the globe.
  • A physical or virtual machine somewhere has to be known by an IP address, which is to computers approximately what postal addresses are to human beings. (Cloud hosts typically give you both, but if you’re an enterprise, you may purchase physical machine and IP addresses separately.)
  • The domain name services need to connect “finaloutpost.net” to the IP address, so that when your browser asks “Where is finaloutpost.net?”, there is an answer like “1.2.3.4”.
  • The IP address needs to be routable. Remember when Facebook was down a few months ago? That happened because their IP address stopped being routable. You can imagine that to be as though your post office had forgotten where your street was. The street is still there and you still live there, but none of the mail is reaching you. The protocol that governs this is called BGP (Border Gateway Protocol) and exciting things can happen when this is misconfigured.

Whew, that’s a lot already! We skipped over the necessary hardware, but even so, this is just the beginning. Now we have a computer somewhere that your browser talks to whenever you type “finaloutpost.net” into it.

The first thing it will say is “ERR_CONNECTION_REFUSED” because there is no web service yet, let alone any content.

So we need to configure a bunch of things on the machine:

  • User accounts for our developers to allow them upload things on the machine and configure it. This typically involves adding “SSH keys”, which may be the most magical thing human beings have invented1.
  • The machine should probably be locked down so it isn’t easy to hack. Default settings that hosts supply are usually optimised for ease of use, not for security. This requires tweaking a bunch of configuration files, e.g. those of the SSH service, and restarting the affected services.
  • A web service. This is software that will talk to browsers on behalf of whatever is on your machine, depending on how you’ve configured them.
  • The corresponding configuration.
    • Your browser will try to connect to the site on port 80 if you try to navigate to “http://finaloutpost.net” and on port 443 if you try to navigate to “https://finaloutpost.net”. You can picture ports a little like the doorbells on a given apartment block, except this one is mostly empty, and most of the doorbells do nothing (ERR_CONNECTION_REFUSED). Installing a web service will make sure several of these apartments are inhabited, but you need to specify which.
    • What is the web service supposed to do with a connection? Well, it might serve a white page with only the words ‘Hello, World!‘ on it, or an image file, or a list of files you can download. For The Final Outpost, we want it to serve a dynamic website coded in PHP (plus some image files). Thankfully, PHP is just a bunch of text files in a folder, so as long as those have been uploaded to the machine, we can tell the web service configuration to serve those files.
  • But wait, if we try to serve those files, all you get to see is text files. We also need to install the PHP interpreter on the machine and tell our web service to run the files it’s serving for “finaloutpost.net” through PHP, plus any PHP extensions needed by the website.
  • At this point, the website loads an error message that something went wrong. There’s no database! We need a database. So we install a database service (MariaDB, the open source successor to MySQL, is popular for small projects).
  • We also need to set up a user to connect to the database with.
  • And no database is very useful without a schema and tables. If you’re unfamiliar with these, picture a library – the schema is something like a book shelf labelled by topic and the tables are the volumes of books in the shelf.

At this point we finally have a somewhat functional website. But boy, those were quite a few steps. This is all easy enough to do when you’ve got a weekend to kill and are setting up the site for the first time… but what happens if your website dies?

Well.

Maybe whatever hosting provider you use (hopefully it isn’t you!) has backups. Maybe you can restore the entire machine from backup. Many cloud providers offer backup services for a small fee – even Linode, which provides almost no management services for the machines it hosts.

But maybe you never thought about backups, or something is wrong with the backup as well – for example, maybe the machine died because it ran out of seconds and restoring it from backup will just let it die all over again.

Now what?

You can of course go through the effort of setting everything up manually again. For a site like The Final Outpost, this is not terribly painful, but it’s not something you want to have to do while panicking about your users’ downtime experience. You might forget something important, like setting the system timezone to what it ought to be.

Several decades ago, system administrators decided that machine setup should be repeatable. The concept of “infrastructure as code” was born. The idea is that, each time you want to manually add something to a machine’s setup, you instead write it into a configuration file, and use some software to turn that into things that happen on the machine: Install the web service, install the database, install user accounts in the database, install the PHP interpreter, et cetera.

Some very popular methods of managing machines via software is Puppet, Chef or Vagrant. But a favourite of many system administrators @pinkgothic has worked with is the dead simple system offered by Ansible.

As far as infrastructure as code goes, Ansible offers the bare minimum functionality. In several cases, you may need to do low-level actions like executing commands directly on the machine, instead of using a pre-existing abstraction.

Its great benefit is that it runs on the developer’s computer, minimising the setup that needs to be done to a blank machine before Ansible can be used to set up the rest.

In using Ansible to setup for new The Final Outpost infrastructure as we work on the Big Recode Project, in theory we could at least recover to a functioning machine environment (albeit not the content of the website without a separate backup2) within a few minutes of work. All that would need to be done is to setup the user accounts on the machine – Ansible would create the infrastructure for us:

  • Add user accounts (beyond the initial user account)
  • Configure machine security
  • Install a web service
  • Configure the web service
  • Install a database service
  • Add users to the database service
  • Install the PHP interpreter
  • Install any PHP extensions needed by the site

In any stressful situation, not having to remember those precise steps is a great blessing.

Our Ansible configuration files live alongside the The Final Outpost PHP code in our repository. Not only do they help us recover from potential disasters, but they also serve as documentation: What is installed on our machines?

With Ansible, we’ve improved our development documentation and our peace of mind.

  1. SSH keys consist of a private key and a public key. The private key, as the name suggests, is meant to be private. It’s a secret no one should ever learn of – note that this makes them quite unlike a password, which you will type into websites to get access. The public key, meanwhile, can be distributed promiscuously. The exciting part is that the public key can be used – without ever comparing it to the private key – to prove that a given person owns the private key. This is called asymmetic cryptography, which was effectively discovered when humans sat down and tried to prove that all mathematical operations are in principle reversible, only to find to their great surprise that this is not, in fact, the case.

  2. To be clear, there will be a separate backup, but it is not Ansible’s job to put it onto the machine.