This is an ansible lookup plugin for integrating with Jerakia
Jerakia is a hierarchical lookup tool. It supports pluggable datasources and the ability to override values in the hierarchy using information about the requestor. See The official Jerakia site for more general information on Jerakia.
This plugin provides an interface between Ansible and Jerakia by way of a lookup plugin. Further plugin types are being investigated.
A hierarchical lookup is made by applying a scope against a hierarchy of lookup paths. A scope is simply information about the requestor, in this case the Ansible node, that it used in determining what data to return. A scope could consist of anything, typical things would be the hostname, environment and location of the node. Using the scope provided in the lookup, Jerakia will run through a hierarchy and return the relevant value.
For the examples in the next section, we assume that Jerakia Server is installed and running on it's default port on the local machine and that we have the following default policy configured in Jerakia
# /etc/jerakia/policy.d/default.rb
policy :default do
lookup :default do
datasource :file, {
:format => :yaml,
:docroot => "/var/lib/jerakia/data",
:searchpath => [
"node/#{scope[:hostname]}",
"environment/#{scope[:environment]}",
"operating_system/#{scope[:osfamily]}",
"common"
]
}
end
end
See the official documentation for more information about Jerakia policies and lookups.
The plugin will look for the ANSIBLE_JERAKIA_CONFIG
environment variable to determine the location of the config file. If the variable is not set, it will look for a jerakia.yaml
file in the directory where your playbook is located. The config file must contain an authentication token to use to connect to Jerakia Server. We can also use the scope
hash to map Ansible variables (facts) to the scope values used by the Jerakia policy above, eg:
token: ansible:52cbf789c7837f9a4aef0d259c00d131f0f2a47894519c273c64a608de1382cba4221447752e9ac2
scope:
hostname: ansible_nodename
environment: ansible_local.custom.environment
osfamily: ansible_os_family
Note that the scope keys in this example are the scope values used in the Jerakia policy, mapped to values which are Ansible variables (facts) for that request.
Supported configuration parameters of jerakia.yaml
are:
Parameter | Description | Required | Default |
---|---|---|---|
token |
The Jerakia token to use to authenticate against Jerakia server | Yes | - |
scope |
A hash containing the scope to use for the request, the values will be resolved as Ansible facts. Use a dot notation to dig deeper into nested hash facts (see environment above) |
No | - |
protocol |
The URL protocol to use | No | http |
host |
Hostname of the Jerakia Server | No | localhost |
port |
Jerakia port to connect to | No | 9843 |
version |
Jerakia API version to use | No | 1 |
policy |
Jerakia policy to use for the lookups | No | default |
Once configured with a jerakia.yaml, you can call the Jerakia lookup plugin directly from your playbooks using the lookup
method. The first argument is always the name of the plugin, jerakia
, and the following arguments contain the namespace and key to lookup, which is formatted as <namespace>/<key>
- hosts: all
tasks:
- debug: msg=" {{ lookup('jerakia', 'apache/port') }}"
In the above example, if we assume the value of ansible_nodename
is foo.enviatics.com
, environment
is dev
and ansible_os_family
is RedHat
then with the policy we have declared, this will cause Jerakia to look up the key port
in the namespace apache
, it will follow the following hierarchy of files looking for the key port
and return the first value it finds:
/var/lib/jerakia/data/node/foo.enviatics.com/apache.yaml
/var/lib/jerakia/data/environment/dev/apache.yaml
/var/lib/jerakia/data/operating_system/RedHat/apache.yaml
/var/lib/jerakia/data/common/apache.yaml
So we would be able to define a default value for the Apache port in common/apache.yaml
but then have the ability to override this value based on a specific node, environment or operating system type. Note that the structure of the hierarchy here is purely an example, and is entirely configurable to suit your specific environment and needs.
This is a very new project so contributions are always welcome, please submit a pull request in the first instance.
This project is maintained by Craig Dunn [email protected] - @crayfishx
This project is licensed under the Apache 2.0 license, please the the LICENSE file included with this software.