Hi Isuru, Just to clarify, please refer to those inline comments and let us know if you have a different view.
On Fri, Nov 27, 2015 at 1:18 PM, Isuru Haththotuwa <[email protected]> wrote: > Hi, > > The requirement is to automate the configurations dynamically in a > serverless manner (without a puppet master), > specifically when running PPaas on docker/kubernetes. > This is not specific to docker containers. We can use same thing (puppet apply) for VMs if needed. > > The puppet modules that are currently used (for VM scenario) can be > re-used, with one change. > So we *should* use the same module. Then we don't need to maintain 2 distributions. We need to update existing modules to cater this requirement if those are lagging. That difference is the need include the nodes definitions (site.pp) in each > puppet module > We don't include site.pp within the puppet module. ideally we shouldn't touch a puppet module if there is no custom changes. I think you have done it correctly but telling something different :D > (can skip this it only a single module is used for a node; currently in > the puppet master based deployment there are several modules referred in a > single node definition). > In docker we only run a single server but in order to start a single server we may refer several modules. As an example, we have a common module called 'wso2base' which stores configs common to a deployment. If we need to start an APIM server in a docker container we need to use both 'apimanager' and 'wso2base' modules. > > A very basic puppet module can have a structure roughly similar to the > following: > > ├── files > ├── manifests > │ └── site.pp > ├── modules > │ └── test > │ └── manifests > │ ├── init.pp > │ └── site.pp > ├── puppet.conf > └── templates > > This same structure can be re-used in both puppet scenarios; where the > deployment has a master and where it does not have a master. > > In the serverless puppet scenario there is a requirement to pass data to > the modules. For this, its possible to use facters (similar to the > deployments that include puppet master). For this, need to do the following: > > > 1. expose the data as a environment variable, with FACTER_ prepended > to the variable name [1] > > Try to use the ruby facter extension to expose environment variable as facters. > > 1. > 2. Access the variable in the manifest file [2] > > After the data is exposed as environment variables, can run the puppet > apply command pointing to the relevant module [3]. > As I know it should be the module path, but not the specific module. > After the configurations is done, its possible to re-use the same approach > that is used currently to push the configured templates to the product with > puppet master based deployment. > > [1]. export *FACTER_message*="test puppet apply message" > > [2]. > > class test { > > file { "/var/tmp/testfile": > ensure => "present", > owner => "root", > group => "root", > mode => "664", > content => "*$message*" > } > > } > > [3]. puppet apply --modulepath *<location_of_modules>* -e "include > *<classname>*" > > -- > Thanks and Regards, > > Isuru H. > +94 716 358 048 > > > Regards, Thilina.
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
