Gfrktyl

I establish a LAMP with a few extras on a remote Debian machine with a similar shell (Bash) script:

#/bin/bash



apt update -y

apt upgrade ufw sshguard unattended-upgrades wget curl git zip unzip tree -y



ufw --force enable

ufw allow 22,25,80,443



apt upgrade lamp-server^ ssmtp

apt upgrade python-certbot-apache

apt upgrade php-{cli,curl,mbstring,mcrypt,gd} phpmyadmin



curl -sS https://getcomposer.org/installer -o composer-setup.php

php composer-setup.php --install-dir=/usr/local/bin --filename=composer



cat <<-EOF > /etc/php*/conf.d/local.ini

    upload_max_filesize = 2000M

    post_max_size = 2000M

EOF



a2enmod http2 deflate expires

Some sysadmins who saw a similar script told me sayings like "you better do it with Ansible because otherwise it will be a nightmare to maintain it".

Well, I can achieve basically the same with the following Ansible playbook I wrote (and have yet to test because I don't have a free machine right now but should work when deployed to all machines):

---



- hosts: all 

  become: yes

  become_user: root

  tasks:



    - name: Update apt package-indexes cache

      apt:

        update_cache=yes



    - name: Install external basics

        apt: state=latest

          with-items:

            - ufw

            - sshguard

            - unattended-upgrades

            - wget

            - curl

            - git

            - zip

            - unzip

            - tree



    - name: Setup firewall with ufw

      ufw:

        rule: allow

        port: 22,25,80,443



    - name: Establish a LAPMS (Linux, Apache, PHP, MySQL, SSMTP) server environment

        apt: state=latest

          with-items:

            - apache2 # Web server

            - python-certbot-apache

            - php

            - php-mysql # MySQL server 

            - php-cli

            - php-curl

            - php-mbstring

            - php-mcrypt

            - php-gd

            - ssmtp # Email server

            - phpmyadmin



    - name: Install Composer

      get_url:

        url: https://getcomposer.org/installer

        dest: /tmp/composer-setup.php

      command: php /tmp/composer-setup.php --install-dir=/usr/local/bin --filename=composer



    - name: Configure PHP variables

      shell: |

        cat <<-EOF > /etc/php*/conf.d/local.ini

          upload_max_filesize = 2000M

          post_max_size = 2000M

        EOF

      args:  

        executable: /bin/bash



    - apache2_module:

    state: present

    name: http2



    - apache2_module:

    state: present

    name: deflate



    - apache2_module:

    state: present

    name: expires

My contemplation

I don't recognize a significant advantage of using mere Ansible over mere shell-scripting in the above trivial case as Ansible does only what we tell it to and doesn't do release_upgrades (as from Apache 2.4 to 3.4) and will basically give me the same apt upgrade -y automation with scheduling (say with cron) so I can't understand how it will be much of a helper (also the result is basically same but the number of lines is far greater (72 instead 20/21) unless one uses Ansible-Galaxy roles which are well organized programs containing a core of one or more Ansible playbooks.

My question

How does mere Ansible by itself (without using Ansible-Galaxy roles) more efficient than mere shell-scripting in general and Bash in particular in a trivial task such as the above?

I do not think there is a big problem with 20 lines, as a shell script for an individual machine or two. That is a good thing to have.

That said, your script is not idempotent. For example it uses apt-get upgrade foo, which can perform changes even if the script has already been run on this system. I do not think it worth using apt-get upgrade foo. That command does not guarantee to apply security or bugfix updates to your dependencies.

A carefully written Ansible playbook can double as a small system check. This relies on the playbook being idempotent (and also that it reports "changed" status accurately). Running ansible-playbook --check will show whether the system still meets all the defined tasks, or whether it has been changed. This can both be useful later on, and also to look for inconsistencies immediately after running a playbook.

And you may set up Ansible so you can run this on several machines at once.

Configuration tools like Ansible are useful at scale. Partly due to these sorts of features. Partly due to these sorts of constraints, which it encourages you to follow.

Encouraging you to write idempotent scripts can also be useful for maintenance. Consider the temptation to write a script that adds lines to an existing file (or adds tokens inside an existing line :-( ). If you ensure idempotence, then you can re-run the modified script without adding duplicate lines.

Another constraint is if you ever want to remove things from an installed system. In many cases this is not a problem, and you could always write an uninstall script/playbook later on. But in some cases you need to be careful about this. E.g. you might want to make sure not to use Ansible lineinfile to replace an individual line, and instead overwrite the entire file with your own version. This can be useful when you no longer want to change line A from the default, but you still want to change line B.

For my usage, I would like to address the removal problem when managing firewalls. If you stop allowing a port in your install script, you might forget to explicitly block the port everywhere. The Ansible ufw module does not help here, because it only allows adding or removing individual rules. I am currently thinking about using an alternative to the ufw firewall, which has proper support for working from configuration files. (E.g. firewalld, shorewall, ferm ...).

The difference between Bash and Ansible is that Ansible, when written properly, is idempotent. There are no changes when a playbook runs repeatedly. In this respect Bash script describes a procedure while Ansible playbook rather describes a state of a system.

To address the comment

"not sure I understand idempotent well enough to understand the answer".

Idempotence means that a playbook "can be applied multiple times without changing the result beyond the initial application". Best practice is to run a playbook twice. During the first run a playbook performs all changes. During the second run no changes should be reported.

One of the main selling points of Ansible is that playbooks tend to be easier to read than dense BASH one liners due to its use of YAML syntax. You can also use linters and debuggers in a more feature rich way than you can with BASH scripts, and some IDEs even have built in Ansible text completion modules to assist with writing playbooks.