Skip to content

Instantly share code, notes, and snippets.

View binford2k's full-sized avatar

Ben Ford binford2k

View GitHub Profile
@binford2k
binford2k / codecheck.rb
Created April 18, 2024 22:34
Quick and dirty script to check Puppetfiles for executable Ruby code
#! /usr/bin/env ruby
require 'ripper'
require 'json'
unless ARGV[0]
puts "Run this script with the name of a file, eg '#{$PROGRAM_NAME} /path/to/Puppetfile'."
puts "If the file contains any Ruby methods, this will print them and then exit with an error code."
exit 0
end
@binford2k
binford2k / puppet_report.rb
Created March 24, 2021 19:45
simple fact to report stats from last puppet run as a fact
Facter.add(:puppet_report) do
setcode do
report = YAML.load_file(Puppet.settings['lastrunreport'])
all_changes = report.resource_statuses.select { |title, rsc| rsc.changed }
config_changes = all_changes.select { |title, rsc| rsc.resource_type != 'Notify' }
{
:time => report.time,
:configuration_version => report.configuration_version,
:status => report.status,
<% |
Optional[String] $es_protocol = undef,
Integer $es_major_version = 0
| -%>
<% if $es_protocol {
$_es_protocol = $es_protocol
}
else {
# A quick and untested implementation of a deferred_epp() function to abstract
# the fiddly bits for deferring a template and render it agent side.
#
# Note: This depends on my find_template() PR.
#
# Note: If you're resolving variables agent side, then you'll have to defer
# them as well. Pass them in via the $variables hash like this example:
#
# $variables = {
# 'password' => Deferred('vault_lookup::lookup',

If you're anything like the rest of us, you're suddenly being asked to make a lot of unplanned infrastructure changes and you haven't been given a lot of time to prepare. You're probably looking into some kind of automation so that you can keep up.

I've got a few tips on getting started and doing it in a way that's less prone to missteps along the way, especially if this is new ground for your team. And at the end is a quick tutorial on using Bolt for quick and easy automation wins.

  1. Make a plan, but allow for course corrections.
  2. Start small and iterate.
  3. Automate the low hanging fruit only.
  4. Document, document, document!

Make a plan, but allow for course corrections

[~]$ cat tmp/append.pp
class foo::bar($foo = []) {
inline_template('<%= @foo.push("bar") %>')
# do things
inline_template('<%= @foo.push("foo") %>')
# more things
inline_template('<%= @foo.push("hello") %>')
# even more things
inline_template('<%= @foo.push("test") %>')
notify{$foo.join(','):}
$variables = {
'password' => 'this is my passphrase'.node_encrypt::secret,
}
# compile the template source into the catalog
file { '/etc/secrets.conf':
ensure => file,
content => Deferred('inline_epp',
['PASSWORD=<%= $password %>', $variables]),
}
{
"reported_compatibility": [
{
"operatingsystem": "Archlinux",
"version": "2020-01-01",
"reporter": "@githubusername or email",
"date": "2020-01-29",
"support": "timlovesbugreports@bastelfreak.de"
}
]
@binford2k
binford2k / 01_site_schema.txt
Last active January 13, 2020 17:57
These usage patterns are required for our content teams and external module authors to allocate developer resources efficiently. This schema is the part of the dataset that will be made public for community use. We attempt to provide as much useful information as possible without compromising sensitive information about users' infrastructures.
# This schema represents a regular site checkin. The service collects far more data,
# but most of it remains in private datasets. The site_id is a hashed & anonymous value.
# It cannot be reversed into something identifiable, even by us. We're limiting the data
# in this table to minimize the ability to "fingerprint" a specific site. We explicitly
# do not reveal node count in any way.
#
# This table provides only a highlevel overview of what user's codebases look like. It
# can be used to answer questions like:
# - are the people using my module on windows also using it on other platforms?
# - does my module need to support a wide range of agent versions or can I tell people
@binford2k
binford2k / report.md
Last active January 6, 2020 19:02
Puppet 3.x -> 4.x function API upgrade report

Puppet 3.x -> 4.x function API upgrade

This is a quick report of all the GitHub repositories that we attempted to automatically upgrade to the Puppet 4.x function API. Many of these are stale and won't ever be noticed. And many of them are redundant forks, because for whatever reason, the GitHub API doesn't always identify forks reliably. 🤷

But it's a decent start!

Of interest is the fact that only roughly 900 module repositories contained