3 ms·

I think you're right that Salt/Puppet and to a lesser extent Chef take the wrong approach, but you make some confusing comments that make me suspect you might n

I think you're right that Salt/Puppet and to a lesser extent Chef take the wrong approach, but you make some confusing comments that make me suspect you might not understand what these existing approaches are about. > IMHO, the overwhelming problem with salt/cfengine/puppet style solutions (which I will refer to as 'post-facto configuration tinkerers', or PFCT's) is that they potentially accrue vast amounts of undocumented/invisible state I think you mean "post-facto" as in: "run after everything is done"? This is not the way that people would advocate Puppet should be used. Puppet should be used from the start, not added as an afterthought once you are done. > IMHO, a cleaner solution is to deploy configuration changes from scratch, by deploying clean-slate instances with those changes made This isn't a cleaner solution, this is almost the solution you get when you use Puppet. With puppet the development workflow is like this: - Span up a vagrant VM - Run your manifests against this VM to test them - To check in, run your manifests against your staging environment - To deploy, spin up new clean production VMs and run puppet manifest against them - Use a reverse proxy to route all traffic to new production VMs. Terminate old production VMs > PFCT's deployment paradigm tends to be relative slow and error prone. This much is true. Puppet's slow speed is particularly galling, but maybe that's just because I use it at work.

contingencies 13y ago
> isn't a cleaner solution, this is almost the solution you get when you use Puppet The difference betwen deploying an instance of a stored environment and generating that environment from some prior state is the generative process, which can fail or change in unexpected ways due to network conditions and other factors. More importantly, PFCTs enable and to some extent encourage modification of generated environments remotely, en-masse, without any significant capacity to ensure that individual instances within a group have not subtly shifted in configuration. This is what I meant by configuration drift. CSIEs, by contrast, are essentially the complete product of the entire generation process, thus ensuring that future instantiations are identical. A subtle difference, but an important one.
- drivebyacct2 13y ago
  If used properly they should have an identical result.
  - contingencies 13y ago
    Perhaps. The problem is, if you use PFCT on a bunch of hosts and something subtle changes that can cause issue, the granularity of the PFCT doesn't necessarily equate to that required for detecting the cause. With a CSIE-style atomic approach to deployment and a properly segregated monitoring system, you can, say, 'roll back' to the last known good version. PFCTs leak state, and will not always allow you this reverse pathway (random examples might include kernel feature or compiler version migration).
- calpaterson 13y ago
  > This is what I meant by configuration drift. I forgot to mention this before, it is strange that you credit yourself with defining this term when it has been well defined for some time in ops. > More importantly, PFCTs enable and to some extent encourage modification of generated environments remotely, en-masse, without any significant capacity to ensure that individual instances within a group have not subtly shifted in configuration. But this adds a significant weight over and above the "generative process" of running manifests. Yes, running manifests against your VMs can "fail or change in unexpected ways due to xyz" - don't do it against VMs that are currently in production! I'm not sure you've ended up with anything less error prone and you're still going to need a way to get from a fresh VM image and your output images - which is where Puppet would come in. I'd really rather not make the entire disk image my build artefact, for fairly obvious reasons (ie: size). You might like this, which is written by a colleague of mine, except that it is not in "opposition" to Puppet/Chef/etc: http://martinfowler.com/bliki/ImmutableServer.html http://martinfowler.com/bliki/ImmutableServer.html
  - _bpo 13y ago
    "Immutable Server" seems like an oxymoron. Frequent refreshes are great, but your system is only doing something useful once it has "mutated" (i.e. accepted external data to operate on). The tradeoff system designers have to make is frequency of refreshes vs the cost of transferring interesting data to that server. Seems like your organization has just coined a new synonym for "gold master"

contingencies 13y ago

> isn't a cleaner solution, this is almost the solution you get when you use Puppet The difference betwen deploying an instance of a stored environment and generating that environment from some prior state is the generative process, which can fail or change in unexpected ways due to network conditions and other factors. More importantly, PFCTs enable and to some extent encourage modification of generated environments remotely, en-masse, without any significant capacity to ensure that individual instances within a group have not subtly shifted in configuration. This is what I meant by configuration drift. CSIEs, by contrast, are essentially the complete product of the entire generation process, thus ensuring that future instantiations are identical. A subtle difference, but an important one.

drivebyacct2 13y ago
If used properly they should have an identical result.
- contingencies 13y ago
  Perhaps. The problem is, if you use PFCT on a bunch of hosts and something subtle changes that can cause issue, the granularity of the PFCT doesn't necessarily equate to that required for detecting the cause. With a CSIE-style atomic approach to deployment and a properly segregated monitoring system, you can, say, 'roll back' to the last known good version. PFCTs leak state, and will not always allow you this reverse pathway (random examples might include kernel feature or compiler version migration).
calpaterson 13y ago
> This is what I meant by configuration drift. I forgot to mention this before, it is strange that you credit yourself with defining this term when it has been well defined for some time in ops. > More importantly, PFCTs enable and to some extent encourage modification of generated environments remotely, en-masse, without any significant capacity to ensure that individual instances within a group have not subtly shifted in configuration. But this adds a significant weight over and above the "generative process" of running manifests. Yes, running manifests against your VMs can "fail or change in unexpected ways due to xyz" - don't do it against VMs that are currently in production! I'm not sure you've ended up with anything less error prone and you're still going to need a way to get from a fresh VM image and your output images - which is where Puppet would come in. I'd really rather not make the entire disk image my build artefact, for fairly obvious reasons (ie: size). You might like this, which is written by a colleague of mine, except that it is not in "opposition" to Puppet/Chef/etc: http://martinfowler.com/bliki/ImmutableServer.html http://martinfowler.com/bliki/ImmutableServer.html
- _bpo 13y ago
  "Immutable Server" seems like an oxymoron. Frequent refreshes are great, but your system is only doing something useful once it has "mutated" (i.e. accepted external data to operate on). The tradeoff system designers have to make is frequency of refreshes vs the cost of transferring interesting data to that server. Seems like your organization has just coined a new synonym for "gold master"