DevOps Swiss Army Knife
December 01, 2017

DevOps Swiss Army Knife

Aiman Najjar | TrustRadius Reviewer
Score 9 out of 10
Vetted Review
Verified User

Overall Satisfaction with Ansible

Ansible is a powerful tool for many DevOps cases, including generic automation scripts, configuration management, and infrastructure orchestration. We've used it mainly for complex application deployments - for each application, we wrote an Ansible playbook to deploy the application and all dependencies to target Chef-managed environments. The deployment process for each application varied a lot and was often very complex, and each playbook would have different logic for configuration and validations.

Those applications ranged from J2EE applications to cron jobs. Target VMs would range from Tomcat application servers to plain Linux machines.

I have also used Ansible for other uses such as for simplifying interaction with a large cluster of nodes to perform system administration tasks (e.g. fetching logs, investigating issues across nodes of a cluster..etc). I have also used its Python library to create custom automation scripts. It worked very well for all cases above.
  • Decentralized configuration management - Ansible supports "desired state" syntax and is a great alternative to centralized configuration management solutions. If you think that maintaining an infrastructure is an overkill for your needs, then you should consider Ansible. Ansible is "agentless" and all you need is version control, SSH access, and proper organization skills!
  • Great for writing clean and readable automation scripts. In my opinion, Ansible Playbooks are the new Shell scripts. It enforces readable structure yet maintains a great flexibility. Add to that, the ability to write playbooks in reusable "roles" as well as the large repository of built-in Ansible modules, Ansible becomes a very awesome alternative to writing complex Shell/Bash scripts.
  • Very powerful tool for system administrators to reliably and quickly interact with nodes of large clusters. With proper organization of your host inventory in versioned-control files, Ansible becomes an indispensable tool for Sys Admins to investigate issues and perform routine tasks across large clusters.
  • Steep learning curve - I have found that Ansible has a steeper learning curve when it comes to playbooks and roles. This could be a side-effect of its power and flexibility. I still believe more could be done to make writing roles simpler.
  • There is no a public repository of playbooks or a "package manager" that facilitates download community-maintained Ansible playbooks.
  • Ansible is a great investment if used for its well-suited scenarios. It has had a positive impact on my clients who used it to modernize their application deployment process. Ansible has 1) increased the reliability of the deployment process and 2) reduced scripts maintenance overhead.
  • Since Ansible is simpler and faster to get started with - compared to centralized configuration management solutions - it can be tempting to use it initially for simpler applications/infrastructure that are anticipated to evolve to complex ecosystems, you may find yourself having to rewrite in another tool in such cases.
  • Ansible is much simpler to get up and running with than Chef, as it requires no infrastructure or agent process or any configuration on the target machine. All you need is SSH access! However, you lose the capabilities that Chef server offers such as data bags (centralized data store with support for encryption), authorization rules, inventory status, periodic configuration pulls, version locking etc.
  • Ansible combines both infrastructure orchestration and configuration capabilities, therefore it can be used as a single tool to both create and configure your VMs on the cloud. However, it lacks the comprehensive support of various cloud resource types that Terraform offers. Terraform can be integrated with Ansible instead to implement an end-to-end process.
  • Ansible is a great replacement for Bash scripts. It natively supports many modules that will save you so many lines of codes, enforces readable YAML structure and is still very flexible and powerful.
Ansible is really unique in that it works well for various DevOps needs. I find it very well suited for:
  1. Automation Scripts - think: deployment scripts, configuration scripts, start-up/shut-down scripts, cron jobs, etc.
  2. Infrastructure as Code - although I would not say it is Ansible's primary use case, Ansible still has a good amount (albeit not comprehensive) of cloud infrastructure orchestration modules, things like creating EC2 instances, ELBs, S3 buckets, Azure resources, etc.
  3. Decentralized / "Push" Configuration Management - that means you trigger Ansible from a client machine and it will remotely execute the configuration scripts over SSH. This is actually enough for many configuration management use cases.

It may not work extremely well for the following cases:

  1. Complex Infrastructure as Code needs - i.e. cloud infrastructure that consists of many cloud resources of different types and advanced configuration.
  2. Configuring Complex Clusters or Ecosystems - for this I would prefer "Pull" / Centralized Configuration Management solution that offers inventory look-ups and integrated data store solution as part of the configuration process.