Why Ansible? Why now?

In recent years, as cloud operating models have become more pervasive, organisations have started to adopt DevOps culture and processes to break previously existing organisational silos such as Development, Operations and QA. A key element for this transition is to treat Infrastructure as Code and to employ specialised automation tools. This is reporting benefits such as:

• Improved agility by eliminating manual or siloed tools which translates in significant reduction of provisioning times
• Minimise provisioning errors      
• Ensure consistency
• Ability to manage larger environments typically associated with scale-out microservices architectures
• Lower operational cost 

The right choice of tool is essential to achieve these outcomes. Instead of leveraging element-specific scripting tools organisations need to move towards automation tools that can:

• address the configuration of large parts of the infrastructure so that multiple teams can “speak” the same language and make possible end-to-end automation, typically driven from a self-service portal
• perform day 2 operations with ease by using “declarative” syntax. With these tools, engineers specify the “desired state” as opposed to the steps to be performed (which is referred to as “imperative”). This style makes it easy to perform tasks such as applying patches, implementing upgrades and avoiding configuration drift. These tasks arguably are more time consuming as they are performed throughout the entire lifetime of the workload, as opposed to the once-off day 1 provisioning. And of course, day 2 operations are typically done with the workload already in production, hence the choice of tool is important

The automation tool ecosystem can be overwhelming due to the amount of tools available and how dynamic it is. New players pop up all the time, and established players dying unexpectedly. This makes it difficult to choose suitable long-lasting tools. It is important to minimise the risk of making the wrong choice around automation tools. Nobody wants to end up with a million-dollar investment in Betamax
One tool that is looking safer to bet on is Ansible. Ansible has a community substantially larger that its competitors and is growing faster than them. [cite the source]. With that in mind it is no surprise to see companies are now providing Ansible modules to automate management tasks for their infrastructure products. This will enable customers to automate configuration and management of full stacks including on-prem physical infrastructure, cloud infrastructure, OS and application
Management in Ansible is structured in “playbooks”, which are written in YAML (Yet Another Markup Language) format. A playbook typically contains one or many tasks that are executed against a number of ‘target’ hosts. The following screenshot shows what’s what through a sample playbook.

Each task leverages the functionality provided by a module. In the above example you can see there is a “yum” module to manage software installation in RedHat Linux variants or a “service” module to manage services in Linux systems. There are many a modules available and writing new ones is not too hard. The following link shows all the modules that have been officially registered with Ansible. You can click in any of them to see how to use them in your playbooks

http://docs.ansible.com/ansible/list_of_all_modules.html

Now that we have covered the basics, in the next article [link to the second article] we will explain the details of the new official Ansible module for PowerMax and VMAX arrays