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 puppet-users+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
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 puppet-users+unsubscribe@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
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 puppet-users+unsubscribe@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
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 <andrea.crotti.0@gmail.com> 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 puppet-users+unsubscribe@googlegroups.com. > To post to this group, send email to puppet-users@googlegroups.com. > 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 puppet-users+unsubscribe@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.