This message was deleted.
# office-hours
s
This message was deleted.
j
hey @Scott Macmillan
lemme take a look\
gratitude thank you 1
r
@Scott Macmillan we have the same approach. I’m also interested in the answer and can share what we are doing.
g
hey @Scott Macmillan 🙂 just to clarify, you're interested in examples etc of how to set up CI/CD for puppet modules?
s
I’m used to “puppet modules” being a mushy term, so I’ll overexplain. 🙂 We update our catalogs on our puppet build masters by putting gitlab runners on them, and then when a build is triggered on our gitlab instance, r10k on the masters creates / updates the environment. Please let me know if that doesn’t make total sense.
g
i'm not sure if i follow. What do you mean by putting gitlab runners on your puppet build masters?
c
This sounds like one for the 🧠 of @David Sandilands
s
Our puppet build masters have the gitlab runner software on them; when someone pushes to our gitlab instance’s puppet control repo, it triggers a build on each puppet master. In the context of that build, r10k then updates the relevant environment on that machine.
So, on each puppet master, gitlab-runner is running this script:
Copy code
#! /bin/bash

set -e

cat > r10k.yaml <<EOF
git:
  provider: 'shellgit'
sources:
  main:
    remote: '<https://r10k-deploy-token>:${REPO_KEY}@gitlab-example.com/puppet'
    basedir: "/etc/puppetlabs/code/environments"
EOF

r10k deploy --color environment "${CI_COMMIT_REF_NAME}" -c ./r10k.yaml -m --verbose=debug

rm -f ./r10k.yaml
(My puppet experience is limited to our academic computing environment, which is a weird one compared to many corporate environments - so please ask me if any of this seems super wacky.)
c
This does seem like an interesting approach.
😄 1
What were your constraints when designing ?
r
i’m in a meeting and will shows ours when it’s done.
🙏 1
i’m also in the academic environment 🙂
metal 1
c
I’d generally direct people towards webhooks and avoid installing additional things on the puppet masters
but I could be missing a trick
🙂
s
The original design isn’t mine - we’ve been running puppet since puppet 3 / 2008 or so, I think. So some of these decisions are baked in for ages, and I haven’t critically examined them myself. That said, we service both a HPRC cluster with 2000+ nodes that are all pretty much identical, but then also configure a ton of other systems - some internal tools and nodes, some are nodes used by various science labs for various purposes. The setup is designed in the paradigm so we can run a given environment on any given node. The move to having the gitlab runners on the puppetmasters is my move from the recent redesign - and the potential performance impacts of the nodes both running these builds via gitlab and then serving up catalogs has been on my mind (and is in part why I’m looking for references). Our old system was pretty convoluted, and this represents a big simplification.
My thought was that hopefully the builds aren’t a big impact, since it’s really just a vehicle to run r10k, which they would need to run anyway.
r
@Scott Macmillan we should definitely talk! i’m in the same boat, though less nodes.
👍 1
t
We usually run local gitlab (where we also mirror upstream modules), gitlab runners for tests and code deployments using r10k. voxpupuli has arch reference pages: https://voxpupuli.org/docs/arch_single_server/ and https://voxpupuli.org/docs/arch_load_balanced/
gratitude thank you 1