Many developers and system administrators manage Servers by logging into them via SSH making changes and logging off. If an admin needs to apply same change to many servers (for example, changing one value in a config file), the admin will have to manually log into each server and make this change repetitively. There are tools which help you to configure these servers uniquely and recreate from scratch without documentation because they are hand-configured. Ansible is powerful IT automation that you can learn quickly. Also, centralize and control your infrastructure easily. 

Ansible and Infrastructure Management

Ansible was built by developers and sysadmins with command line language. The main focus behind building this tool was to manage servers in a centralized way while performing the repetitive process.

Ansible works by pushing changes to all your servers (by default) and requires no extra software to be installed on your servers, unlike most other configuration management tools.

Ansible Architecture:

The above diagram shows the basic architecture of Ansible. The host inventory file determines the target machines where these playbooks will be executed. The remote servers should have Python installed. The Ansible-playbooks consist of one or more tasks that are expressed either with core modules that come with Ansible or custom modules that you can write for specific situations. The plays(tasks)  are executed sequentially from top to bottom, so there is no explicit order that you must define. Playbooks are declarative in nature and are written in YAML. This takes the declarative simplicity of such systems to a different level.

Installation of Ansible

Ansible’s real dependency is Python. Once Python is installed, the simplest way to get Ansible running is to use pip, a simple package manager for Python.

• Red Hat Enterprise Linux/CentOS:

The easiest way to install Ansible on a Fedora-like system is to use the official yum package. If you’re running Red Hat Enterprise Linux (RHEL) or CentOS, you need to install EPEL’s RPM before you install Ansible.

If you’re on RHEL/CentOS 6:

$ rpm -ivh http://dl.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm

If you’re on RHEL/CentOS 7:

$ yum install epel-release

Install Ansible using the following command:

$ yum -y install ansible

• Debian/Ubuntu:

The easiest way to install Ansible on a Debian or Ubuntu system is to use the official apt package.

$ sudo apt-add-repository -y ppa:ansible/ansible

$ sudo apt-get update

$ sudo apt-get install -y ansible

Once Ansible is installed, make sure it’s working by entering ansible –version on the command line:

$ ansible –version

Configuring Ansible Hosts

Ansible keeps track of all the servers that it knows about through a “hosts” file. We need to set up this file first before we can begin to communicate with our other machines.

Open the file with root privileges like this:

$ sudo vi /etc/ansible/hosts

Edit this host file with nano, vim, or whatever editor you’d like, but note you’ll need to edit it with sudo as root. Put the following into the file:

[example]

www.example.com

where an example is the group of servers you’re managing and www.example.com is the domain name (or IP address) of a server in that group.

Ansible Concepts

• Playbooks
• Inventory
• Roles
• Tasks / Handlers / Vars
• Modules

PLAYBOOKS:

• Playbooks are Ansible’s configuration, deployment, and orchestration language. They describe a policy you want on your remote systems to enforce or a set of steps in a general IT process.
• Playbooks are expressed in YAML format. Each playbook is composed of one or more ‘plays’(Tasks) in a list.
• The goal of a play is to map a group of hosts to some well-defined roles, represented by things ansible calls tasks.

file: sample-playbook.yml

– name: reboot the machines

hosts: all

tasks:

– name: uptime of the machine

command: uptime

INVENTORY:

• Inventory files are simple text files which describe your servers IP Addresses or DNS Names grouped by name list of target hosts.
• It located in /etc/ansible/hosts. Inventory files can take advantage of variables and enumerations.

ROLES:

• Roles are ways of automatically loading certain vars, files, tasks, and handlers based on a known file structure.
• Grouping content by roles also allows easy sharing of roles with other users. Roles can be shared and pulled from Ansible Galaxy, GitHub, etc.

TASKS(Plays):

• Each playbook contains a list of tasks. Tasks are executed in order, one at a time, against all machines matched by the host pattern, before moving on to the next task.
• The goal of each task is to execute a module, with very specific arguments.

HANDLERS:

• Handlers are one of the conditional forms supported by Ansible. A handler is similar to a task, but it runs only if it was notified by a task.
• An example situation where handlers are useful is when a task modifies a configuration file of some service, MySQL for example. In order for changes to take effect, the service needs to be restarted.

– name: change mysql max connections
template: src=edited_my.conf dest=/etc/foo.conf
notify:
– restart mysql
handlers:
– name: restart mysql
service: name=mysql state=restarted

Notify keyword acts as a trigger for the handler named “restart_mysql”.

MODULES:

• Modules should be idempotent. If modules apply multiple times in a sequence then it should have the same effect as applying just once. If all the modules a playbook uses, are idempotent, then the playbook itself is likely to be idempotent, so re-running the playbook should be safe.

Executing a playbook:

Example of playbook.yml which install and start HTTP service.

playbook.yml

Command: Ansible-playbook playbook.yml

Output:

PLAY [127.0.0.1] ***************************************************************************

TASK [Gathering Facts] ***************************************************************************

ok: [127.0.0.1]

TASK [ensure apache is at the latest version] ********************************************************

changed: [127.0.0.1]

TASK [ensure apache is running (and enable it at boot)] ********************************************

changed: [127.0.0.1]

PLAY RECAP ***************************************************************************

127.0.0.1 : ok=3 changed=2 unreachable=0 failed=0

Advantages of Ansible

• Clear – Ansible uses a simple syntax (YAML) and is easy for anyone (developers, sysadmins and managers) to understand. APIs are simple and sensible.
• Fast – Fast to learn, fast to set up – especially considering you don’t need to install extra agents or daemons on all your servers.
• Complete – Ansible does three things in one and does them very well. Ansible’s ‘batteries included’ approach means you have everything you need in one complete package.
• Efficient – No extra software on your servers means more resources for your applications. Also, since Ansible modules work via JSON. Ansible is extensible with modules written in a programming language Python you already know.
• Secure – Ansible uses SSH, and requires no extra open ports or potentially vulnerable daemons on your servers.

Conclusion:
Of course, while choosing any tool you need to get familiar with its capabilities, weaknesses. The documentation of Ansible is excellent and there is a huge variety of built-in tasks. Ansible is configured to communicate with the servers that you would like to control. It is capable to configure and manage servers, deploy code along with few other tasks that may be needed in the deployment process. No special coding skill needed for Ansible.

The post Ansible – Server and Configuration Management appeared first on DevOpsTech Solutions.