How Ansible is different from shell or perl scripting?

100 views
Skip to first unread message

Kannappan M

unread,
Jul 23, 2017, 3:55:10 AM7/23/17
to Ansible Project
Hi  All,

could you  please  tell in layman language  how  ansible  different  from Shell or  pearl  scripting apart  from  Ansible  Orchestration  and  Ansible Tower

Regards
Kanna 

Jon Forrest

unread,
Jul 23, 2017, 12:28:11 PM7/23/17
to ansible...@googlegroups.com
One way to think about this is to examine a non-trivial Ansible playbook
and try to imagine how much work would be required to duplicate what
it does in bash or perl. It's important to include the capabilities
of inventory management, access control, and other features of Ansible.

Jon Forrest


Andrew Edelstein

unread,
Jul 23, 2017, 2:15:58 PM7/23/17
to ansible...@googlegroups.com
On 7/23/2017 2:55 AM, Kannappan M wrote:
> could you please tell in layman language how ansible different
> from Shell or pearl scripting apart from Ansible Orchestration
> and Ansible Tower

When done right, Ansible is "idempotent", which means if you run the
same script multiple times on the same host, it will only do what it
needs to do to configure the host. It will check the state of the thing
you have told it to change to determine if it needs to make the change.
If not, it moves on to the next step. With shell scripts, you have to
write that check in yourself, which can be rather complex. Example: you
want to enable a service. The "service" module will do this for you, and
you can "enable" it (configure it to start on boot) AND start it in a
single task. The module will check if the service is already enabled and
enable it if it needs to, and it will detect if the service is already
running and only start it if it's not running. With a shell script,
unless you specifically write in the logic to check if the service is
already running and just tell it to start the service, you'll probably
get an error. Similarly, if you tell it to REstart the service, the
module will do what it needs to do. If it's not running, it will start
it. If it is running, it will stop it first, then start it. In Red Hat,
if you just do "service X restart" it might handle that fine if it's not
running already, or it might not, depending how the start script was
written. Also, by using the "service" module, you don't have to worry
about what the correct command is to do that on Red Hat (or even RHEL 6
initd vs RHEL 7 systemd) vs Debian vs Suse. The module will figure that
out for you and you only have to write one task to work on all three.
(Note: this doesn't help if the name of the service is different on all
three, it only covers knowing the correct service restart command.
Apache is "httpd" on RHEL, but may be "apache" on Debian for instance.
In this case you'd need to account for this, but again, not hard to do
in Ansible.)

Also, though not necessarily an intentional part of the design, I find
it useful if I want to run the same command / script on multiple
servers. I don't have to write a complicated for loop in a shell script
to log into each host and run a command. If I want to gather a piece of
information from a dozen hosts, I can do a quick Ansible specifying the
hosts I want from my inventory and it will log into each of them and run
the command.

ex: I want to start Postfix on all my mail servers. I already have a
"group" in my inventory file called, appropriately "mailservers".

ansible -i inventoryfile mailservers -b -m service -a "name=postfix
state=started"

With a shell script I'd have to do something like:

for server in server1 server2 server3 server4 server5; do ssh
$server "if [! $(sudo service postfix status); then sudo service postfix
start; fi"; done

And I'm only about 85% confident that will work right without testing
it, and it will probably only work on a RHEL system, and assumes the
"postfix" init script accepts "status" as an argument.

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Reply all
Reply to author
Forward
0 new messages