/ansible-packages

Overengineered package selection framework.

Primary LanguageJinjaGNU Affero General Public License v3.0AGPL-3.0

packages

Travis CI test-suite Ansible Galaxy Platforms GitHub Tags GitHub Stars

Overengineered package selection framework.

This role allows you to select/manage packages over a heterogeneous set of hosts using Ansible.

It was written to allow to have the maximum level of flexibility in regards to selecting which packages should be installed on which host. Normally Ansible works by making host groups in your inventory and configuring the packages to install for those groups. This has certain downsides when the complexity increases. For example, imagine that one of those hosts runs a different distribution/OS. Also, when you have groups of packages in the order of hundreds (to keep it generic), you would probably mess up your Ansible inventory and your configuration would be distributed over hundreds of files. Also this approach would not be practical because seeing all those package groups which apply for a given host is not easy to understand when you just want the big picture of software installed on this host. Therefore this role puts its focus on packages, groups of packages and classes of hosts while allowing to overwrite package names to match the naming used by different distributions or versions of distributions.

Why make it that complicated?

Well, it started when I found more and more nice software in Debian repositories combined with the need to install/provision different kinds of systems with a certain subset of the software I know/have tested.

Those different systems include:

History

Before I knew Ansible, I had a shell script which asked me which categories I wanted to install. Now that I know Ansible I have something slightly more advanced 😉

Variable prefixes

All variables are prefixed by the name of this role to avoid conflicts.

Furthermore, there are a number of variable namespaces:

  • single: Name of a single package defaulting to the name in Debian stable or Debian testing.

  • group: A set of packages which fit in the same topic.

    • core: CLI only, does not require X

  • class: List of all packages for a specific class of host.

  • deploy: Options related to the installation and removal of packages as provided by the package management modules in Ansible.

It is preferred when group names match Debtags for the packages they group together. For example field.

Variable suffixes

For group variables, certain suffixes are defined:

  • minimal: Minimal set of packages of the group.
  • basic: Basic set of packages of the group (including minimal).
  • additional: Additional set of packages.
  • auto: Automatically added packages based on other parts of your inventory. For example, when the host is also part of the debops_service_x2go_server host group, some packages might be added additionally based on what other packages are installed.
  • full: Union of the minimal, basic and all the additional sets.
  • extra: Extra set of packages not included in full.

How to deal with the abstraction this role introduces?

There is a export feature available which you can use to generate package lists for the different classes. Furthermore you can keep those lists under version control so you can see what a change to a package group is resulting in for the different classes and if that is what you intended.

Check the example playbooks to get started.

Role variables

Check the defaults/main.yml for a list of all default variables and package presets available.

Requirements

This role makes extensive use of some recently introduced features of Ansible 2. One of those features, namely iterating over included tasks multiple times with the when_* statement had a bug in v2.0 so this role requires at least Ansible 2.1. Furthermore, the packages__name_remapping_by_vars feature is based on the ability to update Ansible variables in place. This does not seem to work on Ansible 2.2. Either use Ansible 2.1 or 2.3.1.0 or later.

Additionally, this role uses features recently introduced in Jinja2, namely the equalto filter which was released with Jinja 2.8. Jinja 2.8 is available in Debian Jessie Backports.

Related projects

  • debops.apt_install

    A more focused and easier to use Ansible role for installing common software for a Debian-based server environment. @ypid uses this role in conjunction with ypid.packages so both roles complement each other.

  • abe-metapackages

    Nice setup of meta packages for Debian. It has been an inspiration for this Ansible role. The reason @ypid has decided not to use meta packages to select packages was because of the limited flexibility compared to Ansible. Ansible facts allow ypid.packages to automatically select packages based on attributes/facts of the hosts.

  • external-test-dependencies of phoronix-test-suite

    Other projects also deal with the different package names across distributions. phoronix-test-suite has a nice collection.

  • pkg-map element of the diskimage-builder from openstrack

    Another way to deal with distro specific package names.

Installation

This role requires at least Ansible v2.3.1. To install it, run:

ansible-galaxy install ypid.packages

To install via git, run either:

git clone https://github.com/ypid/ansible-packages.git ypid.packages
git submodule add https://github.com/ypid/ansible-packages.git ypid.packages

Authors and license

packages role was written by:

License: AGPLv3

README generated by Ansigenome.