Why choose Ansible over other configuration management tools?
Intro:
Every day the same routine for the old school sysadmin: manually deploy or modify VMs, customize the operating system, update packages, apply security patches, fine tune the configuration on the existing environment, create routines with shell script (which cannot be run twice, most of the time), manually deploy apps (copy files, restart instances, service health check): all subject to human failures, jeopardizing the standardization of the environment.
All this creates delays, demotivation (with repetitive jobs) and low productivity, hampering the scalability of the services that you manage. In environments managed by one of these Sysadmins, the DepOps culture is at zero maturity and infrastructure as code is not yet part of the work routine.
To try to solve these problems it is necessary to enter the world of automation, using modern tools of configuration management, provisioning and orchestration.
Infrastructure Automation:
Many of the available tools, such as Ansible, Puppet, Saltstack, Chef and CFEngine, provide automation for infrastructure, cloud, compliance and security management, integration for deployment and continuous deployment (CI / CD). What is the best tool to start automating your environment?
The difficult task of prospecting one of these tools keeps the sysadmin from evolving technically and proposing improvements to the environment they manage. They work the old school way and are conservative and averse to change, “If it ain’t broke, don’t fix it”. Sysadmins need to be up-to-date on automation, and when they do begin studying automation, they will be taken to several tools that theoretically do the same thing. This can make the job a bit traumatic and demotivating for those who are getting starting.
What is the best tool for those with zero maturity in automation?
The quick answer to all these questions: Ansible
But why Ansible and not the other tools in these in this case?
1) All-in-one: Simplifying automation
Ansible can be considered an “all-in-one” tool: All automation steps can be done with Ansible. This is due to the fact that Ansible was developed in Python, and in addition to inheriting the general purpose language feature, you can make use of the thousands of existing packages from the Python community to create your own modules.
Ansible currently has more than 1300 modules in several areas of IT infrastructure: Web, Database, Network, Cloud, Cluster, Monitoring, Windows, Storages and others.
We know that other tools work better at some stage, but in a zero-maturity automation environment Ansible can help a team achieve automation maturity faster.
Configuration Management: Code, life cycle and changes can be made through inventory, playbooks and roles in Ansible. It is possible to manage desired states and idempotency natively in the tasks that will be performed.
Orchestration: Simplified and powerful orchestration engine. Ansible integrates with almost every area of the infrastructure, from provisioning VMs to creating rules on the firewall. It also focuses on areas where other tools leave gaps such as zero stop, continuous updates for multi-tier applications across the infrastructure.
Provisioning: Ansible has modules for containers (Docker), Virtualization (VMware, AWS, OpenStack, Azure, Ovirt) and can easily integrate with other tasks from previous steps.
2) Lower Learning Curve:
Ansible has a very fast learning rate, with easy installation and initial configuration. In less than 30 minutes, it is possible to install, configure and execute ad-hoc commands for ’n’ servers to solve a specific problem: Daylight saving time adjustments, time synchronization, root password change, updating servers, restarting services, etc.
Syntax and workflow are simple to understand, making it easy to learn for new users. The files use YAML (YAML Is not Markup Language), a user friendly declarative language standard that is widely used by other tools and easy to understand, with the addition of using the Python language to extend the functionality of Ansible with customized modules.
3) Mutable Infrastructure
We know that the old infrastructure model takes time to converge to a fully automated environment (infrastructure as code). The environments managed by Sysadmins are constantly modified (mutable infrastructure) and any change is costly, may lead to conflicts between teams and many manual interventions. Ansible adapts well to mixed environments, coexisting seamlessly with partially or mostly automated environments. The transition from one model to another will be less traumatic with Ansible.
4) No Agents: Only an “Ansible Control”
Ansible does not require agents installed at the endpoints. The only requirement is an Ansible installed server with access to the servers to be managed through SSH (for Linux environments) or WINRM (Windows Remote Access) protocols. Playbooks push the desired settings on the hosts defined in the inventory and can even run Ad-Hoc (via the command line, not requiring definitions in files). The agentless model makes adjustments and communication faster than the client-server model.
The only requirement on Linux hosts is to have Python installed. Today Python is natively installed on most Linux distributions.
5) Automate right now:
From the moment you are able to ping the hosts through Ansible, you are able to start the automation of your environment.
Start with small tasks, following best practices, prioritizing tasks that add value to the business and solve major problems or retention of demands, gaining time and more productivity.
Conclusion:
Teams of sysadmins who work the old school way (all manual and with unproductive tools) urgently need to change to the path of infrastructure automation. It will be hard work convincing and engaging people, but choosing Ansible will result in big gains for the team and the organization.
The choice for Ansible can help the team quickly solve their “Achilles’ heel” as well as increase productivity and promote collaboration and job satisfaction.
Go straight to this path and be happy: Automate the heavy, boring, repetitive part with Ansible and have time to become more creative.
Extra: Is Ansible considered Configuration Management or not?
There are several internet discussions about whether Ansible is considered a Configuration Management tool. The theoretical part of configuration management is based on the GCONF school presented by Mark Burgess, creator of CFEngine, where he says GCONF principles are Idempotency and desired state.
Idempotency is the characteristic of verifying the current state of what will be modified. If it is already in the desired state, no action is taken. Ansible in version 2.3 has more than 1300 modules that, for the most part, follow the principle of idempotency. In cases where Ansible does not have a native module, there is a set of “command modules” (shell, raw, telnet, command, script) that need handling so that they become idempotent through attributes “args” or appropriate directives (when, when_changed, when_failed etc).
As for the convergence item, the creator of Ansible, Michael DeHaan, stated in the Ansible discussion group:
“This Desired State thing also gets mislabelled from time to time as ‘Convergence’. Convergence typically means if I run this process 4 or 5 times it gets to where I want to be. Terrible, you want to get there in one hop! […] I think the industry is plagued a bit with the idea that simple things must be talked about in complicated terms, and Ansible is not like that. Our goals are simple — Speak in plain English. Get stuff done.”
Therefore, do not be misled into thinking that Ansible cannot be used as a Configuration Management tool. Version your code, use a job management tool (Rundeck, Jenkins, Tower, AWX or Ansible-pull itself), modify the changes workflow to use infra as a code and keep your environment up-to-date and in the desired state.
