Hi, We are now trying to refactor the puppet modules in [1] according to the best practices DevOps, Automation and Private PaaS teams found over the recent past on designing puppet modules. These include following:
- Using Hiera for keeping site-specific data out of the manifests [2] - Use a base puppet module/class to implement common installation and configuration steps - Use one puppet module to install different versions of a product, product version to be given using a parameter (example: puppet module = wso2esb, product version = 4.9.0) - Eventually include multiple sets of templates for different versions of the product inside a single puppet module - Provide a version for the puppet module (example: puppet module = wso2esb, puppet module version = 1.0.0, product version = 4.9.0) - Implement unit tests for puppet modules [3] - Finally publish puppet modules in Puppet Forge - Afterwards users can either use puppet install or wget for installing puppet modules in their environments These puppet modules will be designed to support different deployment models: - Deploying WSO2 products on VMs using a Puppet Master - Building Docker images with Puppet Apply [4] for Kubernetes - Deploying WSO2 products on WSO2 Private PaaS - On VMs using a Puppet Master with runtime configurations - On Kubernetes using Puppet Apply with runtime configurations Please feel free to add your thoughts. [1] https://github.com/wso2/puppet-modules/ [2] https://docs.puppetlabs.com/hiera/latest/ [3] https://puppetlabs.com/blog/the-next-generation-of-puppet-module-testing [4] https://puppetlabs.com/blog/docker-and-puppet-for-application-management Thanks -- *Imesh Gunaratne* Senior Technical Lead WSO2 Inc: http://wso2.com T: +94 11 214 5345 M: +94 77 374 2057 W: http://imesh.gunaratne.org Lean . Enterprise . Middleware
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture