DEV Community: betadots

DevConf Tag 2

Marcus — Sat, 20 Jun 2026 07:43:19 +0000

Es ist 9Uhr morgens und der Kaffeestand hat mich vertröstet mit den Worten "Wir sind geschlossen, Eröffnung ist 09:30Uhr"

Unter dem einzigen schattenspenden Baum im Hof sammeln sich die Konferenzteilnehmer.

Ich habe mir einen glibc-Workshop und einen Quadlets-Workshop vorgenommen.

glibc-Workshop

Bild: A duck for a bug.

Aufgabe war: Ich habe hier 20 einfache Bugs in glibc heraus gesucht. Wir haben hier drei Mentoren, die an der glibc gearbeitet haben. Ich werde die Bugs jetzt an die Teilnehmer versteigern und wer als erster einen Patch einreicht, gewinnt die Ente.

Der Leiter scherzte noch: Mich hat die Vorbereitung acht Stunden gekostet. Wenn auch nur einer von euch dran bleibt und weiter Patches einreicht, habe ich ein beeindruckendes Verhältnis zwischen Aufwand und Nutzen erreicht. :-)
Leider ist glibc nicht so ruhmreich wie der Kernel und hat keine Vollzeitentwickler.

Podman-Quadlets Workshop

https://codeberg.org/inknos/DevConf26/src/branch/main/demo/01_wordpress/03/README.md

Die Demos waren schön und zeigen, wie man von Docker-Compose auf Podman kommt oder von Quadlets auf Kubernetes oder von Kubernetes auf Quadlets. Quadlets haben Potential, wenn sie etwas Liebe erfahren.

Podman Quadlets funktionieren unter Debian nicht. Dafür habe ich mit einem der RedHat-Entwickler gemeinsam einen Bug-Report erstellt. Am Workshop teilgenommen habe ich mit einer Fedora-VM.
Der Theorie nach bringt Podman in Form von podman machine init und podman machine start eine VM mit, die quadletfähig sein soll, aber die ist unter Debian ebenfalls defekt.

DevConf: Tag 1

Marcus — Thu, 18 Jun 2026 07:54:44 +0000

Die Genese der DevConf: RedHat hat seinen europäisches Hauptquartier in Brno/Tschechien.

Möchtest du life mitschauen? https://www.youtube.com/@DevConfs

Ich möchte die vergangenen Vorträge dokumentieren:

09:00 Einleitung:

Wenn ihr zum ersten Mal hier seid, nehmt die Karte und probiert die Räume ohne Hilfe zu finden https://www.devconf.info/cz/map/

09:30 CVE-Vortrag. RedHat hat ein Rolling-Container-Release mit AI gebaut, sie nennen es "Hummingbird".
"If you have to explain it [CVEs to your manager], you have already lost"
Publikumsfrage: Was ist der Unterschied zwischen Hummingbird und Renovate? -- Beide lösen das gleiche Problem, Hummingbird benutzt Renovate im Hintergrund.

10:15 bpftrace Viktor@RedHat
Ich habe mich spontan daran erinnert, warum ich BPF-Trace verworfen habe. Es hat ein paar sehr nischige High-Level-Anwendungsfälle. Der Maintainer hat das Acknowledged und kündigt Erweiterungen an:

Macros
Libraries and Imports
C-Interoperation

11:00 HTTP3 und Quick Evolution
https://www.goodreads.com/quotes/215637-simplicity-is-a-great-virtue-but-it-requires-hard-work

OpenVox rootless Alpine Containers

Robert Waffen — Fri, 12 Jun 2026 13:42:44 +0000

Over the last weeks, I spent a lot of my Open Source time at betadots GmbH working on improving the OpenVox containers.

The result: both openvoxserver and openvoxdb are now regularly published as Ubuntu and Alpine based container images 🎉

The PRs

This may sound like a small packaging change at first glance, but it actually opens the door for several different deployment styles and operational preferences.

Some users prefer Ubuntu based images for compatibility, familiarity and enterprise environments. Others want the smaller Alpine footprint, faster pulls and a more minimal runtime environment.

How I got there

Building the Alpine containers was a significant challenge because we don’t have packages here. Building Alpine packages would have been another nightmare to solve. So, I looked into the build scripts for the Ubuntu/RHEL packages and extracted all the necessary steps to get the server running. Ideally, I thought, "That’s only a JAR, how complicated can this be? Containers are made for running JARs!" But I couldn’t have been further from the truth. The OpenVox JARs are not self-running and depend on a lot of files and directories being in the right place. Getting this working was a bit of a hassle! But in the end, I got all the steps together, and the containers were building and even starting! They were working! Then, I had to do it rootless. So, we figured out every place where a chmod or chown is made and got this out of the starting process. It wasn’t easy! But we solved it in the end. With much help from the community!

Rootless containers in detail 🥷🐳

One particularly exciting part: the Alpine images are already fully rootless.

That means they are prepared to run without root privileges inside the container, improving the security posture and aligning better with modern container best practices.

The Ubuntu variants are expected to follow soon as the remaining changes are being worked on.

Rootless containers are one of those things that feel a bit like upgrading from telnet to SSH. Once the ecosystem is ready for it, going back feels strange.

Community powered Open Source ❤️

Even though I implemented most of the changes during my Open Source time at betadots GmbH, this was absolutely not a solo effort.

There were reviews, discussions, testing, feedback and many tiny details coming from the OpenVox community. Open Source thrives when individuals collectively contribute their ideas, refining them until the final product surpasses the original draft.

Huge thanks to everyone involved 🙌

Why this matters

Infrastructure projects are often built from many small building blocks:

container images
CI pipelines
packaging
runtime security
multi-distro support
rootless compatibility

Individually, these changes may seem minor.

But together they make the ecosystem more flexible, more secure and easier to integrate into different environments, from homelabs to enterprise deployments.

What’s next?

There is still more work ahead around rootless support, image hardening and ecosystem improvements, but this is another nice milestone for OpenVox containers.

Feedback, testing and contributions are always welcome.

Open Source is still one of the few places where random people on the internet collectively assemble giant infrastructures out of YAML, shell scripts and sleep deprivation 🤖✨

Cheers, Robert

puppet-checkmk dusted off 🧹🦊

Marcus — Fri, 12 Jun 2026 08:47:43 +0000

VoxPupuli's puppet-checkmk [1][2] had become invisible on the Puppet Forge. [3] The Forge has a simple filter: No updates for a long time? Hide it!

Since we hadn't put out a release in a while, we got dropped off the Forge. We've fixed that: dusted off the metadata and added modern operating systems (RedHat-10, Debian-13) to the test matrix.

As sysadmins may guess, there were some quirks with EPEL. I am looking at you, Oracle Linux! ;-) [4]

[1] https://github.com/voxpupuli/puppet-check_mk
[2] https://forge.puppet.com/modules/puppet/check_mk/readme
[3] https://forge.puppet.com/modules?q=check_mk
[4] https://github.com/voxpupuli/puppet-nginx/blob/master/spec/spec_helper_acceptance.rb#L5-L13

puppet-checkmk entstaubt 🧹🦊

Marcus — Fri, 12 Jun 2026 08:47:42 +0000

VoxPupulis puppet-checkmk [1][2] war in der Puppet-Forge unsichtbar geworden. [3]
Die Forge hat einen schlichten Filter: >FIXNUM Zeit kein Update erhalten? Ausblenden!

Wei wir schon lange kein Release mehr veröffentlicht haben, sind wir aus der Forge gefallen. Wir haben das behoben: Metadaten entstaubt und moderne Betriebssysteme (RedHat-10, Debian-13) in die Test-Matrix eingefügt.

In guter Sysadmin-Gewohnheit gab es Freude mit EPEL. Du bist gemeint, Oracle-Linux! ;-) [4]

Puppet Enterprise - Neue Releases und Upgrade Zyklen

Martin Alfke — Wed, 08 Apr 2026 13:59:44 +0000

Bisher gab es bei Puppet Enterprise 2 unterschiedliche Support Releases:

LTS - Long Term Support und
STS - Standard (oder Short) Term Support

Die LTS Releases hatten üblicherweise 2 bis 3 Jahre Support, bevor man ein Upgrade durchführen musste.
Bei STS Releases bezog sich der Support nur auf das jeweils letzte Release.

Mit Puppet Enterprise 2026 (Release ist angekündigt für August 2026) hat Perforce die Support Matrix überarbeitet.
Der neue Support Zyklus wird als Latest / Latest-1 bezeichnet.

In diesem Posting werden die wesentlichen Unterschiede dargestellt und was man in Zukunft bei der Nutzung von Puppet Enterprise berücksichtigen sollte.

Latest

Mit Latest wird das jeweils aktuelle Puppet Enterprise Major Release bezeichnet.
Aktuell ist dies das letzte Release von PE 2025.

Mit dem Release von PE 2026, wird PE 2026 das Latest Support Release.

Latest Releases haben einen vollständigen Support über einen Zeitraum von 12 Monaten.
Innerhalb dieses Zeitraumes sind neue Features und Verbesserungen, Sicherheitsupdates und Fehlerkorrekturen im Support verfügbar.

Danach gibt es in der Folge Minor Releases, die vierteljährlich zur Verfügung gestellt werden.

Latest-1

Als Latest-1 wird das jeweilige vorherige Release bezeichnet, nachdem eine neue Major Version veröffentlicht wurde.

Wenn PE 2026 released wird, wird das PE 2025 Release zu Latest-1.

Latest-1 Releases haben einen eingeschränkten Support über einen Zeitraum von 12 Monaten.
Innerhalb dieses Zeitraumes sind nur Sicherheitsupdates und Fehlerkorrekturen im Support verfügbar.

aktuelles LTS Releases

Das aktuelle LTS Release von Puppet Enterprise ist die Version 2023.8.
Mit dem Release von PE 2026 wird diese Version nicht mehr unterstützt.

Alle anderen älteren Puppet Enterprise Releases sind nicht mehr im Support enthalten.
Wenn eine ältere Puppet Enterprise Version als PE 2025 im Einsatz ist, sollte unbedingt ein Upgrade geplant und durchgeführt werden. Welche Upgrades möglich sind, ist in der Dokumentation zu Puppet Enterprise Upgrades hinterlegt.

Releases und Support Zeitraum

Stand 08.04.2026

PE Version	Support Beginn	Support Name	Support Umfang	Support Ende
2023.8.x	aktuell	LTS	Vollständiger Support	08/2026
2023.8.x	08/2026	LTS	eingeschränkter Support	02/2027
2025.x	aktuell	Latest	Vollständiger Support	08/2026
2025.x	08/2026	Latest-1	eingeschränkter Support	08/2027
2026.x	08/2026	Latest	Vollständiger Support	??/2027
2026.x	??/2027	Latest-1	eingeschränkter Support	??/2028
2027.x	??/2027	Latest	Vollständiger Support	??/2028
2027.x	??/2028	Latest-1	eingeschränkter Support	??/2029
2028.x	??/2028	Latest	Vollständiger Support	??/2029

Zusammenfassung

Perforce entwirrt und standardisiert die Support Zyklen.
Mit den jährliche Major Releases und definierten Zeiträumen für den eingeschränkten Support können Kunden innerhalb von 24 Monaten ein Update durchführen, ohne den Support zu verlieren.

Bei der Vorbereitung und Durchführung von Updates unterstützen wir unsere Kunden gern.

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

Das neue Puppet Open Source Projekt heißt "OpenVox"

Martin Alfke — Tue, 28 Jan 2025 15:00:38 +0000

Puppet by Perforce hat angekündigt,
dass die Open Source Pakete ab 2025 nur noch nach Zustimmung einer nicht weiter definierten EULA verfügbar gemacht werden sollen.

In early 2025, Puppet will begin to ship any new binaries and packages developed by our team to a private, hardened, and controlled location. Community contributors will have free access to this private repo under the terms of an End-User License Agreement (EULA) for development use.

Dabei muss berücksichtigt werden, dass die kostenfreie Variante nur für maximal 25 Nodes gilt.
Wer mehr Systeme mit Puppet Open Source verwalten will, benötigt eine Puppet Labs Support Commercial License.

Die Open Source Community hat das Gespräch mit dem Puppet Management gesucht.

Hier das Resultat:

Das neue Puppet Open Source Projekt heißt OpenVox
- Vorbereitung
- Aus Puppet wird OpenVox und Puppet Open Source
- Source Code, Pakete und Container
- Ich nutze Puppet Open Source. Was muss ich tun?
- Puppet Open Source
- OpenVox
- Die weitere Entwicklung
- Wie kann man helfen?
- Professioneller Support
- Zusammenfassung

Vorbereitung

Vor dem ersten Gespräch mit Puppet hat sich die Community im Vorfeld besprochen und analysiert, ob man als Open Source Projekt in der Lage sein kann, die weitere Entwicklung zu stemmen.
Das Feedback aus der Open Source Community und von Open Source Usern war sehr positiv.

Einige Nutzer haben sogar direkt angekündigt, dass man Entwickler für dedizierte Aufgaben zur Verfügung stellen möchte.

Aus Puppet wird OpenVox und Puppet Open Source

Die Open Source Community hat sich mit Puppet by Perforce darauf geeinigt, dass die weitere Entwicklung von Puppet in einem Fork unter der Verwaltung der Open Source Community erfolgen soll.

Nach einer öffentlichen Abstimmung Ende 2024 innerhalb der Community, hat man sich für den Namen OpenVox entschieden und beschlossen, dass die Entwicklung innerhalb der bereits existierenden Vox Pupuli Puppet Open Source Community auf GitHub stattfinden soll.

Da Perforce die Namensrechte an Puppet besitzt, hat man gemeinsam mit Perforce entschieden, dass die Pakete, die durch das OpenVox Projekt erstellt werden, nicht mehr Puppet im Namen haben sollen.
Dies ist auch in Hinsicht auf Differenzierbarkeit der Herkunft der Pakete sinnvoll.
Die Open Source Pakete von Perforce werden weiterhin puppet-agent, puppetdb und puppetserver heißen.

Gemeinsam mit Perforce wurde vereinbart, dass man sowohl die Kommandozeile, wie auch Namen der Konfigurationsdateien und die Schnittstellen zur Erweiterung von Puppet ( /lib/puppet in Modulen) zu existierenden Installation und Code kompatibel halten möchte.

Die weitere Kompatibilität soll durch ein Language Steering Committee sichergestellt werden, in dem alle Beteiligten gemeinsam über Änderungen an der Puppet DSL oder Inkompatibilitäten entscheiden.

Source Code, Pakete und Container

Der frei verfügbare Puppet Open Source Code wurde in das OpenVox GitHub Projekt geforkt.

Im ersten Schritt hat das Re-branding stattgefunden.
Für Anwender ist es wichtig zu wissen, dass Kommandozeilen Tools, Bibliotheken und Puppet Erweiterungen auch unter OpenVox vollständig kompatibel zu Puppet Open Source sind.

Aktuell werden die Pipelines zur Erstellung der RedHat und Debian Pakete auf öffentliche GitHub Actions umgestellt und sollen sehr bald zur Verfügung gestellt werden.
Erste reproduzierbare Build wurden bereits getetstet.
Pakete für Windows und MacOS sind ebenfalls geplant.

Die Puppet Container (puppetserver und puppetdb) werden nicht mehr weiter gepflegt!

Statt dessen werden OpenVox Container zur Verfügung gestellt. Aktuell wird an OpenVox Server und OpenVoxDB gearbeitet.

Ich nutze Puppet Open Source. Was muss ich tun?

Es gibt 2 Möglichkeiten:

Puppet Open Source
OpenVox

Puppet Open Source

Man muss bei Puppet die EULA akzeptieren und sich ab 25 Nodes um eine Lizenz kümmern.

OpenVox

Die Installations-Anleitung für die Migration findet man auf der
OpenVox Projekt Seite.

Da die Konfigurationspfade und -dateien, sowie die Kommandos alle identisch sind, muss keine weitere Anpassung oder Umstellung vorgenommen werden.
Auch der existierende Puppet Code funktioniert ohne Anpassungen.

Nutzer von OpenVox werden gebeten die aktuellen Pakete und Container in einer Testumgebung zu validieren.

Die weitere Entwicklung

Es gibt eine ganze Reihe von Wünschen aus der Community, die bisher leider nicht umgesetzt wurden.
Zuerst möchte man aktuelle Betriebssystemversionen unterstützen. Hierbei hatte die Community oft nach Paketen für Debian stable und testing gefragt.

Im nächsten Schritt soll der Code von alten Artefakten befreit werden.
Nicht mehr gepflegte Ruby Erweiterungen sollen durch moderne Implementierungen ersetzt werden.
Der Code Zoo (Jruby, Clojure, Java) soll aufgeräumt werden.

Wie kann man helfen?

Die Puppet Community möchte sich als Professionelles Open Source Projekt etablieren.
Dazu sucht man die finanzielle Unterstützung von Usern, Firmen und öffentlichen Einrichtungen für Open Source Arbeit.

Auch individuelle Zuarbeit ist gerne gesehen. Es muss Dokumentation geschrieben werden, die Pakete müssen getestet werden.
Die Community braucht die Unterstützung der Anwender, sei es durch Zuarbeit, Code Reviews oder Bug Reports.

Im nächsten Schritt benötigt man Spiegel Server, Bandbreite und Storage.

Professioneller Support

Open Source Support ist für viele Kunden ein wichtiger Aspekt bei der Wahl der Mittel.
Für OpenVox gibt es bereits jetzt schon 2 Firmen, die Support anbieten:

Wir von der betadots GmbH unterstützen Kunden bei Planung, Installation, Updates von OpenVox, Puppet Open Source und Puppet Enterprise und kümmern uns um die Weiterbildung der Mitarbeiter im Umfeld von Git und GitLab, Foreman/Katello, Puppet/OpenVox und Linux HA.

In Amerikanischem Raum wird die Firma overlookinfratech Ansprechpartner für OpenVox Support sein.

Weitere Firmen werden auf der Support Übersicht von OpenVox gelistet werden.

Zusammenfassung

OpenVox ist ein drop-in Ersatz für Puppet Open Source.

Die Community hat gezeigt, dass sie den Wunsch nach Weiterentwicklung hat und in der Lage ist diese Arbeiten durchzuführen.

Professioneller Support und Trainings stehen in den USA und in Europa zur Verfügung.

Open Source ist die Basis für den Erfolg vieler Unternehmen. Deshalb: Unterstützt Eure Community.

Für weitere Informationen stehen wir gerne zur Verfügung.

Datacenters need automation

betadots GmbH

The Ruby side of Puppet - Part 3 - Custom Types and Providers

Martin Alfke — Mon, 20 Jan 2025 18:50:29 +0000

This is the final post in a three-part serie, covering the concepts and best practices for extending Puppet using custom facts, custom functions and custom types and providers.

Part 1 explores how to create custom facts, which allow nodes to send information to the Puppet Server.

Part 2 discusses building custom functions to process data or execute specific tasks.

Part 3 (this post) focuses on custom types and providers, allowing you to extend Puppet's DSL and control system resources.

Types are at the core of Puppet’s declarative DSL. Types describe the desired state of the system, targeting specific, configurable parts (sometimes OS-specific). Puppet provides a set of core types, available with any Puppet agent installation.

Some of the core types include:

file
user
group
package
service

Why Create Custom Types and Providers:

There are several reasons to develop custom types and providers:

Avoid relying on the often unreliable or hard-to-maintain exec resources
Manage an application that requires CLI commands for configuration.
Handle configurations with highly specific syntax that existing Puppet types cannot manage (like file or concat).

Content:

General concepts
Types and providers in modules
Type description
Provider implementation
Using custom types in Puppet DSL
Resource API
Summary

General concepts

A custom type consists of two main parts:

Type definiton: This defines how the type will be used in the Puppet DSL.
Provider implementation(s): One or more providers per type define how to interact with the system to manage resources.

Type definition

The type describes how Puppet resources are declared in the DSL. For example, to manage an application’s configuration:

app_config { <setting>:
  ensure   => present,
  property => <value>,
  param    => <app_args>,
  provider => <auth_method>,
}

In the type definition, you typically have a namevar (a key identifier) and mutiple parameters and properties.

Namevar: The key identifying the resource instance in the type declaration.
Properties: These represent something measurable on the target system, such as a user’s UID or GID, or an application’s config value.
Parameters: Parameters influence how Puppet manages a resource but don’t directly map to something measurable on the system. For example, manage_home in the user type is a parameter that affects Puppet’s behavior but isn’t a property of the user account.

The difference between parameters and properties is nicely described on the Puppet Type/Provider development page:

Properties:

"Properties correspond to something measurable on the target system. For example, the UID and GID of a user account are properties, because their current state can be queried or changed. In practical terms, setting a value for a property causes a method to be called on the provider."

Parameters:

"Parameters change how Puppet manages a resource, but do not necessarily map directly to something measurable. For example, the user type’s managehome attribute is a parameter — its value affects what Puppet does, but the question of whether Puppet is managing a home directory isn’t an innate property of the user account."

In our example, the property is the value of the config setting, whereas the parameter specifies application attributes.

Provider implementations

Providers define the mechanisms for managing the state of the resources described by types. They handle:

Determining whether the resource already exists.
Creating or removing resources.
Modifying resources.
Optionally, listing all existing resources of the type.

Types and providers in modules

Custom types and providers are placed within the lib/puppet directory of a module.

The type file is located in lib/puppet/type and named after the resource type (app_config.rb in this case).
Provider implementations go into the lib/puppet/provider directory, inside a subdirectory named after the resource type. Each provider is named according to its provider implementation (e.g., ruby.rb, cli.rb, cert.rb, token.rb, user.rb)

For example:

Type: app_config
Providers:
- cert
- token
- user

# <modulepath>/<modulename>
modules/application/
    \- lib/
        \- puppet/
            |- type/
            |    \- app_config.rb
            \- provider/
                \- app_config/
                    |- cert.rb
                    |- token.rb
                    \- user.rb

Type description

New custom types can be crated using two different API versions.
APIv1 is the old, classic way using getters and setters within the providers.
APIv2 is a new implementation which is integrated into PDK - this implementation is also called Resource API.

In the next section we introduce the APIv1 implementation. The Resource API implementation is handled later in this document.

APIv1

The traditional method uses Puppet::Type.newtype, which defines the type.
It is recommended to add the type documentation into the code.
This allows users to run puppet describe <type> on their system to display the documentation.

# lib/puppet/type/app_config.rb
Puppet::Type.newtype(:app_config) do
  @doc = %q{Manage application config. There are three ways
    to authenticate: cert, token, user. cert is the default
    provider.

    Example:

      app_config: { 'enable_logging':
        ensure   => present,
        value    => true,
      }
  }
  # ... the code ...
end

Management

The most important feature of a type is to add or remove something from the system.
This is usually handled with the ensure property.
To enable ensure, a single line is needed: ensurable

# lib/puppet/type/app_config.rb
Puppet::Type.newtype(:app_config) do
  @doc = %q{Manage application config. There are three ways
    to authenticate: cert, token, user. cert is the default
    provider.

    Example:

      app_config: { 'enable_logging':
        ensure   => present,
        value    => true,
      }
  }
  ensurable
end

Namevar

When declaring the type, one must specify a title - one could refer to this as a type instance identifier.
Usually this reflects for something the type is managing.

user { 'betadots': # <- title
}

The most simple implementation is to add a parameter with the name :name.

# lib/puppet/type/app_config.rb
Puppet::Type.newtype(:app_config) do
  @doc = %q{Manage application config. There are three ways
    to authenticate: cert, token, user. cert is the default
    provider.

    Example:

      app_config: { 'enable_logging':
        ensure   => present,
        value    => true,
      }
  }
  ensurable
  newparam(:name) do
    desc "The app config setting to manage. see app_cli conf --help"
  end
end

Passing the namevar: true key to the parameter is another way to identify a namevar:

newparam(:key, namevar: true) do
  desc 'The app config setting key to manage. see app_cli conf --help'
end

Properties

Next we add the other property. Each property can be validated by its content.
In our demo case we expect a string value.

# lib/puppet/type/app_config.rb
Puppet::Type.newtype(:app_config) do
  @doc = %q{Manage application config. There are three ways
    to authenticate: cert, token, user. cert is the default
    provider.

    Example:

      app_config: { 'enable_logging':
        ensure   => present,
        value    => true,
      }
  }
  ensurable
  newparam(:name) do
    desc "The app config setting to manage. see app_cli conf --help"
  end
  newproperty(:value)do
    desc "The config value to set."
    validate do |value|
      unless value =~ /^\w+/
        raise ArgumentError, "%s is not a valid value" % value
      end
    end
  end
end

Besides this one can provide specific valid values which are validated automatically:

newproperty(:enable) do
  newvalue(:true)
  newvalue(:false)
end

Please note that arrays as property values are validated in a different way:

From Puppet custom types website:

By default, if a property is assigned multiple values in an array:

It is considered in sync if any of those values matches the current value.

If none of those values match, the first one is used when syncing the property.

If all array values should be matched, the property needs the
array_matchingto be set to :all. The default value is :first

newproperty(:flags, :array_matching => :all) do
  # ...
end

Accessing values can be done in two ways:

should for properties, value for parameters
value for both, properties and parameters

We prefer to use the explizit methods as this makes it more clear, whether we deal with a property or a parameter.

Parameters

Parameters are defined in a similar way:

# lib/puppet/type/app_config.rb
Puppet::Type.newtype(:app_config) do
  @doc = %q{Manage application config. There are three ways
    to authenticate: cert, token, user. cert is the default
    provider.

    Example:

      app_config: { 'enable_logging':
        ensure   => present,
        value    => true,
        cli_args => ['-p'], # persistency
      }
  }
  ensurable
  newparam(:name) do
    desc "The app config setting to manage. see app_cli conf --help"
  end
  newproperty(:value) do
    desc "The config value to set."
    validate do |value|
      unless value =~ /^\w+/
        raise ArgumentError, "%s is not a valid value" % value
      end
    end
  end
  newparam(:cli_args, :array_matching => :all) do
    desc "CLI options to use during command execution."
    validate do |value|
      unless value.class == Array
        raise ArgumentError, "%s is not a an array" % value
      end
    end
    defaultto ['-p']
  end
end

Boolean parameters

Parameter which get a bool value should be handled in a different way to avoid code repetition

require 'puppet/parameter/boolean'
# ...
newparam(:force, :boolean => true, :parent => Puppet::Parameter::Boolean)

Automatic relationships

Within the type we can specify soft dependencies between different types.

E.g. the app_cli should use a user which must be available on the system

autorequire(:user) do
  ['app']
end

From now on the new custom type can already be used in Puppet DSL, the compiler will create a catalog but the agent will produce an error, as there are no functional providers.

Agent side prerun evaluation

It is possible to have the agent first check some things prior the catalog will be applied.
This is what the :pre_run_check method can be used for

def pre_run_check
  File.exist?('/opt/app/bin/app.exe') && raise Puppet::Error, "App not installed"
end

Features

When using multiple providers (similar to the package resource) we want to be sure that the provider has all required implementations (features).
A type can require a feature:

# lib/puppet/type/app_config.rb
Puppet::Type.newtype(:app_config) do
  @doc = %q{Manage application config. There are three ways
    to authenticate: cert, token, user. cert is the default
    provider.

    Example:

      app_config: { 'enable_logging':
        ensure   => present,
        value    => true,
        file     => '/opt/app/etc/app.cfg',
        cli_args => ['-p'], # persistency
      }
  }
  ensurable
  # global feature
  # feature :cli, "The cli feature requires some parameters", :methods => [:cli]
  newparam(:name) do
    desc "The app config setting to manage. see app_cli conf --help"
  end
  newproperty(:value) do
    desc "The config value to set."
    validate do |value|
      unless value =~ /^\w+/
        raise ArgumentError, "%s is not a valid value" % value
      end
    end
  end
  # The property config_file must be set when using the cli 
  #   option to configure app.
  # The cli provider will check for a feature.
  newproperty(:file, :required_features => %w{cli}) do
    desc "The config file to use."
    validate do |value|
      unless (File.expand_path(value) == value)
        raise ArgumentError, "%s is not an absolute path" % value
      end
    end
    defaultto: '/opt/app/etc/app.cfg'
  end
  newparam(:cli_args, :array_matching => :all) do
    desc "CLI options to use during command execution."
    validate do |value|
      unless value.class == Array
        raise ArgumentError, "%s is not a an array" % value
      end
    end
    defaultto: ['-p']
  end
end

Provider implementation

Once the type is defined, the provider must handle how the resource is managed. Providers typically implement methods to:

Check if the resource exists (exists?).
Create a new resource (create).
Read existing resource properties (prefetch or a getter)
Modify a resource (flush or a setter).
Delete a resource (destroy).

# lib/puppet/provider/app_config/cli.rb
Puppet::Type.type(:app_config).provide(:cli) do
  desc "The app_config types cli provider."
end

It is also possible to re-use and extend existing providers classes.
Common code can be placed inside a generic provider (lib/puppet/provider/app_config.rb).

# lib/puppet/provider/app_config/cli.rb
Puppet::Type.type(:app_config).provide(:cli, :parent => Puppet::Provider::App_config) do
  desc "The app_config types cli provider reuses shared/common code from app_config.rb."
end

If you want to add shared functionality to multiple providers, you can place your code into the PuppetX module directory: lib/puppet_x/<company_name>/<unique class name>.

# lib/puppet/provider/app_config/cli.rb
require_relative '../../puppet_x/betadots/app_api.rb'
Puppet::Type.type(:app_config).provide(:cli) do
  desc "The app_config types cli provider reuses shared/common code from app_config.rb."
end

A new provider can be created by inheriting from and extending an existing provider:

# lib/puppet/provider/app_config/token.rb
Puppet::Type.type(:app_config).provide(:token, :parent => :api, :source => :api) do
  desc "The app_config types token provideris an extension to the api provider."
end

Additionally one can reuse any provider from any type:

# lib/puppet/provider/app_config/file.rb
Puppet::Type.type(:app_config).provide(:file, :parent => Puppet::Type.type(:ini_setting).provider(:ruby)) do
  desc "The app_config types token provideris an extension to the api provider."
end

Selection of provider

The Puppet Agent must know which provider to use, if multiple providers are present.
You can use of the provider meta parameterr or let providers perform checks to determine if they are valid for the system. The options include:

Check	Example	Description
commands	`commands :app => "/opt/app/bin/app.exe"`	Valid if the command `/opt/app/bin/app.exe` exists. The command can be later used using `:app`.
confine - exists	`confine :exists => "/opt/app/etc/app.conf"`	Valid if the file exists.
confine - bool	`confine :true => /^10\./.match(%x{/opt/app/bin/app.exec version})`	Valid if Version is 10.x
confine - Fact	`confine 'os.family' => :debian`	Valid if the fact value matches
confing - feature	`confine :feature => :cli`	Valid if the provider has the feature
defaultfor	`defaultfor 'os.family' => :debian`	Use this provider as default for Debian-based systems.

Reading and applying configuration

The provider needs the ability to create, read, update and delete individual configuration states (CRUD API).

Each configuration property needs a getter (read) and a setter (modify) method.

# lib/puppet/provider/app_config/cli.rb
#   app_config: { 'enable_logging':
#     ensure   => present,
#     value    => true,
#   }
#
Puppet::Type.type(:app_config).provide(:cli) do
  desc "The app_config types cli provider."

  # confine to existing command
  commands :app => "/opt/app/bin/app.exe"

  def exists?
    @result = app_cli('list').split(%r{\n}).grep(%r{^#{resource[:key]}})
    if @result.length > 1
      raise ParserError, 'found multiple config items found, please fix this'
    end
    return false if @result.empty?
    return true unless @result.empty?
  end

  def create
    app(['set', resource[:name], resource[:value]])
  end

  def destroy
    app(['rm', resource[:name]])
  end

  # getter
  def value()
    @result[0].split[1]
  end

  # setter
  def value=(value)
    app(['set', resource[:name], resource[:value]])
  end
end

It is recommended to also create the instances class method, which can collect all instances of a resource type into a hash.
The namevar is the hash key, which has a hash of paramters and properties as value.

require 'yaml'
def self.instances
  instances = []
  YAML.load(app_cli('list')).each do |key, value|
    attributes_hash = { key: key, ensure: :present, value: value, name: key}
    instances << new(attributes_hash)
  end
  instances
end

Sometimes it is not possible to collect all instances, such as with the file resource. In such cases no instance method is defined.

The instance method is used indirectly be each type when calling prefetch to get the acutal configuration and returns the@property_hash instance variable.

def self.prefetch(resources)
  resources.each_key do |name|
    provider = instances.find { |instance| instance.name == name }
    resources[name].provider = provider if provider
  end
end

This allows the type getter and setter to read an manipulate the instance variable, instead of writing getter and setter methods for each type.
This behavior is added by declaring the mk_resource_methods class method.

Once this is implemented you can run the command puppet resource app_config to retrieve all existing configurations.

Refresh events

In some cases it is required to refresh a resource, for example, to restart a service, remount a mount, or rerun an exec resource. To allow a type/provider to react to a refresh event, it needs special handling.

Within the type the refreshable feature must be activated and a refresh definition is added.

The following examples are taken from puppet service type and provider. The feature describes, which provider definition should be executed upon refresh event.

# lib/puppet/type/services.rb
# ...
  feature :refreshable, "The provider can restart the service.",
    :methods => [:restart]
# ...
  def refresh
    # Only restart if we're actually running
    if (@parameters[:ensure] || newattr(:ensure)).retrieve == :running
      provider.restart
    else
      debug "Skipping restart; service is not running"
    end
  end
# ...

Using custom types in Puppet DSL

Once the custom type and provider are implemented, you can use them in your manifests as follows:

# Type declaration
app_config { 'enable_logging':
  ensure    => present,
  value     => true,
  require   => File['/opt/app/etc/app.cfg'],
  subscribe => Service|'app'|,
}
# Type reference
service { 'app':
  ensure    => running,
  subscribe => App_config['enable_logging'],
}
# Type declaration using lambda and splat operator
$config_hash.each |String $key, Hash $hash| {
  app_config { $key:
    * => $hash,
  }
}
# Virtual or exported resource
@@app_config { 'app_mount':
  ensure => present,
  value  => "${facts['networking']['fqdn']}/srv/app_mount",
  tag    => 'blog',
}
# Resource collector
App_config <<| tag == 'blog' |>>

Resource API

The modern resource API has one limitation: one can not refresh types!
Besides this it also consists of types and providers which must be placed at the same location as the existing implementation.

Resource API Type

The resource API type uses an attributes hash to list all parameters and properties. Within the type key one can use any of the built-in Puppet data types.

# lib/puppet/type/app_config.rb
require 'puppet/resource_api'

Puppet::ResourceApi.register_type(
  name: 'app_config',
  docs: <<-EOS,
      @summary The type to manage app config settings
      @example
      app_config { 'key':
        ensure => present,
        value  => 'value',
      }

      This type provides Puppet with the capabilities to manage our application config
    EOS
  features: []
  attributes: {
    ensure: {
      type:    'Enum[present, absent]',
      desc:    'Whether the setting should be added or removed',
      default: 'present',
    },
    name: {
      type:     'String',
      desc:     'The setting to manage',
      behavior: :namevar,
    },
    value: {
      type: 'Variant[String, Integer, Array]',
      desc: 'The value to set'
    }
  }
)

Respource API Provider

The most simple solution is to make use of the SimpleProvider class.
This provider needs up to 4 defines:

get
create
update
delete

# lib/puppet/provider/app_config/cli.rb
require 'puppet/resource_api/simple_provider'
require 'open3'

class Puppet::Provider::AppConfig::Cli < Puppet::ResourceApi::SimpleProvider
  $app_command = '/opt/app/bin/app.exe'

  # Get: fetching all readable config settings into a hash
  def get(context)
    context.debug('Returning data from command')

    @result = []
    stdout, stderr, status = Open3.capture3('/opt/app/bin/app.exe list')
    raise ParseError "Error running command: \n#{stderr}" unless status.success?
    # Missing error handling. This is just for demo
    @command_result = stdout.split(%r{\n})
    @command_result.each do |line|
      next if line == '---'
      key = line.split(':')[0]
      value = line.split(':')[1].strip
      hash = {
        'ensure': 'present',
        'name': key,
        'value': value,
      }
      @result += [ hash ]
    end
    @result
  end

  # Create: add a new config setting with name and should value
  def create(context, name, should)
    context.notice("Creating '#{name}' with #{should[:value]}")
    _stdout, _stderr, status = Open3.capture3("/opt/app/bin/app.exe set #{name} #{should[:value]}")
    # Missing error handling. This is just for demo
    return true unless status.success?
  end

  # Update: correct an existing setting with name and replace with should value
  def update(context, name, should)
    context.notice("Updating '#{name}' with #{should[:value]}")
    _stdout, _stderr, status = Open3.capture3("/opt/app/bin/app.exe set #{name} #{should[:value]}")
    # Missing error handling. This is just for demo
    return true unless status.success?
  end

  # Delete: remove a config setting
  def delete(context, name)
    context.notice("Deleting '#{name}'")
    _stdout, _stderr, status = Open3.capture3("/opt/app/bin/app.exe rm #{name}")
    # Missing error handling. This is just for demo
    return true unless status.success?
  end
end

Summary

Types and providers are not complex. They basically describe the CRUD behavior of Puppet.
The type defines how to use the Puppet DSL, while the provider controls how to check and handle specific settings.

Please stop using exec for almost anything that is not super simple. In most cases, a simple type and provider will allow better analysis, error handling and control over what is happening. Besides this: custom types and providers execute faster compared to exec type usage - far more faster!

The example application and the working types and providers are available on GitHub:

The app: workshop demo app
The Puppet module with types and providers for the app: workshop demo module

App usage:

# Install APP:
git clone https://github.com/betadots/workshop-demo-app /opt/app
/opt/app/bin/app.exe

# Install Puppet module:
git clone https://github.com/betadots/workshop-demo-module -b ruby_workshop modules/app
# Type API V1
puppet resource app_config --modulepath modules
# Type Resource API
puppet resource app_config2 --modulepath modules

Happy puppetizing,
Martin

Die Ruby-Seite von Puppet - Teil 3 - Benutzerdefinierte Typen und Provider

Martin Alfke — Mon, 20 Jan 2025 18:48:32 +0000

Dies ist der letzte Beitrag in einer dreiteiligen Serie, die die Konzepte und Best Practices für die Erweiterung von Puppet mithilfe von benutzerdefinierten Fakten, benutzerdefinierten Funktionen und benutzerdefinierten Typen sowie Providern behandelt.

Teil 1 untersucht, wie man benutzerdefinierte Fakten erstellt, die es Knoten ermöglichen, Informationen an den Puppet-Server zu senden.

Teil 2 behandelt den Aufbau benutzerdefinierter Funktionen zur Verarbeitung von Daten oder zur Ausführung spezifischer Aufgaben.

Teil 3 (dieser Beitrag) konzentriert sich auf benutzerdefinierte Typen und Provider, mit denen Puppets DSL erweitert und Systemressourcen verwaltet werden können.

Typen stehen im Zentrum der deklarativen DSL von Puppet. Typen beschreiben den gewünschten Zustand des Systems und zielen auf spezifische, konfigurierbare Teile ab (manchmal betriebssystemspezifisch). Puppet bietet eine Reihe von Kern-Typen, die mit jeder Puppet-Agent-Installation verfügbar sind.

Einige der Kern-Typen umfassen:

file
user
group
package
service

Warum benutzerdefinierte Typen und Provider erstellen:

Es gibt mehrere Gründe, benutzerdefinierte Typen und Provider zu entwickeln:

Vermeiden von den oft unzuverlässigen oder schwer zu wartenden exec-Ressourcen.
Verwalten einer Anwendung, die CLI-Befehle zur Konfiguration benötigt.
Handhaben von Konfigurationen mit hochspezifischer Syntax, die bestehende Puppet-Typen nicht verwalten können (wie file oder concat).

Inhalt:

Allgemeine Konzepte
Typen und Provider in Modulen
Typbeschreibung
Provider-Implementierung
Verwendung benutzerdefinierter Typen in der Puppet DSL
Resourcen-API
Zusammenfassung

Allgemeine Konzepte

Ein Typ besteht aus zwei Hauptteilen:

Typdefinition: Diese definiert, wie der Typ in der Puppet DSL verwendet wird.
Provider-Implementierung(en): Ein oder mehrere Provider pro Typ definieren, wie mit dem System interagiert wird, um Ressourcen zu verwalten.

Typdefinition

Der Typ beschreibt, wie Puppet-Ressourcen in der DSL deklariert werden. Zum Beispiel, um die Konfiguration einer Anwendung zu verwalten:

app_config { <setting>:
  ensure   => present,
  property => <value>,
  param    => <app_args>,
  provider => <auth_method>,
}

Typdefinition haben einen Namevar (ein Schlüsselbezeichner) und mehrere Parameter und Properties (Eigenschaften).

Namevar: Der Schlüssel, der die Ressourceninstanz in der Typdeklaration identifiziert.
Properties (Eigenschaften): Diese repräsentieren etwas Messbares im Zielsystem, wie die UID oder GID eines Benutzers oder einen Konfigurationswert einer Anwendung.
Parameter: Parameter beeinflussen, wie Puppet eine Ressource verwaltet, spiegeln jedoch nicht direkt etwas Messbares im System wider. Zum Beispiel ist manage_home im user-Typ ein Parameter, der Puppets Verhalten beeinflusst, aber keine Eigenschaft des Benutzerkontos ist.

Der Unterschied zwischen Parametern und Eigenschaften wird auf der Puppet-Typ/Provider-Entwicklungsseite gut beschrieben:

Properties:

"Eigenschaften entsprechen etwas Messbarem im Zielsystem. Zum Beispiel sind die UID und GID eines Benutzerkontos Eigenschaften, da ihr aktueller Zustand abgefragt oder geändert werden kann. Praktisch bedeutet das, dass das Festlegen eines Wertes für eine Eigenschaft eine Methode im Provider aufruft."

Parameter:

"Parameter ändern, wie Puppet eine Ressource verwaltet, entsprechen jedoch nicht unbedingt direkt etwas Messbarem. Zum Beispiel ist das managehome-Attribut des Benutzertyps ein Parameter – sein Wert beeinflusst, was Puppet tut, aber die Frage, ob Puppet ein Home-Verzeichnis verwaltet, ist keine angeborene Eigenschaft des Benutzerkontos."

In unserem Beispiel ist die Eigenschaft der Wert des Konfigurationseinstellungen, während der Parameter die Anwendungsattribute angibt.

Provider-Implementierungen

Provider definieren die Mechanismen zur Verwaltung des Zustands der durch Typen beschriebenen Ressourcen. Sie behandeln:

Bestimmung, ob die Ressource bereits existiert
Erstellen oder Entfernen von Ressourcen.
Ändern von Ressourcen.
Optional das Auflisten aller vorhandenen Ressourcen des Typs.

Typen und Provider in Modulen

Benutzerdefinierte Typen und Provider werden im Verzeichnis lib/puppet eines Moduls platziert.

Die Typdatei befindet sich in lib/puppet/type und ist nach dem Ressourcentyp benannt (app_config.rb in diesem Fall).
Provider-Implementierungen gehen in das Verzeichnis lib/puppet/provider, in ein Unterverzeichnis, das nach dem Ressourcentyp benannt ist. Jeder Provider ist nach seiner Provider-Implementierung benannt (z.B. ruby.rb, cli.rb, cert.rb, token.rb, user.rb)

Beispiel:

Typ: app_config
Provider:
- cert
- token
- user

# <modulpfad>/<modulname>
modules/application/
    \- lib/
        \- puppet/
            |- type/
            |    \- app_config.rb
            \- provider/
                \- app_config/
                    |- cert.rb
                    |- token.rb
                    \- user.rb

Typbeschreibung

Neue benutzerdefinierte Typen können mit zwei verschiedenen API-Versionen erstellt werden. APIv1 ist die alte, klassische Methode, die Getter und Setter innerhalb der Provider verwendet. APIv2 ist eine neue Implementierung, die in PDK integriert ist – diese Implementierung wird auch als Resource-API bezeichnet.

Im nächsten Abschnitt stellen wir die APIv1-Implementierung vor. Die Implementierung der Ressourcen-API wird später in diesem Dokument behandelt.

APIv1

Die traditionelle Methode verwendet Puppet::Type.newtype, die den Typ definiert. Es wird empfohlen, die Typdokumentation in den Code einzufügen. Dies ermöglicht es den Benutzern, puppet describe <type> auf ihrem System auszuführen, um die Dokumentation anzuzeigen.

# lib/puppet/type/app_config.rb
Puppet::Type.newtype(:app_config) do
  @doc = %q{Verwalten der Anwendungsconfig. Es gibt drei Möglichkeiten
    zur Authentifizierung: Zertifikat, Token, Benutzer. Zertifikat ist der Standard
    Provider.

    Beispiel:

      app_config: { 'enable_logging':
        ensure   => present,
        value    => true,
      }
  }
  # ... der Code ...
end

Verwaltung

Die wichtigste Funktion eines Typs besteht darin, etwas zum System hinzuzufügen oder zu entfernen. Dies wird normalerweise mit der ensure-Eigenschaft behandelt. Um ensure zu aktivieren, ist eine einzige Zeile erforderlich: ensurable

# lib/puppet/type/app_config.rb
Puppet::Type.newtype(:app_config) do
  @doc = %q{Verwalten der Anwendungsconfig. Es gibt drei Möglichkeiten
    zur Authentifizierung: Zertifikat, Token, Benutzer. Zertifikat ist der Standard
    Provider.

    Beispiel:

      app_config: { 'enable_logging':
        ensure   => present,
        value    => true,
      }
  }
  ensurable
end

Namevar

Bei der Deklaration des Typs muss ein Titel angegeben werden – dies könnte man als Typinstanz-Identifikator bezeichnen. In der Regel spiegelt dies wider, wofür der Typ verantwortlich ist.

user { 'betadots': # <- Titel
}

Die einfachste Implementierung besteht darin, einen Parameter mit dem Namen :name hinzuzufügen.

# lib/puppet/type/app_config.rb
Puppet::Type.newtype(:app_config) do
  @doc = %q{Verwalten der Anwendungsconfig. Es gibt drei Möglichkeiten,
    sich zu authentifizieren: Zertifikat, Token, Benutzer. Zertifikat ist der Standard
    Provider.

    Beispiel:

      app_config: { 'enable_logging':
        ensure   => present,
        value    => true,
      }
  }
  ensurable
  newparam(:name) do
    desc "Das Anwendungsconfig-Element, das verwaltet werden soll. Siehe app_cli conf --help"
  end
end

Das Übergeben des Schlüssels namevar: true an den Parameter ist eine weitere Möglichkeit, einen Namevar zu identifizieren:

newparam(:key, namevar: true) do
  desc 'Der Schlüssel des Anwendungsconfig-Elements, das verwaltet werden soll. Siehe app_cli conf --help'
end

Eigenschaften

Als Nächstes fügen wir die andere Eigenschaft hinzu. Jede Eigenschaft kann durch ihren Inhalt validiert werden. In unserem Demo-Fall erwarten wir einen Stringwert.

# lib/puppet/type/app_config.rb
Puppet::Type.newtype(:app_config) do
  @doc = %q{Verwalten der Anwendungsconfig. Es gibt drei Möglichkeiten,
    sich zu authentifizieren: Zertifikat, Token, Benutzer. Zertifikat ist der Standard
    Provider.

    Beispiel:

      app_config: { 'enable_logging':
        ensure   => present,
        value    => true,
      }
  }
  ensurable
  newparam(:name) do
    desc "Das Anwendungsconfig-Element, das verwaltet werden soll. Siehe app_cli conf --help"
  end
  newproperty(:value) do
    desc "Der zu setzende Konfigurationswert."
    validate do |value|
      unless value =~ /^\w+/
        raise ArgumentError, "%s ist kein gültiger Wert" % value
      end
    end
  end
end

Außerdem kann man spezifische gültige Werte angeben, die automatisch validiert werden:

newproperty(:enable) do
  newvalue(:true)
  newvalue(:false)
end

Bitte beachten, dass Arrays als Eigenschaftswerte auf andere Weise validiert werden:

Von der Website Puppet benutzerdefinierte Typen:

Standardmäßig wird eine Eigenschaft, die mehrere Werte in einem Array zugewiesen bekommt:

Als synchron betrachtet, wenn einer dieser Werte dem aktuellen Wert entspricht.

Wenn keiner dieser Werte übereinstimmt, wird der erste Wert beim Synchronisieren der Eigenschaft verwendet.

Wenn alle Array-Werte übereinstimmen sollen, muss die Eigenschaft array_matching auf :all gesetzt werden. Der Standardwert ist :first.

newproperty(:flags, :array_matching => :all) do
  # ...
end

Der Zugriff auf Werte kann auf zwei Arten erfolgen:

should für Eigenschaften, value für Parameter.
value für sowohl Eigenschaften als auch Parameter.

Wir bevorzugen die expliziten Methoden, da dies klarer macht, ob wir es mit einer Eigenschaft oder einem Parameter zu tun haben.

Parameter

Parameter werden auf ähnliche Weise definiert:

# lib/puppet/type/app_config.rb
Puppet::Type.newtype(:app_config) do
  @doc = %q{Verwalten der Anwendungsconfig. Es gibt drei Möglichkeiten,
    sich zu authentifizieren: Zertifikat, Token, Benutzer. Zertifikat ist der Standard
    Provider.

    Beispiel:

      app_config: { 'enable_logging':
        ensure   => present,
        value    => true,
        cli_args => ['-p'], # Persistenz
      }
  }
  ensurable
  newparam(:name) do
    desc "Das Anwendungsconfig-Element, das verwaltet werden soll. Siehe app_cli conf --help"
  end
  newproperty(:value) do
    desc "Der zu setzende Konfigurationswert."
    validate do |value|
      unless value =~ /^\w+/
        raise ArgumentError, "%s ist kein gültiger Wert" % value
      end
    end
  end
  newparam(:cli_args, :array_matching => :all) do
    desc "CLI-Optionen, die während der Befehlsausführung verwendet werden sollen."
    validate do |value|
      unless value.class == Array
        raise ArgumentError, "%s ist kein Array" % value
      end
    end
    defaultto ['-p']
  end
end

Boolean-Parameter

Parameter, die einen booleschen Wert erhalten, sollten auf andere Weise behandelt werden, um Codewiederholungen zu vermeiden.

require 'puppet/parameter/boolean'
# ...
newparam(:force, :boolean => true, :parent => Puppet::Parameter::Boolean)

Automatische Abhängigkeiten

Innerhalb des Typs können wir weiche Abhängigkeiten zwischen verschiedenen Typen angeben.

Beispiel: Das app_cli sollte einen Benutzer verwenden, der im System verfügbar sein muss.

autorequire(:user) do
  ['app']
end

Von nun an kann der neue benutzerdefinierte Typ bereits in Puppet DSL verwendet werden, der Compiler wird ein Katalog erstellen, aber der Agent wird einen Fehler produzieren, da es keine funktionalen Provider gibt.

Vorabprüfung auf der Agentenseite

Es ist möglich, dass der Agent zunächst einige Dinge überprüft, bevor der Katalog angewendet wird. Dafür kann die Methode :pre_run_check verwendet werden.

def pre_run_check
  File.exist?('/opt/app/bin/app.exe') && raise Puppet::Error, "App nicht installiert"
end

Merkmale

Bei der Verwendung mehrerer Provider (ähnlich der Ressourcenpakete) wollen wir sicherstellen, dass der Provider alle erforderlichen Implementierungen (Merkmale - Features) hat. Ein Typ kann ein Merkmal erfordern:

# lib/puppet/type/app_config.rb
Puppet::Type.newtype(:app_config) do
  @doc = %q{Verwalten der Anwendungsconfig. Es gibt drei Möglichkeiten,
    sich zu authentifizieren: Zertifikat, Token, Benutzer. Zertifikat ist der Standard
    Provider.

    Beispiel:

      app_config: { 'enable_logging':
        ensure   => present,
        value    => true,
        file     => '/opt/app/etc/app.cfg',
        cli_args => ['-p'], # Persistenz
      }
  }
  ensurable
  # globales Merkmal
  # feature :cli, "Das CLI-Merkmal erfordert einige Parameter", :methods => [:cli]
  newparam(:name) do
    desc "Das Anwendungsconfig-Element, das verwaltet werden soll. Siehe app_cli conf --help"
  end
  newproperty(:value) do
    desc "Der zu setzende Konfigurationswert."
    validate do |value|
      unless value =~ /^\w+/
        raise ArgumentError, "%s ist kein gültiger Wert" % value
      end
    end
  end
  # Die Eigenschaft config_file muss gesetzt werden, wenn die CLI
  #   Option zur Konfiguration von App verwendet wird.
  # Der CLI-Provider wird nach einem Merkmal suchen.
  newproperty(:file, :required_features => %w{cli}) do
    desc "Die zu verwendende Konfigurationsdatei."
    validate do |value|
      unless (File.expand_path(value) == value)
        raise ArgumentError, "%s ist kein absoluter Pfad" % value
      end
    end
    defaultto '/opt/app/etc/app.cfg'
  end
  newparam(:cli_args, :array_matching => :all) do
    desc "CLI-Optionen, die während der Befehlsausführung verwendet werden sollen."
    validate do |value|
      unless value.class == Array
        raise ArgumentError, "%s ist kein Array" % value
      end
    end
    defaultto ['-p']
  end
end

Provider-Implementierung

Sobald der Typ definiert ist, muss der Anbieter steuern, wie die Ressource verwaltet wird. Anbieter implementieren typischerweise Methoden, um:

Überprüfen, ob die Ressource existiert (exists?).
Eine neue Ressource erstellen (create).
Vorhandene Ressourcenattribute lesen (prefetch oder ein Getter).
Eine Ressource ändern (flush oder ein Setter).
Eine Ressource löschen (destroy).

# lib/puppet/provider/app_config/cli.rb
Puppet::Type.type(:app_config).provide(:cli) do
  desc "Der CLI-Anbieter des app_config-Typs."
end

Es ist auch möglich, bestehende Anbieterklassen wiederzuverwenden und zu erweitern. Gemeinsamer Code kann in einem generischen Anbieter (lib/puppet/provider/app_config.rb) platziert werden.

# lib/puppet/provider/app_config/cli.rb
Puppet::Type.type(:app_config).provide(:cli, :parent => Puppet::Provider::App_config) do
  desc "Der CLI-Anbieter des app_config-Typs verwendet gemeinsamen Code aus app_config.rb."
end

Wenn eine gemeinsame Funktionalität für mehrere Anbieter hinzugefügt werden soll, kann man den Code im Puppet_X-Modulverzeichnis ablegen: lib/puppet_x/<unternehmens_name>/<eindeutiger Klassenname>.

# lib/puppet/provider/app_config/cli.rb
require_relative '../../puppet_x/betadots/app_api.rb'
Puppet::Type.type(:app_config).provide(:cli) do
  desc "Der CLI-Anbieter des app_config-Typs verwendet gemeinsamen Code aus app_config.rb."
end

Ein neuer Anbieter kann erstellt werden, indem er von einem bestehenden Anbieter erbt und diesen erweitert:

# lib/puppet/provider/app_config/token.rb
Puppet::Type.type(:app_config).provide(:token, :parent => :api, :source => :api) do
  desc "Der Token-Anbieter des app_config-Typs ist eine Erweiterung des API-Anbieters."
end

Zusätzlich kann man jeden Anbieter von jedem Typ wiederverwenden:

# lib/puppet/provider/app_config/file.rb
Puppet::Type.type(:app_config).provide(:file, :parent => Puppet::Type.type(:ini_setting).provider(:ruby)) do
  desc "Der Datei-Anbieter des app_config-Typs ist eine Erweiterung des API-Anbieters."
end

Auswahl des Anbieters

Der Puppet-Agent muss wissen, welcher Anbieter zu verwenden ist, wenn mehrere Anbieter vorhanden sind. Man kann den provider-Meta-Parameter verwenden oder die Anbieter Überprüfungen durchführen lassen, um festzustellen, ob sie für das System gültig sind. Die Optionen umfassen:

Überprüfung	Beispiel	Beschreibung
Befehle	`commands :app => "/opt/app/bin/app.exe"`	Gültig, wenn der Befehl `/opt/app/bin/app.exe` existiert. Der Befehl kann später mit `:app` verwendet werden.
Einschränkung - existiert	`confine :exists => "/opt/app/etc/app.conf"`	Gültig, wenn die Datei existiert.
Einschränkung - bool	`confine :true => /^10\./.match(%x{/opt/app/bin/app.exec version})`	Gültig, wenn die Version 10.x ist.
Einschränkung - Fakt	`confine 'os.family' => :debian`	Gültig, wenn der Faktwert übereinstimmt.
Einschränkung - Funktion	`confine :feature => :cli`	Gültig, wenn der Anbieter die Funktion hat.
defaultfor	`defaultfor 'os.family' => :debian`	Anbieter als Standard für Debian-basierte Systeme.

Lesen und Anwenden von Konfigurationen

Der Anbieter benötigt die Fähigkeit, einzelne Konfigurationszustände zu erstellen, zu lesen, zu aktualisieren und zu löschen (CRUD-API).

Jede Konfigurationseigenschaft benötigt eine getter- (lesen) und eine setter- (ändern) Methode.

# lib/puppet/provider/app_config/cli.rb
#   app_config: { 'enable_logging':
#     ensure   => present,
#     value    => true,
#   }
#
Puppet::Type.type(:app_config).provide(:cli) do
  desc "Der CLI-Anbieter des app_config-Typs."

  # Einschränkung auf bestehenden Befehl
  commands :app => "/opt/app/bin/app.exe"

  def exists?
    @result = app_cli('list').split(%r{\n}).grep(%r{^#{resource[:key]}})
    if @result.length > 1
      raise ParserError, 'Mehrere Konfigurationselemente gefunden, bitte beheben Sie dies'
    end
    return false if @result.empty?
    return true unless @result.empty?
  end

  def create
    app(['set', resource[:name], resource[:value]])
  end

  def destroy
    app(['rm', resource[:name]])
  end

  # getter
  def value()
    @result[0].split[1]
  end

  # setter
  def value=(value)
    app(['set', resource[:name], resource[:value]])
  end
end

Es wird empfohlen, auch die instances-Klassenmethode zu erstellen, die alle Instanzen eines Ressourcentyps in einem Hash sammeln kann. Der Namevar ist der Hash-Schlüssel, der einen Hash von Parametern und Eigenschaften als Wert hat.

require 'yaml'
def self.instances
  instances = []
  YAML.load(app_cli('list')).each do |key, value|
    attributes_hash = { key: key, ensure: :present, value: value, name: key}
    instances << new(attributes_hash)
  end
  instances
end

Manchmal ist es nicht möglich, alle Instanzen zu sammeln, z. B. beim file-Ressourcentyp. In solchen Fällen wird keine instance-Methode definiert.

Die instance-Methode wird indirekt von jedem Typ verwendet, wenn prefetch aufgerufen wird, um die aktuelle Konfiguration zu erhalten und die @property_hash-Instanzvariable zurückzugeben.

def self.prefetch(resources)
  resources.each_key do |name|
    provider = instances.find { |instance| instance.name == name }
    resources[name].provider = provider if provider
  end
end

Dies ermöglicht es dem Typ, Getter und Setter zu verwenden, um die Instanzvariable zu lesen und zu manipulieren, anstatt für jeden Typ getter- und setter-Methoden zu schreiben. Dieses Verhalten wird durch die Deklaration der mk_resource_methods-Klassenmethode hinzugefügt.

Sobald dies implementiert ist, kann man den Befehl puppet resource app_config ausführen, um alle vorhandenen Konfigurationen abzurufen.

Refresh-Ereignisse

In einigen Fällen ist es erforderlich, eine Ressource zu aktualisieren (refresh), beispielsweise um einen Dienst neu zu starten, ein Laufwerk erneut zu mounten oder eine Exec-Ressource erneut auszuführen. Damit ein Typ/Anbieter auf ein Aktualisierungsereignis reagieren kann, ist eine spezielle Behandlung erforderlich.

Innerhalb des Typs muss die refreshable-Funktion aktiviert werden, und eine refresh-Definition wird hinzugefügt.

Die folgenden Beispiele stammen vom Puppet service Typ und Anbieter. Die Funktion beschreibt, welche Anbieterdefinition bei einem Aktualisierungsereignis ausgeführt werden soll.

# lib/puppet/type/services.rb
# ...
  feature :refreshable, "Der Anbieter kann den Dienst neu starten.",
    :methods => [:restart]
# ...
  def refresh
    # Nur neu starten, wenn wir tatsächlich laufen
    if (@parameters[:ensure] || newattr(:ensure)).retrieve == :running
      provider.restart
    else
      debug "Neustart überspringen; Dienst läuft nicht"
    end
  end
# ...

Verwendung benutzerdefinierter Typen in Puppet DSL

Sobald der benutzerdefinierte Typ und Anbieter implementiert sind, kann man diesen in Puppet Manifesten wie folgt verwenden:

# Typdeklaration
app_config { 'enable_logging':
  ensure    => present,
  value     => true,
  require   => File['/opt/app/etc/app.cfg'],
  subscribe => Service['app'],
}
# Typreferenz
service { 'app':
  ensure    => running,
  subscribe => App_config['enable_logging'],
}
# Typdeklaration mit Lambda und Splat-Operator
$config_hash.each |String $key, Hash $hash| {
  app_config { $key:
    * => $hash,
  }
}
# Virtuelle oder exportierte Ressource
@@app_config { 'app_mount':
  ensure => present,
  value  => "${facts['networking']['fqdn']}/srv/app_mount",
  tag    => 'blog',
}
# Ressourcen-Sammler
App_config <<| tag == 'blog' |>>

Resourcen-API

Die moderne Ressourcen-API hat eine Einschränkung: Man kann Typen nicht aktualisieren! Außerdem besteht sie aus Typen und Anbietern, die am selben Ort wie die bestehende Implementierung platziert werden müssen.

Ressourcen-API-Typ

Der Ressourcen-API-Typ verwendet einen Attributs-Hash, um alle Parameter und Eigenschaften aufzulisten. Innerhalb des type-Schlüssels kann man jeden der integrierten Puppet-Datentypen verwenden.

# lib/puppet/type/app_config.rb
require 'puppet/resource_api'

Puppet::ResourceApi.register_type(
  name: 'app_config',
  docs: <<-EOS,
      @summary Der Typ zur Verwaltung von App-Konfigurationseinstellungen
      @example
      app_config { 'key':
        ensure => present,
        value  => 'value',
      }

      Dieser Typ bietet Puppet die Möglichkeit, unsere Anwendungsconfig zu verwalten.
    EOS
  features: []
  attributes: {
    ensure: {
      type:    'Enum[present, absent]',
      desc:    'Ob die Einstellung hinzugefügt oder entfernt werden soll',
      default: 'present',
    },
    name: {
      type:     'String',
      desc:     'Die Einstellung, die verwaltet werden soll',
      behavior: :namevar,
    },
    value: {
      type: 'Variant[String, Integer, Array]',
      desc: 'Der Wert, der gesetzt werden soll'
    }
  }
)

Ressourcen-API-Anbieter

Die einfachste Lösung ist die Verwendung der Klasse SimpleProvider. Dieser Anbieter benötigt bis zu 4 Definitionen:

get
create
update
delete

# lib/puppet/provider/app_config/cli.rb
require 'puppet/resource_api/simple_provider'
require 'open3'

class Puppet::Provider::AppConfig::Cli < Puppet::ResourceApi::SimpleProvider
  $app_command = '/opt/app/bin/app.exe'

  # Get: Alle lesbaren Konfigurationseinstellungen in einen Hash abrufen
  def get(context)
    context.debug('Gibt Daten vom Befehl zurück')

    @result = []
    stdout, stderr, status = Open3.capture3('/opt/app/bin/app.exe list')
    raise ParseError "Fehler beim Ausführen des Befehls: \n#{stderr}" unless status.success?
    # Fehlende Fehlerbehandlung. Dies dient nur zur Demo
    @command_result = stdout.split(%r{\n})
    @command_result.each do |line|
      next if line == '---'
      key = line.split(':')[0]
      value = line.split(':')[1].strip
      hash = {
        'ensure': 'present',
        'name': key,
        'value': value,
      }
      @result += [ hash ]
    end
    @result
  end

  # Create: Eine neue Konfigurationseinstellung mit Name und Sollwert hinzufügen
  def create(context, name, should)
    context.notice("Erstelle '#{name}' mit #{should[:value]}")
    _stdout, _stderr, status = Open3.capture3("/opt/app/bin/app.exe set #{name} #{should[:value]}")
    # Fehlende Fehlerbehandlung. Dies dient nur zur Demo
    return true unless status.success?
  end

  # Update: Eine vorhandene Einstellung mit Namen korrigieren und durch den Sollwert ersetzen
  def update(context, name, should)
    context.notice("Aktualisiere '#{name}' mit #{should[:value]}")
    _stdout, _stderr, status = Open3.capture3("/opt/app/bin/app.exe set #{name} #{should[:value]}")
    # Fehlende Fehlerbehandlung. Dies dient nur zur Demo
    return true unless status.success?
  end

  # Delete: Eine Konfigurationseinstellung entfernen
  def delete(context, name)
    context.notice("Lösche '#{name}'")
    _stdout, _stderr, status = Open3.capture3("/opt/app/bin/app.exe rm #{name}")
    # Fehlende Fehlerbehandlung. Dies dient nur zur Demo
    return true unless status.success?
  end
end

Zusammenfassung

Typen und Anbieter sind nicht komplex. Sie beschreiben im Grunde das CRUD-Verhalten von Puppet. Der Typ definiert, wie man die Puppet DSL verwendet, während der Anbieter steuert, wie spezifische Einstellungen überprüft und behandelt werden.

Eine exzessive Nutzung der exec Resource ist zu vermweiden. In den meisten Fällen ermöglicht ein einfacher Typ und Anbieter eine bessere Analyse, Fehlerbehandlung und Kontrolle über das, was passiert. Darüber hinaus: benutzerdefinierte Typen und Anbieter führen schneller aus im Vergleich zur Verwendung des exec-Typs - viel schneller!

Die Beispielanwendung und die funktionierenden Typen und Anbieter aus diesem Posting sind auf GitHub verfügbar:

Die App: Workshop-Demo-App
Das Puppet-Modul mit Typen und Anbietern für die App: Workshop-Demo-Modul

App-Nutzung:

# APP installieren:
git clone https://github.com/betadots/workshop-demo-app /opt/app
/opt/app/bin/app.exe

# Puppet-Modul installieren:
git clone https://github.com/betadots/workshop-demo-module -b ruby_workshop modules/app
# Type API V1
puppet resource app_config --modulepath modules
# Type Resource API
puppet resource app_config2 --modulepath modules

Viel Spaß beim Puppetisieren,

Martin

DEV Community: betadots

DevConf Tag 2

glibc-Workshop

Podman-Quadlets Workshop

DevConf: Tag 1

OpenVox rootless Alpine Containers

The PRs

How I got there

Rootless containers in detail 🥷🐳

Community powered Open Source ❤️

Why this matters

What’s next?

puppet-checkmk dusted off 🧹🦊

puppet-checkmk entstaubt 🧹🦊

Puppet Enterprise - Neue Releases und Upgrade Zyklen

Latest

Latest-1

aktuelles LTS Releases

Releases und Support Zeitraum

Zusammenfassung

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

Das neue Puppet Open Source Projekt heißt "OpenVox"

Vorbereitung

Aus Puppet wird OpenVox und Puppet Open Source

Source Code, Pakete und Container

Ich nutze Puppet Open Source. Was muss ich tun?

Puppet Open Source

OpenVox

Die weitere Entwicklung

Wie kann man helfen?

Professioneller Support

Zusammenfassung

The Ruby side of Puppet - Part 3 - Custom Types and Providers

General concepts

Type definition

Provider implementations

Types and providers in modules

Type description

APIv1

Management

Namevar

Properties

Parameters

Boolean parameters

Automatic relationships

Agent side prerun evaluation

Features

Provider implementation

Authentication: `RENOVATE_TOKEN`