Ask Your Question

Advantage of puppet package resource over it's equivalent module

asked 2014-06-09 14:21:18 -0500

droidlabour gravatar image

Looking for the very first time on package (Puppet resource) and it's equivalent Puppet module, it doesn't seem meaningful to write/use modules even for simple packages like wget, unzip, git. What's the advantage of writing modules over installing it via package resource apart from code readability?

edit retag flag offensive close merge delete

2 answers

Sort by ยป oldest newest most voted

answered 2014-06-09 18:36:10 -0500

nibalizer gravatar image

For simply installing a list of packages, the package resource is the right tool for the job. Many organizations will have a 'generic' or 'base' class that gets applied to all nodes and contains a big list of packages to throw on the system. You can make this list more intelligent by filtering on facts to set package names for different operating systems. You can make the list, which is essentially data, more manageable by putting it into hiera.

A module/class has its uses too. Usually when there is a service to be configured. The 'git' package doesn't require any configuration and so should be installed in the big list 'o packages above. But the rsyslog package does require configuration. You want a module containing a class to manage installation of the package, settings in the config file, and starting/enabling the service. You want that class because then you can enable that behaviour on any node with a short, concise, and meaningful stanza.

edit flag offensive delete link more

answered 2014-06-10 00:57:49 -0500

Ancillas gravatar image

The package resource simply ensures that a package is installed. It abstracts the package managers so that you don't need to know if you're using yum or apt, for example.

A module is a way to group a bunch of resources together that are more complex than a single package. Think about how you would deploy a tomcat web application, and configure it. You might have a module that takes a few parameters. In the test environment, you might pass in the connection string of a test database. Your module would then place the correct war file in the appropriate tomcat path, then create a config file with the database connection string, and then restart tomcat. This flow requires multiple resources, and allows the same code to be re-used at all stages of the deployment lifecycle. A production server would use the exact same module, but with a production database connection string.

Once you get modules down, then you can start applying different modules together on nodes. Continuing the example, a webserver node would probably have the following modules applied: java, tomcat, yourwebapp. The modules are best kept separate so that you can re-use them. For example, if you wanted to build a cassandra node, you might use the java module, and a cassandra module. There's no need to re-write the java code because it already exists.

edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower


Asked: 2014-06-09 14:21:18 -0500

Seen: 432 times

Last updated: Jun 10 '14