puppet apply #6 – installing modules

Built in types

So far, this control repo is limited to functionality built into the puppet agent, or that’s written from scratch. Built in types are documented by puppet, eg: https://puppet.com/docs/puppet/5.3/type.html

You can get a list from the client:

$ puppet resource --types
augeas
computer
cron
exec
file
filebucket
[...]

In the control repo structure, add-on puppet modules go into modules/

I use a script to populate it because:

  • The incantation to download modules isn’t especially memorable.
  • There’s one or two modules I’ll always want, like stdlib (which provides commonly used extra functionality) that the script is coded to deploy.

Some observations:

  • I don’t pull down all modules in use on my puppet master, just what I need for the new profile I’m developing.
  • Module dependencies are downloaded automatically by puppet module.
  • As the modules are downloaded into your workspace, the script refuses to run as root.
  • For development purposes, the latest modules are usually fine. So, the script doesn’t have a mechanism to support downloading specific versions.

.gitignore

If you’re using this repository clone to develop locally, you don’t want any modules you install to be picked up by the git client as changes.

Puppet’s sample control repo (the one I’ve modified) includes the necessary configuration to address this; .gitignore in the root of the repository contains:

modules/

Add the stdlib module

The previous post’s branch adds a script (in scripts/) for installing modules.

$ git status
# On branch puppetapply03
nothing to commit, working directory clean

Run it ‘as is’ to download stdlib; the script is hard coded to install that. Note: not sudo. It’ll object to running as root, as it would stick a bunch of root owned stuff in your control-repo directory structure.

scripts/puppetmodule.sh

Expect:

$ scripts/puppetmodule.sh 
Notice: Preparing to install into /etc/puppetlabs/code/environments/local/modules ...
Notice: Created target directory /etc/puppetlabs/code/environments/local/modules
Notice: Downloading from https://forgeapi.puppet.com ...
Notice: Installing -- do not interrupt ...
/etc/puppetlabs/code/environments/local/modules
└── puppetlabs-stdlib (v5.2.0)

If you then run puppet apply, via the script, the behaviour of the profile which dumps the scope changes; a fact is defined by stdlib, and so the profile writes the file to a different location, instead of /tmp.

sudo scripts/puppetapply.sh #--noop
[..]
Notice: /Stage[main]/Profile::Puppet::Clientscope/File[/opt/puppetlabs/puppet/cache/site_agent_variables.yaml]/content: content changed
  • The code doing this is in site/profile/manifests/puppet/clientscope.pp
  • That directory tree restricts access so only root can read the file.
  • The following will be in the output as well;  stdlib has provided additional facts.
Info: Loading facts

add concat module

Check out the next branch:

git checkout puppetapply04

Run puppet apply, and you’ll get an error:

sudo scripts/puppetapply.sh #--noop
[..]
Error: Evaluation Error: Error while evaluating a Resource Statement, Unknown resource type: 'concat::fragment'

A new set of profiles for building message-of-the-day are active; in site/profiles/manifests/motd/

As written, the script offers two ways to add more modules; either:

  • Modify the script in control repo permanently, to include modules you always want to download. Add them along side ‘puppetlabs-stdlib’ space separated.
  • Add modules adhoc by creating /tmp/puppetmodules.list on the machine you’re working on. Each module can go on a separate line.

To add concat, do the following.

$ echo 'puppetlabs-concat' >> /tmp/puppetmodules.list
$ scripts/puppetmodule.sh
[..]
 /etc/puppetlabs/code/environments/local/modules
└─┬ puppetlabs-concat (v5.2.0)
  ├── puppetlabs-stdlib (v5.2.0)
  └── puppetlabs-translate (v1.2.0)

For development and testing I find the temporary file is usually enough.  Once my workspace has a module, it’ll stay there until deleted, so it doesn’t need to be coded into the script permanently.

Puppet apply should now work.

sudo scripts/puppetapply.sh #--noop

You’ll get a diff for /etc/motd because the original code padded each line with a couple of spaces. (I did it to make the original motd.pp manifest look tidier .. it’s a bug really ..)

The revised profile creates /etc/motd_local as well – the contents of this file, if there is anything, is appended to /etc/motd.

Next

puppet apply #7 – classification via hiera

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s