Hi Imesh, We need to consider continues delivery aspects when designing these core puppet modules. Some of the suggestions that you have mentioned are already being implemented while automating APIM deployment patterns. If we can review and adhere to the way automation team design puppet scripts that would cut down any rework for our side. Automation requirement is to do several deployments and run tests on those deployments without any human interventions. We already completed POC of this using puppet, Hiera, Mcollective and Jenkins.
IMO, as the first step we should review the Hiera data model and module structure that we have introduced. And improve it if required or go for new design. IMO, we have achieved 100% data separation from puppet modules and product template versioning. Based on the review we can introduce new base module. Also having environment concept (Development, production, QA) would help us to manage/maintain puppet scripts more easily. WDYT ? Thanks, Krishantha. On Fri, Dec 4, 2015 at 12:19 AM, Imesh Gunaratne <im...@wso2.com> wrote: > 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 > > -- Krishantha Samaraweera Senior Technical Lead - Test Automation Mobile: +94 77 7759918 WSO2, Inc.; http://wso2.com/ lean . enterprise . middleware.
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
