All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
How to Manage LEBs (128MB): Puppet vs Chef vs Ansible vs Salt vs cfengine
raindog308
Administrator, Veteran
Looking for something like one of these, with these requirements:
the master I can run on something big (4GB VPS with SSD CentOS 7, though it's also doing other things)
the client or whatever is OK running on a 128MB VPS.
I don't control the initial templates.
encrypted connections since we're going over the internet
free
These are typically OvZ LEBs from typical LET providers. I don't want to do my own image, just make sure my sshd_config is put in place, my firewall rules are deployed, my library of scripts is put in place, my accounts are created, etc., and of course make sure it stays that way if I change on the master, etc.
Ideally: (1) image from provider's panel, (2) install agent/client/whatever, (3) edit it's config, (4) everything magically moves to my standard, (5) profit.
I'm leaning towards cfengine because of its extremely low memory footprint, opportunistic network philosophy, and encrypted connections. However, I know if any of the newer platforms are LEB-friendly.
Comments
You're opening a lot of interesting threads lately.
Watching this one.
I wonder if you could get away without having to install a client on the OS? Something that opens an SSH connection to the new server and then automatically deploys onto it..
@hawc - That's what Ansible does. No client / agent - works off pure SSH.
A lot of the hard work for puppet is handled on the master end as it is very centralized heavy. (compiling of the catalog etc), though puppet does require ruby which can sometimes take more resources.
I personally handle all our node configurations in puppet so I can attest to it being very useful and good at it. It will setup the whole node from original OS install to production ready. Chances are someone will have written what you are looking for as well already: https://forge.puppetlabs.com/ .
The only issue you may hit is with the puppet agent, not sure how much resources it takes.
Edit: I looked it up. As per the puppet documentation you should have no issue with the agent:
https://docs.puppetlabs.com/puppet/latest/reference/system_requirements.html
was about to say the same. @raindog308, no sleep lately
http://docs.puppetlabs.com/pe/latest/install_system_requirements.html
"To manage ten or fewer nodes, we recommend the following minimum hardware:"
I don't have a VPS with 6GB of RAM. Biggest I have is a 4GB at WiredTree which is certainly very fast but also runs cpanel, etc. I don't have 6GB to dedicate to puppet anywhere. Since it says "minimum" I'm thinking I should take them at their word...?
I'd have maybe ~20 nodes max and most of those are 128s or 512s.
Hmmm...
Most of the RAM comes from puppetdb. Which if I recall is Java based.
I have run it with less and it appeared to work fine. It also depends on how complex your config is for the agents.
If you want, I can spin you up a VM if you want to test how much ram it uses?
For salt, 128MB may not be enough:
Idle (salt-minion): 58M (total)
Running, 3 SLSes (salt-minion): 110M (total)
This is even on HostUS's highly minimized Ubuntu images. You may be able to get it working with SSH vs the standard salt-minion which will reduce memory usage further, and probably bring it within your requirements. It will be much slower due to use of SSH instead of zeromq
However, it does meet the rest:
salt-master memory usage: 484M with 16 minions (idle). Memory fluctuates due to usage of salt reactors, salt mine/etc
Initial template condition is not a problem, may need some adjustments to automatically remove software, but that is it.
salt is encrypted by default, minion and master do a key exchange when the minion first connects.
Yeah, Ansible is really quite LEB friendly. It's written in Python, you don't need any software running on the nodes other than an SSH daemon (dropbear has worked too in my experience, not just OpenSSH, if you're super paranoid about memory usage) and Python installed, and even the master isn't particularly heavy. You can just keep a simple config file on the master, or if you write a dynamic inventory script it can pull on demand from whatever local or remote system you already keep a list of them in.
It's pretty simple to configure too - playbooks are not hard to write (here's a simple example) especially since there are a crapload of modules written for most things you'll want to do. It does take a little bit of effort to pull yourself out of the "write a shell script" mentality - you're saying what state you want things to be in rather than what commands to run to get there (although that's certainly not exclusive to Ansible).
By default Ansible is push rather than pull - on the master you push your config to the VPSes. If you prefer pull, you can install ansible-pull on the servers and put it in a cron and they'll pull configs from a git repo.
It's worth noting that whatever system you use, the master (or the place your configs are stored) has root access to everything, either literally or effectively - the system doesn't understand that you don't want an account added for Skiddy McSkidderson and added to sudoers, it just knows that that was in the config. It's a good idea to severely limit the amount of stuff running on the master and it's not a good idea to run the master on OpenVZ at all unless you trust the host with everything.
The fashion seems to be to massively overspecify the minimum requirements - a lot of software now, especially anything devops-y, seems to do it.
But he's my L3 support tech!
Or run your master locally (push mode).
Wait...could I run my (Puppet) master at home? No problem going out, trickier having anything coming in though possible (typical residential comcast setup).
Ansible looks awesome!
That's the only one that I know how to use, and I like it because doesn't need an agent on your boxes, and it should run "out of the box" on most distros. Even some of the most light ovz templates have the software needed for ansible.
@raindog308
Can you update us on what you choose? I'm interested in learning more about this stuff too. (I'm leaning on ansible right now)
Assuming you can use the required ports, I don't see why not
I do devops at a large (Fortune 20) company, and do consulting on the side. From your list, I prefer Chef, as I find it most powerful. Chef Server has a lot of built-in components (Redis, Postgres, Solr, and a few other things), and can take up a bit of memory for heavy use, although I have it running on a 1GB RAM VPS for my side projects, and it works fine. Chef Server is optional (but highly-recommended); you can use Chef Zero or Chef Solo instead, but you won't be able to do fancy things like search or orchestrate between nodes. I haven't tried running the client on a 128MB RAM VPS, but it might just work.
Ansible is the lightest-weight option in your list; it essentially copies over some python scripts via ssh and runs them. I never thought YAML was a good fit for it, but it gets the job done, for the most part.
I haven't touched Puppet in a while, so I won't comment on it, other than to say that Chef seems to have a bigger market share nowadays (which means more online resources).
cfengine isn't really in the picture much nowadays, although I'm sure it's capable.
Going off of what @amhoab said, assuming you're trying to decide between chef and ansible I found an infographic from 2014 that might be helpful
Ansible has the least overhead and is by far the easiest to get started with in my opinion. All it needs is SSH access and python on the target machine. I've been using it for over two years now and I'm extremely happy with it.
I've tried puppet before but had some bad cases of agents going wild and using up all the RAM. That could have been a bug of course, but it scared us away at the time. A major downside of puppet was that they had their own configuration language and that actions weren't performed in the order they were in a file, but randomly. Thus requiring us to set up a maze of dependencies.
This thread needs a poll, but it's a +1 vote for Ansible from me.
I've tried Chef / Puppet before and I found Ansible to be the best for me. Both in terms of learning curve / ease of deployment and the fact that I don't need an agent means I deploy quickly without having to touch the remote machines first (other than having SSH already setup).
I still need to try Salt though to see how that compares.
The infographic is, understandably, a little out of date:
Ansible does support Windows and Mac OS (although strangely enough, the Windows version can only be used to manage other Windows boxes with no support for SSH/Linux out of the box)
the Ansible community, if not larger, then at the very least, on par with Chef's (read: many third party Ansible tutorials, playbooks available online)
DOH wish i'd actually tried setting up ansible ages ago, always looked like something that would take a long time to get working but actually it was really easy to setup.
Even if it just ends up being used to do the apt/yum updates it should save me a load of time.
Not exactly a complete newborn.
Pick a yearly LEB from a high integrity, high competence provider in a bulletproof network.
I went with @drserver in @incero DC.
That's interesting. Puppet Labs is here in Portland, OR so I hear about them a lot more. I didn't know their market/mind share had shrunk.
+1.
But I think you meant to say: "...and python on the Ansible "master" machine...", n'est pas?
I think I'm going to go with ansible. The "no agent, everything over ssh" is just unbeatable for low end VPSes. Might not be the best choice if you're managing British Petroleum but, well, I'm not.
Per @lbft I think I will make my master my home linux box. Since it's all push, it's a lot safer to do it that way since it's a root ssh key.
I will write it all up...once I find a theme to refresh my blog...
Might be late for the party, Salt supports no-agent, ssh via Salt-SSH:
https://docs.saltstack.com/en/latest/topics/ssh/
I use Ansible in my job, not a big fan of it:
Just my 2 cents.
EDIT: formats and typo fixes.
Nope, every client needs python as Ansible runs python commands on the target machine.
How is it fragile? Especially compared to something like Puppet, which you can break by forgetting it set a single dependency in a maze of sometimes thousands of jobs?
How so?
To me that's the whole point. I want to tell a tool what I want it to do rather than telling it what I want, because in the latter case the documentation side-effect of defining your infrastructure as code gets diminished.
If I come on a bit strong in the above it's because I'm tired and in a hurry. I don't mean to attack you or be offensive.
So in Javascript we always wrote the code in that way - based on a state this is how I want to transition to this new state. All was good for a while until we had to deal with hundreds of states and their transitions. Overtime we had to manage thousands of little bits of information that even Chrome's engine couldn't deal with - it was horribly slow and error prone.
Then came ReactJs - rather than writing our Javascript with transitions in mind we declare what we want the state to be at a given time (declarative). We saw that ReactJs was magnitudes more efficient because it knew more about the current state than the developers did (or ever could know) - it was able to decide the best way to transition. Rather than writing lots of code that would statistically be buggy we could write a small amount of code with ReactJs - less code means less bugs (assuming that ReactJs was made correctly).