Guys just have too much time...
Moving away from Puppet: SaltStack or Ansible?
91–100 of 182 posts
Re: Moving away from Puppet: SaltStack or Ansible?
#92Earlier quoted context omitted.
Open core also has its set of issues. For most open core products I've used over time the community starts creating alternatives to the proprietary products and the upstream slows its acceptance of open code. The upstream will also tend to spend most of its time working on proprietary features. Whether or not tower costs money, it's still a worry of being a single point of failure for autoscaling, which is part of wh…
We've never held back anything from Ansible, really. Rather, Tower is more of a product on top that provides some extra enterprise features that most of our user bases don't need (but they should try it, because they might!). I think if you see things like Windows being part of Ansible proper, it's clear we're not holding that back. But there are also tools the OSS community can't build easily, things that involve co…
But is commercial software dirty? Heck no. Ask any SaaS company :)
The pedantic in me feels compelled to point out that commercial SaaS doesn't have to mean closed; the company I work for is a good example, where our products and service are based on an third-party AGPL licensed software called Odoo[1] (and are therefore AGPL licensed themselves).
In any case, we do use Ansible here, and are happy with it :)
Re: Moving away from Puppet: SaltStack or Ansible?
#93Everybody seems to be taking about moving away from Puppet lately. Maybe I just don't do anything sufficiently complex with it, but I've never had any problems or gripes with Puppet. 99% of the time it seems like the thing I want to do has already been done in a well-written module on the forge.
The author seems to cite two main reasons for wanting to move away from Puppet: their codebase was large and badly structured, and their techops team didn't know Puppet well enough to manage it. Neither of these sound like problems with Puppet itself -- they're certainly not unique to Puppet. I'm not convinced that moving to a newer, less mature technology (which I assume techops don't know well either) will solve these problems.
Re: Moving away from Puppet: SaltStack or Ansible?
#94As someone who used Puppet for some years, went to Salt[1], then Ansible[2], I've setteled on POSIX sh[3], 1: http://git.uggedal.com/historic/states/ 2: http://git.uggedal.com/historic/playbooks/ 3: http://git.uggedal.com/conf
502? Oh the irony.
Re: Moving away from Puppet: SaltStack or Ansible?
#95Does anyone have experience using Configuration Management software in a heterogeneous environment? For example, I've seen large environments running Windows 2008/2008R2/2012/2012R2, various flavors and versions of Linux including Ubuntu Server, CentOS, SUSE, etc... What's the pretty? What's the ugly? I understand consolidation and standardization of operating systems is usually the best state to be in, but in a lot…
I work for a cloud service provider, and we use Chef in a heterogeneous environment. Several flavors of Linux, and Windows 2003-2012 (both 32 and 64 bit). The pretty is that Chef supports Windows very well, and the mature community cookbooks have good support for Windows as well. The ugly is that it makes testing more complex, but things like ChefSpec and ServerSpec + TestKitchen and Jenkins make it possible to relea…
ChefSpec and Test-Kitchen are really awesome. I tend to see Chef as a framework for automating infrastructure, not as a scripting language/environment to define resources.
Chef pays off in large scale infra or highly dynamic environments but chef-solo is still a bit lame (I juse knife-solo for that[1]). So most people seem to start with no-devops, shellscripts, puppet/ansible… later they will understand why there are more complex/flexible solutions out there.
It also depends on the background of the DevOps people: Coming from software engineering, you're probably familar with concepts like DRY, YAGNI and principles of clean and robust code. However when your team consists of people with admin-background, they have probably no experience and will write very bad code especially in less strict scripting languages. They are probably happier and more productive with strict configuration files (e.g. YAML) but in the end, they need to start programming…
Re: Moving away from Puppet: SaltStack or Ansible?
#96Having deployed salt to a medium sized cluster ~1500 farm machines, and around 1500 desktops, the one thing that salt won't do is scale.
Salt has a lovely system where clients attach themselves to a zeromq and listen for commands. However after about 500 clients it starts to fail silently and not all clients update properly.
The way we get round it is to run salt-call on the client at specific intervals. The other annoyance is that is horribly slow (60 seconds plus to run 100 ops (excluding yum operations))
having said that, the YAML syntax with optional python extensions is grand. Whether its quite ready for mainstream adoption is another matter. It sort of works for us.
Re: Moving away from Puppet: SaltStack or Ansible?
#97May I ask why people think Puppet sucks?
Crazy slow, linguistically poor, parser breaks in every release, really hard to test locally.
> parser breaks in every release
This isn't true as of more recent releases (since around ~3.0), they appear to have finally gotten their act together.
> really hard to test locally
Tools like Beaker are finally the norm, so I've high hopes for this improving over the coming year.
But yes, crazy slow alone destroys everything. Typical "fixes" include going masterless, yet there's no standardised distribution methods so you need to invent that yourself. Embedding all files into catalogs, thus turning network overhead into CPU overhead etc.
Not to mention in the insane memory usage client side, i.e. on every single box.
Re: Moving away from Puppet: SaltStack or Ansible?
#98I look for two things when considering configuration tools.
1. How does it handle cross-cutting concerns?
2. How does it handle complex configuration files?
For the cross-cutting concerns I use the firewall as an example. I look to see how multiple projects and modules (that are going to be installed on a machine) can declare their firewall rules.
I'm a Puppet user presently, but a quick look says that Ansible has great firewall support ( http://docs.ansible.com/ufw_module.html ) in a nice tight format, and SaltStack has iptables support in a more verbose format: http://docs.saltstack.com/en/latest/ref/states/all/salt.stat...
On the complex configuration files, I usually consider Nginx and how to define multiple SSL certificates, SSL ciphers, load balancer backends, multiple web sites, and rules for locations on those websites.
On Nginx... perhaps I'm lost in the docs but beyond simple installation I don't see either attempting to handle the config files. Is it the case that one should deploy their own config or write something to define the config from templates? I must be wrong on that, but lack of clear and deep documentation on how to configure Nginx would mean I touch neither and stay with Puppet.
Re: Moving away from Puppet: SaltStack or Ansible?
#99> No masters. For Ansible this meant using ansible-playbook locally, and for Salt this meant using salt-call locally. Using a master for configuration management adds an unnecessary point of failure and sacrifices performance. There are two models for delivering state to your infrastructure nodes. Pulling and Pushing configuration. Ansible Pushes code from the controller to your nodes, while salt, puppet and chef all…
But Ansible doesn't have masters! It has a machine where you run Ansible. But that can be any machine, as long as it has Ansible installed, the Ansible code checked out, and an authorised SSH key. If your usual machine goes down, just check out the code and run from a different machine. The idea that you need to use local playbooks to use Ansible masterlessly just seems mistaken to me. Moreover, any scheme which invo…
I haven't mentioned an Ansible Master? I referred to the user running ansible as the controller.
Running local configuration and checking out local state can indeed be very different from having a master. Like I said, master features often include features such as search and service discovery. Checking out state from version control does not have those features therefore the user implements those features on his own with stateless cookbooks/pillars/modules/whatever. The remote checkout is not a SPOF and a master is.
You are right in regard to the open ports, it is uncommon, though I have seen it with workstations. I edited the post!
Re: Moving away from Puppet: SaltStack or Ansible?
#100Earlier quoted context omitted.
Yep. I understand that, but part of having an open source project is that others may find open bugs and decide to fix them because they're also having the same issue. Closing legitimate bugs hides them from the world and also gives people the impression that it's not something to fix. The performance issue was very likely one of the more major deciding factors. Managing users was so slow that it was painful to do sma…
I think it's something that can be improved, yes. I'm not sure it's a bug, and I'm not sure it's really all that slow. We're talking about 0.5 seconds and maybe it could get down to 0.4? If you dig into the module I'm not sure what you would change. (Again, a fine discussion for ansible-devel probably? How would you solve it?) In your case, managing a list of 80 users to be sure there or not, I might have suggested p…
Ansible seems like a cool project... thanks for stopping by here.
One question, though. 0.4 seconds seems like a very long time to query one user/group, though. You should be able to query thousans of UIDs a second, minimum... unless you're using LDAP and you have a slow network or something. You could write a simple C program to query a bunch of UIDs and I bet it wouldn't even take a millisecond to run. So where is the overhead here for ansible? I apologize if this is a dumb question... I am not very familiar with the architecture.