On Nov 1, 3:30 am, Daenney <daniele.sluijt...@gmail.com> wrote:
> Hi guys,
>
> For a project I'm working on for my studies we need to create a demo setup
> of a small enterprise environment. The linux-part of this is now managed by
> puppet. However, I'm running into something I can't exactly figure to how
> to fix. I've read the docs a few times but I can't find a clear indication
> on how to solve this and what would be the recommended way, Google left me
> out in the cold too.
>
> What I basically need is flow control for my installation. In the current
> state I want to create an nginx-module that handles a few things. My main
> issue is that I want this parameterized.
And that's your first mistake. Functionally, class parameterization
gains you nothing that you cannot achieve in other ways, but it costs
you flexibility.
As you are a student, I suppose you have some programming background.
That's ok, you can probably learn Puppet anyway.
Seriously, there is a mental adjustment to make when shifting from a
procedural programming language to a declarative language such as
Puppet DSL. To use Puppet effectively you need to get over that
hump. Among other things, wipe the word "call" and its synonyms out
of your Puppet vocabulary. They will only lead you astray.
> Depending on a parameter fed to
> that module I want to change the packages installed and additional classes
> being called upon.
>
> I'd like to be able to do something like this:
> nginx(type=default), install nginx, call nginx::conf
> nginx(type=ruby), install nginx-extras, call nginx::conf, call
> nginx::conf::passenger
> nginx(type=php), install nginx, php5-fpm, call nginx::conf, call
> nginx::conf::php
>
> And so forth. I'd rather not split this up into different modules, imho
> that's ugly but I can't figure out how to do it this way in puppet either.
I find "include 'nginx::php'" a lot more readable than "class
{ 'nginx': type => 'php' }", myself, but whatever. Your essential
problem is not related to parameterization.
> Can anyone point me in the right direction?
1) You do not need flow control, which is good because Puppet does not
offer it. You do need to define proper relationships among your
resources and/or classes, however, to ensure that Puppet chooses to
apply them in an order that works. It is in your best interest to
define all the real application-order relationships, but to avoid
defining other relationships (e.g. to force exactly one order of
application among several viable ones). The tools for defining
application-order relationships are the 'require', 'before',
'subscribe', and 'notify' resource metaparameters, the arrow syntax
for declaring relationships, and the 'require' function.
2) It's not clear to me whether the various options you envision for
usage of class nginx are intended to be exclusive alternatives. If
any node might need to use more than one of them then your concept
cannot work as you imagine.
3) Here's a skeleton for something that should work more or less along
the lines you describe:
### nginx module ###
# external classes
# nodes and classes from other modules
# may declare one or more of these:
class nginx::default {
# Note: the relative order of the 'include'
# statements is not significant
include 'nginx::base'
include 'nginx::conf'
}
class nginx::ruby {
include 'nginx::base'
include 'nginx::extras'
include 'nginx::conf'
include 'nginx::passenger'
}
class nginx::php {
include 'nginx::base'
include 'php::base'
include 'nginx::conf'
include 'nginx::conf::php'
}
# internal classes
# nodes and classes from other modules
# should not declare any of these directly:
class nginx::base {
package { 'nginx': }
}
class nginx::conf {
include 'nginx::base'
some_type_that_configures_nginx { 'conf_name':
require => Package['nginx']
}
# Note: some people would prefer a class-level
# relationship to the above resource-level one.
# Either can work.
}
class nginx::extras {
include 'nginx::base'
package { 'nginx-extras':
require => Package['nginx']
before => Some_type_that_configures_nginx[ 'conf_name']
}
}
class nginx::conf::passenger {
include 'nginx::conf'
include 'nginx::extras'
some_type_that_configures_nginx_for_passenger {
'nginx_passenger_conf_name':
require => Some_type_that_configures_nginx['conf_name']
}
}
class nginx::conf::php {
include 'nginx::conf'
require 'php::base'
some_type_that_configures_nginx_for_php {
'nginx_php_conf_name':
require => Some_type_that_configures_nginx['conf_name']
}
}
### php module ###
class php::base {
package { 'php5-fpm': }
}
##############
4) There are other ways to do it, including some involving class
parameterization.
John
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
