Here is an example of a complex project for reference https://github.com/mrlesmithjr/ansible-vsphere-management
<https://github.com/mrlesmithjr/ansible-vsphere-management>When developing a complex project you should keep everything modular (roles, inventory, group_vars, host_vars, and etc.). Pull the external dependencies into your project using Git sub-modules (inventory, group_vars, host_vars) and use a requirements.yml file to define the roles that you need as part of your project. Then use ansible-galaxy install -r requirements.yml -p ./roles to pull those roles into your project. Never make changes to those roles in your project but rather in the external repos of those roles and then pull them back into your project as needed. You can easily include an ansible.cfg as part of your project to define the roles_path and anything else that you may want to define specific to the project. All of your playbooks should just be minimal playbooks defining the roles as required. In regards to import_playbook, I would advise against this if you are doing a lot of dynamic inventory, group_vars, and host_vars manipulation and leverage either a CI/CD pipeline to drive the orchestration or simply create a shell script to drive the orchestration. The reason for this is that you can then pull new inventory, group_vars, and host_vars into subsequent playbooks. These are just some real-world examples that have worked for me on massive projects. Obviously as you progress throughout the project things will be adapted as necessary but just remember to make the project the skeleton of the project and pull in modularly from external sources the building blocks required. Hope this helps! On Friday, March 23, 2018 at 6:52:20 AM UTC-4, [email protected] wrote: > > Hi > > Is there a document describing the best practices to organise a complex > Ansible project ? > > Here is the project that I'm thinking about : > > - Project has been designed as a collection of reusable modules (= role) > which are living under by example this folder "complexproject/roles" fo the > modules part of the main project > - Project could include roles created and managed by external teams and > git cloned locally under "complexproject/imported/projectA/roles, > complexproject/imported/projectB/roles" > - Users access the main playbooks using this command "ansible-playbook -i > inventory complexproject/playbooks/main.yml > - main.yml file contains roles tagged to be called > > E.g. > --- > - hosts: "{{ openshift_node }}" > gather_facts: "{{ gathering_host_info | bool == true }}" > > roles: > - { role: 'enable_cluster_admin', tags: 'enable_cluster_admin', when: > target_platform == 'cloud' } > - { role: 'create_projects', tags: 'create_projects'} > - { role: 'persistence', tags: 'persistence', when: > target_platform == 'cloud' } > > Questions > - Is this approach coherent/consistent ? > - Can we set up a var to tell to Ansible where all the roles are located: > complexproject/roles:complexproject/imported/projectA/roles:complexproject/imported/projectB/roles > - Should we adopt a different approach where different projects which > contain roles are imported using "import_playbook" --> see > `openshift-ansible` project - https://goo.gl/KXDWXN ? > > Regards > > Charles > -- You received this message because you are subscribed to the Google Groups "Ansible Project" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/b0ea7bd3-ef65-4433-87e6-68d0d9a13e96%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
