One big manifest?

[Peter Nijssen]

Hi,

I started to use vagrant with puphpet. Very nice. However, the gui of puphpet gives me too few options, so I want to configure everything myself.

So, I decided to write everything from scratch, using modules. Modules like apache, mysql, php, phpmyadmin which are in the puppet forge etc etc.

Now I need to configure those parts like which mods enabled for apache. Which vhost files. etc.

Everything is done in the main manifest file called site.pp. However, I was wondering, does it really has to become one gigantic file?

Isn't it somehow better to split up? I noticed I can split up using "import", but it's not really good practice apparently.

I guess it's neither a good practice to somehow write it down in the modules itself. 

Or isn't it really common to use existing modules and just write your own? If I look around at github for default boxes, I see a lot of people who all wrote the apache part on their own for example.

Or do I have to write my own module, which splits everything up in classes.

Basically what I want to achieve is that I seperate files where I can configure apache, php, mysql etc etc. Or to hear what actually is best practice. I am only going to use it for one OS, so it doesn't have to take a lot of OS'es into account.

Thanks!

Peter

[Christopher Wood]

Looks like you might want to start here:

http://docs.puppetlabs.com/puppet/latest/reference/modules_fundamentals.html

Also check up on how to do hiera lookups from within puppet3.

Other than that, structuring your modules tends to be a bit site-dependent.

On Fri, Dec 20, 2013 at 08:38:03AM -0800, Peter Nijssen wrote:
> Hi,

> I started to use vagrant with [1]puphpet. Very nice. However, the gui of

> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-users...@googlegroups.com.
> To view this discussion on the web visit
> [2]https://groups.google.com/d/msgid/puppet-users/9b216ae5-b811-46ce-a869-778d07d49717%40googlegroups.com.
> For more options, visit [3]https://groups.google.com/groups/opt_out.
>
> References
>
> Visible links
> 1. https://puphpet.com/
> 2. https://groups.google.com/d/msgid/puppet-users/9b216ae5-b811-46ce-a869-778d07d49717%40googlegroups.com
> 3. https://groups.google.com/groups/opt_out

[Peter Nijssen]

I read that document, however, it doesn't provide me the answer.

Should I write, in general, my own modules? Or should I use predefined modules?

And I if use predefined modules, should the configuration of those modules happen all in site.pp? (Which sounds me like a big file which is getting harder to read the more you need to configure). In the modules itself? Or do you have to write modules which will start those modules?

Op vrijdag 20 december 2013 19:04:33 UTC+1 schreef Christopher Wood:

[Johan De Wit]

This is just a question with so many answers.

have you tried the puppet enterprise quick start guide ?

It is a good way to learn the concepts and get you started quickly.

Get in touch with local puppet users.  Looks to me you are dutch speaking, so get in touch with the dutch or belgian puppet user group.  

https://puppetlabs.com/community/PUG for the list.

Just start writing a simple module, learn 'puppet apply' for test/execute your module.

grts

jo

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/5c62d2f8-812a-4975-9337-8e45bdcf211d%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

-- 
Johan De Wit

Open Source Consultant

Red Hat Certified Engineer         (805008667232363)
Puppet Certified Professional 2013 (PCP0000006)
_________________________________________________________
 
Open-Future                 Phone     +32 (0)2/255 70 70
Zavelstraat 72              Fax       +32 (0)2/255 70 71
3071 KORTENBERG             Mobile    +32 (0)474/42 40 73
BELGIUM                     http://www.open-future.be
_________________________________________________________
 

Upcoming Events:

Puppet Advanced Training | http://www.open-future.be/puppet-advanced-training-7-till-9th-january

Puppet Fundamentals Training | http://www.open-future.be/puppet-fundamentals-training-4-till-6th-february

Subscribe to our newsletter: http://eepurl.com/BUG8H

[Peter Nijssen]

Thanks for your answer.

I've only been a week now in the world of puppet. I started to use it, because I am charmed with the puppet + vagrant combination as a developer. Also, we currently are managing a growing number of servers by hand and I believe puppet can be a nice answer to keep everything consistent and up 2 date.

I've used the puphpet gui interface which works quiet nice. In the end, it offers me too less functionality and I want to stay more in control. So I started to explore puppet a bit more. I wrote my own basic modules, based on this box I found:

https://github.com/bryannielsen/Laravel4-Vagrant

I believe it's a nice example of how you can easily write your own modules.

However, I have also been using the default modules through puppet forge.  In the end, it makes it easier for you since almost everything can be done through it and is probably done in the best possible way. However, I noticed then that configuring those default modules happens in the general site.pp manifest, which can become quiet lenghty. That doesn't feel like a best practice either.

So, at one hand I could write my own custom modules which exactly do what I want and it is configured within those modules, or I could use the default modules from the puppet forge and do the whole configuration within the site.pp.

That's my currently my view, but maybe I am missing something or I should something different.

I'll see if I can dive further into some puppet books and guides :)

Op vrijdag 20 december 2013 23:09:47 UTC+1 schreef Johan De Wit:

[Jason Antman]

Peter,

I looked at puphpet a bit, and had it generate a sample config for me. The puppet manifests that it outputs are VERY far from anything that could be called "best practices". The 'all one .pp file' paradigm leads me to believe they're not even intended to be read or modified by a human, but just used withun the puphpet ecosystem.

The good news is that most of the modules that puphpet uses are widely used forge modules. They have many many more options and functionality than puphpet exposes.

My advice would be that if you've outgrown what puphpet does, you throw out the manifests that it generates (though you can certainly use the same forge/github modules that it uses) and write new manifests in whatever way makes sense to you. Or, use that one giant manifest as a starting point, and break it up into your own manifests and/or modules however makes the most sense (docs.puppetlabs.com has a gresat reference and some good tutorials.

You can probably even keep the rest of the output of puphpet if you need the vagrant configs, etc but just replace or heavily edit the puppet directory.

PS - if you're managing a "growing number of servers", you should probably look into either running an actual puppeg master, or at least keeping all your puppet stuff in version control (git seems to be the most popular in the puppet world by far).

Hope that helps,

jantman

Sent from my Verizon Wireless 4G LTE smartphone

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/8ef7626b-1bcd-49a6-b684-b5872bce44c6%40googlegroups.com.

[Chad Huneycutt]

Hi Peter,
Your instinct is correct. Just like many programming languages
that allow you to keep all of your code in one file (or one function,
even), it's not a good idea. As you mentioned, you can use import to
pull in other files, but the better solution is to use puppet's
autoloading functionality. The autoloader determines where to find
your classes based on the your modulepath and the the directory
structure in your module. So the answer to your question is that your
puppet code should mostly be in modules. There are a few approaches
to do that, but a lot of people have settled on a roles and profiles
pattern for describing nodes, with hiera being used for providing data
to the modules.

It's not really something I can describe in a single email, but there
is a lot of info in blog entries and documentation. I've linked some
starting points below. If you follow their links, you'll get a much
better understanding.

A full example:
https://ask.puppetlabs.com/question/1655/an-end-to-end-roleprofile-example-using-hiera/
Some thoughts on module design:
http://www.devco.net/archives/2012/12/13/simple-puppet-module-structure-redux.php

- Chad

> https://groups.google.com/d/msgid/puppet-users/5c62d2f8-812a-4975-9337-8e45bdcf211d%40googlegroups.com.
>
> For more options, visit https://groups.google.com/groups/opt_out.



--

Chad M. Huneycutt

[Peter Nijssen]

Hi,

Thanks for the respons. Very interesting. I used the modules from puppet forge, but that let me to one big manifest, configuring all those modules. That didn't look like best practice.

For now, I am not going to use puppet yet on our servers. I am trying to get out dev virtual machine up and running and learn puppet through that. I believe I already learned a lot, but what I noticed it, is that everyone is doing differently. All most all tutorials are about writing your own apache module, own mysql module etc. To me, it sounds more interesting to use existing modules. But that means I have to put the configuration, I guess, all in one big manifest. That was my biggest problem.

Greetings,

Peter

Op zaterdag 21 december 2013 14:33:39 UTC+1 schreef Jason Antman:

[Peter Nijssen]

Hi Chad,

Greet to hear that my instinct was correct. As noted in the docs of puppet, using import is not recommended. So that's why I didn't want to use that either. So basically my configuration should be in modules.

That was basically my biggest "problem".

Let's say I use a apache module from the puppet forge. So I include it in my module directories. Now I need to define which apache mods should be loaded, how the vhosts should look like, etc.

Till now, I did that in one big manifest called site.pp. For only apache, that is acceptable. But if you use like 10 modules, that manifests gets too big as you also noted.

Should I then create a module which is called like "apache settings" and in that module I configure everything? Or should I modify the original apache module? The latter sounds like best practice too, since it will hard to keep it up 2 date.

If I write my own apache module, then of course I can activate any mods or vhosts within the same module. Basically, the alinea above and this line were my biggest problem.

I am now going to check out the roles and profiles like you wrote down. Curious if this is going to answer all my questions.

Thanks!

- Peter

Op zaterdag 21 december 2013 14:51:23 UTC+1 schreef Chad Huneycutt: