21 ms·

Salt: Like Puppet, Except It Doesn’t Suck

354 points by Baustin 13y ago

justincormack 13y ago
I much prefer the immutable server model [1] to the puppet model. Build a new tested server with the new config and roll that out. [1] http://martinfowler.com/bliki/ImmutableServer.html http://martinfowler.com/bliki/ImmutableServer.html
- rektide 13y ago
  There's words written about "automatic configuration" in that link but I don't see any guidance or information on what those configuration tools are. The focus is certainly not on automatic configuration: the focus is on use and re-use of images, on taking images, doing something to them, and getting new images. The notion is deeply flawed to me: using an image as a precondition for making an image, over time, becomes an intractable mess and requires very careful supporting documentation to prevent the scheme from devolving into a bunch of "buckets of bits" with no transparency into what work has gone on to make it that way. The #1 thing that I enjoy about automated tooling is that I can take a bare OS and spin up a complete new system in a matter of minutes, and I get to watch that entire process happen before my eyes. There's no mystery, no external dependencies, no existing work I'm riding off of: everything that happens is visible to me in an immediate way. There's a value & use to immutable images, but please decouple your image making from past images made: no one wants to root around to figure out what twelve horrible things you did to install Java 9 image instances back whenever, nor are they going to have any fun reproducing it on the twenty nine active variants of that ancestor image when there's a security fix to be done.
  - justincormack 13y ago
    I think most people use puppet to build their immutable images at present. It is still rather different from running it on production. Sure you should not start from a non reproducible point.
contingencies 13y ago
Salt/Puppet/whatever. I ignore them all. Why? I have put a lot of thought in to this area. IMHO, the overwhelming problem with salt/cfengine/puppet style solutions (which I will refer to as 'post-facto configuration tinkerers', or PFCT's) is that they potentially accrue vast amounts of undocumented/invisible state, therefore creating what I refer to as configuration drift. IMHO, a cleaner solution is to deploy configuration changes from scratch, by deploying clean-slate instances with those changes made. In addition, versioning one's environment in this way creates an identifiable point against which to execute automated tests. (This class of solution I refer to as 'Clean-slate, Identifiable Environments' or CSIES.) Examples are Amazon AMI's, and any other kind of versioned/identified VMs. PFCT's deployment paradigm tends to be relative slow and error prone. CSIE's tend to be fast and atomic. PFCTs are headed for the dustbin of history. They are temporary hacks that clearly grew from old-school sysadmins' will to script. CSIEs embrace modern day devops, as more holistic entities that embrace virtualization and recognize the integrity of the environment as critical to preventing ridiculous numbers of environment-induced, service-level issues that are an expensive tangent to service development, testing and deployment. Thus, I would argue that what we are looking at with PFCT's is a failed paradigm, and with CSIEs, the now real and current opportunity for something far more elegant. (Disclaimer: Haven't tried ansible or vagrant first hand, but they do seem to be PFCT's to me.)
- chongli 13y ago
  Do you have any resources where one might learn about CSIEs? Where to get started, available tools, best practices, etc.
  - contingencies 13y ago
    To be honest nobody else uses the term... I just made it up! But I've been wanting to further publicly elucidate my thinking in this area for some time... maybe soon I'll get around to more. I would say the responses to this post have been sort of comfirmative (not barking up entirely wrong tree; others can see the logic of my thinking to some extent). I personally believe that this area is going to expand rapidly, building off of the trajectory begun by present first-generation of cloud infrastructure. Perhaps for someone who wanted to practice thinking in this area, I would a say exercise is to limit yourself purely to third party and cloud based infrastructure but demand high performance and global (multiple cloud provider) availability, and challenge yourself to write a multi-service system including a deployment tool that automates your solution and actually produces maintainable infrastructure. If you follow through, you will understand the problems.
boothead 13y ago
This is timely! I've just started writing a set of salt states to capture the set up of my new dell xps 13 (sputnik) so I never have to go through the pain of setting up xmonad, emacs and various other development environment stuff again. What I really like about salt is that everything is in one place and all goes towards building the same data structure that everything runs off.
jtreminio 13y ago
I was frustrated with Puppet when I first started. All I wanted was a VM to install a few things so I could do some development and not have to worry about managing my VM. It turned out to be a rabbit hole. As soon as I thought I learned just enough to get it running, something else popped up that stopped me. That's why I created PuPHPet [1]. So far the reception has been fairly positive. At one point in my learning, I got fed up and tried Salt. I couldn't get the Salt hello-world running. I followed the directions to a T. If your tutorial is incorrect, or hard to follow just to get the most basic version up and running, it will turn people away. Also, this was all on top of Vagrant. [1] PuPHPet - https://puphpet.com https://puphpet.com
- tr4656 13y ago
  This is a pretty quick way of setting up basic vagrant boxes. Nice to see this exists.
- joemaller1 13y ago
  PuPHPet works very well for getting basic Vagrant boxes up and running. Thank you.
- nkuttler 13y ago
  Interesting. I find the salt documentation excellent and haven't found any serious bug in it. Too bad it didn't work for you and that you gave up so soon.
- dave1010uk 13y ago
  PuPHPet looks really good. What's the default PHP setup? It would be great to be able to switch between and configure mod_php, fastcgi, fcgid, PHP-FPM, suPHP, suExec, etc.
  - jtreminio 13y ago
    Default is: * Ubuntu Precise 64 Bit (12.04.2 LTS) * Apache * PHP 5.4 You can switch between Apache/Nginx and PHP 5.4/5.3 (5.5 coming today!)
gaadd33 13y ago
Is communication to/from ZeroMQ encrypted? If not it seems like this wouldn't be a very secure way to configure or distribute files over anything other than a VPN or LAN?
- kinofcain 13y ago
  Yes, they encrypt the messages in the application layer before sending them over zmq.
- the_mitsuhiko 13y ago
  It's encrypted but why do you do configuration management through anything else than LAN/VPN?
- DASD 13y ago
  They use AES and RSA but their implementation has had vulnerabilities. http://docs.saltstack.com/topics/releases/0.15.1.html http://docs.saltstack.com/topics/releases/0.15.1.html https://github.com/saltstack/salt/commit/5dd304276ba5745ec21fc1e6686a0b28da29e6fc https://github.com/saltstack/salt/commit/5dd304276ba5745ec21... Here's a good article( http://missingm.co/2013/06/ansible-and-salt-a-detailed-comparison/ http://missingm.co/2013/06/ansible-and-salt-a-detailed-compa...) with a comparison to Ansible that others are also mentioning here. Ansible uses KeyCzar which which seems more sane than rolling your own crypto as many readers here on HN know.
wunki 13y ago
I just released a open-source package which enables you to create a Django centric stack on Vagrant with the help of Salt. It was indeed very easy to write. You can check it out here: https://github.com/wunki/django-salted https://github.com/wunki/django-salted
- terminalmage 13y ago
  Wow, this looks great. I've got a talk proposal submitted for DjangoCon this fall and might just integrate this into the presentation, should it get accepted.
- StavrosK 13y ago
  Same thing for Ansible: http://www.stavros.io/posts/example-provisioning-and-deployment-ansible/ http://www.stavros.io/posts/example-provisioning-and-deploym...
hi2usir 13y ago
"Salt’s approach was far simpler." Funny, that's how I feel about Ansible compared to everything else including Salt.
- crdoconnor 13y ago
  Funny, that's how I feel about salt compared to ansible.
cowmix 13y ago
For years I have been trying to spread the gosspel of bcfg2 because, while not perfect, I thought was a more complete system over Puppet or Chef. Bcfg2, however has some big warts of its own AND it never really caught on. In the past few months I've been slowing converting to SaltStack and it really is everything I ever dreamed of for a CM system. Fast, easy, real-time. Lovin' it.
- Goladus 13y ago
  If bcfg2 was a complete system, it never caught on because the documentation was entirely missing. Every time I looked at it, I blocked on actually getting anything done because I couldn't find an equivalent to these reference manuals: http://docs.puppetlabs.com/references/latest/type.html http://docs.puppetlabs.com/references/latest/type.html http://docs.opscode.com/resource.html http://docs.opscode.com/resource.html https://cfengine.com/archive/manuals/cf-manuals/cf2-Reference#Concept-Index https://cfengine.com/archive/manuals/cf-manuals/cf2-Referenc...
susi22 13y ago
IMO, ansible is even better: https://github.com/ansible/ansible/ https://github.com/ansible/ansible/ It doesn't require any deamon and does all its work over the good old unix fashion way: SSH. And it's python too.
- ch0wn 13y ago
  And if you don't like Python, you usually don't have to touch it. The tasks you run on the server can be any kind of executable. They read some JSON from stdin, do their action and write some JSON to stdout. Whether that program is a Python/Perl/Ruby/LUA script or go binary doesn't matter.
- lobo_tuerto 13y ago
  From the article: "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. Salt’s approach was far simpler." Does that assertion about Chef somehow don't apply to Ansible? On the use case: "I have this command I want to run across 1,000 servers. I want the command to run on all of those systems within a five second window. It failed on three of them, and I need to know which three."
  - tomaac 13y ago
    Ansible can use SSH or ZeroMQ, which is much faster.
  - dbarlett 13y ago
    Two solutions: pull-mode playbooks [1] and fireball mode [2] (temporary ØMQ daemon). [1] http://www.ansibleworks.com/docs/playbooks2.html#pull-mode-playbooks http://www.ansibleworks.com/docs/playbooks2.html#pull-mode-p... [2] http://www.ansibleworks.com/docs/playbooks2.html#fireball-mode http://www.ansibleworks.com/docs/playbooks2.html#fireball-mo...
  - susi22 13y ago
    Well, ansible by default runs with paramiko which is a python implementation of SSH protocol. It will also keep connections open for multiple commands. It also has a pull mode and it also has a fireball mode which uses 0mq: http://jpmens.net/2012/10/01/dramatically-speeding-up-ansible-runs/ http://jpmens.net/2012/10/01/dramatically-speeding-up-ansibl... However, you're not forced to use this. In the beginning, you can just seed your CentOS or debian with a Kickstarter or seed file and then run your inital thing with ansible simply over ssh (using all the goodies, ssh-agent, password less ssh etc..). One huge plus for ansible is also that it used yaml which is rather simple. I've been following both project for >1 year and it seems that recently ansible has picked up a lot and will probably make the "race" (IMO).
moe 13y ago
Dead-end. Use ansible.
memset 13y ago
I think salt is neato, but I also find it very frustrating to use! (Possibly through no fault of salt itself - I feel like I must be missing something.) I am generally able to SSH into a box and get things configured the way I need. However, I have huge amounts of trouble translating that into salt scripts. Consider logrotate. Here is the only documentation I can find on the topic [1]. From this, I have no idea what to put in init.sls to make sure a given log file is being rotated correctly. It seems this would work on the cmdline, but not necessarily in a salt script. And that's just for logrotate! My uswgi + nginx configuration - translating that into salt - I don't know where to begin. How do I make sure things get installed in a certain order? (Answer seems to be having 10 directives, for 10 packages, each depending on another, to enforce order.) Is there anything that more closely mirrors what I actually do when configuring the box? SSH in, set certain values, etc? I guess I could write a shell script (or use fabric) but then I seem to have lost the point of configuration management. [1] http://docs.saltstack.com/ref/modules/all/salt.modules.logrotate.html http://docs.saltstack.com/ref/modules/all/salt.modules.logro...
- Jedd 13y ago
  Hey memset - these sound like pretty straightforward questions (with straightforward answers). Perhaps asking on the mailing list, or hop onto the #salt channel on freenode IRC?
  - memset 13y ago
    That is a great suggestion. I almost never do this for fear of sounding like a noob, but I ought to try giving it a shot more often.
    - tech-dragon 13y ago
      As one of the people on that list who may well respond there, I'll reply here as well so its on the record. You will be very well off if you read and 'digest' the Salt docs on States first, before moving on to modules, pillars, grains, custom returners, etc. What you probably need to do with logrotate is take the configuration that you normaly setup on your servers, then add it to your salt system. So top.sls calls 'logrotate' running the 'logrotate/init.sls' and that has a definition that says "I want logrotate installed, I want it running as a service, and by the way take the file 'logrotate/config.conf' and shove it in /etc/logrotate.d/ as <correct filename>, p.s. If i change that file, restart logrotate" With States & the requisite declarations to enable salt to know what order things need to be in, you shouldnt have much trouble adding a simple service like logrotate along with a specific config file to use for that service.
tptacek 13y ago
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 having things hosted externally.
- 23david 13y ago
  you care about network security, why are you exposing ssh ports in public anyhow? Put them behind a VPN. 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.
  - calpaterson 13y ago
    > you care about network security, why are you exposing ssh ports in public anyhow? Put them behind a VPN. You don't need to do this. SSH is secure enough. Require key-based authentication and leave SSH on port 22.
    - hexedpackets 13y ago
      Switching SSH to any other port is a good idea as it will reduce the random attacks against it. Sure, those drive-by attacks are pretty weak and not much of a threat against a hardened configuration and the real attackers will find the new port anyway, but it reduces noise significantly. Cleaner logs are easier to parse, so the net result is that you can spot attacks that you care about much more easily.
      - nuclear_eclipse 13y ago
        Install fail2ban, leave ssh on port 22, and have clean logs.
cultureulterior 13y ago
Personally, I don't think puppet sucks
- susi22 13y ago
  The problem is most dev-ops and sysadmins don't know ruby and that's a HUGE disadvantage. In the end configuration management will often by done by sysadmins.
  - pilif 13y ago
    I'm only managing 24 machines with puppet, so nothing fancy, but I managed to do all of the stuff I needed without writing a single line of Ruby code. That was handy for me too as while I'm somewhat familiar with Ruby, I'm no expert at all. I can read Ruby no problem and I can write ruby that's not-quite-idiomatic and I'm terribly slow at it.
    - susi22 13y ago
      I forgot to mention that just installing ruby is a HUGE PITA on anything but the most common OSes. It took me 3h last week to get it on a CentOS installed. And I don't even want to try to get it running on our Solaris hosts... Point is: Python is the number one scripting language (after bash) for sysadmins just like Perl used to be.
      - yxhuvud 13y ago
        yum install ruby took you 3h? It may take slightly longer if you want 1.9, but it still exists in fedora so it should not take 3h to solve.
        awj 13y ago
        As a developer that primarily works on ruby, I can see it if he wanted 1.9.3. Most of the references you'll find on that tell you to use @environment_wrapper_of_the_month, and those are deep rabbit holes for people who know nothing about the language.
abtinf 13y ago
Yet another un-googlable project name. Pretty much kills it for me.
- frankwiles 13y ago
  Have you tried Googling salt stack? I've had zero problems finding tutorials and documentation.
- a3n 13y ago
  https://duckduckgo.com/?q=salt+configuration https://duckduckgo.com/?q=salt+configuration
Goladus 13y ago
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.
- sciurus 13y ago
  You can also run puppet without a master server.
  - Goladus 13y ago
    Indeed. The reason I am currently using chef instead of puppet doesn't have much to do with relative technical merits.
- crdoconnor 13y ago
  http://docs.saltstack.com/topics/tutorials/quickstart.html http://docs.saltstack.com/topics/tutorials/quickstart.html
- akoumjian 13y ago
  You can run salt masterless. See the quickstart. http://docs.saltstack.com/topics/tutorials/quickstart.html http://docs.saltstack.com/topics/tutorials/quickstart.html
  - Goladus 13y ago
    Thanks, it may even be that a salt master is lightweight worth configuring. But I should note there's a difference between "can run" and "intended to run." It's as much a semantic thing as a technical thing. Instead of thinking about an unconfigured node as a "minion" awaiting orders and provisions from central command, I prefer to think of a node like a stem cell, fully capable of differentiating itself based on signals that it receives. You need a way to update the DNA and a way to send the signals, that's it. This may seem like a meaningless difference, since there is still value in centralized services (package repositories, security, reporting, monitoring). But it's still a subtly different focus and over time yields different results. For my part I think the distributed, organic "stem cell" way of thinking will win out over "master/minion" in the long run.
UtahDave 13y ago
SaltStack also won at Gigaom Structure last week! http://gigaom.com/2013/06/20/devops-player-saltstack-wins-structure-launchpad-competition-and-investor-interest/ http://gigaom.com/2013/06/20/devops-player-saltstack-wins-st... (I'm a SaltStack employee)
- jemeshsu 13y ago
  Whole article about SaltStack winning the award, and not a link back to SaltStack website.
crb 13y ago
> MCollective (which Puppet Labs acquired several years ago) was (and remains!) fiendishly complex to set up. I didn't find MCollective hard at all - you just install some debs, a message queue server (Stomp was easiest at the time - it's now deprecated, but surely is not much different to RabbitMQ?) and it Just Worked for me. And there was a great screencast. Did it get far more complicated since I used it last?
- druiid 13y ago
  Well, rabbitmq is kind of a pain to get working with it. Additionally, the modules for rabbitmq and mcollective, for puppet, don't really work that well together (read: I had to re-write the ones I found to get them working).
  - apenney 13y ago
    I'm starting work at Puppetlabs in exactly a week's time as part of a brand new "module team" and I personally promise you here and in the open that I am going to tackle the puppetlabs-rabbitmq module and fix it so that it actually works and isn't an abandoned wasteland. Come to that I'm hoping we can start building out a full set of mcollective modules to replace the existing ones that will be fully supported and kept up to date so that getting mcollective running will be as easy as including a class and waiting. A huge part of this job is ensuring community patches get merged in and contributors get treated as I would like to be treated when contributing to a project. I hope we can reverse your experience with modules within a few months (I took this job because I've been in exactly your position, grabbing official modules and having them not work at all!)
    - druiid 13y ago
      FYI we've spoken in the #puppet channel about just this issue ;).
- daenney 13y ago
  To be honest, I've never had an MCollective deployment Just Work(tm). It's always taken some serious debugging to figure out what the heck went wrong this time. RabbitMQ works but is slightly problematic since the authors have a morbid penchant for not wanting to support anything but Apache ActiveMQ. Ask a question about MCollective and RabbitMQ and the answer you get is 'switch to ActiveMQ'.
1gor 13y ago
https://github.com/seattlerb/rake-remote_task https://github.com/seattlerb/rake-remote_task is all you need if you use ruby. require 'rake/remote_task' set :domain, 'abc.example.com' remote_task :foo do run "ls" end
- danudey 13y ago
  State management is about a lot more than 'execute this command on a server' (which is discussed in the article). It's about creating a set of rules and performing idempotent actions. If you're just running shell commands, it's easy to screw up and waste your time or break your server by accidentally having the same commands run twice.
otterley 13y ago
When used with Chef Server 11 (or Hosted Chef), Chef scales reasonably well. You install a client on each node, and the client speaks to the server via HTTPS + REST. The unqualified assertion that Chef uses ssh is inaccurate. You can run chef-solo via ssh if you like, but you'll run into the same scalability ceiling as with any other ssh-based solution.
SandB0x 13y ago
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 Vagrant which does Y better than Chef, etc. I quickly lose patience and get back to digging myself into a deeper technical hole. Is there a non-recursive explanation of what these tools are able to do and where someone like me should start? Edit: Thanks for the helpful responses!
- danudey 13y ago
  These tools allow you to specify a state and then specify which servers should have that state. A 'state', loosely speaking, is a collection of definitions of 'X should be Y'. 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.
dmohjoryder 13y ago
What I prefer about ansible above all others, besides its simplicity, is that its use case scales up and out. By that I mean ansible can be used for platform/app stack provisioning while OS/infra sys admins maybe another tool. To often an agent based approach causes a conflict with OS sys admins and platform/app team regarding ownership/sharing. I want to offer self service as much as possible. Further, most cfg mgmt tools are monolithic in that they want to manage all servers as tho a single team/overload manages them all, rather than various independent sys admin teams. With various independent teams its just too much hassle trying to share roles appropriately or setup separate master/agents. Ansible does not have these issues.
- terminalmage 13y ago
  http://docs.saltstack.com/ref/clientacl.html http://docs.saltstack.com/ref/clientacl.html
kapilvt 13y ago
The thing that bugs me about salt is the almost complete lack of testing/coverage. They had tons of egg-face releases for crypto bugs, upgrade issues, things a basic test suite would have solved. I'd rather not trust my production environments to something that's a roll of the dice of whether its working, secure, or upgradable on a given release.
WickyNilliams 13y ago
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?
- sciurus 13y ago
  Puppet and Chef both support Windows. http://projects.puppetlabs.com/projects/1/wiki/Puppet_Windows http://projects.puppetlabs.com/projects/1/wiki/Puppet_Window... http://wiki.opscode.com/display/chef/Fast+Start+Guide+for+Windows http://wiki.opscode.com/display/chef/Fast+Start+Guide+for+Wi...
- lmickh 13y ago
  As mentioned, this can be done with Chef, Puppet, and Salt, but be careful about how you go about it. It is important to recognize when it is best to leverage AD for your Windows configs. It is easy to fall down the rabbit hole of trying to implement things in a CM tool/Powershell combo that could be done in AD far easier.
  - drummer32 13y ago
    Genuine question: Why would you have Windows servers joined in an AD domain? Or are you talking about pushing changes to workstations?
    - AjithAntony 13y ago
      Because the services you provide depend on a domain for authentication and configuration like Exchange, Citrix, IIS, Sharepoint, SCCM, and every other Microsoft server product. I am dying for the chef/puppet/salt/ansible/cfengine recipe that will let me fully configure this stuff, including the domain memberships.
- ipmb 13y ago
  Salt can configure Windows machines, but you need to have the master running on *nix iirc.
gunmetal 13y ago
Salt is missing templates, the ability to use higher level programming language and all the environment/roles that I find the most powerful part of Chef.
- Game_Ender 13y ago
  You are wrong on all counts here. Salt supports Jinja2 template engine, so you can template your states [1]. You define custom states in python [2]. In the root configuration file (top.sls) you target configuration based on host name, grains (machine specific information) [3]. 1 - http://docs.saltstack.com/topics/tutorials/states_pt3.html http://docs.saltstack.com/topics/tutorials/states_pt3.html 2 - http://docs.saltstack.com/ref/states/writing.htm http://docs.saltstack.com/ref/states/writing.htm 3 - http://docs.saltstack.com/ref/states/top.html http://docs.saltstack.com/ref/states/top.html
- pestaa 13y ago
  That statement is very very wrong. Salt has templates, renderers, grains, while supporting all the data structure languages you can dream of. In fact, it is the most flexible software I've seen recently.
- crdoconnor 13y ago
  Salt has jinja2 templates.
- terminalmage 13y ago
  jinja2 and mako are supported, and you can even write your own renderer without much effort if a templating language is not supported. There's even a renderer for pure python, allowing one to write config files in python for more control and flexibility. One wonders if you've ever actually tried Salt. It really is OK to have an approach of: "I like Chef and it works for me." More power to you. Everyone should use the tool that works for them.
v0land 13y ago
I use SaltStack for managing a render farm consisting of 73 Ubuntu nodes. My requirements are rather simple, really: most states just install some packages, put configuration files into place (sometimes using a template) and enable/start services. However, I can't recall a single problem when setting everything up. SaltStack is clean, simple, and just works.
dmourati 13y ago
It seems most people miss the fact that any sufficiently large system is going to require both a pull-based and a push-based solution. So, take ansible. Primary use: push. But has ansible-pull. Look at puppet. Primary use: pull. But has mcollective. IMO, and I am not there yet but soon to be. The gold standard is to combine two strong players that specialize one each in push/pull. For me, it is looking like ansible/puppet.
deleted 13y ago
[deleted]
- 3am 13y ago
  If someone can't get over the Ansible startup costs, then they have no business managing a system... I can't speak for Salt (last time I tried to use it was in 2010, and it was atrocious then and I haven't gone back).
  - terminalmage 13y ago
    That would be an impressive feat, given that the first commit for the project was in February of 2011.
    - 3am 13y ago
      What a bonehead I am. This is what happens when you say to yourself, "that was about 2 years ago" and you base it on 2012. My only excuse is that I was working on a system config & management product and that I'm having a busy day... I upvoted you for correcting my record.
tegansnyder 13y ago
I use Salt to run commands across our EC2 environment to do things like restart Varnish, clear logs, and run updates. Paired with Unison for file synchronization it works well when your auto-scaling kicks in and you need your new AMI to be synched from staging.
mncolinlee 13y ago
We're actually a Windows-centric shop and have been actively evaluating configuration management solutions for Windows-based virtual machines. Initially, we were only looking at Puppet, Chef, and a commercial product called uProvision along with Vagrant. I was surprised to find that Salt had a real community behind it. Our greatest challenge has been coming up with a tool which can manage images for both VMWare and Microsoft Hyper-V. This article introduced a web integration between Salt and libvirt called Salt-virt. Has anyone tried this interface for managing images? Does it work better than the young integration between Vagrant and libvirt?
- mncolinlee 13y ago
  For anyone else looking, I just found Foreman. This seems to do exactly what we're looking for, but it uses Puppet instead of Salt. Even if it requires a Linux server, making our solution more complicated, it appears to meet our needs very nicely. http://theforeman.org/ http://theforeman.org/
dysinger 13y ago
Puppet is mature and has tons of cookbooks & community. You may not like it but saying it "sucks" is not right. It works and is used tons. Chef doesn't run over SSH in any environment I've used that wasn't a toy (vagrant w/ chef-solo). Please fact check. Fanboy article.
misiti3780 13y ago
I use fabric for everything just because I dont have time to learn another one of these technologies. This salt article seems great - but at the end of the day (and I may be way off base here) all I want to do is install a given version of a piece of software on my server. I dont want to create a receipt (chef), or learn another configuration format (sounds like I would need to do this with Salt stack), etc. My fabric file really seems to do only three things: use pip to install shit that is python (I use Django), use apt-get to install anything that is ubuntu specific, and make wget calls to various pieces of software, pull them down, and build them from source. Until there is an easy way for me to do this without needing to learn yet another technology, I will continue to use fabric (or, until the job of doing this gets so big I can hire a dev ops guy that actually already knows, but I am not there yet :) ). Sorry for the rant, it's just every time I see these articles I wish I had time to learn the technology but then I realize I don't. So - is it just me or is there seem to be a big/huge learning curve for all of these dev ops technologies?
- gchpaco 13y ago
  These technologies come into their own when you are managing large fleets of servers; but by the same right, you need to offer a lot of sophistication to make large fleets of heterogeneous servers work. When you have five servers these seem baroque and overly complicated, but when you have five thousand servers...
- tech-dragon 13y ago
  Yaml is a hair above "properly indenting my templates" as far as complexity goes. You write django templates, you can handle Yaml ;-) As current 'devops guy' on a django project myself, salt works wonderfully. Salt has states available that let you setup all that software, create the virtualenv you need (including telling it you want to use the requirements.txt that you pulled down with your django project source code - Salt gives me my own little Heroku :D ) and for anything left in those wgets you can throw a block of salt cmd.run calls using specified ordering to enable them to run neatly in the sequence you desire.
AaronBBrown 13y ago
This article makes a claim (...Puppet...Suck(s)), but does not take even attempt to explain what it is that sucks. What, specifically, "sucks" about Puppet and Chef and what is so much "simpler" about Salt or Ansible? As an Ops guy who has been running Puppet since 2008 (and Chef most recently) against hundred of servers, I don't see the simplicity reflected in the documentation, nor do I find Puppet or Chef particularly complicated. (Ok, Chef's attributes system is a bit confusing at first, but it is hugely powerful.)
- fusiongyro 13y ago
  From the article: > 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. Salt’s approach was far simpler. I think I'm with you (without the experience): I find "it works over ssh" a lot simpler than "we wrote a custom protocol on 0mq." Simplicity apparently has lots of interpretations. I couldn't care less if ssh performs well enough to support a trillion connections. In practice, you only need a handful, usually one. Maybe Salt is fantastic. I'm not really in a position to judge. The article made it sound interesting to me, but I'm not sure attacking Chef/Puppet was really necessary, especially since it wasn't really expounded on.
- ecopoesis 13y ago
  The main reasons I dislike Puppet: 1) It's slow. Puppet runs take forever and use a lot of resources. 2) The Puppet language is terrible. Basically it looks like someone took Ruby and hit it with the stupid stick. Trying to build reusable components nearly impossible without resorting to hackery. I have no idea is Salt/Ansible/Chef are any better, but I'd be willing to give any of them a try based on just these issues.
knowshan 13y ago
Both Salt and Ansible look interesting. It's much easier to define system state using Ansible or Salt than Puppet. However, I am not sure how would one use Ansible where VMs get launched dynamically (private cloud/virtualization fabric where devs can instantiate systems) and then receive their configuration without any manual steps. For example, one can create kickstart/VM-images which get a hostname based on certain regex pattern, register with a Puppet master, the Puppet master auto-signs certs matching this specific hostname pattern and then client nodes receive their catalog. This is really useful pattern wherein systems pull their configuration state almost immediately after boot. It requires manual setup only while writing kickstart/VM-iamge profile and Puppet master configuration. Ansible's SSH keys setup requires manual intervention, however, I think it can be automated using pre-defined keys in kickstart/VM-images. Haven't tried it yet though...
- killing_time 13y ago
  Yes, having predefined keys in your VM images does the trick, and is exactly what we do for (almost) zero-intervention deployments of our servers in my particular environment. We tend to destroy and recreate servers more often than we scale out, so we haven't bothered to remove the manual step of adding the server's hostname to the ansible inventory_hosts file. However, that's easily automatable... Ansible will _execute_ your inventory_hosts file if it's executable, and IIRC it just needs to return a JSON or YML data structure representing all your servers and the groups they're in. So, as long as you have a library which can query your infrastructure (e.g. boto for EC2 etc) it's not hard to automate this.
spudlyo 13y ago
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. It doesn't have to be this way. The situation where one host repeatedly needs to talk to hundreds via SSH is precisely where the SSH ControlMaster socket shines. This saves you a ton of overhead by not having to start up and tear down the session every time you want to issue a command via SSH. I often use this trick on busy Nagios servers that execute many active checks via SSH -- it works well.
knowshan 13y ago
Good to see tools that work as a system configuration framework and also allow command execution. [ControlTier](http://www.controltier.org/ http://www.controltier.org/) had (don't think it's actively developed now) options to execute general system commands, configure systems and application deployment. But it was fairly complex and required [ant](http://ant.apache.org/ http://ant.apache.org/) skills.
uggedal 13y ago
I used Puppet for a few years (and created a few modules for it https://github.com/puppetmodules https://github.com/puppetmodules). I switched to Salt a year ago. My main motivation were its simplicity (YAML+jinja), lower memory consumption, easier source code both to read and contribute to, and its support for both push and pull based architectures. If you want to get a feel for how salt looks like when managing some servers and laptops you can take a look at my states: https://github.com/uggedal/states https://github.com/uggedal/states
frio 13y ago
From skimming the top level of comments, it seems most people don't like these tools. Fair enough. That said, on-topic, I just wanted to say that having tried Puppet, Chef and Salt, I've found Salt the easiest to use. Straightforward installation (no messing with Ruby versions/rvm/etc.), really simple setup (systemctl start salt-master; systemctl start salt-minion; salt-keys -L; salt-keys -A yourbox; done), and the YAML-based configuration syntax has been a breeze to work with. Really quite pleased with it; it's made getting a few of my hairer boxes under control much easier than I expected (and much easier than I found with Chef or Puppet).
ishbits 13y ago
I've recently been thinking I need to learn Chef or Puppet. This thread has convinced me to pick up and try Ansible first.
tetsusoh 13y ago
emm, Private chef also use zeromq to implement the pub job feature. Puppet has MCollective (with ActiveMQ) to implement the similar feature.
WestCoastJustin 13y ago
I've thrown together a little puppet demo if anything is interested. Highlights what puppet is, and how it works. http://sysadmincasts.com/episodes/8-learning-puppet-with-vagrant http://sysadmincasts.com/episodes/8-learning-puppet-with-vag...

354 points by Baustin 13y ago

I much prefer the immutable server model [1] to the puppet model. Build a new tested server with the new config and roll that out. [1] http://martinfowler.com/bliki/ImmutableServer.html http://martinfowler.com/bliki/ImmutableServer.html

rektide 13y ago
There's words written about "automatic configuration" in that link but I don't see any guidance or information on what those configuration tools are. The focus is certainly not on automatic configuration: the focus is on use and re-use of images, on taking images, doing something to them, and getting new images. The notion is deeply flawed to me: using an image as a precondition for making an image, over time, becomes an intractable mess and requires very careful supporting documentation to prevent the scheme from devolving into a bunch of "buckets of bits" with no transparency into what work has gone on to make it that way. The #1 thing that I enjoy about automated tooling is that I can take a bare OS and spin up a complete new system in a matter of minutes, and I get to watch that entire process happen before my eyes. There's no mystery, no external dependencies, no existing work I'm riding off of: everything that happens is visible to me in an immediate way. There's a value & use to immutable images, but please decouple your image making from past images made: no one wants to root around to figure out what twelve horrible things you did to install Java 9 image instances back whenever, nor are they going to have any fun reproducing it on the twenty nine active variants of that ancestor image when there's a security fix to be done.
- justincormack 13y ago
  I think most people use puppet to build their immutable images at present. It is still rather different from running it on production. Sure you should not start from a non reproducible point.

contingencies 13y ago

Salt/Puppet/whatever. I ignore them all. Why? I have put a lot of thought in to this area. IMHO, the overwhelming problem with salt/cfengine/puppet style solutions (which I will refer to as 'post-facto configuration tinkerers', or PFCT's) is that they potentially accrue vast amounts of undocumented/invisible state, therefore creating what I refer to as configuration drift. IMHO, a cleaner solution is to deploy configuration changes from scratch, by deploying clean-slate instances with those changes made. In addition, versioning one's environment in this way creates an identifiable point against which to execute automated tests. (This class of solution I refer to as 'Clean-slate, Identifiable Environments' or CSIES.) Examples are Amazon AMI's, and any other kind of versioned/identified VMs. PFCT's deployment paradigm tends to be relative slow and error prone. CSIE's tend to be fast and atomic. PFCTs are headed for the dustbin of history. They are temporary hacks that clearly grew from old-school sysadmins' will to script. CSIEs embrace modern day devops, as more holistic entities that embrace virtualization and recognize the integrity of the environment as critical to preventing ridiculous numbers of environment-induced, service-level issues that are an expensive tangent to service development, testing and deployment. Thus, I would argue that what we are looking at with PFCT's is a failed paradigm, and with CSIEs, the now real and current opportunity for something far more elegant. (Disclaimer: Haven't tried ansible or vagrant first hand, but they do seem to be PFCT's to me.)

chongli 13y ago
Do you have any resources where one might learn about CSIEs? Where to get started, available tools, best practices, etc.
- contingencies 13y ago
  To be honest nobody else uses the term... I just made it up! But I've been wanting to further publicly elucidate my thinking in this area for some time... maybe soon I'll get around to more. I would say the responses to this post have been sort of comfirmative (not barking up entirely wrong tree; others can see the logic of my thinking to some extent). I personally believe that this area is going to expand rapidly, building off of the trajectory begun by present first-generation of cloud infrastructure. Perhaps for someone who wanted to practice thinking in this area, I would a say exercise is to limit yourself purely to third party and cloud based infrastructure but demand high performance and global (multiple cloud provider) availability, and challenge yourself to write a multi-service system including a deployment tool that automates your solution and actually produces maintainable infrastructure. If you follow through, you will understand the problems.

boothead 13y ago

This is timely! I've just started writing a set of salt states to capture the set up of my new dell xps 13 (sputnik) so I never have to go through the pain of setting up xmonad, emacs and various other development environment stuff again. What I really like about salt is that everything is in one place and all goes towards building the same data structure that everything runs off.

jtreminio 13y ago

I was frustrated with Puppet when I first started. All I wanted was a VM to install a few things so I could do some development and not have to worry about managing my VM. It turned out to be a rabbit hole. As soon as I thought I learned just enough to get it running, something else popped up that stopped me. That's why I created PuPHPet [1]. So far the reception has been fairly positive. At one point in my learning, I got fed up and tried Salt. I couldn't get the Salt hello-world running. I followed the directions to a T. If your tutorial is incorrect, or hard to follow just to get the most basic version up and running, it will turn people away. Also, this was all on top of Vagrant. [1] PuPHPet - https://puphpet.com https://puphpet.com

tr4656 13y ago
This is a pretty quick way of setting up basic vagrant boxes. Nice to see this exists.
joemaller1 13y ago
PuPHPet works very well for getting basic Vagrant boxes up and running. Thank you.
nkuttler 13y ago
Interesting. I find the salt documentation excellent and haven't found any serious bug in it. Too bad it didn't work for you and that you gave up so soon.
dave1010uk 13y ago
PuPHPet looks really good. What's the default PHP setup? It would be great to be able to switch between and configure mod_php, fastcgi, fcgid, PHP-FPM, suPHP, suExec, etc.
- jtreminio 13y ago
  Default is: * Ubuntu Precise 64 Bit (12.04.2 LTS) * Apache * PHP 5.4 You can switch between Apache/Nginx and PHP 5.4/5.3 (5.5 coming today!)

gaadd33 13y ago

Is communication to/from ZeroMQ encrypted? If not it seems like this wouldn't be a very secure way to configure or distribute files over anything other than a VPN or LAN?

kinofcain 13y ago
Yes, they encrypt the messages in the application layer before sending them over zmq.
the_mitsuhiko 13y ago
It's encrypted but why do you do configuration management through anything else than LAN/VPN?
DASD 13y ago
They use AES and RSA but their implementation has had vulnerabilities. http://docs.saltstack.com/topics/releases/0.15.1.html http://docs.saltstack.com/topics/releases/0.15.1.html https://github.com/saltstack/salt/commit/5dd304276ba5745ec21fc1e6686a0b28da29e6fc https://github.com/saltstack/salt/commit/5dd304276ba5745ec21... Here's a good article( http://missingm.co/2013/06/ansible-and-salt-a-detailed-comparison/ http://missingm.co/2013/06/ansible-and-salt-a-detailed-compa...) with a comparison to Ansible that others are also mentioning here. Ansible uses KeyCzar which which seems more sane than rolling your own crypto as many readers here on HN know.

wunki 13y ago

I just released a open-source package which enables you to create a Django centric stack on Vagrant with the help of Salt. It was indeed very easy to write. You can check it out here: https://github.com/wunki/django-salted https://github.com/wunki/django-salted

terminalmage 13y ago
Wow, this looks great. I've got a talk proposal submitted for DjangoCon this fall and might just integrate this into the presentation, should it get accepted.
StavrosK 13y ago
Same thing for Ansible: http://www.stavros.io/posts/example-provisioning-and-deployment-ansible/ http://www.stavros.io/posts/example-provisioning-and-deploym...

hi2usir 13y ago

"Salt’s approach was far simpler." Funny, that's how I feel about Ansible compared to everything else including Salt.

crdoconnor 13y ago
Funny, that's how I feel about salt compared to ansible.

cowmix 13y ago

For years I have been trying to spread the gosspel of bcfg2 because, while not perfect, I thought was a more complete system over Puppet or Chef. Bcfg2, however has some big warts of its own AND it never really caught on. In the past few months I've been slowing converting to SaltStack and it really is everything I ever dreamed of for a CM system. Fast, easy, real-time. Lovin' it.

Goladus 13y ago
If bcfg2 was a complete system, it never caught on because the documentation was entirely missing. Every time I looked at it, I blocked on actually getting anything done because I couldn't find an equivalent to these reference manuals: http://docs.puppetlabs.com/references/latest/type.html http://docs.puppetlabs.com/references/latest/type.html http://docs.opscode.com/resource.html http://docs.opscode.com/resource.html https://cfengine.com/archive/manuals/cf-manuals/cf2-Reference#Concept-Index https://cfengine.com/archive/manuals/cf-manuals/cf2-Referenc...

susi22 13y ago

IMO, ansible is even better: https://github.com/ansible/ansible/ https://github.com/ansible/ansible/ It doesn't require any deamon and does all its work over the good old unix fashion way: SSH. And it's python too.

ch0wn 13y ago
And if you don't like Python, you usually don't have to touch it. The tasks you run on the server can be any kind of executable. They read some JSON from stdin, do their action and write some JSON to stdout. Whether that program is a Python/Perl/Ruby/LUA script or go binary doesn't matter.
lobo_tuerto 13y ago
From the article: "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. Salt’s approach was far simpler." Does that assertion about Chef somehow don't apply to Ansible? On the use case: "I have this command I want to run across 1,000 servers. I want the command to run on all of those systems within a five second window. It failed on three of them, and I need to know which three."
- tomaac 13y ago
  Ansible can use SSH or ZeroMQ, which is much faster.
- dbarlett 13y ago
  Two solutions: pull-mode playbooks [1] and fireball mode [2] (temporary ØMQ daemon). [1] http://www.ansibleworks.com/docs/playbooks2.html#pull-mode-playbooks http://www.ansibleworks.com/docs/playbooks2.html#pull-mode-p... [2] http://www.ansibleworks.com/docs/playbooks2.html#fireball-mode http://www.ansibleworks.com/docs/playbooks2.html#fireball-mo...
- susi22 13y ago
  Well, ansible by default runs with paramiko which is a python implementation of SSH protocol. It will also keep connections open for multiple commands. It also has a pull mode and it also has a fireball mode which uses 0mq: http://jpmens.net/2012/10/01/dramatically-speeding-up-ansible-runs/ http://jpmens.net/2012/10/01/dramatically-speeding-up-ansibl... However, you're not forced to use this. In the beginning, you can just seed your CentOS or debian with a Kickstarter or seed file and then run your inital thing with ansible simply over ssh (using all the goodies, ssh-agent, password less ssh etc..). One huge plus for ansible is also that it used yaml which is rather simple. I've been following both project for >1 year and it seems that recently ansible has picked up a lot and will probably make the "race" (IMO).

moe 13y ago

Dead-end. Use ansible.

memset 13y ago

I think salt is neato, but I also find it very frustrating to use! (Possibly through no fault of salt itself - I feel like I must be missing something.) I am generally able to SSH into a box and get things configured the way I need. However, I have huge amounts of trouble translating that into salt scripts. Consider logrotate. Here is the only documentation I can find on the topic [1]. From this, I have no idea what to put in init.sls to make sure a given log file is being rotated correctly. It seems this would work on the cmdline, but not necessarily in a salt script. And that's just for logrotate! My uswgi + nginx configuration - translating that into salt - I don't know where to begin. How do I make sure things get installed in a certain order? (Answer seems to be having 10 directives, for 10 packages, each depending on another, to enforce order.) Is there anything that more closely mirrors what I actually do when configuring the box? SSH in, set certain values, etc? I guess I could write a shell script (or use fabric) but then I seem to have lost the point of configuration management. [1] http://docs.saltstack.com/ref/modules/all/salt.modules.logrotate.html http://docs.saltstack.com/ref/modules/all/salt.modules.logro...

Jedd 13y ago
Hey memset - these sound like pretty straightforward questions (with straightforward answers). Perhaps asking on the mailing list, or hop onto the #salt channel on freenode IRC?
- memset 13y ago
  That is a great suggestion. I almost never do this for fear of sounding like a noob, but I ought to try giving it a shot more often.
  - tech-dragon 13y ago
    As one of the people on that list who may well respond there, I'll reply here as well so its on the record. You will be very well off if you read and 'digest' the Salt docs on States first, before moving on to modules, pillars, grains, custom returners, etc. What you probably need to do with logrotate is take the configuration that you normaly setup on your servers, then add it to your salt system. So top.sls calls 'logrotate' running the 'logrotate/init.sls' and that has a definition that says "I want logrotate installed, I want it running as a service, and by the way take the file 'logrotate/config.conf' and shove it in /etc/logrotate.d/ as <correct filename>, p.s. If i change that file, restart logrotate" With States & the requisite declarations to enable salt to know what order things need to be in, you shouldnt have much trouble adding a simple service like logrotate along with a specific config file to use for that service.

tptacek 13y ago

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 having things hosted externally.

23david 13y ago
you care about network security, why are you exposing ssh ports in public anyhow? Put them behind a VPN. 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.
- calpaterson 13y ago
  > you care about network security, why are you exposing ssh ports in public anyhow? Put them behind a VPN. You don't need to do this. SSH is secure enough. Require key-based authentication and leave SSH on port 22.
  - hexedpackets 13y ago
    Switching SSH to any other port is a good idea as it will reduce the random attacks against it. Sure, those drive-by attacks are pretty weak and not much of a threat against a hardened configuration and the real attackers will find the new port anyway, but it reduces noise significantly. Cleaner logs are easier to parse, so the net result is that you can spot attacks that you care about much more easily.
    - nuclear_eclipse 13y ago
      Install fail2ban, leave ssh on port 22, and have clean logs.

cultureulterior 13y ago

Personally, I don't think puppet sucks

susi22 13y ago
The problem is most dev-ops and sysadmins don't know ruby and that's a HUGE disadvantage. In the end configuration management will often by done by sysadmins.
- pilif 13y ago
  I'm only managing 24 machines with puppet, so nothing fancy, but I managed to do all of the stuff I needed without writing a single line of Ruby code. That was handy for me too as while I'm somewhat familiar with Ruby, I'm no expert at all. I can read Ruby no problem and I can write ruby that's not-quite-idiomatic and I'm terribly slow at it.
  - susi22 13y ago
    I forgot to mention that just installing ruby is a HUGE PITA on anything but the most common OSes. It took me 3h last week to get it on a CentOS installed. And I don't even want to try to get it running on our Solaris hosts... Point is: Python is the number one scripting language (after bash) for sysadmins just like Perl used to be.
    - yxhuvud 13y ago
      yum install ruby took you 3h? It may take slightly longer if you want 1.9, but it still exists in fedora so it should not take 3h to solve.
      - awj 13y ago
        As a developer that primarily works on ruby, I can see it if he wanted 1.9.3. Most of the references you'll find on that tell you to use @environment_wrapper_of_the_month, and those are deep rabbit holes for people who know nothing about the language.

abtinf 13y ago

Yet another un-googlable project name. Pretty much kills it for me.

frankwiles 13y ago
Have you tried Googling salt stack? I've had zero problems finding tutorials and documentation.
a3n 13y ago
https://duckduckgo.com/?q=salt+configuration https://duckduckgo.com/?q=salt+configuration

Goladus 13y ago

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.

sciurus 13y ago
You can also run puppet without a master server.
- Goladus 13y ago
  Indeed. The reason I am currently using chef instead of puppet doesn't have much to do with relative technical merits.
crdoconnor 13y ago
http://docs.saltstack.com/topics/tutorials/quickstart.html http://docs.saltstack.com/topics/tutorials/quickstart.html
akoumjian 13y ago
You can run salt masterless. See the quickstart. http://docs.saltstack.com/topics/tutorials/quickstart.html http://docs.saltstack.com/topics/tutorials/quickstart.html
- Goladus 13y ago
  Thanks, it may even be that a salt master is lightweight worth configuring. But I should note there's a difference between "can run" and "intended to run." It's as much a semantic thing as a technical thing. Instead of thinking about an unconfigured node as a "minion" awaiting orders and provisions from central command, I prefer to think of a node like a stem cell, fully capable of differentiating itself based on signals that it receives. You need a way to update the DNA and a way to send the signals, that's it. This may seem like a meaningless difference, since there is still value in centralized services (package repositories, security, reporting, monitoring). But it's still a subtly different focus and over time yields different results. For my part I think the distributed, organic "stem cell" way of thinking will win out over "master/minion" in the long run.

UtahDave 13y ago

SaltStack also won at Gigaom Structure last week! http://gigaom.com/2013/06/20/devops-player-saltstack-wins-structure-launchpad-competition-and-investor-interest/ http://gigaom.com/2013/06/20/devops-player-saltstack-wins-st... (I'm a SaltStack employee)

jemeshsu 13y ago
Whole article about SaltStack winning the award, and not a link back to SaltStack website.

crb 13y ago

> MCollective (which Puppet Labs acquired several years ago) was (and remains!) fiendishly complex to set up. I didn't find MCollective hard at all - you just install some debs, a message queue server (Stomp was easiest at the time - it's now deprecated, but surely is not much different to RabbitMQ?) and it Just Worked for me. And there was a great screencast. Did it get far more complicated since I used it last?

druiid 13y ago
Well, rabbitmq is kind of a pain to get working with it. Additionally, the modules for rabbitmq and mcollective, for puppet, don't really work that well together (read: I had to re-write the ones I found to get them working).
- apenney 13y ago
  I'm starting work at Puppetlabs in exactly a week's time as part of a brand new "module team" and I personally promise you here and in the open that I am going to tackle the puppetlabs-rabbitmq module and fix it so that it actually works and isn't an abandoned wasteland. Come to that I'm hoping we can start building out a full set of mcollective modules to replace the existing ones that will be fully supported and kept up to date so that getting mcollective running will be as easy as including a class and waiting. A huge part of this job is ensuring community patches get merged in and contributors get treated as I would like to be treated when contributing to a project. I hope we can reverse your experience with modules within a few months (I took this job because I've been in exactly your position, grabbing official modules and having them not work at all!)
  - druiid 13y ago
    FYI we've spoken in the #puppet channel about just this issue ;).
daenney 13y ago
To be honest, I've never had an MCollective deployment Just Work(tm). It's always taken some serious debugging to figure out what the heck went wrong this time. RabbitMQ works but is slightly problematic since the authors have a morbid penchant for not wanting to support anything but Apache ActiveMQ. Ask a question about MCollective and RabbitMQ and the answer you get is 'switch to ActiveMQ'.

1gor 13y ago

https://github.com/seattlerb/rake-remote_task https://github.com/seattlerb/rake-remote_task is all you need if you use ruby. require 'rake/remote_task' set :domain, 'abc.example.com' remote_task :foo do run "ls" end

danudey 13y ago
State management is about a lot more than 'execute this command on a server' (which is discussed in the article). It's about creating a set of rules and performing idempotent actions. If you're just running shell commands, it's easy to screw up and waste your time or break your server by accidentally having the same commands run twice.

otterley 13y ago

When used with Chef Server 11 (or Hosted Chef), Chef scales reasonably well. You install a client on each node, and the client speaks to the server via HTTPS + REST. The unqualified assertion that Chef uses ssh is inaccurate. You can run chef-solo via ssh if you like, but you'll run into the same scalability ceiling as with any other ssh-based solution.

SandB0x 13y ago

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 Vagrant which does Y better than Chef, etc. I quickly lose patience and get back to digging myself into a deeper technical hole. Is there a non-recursive explanation of what these tools are able to do and where someone like me should start? Edit: Thanks for the helpful responses!

danudey 13y ago
These tools allow you to specify a state and then specify which servers should have that state. A 'state', loosely speaking, is a collection of definitions of 'X should be Y'. 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.

dmohjoryder 13y ago

What I prefer about ansible above all others, besides its simplicity, is that its use case scales up and out. By that I mean ansible can be used for platform/app stack provisioning while OS/infra sys admins maybe another tool. To often an agent based approach causes a conflict with OS sys admins and platform/app team regarding ownership/sharing. I want to offer self service as much as possible. Further, most cfg mgmt tools are monolithic in that they want to manage all servers as tho a single team/overload manages them all, rather than various independent sys admin teams. With various independent teams its just too much hassle trying to share roles appropriately or setup separate master/agents. Ansible does not have these issues.

terminalmage 13y ago
http://docs.saltstack.com/ref/clientacl.html http://docs.saltstack.com/ref/clientacl.html

kapilvt 13y ago

The thing that bugs me about salt is the almost complete lack of testing/coverage. They had tons of egg-face releases for crypto bugs, upgrade issues, things a basic test suite would have solved. I'd rather not trust my production environments to something that's a roll of the dice of whether its working, secure, or upgradable on a given release.

WickyNilliams 13y ago

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?

sciurus 13y ago
Puppet and Chef both support Windows. http://projects.puppetlabs.com/projects/1/wiki/Puppet_Windows http://projects.puppetlabs.com/projects/1/wiki/Puppet_Window... http://wiki.opscode.com/display/chef/Fast+Start+Guide+for+Windows http://wiki.opscode.com/display/chef/Fast+Start+Guide+for+Wi...
lmickh 13y ago
As mentioned, this can be done with Chef, Puppet, and Salt, but be careful about how you go about it. It is important to recognize when it is best to leverage AD for your Windows configs. It is easy to fall down the rabbit hole of trying to implement things in a CM tool/Powershell combo that could be done in AD far easier.
- drummer32 13y ago
  Genuine question: Why would you have Windows servers joined in an AD domain? Or are you talking about pushing changes to workstations?
  - AjithAntony 13y ago
    Because the services you provide depend on a domain for authentication and configuration like Exchange, Citrix, IIS, Sharepoint, SCCM, and every other Microsoft server product. I am dying for the chef/puppet/salt/ansible/cfengine recipe that will let me fully configure this stuff, including the domain memberships.
ipmb 13y ago
Salt can configure Windows machines, but you need to have the master running on *nix iirc.

gunmetal 13y ago

Salt is missing templates, the ability to use higher level programming language and all the environment/roles that I find the most powerful part of Chef.

Game_Ender 13y ago
You are wrong on all counts here. Salt supports Jinja2 template engine, so you can template your states [1]. You define custom states in python [2]. In the root configuration file (top.sls) you target configuration based on host name, grains (machine specific information) [3]. 1 - http://docs.saltstack.com/topics/tutorials/states_pt3.html http://docs.saltstack.com/topics/tutorials/states_pt3.html 2 - http://docs.saltstack.com/ref/states/writing.htm http://docs.saltstack.com/ref/states/writing.htm 3 - http://docs.saltstack.com/ref/states/top.html http://docs.saltstack.com/ref/states/top.html
pestaa 13y ago
That statement is very very wrong. Salt has templates, renderers, grains, while supporting all the data structure languages you can dream of. In fact, it is the most flexible software I've seen recently.
crdoconnor 13y ago
Salt has jinja2 templates.
terminalmage 13y ago
jinja2 and mako are supported, and you can even write your own renderer without much effort if a templating language is not supported. There's even a renderer for pure python, allowing one to write config files in python for more control and flexibility. One wonders if you've ever actually tried Salt. It really is OK to have an approach of: "I like Chef and it works for me." More power to you. Everyone should use the tool that works for them.

v0land 13y ago

I use SaltStack for managing a render farm consisting of 73 Ubuntu nodes. My requirements are rather simple, really: most states just install some packages, put configuration files into place (sometimes using a template) and enable/start services. However, I can't recall a single problem when setting everything up. SaltStack is clean, simple, and just works.

dmourati 13y ago

It seems most people miss the fact that any sufficiently large system is going to require both a pull-based and a push-based solution. So, take ansible. Primary use: push. But has ansible-pull. Look at puppet. Primary use: pull. But has mcollective. IMO, and I am not there yet but soon to be. The gold standard is to combine two strong players that specialize one each in push/pull. For me, it is looking like ansible/puppet.

deleted 13y ago

[deleted]

3am 13y ago
If someone can't get over the Ansible startup costs, then they have no business managing a system... I can't speak for Salt (last time I tried to use it was in 2010, and it was atrocious then and I haven't gone back).
- terminalmage 13y ago
  That would be an impressive feat, given that the first commit for the project was in February of 2011.
  - 3am 13y ago
    What a bonehead I am. This is what happens when you say to yourself, "that was about 2 years ago" and you base it on 2012. My only excuse is that I was working on a system config & management product and that I'm having a busy day... I upvoted you for correcting my record.

tegansnyder 13y ago

I use Salt to run commands across our EC2 environment to do things like restart Varnish, clear logs, and run updates. Paired with Unison for file synchronization it works well when your auto-scaling kicks in and you need your new AMI to be synched from staging.

mncolinlee 13y ago

We're actually a Windows-centric shop and have been actively evaluating configuration management solutions for Windows-based virtual machines. Initially, we were only looking at Puppet, Chef, and a commercial product called uProvision along with Vagrant. I was surprised to find that Salt had a real community behind it. Our greatest challenge has been coming up with a tool which can manage images for both VMWare and Microsoft Hyper-V. This article introduced a web integration between Salt and libvirt called Salt-virt. Has anyone tried this interface for managing images? Does it work better than the young integration between Vagrant and libvirt?

mncolinlee 13y ago
For anyone else looking, I just found Foreman. This seems to do exactly what we're looking for, but it uses Puppet instead of Salt. Even if it requires a Linux server, making our solution more complicated, it appears to meet our needs very nicely. http://theforeman.org/ http://theforeman.org/

dysinger 13y ago

Puppet is mature and has tons of cookbooks & community. You may not like it but saying it "sucks" is not right. It works and is used tons. Chef doesn't run over SSH in any environment I've used that wasn't a toy (vagrant w/ chef-solo). Please fact check. Fanboy article.

misiti3780 13y ago

I use fabric for everything just because I dont have time to learn another one of these technologies. This salt article seems great - but at the end of the day (and I may be way off base here) all I want to do is install a given version of a piece of software on my server. I dont want to create a receipt (chef), or learn another configuration format (sounds like I would need to do this with Salt stack), etc. My fabric file really seems to do only three things: use pip to install shit that is python (I use Django), use apt-get to install anything that is ubuntu specific, and make wget calls to various pieces of software, pull them down, and build them from source. Until there is an easy way for me to do this without needing to learn yet another technology, I will continue to use fabric (or, until the job of doing this gets so big I can hire a dev ops guy that actually already knows, but I am not there yet :) ). Sorry for the rant, it's just every time I see these articles I wish I had time to learn the technology but then I realize I don't. So - is it just me or is there seem to be a big/huge learning curve for all of these dev ops technologies?

gchpaco 13y ago
These technologies come into their own when you are managing large fleets of servers; but by the same right, you need to offer a lot of sophistication to make large fleets of heterogeneous servers work. When you have five servers these seem baroque and overly complicated, but when you have five thousand servers...
tech-dragon 13y ago
Yaml is a hair above "properly indenting my templates" as far as complexity goes. You write django templates, you can handle Yaml ;-) As current 'devops guy' on a django project myself, salt works wonderfully. Salt has states available that let you setup all that software, create the virtualenv you need (including telling it you want to use the requirements.txt that you pulled down with your django project source code - Salt gives me my own little Heroku :D ) and for anything left in those wgets you can throw a block of salt cmd.run calls using specified ordering to enable them to run neatly in the sequence you desire.

AaronBBrown 13y ago

This article makes a claim (...Puppet...Suck(s)), but does not take even attempt to explain what it is that sucks. What, specifically, "sucks" about Puppet and Chef and what is so much "simpler" about Salt or Ansible? As an Ops guy who has been running Puppet since 2008 (and Chef most recently) against hundred of servers, I don't see the simplicity reflected in the documentation, nor do I find Puppet or Chef particularly complicated. (Ok, Chef's attributes system is a bit confusing at first, but it is hugely powerful.)

fusiongyro 13y ago
From the article: > 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. Salt’s approach was far simpler. I think I'm with you (without the experience): I find "it works over ssh" a lot simpler than "we wrote a custom protocol on 0mq." Simplicity apparently has lots of interpretations. I couldn't care less if ssh performs well enough to support a trillion connections. In practice, you only need a handful, usually one. Maybe Salt is fantastic. I'm not really in a position to judge. The article made it sound interesting to me, but I'm not sure attacking Chef/Puppet was really necessary, especially since it wasn't really expounded on.
ecopoesis 13y ago
The main reasons I dislike Puppet: 1) It's slow. Puppet runs take forever and use a lot of resources. 2) The Puppet language is terrible. Basically it looks like someone took Ruby and hit it with the stupid stick. Trying to build reusable components nearly impossible without resorting to hackery. I have no idea is Salt/Ansible/Chef are any better, but I'd be willing to give any of them a try based on just these issues.

knowshan 13y ago

Both Salt and Ansible look interesting. It's much easier to define system state using Ansible or Salt than Puppet. However, I am not sure how would one use Ansible where VMs get launched dynamically (private cloud/virtualization fabric where devs can instantiate systems) and then receive their configuration without any manual steps. For example, one can create kickstart/VM-images which get a hostname based on certain regex pattern, register with a Puppet master, the Puppet master auto-signs certs matching this specific hostname pattern and then client nodes receive their catalog. This is really useful pattern wherein systems pull their configuration state almost immediately after boot. It requires manual setup only while writing kickstart/VM-iamge profile and Puppet master configuration. Ansible's SSH keys setup requires manual intervention, however, I think it can be automated using pre-defined keys in kickstart/VM-images. Haven't tried it yet though...

killing_time 13y ago
Yes, having predefined keys in your VM images does the trick, and is exactly what we do for (almost) zero-intervention deployments of our servers in my particular environment. We tend to destroy and recreate servers more often than we scale out, so we haven't bothered to remove the manual step of adding the server's hostname to the ansible inventory_hosts file. However, that's easily automatable... Ansible will _execute_ your inventory_hosts file if it's executable, and IIRC it just needs to return a JSON or YML data structure representing all your servers and the groups they're in. So, as long as you have a library which can query your infrastructure (e.g. boto for EC2 etc) it's not hard to automate this.

spudlyo 13y ago

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. It doesn't have to be this way. The situation where one host repeatedly needs to talk to hundreds via SSH is precisely where the SSH ControlMaster socket shines. This saves you a ton of overhead by not having to start up and tear down the session every time you want to issue a command via SSH. I often use this trick on busy Nagios servers that execute many active checks via SSH -- it works well.

knowshan 13y ago

Good to see tools that work as a system configuration framework and also allow command execution. [ControlTier](http://www.controltier.org/ http://www.controltier.org/) had (don't think it's actively developed now) options to execute general system commands, configure systems and application deployment. But it was fairly complex and required [ant](http://ant.apache.org/ http://ant.apache.org/) skills.

uggedal 13y ago

I used Puppet for a few years (and created a few modules for it https://github.com/puppetmodules https://github.com/puppetmodules). I switched to Salt a year ago. My main motivation were its simplicity (YAML+jinja), lower memory consumption, easier source code both to read and contribute to, and its support for both push and pull based architectures. If you want to get a feel for how salt looks like when managing some servers and laptops you can take a look at my states: https://github.com/uggedal/states https://github.com/uggedal/states

frio 13y ago

From skimming the top level of comments, it seems most people don't like these tools. Fair enough. That said, on-topic, I just wanted to say that having tried Puppet, Chef and Salt, I've found Salt the easiest to use. Straightforward installation (no messing with Ruby versions/rvm/etc.), really simple setup (systemctl start salt-master; systemctl start salt-minion; salt-keys -L; salt-keys -A yourbox; done), and the YAML-based configuration syntax has been a breeze to work with. Really quite pleased with it; it's made getting a few of my hairer boxes under control much easier than I expected (and much easier than I found with Chef or Puppet).

ishbits 13y ago

I've recently been thinking I need to learn Chef or Puppet. This thread has convinced me to pick up and try Ansible first.

tetsusoh 13y ago

emm, Private chef also use zeromq to implement the pub job feature. Puppet has MCollective (with ActiveMQ) to implement the similar feature.

WestCoastJustin 13y ago

I've thrown together a little puppet demo if anything is interested. Highlights what puppet is, and how it works. http://sysadmincasts.com/episodes/8-learning-puppet-with-vagrant http://sysadmincasts.com/episodes/8-learning-puppet-with-vag...