Architecture of a complex ansible project

[cmou...@redhat.com]

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

[Marcos Alano]

On Youtube you has this amazing video about best practices:
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!

> --
> 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 ansible-proje...@googlegroups.com.
> To post to this group, send email to ansible...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/ansible-project/c9e936ce-5c2f-4956-a196-9babf84d6802%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



--
Marcos H. Alano
Linux System Administrator
marcos...@gmail.com

[cmou...@redhat.com]

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 ?

[Marcos Alano]

You can use the option --roles-path <path>.

> --
> 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 ansible-proje...@googlegroups.com.
> To post to this group, send email to ansible...@googlegroups.com.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/ansible-project/182d1fde-121b-4f13-89cb-a9be324526cc%40googlegroups.com.

[Larry Smith]

Here is an example of a complex project for reference 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!