“Last week we hosted the first AnsibleFest conference outside of the US – and I’m pleased to say it was a roaring success. With 320 attendees on the day, it was our largest attendance, despite the rather grey and wintery London weather!
The crowd made it for us – fielding great questions, and even interacting with one another during the Q&As. One person’s attendance particularly stood out – for anybody watching Twitter there was an amazingly detailed and informative stream of the day’s events being tweeted. If you didn’t catch Matt Macdonald-Wallace’s stream on the day, here’s a super summary…” -Mark Phillips, EMEA Director of Business Development, Ansible, Inc
No time to read through? Check out these direct links to the festival’s talks:
“Ansible 2 is coming, and it’s going to be awesome!” was the message at AnsibleFest London last week. Talks covered the latest Ansible 2.0 news (scheduled to be released at the end of March); using Ansible Tower to give developers the ability to stand up their development environment at the push of a button; using Ansible to manage Windows and why Rackspace – one of our partner companies – moved from Chef to Ansible for standing up OpenStack (Spoiler Alert: it’s quicker and simpler).
We did our best to share the event online by live-tweeting the whole thing from the front row and here’s our summary of what went down
The day opened with a welcome and “state of the nation” address from Saïd Ziouani, Ansible’s CEO, covering everything from the news that the London AnsibleFest was the biggest one they had ever done with 325 attendees to the impressive stat that “1 out 3 forks of the Ansible code-base results in a contribution back to the community”.
Saïd also stated that the goals for the coming year all focused around compliance, hyper-scale computing, Microsoft Windows support, container technologies such as Docker and Google Kubernetes and the ability to configure your network from Ansible plays.
The first tech-talk was by Marius Boeru from BigStep and covered the ways in which Bigstep are using Ansible to provision large-scale, big-data solutions for multiple customers.
Marius and quite a few other speakers mentioned Vagrant as a good option for standing up development environments (something that we use heavily here at DevOpsGuys) and ensuring that your Ansible plays work as expected.
One of the points that Marius made, and one that was repeated throughout the day, was that Ansible is simple, easy to extend and easy to integrate with, so it’s a very good choice to get developers up and running, as well as providing the operations teams with a flexible tool to reduce their technical debt.
The next talk was by Sebastian Göttschkes. Titled “Vagrant and Ansible, a love story”, the talk covered the point made by Marius about using Vagrant to test things and ensure your development and operations teams can iterate quickly through the development cycle.
The key topic that most people seemed to take away from Sebastian’s talk was that “Works on my machine” is no longer an acceptable response to broken/undeployable code.
Tools such as Vagrant and Ansible allow your teams to recreate production on their local workstation and model how changes to code and configuration would affect your running environment; simply writing code and claiming it’s ready for production without full testing is not an option anymore!
Another point that Sebastian was keen to emphasise was that if you are doing any part of your configuration/installation manually then you have effectively failed at DevOps. Everything should be automated, and, with the various Vagrant providers available for RackSpace and other cloud providers, there really isn’t an excuse: you really should “Automate All TheThings!”.
The third talk was from Ali Asad Lotia and surrounded his work with the NFL on analysis of in-game statistics picked up from individual players on the pitch. Even before he had started talking about the challenges of intermittent connectivity, changing start times and developers who had never deployed code to production, Ali had everyone engaged with the statistic that they were tracking every player on the pitch to within 6 inches of their position with a latency of less than half a second!
Ali talked about a pattern familiar to most organisations when deploying a manual process in a README becomes a shell script and then the shell script gets out of control – and why this led them to decide on using Configuration Management tooling. The next step was to decide where to focus their efforts and (in common with a number of other speakers) they settled on Ansible because they were looking for something with a low operational cost combined with simplicity. Complex solutions were not an option here.
A large part of the reason for focusing on Ansible for Ali and his team was that NFL stadiums have incredibly bad internet connections, meaning that running an agent-based configuration management system such as Puppet or Chef was out of the question because they couldn’t guarantee that the system would call home and update the configuration at the right time. Ansible’s “push” model gave them the ability to control the connection as best they could and only push changes when they needed to.
As with Sebastian’s talk, one of the key points of Ali’s speech was that with Ansible you can start at a simple level. The first playbook that Ali wrote effectively copied the README file so you could read it just as easily. The team were then able to iterate and improve the Ansible plays so quickly that it actually freed them up to spend time looking at other tasks!
Lunch followed this talk, with all the usual free T-Shirts, stickers, cuddly toys and USB keys that accompany conferences such as this as well as a good opportunity to talk to some of the sponsors about what they are up to.
After lunch Jon Hawkesworth from M Modal opened the afternoon session with a talk on managing Microsoft Windows with Ansible. Whilst the talk was good it became apparent that there was more work to do on Ansible to get it working well. The good news was that a lot of this work is being done as part of both a major refactor in the Windows modules and the on-going development of Ansible 2.
Some of the more useful modules highlighted by Jon included the ability to install packages via win_msi, download files or packages to a box via win_get_url and the fact that you can use PowerShell to write modules for Ansible, meaning that Windows developers and operations teams won’t have to learn Python.
The second talk of the afternoon was by Walter Bentley from Rackspace and centred on why he chose to take Rackspace away from Chef and towards Ansible for their OpenStack deployments.
Walter focused on the simplicity and ease that Ansible provides, as well as the fact that it is written in Python; they have a large team who can develop it further if required. Once again, not requiring an agent to run on each host also came up as a positive thing, because all you need is Python and an SSH connection – something that almost all modern Linux distributions have.
One of the key reasons that Walter wanted to automate the installation of Rackspace Private Cloud was to ensure that when he did a demonstration for a client, it took less than five hours reading 62 pages of documentation. Using Ansible and Vagrant, he and his team have managed to get the deploy fully automated and far more quickly: they now deploy at least ten Rackspace Private Cloud installations using this method each week
Walter pointed out that: “the great thing about Ansible is that you can run it over and over again and it only changes things that are different to their desired state”. This is a vital part of any configuration management tooling as it avoids unnecessary service restarts or re-configuration of correct system settings.
After a short break, we were back with James Cammarata from Ansible talking about Ansible V2 and what we could expect to see there. It was interesting to learn that the primary reason behind version 2 was to clear up a lot of technical debt in the code base, and also to see some of the new features.
The features that stood out in Ansible 2 were the ability to have “try/except” blocks in your plays, allowing for recovery from failures in plays and better error messages.
The final two talks of the day were about Ansible Internals and Ansible Tower. Ansible Internals deserves a blog post of its own and we hope to bring that to you in the next couple of weeks so we’ll leave that for now apart from to say that if you’re not looking at extending Ansible then you should – modules, plugins and filters are incredibly powerful and will help you.
Ansible Tower is the commercial offering from Ansible that provides auditing and role-based access control (RBAC) for your infrastructure. Mark Phillips explained how you can point Ansible Tower at your existing Git repositories and then assign permissions to various users to allow them to interact with your infrastructure in different ways.
One example given was that the Operations Team might need to be able to stand up any type of system, whereas QA might only require the ability to standup a dev/qa environment instead
Ansible Tower also provides dashboards that can be used as part of a compliance program and give you an overview of what has failed and where, however the main part of Mark’s message was that Ansible Tower allows you to let “non-technical” people provision environments for their own use without the need for support tickets!
All in all the conference was a great day out. We learned loads, met up with friends and we will definitely be back!