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.
