I'd really recommend that second edition for Pro Puppet for you if you are
starting and want to learn to Puppet the right way. If I remember right
doing Apache vhosts is an example they use in the book even.
The problem is that there are certain types of tasks that it's going to be
able to do with
My rationale for it is exactly that. Focus on learning how Puppet itself
works, and then learn the add-ons after the fact. On top of that, Hiera
isn't a requirement for use - you can just as easily use something like
Foreman (which, from what I've seen of it so far looks really good.) But
even in m
Yeah I think part of the difficulty is that there are multiple ways to do
things and not everyone agrees on what is the best way. There are some
groups that have put their entire Puppet code base on GitHub. I bet you
could find some by Googling or searching on GitHub. That's one of the nice
things
On 6/23/2014 4:05 AM, Ben Ruset wrote:
Ah, okay this makes more sense for me. So I know that I can stick this
in the same file with the node definitions, but there's got to be a
better place for it to go. Where would the "proper" place be for it to go?
Many thanks for your responses. They've bee
I think the good form these days is to create generic modules and keep the
site-specific data in hiera (not that I'm good at keeping up with fashion).
Once you've gone through the Learning Puppet series of docs you'll probably
have more context to the roles/profiles pattern and other links.
htt
Well, so I didn't know if it was "good form" to modify modules to hold
site-specific configuration items.
I think part of my frustration is that I haven't been able to find a doc,
or maybe one doesn't exist, that shows what a decent "production" Puppet
environment might look like. I think it'd be
Perhaps read about modules? if you specify a class name (apache,
apache::vhosts) that class is automatically loaded from the relevant module.
Just like putting stuff directly in node definitions has correctly gone out of
style, so has defining classes/defines outside of modules.
http://docs.pup
Ah, okay this makes more sense for me. So I know that I can stick this in
the same file with the node definitions, but there's got to be a better
place for it to go. Where would the "proper" place be for it to go?
Many thanks for your responses. They've been very helpful.
On Sun, Jun 22, 2014 at
Before hiera you might have a define specifying what a vhost is, and then have
a class with the defines all listed. You would include that class in your node
definition, ensuring that this class was applied after the basic apache class.
Sometimes people would put the defines right in the node, b
Thanks for the answer. I grasp the fundamentals of what you're saying, but
right now I'm a little leery of delving into Hiera when I don't really know
the fundamentals of Puppet itself yet. My reading through those docs would
only confuse me more. (Not that those docs are probably not good - it'
Short version: read up on hiera, data bindings, and create_resources.
Details:
It sounds like you might want to look into hiera (baked into puppet 3 and
higher) and the create_resources function. Specifically that you list the
variable portions of things in your puppet configuration in hiera, a
Alright, this is definitely a Puppet 101 question, and I am sure that the
Puppet docs have an answer for this and I am just dense and can't find it.
I'm trying to teach myself Puppet, with the goal of managing the VPS I run
with it. Additionally, when I get a better grasp on things, I want to
12 matches
Mail list logo