I'm an advocate of both camps. I use puppet in standalone mode when I'm demonstrating puppet to a new client. It's lightweight, I can use NFS or a CM repository to provide the recipes to a server and run it standalone post kickstart. It's the perfect mode for small scale repeatable system builds. Quite often my clients want a definable set to work. A kickstart template with a CM controlled puppet recipe works a treat.
But, when the number of systems grows to a certain size, you do not want the recipes available on each host. For the reasons Nigel cited, it isn't good security practice to provide knowledge of all the servers on your estate to each server. It would be difficult to compartmentalize your recipes via your CM repository / fileshare to minimise the scope. The puppetmaster ensures only the server specific catalog is provided. That's the big win. On Feb 14, 9:33 pm, tom <tom.ash...@gmail.com> wrote: > On 09/02/11 20:42, Kevin Beckford wrote: > > > > > It would be non trivial to keep the configuration data isolated in > > masterless mode if you have a desire to segment and isolate > > configuration data by system, or even system roles (i.e. my website > > database system should not contain puppet manifest with my financial > > database password). > > > I really am trying to understand here. To me this is the thing I love > > about git/merc... wait, I dont love mercurial. The thing I love about > > DVCS is that this seems a perfect problem domain for it. You would be > > the master, store the total repo on your laptop and push the branches > > needed, where they need to go. I suppose that the logic would be in > > several systems instead of one, but git does distributed versioning > > better, surely? Please advise. > > -- > > You received this message because you are subscribed to the Google > > Groups "Puppet Users" group. > > To post to this group, send email to puppet-users@googlegroups.com. > > To unsubscribe from this group, send email to > > puppet-users+unsubscr...@googlegroups.com. > > For more options, visit this group at > >http://groups.google.com/group/puppet-users?hl=en. > > I use Puppet in a standalone mode. > I created a templating system using Perl and TemplateToolkit to create > (simple) puppet manifests and configuration files I wish to manage. > These are stored in a Git repo that allows me to easily see when changes > are made to a servers' configuration before pushing. Rollbacks are > possible too in this scenario. > Clients pull via rsync - there is definitely scope for a more robust TLS > transport here. > The big plus side here is that I am holding every servers' set of files > in a DVCS (as well as my colleagues) so we are less dependant on backups > as everyone in the team will hold a fairly recent copy of the entire > server farm. > Tied in mainly to CentOS, I can Kickstart a server and let it pull it's > own configuration and apply it in mere minutes if I was to loose a server. > > As I say, manifests are fairly simple, but enough to manage files, > services and other custom executables. > > This was inspired by some work a guy did at Oxford University. It seems > to scal very well as I am managing 180+ servers this way. > > Tom -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
