81–90 of 274 posts
Earlier quoted context omitted.
Puppet doesn't require you to do any Ruby. Also, Salt is written in python, for which the same argument holds as well for almost all environments.
It's hard to find an O/S w/o python these days. In the env. I work in we don't have ruby at all installed (Solaris, CentOS, BSD, Windows).
I'm not a web developer but I have a side-project that runs on a cobbled together EC2 instance. The server state is in theory documented in a set of of shell scripts and virtualenv requirements files. I know that I should be doing this in a more robust way but whenever I try and read up on configuration management tools like Puppet and Chef, they're all described in comparative terms - Puppet does X better than Vagra…
For example:
Package 'libapache2-mod-php' should be installed. File '/etc/apache2/sites-available/customersite' should be the contents of this file we have on the master server. File '/etc/apache2/sites-enabled/customersite' should be a symlink to above. Directory '/var/www/customersite' should be the contents of this git repository. Command 'apache2ctl graceful' should be run if any of the above change.
With these five rules, you can turn a default install of Ubuntu into a webserver providing client files in a matter of seconds.
Once you have those rules written, you then apply them. You can wildcard, so that hosts matching 'www*.yourhostingco.com' get these rules.
Now, when you want to add a new webserver to your cluster, you install a new Ubuntu instance, you register it with the Salt master server, and then trigger a state update, and you're done. No SCP'ing files, no manual git checkouts, no copy-paste-edit configuration management.
Then, once you've got all that, you can get into templating. You can do templating both on the contents of files (e.g. for memcached config, insert the machine's internal IP address instead of having one config per server) as well as the rules themselves to avoid having a ton of boilerplate (for module in 'list','of','python','modules', install the module via pip with these rules).
One of my favourite benefits of something like Salt is that if you use Salt to do all of your configuration, then just back up your salt config to github or wherever, then you always have a record of how you did things. You don't get the incomplete documentation or missing steps that happen with most approaches.
As a sysadmin managing a cluster of systems, it can be life-changing.
I'm still looking for a configuration management system that doesn't assume that the first step towards managing servers is to add a new "master" server. From the thread, ansible looks promising. In the meantime I'll keep using chef-solo until opscode kills it.
Earlier quoted context omitted.
Awesome. How many people have reviewed it for flaws? How many people have reviewed OpenSSH?
If it's a concern, just lock it up behind iptables. Only let your master talk to your minions and your minions can only talk to your master.
Earlier quoted context omitted.
While I would prefer ansible as well, the author does show why ansible is problematic for some people: > Chef works atop ssh, which – while the gold standard for cryptographically secure systems management – is computationally expensive to the point where most master servers fall over under the weight of 700-1500 clients That said, unless you must have 700+ simultaneous slave connections, you should probably make lif…
I think that "limit" is just FUD - can anyone explain where it comes from? With persistent SSH connections, the overhead of SSH encryption should be comparable to other encryption methods.
I've used Fabric, Chef, Puppet, and Ansible, and have settled on Ansible; it's a sort of middle ground between Fabric and Chef that does more than just run commands on servers but doesn't require me to buy into a whole elaborate universe of configuration management servers and whatnots. Ansible is great. The ZeroMQ stuff makes sense if you're pushing configurations inside a data center, but it's a dealbreaker for us…
reads article about A I've tried B, C, D, and E, and I like E.
I've used Fabric, Chef, Puppet, and Ansible, and have settled on Ansible; it's a sort of middle ground between Fabric and Chef that does more than just run commands on servers but doesn't require me to buy into a whole elaborate universe of configuration management servers and whatnots. Ansible is great. The ZeroMQ stuff makes sense if you're pushing configurations inside a data center, but it's a dealbreaker for us…
There are ways to configure salt with masterless or behind vpcs or with syndics that are perhaps an enhanced security model. But defaults are for regular use cases, and for most cases the defaults are fine.
I suggest checking it out.
I'm not a web developer but I have a side-project that runs on a cobbled together EC2 instance. The server state is in theory documented in a set of of shell scripts and virtualenv requirements files. I know that I should be doing this in a more robust way but whenever I try and read up on configuration management tools like Puppet and Chef, they're all described in comparative terms - Puppet does X better than Vagra…
[deleted]
The benefit of Salt, which it has over Ansible, is that it doesn't have to use SSH (which, as mentioned in the article, doesn't scale well to large deploys), and it can do a great deal more things than just 'run shell scripts from a file'.
If someone were to read only your comment they wouldn't see the benefit of these systems at all, which is unfortunate.
Is there a comparable tool for Windows? Powershell works great for executing commands on arbitrary servers (which sounds like the basis of Salt), but it'd be great to declaratively say "I want the server in this state" like the config management side of salt. I assume there is a tool built atop of Powershell like this somewhere?
http://projects.puppetlabs.com/projects/1/wiki/Puppet_Window...
http://wiki.opscode.com/display/chef/Fast+Start+Guide+for+Wi...