Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

Ansible is a very popular configuration management and administration tool for Linux servers. It's an agentless configuration management tool that operates in a push model (note its also possible to configure in a pull model but that will be treated as out of scope here). Over the past few years, it's gained a wide following due to its simplicity and active user base.


There is extensive documentation on Ansible at https://docs.Ansible.com/

The current version of Ansible at the time of writing is version 2.9.


While we don't want to reiterate what is already in the Ansible documentation, the tool can be very useful when it comes to Swarm cluster administration. In this KB article, we'll go through basic setup and config.

Installation

The simplest way to install Ansible is to use yum on a RHEL / CentOS based server. This will typically get you version 2.1 or 2.3 of Ansible (which isn't the latest version) but this would still be usable for most operations.

To get a more up-to-date version, install epel-release first and then install Ansible:

[root@caringoadminserver /]# yum install epel-release -y 

[root@caringoadminserver /]# yum install ansible
Loaded plugins: fastestmirror, langpacks
Loading mirror speeds from cached hostfile
* base: mirror.ox.ac.uk
* epel: fedora.cu.be
* extras: ftp.heanet.ie
* updates: mirror.sov.uk.goscomb.net
Resolving Dependencies
--> Running transaction check
---> Package ansible.noarch 0:2.9.3-1.el7 will be updated
---> Package ansible.noarch 0:2.9.6-1.el7 will be an update
--> Finished Dependency Resolution

Dependencies Resolved

================================================================================================================================
Package Arch Version Repository Size
================================================================================================================================
Updating:
ansible noarch 2.9.6-1.el7 epel 17 M

Transaction Summary
================================================================================================================================
Upgrade 1 Package

Total download size: 17 M
Is this ok [y/d/N]: y
Downloading packages:
epel/x86_64/prestodelta | 2.2 kB 00:00:00
ansible-2.9.6-1.el7.noarch.rpm | 17 MB 00:00:03
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
Updating : ansible-2.9.6-1.el7.noarch 1/2
Cleanup : ansible-2.9.3-1.el7.noarch 2/2
Verifying : ansible-2.9.6-1.el7.noarch 1/2
Verifying : ansible-2.9.3-1.el7.noarch 2/2

Updated:
ansible.noarch 0:2.9.6-1.el7

Complete!
[root@caringoadminserver /]#


As you can see, there are minimal dependencies required for Ansible that are taken care of during the install procedure above.

Ansible uses parallel ssh sessions to manage the hosts and this can be configured to use existing ssh keys. The managed hosts should be set up to use password-less auth from the server where Ansible is installed.

For simplicity we'll use the root user for now as that is available on all systems. As a best practice, you should configure an Ansible user per system you plan to pull under orchestration so that user is used when making changes. 

Setting up password-less authentication

There's a good walk-through on Digital Ocean on key-based auth here: 

https://www.digitalocean.com/community/tutorials/how-to-configure-ssh-key-based-authentication-on-a-linux-server

... but we'll go through a basic version below.

First, we need an SSH key. The command to create this is:

ssh-keygen -t rsa

Follow the prompts to fill in details. Then, we can use the tool ssh-copy-id to copy the key to any systems that you would like to manage via Ansible.

For example, if we had a few servers called elasticsearchserver, cloudgatewayserver and platformserver we would use ssh-copy-id to copy the root keys this way.

[root@caringoadminserver /]# ssh-copy-id root@elasticsearchserverhostnameorip
[root@caringoadminserver /]# ssh-copy-id root@cloudgatewayserverhostnameorip
[root@caringoadminserver /]# ssh-copy-id root@platformserverhostnameorip

using ip addresses

[root@caringoadminserver /]# ssh-copy-id root@192.168.1.10

[root@caringoadminserver /]# ssh-copy-id root@192.168.1.20

[root@caringoadminserver /]# ssh-copy-id root@192.168.1.5


Once the password-less auth is setup, the next step is to go back to Ansible configuration.

Ansible Host/Inventory files

The Ansible hosts file is a list of IP addresses or hostnames in groups that can be used to run commands against. This can be in INI or YAML (.ini or .yaml) format.

By default the location of the base inventory file is in /etc/ansible/hosts.

An example hosts file would look like this (INI format):

[csn]
192.168.1.5
[elasticsearch]
192.168.1.10
192.168.1.11
[gateway]
192.168.1.20
[allcaringo]
192.168.1.5
192.168.1.10
192.168.1.11
192.168.1.20


In the example above, the IP addresses could be replaced with host names as long as the Ansible host can resolve the host.

First Ansible command

There are a few different ways that you can use Ansible commands.

The first would be to use the Ansible command as-is. This operates Ansible in "ad-hoc" mode.

This mode allows you to run very basic commands against multiple hosts/groups of hosts.


For example:

[root@caringoadminserver /]# ansible allcaringo -m ping

You should receive a result similar to the below output:

[root@caringoadminserver ~]# ansible allcaringo -m ping
127.0.0.1 | SUCCESS => {
    "ansible_facts": {
        "discovered_interpreter_python": "/usr/bin/python"
    }, 
    "changed": false, 
    "ping": "pong"
}
172.29.0.3 | SUCCESS => {
    "ansible_facts": {
        "discovered_interpreter_python": "/usr/bin/python"
    }, 
    "changed": false, 
    "ping": "pong"
}
172.29.1.20 | SUCCESS => {
    "ansible_facts": {
        "discovered_interpreter_python": "/usr/bin/python"
    }, 
    "changed": false, 
    "ping": "pong"
}
172.29.1.21 | SUCCESS => {
    "ansible_facts": {
        "discovered_interpreter_python": "/usr/bin/python"
    }, 
    "changed": false, 
    "ping": "pong"
}
172.29.1.22 | SUCCESS => {
    "ansible_facts": {
        "discovered_interpreter_python": "/usr/bin/python"
    }, 
    "changed": false, 
    "ping": "pong"
}


Breaking this down, the Ansible command means we are using Ansible in ad-hoc mode.

The "allcaringo" section refers to the hosts in the host inventory we created earlier. If we were to replace "allcaringo" with "elasticsearch", the command would only apply to the 2 elasticsearch hosts we have defined.

The -m flag refers to the module we're using- in this case "ping".  Modules are pre-written tool sets that allow you to run commands against multiple hosts. 

There are hundreds of modules. Here are a few basic ones that are frequently used:

moduleusage
pingping a host
archivecompress a file
commandrun a command on a host
lineinfilechecks for a line of text in a file and adds it if it isn't present
servicestarts stops enables a service
urlmakes a http call to a url
yuminstall a package on a RHEL / CentOS based host
userinteract with PAM
templateapply a template of a file e.g. config file.

We'll review these and others in more detail in a separate article.


  • No labels