Simplifying Software Integration with Pepr
Defense Unicorns
We help mission-focused heroes solve the world’s biggest software challenges.
(Written by Rob Mengert for Defense Unicorns )
Integrating new software into an enterprise tech stack is tricky business!
You need a deep understanding of the system to configure a new application to work securely with all the other services. When done manually, that's a lengthy process that comes with a high potential for human error.
We saw the high cost of integration and the risk of misconfiguration as problems that could be solved with technology, so we created Pepr!
What is Pepr?
Pepr is an open-source project from Defense Unicorns . It's written in TypeScript and provides a framework for converting Kubernetes-based institutional knowledge into code.
You know that one person on the IT team who everyone relies on because they're the only one who understands everything, and if they get hit by a bus, everyone's screwed? (Let's call them Brent.) What if we took Brent and turned him into code? That's Pepr.
(Nothing against Brent, but he can’t take a vacation, take his dog to the vet, or pick up his kids from school since he’s needed for everything. Let’s codify his knowledge!)
There are three high-level constructs of Pepr: Modules, Capabilities, and Actions
A Pepr Module is a TypeScript project that represents a top-level collection of Capabilities. Modules create MutatingWebhookConfigurations, ValidatingWebhookConfigurations, and a secret that contains the Module code transpiled into JavaScript.
A Pepr Capability is a set of related Actions that produce some type of in-cluster transformation on a Kubernetes object or resource. Capabilities are defined in Modules, and they can either mutate or validate resources. Capabilities contain one or more Actions that are user-defined.
A Pepr Action is a collection of behaviors defined in a single function that acts on a Kubernetes object or resource. Actions are the atomic operations that are performed on Kubernetes resources by Pepr.?An Action can be something simple, like adding a label to an object, or something more complex, like wiring up a Grafana dashboard based on a label. (We'll explore a demo of that later in this article.)
A few quick facts about Pepr. It...
Why use Pepr?
One of Pepr’s most attractive features is its fluent API for writing Actions.
Check this out:
Aside from some TypeScript syntax, it’s practically written in English.?That makes writing Pepr Capabilities a breeze!
We prioritized the developer experience when building Pepr. Autocomplete in VSCode makes framing out new Pepr Capabilities straightforward, and because Pepr is written in TypeScript, the full NPM ecosystem is available to expand its Capabilities.
Ready to try Pepr? Let's get on the keyboard!
This demo will show how to auto-create a dashboard in Grafana based on a label attached to a namespace. This is useful because it allows app teams to create dashboards without involving someone from a Platform team. The setup also means that the admin access required to create the dashboard is restricted to Pepr, and what Pepr can do in the cluster is restrained by how the Capability is written.
领英推荐
The first step is to get the Pepr Capability installed in the cluster.?If you don't have a cluster check out the blog.sh script in the repo to spin up a local cluster. Note: This demo is using DUBBD, which relies on Iron Bank images which are restricted to AMD64 architectures, but Pepr works across architectures both AMD and ARM. From this repo, switch to the pepr-grafana-capability folder and execute the following:
git submodule init
git submodule update
nmp install
npx pepr dev
The last command will generate some output and hang onto the terminal to display the Pepr logs as things happen in the cluster.
At this point, the pepr-grafana-capability exists in the cluster.?The Capability will get the Grafana API key out of a secret in the cluster called grafana-admin-api-key in a namespace called admin-ns-devs-do-not-access. Again, this Capability demonstrates how an app team could configure their own monitoring by just putting a label on their namespace.
The namespace and secret can be deployed from the repo. (Be sure to update it with your key.)
kubectl apply -f demo-stuff/grafana-creds.yaml
The next step is to deploy a workload that causes the Capability to fire.?This Capability has been coded to look for a particular label on a namespace. The repo has a small podinfo Zarf package.? The only thing to note is that there is a manifest for the namespace, which has the label present that the Capability is looking for:
apiVersion: v1
kind: Namespace
metadata:
??name: podinfo
??labels:
????pepr.io/create-grafana-dashboard: Enabled
????istio-injection: enabled
If we look in Grafana, there currently isn’t a dashboard called podinfo:
With that in mind, the next steps are to build and deploy the package:
cd podinfo-package && zarf package create --confirm
zarf package deploy --confirm
This will deploy the podinfo package into the cluster.? Very quickly, a dashboard should be present in Grafana:
It will take a couple of minutes to populate the dashboard.? Clicking in, you should eventually see it populate with data:
Wrapping up...
Pepr was originally conceived as a tool for "auto-wiring" Capabilities into Platform One's Big Bang.
As of the time of writing this article, we've published a...
...and there's a Pepr Module for Prometheus integration in development.
Pepr is still settling into its niche. There are a lot of things that Pepr can do, but we're still learning and sorting out what Pepr should do. Can Pepr be a full-fledged policy engine??Sure! Should it be? ...Maybe? ... Maybe not?
Our goal is not to replace other tools in the ecosystem. (We love integrating and playing along with others!) Our goal is to always get mission capabilities in the hands of our warfighters ASAP.
Are we on the right track with Pepr? Please let us know!
To learn more about Pepr, visit: https://pepr.dev/