Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Salt: Like Puppet, Except It Doesn’t Suck

blog.smartbear.com

Post reply on HN
Print view View original

231–240 of 274 posts

Re: Salt: Like Puppet, Except It Doesn’t Suck

#231

Post by sciurus »

jdboyd wrote: post #41
susi22 wrote: post #12

IMO, ansible is even better: 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.

While I would prefer ansible as well, the author does show why ansible is problematic for some people: > Chef works atop ssh, which – while the gold standard for cryptographically secure systems management – is computationally expensive to the point where most master servers fall over under the weight of 700-1500 clients That said, unless you must have 700+ simultaneous slave connections, you should probably make lif…

FWIW, Chef doesn;t work atop ssh. It and puppet both use HTTP.

Re: Salt: Like Puppet, Except It Doesn’t Suck

#233

Post by stfp »

Shish2k wrote: post #148
fmstephe wrote: post #110

Earlier quoted context omitted.

Ok, the declarative and idempotency sounds great. But consider this one use case. I want to stop a service, upgrade it to a new version, restart that service. The service is an application which I wrote that runs in apache tomcat. 1: Stop Service 2: Upgrade 3: Start Service Right now I have just made three non-declarative statements about my tomcat server. I am describing a process that runs through a series of steps…

> I want to stop a service You WANT to stop the service? Really? Stopping the service is an actual headline-level goal, and not a behind-the-scenes detail? Personally I tell puppet "make sure that the latest version of X is running", because that's what I actually want, and I don't care how it does it...

Maybe you want to tell the load balancer before stopping a service, and actually wait for it to drain before going ahead. Or you want to disable alerts for services while they're being restarted.

Maybe puppet has hooks to integrate with the rest of your setup, I don't know - either way, caring about how things are restarted isn't that crazy imo.

Re: Salt: Like Puppet, Except It Doesn’t Suck

#234

Post by AjithAntony »

drummer32 wrote: post #130
lmickh wrote: post #105

Earlier quoted context omitted.

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.

Genuine question: Why would you have Windows servers joined in an AD domain? Or are you talking about pushing changes to workstations?

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.

Re: Salt: Like Puppet, Except It Doesn’t Suck

#235

Post by pilif »

antihero wrote: post #211
nuclear_eclipse wrote: post #203

Earlier quoted context omitted.

Install fail2ban, leave ssh on port 22, and have clean logs.

If someone knows your IP, can't they spoof the packets and get you banned from your own server? Or did they solve this issue somehow already?

The ssh authentication works over TCP which isn't realistically spoofable because to open a connection (which you need first, before you can fail to authenticate ssh), you need to be able to receive the response packets to your spoofed sender address

Re: Salt: Like Puppet, Except It Doesn’t Suck

#236

Post by killing_time »

knowshan wrote: post #172

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…

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.

Re: Salt: Like Puppet, Except It Doesn’t Suck

#237

Post by gizzlon »

peterwwillis wrote: post #138
darkarmani wrote: post #127

Earlier quoted context omitted.

> you care about network security, why are you exposing ssh ports in public anyhow? Put them behind a VPN. Why are you exposing VPN ports in public anyhow? Put them behind a VPN. Seriously though, there isn't anything to say a VPN is any more secure than SSH.

SSH is secure. The configuration of SSH, and the system that it's running on, its operating system, accounts and applications, might not be. It all comes down to how secure you want to be. There is a longer conversation that can be had to explain this. There are lots of mistakes one can make in managing a box with SSH that will easily lead to an account compromise, not even considering universal methods like 0-days,…

This just sounds like FUD. What makes whatever vpn software or "hardware" you're using better, or harder to mismanage, than OpenSSH.

Something concrete please..

Re: Salt: Like Puppet, Except It Doesn’t Suck

#238

Post by tech-dragon »

contingencies wrote: post #221
chongli wrote: post #159

Earlier quoted context omitted.

Perhaps what we want is a build system (a la make) that builds your software and constructs a virtual machine image for it, including the performing of all your tests within the running virtual machine.

You're thinking along the right path. But you can't fully control the environment on all third party hosts/cloud providers, so how do you ensure that the code works on all target infrastructure? There needs to be a unifying abstraction to tie them together, something static enough to maintain a fixed target for service authors.

I would hazard that for a given set of axes in the multivarial formula we will call "control" for short. You definitely can be fully in control. The question is "does what I'm doing fit within the bounding space I can exert full control over.

Salt as an 'ecosystem' has capabilities that extend more into this area. Salt Cloud and the Salt Bootstrap script are 2 of the things that I feel invalidate some of the argument that tools like Salt ( I wont comment on the Chef & Puppet ecosystems ) are capable of operating much closer to your aim than you give them credit for.

For starters, I'd quit before letting a boss tell me their precious snowflake AMI was 'more stable' and I shouldnt waste any time trying to ensure I can recreate it should someone delete the image. In my own workflow, Salt is step 1 in any system. I build a stand alone salt configuration that can from bare OS image on first boot, initialize salt, and then pull the system forward to the desired state. Then for cloud roll out, the next step is to take an image of that VM/Container which I can then replicate much faster.

And one of my long terms plans is to hammer Buildbot, Salt, Salt Cloud, and a lot of time into a system that gives end to end control. Now if only I could code a decent UI for it... putting bootstrap on months of work would feel cheap lol.

Re: Salt: Like Puppet, Except It Doesn’t Suck

#239

Post by lotsofcows »

danudey wrote: post #132
susi22 wrote: post #33

Earlier quoted context omitted.

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.

> It took me 3h last week to get it on a CentOS installed This matches my experience with a significant amount of software on CentOS. Since CentOS is just a rebuild of RHEL, and RHEL is extremely conservative when it comes to new software, CentOS tends to be out of date at release and get progressively worse.

"out of date"? I think you mean, "stable".

That being said, we use third party repos for big projects like mysql and php on the assumption that a project that size is going to be thoroughly tested.

Re: Salt: Like Puppet, Except It Doesn’t Suck

#240

Post by rahoulb »

stfp wrote: post #233
Shish2k wrote: post #148

Earlier quoted context omitted.

> I want to stop a service You WANT to stop the service? Really? Stopping the service is an actual headline-level goal, and not a behind-the-scenes detail? Personally I tell puppet "make sure that the latest version of X is running", because that's what I actually want, and I don't care how it does it...

Maybe you want to tell the load balancer before stopping a service, and actually wait for it to drain before going ahead. Or you want to disable alerts for services while they're being restarted. Maybe puppet has hooks to integrate with the rest of your setup, I don't know - either way, caring about how things are restarted isn't that crazy imo.

Your ultimate goal is to ensure that the service is at the latest version.

There are numerous dependencies to that task - one of which may be stopping the service before upgrading. There are dependencies to stopping the service - maybe telling the load-balancers or your monitoring system. When the service has been upgraded, you can trigger notifications that other items within your config can depend upon (for example, when an upgrade is complete, restart the service, when the service restarts, add it back to the monitoring system etc).

All of these can be modelled in these config-management tools, as explicit dependencies within your manifest file - as opposed to implicit and ad-hoc dependencies within your script.

Post reply on HN