Automating Your (Cloud or On-Prem) Infrastructure With Ansible

Ansible tasks are idempotent. Without a lot of extra coding, bash scripts are usually not safe to run again and again. But Ansible uses "Facts" — system and environment information it gathers —("context") before running Tasks.

Design Principles

• Have a dead simple setup process and a minimal learning curve.
• Manage machines very quickly and in parallel.
• Avoid custom-agents and additional open ports. Be agentless by leveraging the existing SSH daemon.
• Describe infrastructure in a language that is both machine- and human-friendly.
• Focus on security and easy auditability/review/rewriting of content.
• Manage new remote machines instantly, without bootstrapping any software.
• Allow module development in any dynamic language, not just Python.
• Be usable as non-root.

Ansible, by default, manages machines over the SSH protocol.

Once Ansible is installed, it will not add a database, and there will be no daemons to start or keep running. You only need to install it on one machine (which could easily be a laptop) and it can manage an entire fleet of remote machines from that central point. When Ansible manages remote machines, it does not leave software installed or running on them, so there’s no real question about how to upgrade Ansible when moving to a new version.

Playbooks could be considered the main concept in Ansible.

Playbooks are Ansible’s configuration, deployment, and orchestration language. They can describe a policy you want your remote systems to enforce, or a set of steps in a general IT process.

At a basic level, playbooks can be used to manage configurations of and deployments to remote machines. At a more advanced level, they can sequence multi-tier rollouts involving rolling updates, and can delegate actions to other hosts, interacting with monitoring servers and load balancers along the way.

Playbooks are designed to be human-readable and are developed in a basic text language. 

Playbooks are expressed in YAML and have a syntax, which intentionally tries to not be a programming language or script, but rather a model of a configuration or a process.

In my example, I set up two virtual machines with Vagrant. For the first one, I have Ansible installed, and the second one has some configurations I applied.

Configure multi-machine like this in my previous post.

Vagrantfile to multi-machine:

 Vagrant.configure(2) do |config|  
  config.vm.box = "ubuntu/trusty64"  
  config.vm.define "machine1" do |node1|  
    node1.vm.network "private_network", ip: "192.168.0.101"  
    node1.vm.hostname = "machine1"  
    node1.vm.provider "virtualbox" do |v|  
     v.memory = 1024  
     v.cpus = 1  
   end  
  end  
  config.vm.define "machine2" do |node2|  
    node2.vm.network "private_network", ip: "192.168.0.102"  
    node2.vm.hostname = "machine2"  
    node2.vm.provider "virtualbox" do |v|  
     v.memory = 1024  
     v.cpus = 1  
   end  
  end  
 end  

On machine1, install Ansible with the command below:

#vagrant ssh machine1

If asked for a password, put  “vagrant".

And the commands to install Ansible:

 sudo apt-get install software-properties-common
 sudo apt-add-repository ppa:ansible/ansible
 sudo apt-get update
 sudo apt-get install ansible

Edit /etc/ansible/hosts and add the IPs 192.168.0.101 and 192.168.0.102.

To check if everything is OK, run this command:

ansible all -m ping -s -k -u vagrant

The result should be:

machine2 | SUCCESS => {
    "changed": false,
    "ping": "pong"
}

The first Playbook is to install Java and Tomcat on the second machine.

Playbook-tomcat.yml:

- hosts: machine2
  vars:
    http_port: 80
    max_clients: 200
  remote_user: vagrant

  tasks:
    - name: updates a server
      apt: update_cache=yes
    - name: upgrade a server
      apt: upgrade=full
    - name: install java 
      apt: name=default-jdk state=latest
    - name: install tomcat
      apt: name=tomcat7 state=latest
    - name: make sure apache is running
      service: name=tomcat7 state=started

ansible-playbook playbook-tomcat.yml -sudo -u vagrant --ask-pass

After the installation, access Vagrant ssh machine2 and type java -version.

If everything is OK, you should see the installed version.

My complete example.

With Ansible installed on just one machine, it's possible to execute commands to install tools or action on others machines, and that includes versioning playbooks could be versioned in GitHub.