Home

Awesome

ansible-util

Manage basic Ansible requirements and provide default configuration values for roles developed at Silpion.

Synopsis

- name: Maintain basic Ansible requirements
  hosts: all
  roles:
    - role: ansible-util
- name: Maintain basic Ansible requirements
  hosts: debians
  roles:
    - role: ansible-util
      util_template_use_cow: false
      util_action_become_enable: true
      util_action_become_user: root
      util_action_become_method: sudo
      util_local_action_become_enable: true
      util_local_action_become_user: root
      util_local_action_become_method: sudo
      util_persistent_data_path_local: /path/to/shared/local/directory
      util_persistent_data_path_local_mode: 2777
      util_persistent_data_path_local_owner: shared_user
      util_persistent_data_path_local_group: shared_group
      util_persistent_data_path_remote_mode: 755
      util_persistent_data_path_remote_owner: remote_user
      util_persistent_data_path_remote_group: remote_group
      util_module_get_url_timeout: 12
      util_module_service_manage: true
      util_module_service_allow_reload: true
      util_module_service_allow_restart: true
      util_package_state_debian: installed
      util_package_list_custom:
        - foo
      utiL_apt_cache_valid_time: 3600

Description

Role for base configuration of Ansible roles developed at Silpion.

Any role developed at Silpion uses util configuration variables as default for their own variables, e.g. ansible-java role has the following default configuration:

This role further implements common requirements for Ansible itself and provides earliest access to manage EPEL on RHEL based systems, e.g. manage SELinux related topics.

Dependencies

silpion.util role depends on the silpion.lib role. This is configured for the ansible-galaxy install command in requirements.yml.

NOTE: Ensure silpion.lib role is getting installed as silpion.lib. There are hardcoded references to this name.

# Install silpion.lib role with ansible-galaxy
ansible-galaxy install --role-file requirements.yml

Compatibility

Starting with version 2.N this role drops support for includable tasks, e.g. _get.yml or _put.yml. These are now implemented in silpion.lib role, which follows being a library better than this role ever did and ever will.

Requirements

Role Variables

Mentioned above most of these variables are defined to configure downstream roles. Any downstream role (regarding util and lib) should use defaults based on variables in this roles defaults configuration. That means:

silpion.lib uses defaults based on silpion.util. Any Silpion role uses defaults either based on lib or util, which effectively means that any role should be configurable with variables from silpion.util.

If this is not the case in downstream roles this is considered a bug and we are most happy for filed issues or pull requests.

General configuration

util_init_system

Roles supporting a various number of operating systems and versions do require to know what init system to configure for services. The util_init_system variable allows to hardcode that on inventory level for a specific project and is configured dynamically otherwise, e.g.

util_init_system value is written to local facts accessable with ansible_local.util.init.system. This fact may get used in other roles to ease configuration of service management.

The following values are supported (and therefor required):

init system configuration

Init systems today have different requirements when it comes to service deployment, e.g. SysV requires init scripts to be executable while upstart and Systemd discourage this.

util provides the following additional facts for service configuration.

These can be configured/hardcoded with the following variables and are configured dynamicallly otherwise, e.g.

action modules

This role makes the become framework configurable for local_action and action modules.

Persistency

Data persistency is now managed in silpion.lib role, where

The following variables are used in silpion.lib role as defaults for the persistency paradigma.

local

remote

modules

The following variables are used as global configuration options for Ansible modules in general.

ansible_os_family == 'Debian'

ansible_os_family == 'RedHat'

These variables are used to control EPEL installation on RHEL based systems.

Local facts

This role distributes various variables as local facts for third party roles to use.

The role tries to discover most of these facts, but they can be manually set using the corresponding variables. Check variable documentation above for details.

All facts are prefixed with ansible_local.util so a sample access path could look like this: ansible_local.util.init.system. The table below omits this prefix.

Fact nameFact descriptionVariable nameDistributed when
general.role_versionutil role versionlookup from vars/main.ymlalways
general.template_use_cowWether the cow is used for templatesutil_template_use_cowalways
general.package_stateDesired package stateutil_package_state_{{ ansible_os_family}}always
general.persistent_data_pathPersistent data pathutil_persistent_data_path_remotealways
init.systemInit system typeutil_init_systemalways
init.service_dirInit system service files directoryutil_init_service_diralways
init.service_modeInit system service files modeutil_init_service_modealways
modules.get_url.timeoutTimeout for the get_url moduleutil_module_get_url_timeoutalways
modules.service.manageWether the service module may be usedutil_module_service_managealways
modules.service.allow_reloadWether the service module may reload servicesutil_module_service_allow_reloadalways
modules.serivce.allow_restartWether the service module may restart servicesutil_module_service_allow_restartalways
epel.enabledWether EPEL is enabled on this systemutil_epel_enable{{ ansible_os_family }} == RedHat
modules.apt.cache_valid_timeApt cache valid timeutil_apt_cache_valid_time{{ ansible_os_family }} == Debian

Dependencies

None.

Example Playbook

- hosts: all
  roles:
    - role: ansible-util

License

Apache Version 2.0

Integration testing

This role provides integration tests using the Ruby RSpec/serverspec framework with a few drawbacks at the time of writing this documentation.

Running integration tests requires a number of dependencies being installed. As this role uses Ruby RSpec there is the need to have Ruby with rake and bundler available.

# install role specific dependencies with bundler
bundle install
<!-- -->
# run the complete test suite with Docker
rake suite
<!-- -->
# run the complete test suite with Vagrant
RAKE_ANSIBLE_USE_VAGRANT=1 rake suite

Author information

Mark Kusch @silpion.de mark.kusch

<!-- vim: set nofen ts=4 sw=4 et: -->