Hello list,
I thought to use this forum to drop some lines for concepts and updates
to roles in galaxy provided from user groover (e.g. groover.tomcat).
We often had issues reported on github in open source roles regarding
local_action: get_url tasks requiring sudo/become: yes and failing the
plays when no passwordless sudo was available to the users.
The concepts here are quite simple:
- Make downloading assets persistent
- Download from third party once
- Upload to internal network as often as required
- Allow any user with access to a central Ansible node to download
assets from the internet in a persistent place (e.g. NOT /tmp)
- This would require to manage a directory, where all users could
- write to
- read from
which resulted in a task
- name: Install persistent local data path
become: yes
local_action: file
state=directory
dest=/usr/local/...
owner=0
group=0
mode=2777
Many people out there do not need that, but we do, even if a big number
of playbooks is now managed with a continous integration system.
More on that later on.
We often found to be very repetitive with tasks in roles. Like the
persistent local download path above. Many roles had this task and we
started to share variables (like namespace clashing) over different
roles (e.g. {{ ansible_local_data_path }}). Not a good idea. But we
did that.
What I really wanted to do was to give you all the power to
configure the roles to your needs, and there was thankfully one Ansible
feature evolving and totaly functional with the 1.8 releases.
Dependencies. In earlier versions a dependency was triggered as many
times as it was called from roles, so using groover.java and
groover.tomcat roles both depending on another role would have meant
the dependency to run at least twice. If we add the dependency to the
playbook for more transparency even three times.
This changed with Ansible 1.8 and using dependencies started to make
sense.
What I really NOT wanted to do is spam all the roles with all different
dependencies and tell you "if you want to use my tomcat role, you have
to use everything from my playbooks".
So, here at silpion (http://silpion.de) we now treat two
different types of dependencies.
- soft dependencies
- hard dependencies
We only add hard dependencies to roles' meta/main.yml dependencies dict.
This in turn allows to safely use variables from other namespaces (all
our roles use the role name as prefix to variables, e.g. tomcat role
prefixes all variables with tomcat_) as we can ensure that the variables
are known to the Runner. We have a hard dependency configured.
There are still issues with tags, but that's another story not
completely solved right now.
Soft dependencies can get used to fulfill the requirements a role may
have, but it's up to you (all the power again) to either use other roles
from silpion, or to fulfill the requirements yourself (e.g. local facts
like {{ ansible_local['java']['general']['java_home'] }} for the tomcat
role).
We decided: We need dependencies. We also decided that if we use
dependencies, we keep them as few as possible.
So, if you don't like dependencies, I'm sorry, but I'd rather use a
good dependency in favor of all roles repeating tasks and burning
CPU.
We came up with a single role, which should help us to get rid of
repetitive tasks and to even better make complete playbooks configurable
with single variables from that role.
groover.util was born. The util role is not meant to configure nodes.
(It does that regarding installation of Python selinux bindings, or the
EPEL repositories for ansible_os_family == 'RedHat', but that's for a
good reason.)
The util role is meant to configure aspects of Ansible and playbooks
and to ensure Python libraries Ansible requires for our roles are
available on the nodes.
An example.
- hosts: test-environment
vars:
util_package_state_debian: latest
roles:
- { role: groover.java }
- { role: groover.tomcat }
- hosts: production-environment
vars:
util_package_state_debian: installed
roles:
- { role: groover.java }
- { role: groover.tomcat }
All roles depending on groover.util role will have this implemented
whenever they use the nodes package manager to install packages.
That's the idea, basically.
util role is our starting point for anything. It does a few but very
powerful things.
That is why a number of our roles developed at silpion will have a
dependency to the groover.util role in the very near future.
What else. util role will make the local_action: file task from
above completely configurable, once v2 has arrived. Currently there
is an issue with Ansible itself which is fixed with v2.
The following roles will get updates for that very soon:
- groover.etckeeper
- groover.java
- groover.tomcat
- groover.maven
- groover.heka
Roles from cascaya will follow this as well in the future.
Please be aware of one more thing to note regarding our method of
dependencies:
At the time we created our galaxy accounts there was no organisations
feature most of you might know from github. We do not configure
dependencies on `groover.tomcat'. We configure dependencies on our
organisation, silpion.
Each role has a requirements.yml file distributed which stores our
roles as silpion.tomcat, silpion.java, et cetera.
What else. Active pull requests. Because we have changed a lot of roles
we cannot just merge pull requests on github until the "move" is final.
I try the best I can to integrate features requested.
In the process we updated the tomcat role for various feature requests
and issues without staying backward compatible. I personaly think it
was worth it. You'll see.
That's it. I'd add potatoes.
Hope you find this useful in whatever terms/means and understand,
- why we start to use dependencies
- that we were forced to disregard backward compatibility in tomcat
role.
Best,
# kraM (groover@galaxy, spul@github, kraM@freenode)