Ansible Installation in ubuntu16.04

Introduction

Ansible is an open-source automation engine that automates cloud provisioning, configuration management, and application deployment. It can configure systems, deploy software, and orchestrate more advanced IT tasks such as continuous deployments or zero downtime rolling updates. Once installed on a control node, Ansible, which is an agent-less architecture, connects to a managed node through the default OpenSSH connection type.

Ansible Concepts

1. Modules

Ansible uses modules to accomplish most of its Tasks. Modules can do things like install software, copy files, use templates.

2. Playbook

can run multiple Tasks and provide some more advanced functionality that we would miss out on using ad-hoc commands.

3. Roles

Roles are good for organizing multiple, related Tasks and encapsulating data needed to accomplish those Tasks. For example, installing tomcat may involve adding a package repository, installing the package and setting up configuration. We’ve seen installation in action in a Playbook, but once we start configuring our installations, the Playbooks tend to get a little more busy. The configuration portion often requires extra data such as variables, files, dynamic templates and more. These tools can be used with Playbooks, but we can do better immediately by organizing related Tasks and data into one coherent structure.

4. Files

Use files directory, we can add files that we’ll want copied into our servers. For tomcat, I often copy tomcat server configurations, tomcat user configuration file . I will push into github. I will download the latest commit  from Git-hub.

5. Handlers

A Handler is exactly the same as a Task (it can do anything a Task can), but it will run when called by another Task. You can think of it as part of an Event system; A Handler will take an action when called by an event it listens for. This is useful for “secondary” actions that might be required after running a Task, such as starting a new service after installation or reloading a service after a configuration change

6. Meta

It contains dependencies of other roles and author of the role and version of the role. The main.yml file within the meta directory contains Role meta data, including dependencies. If this Role depended on another Role, we could define that here. For example, I have the tomcat Role depend on the java8 Role, which installs java8

7. Templates

It contains template variables, based on Python’s Jinja2 template engine. Files in here should end in .j2

8. Defaults

It contains variable  and values. Which will update in tasks.

9. Vars

It contains variable and values for task script. It will overwrite into defaults folder variable and values

10.  Tests

It contains the inventory file

11. Tasks

It contains all modules , which will execute into remote instance

12.  Facts

It provide information about remote node like os, architecture , private ip public ip etc based on that roles will be on remote machine

Goal

We are taking two instances from google cloud with ubuntu 16.04 LTS ami.  One instance name is ansible and other is aios (all in one stack). We are going to show to you how manage multiple environments like test, dev, prod etc. with ansible stack

Prerequisites

We will have aleast two instances in Google compute engine/AWS/local

Ansible Node

Installation Ansible Package

Adding repo into Instance

$sudo apt-get install software-properties-common

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

$sudo apt-get update

Installing the Ansible

$sudo apt-get install ansible

Verify Ansible  version

[user1@ansible ~]$ ansible –version

ansible 2.3.1.0

config file = /etc/ansible/ansible.cfg

configured module search path = Default w/o overrides

python version = 2.6.6 (r266:84292, Aug 18 2016, 15:13:37) [GCC 4.4.7 20120313 (Red Hat 4.4.7-17)]

We will have repo for test, dev, prod etc. in github.

https://github.com/santoosh/devops/tree/dev

Cloning the branch

$git branch  -b dev git@github.com:santoosh/devops.git

Verify the Ansible facts

$ansible 10.128.0.2  -m setup -a “filter=ansible_local”

10.128.0.2 | SUCCESS => {

“ansible_facts”: {

“ansible_local”: {

“role”: {

“metadata”: {

“env”: “dev”,

“role”: “apache2”

}

}

}

},

“changed”: false,

“failed”: false

}

Changed play.yml accordingly

$cat play.yml

– hosts: all

become: yes

become_method: sudo

roles:

– { role: apache2, when: ansible_local.role.metadata.role  == “apache2”, when: ansible_local.role.metadata.env  == “dev”}

Note: apach2 role will be update  , If any instance is having role= apache2 and env=dev.

Remote Node

Create Factor folder

$ sudo mkdir /etc/ansible/facts.d/

$cat /etc/ansible/facts.d/role.fact .

[metadata]

role=apache2

env=dev

conclusion

Run the paly.yml playbook from ansible node to make changes effect on remotes nodes from ansible machine

 

 

 

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

w

Connecting to %s