for one of my clients, i just had the opportunity to learn ansible and use it for the first time. i have quite a bit of experience with automation, from way back in my Solaris/Unix/Linux admin days. and have even written several custom automation systems for clusters of machines. I've also used various config management systems to do some of the things you can do with ansible. i'm mentioning this to give a sense of what my context is as I learned about ansible.
all that said, i was excited to see what i could learn about ansible and dove right in to it. i pretty much read the entire online manual/documentation straight through and several examples too. my first impression was that the authors of the documentation seem to be drinking too much cool-aid. they made it sound like ansible was the greatest thing since sliced bread; and in my opinion embellishing a bit much. I really wish they wouldn't do that, because anyone using ansible eventually hits reality and if the dichotomy between the hype and reality is too great, it can be rather unsavory. my biggest gripe on this subject is how ansible is touted as a "simple" tool, and how it was designed with "simplicity" in mind ; i found that to be completely untrue. although yaml is human readable and potentially friendly to folks who are not programmers, having an accurate understanding of the nested structures, variable scopes, how jinja2 comes into play, the various data structures that are possible, and all the features and limitations of the various modules does not exemplify simplicity. frankly, i didn't find it simpler than any other automation/config management/orchestration tools i've seen before.
the documentation author's embellishment aside, and the fact that it really isn't as simple as it is touted to be, doesn't necessarily mean it's a poor tool. having been messing around with code in many languages since i was kid, "simplicity" isn't one of my requirements. disassociating myself from the facts about the tool versus the embellishments of the authors i moved on and started to write my own ansible tasks/plays/playbooks.
first thing I noticed is that a lot of the modules were very limiting. as I was reading the documentation I made mental notes of the various modules I encountered keeping in mind that I might be able to use this or that module for what I needed to do. but when I started writing my plays/tasks, I realized I couldn't use them. a couple of examples:
- the 'archive' module has no builtin way to use the 'exclude' option, which I needed to create a tarball of source code while excluding the .git sub-directory and a few other things.
- the 'file' module can set attributes/owner/group/mode on files and directories, but i found no way for it to work with glob patterns easily, or distinguish between files and directories, etc.
- there was no module to move files. so i had to do a move with "shell", and then set owner/group/mode as a second step, often using another "shell" task due to aforementioned issues with 'file' module.
- the 'yum' module has no option for 'reinstall', which I needed to force a reinstall of some packages in a test /dev environment where the package versions didn't increment.
anyway, i found myself using the 'shell' module more than anything else where I can simply pass it a series of shell commands to accomplish what I needed. i found this ironic, because the documentation, and even the output from running ansible encourages the user to try to use the provided modules as much as possible. but i found too many instances where the available modules were too limiting and having to resort to using 'shell'. as a newbie to all this, i really wish that was pointed out to me in the documentation : "just use the shell module if it isn't obvious that the provided modules can do that job". I spent too much time re-reading the documentation of the various modules and searching online (google,stackoverflow, etc.) for a solution only to realize i can solve my problems in a fraction of the time just using "shell".
so I finally got a few plays and playbooks put together. one of the things I wanted to automate was a "port" of another ad-hoc automation script I had written previously that went out to a "build" server that pulled down code, built it into RPM package files, push them to a "repo" server, update the repo meta data, and then connected to a cluster of servers in a dev environment to update or reinstall the latest build. i thought this would be a good exercise to cut my teeth with ansible. well, i did it and it works.... but very, very slowly. my "original" script is probably about 1 order of magnitude faster. actually, the ansible stuff was so slow, I might have been just as fast running those command by hand and ssh'ing into each box. yeah, sure, it worked... but that was just really sad.
not being one to give up easily, i started to do more research about ansible performance. found others who shared my problem, but some information seemed outdated or no longer relevant so I had to dig deeper. read about the accelerator mode, using ssh cp, and eventually, found out about the "pipelining=true" feature and tried that out. sure enough, that did make a big difference; it was no longer as slow as manually running commands, yet it is still slower than my "original" script. and that's where I'm at right now.
my impression so far is that it's a good tool and I can see how it can be very useful, but it seems not mature enough yet. that doesn't mean one shouldn't use it, in spite of everything, i would still use it - i would just keep in mind that it isn't quite as "simple" and not to hesitate to use "shell" more often than not. i think it has a lot of potential, but it's not quite there yet. at least those are the impressions of this ansible newbie - but i'll reserve the right to change my opinion as I continue to improve my knowledge & skill with ansible.
all that said, i was excited to see what i could learn about ansible and dove right in to it. i pretty much read the entire online manual/documentation straight through and several examples too. my first impression was that the authors of the documentation seem to be drinking too much cool-aid. they made it sound like ansible was the greatest thing since sliced bread; and in my opinion embellishing a bit much. I really wish they wouldn't do that, because anyone using ansible eventually hits reality and if the dichotomy between the hype and reality is too great, it can be rather unsavory. my biggest gripe on this subject is how ansible is touted as a "simple" tool, and how it was designed with "simplicity" in mind ; i found that to be completely untrue. although yaml is human readable and potentially friendly to folks who are not programmers, having an accurate understanding of the nested structures, variable scopes, how jinja2 comes into play, the various data structures that are possible, and all the features and limitations of the various modules does not exemplify simplicity. frankly, i didn't find it simpler than any other automation/config management/orchestration tools i've seen before.
the documentation author's embellishment aside, and the fact that it really isn't as simple as it is touted to be, doesn't necessarily mean it's a poor tool. having been messing around with code in many languages since i was kid, "simplicity" isn't one of my requirements. disassociating myself from the facts about the tool versus the embellishments of the authors i moved on and started to write my own ansible tasks/plays/playbooks.
first thing I noticed is that a lot of the modules were very limiting. as I was reading the documentation I made mental notes of the various modules I encountered keeping in mind that I might be able to use this or that module for what I needed to do. but when I started writing my plays/tasks, I realized I couldn't use them. a couple of examples:
- the 'archive' module has no builtin way to use the 'exclude' option, which I needed to create a tarball of source code while excluding the .git sub-directory and a few other things.
- the 'file' module can set attributes/owner/group/mode on files and directories, but i found no way for it to work with glob patterns easily, or distinguish between files and directories, etc.
- there was no module to move files. so i had to do a move with "shell", and then set owner/group/mode as a second step, often using another "shell" task due to aforementioned issues with 'file' module.
- the 'yum' module has no option for 'reinstall', which I needed to force a reinstall of some packages in a test /dev environment where the package versions didn't increment.
anyway, i found myself using the 'shell' module more than anything else where I can simply pass it a series of shell commands to accomplish what I needed. i found this ironic, because the documentation, and even the output from running ansible encourages the user to try to use the provided modules as much as possible. but i found too many instances where the available modules were too limiting and having to resort to using 'shell'. as a newbie to all this, i really wish that was pointed out to me in the documentation : "just use the shell module if it isn't obvious that the provided modules can do that job". I spent too much time re-reading the documentation of the various modules and searching online (google,stackoverflow, etc.) for a solution only to realize i can solve my problems in a fraction of the time just using "shell".
so I finally got a few plays and playbooks put together. one of the things I wanted to automate was a "port" of another ad-hoc automation script I had written previously that went out to a "build" server that pulled down code, built it into RPM package files, push them to a "repo" server, update the repo meta data, and then connected to a cluster of servers in a dev environment to update or reinstall the latest build. i thought this would be a good exercise to cut my teeth with ansible. well, i did it and it works.... but very, very slowly. my "original" script is probably about 1 order of magnitude faster. actually, the ansible stuff was so slow, I might have been just as fast running those command by hand and ssh'ing into each box. yeah, sure, it worked... but that was just really sad.
not being one to give up easily, i started to do more research about ansible performance. found others who shared my problem, but some information seemed outdated or no longer relevant so I had to dig deeper. read about the accelerator mode, using ssh cp, and eventually, found out about the "pipelining=true" feature and tried that out. sure enough, that did make a big difference; it was no longer as slow as manually running commands, yet it is still slower than my "original" script. and that's where I'm at right now.
my impression so far is that it's a good tool and I can see how it can be very useful, but it seems not mature enough yet. that doesn't mean one shouldn't use it, in spite of everything, i would still use it - i would just keep in mind that it isn't quite as "simple" and not to hesitate to use "shell" more often than not. i think it has a lot of potential, but it's not quite there yet. at least those are the impressions of this ansible newbie - but i'll reserve the right to change my opinion as I continue to improve my knowledge & skill with ansible.
