There are several Open Source technologies that will help you manage constant task or large environments on a simple and painless way, saving you time, money and , efforts and helping DevOps. We found out that Ansible may be your best friend on those situations.
As a Linux Systems Administrator, I came up with the point where I needed a configuration management tool for doing a constant task on an easy and simple way.
I tested some other Ansible’s competitors, like Chef or Puppet. I selected Ansible for some of these reasons:
- It’s simple and easy to learn: I think this is the best Ansible feature. IT’ HUMAN-READEABLE! Which can increase development speed and productiveness.
- Written in python: Ansible was written in Python, unlike other competing solutions that were built with languages such as Ruby. Consequently, getting it up and running is easier, since Python libraries are by default present on most Linux distributions. It’s also a language that’s more common for administration and scripting tasks.
- Agentless: For managing nodes, Ansible handles all master/agent communications with standard SSH or the Paramiko module, which is a Python implementation of the SSH2. The tool doesn’t require any agents to be installed on remote systems to be managed.
- YAML bases Playbooks: Playbooks are Ansible’s configuration files as you may know by now. YAML make thing easier, and everybody can understand what the playbook is doing with some basic Ansible’s knowledge.
- Best documentation ever: Seriously, it Is the best documentation EVER! I’ve been working with multiple services, applications, hostings, etc and their documentation is not that helpful most of the times, also, they are hard to understand and it’s hard to find exactly what you’re looking for. With Ansible everything is just simple. Documentation is well organized, with functional examples for almost every use case.
So based on the above point I decided Ansible will be the best and less time consuming option, and actually I was in the correct path. Today Ansible helped me solve numerous of tasks that need to be done several times for multiple environments or every certain time.
You are probably wondering; how can I implement Ansible on your infrastructure? Here are some of the cases you will love to have Ansible as your friend:.
Immutable Server Architecture
Do you need to create a same architecture multiple times for different environments with Amazon Web Services (AWS)?
Ansible it’s a great option for creating AWS Load Balancers, RDS and functional EC2 servers, running the latest version of your code with just 1 click. Sounds amazing right?
Another great example is using Ansible to patch security holes on our architecture. Imagine having 100+ servers and all of them have the same security issue. Like Heartbleed SSH issue.
Example #1: Shellshock
The following playbook was run against 100+ servers and patched the bash vulnerability in less than 10 minutes. The below example updates both Debian and Red Hat Linux variants. It will first run on half of all the hosts that are defined in an inventory file.
hosts: all
gather_facts: yes
remote_user: craun
serial: "50%"
sudo: yes
tasks:
- name: Update Shellshock (Debian
apt: name=bash
state=latest
update_cache=yes
when: ansible_os_family == "Debian"
- name: Update Shellshock (RedHat)
yum: name=bash
state=latest
update_cache=yes
when: ansible_os_family == "RedHat" Example #2: Heartbleed and SSH
The following playbook was run against 100+ servers patching the HeartBleed vulnerability. At the time, I also noticed that the servers needed an updated version of OpenSSH. The below example updates both Debian and RedHat linux variants. It will patch and reboot 25% of the servers at a time until all of the hosts defined in the inventory file are updated.
hosts: all
gather_facts: yes
remote_user: craun
serial: "25%"
sudo: yes
tasks:
- name: Update OpenSSL and OpenSSH (Debian)
apt: name={{ item }}
state=latest
update_cache=yes
with_items:
- openssl
- openssh-client
- openssh-server
when: ansible_os_family == "Debian"
- name: Update OpenSSL and OpenSSH (RedHat)
yum: name={{ item }}
state=latest
update_cache=yes
with_items:
- openssl
- openssh-client
- openssh-server
when: ansible_os_family == "RedHat"
post_tasks:
- name: Reboot servers
command: reboot Have predefined ansible roles and playbook for common situations
Are you constantly installing a software or configuring something over and over again? Why not use Ansible to solve your problem?
Playbooks are simple to write and maintain. Most users become productive with Ansible after only a few hours. Ansible uses the same tools you likely already use on a daily basis and playbooks are written in a natural language so they are very easy to evolve and edit.
You can create predefined roles, for example, Nginx installation and configuration according your need and it’s just matter of executing the role and that’s it! Simple, right?
Let’s imagine you need to update PHP version in a environment. If in the environment there are just 2 servers using PHP, it’s really simple.. but imagine the environment has 100 servers. This can take a long time and will be a headache.
Ansible is the simplest solution for configuration management available. It’s designed to be minimal in nature, consistent, secure, and highly reliable, with an extremely low learning curve for administrators, developers, and IT managers.
The configurations are simple data descriptions of your infrastructure; ensuring everyone on your team will be able to understand the meaning of each configuration task.
With Ansible you could create a role that updates the PHP version and then just execute the role in all the server. Here at ClickIT, we are experts providing Managed services with DevOps solutions such as Ansible, Chef and AWS Opswork”.
