1. Hi Mark, first can you tell us more about you?
Ok, I'll try to keep it brief. I've been working in technology for nearly 21 years now. Some might say that makes me old, I would probably agree with them. I've spent most of that 20 years doing infrastructure automation. I guess my core skills are Unix, Linux,... For most of the last decade, I've been working in large investment banks, although earlier in my carreer I was really fortunate to work for the biggest ISP in the world during the dotcom boom, from 1996 to 2001 I was working for UUNET which was a fabulously exciting time. Working in sort of a dotcom boom versus working in an investment bank, they're almost parallel opposite on the top of the environment. So most of this last decade has been about automation, working with configuration management tools, I've been working with a few of the common tools that we know these days before I discovered Ansible a couple of years ago.
2. Can you explain us what Ansible is?
Ansible is an automation tool but it's far more than just configuration management. I think that a lot of people see Ansible as configuration management just as its competitors Puppet, Chef, tools like that. But it's actually quite a lot more, it's also an orchestration tool, a deployment tool, and arguably each of these facets gives us a workflow engine, so we can do code deployment, provisioning, configuration management. You string all these things together and we can orchestrate an entire environment. On top of all of that, it's actually done very simply, there is no agent involved, it works over SSH which is as we all know - for the most part - a very nice trusted secure reliable transfer mechanism. We use yaml for all of our playbooks which are a definition of your configuration, which also makes it quite easy to read, it's not like reading xml or json for example. So it's simple.
That's a very good question! There are a lot of choices. At the AnsibleFest conference in London, I said at the beginning of the day "Everybody who works in technology knows that there are always at least half a dozen ways to do everything in technology, you can always pick them". So picking that one tool to do lots of jobs is a difficult choice. I would say picking Ansible over the other tools is a fast entry point to getting things done simply, quickly, it's so easy to learn and to pick up, developers can use it, operations people can use it, arguably network engineers can use it. And the fact that it is self documented as well means you can actually show your configuration to a manager and he's going to understand it because you've written a natural language description of everything you do. So I tend to say to people it's a 10 seconds install, after you installed it you can manage 1 server, 10 servers, 10,000 servers. So by the time I've just explained that to you, you could have installed it and got going, so why don't give it a whirl?
The agentless aspect of course gives it a nice easy entry point. I think the language is far easy to understand, it's much more simple to do some things in Ansible than it is in other tools. There are over 200 modules in Ansible Core, each one of these modules designed to do a specific job - put a file into place, template a configuration, start a service, deploy an EC2 AMI - and each one of those because it is a self contained tool to do a job, it's kind of log in unix ethos, small tools designed to take data in, put data out, but do a job well. So I think it's a complete but flexible tool set, arguably more certain than competitors.
Yes, I'd agree fully. Each one of those little modules I was talking about are designed to do a job, and that job is to set a desired state. People are fond of using in the industry the frase "Desired state is what we are aiming for, not a mathematical function". Each one of these modules aims to put something in the desired state. If it's in the state, it's already in, it doesn't do anything with it. If it needs to be changed, it will change it. So therefore I would say, you don't need to test every single one of your steps to get to that desired state because that's what I'm supposed to be doing for you. Testing I think should be done on the infrastructure as a whole when you try to deliver a service for example. It might be a web service, you could test that web service at the end of your Ansible play and make sure there is a key word on the home page or something like that. Or the rest of the steps have obviously done their job if the end goal has been reached.
6. Regarding security, what are the best practices to manage secrets with Ansible?
Another fine question! There are at least half a dozen different ways to do this. With Ansible Core, invariably I would recommend people use SSH keys rather than passwords and I would recommend passwords on SSH keys. Of course that then becomes a management issue. I think when you've got a team of 2 or 3 people, sharing that key/password about between those people is absolutely fine. Once your team starts to grow and you have staff turning organisation you probably want to be thinking about a better way of managing those credentials. Now arguably with Ansible, that's Tower. Tower is our commercial product that sits on the top of the open source products. Tower does credential management, so you can put SSH keys, you can put passwords into the UI, you can delegate access so that people can use the keys and use the passwords but cannot see them and they cannot extract them from the interface in any way either. So then you get key management, staff can come and go, they don't have the need to have the actual keys to the kingdom literally.
7. Can you tell us more about Ansible Tower?
Tower leverages the power of Core. I have no doubt that almost everybody who these days will be using Ansible itself will be using the open source product, and they will be loving the fact that they get everything done with what we call 'Core', the open source product. That's the way we want it to be and that's the way we want it to remain. What Tower does is leverage that and sits on top of Core. It gives role-based access control, so you can carve an organisation into teams and users and you can give those users access to credentials and projects and inventories that they need to, so you may carve open environment into development hosts/production hosts, and you can delegate an access control in Tower. As I mentioned in the previous question with credentials, you've got full credential management in there. You've also got job history, so everytime you are on Ansible playbook on the command line, at the moment you haven't got that centralised history which is what Tower then gives you so you can see every run as it has been run in the past - you can look at the output exactly as it happened at the time. Then finally you've got the nice web page GUI - some people like a nice web page GUI.
I love the way it's progressing of course. I used Ansible as an engineer, the open source product in the summer of 2013, so I guess it was 18 months old then. Now we are another 18 months down the road, so yeah I've been working with it for roughly over half its life. I think these days, the product is coming along fabulously. One of the things that I've always liked about it, even it's a very young product, was coming off the back of 7 years of working with another well-known configuration management tool, I was astounded at how complete the product was even after 18 months, and not just how complete it was but how flexible it was built, the extensibility was amazing back then. When I first started using it I think it was 60 modules in Core, now there are 210. The modules keep adding, that flexibility is allowing that to happen, I think it is only just getting better.
9. Last question, Ansible 2 is coming, can you tell us what is new in this version?
I can tell you a little bit about what's new in it. It's basically been a refactor. So the sum of that original code, naturally it's an open source project, lots and lots of people working on it, lots of stuff imported into the code base, and we've always had a good process for what we pour back into the product to try maintain that excellent engineering that has been done since the beginning. But version 2 augments that basically. It makes it even better, gives us an even more flexible future. I think there are some additional benefits coming to version 2, the specifics of which I don't know because I don't get time to toy with it like I used to when I was independent.