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, > > 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 > > > > -------- Original message -------- > From: Peter Nijssen <[email protected] <javascript:>> > Date: 2013/12/21 08:00 (GMT-05:00) > To: [email protected] <javascript:> > Subject: Re: [Puppet Users] One big manifest? > > > 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: >> >> 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 >> >> >> >> >> >> >> >> >> >> >> >> >> On 12/20/2013 07:15 PM, Peter Nijssen wrote: >> >> 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: >>> >>> 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 >>> > 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 >>> > >>> > -- >>> > 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 [email protected]. >>> > 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 >>> >> -- >> 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 [email protected]. >> 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 >> >> -- > 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 [email protected] <javascript:>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/puppet-users/8ef7626b-1bcd-49a6-b684-b5872bce44c6%40googlegroups.com > . > For more options, visit https://groups.google.com/groups/opt_out. > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/b94ce843-13ae-4d8c-bb88-82af15fcfb96%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
