We're big fans of automation, especially Ansible. When I found Allan Denot's post on the configuration management and orchestration engine, I knew I wanted to learn more about his experience. Here's our conversation with Allan on the differences between Ansible and Puppet or Chef. He shared his excitement about Ansible 2 and, believe it or not, that wishes the tool could make breakfast for him too.
How would you describe Ansible for a developer who has always built servers or environments manually?
With Ansible you can describe infrastructure and configuration in a very simple format: YAML. Instead of writing commands to run, you write the final state desired for the server. Ansible uses its modules to ensure it's achieved. If nothing has changed, Ansible doesn't touch the server configuration. It verifies item by item and reports back.
Since the files can be version controlled, we now have a workflow that is similar to a software development workflow where any changes to infrastructure can be tracked and approved by other engineers.
How would you describe Ansible to someone familiar with Puppet or Chef?
Ansible defines infrastructure as data, not as code. That alone removes a big chunk of complexity from configuration management. Code is only necessary when you need to extend core modules.
Ansible is agentless and allows both push and pull modes. Push mode is more common and configuration is applied to hosts using SSH. There's also no need to install anything in the target host other than Python. For speed concerns, Ansible provides several ways to speed up connections.
How did you get started with Ansible and what's your experience been like?
The company I worked pushed Ansible as a configuration management and deployment tool. We were tasked to upgrade all of our deployments from Bash scripts to Ansible.
Because of the flexibility that Ansible provides, in order to achieve some outcomes with minimal code in a simple way, we needed to add a level of creativity when writing the playbooks, which I think is great. I lost count of the number of times I kept trying something different only to realize "Oh, I didn't know Ansible could do that".
What sort of mind shift is required for developers to be comfortable with Ansible?
Ansible isn't used to write bash commands as much as idempotent tasks. The frame of mind is that you're defining the desired state of your servers; so ideally when you run a playbook twice, the second time it has to return all OK and nothing changed as the state is already reached.
What has you most excited about Ansible 2?
Blocks! They are language feature that allow you to group tasks and pass common parameters once they apply to all tasks in the group. This makes playbooks much cleaner and easier to read.
What's the one thing that Ansible can't do that you wish you could automate?
I've thought about that quite a bit. It would be something like:
breakfast: eggs=2 eggs_mode=scrambled coffee=black
But seriously, While Ansible can't make your breakfast yet, there is a lot to be excited about. Be sure to check out Runner, the CenturyLink Cloud solution automation service built on Ansible.
Allan Denot is a DevOps engineer living in Australia, though he's originally from Brazil. In 2001, Allan released a Linux distribution. He continues to be involved in cloud software. He has created products, started companies, and currently blogs on DevOps thoughts at allandenot.com.