Ansible Galaxy Role Optimization: Structuring Modular Playbooks for SDDC Code
Refactoring a 3,000-line monolithic Ansible playbook into modular Ansible Galaxy collections (community.vmware, community.general).
βA 3,000-line single Ansible playbook is impossible to debug. Modularizing code into clean Ansible Galaxy roles makes infrastructure maintainable and reusable.β
In our early iterations of automated SDDC lab deployments at NTT Data, all tasks (vCenter deployment, ESXi setup, NSX-T configuration) were housed in a single monolithic deploy.yml file.
Refactoring Monolithic Playbooks into Modular Collections
We refactored the entire repository into modular Ansible roles and external collection requirements (requirements.yml).
deploynestedInfra.yml: Deploys nested ESXi hypervisors and vCenter.deploynsxtInfra.yml: Instantiates NSX-T Manager and configures Edge Cluster switches.undeploy.yml: Gracefully powers off and purges target pods.
[!IMPORTANT] Separate infrastructure state parameters (
answerfile.yml) completely from task execution logic (playbooks/).
# # requirements.yml for Modular SDDC Automation
collections:
- name: community.vmware
version: 3.2.0
- name: community.general
version: 5.0.0
- name: ansible.posix
version: 1.4.0
The Verdict
Key Takeaway
Decouple Infrastructure Parameters from Task Execution Roles.
Structure automation repos into modular Ansible Galaxy roles, separating environment variables (answerfile.yml) from execution tasks.
Sachin Kumar Sharma
Associate Director (Infrastructure & Cloud Architecture Strategy) | 20+ Yrs Exp
Architecting resilient multi-cloud enterprise landing zones, SDN overlay fabrics, DevSecFinOps automation pipelines, and autonomous Agentic AI platforms.