7

I am currently deploying a new product and came across some problems to structure my Playbook and Roles. I have three different solutions and hope to get some input which path might be the best.

The product is a webapp on a windows server. The following steps are needed to deploy (high level):

  • install javajdk
  • install tomcat
  • install win_service
  • configure java regkes
  • configure tomcat
  • install webapp
  • start service

I use static inventories for prod and staging, group_vars, roles (created with ansible-galaxy) so there is some kind of structure.

Solution 1 Put everything in one huge playbook. That does not sound well, but has the advantage that you know the variables from previous installations e.g. tomcat needs to know where JAVA_HOME is... that was with the javajdk installation, due to more than one java on the machines there is no global JAVA_HOME...

Solution 2 Break all out in small roles. Sounds great but roles should be independent from each other. I did not found a method to decouple tasks. Would it make sense to have single roles for e.g. install_tomcat, config_tomcat and set up a playbook which has the mentioned roles in sequence?

But how does one role know about, e.g. a path name which is needed in the next role. -> Installation sets the path, config needs to know.. I an really unsure to make roles independent.

Solution 3 Kind of solution 2. Have a main playbook which contains only roles, split as much as possible to roles. Have independent variable names in ./roles/vars/main.yml

Somehow(?) find a place higher in the variable precedence with the playbook where all needed var definitions go. Internally either path a variable to the role or simply over-rule a role variable.

E.g. a product has a service, the service name is generally part of a path name for tomcat. The tomcat name should not depend on the service, so there should be a tomcat_install_path in the role but also a service_name with the product. So in case the playbook for the product is called the service name should be part of the name, the tomcat_install is called with a total different deployment there should be no fiddling with a service name.

I would go with Solution 3 but I have not yet found a way to set that up. What is the experts opinion, is solution 3 doable, is one of the other once better or is there a 4th solution?

030
  • 13,235
  • 16
  • 74
  • 173
Michael Hoeller
  • 221
  • 1
  • 2
  • 8

2 Answers2

3

I would recommend to structure the code as defined in the Ansible Best Practices document:

enter image description here

and to follow the structure that major contributors to the ansible galaxy platform use, like geerlingguy.

If one will follow a significant different structure then it will be really hard in the future to reuse roles from the ansible galaxy community and one has to reinvent the wheel.

030
  • 13,235
  • 16
  • 74
  • 173
  • Thanks. And concrete in regards to my question: How will you decouple and reuse e.g. javajdk installation and the reuse of it in a tomcat installation? When they are decoupled than the variables e.g. pat to javaddk will need to be "in" the role. How do you handle this in a tomcat installation with out changing variables all over the place? Is there a common concept to use variable precedence? Is so which? – Michael Hoeller Nov 26 '17 at 15:40
  • I would check ansible galaxy and install a jdk and tomcat role. I will not write a role myself unless it is unavailable. For example, https://github.com/silpion/ansible-tomcat and ansiblebit.oracle-java – 030 Jan 04 '18 at 21:46
  • Note that I did not test the tomcat role. You could test the tomcat role locally. If that does not work, you could use another tomcat role from galaxy. – 030 Jan 04 '18 at 21:52
1

Short Answer: You do programming here. Consider Programming Standards (cleancode) like "package by feature" and build role which are reusable and express the reason of the role. e.g. 

roles:
  - role: jdk
  - role: tomcat  
      (contains tasks with 'install tomcat', 'configure tomcat' ) 
      (requires jdk)
  - role: the_wepapp 
      (requires tomcat)

Futhermore: The underlying role e.g. the jdk should never know about the tomcat role etc...

schmichri
  • 131
  • 4