¿Tres soluciones para estructurar una implementación con Ansible?

Actualmente estoy implementando un nuevo producto y encontré algunos problemas para estructurar mi Playbook y Roles. Tengo tres soluciones diferentes y espero obtener información sobre qué camino podría ser el mejor.

El producto es una aplicación web en un servidor de Windows. Los siguientes pasos son necesarios para implementar (alto nivel):

• instalar javajdk
• instalar tomcat
• instalar win_service
• configurar regkes java
• configurar tomcat
• instalar webapp
• Empieza el servicio

Utilizo inventarios estáticos para producción y puesta en escena, group_vars, roles (creados con ansible-galaxy), por lo que hay algún tipo de estructura.

Solución 1 Ponga todo en un enorme libro de jugadas. Eso no suena bien, pero tiene la ventaja de que conoce las variables de las instalaciones anteriores, por ejemplo, tomcatnecesita saber dónde JAVA_HOMEestá ... eso fue con la javajdkinstalación, debido a que más de un Java en las máquinas no hay global JAVA_HOME...

Solución 2 Divida todo en pequeños roles. Suena genial, pero los roles deben ser independientes entre sí. No encontré un método para desacoplar tareas. ¿Tendría sentido tener roles individuales, por ejemplo install_tomcat, config_tomcaty configurar un libro de jugadas que tenga los roles mencionados en secuencia?

Pero, ¿cómo sabe un rol, por ejemplo, un nombre de ruta que se necesita en el próximo rol? -> La instalación establece la ruta, la configuración necesita saber ... Estoy realmente inseguro de hacer que los roles sean independientes.

Solución 3 Tipo de solución 2. Tenga un libro de jugadas principal que contenga solo roles, dividido lo más posible en roles. Tener nombres de variables independientes en./roles/vars/main.yml

De alguna manera (?) Encuentra un lugar más alto en la precedencia variable con el libro de jugadas donde varvan todas las definiciones necesarias . Internamente, puede enrutar una variable al rol o simplemente anular una variable de rol.

Por ejemplo, un producto tiene un servicio, el nombre del servicio generalmente es parte de un nombre de ruta para tomcat. El tomcatnombre no debe depender del servicio, por lo que debe haber una función tomcat_install_pathen el rol, pero también una service_namecon el producto. Por lo tanto, en caso de que el libro de jugadas para el producto se llame, el nombre del servicio debe ser parte del nombre, si tomcat_installse llama con una implementación totalmente diferente, no se debe jugar con un nombre de servicio.

Iría con la Solución 3, pero aún no he encontrado una manera de configurarlo. ¿Cuál es la opinión de los expertos? ¿Es factible la solución 3, es una de las otras una vez mejor o hay una cuarta solución?

Recomendaría estructurar el código tal como se define en el documento de Mejores prácticas de Ansible :

y para seguir la estructura que utilizan los principales contribuyentes a la plataforma de galaxia ansible, como geerlingguy .

Si uno sigue una estructura diferente significativa, será muy difícil en el futuro reutilizar los roles de la comunidad de galaxias ansibles y uno tiene que reinventar la rueda.

Respuesta corta: haces programación aquí. Considere los Estándares de programación (código limpio) como "paquete por característica" y cree un rol que sea reutilizable y exprese la razón del rol. p.ej

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

Además: el rol subyacente, por ejemplo, el jdk nunca debería saber sobre el rol de tomcat, etc.