Salt: Like Puppet, Except It Doesn’t Suck • Hacker News Board

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

#261

Post by contingencies » Tue, Jun 25, 2013, 3:21 PM UTC

regularfry wrote: post #252

_bpo wrote: post #196

Earlier quoted context omitted.

"Immutable Server" seems like an oxymoron. Frequent refreshes are great, but your system is only doing something useful once it has "mutated" (i.e. accepted external data to operate on). The tradeoff system designers have to make is frequency of refreshes vs the cost of transferring interesting data to that server. Seems like your organization has just coined a new synonym for "gold master"

You can do it the other way round: have your data on direct-attached storage and network mount the root filesystem.

We do well with DRBD as an alternative here .. adequate network redundancy without performance penalties.

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

#262

Post by contingencies » Tue, Jun 25, 2013, 3:24 PM UTC

regularfry wrote: post #255

contingencies wrote: post #224

Earlier quoted context omitted.

Computer systems in the wild are stochastic Try telling a client who wants 100% uptime that! Computer systems can be many things - it could be (and probably has been) argued that we as progammers fundementally aim to reduce random qualities and increase stability within our programs. there are well-reasoned (and researched) assumptions behind these tools I can see where PFCT's came from. I took a look at the paper (w…

>> Computer systems in the wild are stochastic > Try telling a client who wants 100% uptime that! A client who asks for 100% uptime will end up disappointed. > We attempt to remove an entire class of issues related to deployment environment by changing our platform engagement paradigm to one that is less procedural/'stochastic' to something that is more atomic/reliable. I'm afraid I don't get the difference. You've a…

A client who asks for 100% uptime will end up disappointed.

Sure.

[...] I don't think there's a fundamental advantage to full-system deployment that can't be matched by a thought-out application of conventional configuration management.

OK, on the face of it, this is a fair line of reasoning. If we assume, however, that we are looking for ... replication (say, for the purposes of regression testing, etc.) then we really do need to know that the entity in question is the same as the last time it was .. err .. generated/instantiated. With the process you propose, there is clearly higher risk here. That is a paradigm weakness.

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

#263

Post by contingencies » Tue, Jun 25, 2013, 3:26 PM UTC

regularfry wrote: post #253

contingencies wrote: post #222

Earlier quoted context omitted.

PXE boot is a great way to automatically re-provision physical servers.

If one of your complaints about configuration management systems was that they're slow, this is not the answer.

PXE is fast. I'm not sure what your experiences are, but I'd like to hear them. I've never had an issue with speed.

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

#264

Post by WestCoastJustin » Tue, Jun 25, 2013, 5:10 PM UTC

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-vag...

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

#265

Post by mncolinlee » Tue, Jun 25, 2013, 6:34 PM UTC

mncolinlee wrote: post #144

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 M…

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/

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

#266

Post by tech-dragon » Wed, Jun 26, 2013, 7:46 AM UTC

memset wrote: post #43

Jedd wrote: post #37

Earlier quoted context omitted.

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?

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.

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 , 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.

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

#267

Post by tech-dragon » Wed, Jun 26, 2013, 7:56 AM UTC

misiti3780 wrote: post #153

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 fabri…

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.

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

#268

Post by regularfry » Wed, Jun 26, 2013, 12:25 PM UTC

contingencies wrote: post #263

regularfry wrote: post #253

Earlier quoted context omitted.

If one of your complaints about configuration management systems was that they're slow, this is not the answer.

PXE is fast . I'm not sure what your experiences are, but I'd like to hear them. I've never had an issue with speed.

I may have jumped the gun. I was assuming PXE to boot an imaging environment, which copies the system image to local media so you don't have a runtime dependency on the boot infrastructure. In that case, speed-wise, you've not gained anything because you've got two boot cycles and a system copy before your new server is ready.

If you're not copying the system image and simply network booting a remote image, then that doesn't apply, and yes, that can be fast.

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

#269

Post by snowwrestler » Wed, Jun 26, 2013, 2:52 PM UTC

darkarmani wrote: post #127

23david wrote: post #88

Earlier quoted context omitted.

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.

> 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.

Yes, there is. If you get into my VPN, all you get is another connection to the public Internet. If you get into my SSH you have my server. VPN adds another layer to the onion.

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

#270

Post by regularfry » Wed, Jun 26, 2013, 5:01 PM UTC

contingencies wrote: post #261

regularfry wrote: post #252

Earlier quoted context omitted.

You can do it the other way round: have your data on direct-attached storage and network mount the root filesystem.

We do well with DRBD as an alternative here .. adequate network redundancy without performance penalties.

"Adequate" is an interesting word :-) We don't consider DRBD in anything other than synchronous replication mode to be reliable, which puts a fair performance penalty on it.