Posts in Category: ansible

Comparison between Ansible and Puppet

Key differences between Ansible and Puppet:

  • No single master server. You can simply install ansible on any server and that can then act as the muster. In Puppet, that’s not possible because the puppetmasters url is hardcoded into each puppet agent’s puppet.conf file.
  • Orchestration is done via the “push” system rather than the “pull” system. I.e. you don’t need to log into ansible client and then trigger a ansible run.
  • The code  in a playbook is executed in the order that they are specified. Where that is not the case with puppet, where if you want you can specify ordering using the before/require metaparameters
  • Puppet is based on ruby. However Ansible is based on python, and you can write python code right into your ansible code. Python comes with a huge amount of

Ansible – Available setting to add to a playbook’s header section

- name:  blahblah
  hosts: hostname
  vars:
    var1: value1
    var2: value2
  vars_files:
    - /path/to/var1.yaml
    - /path/to/var2.yaml
  vars_prompt:             this key's value is a 2 item array, each item is a single item hash 
    - name: var_name         
    - prompt: the prompt message itself     # this will do a prompt for more info during runtime 
  sudo: 
  user:
  connection:
  gather_facts:

Note: by default behind the scenes the setup module always runs behind the scenes to collect facts. You can disable this


Ansible – A playbook for setting up an apache webserver

Here’s a simple playbook that sets up an Apache web server on a RHEL/CentOS 7 box:

[root@controller playbooks]# pwd
/root/playbooks
[root@controller playbooks]# cat httpd.yaml
---
- name: This sets up an httpd webserver
  hosts: ansibleclient01.local
  tasks:
  - name: Install apache packages 
    yum:
      name: httpd
      state: present
  - name: ensure httpd is running
    service:
      name: httpd 
      state: started
  - name: Open port 80 for http access
    firewalld:
      service: http
      permanent: true
      state: enabled
  - name: Restart the firewalld service to load in the firewall															

Ansible – Make the controller aware of it’s clients

Before the controller can manage the clients, it first need to provide ansible an  inventory of the clients it is allowed to manage. This inventory needs to be in the form of a file called “hosts”.

You can choose where you store the hosts file. But the default location ansible will look for the hosts file is specified in ansible’s main config file:

 

[root@controller ~]# cat /etc/ansible/ansible.cfg | grep "^inventory"
inventory = /etc/ansible/hosts

In my case, my file looks like:

 

$ cat /etc/ansible/hosts
# Ungrouped hosts, specify before any group headers.
ansibleclient01.local
ansibleclient02.local

# A collection of hosts belonging to the 'clients' group
[clients]
ansibleclient01.local
ansibleclient02.local

 

 

 

After that you can check if your controller  can ping it’s clients, you can run the following command:

 

$ ansible ansibleclient01.local -m ping
ansibleclient01.local | SUCCESS => {
 "changed": false,
 "ping": "pong"
}

 

Or you can ping a group of clients:

 

$															

Ansible – Installing Ansible

There are a few of ways to install ansible. For the rest of these articles I’ll be running Ansible on Centos 7.

Install Ansible using yum

This is done like this:

$ yum install epel-release
$ yum install ansible

Then check the version of ansible installed:

$ ansible --version

It is actually recommended to install ansible on all client’s and just the controller. That way the clients ends up installing all the python related dependencies.

 

However the downside with this approach is that the version of ansible that get’s installed is a few versions behind the latest stable version.

Install Ansible from source

To install a newer version, you can run this script as the root user:

After running the above script, log into the machine as the user, “ansible” and password “vagrant”.

Then check what version of ansible


Ansible – A “hello world” Playbook

Playbooks are written in yaml format, and you can actually choose where to store your playbooks. In my case I’ll create a folder called “playbooks” for storing my playbooks, and I’ll create this in the root user’s home directory:

 

[root@controller ~]# pwd
/root
[root@controller ~]# mkdir playbooks
[root@controller ~]# cd playbooks
[root@controller playbooks]# pwd
/root/playbooks

In this directory, I’ll then create the following file:

 

[root@controller playbooks]# cat HelloWorld.yml
---
- name: This is a hello-world example
  hosts: ansibleclient01.local
  tasks:
  - name: Create a file called '/tmp/testfile.txt' with the content 'hello world'.
    copy: 
      content: "hello world\n" 
      dest: /tmp/testfile.txt

This playbook is designed to create the file “/tmp/testfile.txt” on the client ansibleclient01.local using ansible’s copy module.

 

You can think of this playbook as a



Ansible – About this Course

What is Ansible

Ansible can be thought of as a multi-purpose tool for:

  • Cloud Infrastructure Automation – You can use it to build new virtual machines on popular cloud platforms, such as AWS and Azure. Another very popular tool that’s used for this kind of work is Terraform
  • Configuration Management of Linux/Windows machines – You can use it to configure Linux and Windows Machines. This means Ansible is used to install software, update config files, and start services.
  • Deployment tool – It can be used to deploy new versions of in-house developed software to your server

 

Ansible has a controller-client type architecture, where you have one main (aka the controller) managing lots of other machines (aka clients). Ansible is an agentless architecture which means that you only need to install Ansible on the Controller.