4 ms·
At some point in my organization's press toward Ansible, I came to the realization that Ansible the product is yet another layer of abstraction that is there fo
by devchix 5y ago
At some point in my organization's press toward Ansible, I came to the realization that Ansible the product is yet another layer of abstraction that is there for its own sake, and of dubious value. I converted a simple script to patch stuff, something that is trivial to write and run, and the yum module behaves different enough from the command-line yum that I have to learn a different way to get and parse the output. AWS logs also behave the same way, impossible to take up and read, quickly, trivially. Why do people read logs? To find out what happened, and do so quickly. Someone will argue that logs are so verbose we need to make them machine-friendly vs. people-friendly, so we can make tools to process them. Somewhere in the past 5 years we've gone toward making things more tool-friendly that humans can no longer interact with them in meaningful way. Some time in the future when something else supplants Ansible, shell will still be there, and still works. Meanwhile, I crib from Ansible docs and StackOverflow just to get things to work the way it did, and the pay-off is ... what exactly?
Edited to add:
Years ago Solaris10 converted the rc boot scripts to what was systemd precursor, SMF. I drank the koolaid, yes! we can build dependencies now, we have service-level kernel events now! I can get rid of daemons and watchdog scripts now! The innards of SMF was indecipherable XML, dependencies grew, you could no longer find a good system view when you ask SMF, and you couldn't easily find and fix what's wrong with the service file. At the time, it was designed to be un-messed-around-with by keyboard-happy warrior greybeard sysadmins, judged to be a source of instability and inconsistency.
- commandlinefan 5y ago> another layer of abstraction that is there for its own sake, and of dubious value Wait until you see Spring Boot.
- honkycat 5y agoI agree ansible is bad, but it is NOT the state of the art. Honestly its kind-of old and dead at this point replaced by stuff like CDKs. Programming in YAML sucks. YAML based solutions will always come up short because you cannot develop proper abstractions so you end up with a big bowl of copy-pasta amd indecipherable work-arounds. IMO the modern web is all based around adding types to systems because we've realized the extra toil types require make large systems have fewer bugs and more maintainable.
- rhn_mk1 5y agoWhat are CDKs?
- em-bee 5y agocloud development kit if i am not mistaken
- em-bee 5y agowhen i evaluated ansible and saltstack a few years ago, i went with saltstack because the ansible example felt much more like programming in yaml, while the salt example was much more declarative. i am still not happy with yaml, but i haven't seen any better alternative than saltstack yet. cloud development kits seem to target cloud APIs only and don't look like they could work for just a bunch of computers
- fpoling 5y agoThis is the my experience as well. For an activist website that I maintain I just use a PHP script to install everything and to ensure that everything has proper permissions. The site uses Wordpress and patching config files in PHP is simpler than in bash. I am glad that I have not bothered with Ansible, as I would most likely ended up with YAML programming which is way worse than bash.
- anthk 5y agoPerl was made exactly for that.
- fpoling 5y agoThat would require another language to know to maintain the script while Wordpress already requires some PHP knowledge. PHP is very OK for that. The only significant gripe is that even with PHP 7 the language does not have a utility to start an external program directly without going through shell and the need to escape arguments.
- ericbarrett 5y agoI'm with you on logs. The recent trend of "machine-readable" logs, encapsulated as JSON structs, adds so much complexity to the process, and makes them unscannable to the human eye. And yet for general use cases you're not getting anything a regex couldn't parse out of the log prefix. In 2010 I could search a terabyte of logs with grep -F in under a minute. With a "modern" setup you can't even see your logs until you have Elisticsearch up and running.
- devchix 5y ago> encapsulated as JSON structs, adds so much complexity to the process Or XML, you need to have written a parser (or pay Splunk to do it for you), you have to know how deeply nested your param of interest is. AFAIU Splunk has problems with too-deeply nested JSON, it was written at the time of unstructured logs. I can say this with confidence, for most of my problem cases, a good start to finding the culprit was a good tail -f and grep. I doubt myself and frequently ask if I'm one of those idiots who'd rather have faster horses. I mean, those are brilliant people making money hand over fist with their log analytics and event management tools, they know what they're doing, right? Right?