infrastructure

Ansible 101 - on a Cluster of Raspberry Pi 2s

Ansible 101 - Raspberry Pi Dramble cluster

Over the course of this year, I've acquired six Raspberry Pi model 2 B computers, and configured them in a cluster (or 'bramble') so I can use them to test different infrastructure configurations, mostly for running Drupal 8. All the Ansible playbooks and instructions for building the cluster are available on the GitHub project page for the Raspberry Pi Dramble.

Each Raspberry Pi has its own RGB LED board that's wired into the GPIO pins, so they're controlled by software. I can demonstrate different ways of managing the cluster via Ansible, and I finally took the time to make a video, Ansible 101 - on a cluster of Raspberry Pi 2s, which shows how it all works together:

Setting up GlusterFS with Ansible

NOTE: This blog post was written prior to Ansible including the gluster_volume module, and is out of date; the examples still work, but Ansible for DevOps has been since updated with a more relevant and complete example. You can read about it here: Simple GlusterFS Setup with Ansible (Redux).

Modern infrastructure often involves some amount of horizontal scaling; instead of having one giant server, with one storage volume, one database, one application instance, etc., most apps use two, four, ten, or dozens of servers.

Many applications can be scaled horizontally with ease, but what happens when you need shared resources, like files, application code, or other transient data, to be shared on all the servers? And how do you have this data scale out with your infrastructure, in a fast but reliable way? There are many different approaches to synchronizing or distributing files across servers:

Introducing the Dramble - Raspberry Pi 2 cluster running Drupal 8

Dramble - 6 Raspberry Pi 2 model Bs running Drupal 8 on a cluster
Version 0.9.3 of the Dramble—running Drupal 8 on 6 Raspberry Pis

I've been tinkering with computers since I was a kid, but in the past ten or so years, mainstream computing has become more and more locked down, enclosed, lightweight, and, well, polished. I even wrote a blog post about how, nowadays, most computers are amazing. Long gone are the days when I had to worry about line voltage, IRQ settings, diagnosing bad capacitors, and replacing 40-pin cables that went bad!

But I'm always tempted back into my earlier years of more hardware-oriented hacking when I pull out one of my Raspberry Pi B+/A+ or Arduino Unos. These devices are as raw of modern computers as you can get—requiring you to actual touch the silicone chips and pins to be able to even use the devices. I've been building a temperature monitoring network that's based around a Node.js/Express app using Pis and Arduinos placed around my house. I've also been working a lot lately on a project that incorporates three of my current favorite technologies: The Raspberry Pi 2 model B (just announced earlier this month), Ansible, and Drupal!

In short, I'm building a cluster of Raspberry Pis, and designating it a 'Dramble'—a 'bramble' of Raspberry Pis running Drupal 8.

Highly-Available PHP infrastructure with Ansible

I just posted a large excerpt from Ansible for DevOps over on the Server Check.in blog: Highly-Available Infrastructure Provisioning and Configuration with Ansible. In it, I describe a simple set of playbooks that configures a highly-available infrastructure primarily for PHP-based websites and web applications, using Varnish, Apache, Memcached, and MySQL, each configured in a way optimal for high-traffic and highly-available sites.

Here's a diagram of the ultimate infrastructure being built:

Highly Available Infrastructure

Highly-Available Infrastructure Provisioning and Configuration with Ansible

The following is an excerpt from Chapter 8 of Ansible for DevOps, a book on Ansible by Jeff Geerling. The example highlights Ansible's simplicity and flexibility by provisioning and configuring of a highly available web application infrastructure on a local Vagrant-managed cloud, DigitalOcean droplets, and Amazon Web Services EC2 instances, with one set of Ansible playbooks.

tl;dr Check out the code on GitHub, and buy the book to learn more about Ansible!

Secure your servers from Shellshock Bash vulnerability using Ansible

Now that all Server Check.in infrastructure is managed by Ansible (some servers are running CentOS, others are running Ubuntu), it's very simple to update all the servers to protect against vulnerabilities like Heartbleed or today's new Shellshock bash vulnerability.

For CentOS (or RedHat)

$ ansible [inventory_group] -m yum -a "name=bash state=latest" [-u remote_username] [-s] [-K]

For Debian (or Ubuntu)

$ ansible [inventory_group] -m apt -a "update_cache=yes name=bash state=latest" [-u remote_username] [-s] [-K]

If you have a different method of patch management, or you need to apply the fixes manually, then this method won't apply—but for most infrastructure using normal system-provided packages, using the above commands will get the fixes with minimal effort.

A little further explanation:

Simple Git-based multi-server deployments

Ansible is used to manage most of Midwestern Mac's infrastructure and deployments, and while it's extremely easy to use, there are a couple situations where a project just needs a little code to be updated across two or more servers, from a central Git repository, or from one master application server.

All Git repositories include a hooks folder, which contains sample git hook scripts. Inside this folder are a series of sample hook files like post-commit.sample and pre-rebase.sample. If you add a shell script of the same name as any of these files (excluding the .sample) to this folder, Git will run the script when the particular action runs (e.g. git will run a post-commit script after a commit).

Using Ansible Galaxy

Ansible Galaxy Logo

Ansible Galaxy was launched just a few short months ago, and already has over 500 roles maintained by over 225 users. The idea behind Galaxy is to give greater visibility to one of Ansible's most exciting features: reusable Roles for server configuration or application installation.

Galaxy is still in beta, and likely will be for a while longer, but if you have Ansible 1.4.2 or later installed, you can use the ansible-galaxy command to get started.

Easily manage Apache VirtualHosts with Ansible and Jinja2

Server Check.in's entire infrastructure is managed via Ansible, which has helped tremendously as the service has grown from one to many servers.

Ansible Borg Cow
cowsay and Ansible were made for each other.

One pain point with running Apache servers that host more than one website (using name-based virtual hosts) is that the virtual host configuration files quickly get unwieldy, as you have to define the entire <VirtualHost /> for every domain you have on the server, and besides Apache's mod_macro, there's no easy way to define a simple structured array of information and have the vhost definitions built from that.

Pages

Subscribe to RSS - infrastructure