Local configuration

The configuration on my local machines (as on my remote machines), I tend to manage using configuration management systems (CMS), like puppet, Ansible or Chef.

Years ago when I was learning Puppet for work, it seems a good idea to also manage my local configuration with puppet.

I have written a lot of code during the years for Puppet, configured Hiera to manage the configuration for different hosts and ran the puppet client on the local host to deploy the whole catalog each time.

That worked quite well for me, but after a year or two it started to fall apart. This was mainly due to shifts in how puppet continued to develop, changes to the client and me not keeping up with the latest and greatest on my local workstation (I usually prefer running workstation compared to one that is always at the edge and needs fixing).

When a new host came into the spiel (like reinstalling a just a new laptop), those usually got installed with a newer version of the OS and therefore also had a different puppet agent deployed.

While my configuration still was identical on the hosts, suddenly changes in the packages, tools and the puppet agent started to demand my focus: The complexity increased, while the gain stayed the same. That’s why I started a while ago to address the issue with the local agent and use Ansible instead of Puppet for the local configuration.

Given that the premise of Ansible also has a different goal (state configuration vs. procedural configuration), it also is agent less and will not require to keep up with updates for any agents.

So a while ago I started to migrate the Puppet modules into roles and playbooks for Ansible. That also worked great.

My current workflow to configure a machine looks like that:

bash alias -> run ansible-playbook -> configure machine

The bash_alias takes some parameters, e.g. the name of the component I’d like to configured. I’ve called the alias ap ( a nsible-p laybook ) to make it faster. So to configure the basic environment, I type something like this:

ap environment

This playbook then will deploy basic files and directories.

Any other specific requirements will have their own playbooks, like ssh which deploys my keys and configuration for the ssh agent.

The alias also takes the job of finding the right playbook and loading any required variables from the Ansible code repository.

The playbook run is just a play, standard playbook run against the local host. The main playbook is always the same: deployment.yml, which handles the loading of variables (vars/<string>.yml) and loading the target playbook (include: playbooks/<string>.tasks.yml. Instead of running the playbooks directly, this filters them through the deployment.yml and saves me mainly writing tasks, like the head of the common playbooks, including fact gathering, loading variables, etc.

When it comes to the machine configuration, I had to optimize a bit as well to avoid me writing the same code over and over again. There are som common tasks shared among the most applications:

# Create directories # Create/deploy files # Install software

Especially the handling of files turned out to show up again and again. So it got outsourced into a role which then only gets some parameters to deploy the files and directories where necessary.

Software installation is handled by the playbook software.tasks.yml.

ap software

That is basically the current local deployment scheme I use on a couple of machines. Since the whole Ansible code is in a code repository, I can easily share it on my hosts. I’ve also a playbook for the GIT repository configuration on my hosts:

ap git

This updates all my GIT repositories as well as the configuration repository in a matter of seconds.

If anybody has a smoother way of configuration and keeping all the hosts in line, please let me know. I’d like to hear about that.