Table of Contents
ansible
Ansible is a configuration management system which uses a push service to manage the configuration of remote systems from the ansible server (unlike, for example, puppet, which is a pull service triggered from the client end). The only requirements on the client (managed) systems are that they:
- have a python interpreter installed
- can be SSHed to (preferably by public key authentication, but passwords can work too)
- can be SSHed to by root, or by a user with sudo rights
Ansible is based around the concepts of:
- tasks, which are individual actions performed on a remote machine (such as installing a package, or creating a user)
- plays, which are collections of tasks, performed in order
- playbooks, which are collections of plays
- inventories, which define values specific to particular servers or groups of servers, and which can be used within tasks to configure different systems in different ways, without the tasks being specific to different systems
- deployment files, which are files which get copied to remote systems (and then possibly modified according to inventory contents)
Background
I find ansible a very nice idea in principle (there will be a "but" a bit further down…):
- it has minimal requirements for the target systems:
- connecting by SSH is something I wouldn't even consider building a machine without
- SSH authentication by public key is just so standard that using passwords is pretty deprecated these days
- python is either a standard thing to find on a freshly-installed machine, or else it is so simple to add that it's probably the only thing you might need to do before you can manage a system using ansible
- I prefer its push model where the ansible server tells the client systems what state they should be in, and issues the appropriate commands to get them into that state, compared to the pull model of, for example, puppet, which requires you to run the client service on each target machine either manually (which is tedious) or as a cron job (which means you have little idea when any of your servers are going to update themselves)
- the idea of consistent package and configuration management is in itself just very satisfying :)
But...
Ansible, as I say, is a nice idea, but:
- it is very slow at connecting to, and running commands on, remote machines (compared to, for example, using a bash script and commands like SSH and rsync)
- this is sufficiently problematic that a completely independent group of programmers have come up with Mitogen, which speeds things up tremendously
- it lacks some amazingly obvious features, for example:
- you cannot rename a file
- you can create a file, you can delete a file, you can find out whether a file exists, you can modify the contents of a file, you can add to the contents of a file, but you can't rename a file
- the apt command supports "allow-unauthenticated" for installing packages which fail authentication, but there is no way to perform the equivalent of an apt-get update with "allow-insecure-repositories", so the package manager may not even know that there is a package available to install
- you cannot nest loops without hiding the inner loop code in a different file
- ansible has a pretty odd approach to performing loops - the loop variable is always called item, and there can only be one of it. If you want to have a nested loop, you have to write a loop which executes code from another file, and then in that other file you write the second (inner) loop
- the output is incredibly verbose, with no way I've found so far of telling it "just tell me the important stuff and keep quiet about the rest"
- you can actually turn up the verbosity, but considering that it starts from what in most applications would probably be -vvvv it's amazing that you can't turn it down
- the output by default is in a wild variety of colours, including for example dark blue on black (which is literally unreadable) and also red on black (which, unless my eyes are distinctly different from most people's, is very uncomfortable to try reading)
- fortunately there is a config file setting nocolor=True to make the output monochrome
- tasks are reported in the output, not when they commence, but when they complete - this can lead to puzzling delays in the output if you've got, for example, a reboot in there somewhere, because ansible doesn't tell you that it's doing a reboot until the machine has come back up again (or failed and timed out, which takes even longer)
Go up
Return to main index.