Ansible

A little post about automation with Ansible

Just to show the main differences. Ansible is a procedural tool (one or more tasks), Puppet is traditionally a declarative tool (defined system configuration). However, Puppet more features these days, the lines are a bit blurred. There is a commercial version of each, with powerful user interface and features, but the community edition is free to use. There are other tools, such as Chef and Saltstack.

For Ansible, it’s a deploy via SSH and Python, no agents and no extra software dependencies. Generally a user would checkout a GIT code branch and deploy some or all of those files to the remote hosts. Because its SSH, key pairs are helpful in ensuring the target action happens with the right permissions.

Ansible has modules so in addition to delivering files, it can extract zip archives, add users, install packages, enable services and so on. A procedural configuration of the remote host. One or more actions in sequence, targeting remote systems in parallel.

Ansible is idempotent so all the actions are a specified state (service=on, user=exists, and so on). If the result is “no change” then nothing is done, so you can schedule it and repeat it without any consequences.

Ansible uses an “inventory” file containing all the hosts you might target. You reference  the inventory file with your commands, this is /etc/ansible/hosts by default, or it can be in your home directory. You can use host name groupings in the inventory, and reference hosts using wildcards.

File copy examples (-b means become user/root, -m is the module, -i the inventory):

ansible websvr* -b -i my.inv -m file -a "name=/tmp/sw state=directory mode=0700 owner=apache group=apache"
ansible websvr* -b -i my.inv -m copy -a "src=git/test.txt dest=/tmp/sw/new.txt mode=0600 owner=apache group=apache"
ansible websvr* -b -i my.inv -m unarchive -a "src=git/software.zip remote_src=no dest=/tmp/sw"

Here are some more examples for running commands,

ansible melsmn* -i my.inv -m command -a "ln -s .bash_profile .profile"
ansible fxbatch -i my.inv -m shell -a "\"runInstaller.sh > /tmp/my.out\""
ansible fxlinux -b -i my.inv -m yum -a "name=epel-release state=present"
ansible fxlinux* -b -i my.inv -m service -a "name=firewalld state=started enabled=yes"

Often you will want to deploy a larger configuration, so you can write a playbook for that. The playbook can be checked in with GIT for version control.

ansible-playbook -i my.inv redhat7security.play

The playbook might contain tasks like this,

- hosts: redhat7
  become: yes
  tasks:
  - name: ensure these packages are installed
   yum: state=present name={{ item }}
    with_items:
    - mlocate
    - yum-cron
  - name: run open-vm-tools
    service: name=vmtoolsd enabled=yes state=started
  - name: etc profile
    copy: src=/foxtel/redhat7/etc_profile dest=/etc/profile owner=root group=root mode=0644


…and so on. With Ansible, you would maintain the playbooks for particular systems and services (eg . Linux Directory Server). Then if you add or remove a server all you need to do is update the inventory file and re-run the playbook.

Ansible is much easier to learn and get started than Puppet and is quite effective when you have the SSH keys and sudo sorted. Unlike Ansible, Puppet uses an agent that has full acccess.

One tip - make sure the Ansible host has plenty of memory if you will use it to deliver large software packages.

I hope you find this information useful.

Comments

Popular posts from this blog

Allow me to introduce myself