Hi Imesh,

On Fri, Dec 4, 2015 at 10:12 PM, Imesh Gunaratne <[email protected]> wrote:

> Hi Krishantha,
>
> On Fri, Dec 4, 2015 at 12:36 PM, Krishantha Samaraweera <
> [email protected]> wrote:
>
>>
>> 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.
>>
>
> +1 Yes definitely, we are now reviewing the API-M puppet module developed
> by your team, planning to take it as it is and do any necessary changes to
> make it generic.
>

+1 for  looking into existing scripts and trying to reuse them.  Yes there
are many things that we can make more generic.


>
>> 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.
>>
>
> Do you think Mcollective and Jenkins should be part of the generic puppet
> modules?
>

No, however we used factors to store deployment pattern and product name.
By changing those factors different deployment patterns can be triggered
though Jenkins. We used below Mcollective command to change factors in all
agent machines. This helps us to trigger deployments though Jenkins.

*mco shell run 'rm /etc/facter/facts.d/deployment_pattern.txt;mkdir -p
/etc/facter/facts.d; echo  "deployment_pattern=pattern1" >>
/etc/facter/facts.d/deployment_pattern.txt'*

So if you can consider about factors to hold high level deployment options
then that would be very continuous delivery friendly option.

Thanks,
Krishantha.


>> 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.
>>
>
> +1 Will do.
>
>>
>> Also having environment concept (Development, production, QA) would help
>> us to manage/maintain puppet scripts more easily.
>>
>> Yes we noticed this in Hiera. We should be able to keep this feature in
> the generic puppet modules.
>
> Thanks
>
>
>> WDYT ?
>>
>> Thanks,
>> Krishantha.
>>
>> On Fri, Dec 4, 2015 at 12:19 AM, Imesh Gunaratne <[email protected]> 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.
>>
>
>
>
> --
> *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
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Reply via email to