Hi Faifel,
this is the way I like to organize my modues:
modules/$environment/$type
where $environment usually is one of dev qa stg and prd
and type is one of base common and roles.
So in a typical configuration it would be something like:
modules/dev/common
modules/dev/base
modules/dev/roles
modules/qa/common
modules/qa/base
modules/qa/roles
modules/stg/common
modules/stg/base
modules/stg/roles
Now
base contain base modules that configure your OS. ie:
companyname_ldap
companyname_ntp
companyname_network
companyname_mail
and usually you have something like:
companyname_base
that will include all the rest of the modules.
Common will contain all the external modules
apache
postfix
ldap
Roles will contain application modules
companyname_role_frontend
companyname_role_webapp
companyname_role_dbserver
Now. here is the important bit:
Each module is a git repo with one or more remotes. If it is a base or a
role module, then the remote will be a private repo. If it is a common
module then it will have 2 remotes, a private one and the mantainer repo.
All modules are tagged. Tags can be different among environments but you
should always push forward incremental tags, never backwards. IE:
GOOD:
dev/common/apache -> tag 1.4
qa/common/apache -> tag 1.2
stg/common/apache -> tag 1.1
prd/common/apache -> tag 1.1
WRONG:
dev/common/apache -> tag 1.0
qa/common/apache -> tag 1.3
stg/common/apache -> tag 1.3
prd/common/apache -> tag 1.1
That is a little bit of common sense. You should never push higher tags in
more critical environments if they never were tested in the testing
environments.
Finally with common modules it works something like this:
1- clone the module and create tag 1.0
2- New release by the developer, pull the changes from the remote and
create a new tag 1.1
3- push the new tag in dev environment and test it against that.
4- If all is good, promote the tag to the rest of the environments.
Hope it make sense, bug if you have any question just let me know
Cheers
Juan
On Wednesday, August 7, 2013 3:18:02 AM UTC+1, Feifei Jia wrote:
>
> Thanks for the reply, Brian.
>
> I have looked into librarian-puppet, a good tool, just like ruby bundler.
> Will give it a try.
>
> And I'm also interested in your alternative way to organise your module.
> Could you explain more on that? What the modules directory structure look
> like? Just like the following?
>
> /etc/puppet/modules/{library_modules, your_module_a, your_module_z}
>
>
> On Tuesday, August 6, 2013 5:52:12 PM UTC+8, blalor wrote:
>>
>> On Aug 6, 2013, at 5:27 AM, Feifei Jia <feif...@gmail.com> wrote:
>>
>> This is very inconvenient, obviously. So how do you guys manage
>> third-party modules, except using git submodule? Thanks.
>>
>>
>> I use librarian-puppet https://github.com/rodjek/librarian-puppet for
>> one of my projects. It's basically a dependency management system for
>> Puppet modules, a la Maven, Ruby gems, etc. The problem is that I find its
>> resolution of versions quite unreliable, for example grabbing apache 0.8.1
>> when 0.6.x is specified. The author is working on a replacement called
>> Henson https://github.com/wfarr/henson.
>>
>> Librarian-puppet has some (undocumented) functionality that looks like
>> it'll allow you to cache your dependencies and work from those, so I'm
>> considering looking into that and committing the cardinal version control
>> sin of checking in 3rd-party dependencies. For right now, tho, despite my
>> concerns with it, I find it a huge improvement over submodules or managing
>> others modules in my source.
>>
>> An alternative may be to separate out your own modules from 3rd-party
>> modules. As it is, I put librarian-puppet-managed modules into a
>> "library_modules" folder and ones developed just for a given project into
>> "modules". That will give you some separation of code and at least make it
>> easier to manage updates.
>>
>> --
>> Brian Lalor
>> bla...@bravo5.org
>> http://github.com/blalor
>>
>>
--
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+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.
