3 ms·
Horses for courses, it depends on what you're doing, but I've built Multi-£Bn production systems for the last decade on Puppet then Chef then Ansible (and now n
by vr46 6y ago
Horses for courses, it depends on what you're doing, but I've built Multi-£Bn production systems for the last decade on Puppet then Chef then Ansible (and now none of those) and I can't say that Ansible is very buggy these days nor does it fail at complexity. I mean, we found that provisioning with Packer using Ansible as the engine worked perfectly fine, nothing to do with PR material. Newer definitely isn't better, I would always go with reliable, battle-tested tech, but the old ways are largely pointless for most clients and developers who have long left behind artisan infrastructure. If tons of complexity is needed that baffles Ansible/Salt etc, I would be looking at the architects askew TBH...
- MPSimmons 6y agoAt my employer, we use a sensible bi-modal approach, where every machine gets a base configuration applied through Puppet, and we consider this The Platform, and any per-machine (or per-use-case) changes should be applied through an Ansible repo. Puppet lays down those things that the platform "promises"* to provide - syslog, time, auth, DNS, etc, and Ansible does application-specific things. * - Not a strict promise in the Mark Burgess "Promise Theory" sense, but similar in thought.
- trabant00 6y ago> If tons of complexity is needed that baffles Ansible/Salt etc, I would be looking at the architects askew TBH... Simple clean architectures can be deployed with anything. I judge a tool by it's ability to "make the easy things easy, and the hard things possible". But you do have a very good point here: > the old ways are largely pointless for most clients and developers who have long left behind artisan infrastructure I don't like that it is this way, maybe I'm just old fashioned. But yes. This is the way it is.