Lodbrok.be
Don't tell the systems HOW to do stuff, tell WHAT to do.
It it a one size fits all?
But before you are looking further, you should learn: RAL/resource, Facter, exec, Augeas/Xpath, Marionette Collective, ...
server> yum install puppet-server client> yum install puppet client> echo "10.10.10.10 puppet" >> /etc/hosts # make sure the client finds the master server> service puppetmaster start client> service puppet start server> puppet cert --list server> puppet cert sign --all server> puppet cert list --all config: /etc/puppet/ logs: /var/log/messages /var/log/daemon.log vardir (where Puppet stores dynamic and growing data) default: /var/lib/puppet/ server> facter server> egrep "fqdn:|memorytotal:|lsbdistdescription:" /var/lib/puppet/yaml/node/* server> ls -1 /var/lib/puppet/ssl/ca/signed/ | sed -e 's/.pem//' # list nodes with signed certificates from facter info client> puppet agent --test # force-run the agent once (optional --server=`hostname`)
[root@sapocvm1 manifests]# cat /etc/puppet/manifests/site.pp
file {'puppetisalive':
path => '/tmp/puppetlives',
ensure => present,
mode => 444,
content => "I'm a test file.",
}
[root@sapocvm2 ~]# puppet agent --test
info: Caching catalog for sapocvm2.gent.volvo.net
info: Applying configuration version '1398242680'
notice: /Stage[main]//File[puppetlives]/ensure: created
notice: Finished catalog run in 0.08 seconds
[root@sapocvm2 ~]# ls -ld /tmp/puppetlives
-rw-r--r--. 1 root root 16 Apr 23 10:44 /tmp/puppetlives
[root@sapocvm2 log]# tail -f messages
Apr 23 10:44:39 sapocvm2 puppet-agent[23803]: Caching catalog for sapocvm2.gent.volvo.net
Apr 23 10:44:39 sapocvm2 puppet-agent[23803]: Applying configuration version '1398242680'
Apr 23 10:44:39 sapocvm2 puppet-agent[23803]: (/Stage[main]//File[puppetlives]/ensure) created
Apr 23 10:44:39 sapocvm2 puppet-agent[23803]: Finished catalog run in 0.08 seconds
# on the server:
# changed the "description" puppetlives -> puppetisalive
# added mode => 444
[root@sapocvm2 ~]# puppet agent --test
info: Caching catalog for sapocvm2.gent.volvo.net
info: Applying configuration version '1398242943'
notice: /Stage[main]//File[puppetisalive]/mode: mode changed '0644' to '0444'
notice: Finished catalog run in 0.05 seconds
[root@sapocvm2 ~]# ls -ld /tmp/puppetlives
-r--r--r--. 1 root root 16 Apr 23 10:44 /tmp/puppetlives
$ puppet resource user <username> $ puppet describe --list # describe info for resources $ puppet apply /root/examples/test.pp $ puppet agent --test --debug --noop # --debug shows details and --noop simulates changes
|-modules.pp
|-manifests-|-nodes.pp
| |-site.pp
|
|-modules---|-sudo-----------------|-files-----|-sudoers
|
|-manifests-|-init.pp
my_module/ — This outermost directory’s name matches the name of the module.
manifests/ — Contains all of the manifests in the module.
init.pp — Contains one class named my_module. This class’s name must match the module’s name.
other_class.pp — Contains one class named my_module::other_class.
my_defined_type.pp — Contains one defined type named my_module::my_defined_type.
implementation/ — This directory’s name affects the class names beneath it.
foo.pp — Contains a class named my_module::implementation::foo.
bar.pp — Contains a class named my_module::implementation::bar.
files/ — Contains static files, which managed nodes can download.
service.conf — This file’s URL would be puppet:///modules/my_module/service.conf.
lib/ — Contains plugins, like custom facts and custom resource types.
templates/ — Contains templates, which the module’s manifests can use.
component.erb — A manifest can render this template with template('my_module/component.erb').
tests/ — Contains examples showing how to declare the module’s classes and defined types.
init.pp
other_class.pp — Each class or type should have an example in the tests directory.
spec/ — Contains spec tests for any plugins in the lib directory.
figure out howto multi-master (n-serv 1-client) / federated (n-teams 1-client) / multi-tenant (1-serv n-cust)
Example:
You probably have several difference choices that might have different drawbacks or benefits depending on exactly how you're managing things. One option that comes to mind is to use something like 'environments' to define a different site.pp file for each tenant. Each tenant could "claim" the machines under their control by setting a property on the console or in the agent's puppet.conf like so:
[agent]
tenant = "teamA"
In your master's puppet.conf, something like this:
[master]
manifest = "/usr/local/etc/puppet/tenant/${tenant}/manifests/site.pp
And so Team A's site.pp would be at:
/usr/local/etc/puppet/tenant/teamA/manifests/site.pp
You could arrange the directory/manifest structure there any way you want. This would be equally as valid:
[master]
manifest = "/usr/local/etc/puppet/manifests/${tenant}-site.pp
If you worry that 1 team will add node classification of another one, then the only way is via enviroments, each enviroment will have it's own site.pp.
References:
Reference