TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

Decentralize your DevOps with Master-less Puppet and supply_drop

30 pointsby pgr0ssover 13 years ago

6 comments

viraptorover 13 years ago
How can you tell what's in each system at every step? I mean - you know what should be there, but how can you be sure someone didn't forget to apply, or that they had a clean tree at the time? They say "With a centralized Puppet server, the server maintains a single canonical version of the Puppet configuration." I'd counter with: make it always have the latest version from git - you end up in the same position you want, as described in the same point.<p>I'm usually relying heavily on external resources (puppet) / node searches (chef)... not sure I really like the chef-solo or forced apply in puppet way of doing things.
sciurusover 13 years ago
At work I recently started to use masterless puppet to manage a working environment (e.g. directory structure, shell configuration, packages installed into our own RPM database) on compute clusters we use but don't have root access to. It was much easier to get working than I expected. Looking at the source for rump (<a href="https://github.com/railsmachine/rump" rel="nofollow">https://github.com/railsmachine/rump</a>) was helpful when determining the proper directory structure and puppet command line options.
fsaintjacquesover 13 years ago
I'm currently trying to run Chef in solo-mode with a git repository. Nodes would update with regular pull &#38; apply. Has anyone tried something like this?
评论 #3577399 未加载
评论 #3577202 未加载
sciurusover 13 years ago
In this workflow, the configuration being applied to a server is whatever people happen to have rsynced to it. That may allow for quick iteration in their QA environment (as long as people avoid stepping on each others toes), but wouldn't it be better if the sandbox and production servers pulled their configuration from the sandbox and production git branches?
评论 #3577333 未加载
评论 #3577324 未加载
troelsover 13 years ago
Couldn't this cause a race condition if two admins try to apply changes at the same time? Without a centralised repository, I presume that you would need to introduce a locking mechanism on a per-node level, so one would: take lock, run noop, run apply, release lock. Maybe make it implicit.
seanyover 13 years ago
Wouldn't this break externalized resources?