Just as a follow up, now that I've been able to dig into this project - I settled on ansible. Even for a single system, this is a very clear win over what I was doing before, and I wish I had done it sooner, and I *really* wish the former IT guys that I inherited stuff from had done it sooner.
For a single system, was it a net time gain? No. I think it was a net time sink. But there are some huge benefits that make it worthwhile. #0 The time sink was surprisingly small. I found, for basically everything I wanted to do, I would just google for it and immediately find exactly what I want. Search for "ansible localtime" or "ansible timezone" and people have already written exactly what you want. Ansible's module index is well organized and intuitive, well documented, easy to use. Covers almost everything I could want - For some things, the old way was faster. For other things, the new way is faster. For example, simply installing a yum package was probably faster before - because I would paste a command and there was nothing to gain over that. The new way, by the time I figured out what package I need to install, I could have had it installed before I wrote the command in the playbook. However, many things are actually faster the new way - because as mentioned below, it's difficult to script "Find the line 'enabled=0' in the [foobar] section of the config file and change that line to 1" whereas, ansible handles that perfectly because it knows how to parse that config file. #1 now that I'm familiar with the tool, there's literally no reason I would ever go hand-edit config files on that system ever again, which makes it completely native and natural for every single config change to be documented and executable. I formerly had things written like "Go edit sshd_config, find the place where it says "foobar" and change it" ... And even when shell scripting something, it's difficult to script something like "Edit the yum repo file, find the [epel] section (not to be confused with the other [blah] sections) and the location where it says Enabled=0 specifically within the [epel] section, and change it to 1" ... But ansible handles this no sweat. Because it knows how to parse ini files. As follows: ini_file: dest=/etc/yum.repos.d/epel.repo section=epel option=enabled value=1 #2 Formerly, I had a combination of instructions and commands to copy and paste, and executable shell scripts to run on a new server to configure it. I have now converted all that into a single document with minimal instructions to get up to the point where ssh is available, and then an ansible playbook takes everything from that point onward. I have found in the past, that my documentation with commands and scripts, would sometimes either break or human error would occur, pasting something in the wrong order or something like that. Now there's no possibility of human error anymore - Yes it's possible for a new OS environment to become incompatible with something in the playbook, but the playbook will actually *stop* and notify me of which thing went wrong, whereas a shell script error would bomb onward, and if you're lucky maybe you can understand what went wrong by the error message (I emphasize, if you're lucky.) #3 I have gained freedom. Formerly, I felt locked in, if I ever need to rebuild this server for some reason, I know it would be a significant hassle in terms of time suck and potential error. No more! If I want to move this thing from Amazon to Digital Ocean, or whatever... No hesitation. Total confidence. If I leave this job and I want to make sure my successor knows what I did and how to manage it... Awesome! Job done. Yes, this was highly worthwhile, for the sake of consistency and repeatability, etc. _______________________________________________ Tech mailing list Tech@lists.lopsa.org https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech This list provided by the League of Professional System Administrators http://lopsa.org/
