# Architecture of a complex ansible project **URL:** \ **Category:** Ansible Project\ **Created:** [March 23, 2018, 10:52am UTC](https://forum.ansible.com/t/architecture-of-a-complex-ansible-project/27090 "2018-03-23T10:52:20Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![cmoullia](https://avatars.discourse-cdn.com/v4/letter/c/a5b964/32.png) [@cmoullia](https://forum.ansible.com/u/cmoullia)\ **Post date:** [March 23, 2018, 10:52am UTC](https://forum.ansible.com/t/architecture-of-a-complex-ansible-project/27090/1 "2018-03-23T10:52:20Z")
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. ---
**Author:** ![mhalano](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/mhalano/32/1815_2.png) [@mhalano](https://forum.ansible.com/u/mhalano)\ **Post date:** [March 23, 2018, 11:15am UTC](https://forum.ansible.com/t/architecture-of-a-complex-ansible-project/27090/2 "2018-03-23T11:15:25Z")
On Youtube you has this amazing video about best practices: [https://www.youtube.com/watch?v=5BhAJ4mEfZ8](https://www.youtube.com/watch?v=5BhAJ4mEfZ8) I think you should standardize your roles and export to it's own repository. After that you can use Ansible Galaxy to install that. You should think "I don't want to publish my roles!" but Ansible Galaxy you can download roles from a Git repo (even a private one) and not just the website galaxy.ansible.com. Cheers! ---
**Author:** ![cmoullia](https://avatars.discourse-cdn.com/v4/letter/c/a5b964/32.png) [@cmoullia](https://forum.ansible.com/u/cmoullia)\ **Post date:** [March 23, 2018, 1:36pm UTC](https://forum.ansible.com/t/architecture-of-a-complex-ansible-project/27090/3 "2018-03-23T13:36:51Z")
Is the folder where galaxy upload the roles locally on your machine part of the path that ansible-playbook will look for to find a role ? ---
**Author:** ![mhalano](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/mhalano/32/1815_2.png) [@mhalano](https://forum.ansible.com/u/mhalano)\ **Post date:** [March 23, 2018, 1:43pm UTC](https://forum.ansible.com/t/architecture-of-a-complex-ansible-project/27090/4 "2018-03-23T13:43:25Z")
You can use the option --roles-path \. ---
**Author:** ![Larry\_Smith1](https://avatars.discourse-cdn.com/v4/letter/l/d26b3c/32.png) [@Larry\_Smith1](https://forum.ansible.com/u/Larry_Smith1)\ **Post date:** [April 6, 2018, 2:54am UTC](https://forum.ansible.com/t/architecture-of-a-complex-ansible-project/27090/5 "2018-04-06T02:54:02Z")
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!