🔰Ansible : A Case Study how industries are solving challenges using Ansible🔰

I will start my blog with a beautiful quote by John Lasseter

“The art challenges the technology, and the technology inspires the art.”

In this blog first we will start with what is ansible, its history, its architecture, why do we need it?, what are the different challenges that many industries were facing before ansible & how it helps to solve them?

👉🏻Lets get started …😃

What is Ansible?

Ansible is a radically simple IT automation engine that automates cloud provisioning, configuration management, application deployment, intra-service orchestration, and many other IT needs.

Being designed for multi-tier deployments since day one, Ansible models your IT infrastructure by describing how all of your systems inter-relate, rather than just managing one system at a time.

It uses no agents and no additional custom security infrastructure, so it’s easy to deploy — and most importantly, it uses a very simple language (YAML, in the form of Ansible Playbooks) that allow you to describe your automation jobs in a way that approaches plain English.

Advantages of Ansible

• Free: Ansible is an open-source tool.
• Very simple to set up and use: No special coding skills are necessary to use Ansible’s playbooks (more on playbooks later).
• Powerful: Ansible lets you model even highly complex IT workflows.
• Flexible: You can orchestrate the entire application environment no matter where it’s deployed. You can also customize it based on your needs.
• Agentless: You don’t need to install any other software or firewall ports on the client systems you want to automate. You also don’t have to set up a separate management structure.
• Efficient: Because you don’t need to install any extra software, there’s more room for application resources on your server.

Basic Ansible Architecture

Controller Node :

System where we install ansible, make Inventory, run ansible command and create playbooks and have ansible configuration file.

Managed/Target Nodes :

The network devices (and/or servers) you manage with Ansible. Managed nodes are also sometimes called “hosts”. Ansible is not installed on managed nodes that’s why they are agentless.

Inventory :

Ansible Inventory is a file which defines all the remote hosts (target nodes) i.e. the IP address, username, password, protocol etc.

How playbooks come into play in Ansible?

Playbooks is the language for Ansible’s configuration, deployment, and orchestration. They describe a policy as to how remote systems should be enforced, or a set of steps in a general IT process. If Ansible modules are the tools in admin’s workshop, playbooks are his instruction manuals, and his inventory of hosts are simply his raw material.

Basically, playbooks are used to manage configurations of remote machines and their deployments. At a more advanced level, they can sequence multi-tier rollouts involving rolling updates. They can also delegate actions to other hosts, interact with monitoring servers and load balancers.

Modules :

Ansible works by connecting to your nodes and pushing out scripts called “Ansible modules” to them. Most modules accept parameters that describe the desired state of the system. Ansible then executes these modules (over SSH by default), and removes them when finished. Your library of modules can reside on any machine, and there are no servers, daemons, or databases required.

Ansible is used for Configuration Management and there are two ways :

• Ad-Hoc Commands -Manual way of writing commands on CLI to automate a single task on one or more managed nodes.
• Playbooks -Playbooks are the program files in ansible where we only once write code and use it as many times. These are written in standard YAML format helps to manage our information in key-pair value format.

History of Ansible

Here, are important land marks from the history of ansible:

• In February 2012 the Ansible project began. It was first developed by Michael DeHaan, the creator of Cobbler and Func, Fedora Unified Network Controller.
• Initially called AnsibleWorks Inc, the company funding the ansible tool was acquired in 2015 by RedHat and later on, along with RedHat, moved under the umbrella of IBM.
• In the present, Ansible comes included in distributions like Fedora Linux, RHEL, Centos and Oracle Linux.

Why use Ansible?

Here are some important pros/benefits of using Ansible :

• One of the most significant advantages of Ansible is that it is free to use by everyone.
• It does not need any special system administrator skills to install and use Ansible, and the official documentation is very comprehensive.
• Its modularity regarding plugins, modules, inventories, and playbooks make Ansible the perfect companion to orchestrate large environments.
• Ansible is very lightweight and consistent, and no constraints regarding the operating system or underlying hardware are present.
• It is also very secure due to its agentless capabilities and due to the use of OpenSSH security features.
• Another advantage that encourages the adoption of Ansible is its smooth learning curve determined by the comprehensive documentation and easy to learn structure and configuration.

Important terms used in Ansible

• Ansible server: The machine where Ansible is installed and from which all tasks and playbooks will be ran
• Module: Basically, a module is a command or set of similar commands meant to be executed on the client-side
• Task: A task is a section that consists of a single procedure to be completed
• Role: A way of organizing tasks and related files to be later called in a playbook
• Fact: Information fetched from the client system from the global variables with the gather-facts operation
• Inventory: File containing data about the ansible client servers. Defined in later examples as hosts file
• Play: Execution of a playbook
• Handler: Task which is called only if a notifier is present
• Notifier: Section attributed to a task which calls a handler if the output is changed
• Tag: Name set to a task which can be used later on to issue just that specific task or group of tasks.

Case Studies:

BINCKBANK

About BinckBank Based in Amsterdam, NL Largest Dutch online discount broker 590 employees 760,000+ accounts 600 UNIX servers Mark Maas, UNIX/Linux System Administrator

THE CHALLENGE

We have 600 UNIX servers in house. We have a lot of specialty environments that we need to create while at the same time managing our production environment.

Our problem was complexity in the datacenter. We wanted automation but we also wanted simplicity and to not have to send people to training in order to use the product.

BEFORE ANSIBLE

In the past we did our own scripting for menial tasks over a lot of late nights of pizza.

WITH ANSIBLE

Ansible is quite fun to use right away-as soon as you write five lines of code it works.

With SSH and Ansible I can send commands to 500 servers without having even used the servers before.

We are completely focused on automating as much as possible in our datacenter and going beyond Unix to create more stuff for more people to do be able to do more.

HOOTSUITE

About HootSuite Based in Vancouver, BC, Canada Social media management ~400 employees Over 8 million users 75% of Fortune 500 uses HootSuite Beier Cai, Director of Technology

THE CHALLENGE

Our infrastructure is not scripted, repeatable or immutable.

Rebuilding a server relies on limited documentation and mostly memory.

Lack of repeatability makes automating our infrastructure and application deployment difficult.

There was one time we had to spend over a month of an engineer’s time to rebuild a server that had lived for 2 years with random config changes by ops engineers along the way, with limited documentation.

BEFORE ANSIBLE

We had limited experience with Puppet, but didn’t quite like it because

1) It needs agents, and we don’t like agents and

2) we favor immutability over snowflake factory for infrastructure management.

WITH ANSIBLE

Ops and devs both feel safer, literally. Before they were always worried about ‘what if the server dies’. They aren’t worried about this anymore after all servers are properly ‘Ansiblized’.

With the help of Vagrant we can test server builds locally as many times as we want until it works, instead of testing it on EC2 cloud which is remote and always slow.

Increase our bus factor from 1 to infinite! Before, only 1 or 2 people know how a server was built from the beginning. With Ansible, storing playbooks in source control gives everyone the ability to rebuild the server at any time.

NASA

About NASA They put men on the freaking moon

About NASA WESTprime, WESTPrime == Web Enterprise Service Technologies prime Blanket purchase agreement funded by NASA Contracted to InfoZen Inc., a cloud broker and integrator based in Rockville, MD InfoZen responsible for entire cloud migration for all NASA web assets Jonathan Davila, Senior DevOps Lead, InfoZen

THE CHALLENGE

WESTPrime’s initial focus was to move roughly 65 applications off the old data center as quickly as possible in a seemingly impossible timeline.

All of a sudden they had an environment spanning multiple VPCs and AWS accounts with no way of centrally managing it.

Faced with a very ugly scenario where even simple things like ensuring every SysAdmin had access to every server, or simple patching were extremely burdensome.

BEFORE ANSIBLE

Previously, NASA WESTPrime was using a lot of shell scripts. There was a lot of “manually ssh-in-and-do-x” type of work being done.

Then created a demo day in which we invited the automation players to demonstrate the enterprise flavors of their product.

After quite a long day of deep level demos and Q&A, and a week of analysis with the technical team we decided unanimously that Ansible was the best fit for us.

Why? No agents Very small learning curve (a day or less!) Non-technical staff can read a play and know what’s happening Native use of SSH The most active open source community among its competitors

WITH ANSIBLE

NASA web app servers are being patched routinely and automatically through Tower with a very simple 10-line Ansible playbook.

Every single week www.nasa.gov is updated via Ansible, generally only taking about 5 minutes to do, including the mobile version of nasa.gov.

Because of Ansible we are able to organize our inventory of AWS resources in a very granular way that was not at all possible before.

One time we faced some strict deadlines for monitoring and we didn’t have time to deploy Nagios agents (due to lengthy approval workflows in place) to monitor RAM and CPU. So what did we do? We did a very simple hack to be able to monitor CPU and RAM with Ansible in near real-time (no agent required!).

Ansible was leveraged to remediate both OpenSSL issues this year in ridiculous time (leadership was blown away). It is also used to ensure our environment is compliant with necessary Federal security standards as outlined by FedRAMP and other regulatory requirements.

There is a level of comfort and confidence that Ansible has been able to provide that simply was not there before.

Thanks for reading !!!😊✨

🔰Keep Learning ❗❗🔰Keep Sharing ❗❗