Ansible for devops
February 25, 2020

Why Use Ansible for DevOps?

Open Source

Defining Orchestration with Ansible for DevOps

Before choosing Ansible for DevOps, it’s important to first discuss the necessity of utilizing orchestration. In general, it has always made sense to automate repetitive tasks, and systems have always been full of repetitive tasks. The scope of what is considered a “task” has increased significantly as we have developed modern deployment methods. 

Now, in 2020, things, like spinning up a whole compute environment, provisioning all the software in that environment, and ultimately deploying that environment into Production, can and should be automated. When we look at the structure of newer architectures like microservices, mesh, elastic scale, etc. it becomes apparent quickly that none of this can be achieved at scale without automation. Imagine having to deploy 1000 new containers by hand when additional load is detected in a system. It’s much better to be detected. 


Why Move Away from Shell Scripts

In the past, to automate less sophisticated tasks such as rotating log files or archiving backup data, system admins usually wrote shell scripts. Though we certainly can achieve automation and orchestration with shell scripts, they present a lot of problems for businesses as automation needs to grow. Shell scripts are free-form languages, and code style varies across developers. 
Disadvantages of shell scripts include: 

  • They are time-consuming and often require a lot of bespoke code to be written, leading to a lack of standardization.
  • They can easily spin out of control and become overwhelmingly complex.
  • They are often tightly coupled to the current ‘state’ of the underlying operating system, so things like system upgrades can break them easily.
  • They are cumbersome to scale and deploy out to new machines.
  • There is no standard protocol nor method for central management, monitoring, and/or governance.
  • Failed operations and exception handling/rollback must be considered and manually implemented.

Versatility of Ansible

At OpenLogic by Perforce, we work with customers of all organization sizes. Our team has had the chance to see Ansible operate at all different levels of scale. Below are some actual customer use cases that demonstrate Ansible’s flexibility as an orchestration provider.

Small Appliance ISV

A software company wants to make it easy for people to install their appliance application on a small piece of hardware, maybe an Intel NUC. Rather than distributing an inflexible image of the appliance software, forcing the user to adopt a particular OS, they could distribute an Ansible Playbook for their end users to run against their own machines. This would prepare any mainstream operating system for the company’s product and would allow the user to BYO-OS and maintain the OS according to their own internal standards. 

Mid-Size On-Prem VMWare Farm

A business maintains an on-prem VMWare implementation for the purpose of running various local intranet applications. A few thousand VMs are deployed which must be configured for various business applications. New machines need to have particular OSes, environment configuration, and software dependencies installed. Businesses can run Ansible servers which will run Ansible Playbooks against target VMs with SSH. Those Playbooks can enforce configuration, dependencies, etc. across new and existing resources by just updating a central inventory.

Large On-Prem Enterprise

Large enterprise has built a very large, geographically distributed cloud and on-prem infrastructure for public and private consumption. Hundreds of thousands of VMs, containers, bare metal assets, software applications, services, etc. Hundreds of new assets added/decommissioned/changed daily. Responsibilities are stretched across many different ops and infrastructure teams across the company, as well as outsourced resources. Ansible AWX and Ansible Tower can be used to centrally manage numerous Ansible servers. In addition, many different Playbooks can be stored, deployed, altered, and managed in general through AWX/Tower with role-based access control and other semantics necessary for larger organizations.

Use of Declarative Syntax with Ansible

Ansible uses a Declarative syntax. Declarative syntax has proven to be an easier and more efficient means of achieving continually enforceable configuration.  

How this difference plays out:
Imperative: “First, install CentOS 8 on a VM. If that fails send an email to Quality. If that succeeds send an email to Ops. Then, Install Apache Web Server on the new VM. If that succeeds, then send an email to the Web Team. 
If that fails, then send an email to Quality”.
Declarative: “I need an environment running the newest CentOS with Apache Web Server 2.4 and MariaDB installed, please, and keep us up to date”.

What does this mean? The declarative syntax allows us to simply “declare” what we would like a thing to be, and the related process or application will work behind the scenes to ensure that the state is maintained. Imperative syntax asks us to spell out each step and decide what to do if something goes wrong in each case. 

Get More Information on Ansible

If you’re looking to compare ansible to other orchestration tools, download The Benefits of Ansible Orchestration. This free white paper compares Ansible vs. Chef and Ansible vs. Puppet. The paper also describes how to complete a migration to Ansible and the overall benefits that come with it. Learn where Ansible doesn’t belong and how Ansible is a modern orchestration solution. Download the free white paper today!