I would recommend having a look at the modules on puppet forge to give you a kickstart into the process. http://forge.puppetlabs.com/
There are a bunch of useful modules in there. On 12 March 2013 19:16, Andrea Crotti <[email protected]> wrote: > Mm ok then I'll drop the idea and try to go with modules.. > The other problem now is that I should somehow switch from an architecture > which was provisioned but never correctly maintained with puppet > to using puppet master and all these nice things, which is not going to be > trivial.. > > On Monday, March 11, 2013 7:42:07 PM UTC, joe wrote: >> >> Modules are not overkill and are, in fact, the only way you can do what >> you intend. >> >> There is currently no module structure that would allow you organize your >> manifests the way you'd like and still be able to apply classes flexibly. >> >> The reason for this is that the module structure in puppet is mostly a >> file naming convention that allows the master to locate particular >> classes. If you wish to flexibly include/declare classes as you wish, the >> only way puppet would be able to find them and flexibly apply them would be >> to follow the module convention. >> >> For instance, for a class nginx, the *only* place puppet can find that >> and apply it flexibly is if it is located in $moduledir/nginx/manifests/* >> *init.pp. >> >> Otherwise, you'd have to still rely on import and then have a *ton* of >> conditionals everywhere to figure out whether to actually apply each class. >> This is not maintainable at all. >> >> Go with modules. You'll have many fewer issues later. >> >> On Monday, March 11, 2013 12:23:47 PM UTC-6, Andrea Crotti wrote: >>> >>> So far we have a similar situation, for each different server one fabric >>> and one puppet file, where the fabric file simply applies it in a brutal >>> way. >>> >>> >>> with settings(user='root'): >>> put('qa.pp', 'qa.pp') >>> put('puppet apply qa.pp') >>> >>> And puppet files don't use anything like classes or modules, but simply: >>> >>> package {["nginx", "python-virtualenv", "rsync", "autossh", >>> "redis-server", "git-core", "python-dev", "ntp"]: >>> ensure => installed} >>> >>> service { 'nginx' : >>> ensure => "running", >>> enable => true, >>> hasrestart => true, >>> require => Package["nginx"] >>> } >>> >>> >>> Now there are many issues with the current setup, where the first is we >>> are not really managing our servers, but we can only provision them.. >>> >>> The second big problem is that there is a lot of repetition everywhere >>> and the third is that I can't easily provision multiple services on a >>> single machine (if they were supposed initially to run on different >>> machines). >>> >>> Now I read some doc and in theory it looks like I should create one >>> module per each service. >>> >>> - nginx >>> + templates >>> + manifests >>> >>> - couch >>> + templates >>> + manifests >>> >>> this is however overkill for me, what I think would make more sense >>> would be >>> >>> - templates >>> + nginx >>> + couch >>> >>> - manifests >>> + base.pp >>> + couch.pp >>> .. >>> >>> Is it possible to use such a structure though? >>> >>> I just want to be able to use classes smartly, avoid duplication and >>> start working with puppetmaster instead of this silly way.. >>> >>> Any advice? >>> Thanks >>> >> -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/puppet-users?hl=en. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
