Ansible: config management & deploying code with James Cammarata from Red Hat

Hi there, my name is Mattias Geniar and in this episode of Syscast I am joined by James Cammarata from Red Hat. James is the lead developer on the Ansible project. We discuss getting started with Ansible, using it as config management, as a deployment tool, orchestrating different runs and some of the challenges involved in doing so.

I very much enjoyed this talk with James because I had no former experience with Ansible and after our talk, I feel I have a much better understanding of it. On a side note, if you like this show but you haven’t signed up for my weekly Linux and open source newsletter, I highly encourage you to do so, obviously. You can check it out at cronweekly.com and receive tips and tricks for Linux sysadmins and developers straight into your mailbox every Sunday morning.

Now, without further delay, here’s the show. In this episode of Syscast, I am joined by James Cammarata from Red Hat to talk about all things Ansible. Hi there, James.

How are you?

Fine as well. Thanks for coming on the show. Appreciate you taking the time off for this.

No problem. Cool, cool. I’m guessing listeners here are sysadmins, so we know Ansible or we at least have heard of it.

They may not know you per se, so could you introduce yourself? Who are you? How did you just get into IT, into programming?

Who is James?

Sure. So I’m James Cammarata, like you said. I’ve been with Ansible for just over three years.

I think I was the sixth employee hired by the company after they started up to create a company around Ansible. A little bit of my background. I pretty much went to college to be a programmer.

So I started at basically a company turning Perl scripts into Python scripts for Zope, if anyone remembers Zope. I sure don’t. It was a very popular Python kind of CRM framework.

This was like 2003. So it kind of fell by the wayside a bit. But that got me into programming.

And it was a very small company. And we started out with five people, kind of fell down to three. So I ended up being both sysadmin, programmer, networking, and help desk. as is pretty common at small companies when you’re one of the few IT people there.

So yeah, I pretty much started doing Python right out of college. and basically mainly hacked Python scripts for doing sysadmin stuff. About 2008, I was working at a company. I was building servers all the time, and a friend of mine introduced me to the Cobbler project.

If anybody, I’m sure some sysadmins out there are familiar with Cobbler. It was all about kick-starting servers. And I’d been into open source for a while, so I started contributing to it because it made my job easier.

And basically from that point on, I was contributing to it a lot. And basically, Michael DeHaan, the creator of that project, left. And after a little while, I started running that project.

So I ran Cobbler from about 2010 until I joined Ansible. And Michael DeHaan also started Ansible, so he knew me from the Cobbler days. So when he was looking to hire somebody who knew Python and open source, he came to me and asked me if I wanted to work for Ansible.

I had never touched it before that, so I basically had a very quick ramp up on Ansible at that point.

Full-time Ansible. I was kind of co-maintainer with somebody else who had left the project, and right as I was getting into Cobbler, he kind of came back around and was like, hey, how can I help? I said, here, take it.

So he’s been running the Cobbler project since… So yeah, I’ve been doing Ansible as a full-time job and a half. So for quite a while, the core team was very, very small for Ansible doing the open source side of the project because we were a small company.

Cool. Well, as a sysadmin, I think just reboot the server and you’re done. How hard is it really to be a sysadmin?

Come on. it comes to linux so yeah the entire goal is not to reboot it exactly someday we’ll have uh in memory kernel available for everyone uh the upgrades at least and uh then we can never never uh reboot them anymore um kernel patching in memory so true indeed i wonder how many people actually do that in production it seems like such a gimmick uh i’m not sure yeah how that goes not too many no i think you need balls of steel to do it Going back a bit to Ansible, it’s your current employer. What’s your role exactly? What’s your day-to-day job at Ansible?

Yeah, so like I said, I started working for Ansible and I was basically just a programmer. Michael left the company in early 2015. So at that point, I became the lead maintainer for Ansible.

So I’ve been running the project since January of 2015 last year. Beyond that, once Red Hat bought us, I kind of quit doing the managerial stuff because I was managing the open source team. Now I’m just dedicated to writing programming.

I’m essentially like the architect of Ansible.

All right. What was that like being bought by Red Hat? Did that change your role?

Obviously it did. It’s less of the management side. Was that a good thing for you?

Yeah, no, it’s been really, really good. Ansible was founded by quite a few ex-Red Hat people, so the culture they brought to Ansible was very much inherited from Red Hat. So when Red Hat bought us, the transition was extraordinarily smooth.

It’s the first time I’ve gone through a company I’ve worked for being purchased by another company, and I have nothing to compare it against, but I can only imagine it could not be any smoother than that.

Definitely more people. We mentioned at Ansible Fest last week, and since Red Hat has bought us, the core team has gone from four people to, I think, 13 or 14 now. So that’s just the open source side of the team.

So we definitely got a lot more headcount and more people to help us work on the project and do things like dedicated people to QA, more documentation people. So, you know, definitely a big bonus there. In terms of the day-to-day project, Red Hat has been very hands-off.

They’re just very excited to use Ansible for a lot internally and to, you know… Just use us, like I said, more and more everywhere. The only thing they want is for us to have kind of a longer supported version of Ansible.

Obviously, that’s their business model with the enterprise Linux is a longer support cycle. Whereas before, as an open source project, it was pretty much we supported the current version and that was about it.

Sure. Ansible, most people probably know Ansible as a configuration management system along the lines of Puppet or Chef or SaltStack. But the way I always describe Ansible is that it is a general purpose automation engine.

You can pretty much, if you can do it with a script or anything else, a command line program, you can automate it with Ansible. It’s just extraordinarily flexible. It’s very easy to write modules and other plugins to add on to the functionality.

So if Ansible doesn’t do it, you can pretty much extend it to do just about anything you want it to.

Obviously, like I said, configuration management, but when you have those systems configured, the next step is deploying software on them. That’s where for a long time, a lot of other configuration management systems fell down because it’s really difficult with some of those other systems to orchestrate complex tasks across multiple servers. They were all very, very much focused on configuring one system only. um so the the common example i always give with ansible it’s uh very trivial to do this with ansible is to say you have typical web application you’ve got a load balancer some web servers a database behind them with ansible you can say five at a time take the servers out of the load balancer upgrade them restart things reboot them if you need to reinsert them into the load balancer and then move on to the next five all the while saying if any more than 10% or 20%, whatever you set your threshold to, if that threshold number of servers fails this process, stop, and then you can start rolling things back to bring things back to the state they were in before you started the entire deployment.

You can do all of that with the Ansible out of the box. You don’t have to add on to it at all. Doing that with other systems is a very, very complex Ansible is no problem.

It sounds very impressive. To be honest, I come from the other systems, a Puppet user myself. The scenario that you just described, I’m thinking in my head what that would mean in my Puppet code base, my modules.

And, well, orchestration, like you mentioned it, is, I think, one of the hardest things to get right, especially if it’s on track, keep going. If it’s failing, roll back. Very hard topic to nail.

And I think Ansible, the way you describe it, you’ve got that covered.

Sure, sure. So with Ansible, the main kind of structure of what you run is called a playbook. It’s a YAML document.

Things are listed in order in the YAML. They’re basically just lists of tasks and Ansible executes things in those playbooks in the order they’re listed. So there’s not kind of an eventual convergence scenario that you have with some of the other configuration management systems.

Things are executed more like a script. Some people don’t like that. Some swear by it.

Obviously, we think it’s the best way to do it because then you don’t have to define your dependencies. ahead of time. And if you forget something, you have to rerun it over and over again. I used Puppet for five years in production.

So I’m very, very familiar with having to deal with Puppet in production. I used CF Engine for two years before that. So I don’t know how many people have actually used CF Engine, but yeah, compared to that, it’s…

It’s very, very easy to use. The YAML syntax is very, very straightforward. It’s very, very easy to learn.

I see just constant stream of tweets about, you know, hey, I’ve been using Ansible for three hours and I’m already being productive with it. Just it’s super easy to pick up and learn.

That’s indeed what I’m taking away from all of this. Given your Puppet experience, Puppet is very dependent on, well, it’s a graph that you create. You set up dependencies between services.

It quickly becomes enormously complex. Ansible sounds a lot easier. I don’t mean to put this in the wrong way.

Is it because it’s more basic, more practical? I’m not sure how to define what I’m trying to say here. Puppet ensures something of a higher level abstraction.

If you want to install a package, you just declare a package. Puppet will figure out if it’s yum apt or something else. How would that go in Ansible?

Sure. We resisted adding that functionality for a long time, even though Ansible does it now. Each task is still declarative.

When you list it, you still say package name equals, you know, HTTPD state equals present. So you still declare things. in the state you want them to be in for each task. The difference is Ansible doesn’t compile all of those tasks into a state like Puppet does and then just tell the machine to figure out how to get into that state.

Ansible, like I said, is more script-like. It says one task at a time. Make sure that things are in the state you say them.

Some people, I think that’s a misconception about being simple is that you’re not powerful, but that’s definitely not the case with Ansible. With Ansible, we have over, I think we’re coming up on 600 modules that we include with the distribution. So you can do everything from that very simple file package service configuration management all the way up to spinning up entire environments in EC2 or just about any one of the major cloud environments very, very complex things are done with Ansible every day.

It’s definitely not underpowered while being simplistic, definitely.

Okay. You’ve mentioned Ansible being good at config management and deployment. The way that you describe it now, it’s reaching into the Terraform area of managing your VMs, deploying your VMs.

That’s an actual use case of Ansible, too.

Creating the abstraction is easy. The hard part is the fact that every distribution has different names for those packages or the service names. So creating like the abstract package is easy.

The hard part is like… managing what those names will be across all of your packages or all of your distributions on you know red hat distributions apache is the httpd package but on debian and ubuntu it’s the apache 2 package they have different users different groups different directories they install to so it’s generally it’s somewhat easy to create that abstraction around it but at the same time there’s a lot once you get past that first layer of just saying you know not having to worry about what the underlying package management system is there’s a whole lot more you have to worry about so it doesn’t really save you a lot to create that first layer of excuse me of abstraction oh i agree ubuntu has its strengths red hat has its strengths it’s best to play into them instead of making a generic linux layer on top of it Right. So getting back to your question about roles, roles are essentially chunks of playbooks that are designed to be more reusable than just a monolithic playbook that you write. So you could create a web server role that handles installing Apache or Nginx or whatever web server you prefer across all of these different distributions totally transparently to the playbook that you’re running.

You just include this web server role and you write your role to worry about all the details under the hood.

Okay, so it’s a lot easier to say as a non-techie perhaps, hey, I want a web server. It doesn’t really matter how that web server looks. I just want a working web server.

And the role bundles the different playbooks together.

So a playbook, basically you just list which hosts you’re going to operate on, some other options, and then it’s your list of tasks or your list of roles that you’re going to use for that playbook. Inside a playbook, we have what we call plays. So a playbook can be made up of multiple plays.

Sometimes when you’re automating something, you want a play to work on, say, your web server group of hosts, and then your next play will do something with your database group of hosts. So you might have multiple plays within your playbook. That’s just the terminology we came up with.

But, yeah, basically each play, you list which hosts you’re going to operate on, and then your list of tasks essentially is about it.

Yeah, all of pretty much the user interaction with Ansible is almost entirely through YAML. If you want to write modules to extend the functionality of Ansible, you can write modules in any language. They basically just have to follow a set of rules.

They basically have to take their list of arguments via JSON, and then they have to spit out JSON on standard out that Ansible reads in to parse out the results.

Yeah, absolutely. That’s actually something we just added was the ability to actually have binary modules. So if you had like a compiled Go binary or anything that’s not a scripted language, it would actually work now.

I believe that’s going to be in 2.2. I forget if we put that in 2.1 or not.

Sure. So with Ansible 2.0, for those who aren’t familiar, we basically did a major rewrite of some of the two out of what I call the three major components of Ansible had a major refactoring. Basically, that was because with Ansible, we had gotten so popular, grown so fast over time.

2,200 contributors at this point. There was a lot of people adding code to the database and at times didn’t get added in very sane ways, to put it bluntly. There wasn’t a lot of times decisions that seemed good ended up not being very good.

And it was starting to get difficult to add features to the code without breaking things that seemed very unrelated. So 2.0 was a major refactor. 2.1 was, in a lot of ways, fixing some of the problems that were introduced with 2.0, some of the regressions.

Some people had problems with moving from 1.9 to 2.0, so 2.1 tried to address all of those problems. At the same time, 2.1 added a lot of features like better Windows support, better Docker modules, a ton of features, really. Really cool.

Yeah, that was long planned. We actually started the rewrite in November of 2014 and then continued through after Michael left. I think it was about June of 2015 that we started getting, I think that was when I did the release candidate for 2.0.

The first release candidate was June and then we ended up releasing it in November, I believe. So it was a very, very long development cycle because it was such a major rewrite. It was just a total, some chunks of code were rewritten from scratch to try and make things more extensible, better architecture.

Yeah. Ansible core itself is not that unwieldy. I believe it’s around 30,000 lines of Python code.

The bulk of the code itself lives in modules. Two-thirds of the code base is the module code.

Yeah, so yeah, modules are what I always say are the heavy lifters of Ansible. The modules do all the work. So you’ve got the file, copy, template modules, all the way up to, like I said, modules like the EC2 module, which will start up a given number of instances in EC2.

So pretty much if you want to extend the functionality of Ansible, you do it via modules.

Okay, cool. Say if you were to put on your sales hat, not sure if you do that anytime. I’m a Puppet user.

What would you say to me to persuade me to drop Puppet and go for Ansible?

So you don’t have to buy Ansible. You try it out. It’s open source.

So that’s my first… thing I would say. Second is one of, obviously those are familiar with Ansible, those maybe not. The number one feature of Ansible is that it’s agentless.

We do everything over SSH. You don’t have to install anything on the servers you’re managing. that in itself is a huge benefit over puppet because one of the difficulties you run into with puppet is scaling the puppet master server. Once you get up to, you know, say more than 50 servers, I don’t know kind of what that threshold is now.

Uh, I know when we had a hundred servers, we basically had to run, you know, Pat puppet via passenger and, uh, start scaling it up. We had basically four puppet master threads to handle a hundred servers. So, uh,

That’s cool. Especially when you’re doing cloud deployments or Docker deployments, you don’t want to have an agent running and having to deal with the key management, all the aspects that come along with having that agent running on that system. It’s just something else you have to take care of.

Whereas most people run SSH already on all their servers and have to a lot of times touch those servers. So they have SSH keys set up, which makes it very, very simple to get started with Ansible.

Basically, it’s simplicity. Obviously, Puppet is not the easiest thing to pick up. Chef, a lot of times, you don’t have to know Ruby to use Chef, but it really helps, especially if you’re trying to do anything more powerful with it.

So Ansible is simple. You write YAML playbooks and you can do some very, very complex things. So that’s kind of our sales pitch is, you know, simple, agentless, powerful.

Okay, nice sales hat. It works. Getting back to the practical technical bits, how do you literally get started with Ansible?

How do you bootstrap a new server? And what are your first steps that you should do in order to get started with Ansible?

Yeah, so you can install Ansible a lot of different ways. We package it for just about every major distribution, so you should be able to install it that way. Or if you want to, you could install it via PIP.

Ansible is on PyPI, so you can install it on PIP. You can even do it in a virtual EMV if you wanted to try it out. As a developer, the way I install it is by checking out the Git source tree from GitHub, and we have a script that we ship with it, and it’s in a subdirectory called hacking.

You just source this script called hackingenv-setup, and it modifies your Python path. In your active shell, it doesn’t do anything permanently. It’s just in your running session, tweaks your Python path to use the directory, the source code directory, and you can start running Ansible right away.

So all you have to do is have SSH available. And that’s your bootstrap step. If you don’t have SSH keys, I highly recommend it.

You don’t have to, but otherwise you have to, every time you run Ansible, type in the password for the servers you’re managing, which can be a bit of a pain if you’re managing 100 servers. So I definitely recommend having SSH keys, which most sysadmins have.

Yeah, pretty much. And then just to make sure, we have two ways of running Ansible. We actually have an ad hoc, what we call ad hoc mode, that basically acts like a parallel SSH client.

But the difference is you can run, you run modules via that ad hoc mode instead of just, you know, shell commands, which one of the modules we have is the shell command module. So very simply, you could just do Ansible and then, you know, the host you want to talk to and whatever module you want to run arguments you want to pass to it you know very simply if you just want to make sure you have connectivity you just use the ping module and it’ll tell you that ansible is connected to it and it’s working okay that’s uh that’s one of the ways that you can run so there’s there’s a there’s a push and a pull way i think of uh putting it to run ansible um could you describe both and when would you use one over the other Sure. So Ansible is very much designed to be a push model.

It’s one of the big differences, again, between that and just about every other system out there. Ansible does everything from kind of a centralized host to push things out. Some people think there’s scalability issues with that, but I know of people managing 10,000 servers in a group with that push model.

So if you’re dealing with that kind of scale, not many people are. You shouldn’t have problems. The main parameter there is like the number of forks you use, which is kind of your level of parallel actions that you do.

So you could say, you know, 500 forks across 10,000 servers. You’re basically touching 500 servers at a time. Just depends on how much memory and CPU you have on the system you’re running Ansible from. ansible pull mode was designed to give an option for those people that liked the puppet model that didn’t want to have to always do pushes to their servers in order to do some basic you know make sure their configs didn’t drift things like that so ansible pull mode works by um you typically set it up via cron uh you just just say, you know, Ansible pull and point it at a source code repository.

I think we support SVN and Git at the very least. So it goes, checks out the playbook from the source code repository and then runs it on the system. However often you set it up to via cron or at or whatever system you want to use.

I would say it’s definitely a minority. I don’t have numbers. I don’t know if we’ve asked that on any of our recent community surveys.

We periodically do community surveys to ask questions like that. I don’t recall if we have recently. But if it’s more than 20% of the users, I’d be surprised.

Okay, okay. Going back to the push model then, you also mentioned that you could use a server for this. What’s your best practice?

Should you run this from, say, a laptop for each developer? Would you run this from a central server on which you manage access? What’s the plan, mainly?

It really depends on the security profile of your company. Most larger companies have essentially a bastion or jump host. I would definitely recommend running it from there.

With Ansible, it’s SSH, you can set up tunnels. So you can tunnel through a bastion host if you wanted to continue running it from your desktop or laptop. So it just depends on how people want to use it.

With cloud environments, I typically recommend that people set up a server in the cloud environment to manage that environment from. Otherwise, you’re doing SSH over the internet and your latency and timeouts can vary wildly. So just for a smoother ride, do it from within your cloud environment.

Okay, cool. One of the challenges that I have in Puppet in this case, but I’m sure Chef and the others have it as well. How do you enforce different environments like a development or a staging or a production?

How do you enforce versions to be the same across them all?

The good thing about Ansible is your playbook is detached from your inventory. So you should be able to have the exact same playbook You try it out in your development environment with your development inventory. You then take that exact same playbook, apply it to your QA inventory source, and then up all the way up to prod or however many environments you have.

The tasks you run are decoupled from the inventory. You can change how the playbook functions by essentially having variables on your inventory sources. Your inventory, we call them host vars and group vars.

You have hosts and inventory, they can be in one or up to however many groups you want to have. Hosts and groups can have variables assigned to them in the inventory. So you pretty much kind of override some things based on those variables.

So it allows you to have the same core playbook very easily transfer across your environments.

So the parameters that you can set per host or per group would be the environments. And how do you determine logic then? Say you want a development environment to have, say, a slightly different setup than a production environment, maybe in terms of firewalling.

How would you go about separating those?

Again, you could have… variable files that you want. You could include extra variables as you’re running it. It’s kind of a runtime set of variables.

So you can change, again, the profile of what the playbook or whatever roles you’re running is doing. Say, okay, in development, I want a simple cluster. It’s basically an all-in-one cluster.

But as I go up to QA, I actually want this cluster, you know, say you’re deploying OpenStack, which, you know, the OpenStack team uses Ansible almost exclusively to do all of their infrastructure stuff. So, you know, in dev, you might deploy your all-in-one OpenStack cluster on one system, but then QA, you know, you have your Nova servers and your Quantum servers are all on different boxes, and you can control all of that with… variables on inventory, variables that you pass in at runtime. Sounds very flexible.

Yeah. Are there best practices around this? Is there a recommended way for Ansible to do things?

Sort of a, how would you say, a linting norm? Yeah.

Sure. Actually, there’s an Ansible Lint program out there that was written by a third party to kind of run through some of the best practices in the format of your playbooks and other files that you may use with Ansible. In terms of the actual structure of the playbooks and roles and how you structure that, we’re a little bit more freeform on that because some people like doing things one way and others really like doing it the other.

Some people love roles. Some people hate roles. role. So they do everything with includes, which is a role is basically the same thing as an include, but it gives you a lot more flexibility and is designed to be more reusable by just random third parties.

So the best practices and formatting of the YAML, yes. In terms of the overall structure, there’s two or three ways that people do it. And we’ve held off on telling people any one way to write their playbooks.

Okay, give it a give the freedom to the users. Sounds like a good plan. So it’s also sounds like a perhaps a difficult situation as an implementer.

So say I wanted to use ansible in my environment, and I have the plan to do this on 1000s of servers. It sounds like I really need to think about how I’m going to structure my code, my usage, my inventory. It’s probably, regardless of what tool you’re using, it’s probably best to think about it either way.

But in case of like a Puppet, they don’t enforce it, but they recommend a very specific way of working. So Ansible gives you a lot more freedom.

you know, install both packages. You can install both of them. Might be a little tricky on Ubuntu because Ubuntu likes starting up the services beforehand.

So I would still just install both packages and then I would restart the MySQL service and then restart the Apache service. Before you restart the Apache service, you probably want to deploy your web application to it. So that would be the step before you restart Apache.

Yeah, absolutely. There was a funny anecdote I heard from one of our service people that went out on a business call to help some people do things at a company. And in this meeting, there were salespeople, and he brought up a playbook and said, hey, showed it to the salesperson and said, tell me what this playbook is doing.

And the salesperson was able to say, oh, well, it’s doing this, this, and this. Because it’s very, very readable. The task is just what module you’re going to use and then what parameters to that module you’re going to do.

So you see a shell module being used and then a command line argument afterwards. And you say, oh, this is just running the shell command right here. Or, oh, it’s just starting up these EC2 instances.

It’s very, very, very easy to read.

Okay. I don’t know any Python. I’m a PHP guy myself.

So without any Python knowledge, is it easy to get started with Ansible?

Yeah, absolutely. YAML is one of those, it’s a document language. So it’s kind of crosses, it’s gotten popular enough that it’s crossed outside of just being a Python kind of structured document.

A lot of people use it in many languages. So that’s probably the biggest barrier to getting up and running with Ansible is if you don’t know YAML, learning YAML so that you could properly structure the document.

Indeed, even JSON, if you have to write it by hand, is not the most fun format to document things in. If we could jump into testing Ansible code, how would you go about doing that? You have an Ansible playbook.

How do you make sure it does what you tell it to do?

Sure. So Ansible has a dry run mode that we call check mode. So you can run it in check mode and it will tell you, oh, this module would have changed this.

This module would have changed that. This module didn’t change anything. So you can dry run your playbooks that way to see what it would have changed or not. and then just just like puppet it’s each module action should really design be designed around um being idempotent so you run your playbook if it something failed you can go out maybe fix it run another playbook to fix that and then rerun the original playbook and uh you’re up and running so when you say that there’s a dry run that is actually run against a particular server It’s run exactly as it would be if you were running the playbook live.

It actually goes out, talks to those servers, gathers the information, and does everything right up to that step inside the module that it would have actually changed something, but instead just returns the result that it would have changed.

Cool. A puppet does something similar in there are downsides and negatives to that. And, for instance, if you well, if you part of your, your dry run, or your no up run would add a user and you want to use that user in a later stage doesn’t always work as you planned.

Is there something in Ansible where you mock or you fake those resources that should have been created?

We have package manager for NPM, so you could install the things that way, whatever dependencies there are. So after that, you typically have your code in a source code repository. So Ansible has support for obviously Git, Mercurial, pretty much any of the major source code management.

You can have a CVS module. So you check out your source code, and then you can use other module actions to copy it into place, or if you’re doing something like the… I forget the name of it.

But say you basically copy everything to a directory and then you change a symlink to point at the most recent version. That’s all very easy to do with Ansible. We have modules that create symlinks, copy things around.

It’s the Capistrano way of doing things. yeah yeah it just depends on pretty much a lot of you however you would deploy it today it’s pretty much very easy to take that to the ansible approach um except doing it with modules so that you kind of have this more full feature error handling things like that you know you don’t have to write shell scripts that you have to write all these you know if else if conditionals like oh you know my rc for my git checkout failed and all this stuff that’s all handled via the module code in ansible so it really shrinks what you would have been doing into shell script into just a few tasks in the ansible

Well, I recently, and I mean yesterday, read a blog post, I think, from the Red Hat team about how to deploy such an application with Ansible. It was very, very mostly readable. If I remember my Capistrano days, it’s a bit of a hell to structure things and it’s a bit all over the place.

Ansible sounds like a really good alternative for such a deployment process.

Yeah, and like I said, deploying something on one server is easy. It’s when you’ve got complex actions between many servers, you know, tiers of architecture is when things get complex. I always say, in terms of config management, any one of us will get you what you want, whether you’re using Puppet or CFEngine or Salt or Chef.

Or Ansible, it’s doing the basic file package service stuff is really the easy thing to do. It’s when you’re trying to do very complex things that Ansible really outshines all the others.

Yeah, absolutely. A lot of people actually use Ansible to manage their puppet deployments. It’s a very common use case to the point where somebody actually created a puppet module so that you can trigger puppet runs remotely with Ansible via, you know, very similar to the way you would do with M Collective.

You know, I’ve used PubFix for many, many years, and in all the time I’ve been doing Ansible, I have yet to hear somebody who’s using mCollective in any major way. It’s just not a very easy system to pick up. Have you used mCollective much yourself?

We are actually in the process of implementing and rolling it out to our system, but I agree with the current sentiment. It’s very powerful, complicated, and a bit of a hassle to set up, to secure, to get to a stage where you can set privileges, who can run what, and who should be limited to what. Right.

Yeah, it gets tricky, and Ansible sounds like an easier solution to get something similar out of the box.

Yeah, so a lot of people use it that way because it’s very similar. I tried mCollective in the past, never liked it. I always ended up using parallel SSH or SSH in loops to do my deployments.

I always worked for financial institutions or other places where we didn’t actually have Puppeteer running in our environments because we didn’t want things changing in the middle of the day. We had very strict change control windows that we were allowed to do, you know, things in. So, you know, we always triggered our runs and I wish I’d had Ansible then to do it.

I can imagine an SSH for loop can get you pretty far, but error handling rollbacks going forward, that’s something, if it’s handled by a higher level framework, it’s definitely a win. Yep. Okay, I think I have a pretty good understanding of the powers and strengths of Ansible.

Are there absolute real killer features of Ansible that you’d like to plug that I forgot to mention here?

I don’t think so. Obviously, the killer feature of Ansible is always the agentless, the fact that you don’t have to have anything running on the remote server. But yeah, you pretty much covered it, I think.

Okay.

You know, I still, I really love OpenStack. I love the promise of it. It bums me out that I hear that it’s, you know, so many people have trouble with it.

I think it’s just an awesome idea to have something so powerful, like be able to run your own. cloud of systems uh it’s so many previous companies i’d wish i’d had the ability to just spin up a server to hand off to a developer or somebody else so much easier than doing it through something like vmware or anything else so that i still really love openstack So I hope it gets a bit easier to use for people.

I read horror stories about OpenStack. I think whether it’s rightfully so or not, it gets ridiculed a bit for its complexity. I have a future episode planned on OpenStack.

So I’m curious to see how complex it really is. But as you mentioned, it’s an extremely powerful tool. But it’s a tool.

You need to master it. So yeah. Yep.

Okay, good tip, I think. If listeners would like to reach out to you or ask for help, where can they find you?

The best ways are probably via Twitter. So the, at the Jimmy C T H E J I M I C on GitHub. The other best way, if you want to talk to me right now is we have a couple of chat channels on IRC free note.

We have a hashtag Ansible and a hashtag Ansible dash develop. So if you have an issue or you’re having, you know, you’re looking at the code and you want to, you know, get involved with writing, you know, working on Ansible, definitely catch me that way.

Okay, nice. I’ll include all of your links in the show notes. So if anyone’s interested in reaching James, look at the show notes, click on a few links, and it should be really easy to find.

Just as a closing note, I’d like to give a special thanks to Serge van Ginderachter. I’m not sure if you know him, James, but he helped me prepare some of the questions here. because Ansible to me is a bit of a new territory. And Sergio was my veteran go-to man.

Thanks, Sergio, for helping me out here.

Yeah, indeed. Every time I say something good about Puppet, he comes in and says, Ansible is nice as well. He’s an evangelist of Ansible.

I think he’s one of the best boards you can have to pronounce the project. For the listeners, if you listened to the show and you liked it, I would really appreciate it if you could share it on either social media or give a rating in iTunes or wherever you get your podcasts. It helps me get more exposure and helps grow the show.

So thanks. Take care, James. And for the listeners, I will see you next time.

Bye-bye. Thank you. Thank you.