Chef vs. Ansible
-
I'm doing some Ansible setup this morning to learn more about it. One of the key differences between Ansible and Chef, besides the age old Python versus Ruby debate, is that Ansible is agentless (the Ansible server contacts the servers to manage them) and Chef is agent based (the servers reach out to the Chef server for their configurations.) Both have their merits, but I wanted to touch on this a little bit.
For agentless, we need to set up correct permissions and enable networking and expose the servers to some degree. On a closed LAN this is not that big of a thing, but should still involve some firewall configuration. When doing this from a LAN needing to reach out to the management server located elsewhere, this can be very limiting.
The agent based process is nice because accounts do not need to be configured but an agent has to be downloaded and installed and configured to reach out to the management server. This is nice because you do not need to expose the server(s) in any specific way nor do you have to configure each server to be reachable - only the management server. This means that a single hosted server can manage servers that are located behind firewalls, are not exposed or even those that have become confused and lost their configuration.
I know that there is always this big push in the SMB for things to be agentless (from Spiceworks itself, backup software on virtualization, monitoring, and more) but in many of these cases, I want an agent. I want the individual machines reaching out to the management server, I want the local processing, I want data collected even when the network is down. Is agentless really that good of an idea for a normal business here?
-
A lot of folks tend to think that an agentless setup is easier. I could go either way, depending on what the product does. For things like backups, provisioning, and server monitoring, I prefer an agent. I don't have any experience with Ansible or Chef, so I can't speak to those. But you can count me in the "Agent, please" camp.
-
In both cases, one would hope that the setup would be automated so that the effort of either would be zero. Once the engineering is done, anyway.
Spiceworks offers both and the agent based is like 100x easier than the agentless. The agentless is what results in 99% of the support issues.
-
heres one way with just using a jump box as an ssh proxy
http://alexbilbie.com/2014/07/using-ansible-with-a-bastion-host/
-
You can also do ansible pull, which I haven't looked into yet. It pull in config files and runs them locally.
-
From their docs:
Ansible-Pull
Should you want to invert the architecture of Ansible, so that nodes check in to a central location, instead of pushing configuration out to them, you can.
The ansible-pull is a small script that will checkout a repo of configuration instructions from git, and then run ansible-playbook against that content.
Assuming you load balance your checkout location, ansible-pull scales essentially infinitely.
Run ansible-pull --help for details.
There’s also a clever playbook available to configure ansible-pull via a crontab from push mode.
-
@johnhooks said:
heres one way with just using a jump box as an ssh proxy
http://alexbilbie.com/2014/07/using-ansible-with-a-bastion-host/
That helps for single, big sites, but not for supporting lots of unique sites, like you would get with many SMB shops sharing a server.
-
@johnhooks said:
From their docs:
Ansible-Pull
Should you want to invert the architecture of Ansible, so that nodes check in to a central location, instead of pushing configuration out to them, you can.
The ansible-pull is a small script that will checkout a repo of configuration instructions from git, and then run ansible-playbook against that content.
Assuming you load balance your checkout location, ansible-pull scales essentially infinitely.
Run ansible-pull --help for details.
There’s also a clever playbook available to configure ansible-pull via a crontab from push mode.
Doing this, there would be no need for the Ansible server at all, I presume.
-
@scottalanmiller said:
@johnhooks said:
From their docs:
Ansible-Pull
Should you want to invert the architecture of Ansible, so that nodes check in to a central location, instead of pushing configuration out to them, you can.
The ansible-pull is a small script that will checkout a repo of configuration instructions from git, and then run ansible-playbook against that content.
Assuming you load balance your checkout location, ansible-pull scales essentially infinitely.
Run ansible-pull --help for details.
There’s also a clever playbook available to configure ansible-pull via a crontab from push mode.
Doing this, there would be no need for the Ansible server at all, I presume.
Ya looks like you could just pretty much create a git repo and they pull from it.
-
Chef can do that too. A lot of people do that. You lose reporting, but it scales like crazy and is very easy to manage.
-
Ya I think it's more suited to central deployments, or small local dev.
I'm assuming tower addresses this. It has job scheduling and reporting with some other stuff, but it's fairly expensive.
-
Yes, the cost of these hosted management solutions seems unrealistic. I know no one that pays for them and they are priced way out of the scope of the SMB. They only make sense for shops with huge numbers of servers which are also the shops that can easily afford to figure out how to run the systems for free. The people who need it hosted are the ones for whom the value is low.
-
You don't think $5,000 a year for 100 nodes is reasonable?
-
@johnhooks said:
You don't think $5,000 a year for 100 nodes is reasonable?
Not so much, no. When you consider that the assumption is that many of those nodes are $5/mo to operate. That could be nearly 10% of your entire server budget!
-
@johnhooks said:
You don't think $5,000 a year for 100 nodes is reasonable?
That's $5000 for what? updates?
I hear you guys talking about Chef and Ansible all the time, but haven't dug into it at all.
-
@scottalanmiller said:
@johnhooks said:
You don't think $5,000 a year for 100 nodes is reasonable?
Not so much, no. When you consider that the assumption is that many of those nodes are $5/mo to operate. That could be nearly 10% of your entire server budget!
lol plus thats the base price with only 30 days of support and no SLA ....
-
@Dashrender said:
@johnhooks said:
You don't think $5,000 a year for 100 nodes is reasonable?
That's $5000 for what? updates?
I hear you guys talking about Chef and Ansible all the time, but haven't dug into it at all.
Pretty graphs and help installing.
You do get remote job running though, but still.
-
@johnhooks said:
@scottalanmiller said:
@johnhooks said:
You don't think $5,000 a year for 100 nodes is reasonable?
Not so much, no. When you consider that the assumption is that many of those nodes are $5/mo to operate. That could be nearly 10% of your entire server budget!
lol plus thats the base price with only 30 days of support and no SLA ....
Exactly. Those prices get a bit crazy. $5/year/server would make a lot more sense. There are many cases where I would pay more for Ansible than I would for the server itself!
