Ansible is an open source automation tool used to configure servers, install software and perform a wide variety of IT tasks from one central location. It is a one-to-many agentless mechanism where all instructions are run from a control machine that communicates with remote clients over SSH (although other protocols are also supported).
Though targeted for system administrators with privileged access who routinely perform tasks such as installing and configuring applications, Ansible can also be used by non-privileged users. For example, a database administrator (using the mysql account) could use Ansible to create MySQL databases, add users and define access level controls to databases.
Let’s go over a very simple scenario where a system administrator provisions 100 servers each day and must run a series of commands on each one before handing it off to users. So you run a series of commands that look like this:
$ groupadd admin$ useradd -c “Sys Admin” -g admin -m sysman$ mkdir /opt/tools$ chmod 755 /opt/tools$ chown sysman /opt/tools$ yum -y install httpd$ yum -y update$ systemctl enable httpd$ systemctl start httpd$ rm /etc/motd
These commands can be placed in an Ansible "playbook" and executed against your 100 servers in one shot:
- name: daily tasks hosts: my_100_daily_servers tasks: - group: name=admin state=present - user: name=sysman comment="Sys Admin" group=admin - file: path=/opt/tools state=directory owner=sysman mode=0755 - yum: name=httpd state=latest - yum: name=* state=latest - service: name=httpd state=started enabled=yes - file: path=/etc/motd state=absent
This example is very simple but should illustrate how easily commands can be specified in yaml files and executed against pre-defined servers. In a heterogeneous environment, conditional statements can be added so that certain commands are only executed in certain servers (i.e. “only execute yum commands in systems that are not Ubuntu or Debian”).
One powerful property of Ansible is that a playbook describes a desired state in a computer system, so a playbook can be run multiple times against a server without impacting its state. If a certain task has already been implemented (i.e. “user sysman already exists”) then it simply ignores it and moves on.
Over the next few weeks, I will publish a series of blogs with detailed examples of routine tasks that can be easily be implemented with Ansible, including tasks specific to Dell PowerEdge servers. Although Ansible is also supported on Windows using PowerShell, the blog series will focus exclusively on Linux. Towards the end of the series I will do a brief comparison with other popular configuration management tools such as Puppet and Chef.