Ansible scratches our product team's imperative orchestration itch!
October 09, 2015
Ansible scratches our product team's imperative orchestration itch!
Score 8 out of 10
Vetted Review
Verified User
Software Version
1.9.3
Modules Used
- rax
Overall Satisfaction with Ansible
We use Ansible to orchestrate the create, converge, and destruction of cloud infrastructure. The converge portion is managed by Chef. We differentiate Chef from Ansible in that Chef is used to lay down declarative, idempotent resources. Ansible is used to perform one-time shot operations like creating clusters, running db migrations, managing DNS records. We wrap Ansible in Jenkins to make orchestration easier to manage in our CI processes and also to increase visibility. As we are based in the public cloud, we rely heavily on the dynamic inventory portion of Ansible.
- Imperative orchestration works well. There is no resource ordination issues like there can be with Puppet or Chef.
- It is easy to get started and start iterating on plays, books, roles.
- The docker and rax resources are very robust and compelling. I hope these continue to develop and flourish.
- There are conflicting stories on how best to organize a role's structure. Old documentation exists, and as Ansible has grown directions have pivoted a bit. This should be trued up.
- Pull-based Ansible is a compelling use case. Ansible should come up with a pattern which supports this configuration.
- How to integrate ServerSpec infrastructure integration testing is sorely lacking. Ansible should curate practices and docs around this.
- Ansible makes it easier to ship code as the orchestrator of the release.
- Ansible enables clear blue-green release processes.
- Ansible moves fast and breaks the runtime with regressions. We rightly pin dependencies hard to insulate ourselves from unintentional breaking changes.
- Chef
I've said this before, but Ansible is a great declarative orchestrator. One thing that is both good and bad about it is that it has no store about the state of the gear it manages. With dynamic inventory, I either have to realize facts for my entire fleet or rely on prior runs writing metadata to my cloud instances and subsequent runs referencing said information from the cloud API. Contrast this to Chef which has a solr instance which lets me store information about node objects which is updated on successful converges. That store is always available for recipe use and other business processes.