Puppet.
Not a fan right now.
Where I am at in my stockholm syndrome development as I cope with learning Puppet using their official VM and docs is that I recognize that, while in my impression it is a bit over-engineered to the point of feature redundancy, this is a good orchestration framework and I think this as much as I acknowledge that it’s documentation is unnecessarily overcomplicated with a flow that is disjointed to the point of nigh incoherency.
- They just had too much to drink and they didn’t mean it.
- They’ll change if I get better.
- I had it coming.
- They said they wouldn’t do it again and they really mean it this time.
- It’s the influence of their Javaland friends.
- My baby SDLC needs to grow up with an orchestration framework around so that it knows how to act when it’s older.
That out of the way, let’s pick up where we left off last night going through the concepts presented in the VM.
Note to self: Don’t go to bed tonight without putting the finishing touches on that new file lock addition on that thing you said you’d finish today. You made a commitment and it’s the last piece.
So, yesterday, I’d finished the quest for resources, and another for manifests and classes. Next is modules, and it seems like most of the fundamentals of using and creating modules were covered in the course of building one in the previous section.
So, it looks like a puppet subcommand master is able to print values from its configuration file with the --configprint switch supplied to it.
root@learning:~ # puppet master --configprint modulepath /etc/puppetlabs/code/environments/production/modules:/etc/puppetlabs/code/modules:/opt/puppetlabs/puppet/modules root@learning:~ #
Interesting. There’s the other modules directory I pointed out the other day in code/ that I said seems to be environment-independent (also I am still not clued in as to why puppet is environment-aware as typically that’s going to be service independent for a whole barrage of valid reasons– I would not feel comfortable managing independent, full blown pre-prod and prod environments off one master in an enterprise environment at least).
There’s also a modules directory in /opt.
The one they care about right now is /etc/puppetlabs/code/enviornments/production/modules. Ah. Site-specific modules, or environment-independent modules (words mean things) are kept in the directory I was just talking about. And modules that are built into puppet are separated into the modules directory in /opt. Now I know.
LOL.
So, yesterday, I said something along the lines of “they could have just dumped the output of tree and made a couple paragraphs to explain all of this”. Well they did in this section.
When I run it on mine I get a bigger dump showing quite a bit of variance in the structure of modules:
root@learning:~ # tree -L 2 -d /etc/puppetlabs/code/environments/production/modules/ /etc/puppetlabs/code/environments/production/modules/ ├── concat │ ├── files │ ├── lib │ ├── manifests │ ├── spec │ └── tests ├── cowsayings │ ├── examples │ └── manifests ├── docker │ ├── doc │ ├── junit │ ├── lib │ ├── log │ ├── manifests │ ├── spec │ └── templates ├── dockeragent │ ├── examples │ ├── files │ ├── lib │ ├── manifests │ └── templates ├── graphite │ ├── manifests │ ├── spec │ └── templates └── stdlib ├── examples ├── lib ├── manifests └── spec
So I can definitely see now why there was a deeper dive into modules.
Out of time since it is a workday and I need to take care of some stuff.