Code4Lib 2015 - Ansible & Docker

This year, instead of going to Computers in Libraries, I'm attending Code4Lib.  Code4Lib is a community of people interested in the intersection of computer programming and libraries.  It seemed like it could be different from Computers in Libraries and touch on subjects and get into detail that I've occasionally felt lacking at Computers in Libraries.  Plus it provided an opportunity to go somewhere other than Washington D.C., as Code4Lib is in Portland for 2015.

The conference proper runs Tuesday, February 10 through mid-day on Thursday, February 12, but I started out by attending two pre-conference half-day sessions on Monday, February 9.

Ansible

The first program was on Ansible.  Walking into the program I really didn't know what Ansible was, but the title of the session "Replace Yourself with a Painfully Complex Bash Script...Or Try Ansible" appealed to me.

On Linux systems if you need to write programs used for system maintenance you typically use a shell scripting language, and the most common shell (command line environment) in use there is called BASH (Bourne Again SHell -- a pun on the fact is was an improvement over a previous shell called the Bourne shell).  BASH shell scripting actually made the news in 2014 when it was discovered that it was possible to pass information to a Linux server (typically a web server) in such a way that an outsider could get code to run in a BASH script without the system administrator knowing about it.  This vulnerability (just one of the named major security crises of 2014) was called Shellshock.

Shellshock really doesn't have anything to do with Ansible, but it was a problem that came about because BASH is so complicated and powerful.  Unlike most vulnerabilities of 2014, the bug that created Shellshock wasn't a bug -- it really was a feature that someone had added into BASH in the distant past when no one imagined that scripts running in it would be accessible in any way from the outside.  People forgot about the feature after a while and then someone figured out that this feature was still present and could be used to attack a system.

Because of its complexity, BASH scripts can be difficult to write and difficult to maintain.  If you have to maintain a lot of different Linux systems and there are a lot of scripts that you need to write to keep your job "easy" it can get complicated fast.  Ansible is an answer to that problem.  It's designed so that you can create easy to create, modify and comprehend structures and scripts for the maintenance of (typically) multiple Linux systems.  You create an Ansible instance on a central Linux server and you can write scripts that can be used to maintain that system and other systems that the central system can connect to.

I didn't immediately think of a case where I really need Ansible at the moment, but I can definitely see that it might be a good way of dealing with certain kinds of problems in the future.  I'm currently maintaining 5 virtual Linux servers and there could be many cases where I want to make sure that changes are made uniformly on multiple of them, and Ansible would make that easy to do.

Docker

Docker is something that I've wanted to learn about for a while, so I'm glad that I went to this session as I learned quite a bit.  I'm not sure how much others learned and the session was kind of a mess, for a variety of reasons, but I got some value out of it.

In the Linux world Docker is one of the big hot topics.  It is a virtualization technology, kind of like VMWare or VirtualBox.  Those technologies allow you to run a computer within the context of a different computer, allowing you to buy one big server and run a bunch of little servers on a single piece of equipment, or allow you to run Windows within the context of a running MacOS installation.

A big reason to do this is because it's a bad idea to have (in the world of servers particularly) too many eggs in one basket.  If you make one big server that does everything, if something goes terribly wrong with one of those things it can take everything else down with it.  If you make a bunch of tiny servers with dedicated jobs and something goes crazy with one of them, you just lose that one server.

Docker allows you to take this concept with servers on further.  With it you can install, configure, and run an isolated instance of a service within the context of a single Docker container.  This container can be isolated from the rest of the system, so the amount of damage it can do is severely limited and it can't step on the toes of any other Docker containers.  Using Docker allows you to put more stuff on a given server without worrying too much about what's going to happen to everything in container B when someone hacks into the product that is container A.

The problem with the session was that setting up Docker is a little resource intensive.  You have to download and install Docker and then you have to download and install all of the components Docker needs to make the containers that run the services that you want to be running.  The wifi was slow  before the ~50 people attending the Docker program started trying to download all of its components, and that's after the presenter jumped through hoops to try and reduce the drain that this process would have on the wifi.

In my case I was able to use a 4G hotspot instead of the Wifi, and then I connected to a computer running remotely to try Docker installation and configuration.  This put a (light and hardly noticeable) drain on the remote system that was fast while keeping me off of the very slow local wifi.

I was then able to do some basic testing of Docker to see how it worked and get a basic idea of how one might use it.  It is an interesting and compelling technology and I look forward to making use of it in the future.