1. Home
  2. Configuration Management Tools
  3. Ansible Reviews
  4. User Review of Ansible
Ansible - great for simple configurations
May 22, 2018

Ansible - great for simple configurations

Chien Huey | TrustRadius Reviewer
Score 8 out of 10
Vetted Review
Verified User

Overall Satisfaction with Ansible

Ansible was used by the DevOps team to configure our computing clusters along with Terraform. It addresses the challenges involved in managing the configuration of our computing infrastructure. It is an excellent complement to Terraform because Terraform manages the cloud infrastructure creation (e.g. the VPC, instances, security groups, etc). Once the cloud infrastructure is created, Ansible can be used to configure the instances. Things, like configuring the services on the instances as well as installing and configuring software, can be handled by Ansible. Also the lightweight nature of Ansible - only requiring ssh is beneficial.
  • Installing and configuring software on instances.
  • Lightweight footprint. No agent required.
  • Predictable execution. Generally, the playbooks are run top to bottom.
  • Scheduling is not included in the OSS product, requires a purchase of Ansible Tower.
  • Relies solely on a reliable SSH connection.
  • No protection against concurrent playbook runs.
  • Ansible has allowed us to automate the configuration of singleton services like InfluxDB. Previously, the time series database had to be configured by hand which was time-consuming and error-prone.
Ansible is sufficient for our purposes because our configurations are relatively simple. Chef and Puppet would work better for more complex configurations. Also, our applications are deployed using Docker which simplifies our configuration requirements. An organization with more complex configurations would find Chef or Puppet suits their needs better.
Ansible works well if you can rely on having rock solid SSH connectivity. It also works well with the instances that you're configurations are relatively disposable. As Ansible makes changes as it processes the playbook, it is possible for changes to be made halfway down the playbook and then a failure to put the instance in an in-between state where it's neither the before state or after state. Rather it's somewhere in between.