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
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
