Forem: Robert Waffen

How to keep your Puppet modules up to date with Renovate

Robert Waffen — Wed, 25 Mar 2026 16:14:50 +0000

Managing a Puppet control repository with a growing list of dependencies can quickly become a challenge.
Keeping everything up to date manually?
That’s not just tedious — it’s also error-prone.

Modules are updated frequently, sometimes daily.
With a long list of dependencies, it’s easy to miss important updates.
And let’s be honest: humans are not exactly known for perfect consistency when it comes to repetitive tasks.

So why not let a bot handle it?

Why Renovate?

Renovate is designed to take over exactly this kind of work.
It continuously scans your repositories, detects dependency updates, and automatically creates merge requests for you — including changelogs.

Instead of manually checking versions, you simply review and merge PRs.
Much cleaner.
Much safer.

Assumptions

Before we get started, this setup assumes:

Your repositories are hosted on GitLab
You are using GitLab CI with runners
You can run container-based jobs

Setting Up Renovate

Create a Renovate Runner Repository

Create a dedicated repository in GitLab, for example: renovate-runner

Inside this repository, create a config.js file:

module.exports = {
  autodiscover: false,
  dependencyDashboard: true,
  // We only enable the puppet manager here
  // see all managers: https://docs.renovatebot.com/modules/manager/
  enabledManagers: ['puppet'],
  // GitLab API - update with your instance URL
  endpoint: 'https://gitlab.example.com/api/v4/',
  extends: ['config:base', ':semanticCommits', ':semanticCommitTypeAll(chore)'],
  labels: ['renovate', 'dependencies'],
  platform: 'gitlab',
  prCreation: "immediate",
  prHourlyLimit: 20,
  repositories: ['puppet/control-repo'],
  requireConfig: true,
  reviewers: ['@rwaffen'],
  token: process.env.RENOVATE_TOKEN
};

This configuration will create one merge request per dependency update.

If you prefer grouped updates, you can extend it like this:

packageRules: [
  {
    matchManagers: ["puppet"],
    groupName: "{{manager}}",
  }
]

Add GitLab CI Configuration

Create a .gitlab-ci.yml:

---
run_renovate:
  image:
    name: ghcr.io/voxpupuli/renovate:latest
    entrypoint: [""]
  resource_group: production
  script:
    - renovate $RENOVATE_EXTRA_FLAGS
  only:
    - schedules
    - triggers
    - web
  # variables:
  #   LOG_LEVEL: debug

Running Renovate

With everything in place, you can trigger a pipeline in your renovate-runner repository.

Once started, Renovate will take over and handle the full update cycle for you:

It launches the Renovate container
Authenticates using your configured token
Scans the defined repositories
Detects dependency files such as Puppetfile
Resolves current versions and checks for new releases or tags
Creates merge requests whenever updates are available

At this point, your role shifts from maintainer to reviewer:
you simply go through the generated merge requests and decide what to merge.

To make this process truly hands-off, you should also configure a scheduled pipeline in GitLab.
This ensures Renovate runs regularly and keeps your dependencies continuously up to date — without any manual triggering.

Authentication: `RENOVATE_TOKEN`

Renovate requires a Personal Access Token (RENOVATE_TOKEN) to interact with your repositories.

Required permissions:

api
write_repository

It is highly recommended to create this as a group access token, so Renovate can access all relevant repositories — especially important if your Puppetfile includes Git-based modules.

Choosing the Right Container Image

Renovate provides official container images, but they come with some trade-offs:

Large size
Based on Ubuntu
Higher number of known vulnerabilities (CVEs)

Vox Pupuli provides a leaner alternative:

Smaller footprint
Based on Alpine
Significantly fewer vulnerabilities

IMAGE                                 ID             DISK USAGE   CONTENT SIZE   EXTRA
ghcr.io/renovatebot/renovate:latest   0334065a0093       1.87GB          416MB
ghcr.io/voxpupuli/renovate:latest     e354b2af781c        726MB          132MB

Vulnerability Scan (grype)

grype ghcr.io/renovatebot/renovate:latest

 ✔ Scanned for vulnerabilities     [297 vulnerability matches]
   ├── by severity: 1 critical, 10 high, 971 medium, 137 low, 15 negligible
   └── by status:   14 fixed, 1120 not-fixed, 837 ignored

grype ghcr.io/voxpupuli/renovate:latest

 ✔ Scanned for vulnerabilities     [19 vulnerability matches]
   ├── by severity: 0 critical, 15 high, 4 medium, 0 low, 0 negligible
   └── by status:   13 fixed, 6 not-fixed, 0 ignored

Final Thoughts

With Renovate in place, dependency management becomes predictable and automated.
Instead of chasing updates manually, you get a steady stream of structured merge requests — complete with context and changelogs.
In other words: less chaos, more control.

🧩 Puppet Module Update Process

Robert Waffen — Fri, 11 Jul 2025 07:59:30 +0000

🔍 1. Identify and Analyze the Module

Extract a module name from the Puppetfile.
Search for the module on Puppet Forge.
Compare available versions and identify the latest one.

📝 2. Review Changes in the Module

Follow the Project URL on the Forge page to the GitHub repository.
Check recent changes under Releases or in the Changelog.

Example:

⚠️ 3. Watch for Breaking Changes

Possible breaking changes:
- Removal of support for EOL software
- API changes
- Renamed parameters or variables
Note: Not every breaking change will affect your setup.
- Example: Dropping EL6 support likely doesn’t concern you.

🔍 4. Evaluate Other Changes

Linked pull requests (PRs) may offer additional insights.
Check whether changes are understandable and whether breaking changes apply to your environment.

🌱 5. Integrate into Development Branches

If the module is considered ready for update:
- Integrate into a feature or development branch.

🌲 6. Control Repo Branch Structure

Typically present:

development
production
Optionally: staging before production
Additionally: 0–n feature branches

🧪 7. Testing in Development Environment

Test the updated module in a suitable environment (VM, container).
Observe how it interacts with other modules.

Possible findings:

Dependencies on specific module versions
New facts writing additional data to PuppetDB
New or modified parameters requiring Hiera data

🔄 8. Forward the Change

Once all adjustments are complete:
- Pass the change to the next branch for further testing or rollout preparation.

🤖 9. Automation with Renovate Bot

This process is quite detailed and time-consuming.
With Renovate Bot, collecting and reviewing relevant updates becomes much easier.
Renovate can be integrated into GitLab or GitHub.
It works similarly to GitHub’s built-in Dependabot, but is more flexible and configurable.

🧰 10. Automation with VoxBox

You can also try using the Vox Pupuli VoxBox to list all dependencies for the entire control repo.
- This doesn't work with every setup.
- If there are private modules in the Puppetfile, the person running the command must have access to them.
- Example command:
- podman run -it --rm -v $PWD:/repo:Z ghcr.io/voxpupuli/voxbox:latest r10k:dependencies
More useful information can be found in the Vox Pupuli VoxBox documentation

🧩 Puppet Modul Update Prozess

Robert Waffen — Fri, 11 Jul 2025 07:58:40 +0000

🔍 1. Modul identifizieren und analysieren

Einen Modulnamen aus dem Puppetfile entnehmen.
In der Puppet Forge nach dem Modul suchen.
Verfügbare Versionen vergleichen und die neueste identifizieren.

📝 2. Änderungen im Modul prüfen

Über den Link zur Project URL auf der Forge-Seite zum GitHub-Repository wechseln.
Dort unter Releases oder im Changelog die letzten Änderungen prüfen:

Beispiel:

⚠️ 3. Auf Breaking Changes achten

Mögliche Breaking Changes:
- Entfernung der Unterstützung für EOL-Software
- Änderungen an der API
- Umbenennung von Variablen
Hinweis: Nicht jede Breaking Change ist für jedes Setup relevant.
- Beispiel: Der Entfall von EL6-Support betrifft euch vermutlich nicht.

🔍 4. Sonstige Änderungen bewerten

Auch verlinkte Pull Requests (PRs) können Aufschluss geben.
Prüfen, ob Änderungen nachvollziehbar sind und keine Breaking Changes enthalten, die euch betreffen.

🌱 5. Aufnahme in Entwicklungszweige

Wenn das Modul als updatefähig eingeschätzt wird:
- Aufnahme in einen Feature- oder Development-Branch

🌲 6. Branch-Struktur im Control-Repo

Typischerweise vorhanden:

development
staging
production
Zusätzlich: 0–n Feature-Branches

🧪 7. Tests in Entwicklungsumgebung

Test des neuen Moduls in geeigneter Umgebung (VM, Container)
Beobachtung des Zusammenspiels mit anderen Modulen

Mögliche Erkenntnisse:

Abhängigkeit zu anderen Modul-Versionen
Neue Facts, die zusätzliche Daten in die PuppetDB schreiben
Neue oder geänderte Parameter, die Hiera-Daten erfordern

🔄 8. Change weiterreichen

Wenn alle Anpassungen erledigt sind:
- Übergabe des Changes in den nächsten Branch zur weiteren Prüfung oder Vorbereitung für den Rollout.

🤖 9. Automatisierung mit Renovate Bot

Dieser Prozess ist sehr kleinteilig und kann zeitaufwendig sein.
Mit Hilfe von Renovate Bot lässt sich das Sichten und Sammeln der relevanten Informationen deutlich erleichtern.
Renovate ist ein Bot, der sich in GitLab oder GitHub integrieren lässt.
Er funktioniert ähnlich wie der GitHub-eigene Dependabot, ist aber deutlich flexibler und konfigurierbarer.

🧰 10. Automatisierung mit VoxBox

Man kann auch versuchen mit der Vox Pupuli Voxbox die Abhängigkeiten für das gesamte Control-Repo anzeigen zu lassen.
- Das klappt nicht bei jedem Setup.
- Wenn im Puppetfile private Module sind, muss der jenige der es ausführt, Zugriff auf diese haben.
- Beispielbefehl:
- podman run -it --rm -v $PWD:/repo:Z ghcr.io/voxpupuli/voxbox:latest r10k:dependencies
Weitere nützliche Informationen gibt es in der Vox Pupuli VoxBox Dokumentation

All the Vox Pupuli containers

Robert Waffen — Mon, 24 Mar 2025 09:43:36 +0000

You may have heard about our (now deprecated) puppetserver/puppetdb container images?
But did you know that we have a lot more containers available?
We have the brand new OpenVox containers, which replace the old puppetserver and puppetdb containers, and even some more.

OpenVox containers

openvoxserver

openvoxserver is a drop-in replacement for the old voxpupuli/puppetserver container.

openvoxdb

openvoxdb is a drop-in replacement for the old voxpupuli/puppetdb container.

openvoxagent

openvoxagent is a drop-in replacement for the old puppet/puppet-agent container. It is mostly used for testing purposes, as of now.

Vox Pupuli containers

voxbox

voxbox is a container that contains a lot of tools that are useful for OpenVox/Puppet development and testing.
It includes tools like puppet-lint, modulesync, onceover, facter, yamllint, rubocop and the Vox Pupuli testing gems.

r10k

r10k is a container that contains r10k, a tool to manage OpenVox/Puppet environments.

semantic-release

semantic-release is a container that contains the semantic-release tool, which is used to automatically release new versions of software projects.

commitlint

commitlint is a container that contains the commitlint tool, which is used to lint commit messages.

See also: commitlint and conventional commits

puppet-catalog-diff-viewer

puppet-catalog-diff-viewer is a container that contains the puppet-catalog-diff-viewer tool, which is used to visualize the differences between two OpenVox/Puppet catalogs.

puppetboard

puppetboard is a container that contains the puppetboard tool, which is a web interface for OpenVoxDB/PuppetDB.

Conclusion

So you see, we have a lot of containers available.
If you have any questions or suggestions, feel free to reach out to us on GitHub or on our other Channels
If you need help with any of the containers, feel free to open an issue on the respective GitHub repository.
Some examples of how to use the containers can be found in the CRAFTY repository.

New container names for puppetserver and puppetdb

Robert Waffen — Fri, 02 Aug 2024 12:57:37 +0000

Beginning of today we are also releasing our puppetserver and puppetdb containers with shorter names.

The current names are: voxpupuli/container-puppetserver and voxpupuli/container-puppetdb.

The new, shorter names are: voxpupuli/puppetserver and voxpupuli/puppetdb.

The content is exactly the same, only the name has changed. Only new tags will be pushed to the new names. The old names will also be updated.

We plan to deprecate the old names in 6 months (2025-02), so please update your scripts and configurations to use the new names.

Vox Pupuli Elections voting period

Robert Waffen — Wed, 10 Apr 2024 07:41:26 +0000

After a slight delay, we are opening the voting period for this year’s PMC elections. Votes will be accepted until May 15 2024 23:59 UTC.

Please help us select the Vox Pupuli Project Management Committee for the 2024 year. The people on this committee will help take care of the Code of Conduct and its values, participate in strategic planning, and decision making using lazy consensus, amongst other things.

New this year, we are also adding two specialized roles:

The accounting officer will keep track of budget, expenses, and sponsorships.
The social media officer will coordinate social, blog, and other similar activities. They’re not necessarily responsible for -all- content, but will help facilitate it.

These roles will be self selected amongst the committee after the election concludes.

Visit the page below to read more about the candidates and to make your choices.

Vox Pupuli elections, 2024

Thank you so much for your help!
(original post from @binford2k at voxpupuli.org)

What it means to be a PMC member

Robert Waffen — Mon, 19 Feb 2024 09:34:36 +0000

The upcoming Project Management Committee (PMC) elections are drawing near, prompting a reflection on the essence of committee membership.

In essence, being part of the PMC revolves around fostering an environment of excellence and collaboration. TL;DR: Strive to embody these principles and actively contribute to adaptation and enhancement!

Having served on the PMC for a year now, I've encountered no major issues. But what constitutes a problem, you may wonder? Allow me to elaborate briefly: As a committee member, one of your primary responsibilities is maintaining peace and harmony within our chat rooms and forums. Should tensions arise, your role is to defuse conflicts and, if necessary, take measures such as user bans. Fortunately, such interventions have not been required within the Vox Pupuli community, which prides itself on its serene, inclusive atmosphere. Over my two years of increasing involvement, I've yet to witness a situation necessitating moderator (PMC member) intervention. For guidance on conduct, our Code of Conduct can provide valuable insights.

In addition to responsibilities, PMC membership also grants certain privileges. One such privilege is administrative access on GitHub. However, as the adage goes, "with great power comes great responsibility!" This access is bestowed upon members to facilitate the migration of others to Vox Pupuli or to manage organizational settings. Tasks may include adding new members on GitHub or implementing changes suggested directly on the platform.

Curious about the current PMC team? Meet them here. These individuals were elected last year. If you're considering joining, you can submit your application via the plumbing repository on GitHub. Simply create a pull request and add yourself or nominate someone else. For example: My nomination by @tuxmea. Yes, you read that correctly – you can also nominate others whom you believe would be valuable additions to the PMC.

For a comprehensive overview of PMC membership duties, refer to our Governance Document.

Vox Pupuli is now also on dev.to

Robert Waffen — Fri, 16 Feb 2024 12:52:38 +0000

As of today, we've officially joined dev.to, a leading platform for tech and development blogging. In addition to our established blog on voxpupuli.org, we'll be expanding our reach to include dev.to. Stay tuned for upcoming posts, including insights into the Project Management Committee (PMC) election and the significance of being part of the PMC. These initial posts mark the beginning of our journey on both platforms, and we're excited to see where it takes us.

Puppet und Kubernetes

Robert Waffen — Wed, 09 Aug 2023 14:46:17 +0000

Heute zeigen wir, wie man einen Kubernetes Cluster mit Puppet aufsetzen und verwalten kann.

Puppet Modul Auswahl

Es gibt einige Puppet Module auf der Puppet Forge, mit denen man Kubernetes verwalten kann.
So findet man unter anderem die Module Puppetlabs Kubernetes und Voxpupuli k8s.
Alle weiteren Module haben seit geraumer Zeit keine Aktualisierungen mehr erhalten. Daher betrachten wir diese Module als verwaist.

Hinweis: auf dem CfgMgmtCamp 2023 hat die Puppet Open Source Community mit den Puppet Mitarbeitern geredet und darum gebeten, das puppetlabs-kubernetes Modul zu archivieren. Dieses Modul benötigt für das initiale Setup eine bereits laufende Kubernetes Umgebung und möchte die Konfiguration mit Hilfe eines besonderen Containers auslesen.

Wir empfehlen dringend, das neue, moderne Voxpupuli k8s Modul zu verwenden.

Puppet-K8S Modul

Mit dem Puppet K8S Modul kann man Controller Nodes und Worker Nodes einrichten. Beide benötigen dazu die Klasse k8s.
Alle Einstellungen können mit Hilfe von Hiera Daten vorgenommen werden. Dabei sind die Parameter über 3 Klassen verteilt:

Allgemeine Daten: k8s Klasse
Controller Daten: k8s::server Klasse
Worker Daten: k8s::node Klasse

Ein einfacher Cluster benötigt die folgenden Parameter:

Kubernetes controller (apiserver, controller-manager und scheduler)

k8s::role: 'server'
k8s::master: 'http://controller-0.example.com:6443'

Das Setup der notwendigen etcd Server Instanzen kann auf 2 unterschiedliche Arten vorgenommen werden:

Statische Liste (FQDN)
Verwendung von PuppetDB

# PuppetDB
k8s::puppetdb_discovery: true
# oder Liste
k8s::server::etcd_servers:
  - 'https://node1:2379'
  - 'https://node2:2379'
  - 'https://node3:2379'

Das Erzeugen der für Kubernetes notwendigen Zertifikate kann das Modul übernehmen. Man kann auch bestehende Zertifikate hinterlegen.
Beim Aufsetzen einer geclusterten Control Plane, muss man beachten, dass die Zertifikate des ersten Cluster Control Nodes auf die weiteren Control Nodes verteilt wird. Dies betrifft die folgenden Verzeichnisse:
/etc/kubernetes/certs und /var/lib/etcd/certs.
Die Verteilung ist noch nicht Bestandteil des Moduls.

k8s::server::etcd::generate_ca: true
k8s::server::generate_ca: true

Kubernetes worker (kubelet)

k8s::role: 'node'
k82::master: 'https://controller-0.example.com:6443'

Beispiel für containerd und bridge networking

Controller

k8s::role: 'server'
k8s::master: 'https://controller-0.example.com:6443' # default
k8s::container_manager: 'containerd'

k8s::manage_firewall: true    # default: false
k8s::puppetdb_discovery: true # default: false

k8s::server::node_on_server: false # don't use controller as worker
k8s::server::etcd::generate_ca: true
k8s::server::generate_ca: true

# bind apiserver to a interface the worker and controller can communicate with
k8s::server::apiserver::advertise_address: "%{facts.networking.interfaces.enp0s8.ip}"

# flannel networking is default in the module
# but we want to showcase bridged networking here
k8s::server::resources::manage_flannel: false

k8s::service_cluster_cidr: '10.20.0.0/20' # overlay network for cluster services
k8s::cluster_cidr: '10.20.16.0/20'        # overlay network for the pods in the cluster

Worker

k8s::role: 'node'
k8s::master: 'https://controller-0.example.com:6443' # default
k8s::container_manager: 'containerd'

k8s::manage_fireall: true
k8s::puppetdb_discovery: true

# the same as in k8s::server::resources::bootstrap::secret but prefixed with "puppet."
k8s::node::node_token: "puppet.%{lookup('k8s::server::resources::bootstrap::secret')}"

# for debugging
k8s::node::manage_crictl: true
k8s::install::crictl::config:
  'runtime-endpoint': 'unix:///run/containerd/containerd.sock'
  'image-endpoint': 'unix:///run/containerd/containerd.sock'

k8s::service_cluster_cidr: '10.20.0.0/20' # overlay network for cluster services
k8s::cluster_cidr: '10.20.16.0/20'        # overlay network for the pods in the cluster

Shared data

lookup_options:
  k8s::server::resources::bootstrap::secret:
    convert_to: Sensitive

# Sensitive[Pattern[/^[a-z0-9]{16}$/]]
k8s::server::resources::bootstrap::secret: 'a23456789bcdefgh'

Beispiel für containerd und cilium

Zuerst wird kube-proxy benötigt um ein initiales Setup zu erzeugen.
Danach wird Cilium installiert, welches kube-proxy ersetzt.
Nach der Cilium Installation kann kube-proxy wieder entfernt werden.

Controller

k8s::role: 'server'
k8s::master: 'https://controller-0.example.com:6443' # default
k8s::container_manager: 'containerd' # default: crio

k8s::manage_firewall: true    # default: false
k8s::puppetdb_discovery: true # default: false

k8s::server::node_on_server: false # don't use controller as worker
k8s::server::etcd::generate_ca: true
k8s::server::generate_ca: true


# bind apiserver to a interface the worker and controller can communicate with
k8s::server::apiserver::advertise_address: "%{facts.networking.interfaces.enp0s8.ip}"

# we want to showcase cilium here
k8s::server::resources::manage_flannel: false

Worker

k8s::role: 'node'
k8s::master: 'https://controller-0.example.com:6443'
k8s::container_manager: 'containerd'


k8s::manage_firewall: true
k8s::puppetdb_discovery: true

# the same as in k8s::server::resources::bootstrap::secret but prefixed with "puppet."
k8s::node::node_token: "puppet.%{lookup('k8s::server::resources::bootstrap::secret')}"

# for debugging
k8s::node::manage_crictl: true
k8s::install::crictl::config:
  'runtime-endpoint': 'unix:///run/containerd/containerd.sock'
  'image-endpoint': 'unix:///run/containerd/containerd.sock'

k8s::service_cluster_cidr: '10.20.0.0/20' # overlay network for cluster services
k8s::cluster_cidr: '10.20.16.0/20'        # overlay network for the pods in the cluster

Shared data

lookup_options:
  k8s::server::resources::bootstrap::secret:
    convert_to: Sensitive

# Sensitive[Pattern[/^[a-z0-9]{16}$/]]
k8s::server::resources::bootstrap::secret: 'a23456789bcdefgh'

Nach dem initialen Setup kann Cilium installiert werden.

Initialize cilium

⚠️ Alle hier genannten Schritte müssen auf EINEM der Controller ausgeführt werden!

Das Cilium Paket muss heruntergeladen werden. Dies ist noch nicht Bestandteil des Moduls. Die notwendige Konfiguration erfolgt in der Datei cilium-values.yaml.

Installation laut cilium quick installation

CILIUM_CLI_VERSION=$(curl -s https://raw.githubusercontent.com/cilium/cilium-cli/master/stable.txt)
CLI_ARCH=amd64
if [ "$(uname -m)" = "aarch64" ]; then CLI_ARCH=arm64; fi
curl -L --fail --remote-name-all https://github.com/cilium/cilium-cli/releases/download/${CILIUM_CLI_VERSION}/cilium-linux-${CLI_ARCH}.tar.gz{,.sha256sum}
sha256sum --check cilium-linux-${CLI_ARCH}.tar.gz.sha256sum
sudo tar xzvfC cilium-linux-${CLI_ARCH}.tar.gz /usr/local/bin
rm cilium-linux-${CLI_ARCH}.tar.gz{,.sha256sum}

Die cilium-values.yaml Datei

---
k8sServiceHost: controller-0.example.com
k8sServicePort: 6443
autoDirectNodeRoutes: true
rollOutCiliumPods: true
kubeProxyReplacement: strict
tunnel: disabled
ipv4NativeRoutingCIDR: 10.20.16.0/20 # overlay network for the pods in the cluster
priorityClassName: system-cluster-critical
ipam:
  mode: kubernetes
nodePort:
  enabled: true
  directRoutingDevice: ens192
bpf:
  clockProbe: true
  masquerade: true
  tproxy: true
loadBalancer:
  mode: hybrid
  algorithm: maglev
  hashSeed: uWul3Twb7mKCmNSN
hubble:
  relay:
    enabled: true
    rollOutPods: true
  ui:
    enabled: true
    rollOutPods: true
operator:
  rollOutPods: true
  prometheus:
    enabled: true
hostPort:
  enabled: true
ipv4:
  enabled: true
ipv6:
  enabled: true
socketLB:
  enabled: true
prometheus:
  enabled: true

Vor der Cilium Installation muss man prüfen, dass alle Worker Nodes verbunden sind. Diese können auch im Status NotReady sein.

# kubectl get nodes

NAME                   STATUS     ROLES    AGE   VERSION
worker-1.example.com   NotReady   <none>   83s   v1.26.4
worker-2.example.com   NotReady   <none>   83s   v1.26.4

Installation von Cilium:

cilium install --version v1.13.2 --helm-values /path/to/cilium-values.yaml

ℹ️  Using Cilium version 1.13.2
🔮 Auto-detected cluster name: default
🔮 Auto-detected datapath mode: tunnel
🔮 Auto-detected kube-proxy has not been installed
ℹ️  Cilium will fully replace all functionalities of kube-proxy
ℹ️  helm template --namespace kube-system cilium cilium/cilium --version 1.13.2 --set autoDirectNodeRoutes=true,bpf.clockProbe=true,bpf.masquerade=true,bpf.tproxy=true,cluster.id=0,cluster.name=default,encryption.nodeEncryption=false,hostPort.enabled=true,hubble.relay.enabled=true,hubble.relay.rollOutPods=true,hubble.ui.enabled=true,hubble.ui.rollOutPods=true,ipam.mode=kubernetes,ipv4.enabled=true,ipv4NativeRoutingCIDR=10.20.16.0/20,ipv6.enabled=true,k8sServiceHost=localhost,k8sServicePort=6443,kubeProxyReplacement=strict,loadBalancer.algorithm=maglev,loadBalancer.hashSeed=uWul3Twb7mKCmNSN,loadBalancer.mode=hybrid,nodePort.directRoutingDevice=enp0s8,nodePort.enabled=true,operator.prometheus.enabled=true,operator.replicas=1,operator.rollOutPods=true,priorityClassName=system-cluster-critical,prometheus.enabled=true,rollOutCiliumPods=true,serviceAccounts.cilium.name=cilium,serviceAccounts.operator.name=cilium-operator,socketLB.enabled=true,tunnel=disabled
ℹ️  Storing helm values file in kube-system/cilium-cli-helm-values Secret
🔑 Created CA in secret cilium-ca
🔑 Generating certificates for Hubble...
🚀 Creating Service accounts...
🚀 Creating Cluster roles...
🚀 Creating ConfigMap for Cilium version 1.13.2...
🚀 Creating Agent DaemonSet...
🚀 Creating Operator Deployment...
⌛ Waiting for Cilium to be installed and ready...
✅ Cilium was successfully installed! Run 'cilium status' to view installation health

Nun sollten alle Worker im Ready Status sein:

kubectl get nodes

NAME                   STATUS   ROLES    AGE   VERSION
worker-1.example.com   Ready    <none>   5m    v1.26.4
worker-2.example.com   Ready    <none>   5m    v1.26.4

cilium status

    /¯¯\
 /¯¯\__/¯¯\    Cilium:          OK
 \__/¯¯\__/    Operator:        OK
 /¯¯\__/¯¯\    Hubble Relay:    disabled
 \__/¯¯\__/    ClusterMesh:     disabled
    \__/

Deployment        cilium-operator    Desired: 1, Ready: 1/1, Available: 1/1
DaemonSet         cilium             Desired: 1, Ready: 1/1, Available: 1/1
Containers:       cilium             Running: 1
                  cilium-operator    Running: 1
Cluster Pods:     1/1 managed by Cilium
Image versions    cilium             quay.io/cilium/cilium:v1.13.2@sha256:85708b11d45647c35b9288e0de0706d24a5ce8a378166cadc700f756cc1a38d6: 1
                  cilium-operator    quay.io/cilium/operator-generic:v1.13.2@sha256:a1982c0a22297aaac3563e428c330e17668305a41865a842dec53d241c5490ab: 1

Nach der erfolgreichen Installation von Cilium kann kube-proxy deinstalliert werden:

k8s::server::resources::kube_proxy::ensure: absent

Weitere Dokumentation

Class reference
Examples
- Simple bridged setup
- Cilium setup

Puppet and Kubernetes

Robert Waffen — Wed, 09 Aug 2023 14:44:05 +0000

Within this article we explain how one can make use of Puppet to deploy Kubernetes.

Puppet Module selection

There are several Puppet Modules on the Puppet Forge which allow one to manage Kubernetes using Puppet.
You will find the Puppetlabs Kubernetes and the Voxpupuli k8smodule.
All other modules have not received an update for several years. We therefore consider these modules to be unmaintained.

Sidenote: at CfgMgmtCamp 2023 the Puppet community asked the Puppet staff to please deprecate the puppetlabs-kubernetes module. This module requires to already have a kubernetes instance running and uses a container to read config which you can then use to configure kubernetes. Sounds like a hen-egg problem.

We highly recommend to make use of the new, modern Voxpupuli Module.

Puppet-K8S Module

The Puppet K8S Module is able to install control nodes and worker nodes. Both need the class k8s within their node classification.
All settings can be configured using hiera. Most parameters are spread over three classes: k8s main class, k8s::server and k8s::node subclasses.

A simple setup requires the following parameters

Kubernetes controller (apiserver, controller-manager and scheduler)

k8s::role: 'server'
k8s::master: 'http://controller-0.example.com:6443'

The setup of the etcd server instances is controlled via two different ways:

provide a static list of etcd server fqdn
use PuppetDB for etcd server discovery.

k8s::puppetdb_discovery: true
# or
k8s::server::etcd_servers:
  - 'https://node1:2379'
  - 'https://node2:2379'
  - 'https://node3:2379'

If you don't have pre-existing tls certificates you can use the generate features. This will auto generate all needed certificates for a cluster. On a single controller this is all you need. If you have a clustered control plane you need to somehow transfer the generated certs from the first controller from /etc/kubernetes/certs and /var/lib/etcd/certs to the other controllers. The cert distribution in a clustered setup is not part of the module yet.

k8s::server::etcd::generate_ca: true
k8s::server::generate_ca: true

Kubernetes worker (kubelet)

k8s::role: 'node'
k82::master: 'https://controller-0.example.com:6443'

Example for containerd as cri and bridge networking as cni

Controller

k8s::role: 'server'
k8s::master: 'https://controller-0.example.com:6443' # default
k8s::container_manager: 'containerd'

k8s::manage_firewall: true    # default: false
k8s::puppetdb_discovery: true # default: false

k8s::server::node_on_server: false # don't use controller as worker
k8s::server::etcd::generate_ca: true
k8s::server::generate_ca: true

# bind apiserver to a interface the worker and controller can communicate with
k8s::server::apiserver::advertise_address: "%{facts.networking.interfaces.enp0s8.ip}"

# flannel networking is default in the module
# but we want to showcase bridged networking here
k8s::server::resources::manage_flannel: false

k8s::service_cluster_cidr: '10.20.0.0/20' # overlay network for cluster services
k8s::cluster_cidr: '10.20.16.0/20'        # overlay network for the pods in the cluster

Worker

k8s::role: 'node'
k8s::master: 'https://controller-0.example.com:6443' # default
k8s::container_manager: 'containerd'

k8s::manage_fireall: true
k8s::puppetdb_discovery: true

# the same as in k8s::server::resources::bootstrap::secret but prefixed with "puppet."
k8s::node::node_token: "puppet.%{lookup('k8s::server::resources::bootstrap::secret')}"

# for debugging
k8s::node::manage_crictl: true
k8s::install::crictl::config:
  'runtime-endpoint': 'unix:///run/containerd/containerd.sock'
  'image-endpoint': 'unix:///run/containerd/containerd.sock'

k8s::service_cluster_cidr: '10.20.0.0/20' # overlay network for cluster services
k8s::cluster_cidr: '10.20.16.0/20'        # overlay network for the pods in the cluster

Shared data

lookup_options:
  k8s::server::resources::bootstrap::secret:
    convert_to: Sensitive

# Sensitive[Pattern[/^[a-z0-9]{16}$/]]
k8s::server::resources::bootstrap::secret: 'a23456789bcdefgh'

Example data for containerd as cri and cilium as cni

In the first place we need kube-proxy to get an initial setup working.
After this we will install cilium, which will completly replace kube-proxy.
After the installation of cilium we can remove kube-proxy.

Controller

k8s::role: 'server'
k8s::master: 'https://controller-0.example.com:6443' # default
k8s::container_manager: 'containerd' # default: crio

k8s::manage_firewall: true    # default: false
k8s::puppetdb_discovery: true # default: false

k8s::server::node_on_server: false # don't use controller as worker
k8s::server::etcd::generate_ca: true
k8s::server::generate_ca: true


# bind apiserver to a interface the worker and controller can communicate with
k8s::server::apiserver::advertise_address: "%{facts.networking.interfaces.enp0s8.ip}"

# we want to showcase cilium here
k8s::server::resources::manage_flannel: false

Worker

k8s::role: 'node'
k8s::master: 'https://controller-0.example.com:6443'
k8s::container_manager: 'containerd'


k8s::manage_firewall: true
k8s::puppetdb_discovery: true

# the same as in k8s::server::resources::bootstrap::secret but prefixed with "puppet."
k8s::node::node_token: "puppet.%{lookup('k8s::server::resources::bootstrap::secret')}"

# for debugging
k8s::node::manage_crictl: true
k8s::install::crictl::config:
  'runtime-endpoint': 'unix:///run/containerd/containerd.sock'
  'image-endpoint': 'unix:///run/containerd/containerd.sock'

k8s::service_cluster_cidr: '10.20.0.0/20' # overlay network for cluster services
k8s::cluster_cidr: '10.20.16.0/20'        # overlay network for the pods in the cluster

Shared data

lookup_options:
  k8s::server::resources::bootstrap::secret:
    convert_to: Sensitive

# Sensitive[Pattern[/^[a-z0-9]{16}$/]]
k8s::server::resources::bootstrap::secret: 'a23456789bcdefgh'

If this setup is deployed like that, we can now deploy cilium.

Initialize cilium

⚠️ All steps here are done on one of the controllers.

Download the cilium binary. This is not included in the module yet. Most likely you also need some configuration then for cilium. So create a cilium-values.yaml

Taken from the cilium quick installation

CILIUM_CLI_VERSION=$(curl -s https://raw.githubusercontent.com/cilium/cilium-cli/master/stable.txt)
CLI_ARCH=amd64
if [ "$(uname -m)" = "aarch64" ]; then CLI_ARCH=arm64; fi
curl -L --fail --remote-name-all https://github.com/cilium/cilium-cli/releases/download/${CILIUM_CLI_VERSION}/cilium-linux-${CLI_ARCH}.tar.gz{,.sha256sum}
sha256sum --check cilium-linux-${CLI_ARCH}.tar.gz.sha256sum
sudo tar xzvfC cilium-linux-${CLI_ARCH}.tar.gz /usr/local/bin
rm cilium-linux-${CLI_ARCH}.tar.gz{,.sha256sum}

The cilium-values.yaml

---
k8sServiceHost: controller-0.example.com
k8sServicePort: 6443
autoDirectNodeRoutes: true
rollOutCiliumPods: true
kubeProxyReplacement: strict
tunnel: disabled
ipv4NativeRoutingCIDR: 10.20.16.0/20 # overlay network for the pods in the cluster
priorityClassName: system-cluster-critical
ipam:
  mode: kubernetes
nodePort:
  enabled: true
  directRoutingDevice: ens192
bpf:
  clockProbe: true
  masquerade: true
  tproxy: true
loadBalancer:
  mode: hybrid
  algorithm: maglev
  hashSeed: uWul3Twb7mKCmNSN
hubble:
  relay:
    enabled: true
    rollOutPods: true
  ui:
    enabled: true
    rollOutPods: true
operator:
  rollOutPods: true
  prometheus:
    enabled: true
hostPort:
  enabled: true
ipv4:
  enabled: true
ipv6:
  enabled: true
socketLB:
  enabled: true
prometheus:
  enabled: true

Before running the cilium install, check if all worker nodes are connected to the cluster. They may be in a NotReady state, but this is okay for now.

# kubectl get nodes

NAME                   STATUS     ROLES    AGE   VERSION
worker-1.example.com   NotReady   <none>   83s   v1.26.4
worker-2.example.com   NotReady   <none>   83s   v1.26.4

Installing cilium with the values:

cilium install --version v1.13.2 --helm-values /path/to/cilium-values.yaml

ℹ️  Using Cilium version 1.13.2
🔮 Auto-detected cluster name: default
🔮 Auto-detected datapath mode: tunnel
🔮 Auto-detected kube-proxy has not been installed
ℹ️  Cilium will fully replace all functionalities of kube-proxy
ℹ️  helm template --namespace kube-system cilium cilium/cilium --version 1.13.2 --set autoDirectNodeRoutes=true,bpf.clockProbe=true,bpf.masquerade=true,bpf.tproxy=true,cluster.id=0,cluster.name=default,encryption.nodeEncryption=false,hostPort.enabled=true,hubble.relay.enabled=true,hubble.relay.rollOutPods=true,hubble.ui.enabled=true,hubble.ui.rollOutPods=true,ipam.mode=kubernetes,ipv4.enabled=true,ipv4NativeRoutingCIDR=10.20.16.0/20,ipv6.enabled=true,k8sServiceHost=localhost,k8sServicePort=6443,kubeProxyReplacement=strict,loadBalancer.algorithm=maglev,loadBalancer.hashSeed=uWul3Twb7mKCmNSN,loadBalancer.mode=hybrid,nodePort.directRoutingDevice=enp0s8,nodePort.enabled=true,operator.prometheus.enabled=true,operator.replicas=1,operator.rollOutPods=true,priorityClassName=system-cluster-critical,prometheus.enabled=true,rollOutCiliumPods=true,serviceAccounts.cilium.name=cilium,serviceAccounts.operator.name=cilium-operator,socketLB.enabled=true,tunnel=disabled
ℹ️  Storing helm values file in kube-system/cilium-cli-helm-values Secret
🔑 Created CA in secret cilium-ca
🔑 Generating certificates for Hubble...
🚀 Creating Service accounts...
🚀 Creating Cluster roles...
🚀 Creating ConfigMap for Cilium version 1.13.2...
🚀 Creating Agent DaemonSet...
🚀 Creating Operator Deployment...
⌛ Waiting for Cilium to be installed and ready...
✅ Cilium was successfully installed! Run 'cilium status' to view installation health

Now all worker nodes should be in a Ready state.

kubectl get nodes

NAME                   STATUS   ROLES    AGE   VERSION
worker-1.example.com   Ready    <none>   5m    v1.26.4
worker-2.example.com   Ready    <none>   5m    v1.26.4

cilium status

    /¯¯\
 /¯¯\__/¯¯\    Cilium:          OK
 \__/¯¯\__/    Operator:        OK
 /¯¯\__/¯¯\    Hubble Relay:    disabled
 \__/¯¯\__/    ClusterMesh:     disabled
    \__/

Deployment        cilium-operator    Desired: 1, Ready: 1/1, Available: 1/1
DaemonSet         cilium             Desired: 1, Ready: 1/1, Available: 1/1
Containers:       cilium             Running: 1
                  cilium-operator    Running: 1
Cluster Pods:     1/1 managed by Cilium
Image versions    cilium             quay.io/cilium/cilium:v1.13.2@sha256:85708b11d45647c35b9288e0de0706d24a5ce8a378166cadc700f756cc1a38d6: 1
                  cilium-operator    quay.io/cilium/operator-generic:v1.13.2@sha256:a1982c0a22297aaac3563e428c330e17668305a41865a842dec53d241c5490ab: 1

After successfully installing cilium, we can now disable kube-proxy. We don't need it anymore. Therefor set on the controller the following key and value.

k8s::server::resources::kube_proxy::ensure: absent

Forem: Robert Waffen

How to keep your Puppet modules up to date with Renovate

Why Renovate?

Assumptions

Setting Up Renovate

Create a Renovate Runner Repository

Add GitLab CI Configuration

Running Renovate

Authentication: RENOVATE_TOKEN

Choosing the Right Container Image

Vulnerability Scan (grype)

Final Thoughts

🧩 Puppet Module Update Process

🔍 1. Identify and Analyze the Module

📝 2. Review Changes in the Module

⚠️ 3. Watch for Breaking Changes

🔍 4. Evaluate Other Changes

🌱 5. Integrate into Development Branches

🌲 6. Control Repo Branch Structure

🧪 7. Testing in Development Environment

🔄 8. Forward the Change

🤖 9. Automation with Renovate Bot

🧰 10. Automation with VoxBox

🧩 Puppet Modul Update Prozess

🔍 1. Modul identifizieren und analysieren

📝 2. Änderungen im Modul prüfen

⚠️ 3. Auf Breaking Changes achten

🔍 4. Sonstige Änderungen bewerten

🌱 5. Aufnahme in Entwicklungszweige

🌲 6. Branch-Struktur im Control-Repo

🧪 7. Tests in Entwicklungsumgebung

🔄 8. Change weiterreichen

🤖 9. Automatisierung mit Renovate Bot

🧰 10. Automatisierung mit VoxBox

All the Vox Pupuli containers

OpenVox containers

openvoxserver

openvoxdb

openvoxagent

Vox Pupuli containers

voxbox

r10k

semantic-release

commitlint

puppet-catalog-diff-viewer

puppetboard

Conclusion

New container names for puppetserver and puppetdb

Vox Pupuli Elections voting period

What it means to be a PMC member

Vox Pupuli is now also on dev.to

Puppet und Kubernetes

Puppet Modul Auswahl

Puppet-K8S Modul

Kubernetes controller (apiserver, controller-manager und scheduler)

Kubernetes worker (kubelet)

Beispiel für containerd und bridge networking

Controller

Worker

Shared data

Beispiel für containerd und cilium

Controller

Worker

Shared data

Initialize cilium

Weitere Dokumentation

Puppet and Kubernetes

Puppet Module selection

Puppet-K8S Module

Kubernetes controller (apiserver, controller-manager and scheduler)

Kubernetes worker (kubelet)

Example for containerd as cri and bridge networking as cni

Controller

Worker

Shared data

Example data for containerd as cri and cilium as cni

Controller

Worker

Shared data

Initialize cilium

Authentication: `RENOVATE_TOKEN`