|
So where should I be looking instead?
|
#
?
Nov 11, 2014 22:13
|
|
|
|
| # ? Apr 25, 2024 05:28 |
|
|
luminalflux posted:What's a good resource to learn modern puppet if I've spent the last 3 years in chef-land? Just out of curiosity, how come you want to move to puppet if you've been using chef?
|
|
#
?
Nov 11, 2014 22:14
|
|
|
swampcow posted:The link you provided is the old way of writing modules. The params section is obsoleted by hiera and automatic parameter lookups, for instance. Also, puppetlabs is now teaching that you shouldn't use inheritance. Admittedly, I just pulled the first bit on modules Google picked up on Puppetlabs' website, but... I haven't seen anything indicating that inheritance is out, except for not inheriting across modules, which is basic OO stuff that shouldn't even bear mentioning. I'm also curious if you have a link for params being obsoleted. I mentioned hiera because autoparams through hiera is best practice, but I haven't seen anything about params being obsoleted, especially since they're required for autoparams to work anyway. You still need them in your modules. If this is changing, I'd like to know.
|
|
#
?
Nov 11, 2014 22:14
|
|
|
evol262 posted:Admittedly, I just pulled the first bit on modules Google picked up on Puppetlabs' website, but... When I said params were being obsoleted, I meant the params subclass that seems to be used everywhere. Sorry about the ambiguity. As for class inheritance, when I took the puppetlabs class a few months ago, the instructor recommended against using them. I'm inclined to agree, since it's been easier in my experience to have a few well placed parameters, rather than several inherited classes while still having the need to specify parameters. Though I would be open to hear of a non-trivial example where inheritance is most appropriate.
|
|
#
?
Nov 11, 2014 22:44
|
|
|
Yeah, params are still used, so...?code:code:code:Anyway, standard module structure. Also I suggest this doc on the Role/Profile/Module method. Senso fucked around with this message at 22:58 on Nov 11, 2014 |
|
#
?
Nov 11, 2014 22:48
|
|
|
Senso posted:Yeah, params are still used, so...? If you're using hiera to fetch parameter values, you don't want to use this method of declaring classes. Because with the above method, you can only declare the class in one place. However, if you do 'include myclass', it can be declared in multiple places without ill effect while still getting the parameter values from hiera.
|
|
#
?
Nov 11, 2014 22:51
|
|
|
swampcow posted:When I said params were being obsoleted, I meant the params subclass that seems to be used everywhere. Sorry about the ambiguity. You really don't have to look any farther than apache to see where inheritance can be useful. Obviously it's not appropriate everywhere, but I don't think I'd recommend against using it entirely, since there are some patterns that it's just indispensable for. Especially if you're keeping hierarchical data for autoparams in JSON or etcd or somewhere else where it makes sense to have all the apache poo poo under the same tree instead of multiple base classes that all do apache stuff. Senso posted:Yeah, params are still used, so...? I suspect this is what he meant. This isn't good practice. You should just instantiate by importing and let hiera handle populating all the parameters. You still need them in your module so autoparams works, but don't do ^
|
|
#
?
Nov 11, 2014 22:54
|
|
|
Fair enough, it's true that "include module" allows using it more than once. I've never had to declare a module more than once anyway, because everything is in its own profile. The profiles I include them because they are re-used on different nodes.
|
|
#
?
Nov 11, 2014 23:02
|
|
|
fletcher posted:Just out of curiosity, how come you want to move to puppet if you've been using chef? I don't want to per se, but newjob uses puppet and I have 3 months until I start so might as well get proficient.
|
|
#
?
Nov 11, 2014 23:18
|
|
|
if I am starting from scratch, should I just say gently caress puppet and use something else? What is the something else? Chef?
|
|
#
?
Nov 18, 2014 05:37
|
|
|
adorai posted:if I am starting from scratch, should I just say gently caress puppet and use something else? What is the something else? Chef? Starting from scratch in 2014, use salt or ansible. Use puppet or chef if you're really into ruby (chef) or want to integrate with vendor kit (either). You can find out how to do almost anything with puppet or chef, though it may take a little while to figure out how to get some cookbook from 2011 to work. Ansible and salt rarely need you to go on the internet because they're somewhat saner, but aren't established enough for F5 and Netapp to officially support them yet (they may now, but those are just two companies I picked out of a hat). Powershell DCM also looks interesting. All config management systems have pros and cons, and places where they're weak or strong (tooling around them, windows support, scaling, community, ease of use, ease of extensibility), and it's really hard to just recommend one without knowing more about your use case
|
|
#
?
Nov 18, 2014 06:07
|
|
|
Ah, huh. Interesting. We were thinking about setting up puppet, just because we heard of it and we're starting to deploy more linux servers. Never heard of salt. So I guess we should be looking at that, instead?
|
|
#
?
Nov 18, 2014 06:17
|
|
|
SSH IT ZOMBIE posted:Ah, huh. Interesting. We were thinking about setting up puppet, just because we heard of it and we're starting to deploy more linux servers. Never heard of salt. So I guess we should be looking at that, instead? If you currently have config management, use whatever that is. If you don't currently have config management, have in-house python expertise (or can live with community stuff), and never want to use foreman or tie other infra into your config management system (or can wait until your vendor supports it), use salt. If you don't currently have cm and have in-house expertise in Ruby or want to reuse cookbooks written by vendors (rackspace and others), use chef. If you don't currently have cm and have engineers who can write addons in some language, use ansible. If you use Windows, look at powershell DCM. If it's cfengine, replace it with something else. If you don't currently have cm and want to tie in other infra or vendor tools (foreman, katello, whatever), or have an enormous base of community stuff in a DSL, use puppet. Puppet and chef (puppet a little more so) are most likely to let you add support for your appliances and other equipment without ever touching a language. Chef's basically pure ruby, which has its appeal, but chef and puppet are more similar than different. They're the established "enterprise" tools. Salt and ansible are newcomers. Ansible's schtick is flexibility. Any language you want, all you need is ssh. Salt is a little more "puppet in Python", but it's a few years newer, and doesn't have as much cruft yet. Nobody's going to debate what is isn't deprecated. Because it isn't new enough to have anything deprecated. They're all good choices. But you need to pick which one is right for you.
|
|
#
?
Nov 18, 2014 06:34
|
|
|
The only way to win the configuration management game is not to play. (They're great if you have to support piles of random apps, but if you're mostly supporting your own app's infrastructure, there's better ways to do almost all of it. Aim for immutable infrastructure everywhere you can.) Salt and Ansible lack many higher-level abstractions, so they're a good match if you tend to write one-off scripts for everything you run anyway. I've found them to be unmanageable when you start trying to wrangle heterogeneous infrastructures with lots of different apps and non-identical configurations. Your mileage may vary.
|
|
#
?
Nov 18, 2014 09:27
|
|
|
To add another dimension to the discussion, what cm comes with good orchestration? Puppet has MCollective, but it's not something you can just drop in. A puppetlabs employee said that it's not quite up to snuff yet. If I switched to another cm, I'd want orchestration plus all the advantages of hiera.
|
|
#
?
Nov 18, 2014 18:00
|
|
|
swampcow posted:To add another dimension to the discussion, what cm comes with good orchestration? Puppet has MCollective, but it's not something you can just drop in. A puppetlabs employee said that it's not quite up to snuff yet. If you have more money than sense you could use HP Server Automation and Operations Orchestration. They're separate products but they play reasonably nice with each other.
|
|
#
?
Nov 18, 2014 18:08
|
|
|
Salt actually started out as a tool for remote execution and orchestration and eventually grew to include Puppet-style config management. So it's a great option in that respect. Salt's version of hiera is called "Pillar" and works similarly.
|
|
#
?
Nov 18, 2014 18:31
|
|
|
Docjowles posted:Salt actually started out as a tool for remote execution and orchestration and eventually grew to include Puppet-style config management. So it's a great option in that respect. This is very good to know, thanks.
|
|
#
?
Nov 19, 2014 01:27
|
|
|
swampcow posted:To add another dimension to the discussion, what cm comes with good orchestration? Puppet has MCollective, but it's not something you can just drop in. A puppetlabs employee said that it's not quite up to snuff yet.
|
|
#
?
Nov 19, 2014 06:27
|
|
|
Since we're on the subject of mcollective: does anyone use/know of a client/agent that takes a script as input and executes it on the nodes? I see implemented_by in the docs but I don't think it's intended to be used that way. https://docs.puppetlabs.com/mcollective/simplerpc/agents.html#actions-in-external-scripts Or maybe I shouldn't bother with simplerpc.
|
|
#
?
Nov 19, 2014 08:35
|
|
|
|
| # ? Apr 25, 2024 05:28 |
|
|
Thanks to this thread, I started experimenting with ansible. Right now in my learning phase I am trying to lab up the automatic configuration of an HA wordpress blog, including 2x load balancers, 3x web servers, and 3x db servers. Anyone have any other suggestions for a neat lab to work on that will actually teach me something here?
|
|
#
?
Dec 5, 2014 04:56
|
|