On lut 17, Demetri A. Mkobaranov wrote:
> I've notice that in debops v.2 every role has a main_env.yml
not every role, my bad. Some roles.
In short: these separate 'main_env.yml' tasks set up "environment" for
roles to work with. If they are present in the playbook of a given role, you
should include them in the custom playbooks as well.
A bit longer explanation: DebOps is designed with a clear separation between
roles in mind. Each role takes care of its own "service", and when you want to
configure something for a different role, for example open a firewall port for
the webserver, you need to pass the configuration via dependent variables on
the playbook level. Even though roles in the same playbook can see their own
variables, since they are in the same "namespace", they strictly do not access
them directly - this permits us to mix and match roles in different playbooks
without the risk of referencing a variable that's suddenly not defined.
Some roles however are more dynamic. For example, the 'postfix' role wants to
open ports in the firewall for the 'smtp', 'submission' and
but only if these services are actually used. The decision when to use these
services is done in a template
('templates/lookup/postfix__env_active_services.j2') based on the contents of
the 'postfix__combined_mastercf' variable. Ordinarly, all variables in roles
in the same playbook are accessible, so most of the time the 'ferm' role can
read the variable defined in another role, usually named
'<role>__ferm__dependent_rules' and configure the firewall accordingly.
However in the 'postfix' case, the template that is looked up during the
variable resolution is stored in the 'postfix' role, not the 'ferm' role.
would pass the variable with 'lookup("template")' directly to the
Ansible would try and look for the template in the 'ferm' role which is
The solution to this is to prepare an additional variable using the 'set_fact'
Ansible module. We do that with the 'main_env' task list from the
role which gets executed before the 'ferm' role. The variable stays resolved
with the list of services that we want opened and can then be referenced in
the 'postfix__ferm__dependent_rules' variable which is passed to the
role. When we do the 'set_fact' task, Ansible is inside of the 'postfix'
and can find the correct template.
Of course it could be a bit easier to rearrange the roles, have 'postfix' role
be executed before the 'ferm' role and just set the relevant variable inside
of the 'postfix' role itself... However the order of the roles in the playbook
determines the execution order of the handlers which are used to restart
services. I want to be sure that the firewall rules are set up before Postfix
service is restarted, to be on the safe side. And, I want to keep the
preferred order of the roles in DebOps playbooks somewhat consistent, with the
"dependent roles" being applied before the main role of a given playbook.
There are of course exceptions, but they are usually for a specific reason.