Wir sind eine zertifizierte B Corporation.

Cloud-Native

Data & KI

Produktentwicklung

Resilienz & IT-Security

Leistungen

Arbeitsweise

Projekte

Berlin

Bielefeld

Dortmund

Erfurt

Frankfurt am Main

Hamburg

Karlsruhe

Leipzig

München

Münster

Nürnberg

Solingen

Stuttgart

Standorte

Blog

Softwerker

Fachmedien

Webinare

Events

Wissens-Hub

Unsere Kultur

Kultur & Karriere Podcast

Deine Entwicklung

Jobs

Karriere

Über uns

Aktuelles

Kontakt

International contact

Alle Standorte

Du hast Fragen oder möchtest dich mit mir austauschen? Gern - trag einfach deine Kontaktdaten ein.

Contact Us | Sub-Navi-Kontakt oder Zero Search Hits

Kontakt aufnehmen

Marketing & Community Management

Konntest du keine Einträge zu deinem Thema finden?  

Logo SoftwerkerCast - der IT-Podcast von Techies für Techies

WISSENS-HUB

Community

Softwareentwicklung

Kultur

SoftwerkerCast

Beim SoftwerkerCast gibt es geballtes Wissen für die Ohren aus der bunten Welt der Softwareentwicklung – von A wie API Design bis Z wie Zero Downtime.

SoftwerkerCast: der IT-Podcast von Techies für Techies

Jetzt abonnieren

Du hast Fragen oder möchtest dich zu deinen Herausforderungen austauschen? Gern – trag einfach deine Kontaktdaten ein.

Kontaktanfrage | Sales (allgemein)

Hast du Fragen?

SoftwerkerCast - der IT-Podcast von Techies für Techies

Marco Paga spricht in dieser Folge mit Goetz Markgraf über künstliche Intelligenz in der Softwareentwicklung.

Senior Agile Consultant

SOFTWERKER

SoftwerkerCast Episode 42: KI in der Softwareentwicklung

Als Product Consultant hilft Marc Pudelski Unternehmen dabei, bessere digitale Produkte zu entwickeln. Was das bedeutet, erklärt er in dieser Folge.

SoftwerkerCast Episode 41: Produktstrategie

Nach der ⁠Einführung in Green IT⁠ in der vergangenen Folge haben wir dieses Mal mit Daniel Eichten einen Gast, der das Thema durch die Brille der Enterprise-Architektur betrachtet.

SoftwerkerCast Episode 40: Green IT & Enterprise-Architektur

Green IT – nur ein zeitgeistiger Hype oder 2024 eine Notwendigkeit? Dennis Breitling und Henning Waack zeigen in dieser Folge, welche Bestrebungen unter diesem trendig klingenden Oberbegriff zusammengefasst werden – und dass sie darauf abzielen, nicht nur Energie, sondern auch Kosten zu sparen.
 

IT Consultant

SoftwerkerCast Episode 39: Einführung in Green IT

Sebastian Klatt von der METRO.digital zeigt in dieser Folge, wie so genannte „Recommender-Systeme“ unter der Haube aussehen: Welche Kriterien spielen dabei eine Rolle? Wie geht man vor, wenn man noch gar nichts über den User weiß (Stichwort: Coldstart-Problem)?

SoftwerkerCast Episode 38: Recommender-Systeme unter der Haube – mit Sebastian Klatt (METRO.digital)

ÖPNV – dahinter steckt in diesem Fall nicht der Begriff „Öffentlicher Personennahverkehr“ sondern vielmehr: „Öffentlicher Pflanzennahverzehr“. Was wiederum ein Smart-City-Projekt bezeichnet, das vor einigen Jahren gestartet ist. David Schwarzmann berichtet.

IoT Consultant

SoftwerkerCast Episode 37: Smart City – das digitale Gewächshaus

Niklas Haas und Kamil Braschke geben Einblicke in die aktuellen Entwicklungen rund um Private ChatGPTs und Self-hosted LLMs und werfen einen Blick in die Glaskugel – mit sehr spannenden Prognosen.

Topic Lead GenAI & GenAI Consultant

SoftwerkerCast Episode 36: Custom GPTs und Self-Hosted LLMs

Wo könnte man besser frei und neu denken als draußen in der Natur, außerhalb der Komfortzone? Jörg Schmerbauch gibt Marco Paga Einblicke in seine Arbeit als „Outdoor-Coach“ – und verrät, worauf es bei Einzel- und Teamcoachings in der freien Natur ankommt. 

SoftwerkerCast Episode 35: Walk-Life-Balance – Coaching im Grünen

„Was Hänschen nicht lernt, lernt Hans nimmermehr"? Fehlanzeige! Unsere Weihnachtsfolge ist ein Mut machendes Plädoyer für Beharrlichkeit und den Glauben an sich selbst.

IT-Consultant & Developer

SoftwerkerCast Episode 34: Vom Underdog zum Informatiker mit Bestnoten: Die ganz persönliche Geschichte eines ITlers

Marco Paga spricht mit Julian Arz über WebAssembly, einen offenen W3C-Standard, dessen beide Namensbestandteile „Web“ und „Assembly“ wenig über seine Funktionalität aussagen. WebAssembly kann nämlich noch einiges mehr und hat laut Julian „riesiges Potenzial“. 

SoftwerkerCast Episode 33: WebAssembly: „Riesiges Potenzial“

Mirko Novakovic ist codecentric-Mitgründer und Softwerker-Gründer sowie ehemaliger Softwerker-Herausgeber. In dieser Folge teilt er seine Erfahrungen als Serial Entrepreneur im IT-Umfeld und gibt wertvolle Tipps für Startup-Gründer.

SoftwerkerCast Episode 32: Das Startup-Mindset – mit Mirko Novakovic

Dr. Boris Adryan ist Academic Director, Data & Digital, bei Merck in Darmstadt. Er lehrt dort das Denken in Daten: Während eines zehnwöchigen Schulungsprogramms können sich Merck-Angestellte von ambitionierten Datenanwendern zu „Citizen Data Scientists“ weiterqualifizieren.

SoftwerkerCast Episode 31: Data Literacy und Data Creativity

Unsere Halloween-Folge zeigt euch die Highlights von Micro-Frontends – und entführt euch in ein auditives ⁠Uncanny Valley⁠. Frankenstein oder Geniestreich? Gruselig echt oder echt gruselig? Ihr entscheidet. Keine weiteren Spoiler.

Frontend Developer & Consultant

SoftwerkerCast Episode 30: Halloween-Spezial: Micro-Frontends

Niklas und Kamil geben in dieser Folge Einblicke in die Verwendung von Private ChatGPT und in Prompt Engineering. Weshalb sich Wissensmanagement besonders als Anwendungsfall für Large Language Models eignet thematisieren die beiden Experten ebenso wie die Vorteile von Microsofts Azure AI Services.

SoftwerkerCast Episode 29: Private ChatGPT und Prompt Engineering

Elvira „Ellie“ Siegel hat Machine Learning an der LMU in München studiert und ist Teil des SHERLOQ-Teams, das ein Produkt zur KI-gestützten Dokumentenverarbeitung entwickelt. In dieser Folge ordnet sie den Bereich der großen Sprachmodelle (LLM) in die Welt der künstlichen Intelligenz ein.

Machine Learning Engineer

SoftwerkerCast Episode 28: Large Language Models

Mit welchen Frontend-Technologien sollten sich Backend-Entwicklerinnen und -Entwickler heute mindestens auskennen?
Daniel Zenzes, seines Zeichens Principal Software Engineer bei adesso und ebenfalls Podcast-Host von „Herr Zenzes will's wissen“, verrät in dieser Folge, was die Frontend-Basics sind.

SoftwerkerCast Episode 27: Frontend für Backend Developer

Senior IT Consultant

SoftwerkerCast Episode 26: State of Frontend

SoftwerkerCast Episode 25: Serverless – Public Cloud oder On-Premises?

Senior Solution Architect

SoftwerkerCast Episode 24: Crossplane – Zwischen Multi-Cloud und Platform Engineering

Cloud, Data & Innovation

SoftwerkerCast Episode 23: Data Mesh – DDD für Daten?

Senor IT Consultant

Principal Agile & Product Coach

SoftwerkerCast Episode 22: 5 Hebel für eine kürzere Time-to-Market

IT Consultant / Software Engineer

SoftwerkerCast Episode 21: Service Meshes

Team Lead & Consultant Data/AI

SoftwerkerCast Episode 20: Explainable AI

SoftwerkerCast Episode 19: Daten, AI und Erklärbarkeit 

SoftwerkerCast Episode 18: OpenFGA – Autorisierung leicht gemacht

SoftwerkerCast Episode 17: ChatGPT – Praktische Nutzung

Principal IAM Consultant

SoftwerkerCast Episode 16: Open Policy Agent: Mächtig sicher

SoftwerkerCast Episode 15: ChatGPT – Zwischen Hype, Hate und Halluzination

Principal IT Consultant

Cloud Partner Manager

SoftwerkerCast Episode 14: Platform Engineering XXL

SoftwerkerCast Episode 13: Platform Engineering mit Backstage

Senior Solution Architect / Head of API Consulting

SoftwerkerCast Episode 12: Platform Engineering 101

SoftwerkerCast Episode 11: Wie viel Wissen ist nötig, um Wissen zu teilen?

Standortleitung Dortmund

SoftwerkerCast Episode 10: „Kunde“ – wer ist das? Und wenn ja, wie viele?

SoftwerkerCast Episode 9: IT Security als „everybody's job“

SoftwerkerCast Episode 8: Cloud-Native (mit Lünendonk)

Software Team Enabler

IT Consultant and Software Engineer 

SoftwerkerCast Episode 7: 10x schneller in Softwareprojekten

Full Stack Consultant

SoftwerkerCast Episode 6: Software-Wartung – die vergessene Disziplin

SoftwerkerCast Episode 5: Recruiting in der IT

SoftwerkerCast Episode 4: IT als Beruf UND Hobby?

SoftwerkerCast Episode 3: To Cloud or not to Cloud?

SoftwerkerCast Episode 2: Application Performance … Management oder Monitoring?

SoftwerkerCast Episode 1: Jobs in der IT

SoftwerkerCast: Trailer

Marco Paga

Zu den Ausgaben

Zur SoftwerkerKonf

Stöbert in unserem kostenfreien Fachmagazin für Entwickler und Softwarearchitekten!

Trefft uns auf unserer Online-Konferenz zum Austausch über aktuelle Tech-Themen.

Hier gibt's noch mehr vom Softwerker

Der Softwerker – Das Magazin

SoftwerkerKonf

Unser SoftwerkerCast-Team

Head of Feelgood Management

Senior Community & Content Manager

Schreibt uns

<p>In diesem Artikel möchte ich einen Überblick über Tekton geben mit dem Ziel, die Grundlagen zu erklären und einen schnellen Einstieg zu ermöglichen.</p><p>Tekton möchte laut eigener Homepage der Standard für CI / CD werden. Zum einen bietet es ein Framework, um Cloud-native CI/CD-Systeme in Kubernetes zu bauen und darüber hinaus ein standardisiertes Tooling für diese Systeme. So hat es schon Einzug in Jenkins X gehalten und ist die Basis für <a href="https://cloud.redhat.com/learn/topics/ci-cd" target="_blank">RedHat OpenShift Pipelines</a> .</p><p>Entwickler, die ein CI-System nutzen wollen, profitieren von der breiten Unterstützung, da vorhandene Pipelines und Pipelineschritte ohne Aufwand zwischen den Tekton CI-Implementierungen ausgetauscht werden können.</p><p>Das Tekton-Projekt nutzt Kubernetes als Plattform und stellt im Kern die Building Blocks einer CI Pipeline in Form von CRDs dar. Eine Custom Resource Definition, kurz CRD, ist ein selbst erstelltes Kubernetes-Objekt, das genutzt werden kann, um eigene Objekte innerhalb der Kubernetes API sichtbar und nutzbar zu machen. So finden sich in Tekton Objekte wie z. B. eine <code>Pipeline</code>, die ebendiese abbildet, und durch <code>Tasks</code>, welche die einzelnen Prozessschritte ausführen, ausgestaltet werden können.</p><p>Die gesamte Konfiguration findet dann wie von Kubernetes gewohnt über Manifeste statt. Das vorhandene Kubernetes Know-how kommt hier voll zum Zuge, denn neben der Konfiguration kann auch eine Introspektion der Prozesse über diesen Weg stattfinden.</p><p>Als zentrale Anlaufstelle für durch die Community gepflegte Tasks und Pipelines wird der <a href="https://hub.tekton.dev/" target="_blank">Tekton Hub</a>  angeboten. Dort zu finden sind schon viele Bausteine, um die üblichsten Schritte abzudecken. Zusätzlich zu dem öffentlichen Hub ist es sehr einfach möglich, innerhalb der eigenen Organisation einmal spezifische Lösungen zu implementieren und zuverlässig zu verteilen.</p><p>Neben den Manifesten liefert Tekton natürlich auch die <a href="https://github.com/tektoncd/pipeline" target="_blank">Kubernetes-Operatoren im Tekton Pipelines Repository</a> , welche die konfigurierten Arbeitsschritte ausführen. Wie bei modernen CI-Systemen üblich werden die Build-Schritte innerhalb von Containern ausgeführt.</p><h2>Installation</h2><p>Die Installation erfolgt entweder durch Apply der Kubernetes-Manifeste der Release-Seite oder durch den <a href="https://operatorhub.io/operator/tektoncd-operator" target="_blank">Tekton Operator</a> .</p><p>Der Tekton Operator ist aktuell noch in einer frühen Entwicklungsphase und bietet aktuell die reine Installation. Hinweise zur Konfiguration der Installation sind auf den <a href="https://tekton.dev/docs/operator/" target="_blank">Hilfeseiten</a>  zu finden.</p><p>Die Installation über die Kubernetes-Manifeste ist im <a href="https://tekton.dev/docs/getting-started/">Getting Started Guide</a>  verständlich beschrieben.</p><p>Um schnell eine nutzbare Installation zu haben, empfehle ich die Installation der Pipeline- und der Dashboard-Komponente, die einen visuellen Einblick in die laufende Tekton-Installation bietet. Das Dashboard ist über einen Browser von außen zu erreichen.</p><h2>Ready-to-run-Projekt</h2><p>Im <a href="https://github.com/marcopaga/tekton-demo" target="_blank">Github-Projekt Tekton-Demo</a>  ist eine komplette Installation zu finden, die mit <a href="https://k3d.io/" target="_blank">K3d</a>  direkt auf dem lokal System läuft. Die Installation ist sowohl im README zu finden als auch immer aktuell <a href="https://github.com/marcopaga/tekton-demo/blob/main/.github/workflows/create-cluster.yml" target="_blank">in der GitHub Action</a> .</p><p>Nachdem die Installation erfolgreich durchgelaufen ist, ist das Cluster eine laufende Tekton-Installation mit Tasks und Pipelines, welche im Namespace <code>tekton-pipelines</code> installiert sind. Da man sehr leicht im falschen Namespace schaut, möchte ich nur kurz <code>kubectx</code> und <code>kubens</code> empfehlen, denn <code>kubens tekton-pipelines</code> setzt den default Namespace korrekt.</p><p>Das Dashboard ist über einen Port-Forward erreichbar und ein Eventlistener ist über einen Ingress nutzbar. Es kann auch schon auf Events reagieren, doch dazu kommen wir in einem weiteren Blogartikel.</p><h2>Eine beispielhafte CI Pipeline</h2><p>Nach der Installation können wir auch schon die Hauptkomponenten kennenlernen und mit diesen ein „Hello, World!“-Beispiel aufbauen.</p><p>Ein <code>Task</code> besteht aus einer Serie von <code>Steps</code>, die der Reihenfolge nach ausgeführt werden. Ein <code>Step</code> ist ein in sich abgeschlossenes Kommando, das im folgenden Beispiel Names <code>hello</code>, der Aufruf von <code>echo "Hello World!"</code> ist. Dies wird in einem Bash Container gestartet und ausgeführt, was natürlich auch nach Gusto geändert werden kann.</p><p>Im realen Einssatz finden sich an dieser Stelle Kommandos, die einen Checkout vornehmen, Images bauen und vieles mehr.</p>

```
apiVersion: tekton.dev/v1beta1
kind: Task
metadata:
  name: hello
spec:
  steps:
    - name: hello
      image: bash:latest
      command:
        - echo
      args:
        - "Hello, world!"
```

<p>Ebenfalls ist ein <code>goodbye</code> Task angelegt, der sich durch ein <code>echo</code> Kommando auf der Systemconsole verabschiedet.</p><p>In diesem kleinen Beispiel werden wir eine Pipeline erzeugen, welche die beiden Tasks nacheinander aufruft, damit bei Betrachtung der Pipeline-Logs sowohl die Begrüßung als auch die Verabschiedung anzeigt.</p><p>Sehr intuitiv – wie ich jedenfalls finde – erstellen wir ein CRD vom Typ <code>Pipeline</code> und definieren dort eine Liste von Tasks, die mit Abhängigkeiten untereinander versehen werden können. In diesem einfachen Beispiel geben wir über <code>runAfter</code>an, dass die Verabschiedung nach der Begrüßung stattfinden soll.</p>

```
apiVersion: tekton.dev/v1beta1
kind: Pipeline
metadata:
  name: hello-goodbye-pipeline
spec:
  tasks:
    - name: hello
      taskRef:
        name: hello
    - name: goodbye
      runAfter:
        - hello
      taskRef:
        name: goodbye
```

<p>Der oben definierte <code>Task</code> wird über eine <code>taskRef</code>verlinkt, sodass die definierten Tasks darüber verknüpft werden und die Pipeline die zwei Schritte durchläuft.</p><h2>Interaktion mit Tekton</h2><p>Wie zu Beginn dargestellt arbeitet Tekton über die Konfiguration und Installation von CRDs. Diese API-Objekte können direkt über <code>kubectl</code> abgerufen und manipuliert werden, worüber eine nachvollziehbare API abgebildet wird. Installierte Pipelines können problemlos abgerufen werden:</p>

```
# kubectl get pipelines.tekton.dev --all-namespaces -o wide
NAMESPACE          NAME                     AGE
8
tekton-pipelines   hello-goodbye-pipeline   1s
9
```

<p>Weiterhin ist es natürlich auch möglich, eine Pipeline zu starten. In dem Repository ist ein <code>PipelineRun</code> zu finden, den ich im Folgenden einmal darstelle:</p>

```
apiVersion: tekton.dev/v1beta1
kind: PipelineRun
metadata:
  generateName:  hello-goodbye-pipeline-
spec:
  pipelineRef:
    name:  hello-goodbye-pipeline
```

<p>Die Konfiguration stellt ein Präfix für die erstellten Runs über das <code>generateName</code>-Attribut zur Verfügung. Ebenfalls wird eine Referenz zu der zu verwendeten Pipeline vergeben, welche wir während der Installation erzeugt und uns im Verlauf dieses Artikels angeschaut haben.</p><p>Wie kann eine Pipeline gestartet werden? Jetzt brauchen wir doch noch ein weiteres API-Objekt und zwar den <code>PipelineRun</code>. Dieses Objekt bringt die notwendigen Parameter – in unserem Fall noch keine – in Verbindung mit der auszuführenden Pipeline. Als Nutzer können wir durch Referenz auf den erzeugten Run den Status und auch die Log-Ausgabe abrufen.</p><p>Los geht’s:</p>

```
kubectl create -n tekton-pipelines -f ./hello-goodbye-pipeline-run.yaml
```

<p>Und wie schon angedeutet rufen wir alle Ausführungen ab:</p>

```
kubectl get pipelineruns.tekton.dev --all-namespaces -o wide
NAMESPACE          NAME                             SUCCEEDED   REASON      STARTTIME   COMPLETIONTIME
8
tekton-pipelines   hello-goodbye-pipeline-v5h5l   True        Succeeded   13s         1s
```

<p>Hier erkennbar sind die vorhandenen Statusfelder dieses Objekts. Für das Blackbox-Testing können wir daher auf den Statuswechsel des PipelineRuns auf <code>Succeeded</code> warten, um den Durchlauf einer Pipeline zu erkennen.</p><p>Neben der direkten Interaktion mit <code>kubectl</code> bietet Tekton ein spezialisiertes Command Line Interface (CLI), das direkt über den aktuell genutzten Kubernetes Context mit dem Cluster interagiert. Viele Kubernetes-basierten Tools bringen ein passendes CLI mit, um effizient mit der Plattform zu arbeiten. <code>tkn</code> ist das entsprechende go Binary, was problemlos auf verschiedenen Plattformen lauffähig ist. Eine Installationsanleitung ist über das <a href="https://github.com/tektoncd/cli">GitHub Repository</a>  zu finden.</p><p>Mit diesem CLI ist es dann einfacher möglich z. B. die Tasks und Pipelines abzurufen. Hier ein kurzes Beispiel:</p>

```

tkn task list --all-namespaces
tkn pipeline list --all-namespaces
```

<p>Diese beiden Aufrufe zeigen alle vorhandenen Tasks und Pipelines in allen Namespaces an.</p><p>Die Inspektion der Logs erfolgt über dieses Kommando:</p>

```
tkn pr logs $PIPELINE_RUN_NAME
```

<p>Die Ausgabe aller Tasks wird hier gesammelt, nachvollziehbar ausgegeben und sieht wie folgt aus:</p>

```
[hello : hello] Hello World!

[goodbye : goodbye] Goodbye World!
```

<h2>Fazit</h2><p>Wir haben jetzt mit wenig Aufwand die Installation vorgenommen und auch schon die erste Pipeline erstellt. Damit haben wir schon viel erreicht und konnten den ersten Blick hinter die Kulissen wagen.</p><p>In den folgenden Artikeln werden wir eine Buildpack-Pipeline erstellen und die Build-Pipeline um einen WebHook-Trigger von außen erweitern. Damit kann Tekton automatisch ein Container Image bauen, wenn ein Push in einem Git-Repository getätigt wurde.</p>

Tekton Cloud-Native CI/CD: Ein pragmatisches Intro

<h1>Tekton Triggers in der Praxis</h1><p>Dieser Artikel ist Teil einer Reihe, die sich mit Tekton CI/CD und dem praktischen Einsatz beschäftigt.</p><p>Im <a href="https://blog.codecentric.de/2022/01/tekton-cloud-native-ci-cd-ein-pragmatisches-intro/" target="_blank">ersten Artikel</a>  haben wir die Installation vorgenommen und die erste Pipeline erstellt. Im <a href="https://blog.codecentric.de/2022/02/alles-schon-da-tekton-buildpack-pipeline/" target="_blank">zweiten Artikel</a>  haben wir die Vorteile von Tekton durch den geschickten Einsatz der wiederverwendbaren Komponenten erleben können. Dieser Artikel beschäftigt sich mit der Einbettung von Tekton in einen Projektkontext. Das Ziel für diesen Artikel ist erstmal die Grundlagen dafür zu schaffen. Wir werden mit Tekton Triggers ein WebHook Interface öffnen und ein Gitlab-WebHook-JSON-Objekt schicken, das einen Build in der Tekton-Installation startet.</p><h2>Möglicher Einsatz</h2><p>Was meine ich an der Stelle mit einem „Projektkontext“? Bisher haben wir Tekton in einem isolierten Setup laufen lassen, was in der Praxis nicht hilfreich ist, denn damit geht die Sichtbarkeit auf die eigene Arbeit schnell verloren. Die Gesamtsicht ist über mindestens zwei Systeme verteilt, welche untereinander nicht verknüpft sind. Schlimmer sogar, die Tekton muss bisher manuell gestartet werden.</p><h2>Warum nicht einfach das Integrierte nutzen?</h2><p>Der Trend bei den großen Plattformen wie <a href="https://github.com/" target="_blank">GitHub</a>  oder <a href="https://about.gitlab.com" target="_blank">Gitlab</a>  ist die Integration der Entwicklungstools. Angefangen vom Git Repository über eine Pipeline-Lösung wie <a href="https://github.com/features/actions" target="_blank">GitHub Actions</a> , über das <a href="https://github.blog/2019-05-10-introducing-github-package-registry/" target="_blank">Container Repository</a>  bis hin zur Integration der <a href="https://about.gitlab.com/blog/2018/08/02/4-ways-to-use-gitlab-issue-boards/" target="_blank">Organisationstools</a> . Der dahinterstehende Grund dabei ist die Transparenz zu erhöhen.</p><p>Dem entgegen steht die Nutzung von Tekton für den Aspekt der CI/CD-Ausführung. Sinn ergibt das, wenn der Wunsch der Compliance, Wiederverwendbarkeit und vermeintlicher Zukunftsfähigkeit steigt. Die <a href="https://github.com/tektoncd/community/blob/main/roadmap.md#mission-and-vision" target="_blank">richtungsweisende Vision</a>  ist die API-Kompatibilität in die Breite zu tragen und ein nachhaltiges Öko-System aufzubauen. Dies ist natürlich erstmal der Beginn einer Reise und es bleibt abzuwarten, ob dies realistisch ist. Bei Entscheidungen die das CI/CD-System betreffen ist die Zukunftsfähigkeit aus meiner Sicht ein interessantes Kriterium.</p><p>Schreibt gerne eure Meinung in die Kommentare oder gebt gerne <a href="https://twitter.com/m_p_dus?s=20" target="_blank">per Twitter</a>  Feedback.</p><h2>Triggers Installation</h2><p>Tekton Triggers sind eine weitere Komponente, die im Cluster installiert sein muss. Hierzu können wir der Installationsanleitung im <a href="https://github.com/tektoncd/triggers" target="_blank">GitHub – Projekt folgend</a>  die notwendigen Manifeste einspielen. Im Kapitel „<a href="https://github.com/tektoncd/triggers/blob/main/docs/install.md#setting-up-tekton-triggers" target="_blank">Setting Up Tekton Triggers</a> “ findet man die beiden Dateien, welche über das Tool der Wahl eingespielt werden können.</p><p>Die Datei mit dem Namen release.yaml beinhaltet die gesamte Triggers-Basisinstallation und die interceptors.yaml-Datei bringt <a href="https://tekton.dev/vault/triggers-main/interceptors/#overview" target="_blank">Interceptoren</a>  für die einfache Anbindung von Systemen wie gitlab, github oder bitbucket mit. Diese sollten ebenfalls installiert werden, denn wir werden einen installierten <code>ClusterInterceptor</code> später noch benutzen. Im nächsten Abschnitt beschreibe ich, welchen Zweck diese haben.</p><p>An dieser Stelle der kurze Hinweis, dass die Tekton-Installation inklusive der Tekton Triggers in <a href="https://github.com/marcopaga/tekton-demo" target="_blank">meinem GitHub Projekt</a>  fertig aufgebaut ist. Einfach klonen und testen. Alles Wichtige ist in der README.md oder auch in der github Action zu finden, die den Code bei jedem Push testet. Mehr zu diesem Projekt ist im <a href="https://info.codecentric.de/softwerker-vol-19" target="_blank">Softwerker Vol. 19</a>  zu finden, denn dort beschreibe ich das gesamte Projekt in der Tiefe und zeige die Zusammenhänge auf.</p><h2>Triggers-API-Objekte</h2><p>Die Triggers API sieht auf den ersten Blick sehr kompliziert aus, jedenfalls ist es mir so gegangen. Am besten wir gehen Schritt für Schritt durch und verstehen, wofür das jeweilige Objekt genutzt wird. Hier meine kurze <a href="https://remarkable.com/referral/NT3R-9TVK" target="_blank">Remarkable-Notiz</a>  die mir bei der Orientierung sehr geholfen hat:</p><p><img width="1024" height="1090" src="https://media.graphassets.com/fhVlBFQpQqubKkeJ1JVG" alt /></p><h3>EventListener</h3><p>Unser Ziel ist einen WebHook von außen zu empfangen. Auf Seite von Kubernetes bedeutet dies, dass ein Service einen TCP-Port zur Verfügung stellt, der dafür genutzt werden kann. Als Anker wird der EventListener genutzt und mit den weiteren Objekten verknüpft. Neben dem zu verwendenden <code>ServiceAccount</code> werden an dieser Stelle die Trigger angehängt. Hinter einem EventListener können beliebig viele Trigger auf unterschiedliche Anfragen lauschen.</p><p>Durch Erstellung des EventListeners wird automatisch der beschriebene Service erstellt. Nur kurz zur Einordnung: Dieser Service ist nur im Cluster verfügbar und kann je nach Use Case z. B. durch ein <code>Ingress</code> für andere Applikationen außerhalb des Clusters sichtbar gemacht werden.</p><h3>Trigger</h3><p>Die Aufgabe des Triggers ist darauf aufbauend die Anfragen zuzuordnen und durch die Verwendung von Interceptoren, TriggerBindings und TriggerTemplates zu verarbeiten. Der Trigger hat einen Namen und alles weitere wird in den genutzten Objekten verwendet.</p><h3>Interceptor</h3><p>WebHooks werden häufig durch bestimmte Systeme aufgerufen. Im Falle von Tekton sind dies Git Repositories wie z. B. Gitlab oder Github. Die Formate des Aufrufs und die genutzten Sicherheitsmechanismen unterscheiden sich zwischen den Systemen.</p><p>Ein <a href="https://github.com/tektoncd/triggers/tree/main/examples/v1beta1/github" target="_blank">WebHook von Github</a>  wird z. B. mit einem HMAC des Payloads und mithilfe eines geheimen Strings abgesichert, wohingegen durch <a href="https://github.com/tektoncd/triggers/tree/main/examples/v1beta1/gitlab" target="_blank">Gitlab</a>  ein <code>X-Gitlab-Token</code> HTTP Header mit einem Secret hinzugefügt wird.</p><p>Wir können den passenden Interceptor nutzen, das notwendige Secret und den Event-Type definieren.</p><h3>TriggerBinding</h3><p>Mit diesem Binding greifen wir auf den JSON Body der Anfrage zu und extrahieren die notwendigen Informationen, wie z. B. die URL des git repositories und den Branch-Namen.</p><p>Die extrahierten Werte sind dann als Parameter verwendbar und können im letzten Objekt verwendet werden.</p><h3>TriggerTemplate</h3><p>An dieser Stelle wird jetzt der eigentlich Aufruf vorgenommen, und zwar werden hier die extrahierten Parameter referenziert und einem Template, z. B. einem PipelineRun, zur Verfügung gestellt. Der PipelineRun wird bei einem WebHook-Aufruf gestartet und das Wissen aus den ersten Artikeln greift hier wieder.</p><h2>Praktische Umsetzung im Sample Projekt</h2><p>Hier das<a href="https://github.com/marcopaga/tekton-demo/blob/2bf387b0df0563fe7d6238d03282d5de49f050c9/tekton-triggers/gitlab-trigger-pipeline-listener.yaml" target="_blank"> komplette Beispiel aus dem Demo-Projekt</a> , welches die angesprochenen Objekte nutzt:</p><div>

```yaml
apiVersion: triggers.tekton.dev/v1beta1
kind: EventListener
metadata:
  name: gitlab-listener
spec:
  serviceAccountName: tekton-triggers-gitlab-sa
  triggers:
    - name: gitlab-push-events-trigger
      interceptors:
        - name: "verify-gitlab-payload"
          ref:
            name: "gitlab"
            kind: ClusterInterceptor
          params:
            - name: secretRef
              value:
                secretName: "gitlab-secret"
                secretKey: "secretToken"
            - name: eventTypes
              value:
                - "Push Hook"
      bindings:
        - name: git-revision
          value: $(body.checkout_sha)
        - name: git-repository-url
          value: $(body.repository.git_http_url)
      template:
        spec:
          params:
            - name: git-revision
            - name: git-repository-url
          resourcetemplates:
            - apiVersion: tekton.dev/v1beta1
              kind: PipelineRun
              metadata:
                generateName: show-parameter-triggered-pipeline-
              spec:
                pipelineRef:
                  name: show-parameter-pipeline
                params:
                  - name: image
                    value: test-image-build-by-buildpack-and-triggered:latest
                  - name: git-repository-url
                    value: $(tt.params.git-repository-url)
                  - name: git-revision
                    value: $(tt.params.git-revision)
```

</div><p>In dem Beispiel-Projekt wird der Aufruf durch eine Gitlab-Instanz durch einen curl simuliert. Der Aufruf enthält, wie bei den Interceptoren beschrieben, das notwendige Secret und die eigentlichen Daten des Aufrufs.</p><div>

```bash
curl -v \
-H 'X-GitLab-Token: 1234567' \
-H 'X-Gitlab-Event: Push Hook' \
-H 'Content-Type: application/json' \
--data-binary "@gitlab-push-event.json" \
http://localhost:8081
```

</div><p>In diesem kurzen Ausschnitt möchte ich beschreiben, wie eine Zuordnung zum Aufruf stattfinden kann, denn auf der einen Seite ist dieser Aufruf ein Fire-and-Forget-Lösung, doch auf der anderen Seite kann es notwendig sein, im Rahmen einer Fehlersuche die Verarbeitung nachzuvollziehen. Möglich ist dies, weil Tekton Triggers ein JSON-Objekt zurückliefert, welches eine Event-ID definiert. Diese Event-ID wird als Label an den PipelineRun weitergegeben, der dann darüber identifiziert werden kann. Im folgenden Snippet ist dies in der Praxis dargestellt und <a href="https://github.com/marcopaga/tekton-demo/blob/2bf387b0df0563fe7d6238d03282d5de49f050c9/.github/workflows/create-cluster.yml#L77" target="_blank">komplett hier zu finden</a> .</p>

```
    EVENT_ID=$(./trigger-tekton.sh | jq -r '.eventID')
    echo "EVENT-ID found in the response of the web-hook call${EVENT_ID}"
    # Wait for the triggered PipelineRun to complete
    kubectl -n tekton-pipelines wait --for=condition=SUCCEEDED=True --timeout=60s pipelineruns.tekton.dev -l triggers.tekton.dev/triggers-eventid==$EVENT_ID
```

<h2>Zusammenfassung und Ausblick</h2><p>Dieser Artikel zeigt anhand eines praktischen Beispiels, wie Tekton in eine vorhandene Umgebung eingebunden und genutzt werden kann. An dieser Stelle haben wir ein CI-System aufgebaut, das automatisch Pipelines startet wenn ein Push stattgefunden hat.</p><p>Wie geht die Serie weiter? Wie angekündigt wird ein Post folgen, der die Integration mit Gitlab praktisch darstellt – und zwar auf Basis eines AWS EKS Clusters. Was danach kommt ist noch offen: Möglich wäre es z. B., einen eigenen Task zu entwickeln und zur Verfügung zu stellen oder auch in die Richtung der <a href="https://tekton.dev/docs/chains/" target="_blank">Supply Chain Security</a>  abzubiegen.</p><p>Wenn ihr Fragen oder Anmerkungen zu dem Post habt, freue ich mich über Rückmeldungen von euch hier auf dem Blog, per E-Mail oder gerne auf <a href="https://twitter.com/m_p_dus">Twitter</a> .</p>

Tekton Triggers in der Praxis

<p>Im <a href="https://blog.codecentric.de/2022/01/tekton-cloud-native-ci-cd-ein-pragmatisches-intro/">ersten Artikel</a>  haben wir die Tekton-Installation gemeistert, erste API-Objekte kennengelernt und dabei eine erste kleine Pipeline erstellt. Hier eine kurze <a href="https://remarkable.com/referral/NT3R-9TVK" target="_blank">grafische Zusammenfassung</a>  als Erinnerung.<img width="1024" height="768" src="https://media.graphassets.com/6GtFNokKQ8uWaaYYGE6b" alt="Tekton Building Blocks" /><br /> Jetzt werden wir eine praktisch nutzbare Pipeline erstellen, die, wie für ein CI-System üblich, bei neuen Commits neue Images erstellt. Die Wiederverwendbarkeit von Tekton-Komponenten, sowohl Tasks als auch ganze Pipelines, ist eine Stärke, die ich gerne in diesem Artikel praktisch darstellen möchte.</p><h2>Wie bauen wir?</h2><p>Container Images können wir auf verschiedene Arten erstellen. Docker, die Firma, die Container in die Breite getragen hat, sah es vor, ein <code>Dockerfile</code> zu schreiben, das durch einen <code>docker build</code> schrittweise ein Container Image gebaut hat. Ein <code>Dockerfile</code> zu schreiben ist sehr simpel, jedoch wird es schnell sehr aufwendig, wenn man einen sicheren, stabilen Build und Betrieb gewährleisten möchte.<br /> Ich möchte nur zwei Impulse setzen, die man klären sollte:</p><ul><li>Sollte das CI-System wirklich einen Docker Socket an die Build-Container weitergeben?</li><li>Sollte innerhalb des Docker Images wirklich der Root User genutzt werden?</li></ul><p>Für diese Themen gibt es viele Lösungsmöglichkeiten. Im Folgenden werde ich den Buildpack-Ansatz beleuchten.</p><p><a href="https://buildpacks.io/" target="_blank">Cloud-Native Buildpacks</a>  sind eine einfache Lösung, um Container Images zu erstellen. Was ist also zu tun? Es reicht ein <code>pack build my-image</code>, um die Anwendung im aktuellen Verzeichnis als <code>my-image</code> zu bauen und in einem Image Repository abzulegen. Zugegebenermaßen ist die Lösung sehr einfach zu nutzen, gleichzeitig passiert viel im Hintergrund, um einen optimalen Image Build zu gewährleisten. Themen wie z. B. Caching und Security werden transparent gelöst.</p><h2>Integration in Tekton</h2><p>Wir werden eine Pipeline benötigen, die Schritt für Schritt die benötigten Tasks ablaufen lässt. Die Pipeline wird zuerst den Sourcecode aus einem Git-Repository klonen und in einem Verzeichnis ablegen. Der zweite Schritt wird den Sourcecode in diesem Verzeichnis lesen und mit Buildpack Tooling das Image erstellen und in ein Container Registry pushen.<br /> Im ersten Artikel haben wir uns angeschaut, wie wir eine Pipeline erstellen können und Tasks verknüpfen, aber mit Dateien haben wir noch nicht gearbeitet.</p><h2>Workspaces</h2><p>Verzeichnisse können in Tekton mithilfe von Workspaces zwischen Tasks geteilt werden. Workspaces können auf diverse Kubernetes-Storage-Typen zurückgreifen; so kann z. B. ein <em>PersistentVolumeClaim</em>, eine <em>Config-Map</em> oder ein <em>emptyDir</em> verwendet werden.</p><p>Bei der Definition einer Pipeline legen wir die benötigten Workspaces fest. In unserem Fall definieren wir einen Workspace, um den Sourcecode aus dem Git-Repository für die Laufzeit der Pipeline zu speichern. An dieser Stelle sind nur der Name und die Verknüpfung zu den Tasks bekannt. Tasks können Workspaces erwarten, die dann unter einem bestimmten Namen durch die Pipeline bereitgestellt werden können.</p><p>Hier sehen wir eine kurze Pipeline, die den Sourcecode aus einem Git-Repository in einen Workspace mit dem Namen <em>source-workspace</em> klont.</p><div>

```yaml
apiVersion: tekton.dev/v1beta1
kind: Pipeline
metadata:
  name: git-clone-sample-pipeline
spec:
  params:
    - name: git-clone-url
      type: string
      description: HTTP URL of the git repository to clone
    - name: git-revision
      type: string
      default: "main"
      description: Git revision (branch, tag, commit-id) to clone
  workspaces:
    - name: source-workspace # Directory where application source is located. (REQUIRED)
  tasks:
    - name: fetch-repository # This task fetches a repository using the `git-clone` task you installed
      taskRef:
        name: git-clone
      workspaces:
        - name: output
          workspace: source-workspace
      params:
        - name: url
          value: $(params.git-clone-url)
        - name: revision
          value: $(params.git-revision)
        - name: subdirectory
          value: ""
        - name: deleteExisting
          value: "true"
```

</div><h2><em>PipelineRun</em></h2><p>Wie schon im ersten Artikel beschrieben, erzeugen wir einen <code>PipelineRun</code>zum Start der Pipeline und zur Übergabe von Parametern und Workspaces.</p><p>Im folgenden Beispiel starten wir die oben definierte Pipeline mit den gewünschten Werten. Das Git-Repository wird auf einen festen Wert gesetzt und der <code>source-workspace</code> wird mit einem vorhandenen <code>PersistentVolumeClaim</code> verknüpft.</p><div>

```yaml
apiVersion: tekton.dev/v1beta1
kind: PipelineRun
metadata:
  generateName: git-clone-sample-pipeline-
spec:
  serviceAccountName: tekton-service-account
  pipelineRef:
    name: git-clone-sample-pipeline
  workspaces:
    - name: source-workspace
      subPath: source
      persistentVolumeClaim:
        claimName: source-workspace-pvc
  params:
    - name: git-clone-url
      value: https://github.com/marcopaga/feeding-the-ci-process-single-project.git
```

</div><p>Jetzt startet die Pipeline, klont das Repository und terminiert erfolgreich.</p><h2>Credentials für Clone und Push bereitstellen</h2><p>Für Open-Source-Projekte mit einem öffentlich verfügbaren Repository sind wir damit am Ziel. Bei dem internen Einsatz mit Credentials auf einem Repository müssen wir diese noch dem Git-Prozess zur Verfügung stellen.</p><p>Bei der Recherche zu diesem Aspekt habe ich verschiedene Informationen gefunden. Für mich hat diese Variante, die dort beschrieben wird, funktioniert. Im Kern wird ein Secret mit den Anmeldeinformationen erstellt und mit Annotations erweitert, die beschreiben, für welchen Einsatz und welchen Server dies zu verwenden ist. Der Key <code>tekton.dev/git-0</code>gibt an, dass dies für github.com-Repositorys zu verwenden ist.</p><div>

```yaml
apiVersion: v1
kind: Secret
metadata:
  name: github-clone-secret
  annotations:
    tekton.dev/git-0: https://github.com
type: kubernetes.io/basic-auth
stringData:
  username: git-clone-user-name
  password: git-clone-password
```

</div><p>Das alleine reicht noch nicht, denn die zu benutzenden Secrets müssen dem <em>ServiceAccount</em> des <em>PipelineRuns</em> hinzugefügt werden. Wie im folgenden Beispiel zu sehen, wird das Secret einfach mit aufgeführt.</p><p>Für den Container Image Push ist ebenfalls ein Secret notwenig. Hierbei reicht es, ein normales <a href="https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/#create-a-secret-by-providing-credentials-on-the-command-line" target="_blank">Docker Registry Secret</a>  anzulegen, wie hier in den Tekton Docs beschrieben. Wichtig auch hierbei ist, dies dem <em>ServiceAccount</em> hinzuzufügen.</p><p>Im Folgenden ist ein <em>ServiceAccount</em> mit den beiden definierten Secrets zu sehen.</p><div>

```yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  name: buildpacks-service-account
secrets:
  - name: docker-registry-secret
  - name: gitlab-clone-secret
```

</div><h2>Vorhandene Pipeline und Tasks nutzen</h2><p>Jetzt haben schon einmal eine Pipeline angelegt, mit der wir den Code klonen können. Wir können jetzt mit unserem Wissen weitermachen und schrittweise die nächsten Schritte hinzufügen.</p><p>Auf dem Tekton Hub finden wir <a href="https://hub.tekton.dev/?query=buildpack" target="_blank">Tasks für den Build</a> . So weit, so gut! Die Tasks sind gut dokumentiert und eigentlich können wir diese direkt einbauen.</p><p>Man kann auch <a href="https://hub.tekton.dev/?query=buildpack&kind=Pipeline" target="_blank">nach Pipelines suchen</a> . Wenn wir das machen, finden wir eine komplette Pipeline, die schon fertig und getestet ist.</p><p>Die Buildpacks-Pipeline ist wunderbar dokumentiert. Wir finden Informationen zum Hintergrund, den benötigten Abhängigkeiten und der Installation.</p><p>Wie im ersten Artikel beschrieben, werden diese installiert und direkt benutzt. Der vorhandene <code>PipelineRun</code> wird der Dokumentation folgend angepasst und schon ist alles fertig.</p><h2>Fazit</h2><p>Diese Wiederverwendbarkeit erlaubt eine Zusammenarbeit und einen Austausch von CI-Komponenten innerhalb der eigenen Organisation und sogar im Open-Source-Umfeld.</p><p>Wir konnten durch Verwendung und Konfiguration von Community-Komponenten mit sehr wenig Aufwand eine funktionierende Pipeline erstellen. Damit haben wir jetzt einen Startpunkt, um die eigenen Erweiterungen vorzunehmen und auch dabei von der Community des Tekton Hubs zu profitieren und hoffentlich sogar eigene Contributions zurückzugeben.</p><p>Im nächsten Artikel werden wir mit Tekton Triggers auf dieser Basis weitermachen und beim Push in ein Repository einen Build dieser Pipeline starten.</p>

Tekton Buildpack Pipeline: Alles schon da?

**Der Open Policy Agent (OPA) ist eine universell einsetzbare, quelloffene Policy Engine, also eine Sammlung von Komponenten, die eine einheitliche und effiziente Umsetzung von Regeln aller Art erlaubt. Dieser Artikel zeigt ein kleines Praxisbeispiel.**

Wann hast du das letzte Mal von einer Policy gehört? Etwa:
Wir sollen im Terraform-Skript darauf achten, dass wir bestimmte Parameter setzen.
Oder:
Wir sollen beim Kubernetes-Deployment darauf achten, dass wir nicht als Root laufen.
Das Ganze kann man umsetzen, indem man organisatorische Maßnahmen trifft, was eine umständliche Formulierung für ein Peer Review oder Freigabeprozess ist. Oder durch geschickte Automatisierung. Letztere erhöht zum einen die Sicherheit – denn, mal Hand aufs Herz: Wie oft fällt doch mal etwas nicht auf? – und zum anderen auch die Geschwindigkeit, da eine automatische Prüfung innerhalb einer Pipeline auf jeden Fall schneller ist, als ein Mensch es je sein kann.
In dieses kleine Beispiel möchte ich gerne in diesem Artikel konkret hineinschauen, weil ich denke, dass dies eine schöne Möglichkeit ist, mit wenig Aufwand einen In-House-Prozess durch Automatisierung zu beschleunigen – mit dem Open Policy Agent.

## OPA-Ökosystem
Um es direkt zu sagen: Das Ökosystem ist groß und die Einsatzmöglichkeiten sind sehr vielfältig. 
OPA bietet zum einen die Softwarekomponenten, die benötigt werden, um Regeln während der Laufzeit auszuführen, und zum anderen ist es ein Ökosystem mit verschiedensten Werkzeugen und Integration. Und da zeigt sich meiner Meinung nach auch die Stärke dieser Lösung. 
Wir haben damit die Möglichkeit, als Community voneinander zu profitieren, wie wir es auch normalerweise bei unserer Arbeit gerne machen. 

## Benutzung
Wenn wir das Projekt einsetzen wollen, können wir zwischen mehreren Deployment-Varianten auswählen. Im Folgenden einmal die Herausstechenden:

1. Einbindung als Library, z. B. in einem Go-Projekt oder über Web Assembly
2. Standalone-Deployment als Service mit REST-basierter API
3. Benutzung in einem Test-Tool wie z. B. <a href="https://github.com/open-policy-agent/conftest" rel="noopener noreferrer" target="_blank">Conftest</a> 

Je nach Einsatzszenario unterscheiden sich die Ansätze, wie die Daten und Regeln geladen und zur Ausführung gebracht werden. So gibt es etwa die Möglichkeit, die Daten und Regeln in der Auslieferung als Paket mitzuliefern oder diese Regeln von außen zu erhalten.

Was die Szenarien verbindet, ist das generelle Vorgehen: Zunächst erfolgt ein Aufruf, der von außen an die Engine geliefert wird. Die Regeln werden dann ausgeführt und die Entscheidung wird mit Meta-Daten zurückgeliefert. 
Conftest ist das einfachste Werkzeug, da in diesem Fall die Regeln und die Eingabedaten vorhanden sind und einfach lokal ausgeführt werden kann.

## Rego
Bei dieser Sprache handelt es sich um eine für diesen Zweck optimiert entwickelte Sprache, die von Dataloc inspiriert ist. Ich muss zugeben, dass ich erst im Rahmen der Recherche das erste Mal von dieser Sprache gehört habe.
Wir können hiermit effizient Regeln definieren, die auf strukturierte Eingabedaten angewendet werden. 
Dokumente oder Eingabedaten sind über eine bestimmte Variable innerhalb der Regelausführung bekannt und können über logische Operationen validiert werden. Die Navigation innerhalb der Dokumente ist mit <a href="https://github.com/stedolan/jq" rel="noopener noreferrer" target="_blank">https://github.com/stedolan/jq</a>  vergleichbar und geht mit ein wenig Übung leicht von der Hand.
Damit gehen wir schnell in das obligatorische „Hello, World!“-Beispiel. Als Eingabedaten verwenden wir hier ein JSON-Dokument mit dem Input-Objekt bestehend aus zwei Attributen.
Die Policy prüft, ob die beiden Attribute mit den gewünschten Werten vorhanden sind.

Eingabedaten:
```yaml
{
    "greeting": "hello",
    "message": "world",
	
}

```
Policy:
```yaml
default result := false
result if {
    input.message == "world"
    input.greeting == "hello"
}
```

# Kubernetes

Eingabedaten können beliebige strukturierte Dokumente sein, wie z. B. YAML- oder JSON-Dokumente, sodass sich als Beispiel Kubernetes-Manifeste anbieten, weswegen ich in diesem kurzen Artikel diesen Use Case betrachte.

Die Validierung von Kubernetes-Manifesten kann sowohl im CI-System als auch durch einen Admission Controller im Cluster erfolgen. Innerhalb des CI-Systems wird das OPA-Tooling verwendet, um einen Build mit einer entsprechenden Fehlermeldung zu beenden. Darüber hinaus kann auf den Clustern ein aktiver Check in Form des o. g. Admission Controllers eingebunden werden. Dieser Admission Controller weist Kubernetes-API-Objekte zurück, die den definierten Firmenvorgaben nicht entsprechen.

Ein kleines Beispiel, wie man die Validierung der Kubernetes-Manifeste über das Open-Policy-Agent-Tool <a href="https://github.com/open-policy-agent/conftest" rel="noopener noreferrer" target="_blank">Conftest</a> umsetzen kann: Conftest ist ein kleines Kommandozeilentool, das die Rego-Policies und Deploymentkonfiguration erhält, die Prüfung vornimmt, das Ergebnis ausgibt und einen entsprechenden Return-Code liefert, um in der CI darauf reagieren zu können. 

Wir implementieren jetzt diese Policies in Rego, die ein Deployment prüfen.


```yaml
# Wird in den folgenden Regeln referenziert, um nur auf Deployments zu arbeiten. Andere API-Objekte werden ignoriert
is_deployment {
  input.kind = "Deployment"
}

# Nur Container-Images vom internen Container-Repository sollen verwendet werden. Wird geprüft durch eine Regular Expression auf dem Image-Name
deny[msg] {
    kubernetes.is_deployment
    container := input.spec.template.spec.containers[_]
    not re_match("^internal.repository.de/.+$", container.image)
    msg = sprintf("Container in Deployment %s should use an image from the internal repository", [name])
}

# Wir wollen eine Warnung erzeugen, falls für ein Deployment keine Liveness-Probe definiert wurde. Es wird direkt geprüft, ob diese definiert wurde
warn[msg] {
    kubernetes.is_deployment
    container := input.spec.template.spec.containers[_]
    not container.livenessProbe
    msg = sprintf("Container in Deployment %s should define a livenessProbe", [name])
}
```

Sollte eine Regel nicht erfüllt sein, wird eine Meldung durch den msg-Block zurückgeliefert und ist damit in der CI-Pipeline sichtbar.
Ein sehr einfacher Schritt, der aus dem Stand Mehrwert bietet. Wenn du Fragen dazu hast, melde dich gerne direkt bei mir z. B. über <a href="https://twitter.com/m_p_dus" rel="noopener noreferrer" target="_blank">Twitter</a>  oder per-Mail, dann schaue ich gerne zusammen mit dir, wie wir das umsetzen können.

# Ausblick
Dieser Artikel hat dir schnell einen ersten Überblick über das Projekt Open Policy Agent (OPA) und eine Einsatzmöglichkeit gegeben. Es gibt viel mehr Optionen, das Tool zu verwenden. Um einen ersten Eindruck davon zu erhalten, lohnt es sich, auf der Ökosystem-Seite des Projekts zu stöbern.
Weiterhin werden wir auf diesem Blog Artikel zu diesem Thema posten und auch eine <a href="https://www.codecentric.de/softwerkercast" rel="noopener noreferrer" target="_blank">SoftwerkerCast-Folge</a> zu diesem Thema aufnehmen. 

Open Policy Agent – Maschinen, die auf Regeln starren

Warum „Platform Engineering“ eigentlich der falsche Begriff ist und wie man den Golden Path findet, erklärt Daniel Kocot, Senior Solution Architect, im folgenden Interview.\nMarco Paga: Warum ist Platform Engineering interessant?\nDaniel Kocot\n: Ich habe im September [2022] einen ersten Versuch eines \nBlogposts\n gestartet, um das Thema aufzunehmen und zu verstehen, woher der Drive kommt, um festzustellen, dass wir das bei codecentric seit 2014 gemacht haben, ohne es „Platform Engineering“ zu nennen. Wir haben schon immer etwas ausgeliefert oder zu Kunden mitgebracht, um sie zu befähigen, Softwareprodukte schneller umzusetzen. Das heißt, es ist alles schon da gewesen, jetzt gibt es einen Begriff dafür – der vielleicht nicht ganz passend ist, das schon vorab.\nMaximilian Mayer: Lass uns den Begriff „Platform Engineering“ gleich vorab klar definieren, damit jeder von uns versteht, was das überhaupt ist, wenn wir darüber sprechen.\nDK\n: Platform Engineering ist eigentlich ein falscher Begriff. Ich baue keine Plattform auf, sondern unterstütze dabei, eine Plattform entstehen zu lassen. Also Softwareprodukte oder ein Softwareprodukt an sich. Das heißt, ich bin in der DevOps-Schiene unterwegs und versuche entsprechend, all das, was diese Software braucht, in den Lebenszyklus zu integrieren. Darin steckt auch Governance: dass man Vorgaben macht und schaut, wohin die Reise gehen könnte. Ich möchte damit verhindern, dass Teams etwas benutzen, was im Unternehmen nicht gesetzt ist, und baue Schranken auf. Wenn wir über Platform Engineering reden, dann auch über den „Golden Path“ und welche Rolle Spotify darin hat.\nMM: Wir reden also nicht von einzelnen CI/CD-Pipelines, sondern Platform Engineering ist eher so etwas wie ein Meta-Begriff.\nDK\n: Genau. Es ist ein Überbegriff. Vielleicht möchte ich auch nicht, dass eine Plattform das für mich erledigt, sondern eine Art von Orchestrierung und eine unendliche Anzahl von verschiedenen Plattformen, die mir helfen, Dinge voranzutreiben. Es kommt auch darauf an, wo ich unterwegs bin. Falls ich mit Azure arbeite, ist es eventuell sinnvoll, gewisse Sachen mit Azure DevOps zu lösen. Aber ich kann es durch Platform Engineering so abstrahieren, dass die Software-Entwicklungsteams gar nicht mitbekommen, welche darunter liegenden Technologien sie benutzen. Ganz klar spielt hier auch Developer Experience eine Rolle: das Gefühl zu haben, sich auf die Entwicklung konzentrieren zu können, ohne z. B. irgendwelche Pipelines bauen zu müssen. Es ist alles schon da.\nMP: Das heißt, es ist zum einen Dokumentation, also es sind Hilfestellungen oder Ideen hinterlegt, wie bestimmte Dinge umgesetzt werden, welche Technologien oder innerhalb welchen Technologiespektrums man sich bedienen sollte. Und ich habe auch schon Artefakte mitgebracht, z. B. ein Testing oder etwas in Richtung CI/CD. Das ist ein Baukasten, aus dem ich mich bediene. Fehlt außerdem noch etwas?\nDK\n: Es ist, grob gesagt, genau dieser Baukasten. Was wichtig ist: Ich muss die Entwickler abholen und mich erkundigen, was sie benutzen, was „State of the Art“ ist. Vielleicht stelle ich z. B. fest, dass eine bestimmte Frontend Library nicht das Richtige ist. Ich muss einen Weg finden, die Dinge langfristig besser steuern zu können. Das trägt Spotify sehr stark nach außen, mit Backstage z. B. Die Grundlage von allem ist der sogenannte „Golden Path“: den Fokus auf die reine Entwicklung zu legen. Wir haben, wie ihr auch wisst, sehr häufig Debatten über CI/CD-Pipelines, welches Tooling, warum und zu welcher Zeit. Das will man umgehen, indem man sagt: OK, du willst eine Spring-Boot-Anwendung entwickeln – hier ist ein Button, der ganz viele Dinge auslöst. Schon passieren Sachen im Hintergrund, und ich kann mich wieder auf die Entwicklung fokussieren. D. h. ich kann das Repo auschecken und direkt anfangen, ohne mir Gedanken machen zu müssen, was ich ja auch nicht will. Ich will mir nicht zuerst etwas aufbauen, sondern direkt starten. Es ist alles gesetzt, es gibt vielleicht gewisse Spielregeln, an die ich mich halten muss. Die kann ich auch noch verändern. Aber es ist ein Baukasten, plus ein bisschen mehr.\n„Was wir hier tun, ist nichts Neues. Wir geben dem Ganzen einen anderen Raum und eine andere Position.“\nMM: Das gibt es in der IT doch eigentlich seit 20, 30 Jahren und es hat jetzt einfach einen neuen Namen bekommen – oder sehe ich das grundlegend falsch? Ich komme aus dem Ops-Bereich, dort wurde den Entwicklern häufig schon vorgearbeitet: „Schubs deine Sachen da hinein, dann verteilen wir es weiter“ usw., d. h. sie hatten schon früher in mehr oder weniger komfortablen Konstrukten schöne Buttons, auf die sie nur noch klicken oder E-Mails, die sie verschicken mussten, um Sachen über den Zaun zu werfen. Sehe ich das verkehrt?\nDK\n: Die Grundlage ist immer schon da gewesen. Was wir hier tun, ist nichts Neues. Wir geben dem Ganzen einen anderen Raum und eine andere Position. Wir wollen den gesamten Entwicklungszyklus transparent unterstützen und bieten dir ein gewisses Set von Möglichkeiten. Du kannst natürlich auch den Golden Path verlassen und sagen: Juckt mich alles nicht. Aber wenn du in einem Großunternehmen gewisse Regularien hast und bestimmte Software- und Infrastrukturkomponenten nutzen möchtest, hast du hiermit eine gewisse Chance, alles in eine Art von Alignment zu setzen, sodass alle das nutzen, was da ist und kein Wildwuchs entsteht. Denn das sehen wir bei sehr vielen Kunden: Sehr, sehr viele Komponenten, aber man fragt sich, in welchen Komponenten das Service-Team, das für die Bereitstellung zuständig ist, eigentlich fit ist. Man muss sich um eine schnellere Time-to-Market bemühen. Und am meisten halten Diskussionen darüber auf, \nwas\n man verwendet und \nwarum\n. Es gibt auch Sicherheit, wenn alles standardisiert ist und es geht dann nur noch um die Entwicklung: das Erstellen und Deployment von Software.\nDer Golden Path\nMP: Kannst du den Begriff „Golden Path“ noch einmal für uns einordnen und sagen, was sich dahinter verbirgt?\nDK\n: „Golden Path“ ist das, was die Geschwindigkeit bei Spotify ausmacht. Die können relativ schnell Sachen ausliefern, die bekommen ein schnelles Onboarding hin. Der Golden Path zielt darauf ab, gewisse Sachen zu standardisieren: Abhängigkeiten von Services, Discovery von Services etc., sodass ich Sachen nicht nur schnell finde, sondern auch schnell nach dem Baukastenprinzip zusammenklicken und mich aufs Entwickeln fokussieren kann. \n„Man muss sich um eine schnellere Time-to-Market bemühen. Und am meisten halten Diskussionen darüber auf, \nwas\n man verwendet und \nwarum\n.“\nMM: Das Gedanke hinter dem Golden Path ist also „Schuster, bleib bei deinen Leisten“ bzw. „Entwickler, kümmere dich bitte darum, dass du entwickelst und nicht um das Drumherum“, denn Letzteres wird schon vorbereitet. Spannend, dass du Standardisierung nennst, denn daran scheitert es oft in Unternehmen: Man möchte oft den zweiten Schritt vor dem ersten machen – Kubernetes und all die fancy Sachen – aber der erste Schritt, Dinge zu standardisieren, wird vergessen. So entsteht Schatten-IT: Leute, die die neuesten Sachen machen wollen, treffen auf solche aus dem „Legacy“-Bereich, die noch nicht abgeholt sind und beim Bewährten bleiben wollen. Mit Platform Engineering lassen sich alle schön einfangen, um einen Rahmen zu geben, oder?\nDK\n: Platform Engineering ist eine Art von Knowledge Sharing: Ich teile das Wissen, das ich im Unternehmen gesammelt habe, wie ich Dinge aufbaue. Marco nannte es vorhin „Dokumentation“.  Für Entwickler ist es dann alles unter einem Dach, und ich muss nur dafür Sorge tragen, dass die Entwickler es benutzen. Natürlich gibt es Feedback Loops. Was man mit Platform Engineering erreichen möchte, ist eine Art Self-Service.\nMP: Self-Service heißt, es ist noch kein Platform Engineering, wenn man ein gutes Confluence-Wiki pflegt und ein Ticket-System hat, wo man bestimmte Dinge anfragen kann. Da geht es schon um mehr.\nDK\n: Ja. Ich mag den Begriff „Developer Experience“ nicht – das ist immer so eine eine platzende Seifenblase, und kein Mensch kann etwas damit anfangen – aber es geht darum, dass der Entwickler sagen kann: „Ich klicke mir etwas zusammen, dann passiert etwas Magisches. Ich muss nicht wissen, wie ein Kubernetes-Deployment funktioniert, weil es gar nicht meine Baustelle ist. Ich will nur sehen, dass mein Service in irgendeinem Cluster liegt und funktioniert.“\nMM: Ich war jahrelang im Ops-Bereich tätig und kenne den ewigen Konflikt mit Entwickler-Teams, die mal etwas anderes machen wollen. Wenn man denen dann sagt: Nimm das und benutze es, wird es immer welche geben, die ihre eigenen Tools benutzen wollen, das neueste JavaScript-Framework usw. Hier sehe ich die Gefahr, dass sich Geschichte wiederholen könnte. Wie gehe ich damit um?\n„Platform Engineering ist eine Art von Knowledge Sharing: Ich teile das Wissen, das ich im Unternehmen gesammelt habe, wie ich Dinge aufbaue.“ \nDK:\n Gute Frage. Man muss den Mehrwert erklären können: Warum gehen wir so vor? Weil wir Geschwindigkeit wollen. Wenn das der eine oder andere als Gängelung auffassen sollte, kann man sagen: Ja, du kannst das anders machen, aber dann bekommst du keine Unterstützung und wir können das nicht jedes Mal machen. Wir können nicht auf jede Technologie reagieren, weil wir einen Plan haben. Wenn jemand Vorschläge hat, kann er die natürlich einbringen. Das ist dann allerdings ein Abweichen vom Golden Path, vom „One-Click Shop“, wie es ein Kunde von mir nennt. Ich mache einen Klick und bin schon in der Entwicklung. Ich kenne genug Beispiele von Kunden, wo das schon so funktioniert: Das nennt sich dann „App Store“ o. ä., wo du dir wirklich mit einem Klick Applikationen in jeder Programmiersprache zusammenbauen lassen kannst. Und alles ist konfiguriert. Das ist möglich. Es ist nur die Frage, wie schnell ich das auf die Mannschaft übertragen kann. \nEs geht auch um Adaption, nicht um Kopieren. Nur weil Spotify es so macht und Backstage nutzt, heißt es nicht, dass wir es auch so machen. Es geht darum, zu entscheiden, was mir aktuell hilft – und wenn es erstmal nur ein Git-Repo ist.\nMP: Diese Einordnung ist wichtig. Es ist ein Weg, den man geht, und je nachdem, wo man startet, kann man relativ schnell Mehrwert bieten. Während des Prozesses lassen sich ja auch Schleifen drehen. Wenn Leute andere Technologien verwenden wollen, die z. B. schneller oder besser machen, kann man diesen Leuten Anknüpfungspunkte bieten – sei es, dass man sich in einer Gilde austauscht oder in Sachen Architektur die Möglichkeit hat, einen Dialog aufzubauen oder das Ganze auszutesten, zu validieren, ob das wirklich mehr bringt, dass es irgendwo geregelt ist, und die Potentiale mitnehmen kann.\nDK\n: An Begrifflichkeiten gibt es auch noch „Internal Developer Platform“, abgekürzt IDP, was total schlecht gewählt ist, weil IDP normalerweise etwas anderes bedeutet. Max hat es schon gesagt: Es gibt tausend Begriffe für Dinge, die eigentlich schon da sind. Man muss für sich schauen, was das Ziel ist, welcher Player im Markt man ist: Bin ich ein Datenlieferant, muss ich natürlich bis zum Ende durchautomatisieren, und das muss ich in eine Plattform – jetzt sage ich es schon wieder – oder einen Lebenszyklus gießen. Das ist es, was wir als Entwickler tun: Wir haben eine Idee, setzen diese um, indem wir etwas entwickeln, wir testen, kommunizieren viel, holen Feedback. Und am Ende gibt es ein Artefakt, das in eine Produktion deployt wird. Was wir [mit Platform Engineering] leisten, ist einfach eine Art Unterstützung. Wir helfen, Sichtbarkeit zu erlangen, Dinge zu sehen und zu verstehen, das Suchen und Finden für Entwickler noch einfacher zu machen – in der Regel braucht man einfach eine Such-Engine, die einem hilft, Dinge wiederzufinden. Wir bauen nichts Neues, sondern nehmen Komponenten, die seit 20 Jahren oder länger schon da sind – und geben ihnen ein neues Ansinnen. \nMM: Es ist also weniger die Frage, \nwomit\n als die Frage, \nwie \nman es macht. Hier sehe ich zwei Kernelemente: Standardisierung und Integration der Möglichkeiten. Oft hat man eine Build-Pipeline und einen Kommunikationskanal an anderer Stelle. Wenn man das miteinander sauber integrieren kann, ist das schon die halbe Miete. Wenn man dann noch klar macht, dass es das ist, was mit dem Label „Platform Engineering“ gemeint ist, hat man den Begriff schon entmystifiziert.\n„Es geht um Adaption, nicht um Kopieren. Nur weil Spotify es so macht und Backstage nutzt, heißt es nicht, dass wir es auch so machen.“\nTool-Unterstützung\nMP: Was wirklich wichtig ist, ist, dass man nicht einfach irgendein Tool kauft und installiert. Sondern es geht um viel mehr.\nTrotz allem gibt es Tools, die unterstützen. Was sind sonst noch Tools, die man nutzen kann?\nDK\n: Backstage ist eine Art Entwicklungsportal oder -Framework. Es kommt darauf an, was man braucht. Es gibt auch Humanitec, das so etwas wie Plattform-Orchestrierung bietet, eine zentrale Steuerungseinheit. So werden Dinge einfacher und greifbarer, weil wir nicht so viel über die darunter liegende Plattform wissen müssen, sondern einfach eine Art Konfigurationsmanagement machen. Bei Humanitec gibt es auch eine Beschreibungssprache, die sich \nPlaform-Agnostic Workload Specification \nnennt. Die beschreibt, wie ein Workload Plattform-agnostisch aussehen soll. Das heißt, ich kann mir in einer YAML-Datei den Workload beschreiben, den ich auf verschiedene Plattformen auslagern möchte. Jonas hat über \nCrossplane\n geschrieben, das auch in diese Richtung geht: Es bietet Möglichkeiten für verschiedene Cloud-Hersteller, bewegt sich also in Richtung Multi-Cloud, und kann Dinge dadurch vereinfachen. Es gibt, wie immer, einen Haufen Tools, und man muss sich für sich überlegen: Was will ich eigentlich erreichen bzw. was hilft mir im Moment? Aktuell brauchen die meisten eine Sichtbarkeit auf vorhandene Services und darauf, wie eigentlich entwickelt wird, was die eigenen Standards sind. Daraus ergeben sich im Laufe der Zeit weitere Tools, die ich brauche, um den Platform-Engineering-Begriff füllen zu können. Das Erste ist für die meisten Discovery. Das ist ein einfaches und lösbares Problem: Sichtbarkeit auf das, was ich habe und wo ich stehe.\nMP: Vielen Dank, Daniel, dass du dir die Zeit genommen hast, mit uns das Thema Platform Engineering mit Leben zu füllen und den Leuten näher zu bringen!\nDieses Gespräch führten Max, Marco und Daniel im Rahmen unseres Podcasts SoftwerkerCast. Weitere Folgen unter \nhttps://www.codecentric.de/softwerkercast\n. \n\nMaximilian Mayer\n arbeitet als APM Consultant für die codecentric AG. Er hat viele Erfahrungen als Linux-Admin und im DevOps-Umfeld gesammelt. Neben Automatisierung interessiert er sich für Ruby-Entwicklung. Motorräder und alte Autos zählen zu seinen Leidenschaften.\nMarco Paga\n entwickelt Software aus Leidenschaft. Gerne arbeitet er im Team an der Lösung komplexer Probleme. In der Vergangenheit hat er dabei erfolgreich Legacy-Applikationen modernisiert, um diese auf geänderte Herausforderungen vorzubereiten. Alle Beteiligten auf diesem Weg mitzunehmen und für neue Technologien zu begeistern – das ist für ihn selbstverständlich.

„Platform Engineering ist eine Art von Knowledge Sharing“

Platform Engineering mit Backstage\nIm folgenden Interview berichten Marc Schnitzius und Pascal Sochacki von ihren ersten Erfahrungen mit Backstage als Platform-Engineering-Lösung.\nMarco Paga: Marc, Pascal, ihr habt eine Sicht auf Platform Engineering, die ihr gerne mit uns teilen wollt.\nMarc Schnitzius\n: In dem Projekt, in dem ich aktuell mit Pascal bin und generell in Projekten ist man oft in der folgenden Situation: Die Firma schneidet neue Domänen und startet Teams, die alle Services programmieren sollen. Da läuft viel parallel, und es gibt eine ganze Menge Tools, die theoretisch jeder beherrschen müsste, um die Services deployen zu können. Daher kommt der Gedanke, die Hemmnis, die dadurch entsteht, und die kognitive Last zu reduzieren – man muss erst viel lernen, hat eine lange Ramp-up-Phase, muss viele Tools beherrschen – und eine Plattform zu bauen, die das Ganze einfacher macht. \nMP: Das heißt, der Kunde hatte schon viel gemacht, man konnte also schon viele Tools nutzen, musste dann immer nur ein gewisses Konzert „abfeuern“, damit man wirklich einen neuen Service an den Start bringen konnte?\nMS\n: Tatsächlich gab es einige Tools. Aber für die Software, die geschrieben werden sollte – sie wollten mehr in Richtung Microservice-Architektur gehen – kamen einige neue Tools dazu. Das war das eigentliche Problem: der Umstieg von den bekannten, vielen Tools, die ein Dev-Team auch schon relativ langsam gemacht haben, zu vielen neuen Tools, die die Dev-Teams noch langsamer gemacht haben. Keiner will langsame Teams. Deshalb kam der Gedanke, eine „Paved Road“ zu bauen, mit der die Software schnell von der Idee in die Umsetzung kommt.\nMaximilian Mayer: Aber ihr habt wohl kaum gesagt: „Wir machen jetzt Backstage“, sondern es wird ein Prozess gewesen sein, oder?\nMS\n: Auf jeden Fall. Der Prozess dauerte etwa ein dreiviertel Jahr, bis wir zu Backstage gekommen sind. Zuerst haben wir umgestellt von Jenkins auf GiLab CI, haben Kubernetes-Infrastruktur aufgebaut, in dem Fall in der IONOS-Cloud. Es war ein reguliertes Umfeld, deswegen war ein DSGVO-konformer Cloud-Anbieter wichtig. Wir haben viele Terraform-Module geschrieben und erst einmal den Prozess modelliert, wie wir was automatisieren wollten. Am Ende kam ein guter Prozess heraus, für den man aber immer noch eine Anleitung brauchte, was wo zu tun ist. Es gab immer noch eine relativ hohe Hemmschwelle in den Entwicklerteams, diese Plattform zu nutzen, denn: Was Terraform war, was Kubernetes war, wie man deployt, was man kaputt machen konnte usw., war alles nicht klar. Dann kamen wir auf den Gedanken, dass wir ein Frontend für unsere Plattform brauchten, das genau den Prozess, den wir modelliert hatten – neuen Service schnell starten, deployen, monitoren – nochmal abstrahiert und zugänglicher macht.\nMP: Mit „neuen Service starten“ meinst du, dass ein Team damit anfängt, einen neuen Microservice aufzusetzen und dann unterstützt wird dadurch, dass es ein eigenes Git-Repo bekommt, ein CI-System für das Projekt, dass Kubernetes-Ressourcen erzeugt werden ...\nMS\n: ... Security Compliance usw. Alles, was man in eine Pipeline packen kann, sollte einfach schon da sein. Dinge, die normalerweise erst später im Projekt kommen, z. B. Security Scanning, ist darin von Anfang an enthalten. Das ist der DevOps-Gedanke: schnell Feedback zu geben, wo es ein Problem gibt, und es direkt zu adressieren.\nMP: Ihr habt also bei den Basics angefangen: erst einmal alles automatisiert, dargestellt, sodass man darauf aufsetzen kann. Das ist auch ein Learning: dass man erst die Basics einbeziehen muss, bevor man die weiteren Abstraktionsschichten nutzen kann, und auch gewinnbringend. Ich kann ja nicht einfach ein Plattform-Tool nutzen, wenn ich dahinter noch kleine Snowflake-Server habe, die manuell gewartet werden. \nMS\n: Genau. Es ist sehr wichtig, alles iterativ anzugehen. Eine Plattform ist im besten Fall ein Produkt, und die Kunden des Plattform-Teams sind die Entwickler-Teams. Ein Produkt kommt meistens nicht mit einem großen Knall daher, sondern iterativ und im besten Fall so, dass man sich immer wieder vergewissert, ob es noch dem Kundenbedürfnis entspricht. \nAls wir schon fast ein Jahr im Projekt waren, haben wir gesehen, wie die Prozesse sind, wie Leute arbeiten, wie die Teams funktionieren, worauf es ankommt, wo es scheitert, wo Bottlenecks sind. Wir haben erst mal modelliert und angefangen zu automatisieren. Am Ende haben wir dem Produkt ein Gesicht gegeben, ein UI.\nMP: Und das Gesicht könnte in eurem Fall Backstage sein?\nMS\n: Genau. Hier kam Pascal ins Spiel. \n„Eine Plattform ist im besten Fall ein Produkt, und die Kunden des Plattform-Teams sind die Entwickler-Teams.“ \nBackstage\nPascal Sochacki\n: Ich betreibe Backstage seit zwei, drei Monaten und versuche es für uns zu entwickeln, damit wir ein schönes UI für unsere Plattform haben.\nHier muss ich kurz ausholen und erklären, was überhaupt Backstage ist und woher es kommt: Seit zwei Jahren ist es in der CNCF [Cloud-Native Computing Foundation], wurde von Spotify als Open Source bereitgestellt und bei Spotify schon länger eingesetzt. Es ist ein Service-Katalog für große Firmen mit mehreren Teams, die mehrere Services entwickeln, damit ich einen Ort habe, an dem ich alle Informationen finde, die ich für mein tägliches Doing als Entwickler brauche. Es geht darum, zu erfahren, welche Services es um mich als Entwickler herum noch gibt, damit ich z. B. keinen Service schreibe, den es vielleicht schon gibt. Oder welche APIs es gibt, die ich eventuell von anderen Teams konsumieren kann. Oder wenn ich einen neuen Service starten will, der schon so konfiguriert sein soll, dass er auf der zentralen Plattform laufen kann, ohne dass ich viel durchlesen und konfigurieren muss. Es bringt auch ein großes Plug-in-System mit sich, d. h. wenn ich in meiner Plattform schon verschiedene Tools verwende, kann ich sie dort wunderschön integrieren. \nMP: Backstage bietet mir also die Transparenz, die ich brauche. Ich habe verschiedene Services, OpenAPI Specs usw. Wie kann ich das als Entwickler pflegen? Muss ich da immer auf die Oberfläche und klicke mich durch, oder wie kommen die Daten rein?\nPS:\n Es gibt mehrere Möglichkeiten. Ich habe ein Git-Repo, und dort liegt die \ncatalog-info.yaml. \nDie hat ein gewisses Schema, was genau dieses Repo darstellt. Dann kann man entweder die URL Backstage übergeben, und es checkt sie ein; oder man kann sich über Plug-ins einen „Crawler“, wie ich es nennen würde, schreiben, der über alle Git-Repos geht, die er findet. Wenn er die \ncatalog-info.yaml\n findet, registriert er diese und sie ist danach in Backstage vorhanden. Es gibt also keine Hürde, weil ich niemanden bitten muss, meinen Service zu registrieren, sondern das sollte jeder selbst tun.\nMP: Also sehr zugänglich. Was ich oft beim Kunden sehe, ist, dass es ein System gibt, das man pflegen könnte, aber das ist oft sehr veraltet. Daher klingt das sehr gut, dass man bei Backstage mehrere Möglichkeiten hat, es aktuell zu halten.\nMM: Backstage ist glaube ich nicht das einzige Tool [dieser Art] auf dem Markt, aber es legt den Fokus sehr stark auf Platform Cataloguing. Mir fallen andere Tools ein, die so etwas Ähnliches anbieten, einige davon habe ich schon bei Kunden gesehen, aber das war immer eine ziemliche Fummelei. Wie hat Spotify mit Backstage Akzeptanz erreicht? Denn daran scheitert es meistens: Das Tool kann noch so cool sein – wenn es niemand benutzen möchte, hat man verloren. Deshalb bin ich neugierig: An welchem Punkt holt Backstage die Entwickler ab, dass es tatsächlich eine hohe Akzeptanz erreicht?\nPS\n: Schwierige Frage, die wir für unser Projekt auch noch nicht ganz beantwortet haben. Wir sind gerade noch dabei, alle Teams in Backstage zu registrieren. Leuten zu sagen: „Hey, macht das jetzt bitte!“ ist immer schwierig. Man muss ihnen einen Benefit versprechen. Man könnte sie mit Dokumentation locken – das klingt vielleicht komisch, aber Backstage gibt einem die Möglichkeit, seine Dokumentation zu pflegen, als Code im Repo. So habe ich es geschafft, ein Team onzuboarden. \n„Ab einer gewissen Größe ist es sinnvoll, Leute an Bord zu haben, die nur das tun: das Ganze als Produkt denken.“\nMM: Man muss die Leute aus ihrer Komfortzone herauslocken in eine neue Komfortzone. Wenn die Hürde dann gering ist, umso besser. \nMS\n: Ab einer gewissen Größe ist es sinnvoll, Leute an Bord zu haben, die nur das tun: das Ganze als Produkt denken. Das ist auf jeden Fall ein Learning für uns.\nEs ist auch immer schwierig, wenn schon Software vorhanden ist und man schauen muss, ob alles zueinander passt oder ob die Services von ihrer Architektur her so verteilt sind, dass man jedes Mal ganz individuell handeln muss. Wenn es keine Schnittmenge gibt, wird es schwierig. \nMM: Was sind weitere Learnings aus dem Projekt? Dinge, die ihr beim nächsten Mal anders machen werdet?\nMS\n: Ich bin, wie gesagt, seit etwas über einem Jahr in dem Projekt. Als ich dazu kam, lief das Ganze schon ein halbes Jahr. Zu dem Zeitpunkt waren hauptsächlich Entwickler von codecentric in dem Projekt. Das Bottleneck war immer beim Operations-Team. Daher war die Idee, dass ich mit ihnen spreche und sie enable, ihnen zeige, wie Automatisierung funktionieren kann. Es war ziemlich schnell klar, dass nicht einer eine Plattform baut und das Problem weg ist. Ein Learning war, alles ganzheitlich zu denken, nicht nur in der Domäne Operations, sondern sich zu fragen, wie sie arbeiten, was deren Wertschöpfungskette ist. So kamen wir zu der Erkenntnis, dass eine Plattform Sinn machen würde, da die Firma viele Teams zusammenstellte und anfing, viele Services zu programmieren. Spätestens da wurde klar, dass man ein Team brauchen würde, das das Ganze treibt. Es gibt ja nicht nur die Leute, die die Plattform bauen, sondern am besten je nach Größe auch ein eigenes Team oder zumindest eine Gruppe, die Enablement-Rollen in den Teams besetzen kann. Das kommt aus dem Team-Topologies-Gedanken: Steram-Aligned-Teams, Enablement-Teams und eben ein Plattform-Team.\n„Man muss Backstage sehen wie normale Software, die upgegradet werden muss, wo Abhängigkeiten upgedatet werden müssen.“ \nMP: Wenn man es auf die Wertschöpfungskette der Teams bezieht, macht es ja auch Sinn, das so aufzusetzen. Auf der einen Seite hat man ein Team, das sich um die Plattform kümmert und Leute, die in die Teams hineingehen und fragen, was deren aktuelle Needs sind, wo es klemmt, wo es mehr Transparenz braucht. Damit man die Plattform auch als Produkt leben lässt und nicht im schlimmsten Fall „abwirft“ und abwartet, was passiert.\nMS\n: Ein Operations-Team denkt erst mal gar nicht in Produkten. Es denkt in Infrastruktur: Wenn im Monitoring etwas rot wird, behebt man das, und dann geht es weiter. Sie denken nicht in Zyklen. \nMP: Nochmal zu Backstage: Ist es ein „Free Lunch“, d. h. wenn ich meine ganzen darunter liegenden Prozesse automatisiert habe, IaC-Tools verwende, werfe ich dann einmal Backstage ab und es läuft immer, oder wie sieht Tag 2 aus?\nPS\n: Anders als andere Projekte bei der CNCF ist Backstage Software, die ich von Grund auf kompiliere und deploye. Ich habe selber den TypeScript-Code in der Hand und muss meine Änderungen vornehmen. Wenn ich Plug-ins hinzufüge, ist das ein \nnpm-install \nund ich habe das Modul in meinem Backstage und muss es noch in meinen Code einbauen. Das heißt, man muss es sehen wie normale Software, die upgegradet werden muss, wo Abhängigkeiten upgedatet werden müssen. Deshalb ist es etwas anstrengender als andere Tools, die man normalerweise in dem Umfeld benutzt. \nMM: Vermutlich ist es deswegen auch weniger für Ops-Teams geeignet, sondern eher für Personen, die einen Softwareentwickler-Hintergrund haben.\nPS\n: Das würde ich auch sagen. Das ist das Spannende und Schwierige an Backstage: Du kannst zu keinem Ops-Team gehen und sagen: Benutz das bitte.\nMM: Eine wichtige Information. Denn wenn man so ein Tool einsetzt, das eine Plattform bietet, neigt man dazu, es den Ops-orientierten Leuten aufs Auge zu drücken. Denn da könnte der erste Fehler in der Implementierung entstehen. \nMS\n: Wir kennen das aus der DevOps-Bewegung: Ein Ops-Team bekommt neue Tools, und dann soll es ein DevOps-Team sein. Es ist eine Illusion zu glauben, dass es reicht, ein Operations-Team in „DevOps“ umzubenennen, dann vielleicht noch in „SAE-Team“, dann in „Plattform-Team“. Das wird nichts.\nMP: Was gibt es sonst noch zu Backstage zu sagen?\nMS\n: Wir können noch darüber sprechen, wann es überhaupt Sinn macht, sich darüber Gedanken zu machen, Backstage zu nutzen und wie man anfängt. Wenn wir ein Plattform-Team haben und jemanden, der an Backstage „schraubt“, es eigene Software ist, ist es auch immer ein Investment. Wann lohnt es sich?\nDie kognitive Last von Entwicklern kann man beispielsweise mit einfachen Umfragen messen: Wie schwierig ist es, ein Test Environment aufzusetzen? Man kann die Zeit messen. So lässt sich der Bedarf offenlegen. Neben Test Environments kann man fragen, wo die Ownership liegt. Wenn sie beim Dev-Team liegt, sind diesem alle Prozesse klar? Wen muss ich informieren, wenn es außerhalb der Geschäftszeiten einen Ausfall gibt? Wie laufen Restores ab? Viele Dinge außerhalb der fachlichen Anforderungen an ein Dev-Team kann man gut messen, damit den Bedarf an dem Thema generell transparent machen und tracken, ob sich diese Metrik vielleicht mit Einführung der Plattform verringert. \nMP: Das heißt, man kann damit die Investition rechtfertigen, wenn ich das Ganze auf eine Zeitachse legen kann. Habt ihr für euch ein Template mit einigen Faktoren ausgearbeitet?\nMS\n: Daran arbeiten wir gerade – es transparenter zu machen. Wir hätten es von Anfang an machen sollen. Man kann schnell transparent machen, wie viel schneller man geworden ist, welches Problem man gelöst hat. Eine Zahl, die höher oder niedriger ist, sagt mehr aus als ein Ticket, auch über die eigene Domäne hinaus, wo es gar kein fachliches Verständnis gibt. \nMP: Seid ihr selber transparent im Sinne von „Dogfooding“, insofern, als ihr das Platform Engineering auf der Plattform selber darstellt? Wenn ich als interessierter Entwickler wissen möchte, was ihr gerade macht, worauf ihr den Fokus legt, wo kann ich das direkt in Erfahrung bringen?\nMS:\n Ein Plattform-Team arbeitet eigentlich nicht anders als ein Software-Team. Im besten Fall gibt es einen Scrum-Zyklus, ein Board, ein Backlog, ein Review. Genau diesen Prozess implementieren wir gerade. Dadurch, dass unser Team gewachsen ist, wird dies erst möglich.\nMP: Haltet uns gern auf dem Laufenden. Vielen Dank, dass ihr euch die Zeit genommen habt, so offen mit uns darüber zu sprechen. \nDieses Gespräch führten Marc, Pascal, Marco und Max im Rahmen unseres Podcasts SoftwerkerCast. Weitere Folgen unter \nhttps://www.codecentric.de/softwerkercast\n. \n\n
\nMarc Schnitzius\n ist DevOps und Infrastructure Consultant bei codecentric in Frankfurt. \nPascal Sochacki \nist IT Consultant bei codecentric in Nürnberg. Sein aktuelles Fokusthema ist Backstage.\nMaximilian Mayer\n arbeitet als APM Consultant für die codecentric AG. Er hat viele Erfahrungen als Linux-Admin und im DevOps-Umfeld gesammelt. Neben Automatisierung interessiert er sich für Ruby-Entwicklung. Motorräder und alte Autos zählen zu seinen Leidenschaften.\nMarco Paga\n entwickelt Software aus Leidenschaft. Gerne arbeitet er im Team an der Lösung komplexer Probleme. In der Vergangenheit hat er dabei erfolgreich Legacy-Applikationen modernisiert, um diese auf geänderte Herausforderungen vorzubereiten. Alle Beteiligten auf diesem Weg mitzunehmen und für neue Technologien zu begeistern – das ist für ihn selbstverständlich.

„Eine Plattform ist ein Produkt, die Entwickler-Teams sind die Kunden“

Victor Volle und Marc Bialowons geben Einblicke aus dem Review eines Platform-Engineering-Projekts in einem großen Unternehmen, das sich in diesem Bereich klar als Vorreiter herausstellte. Marco Paga hat mit ihnen gesprochen.\nMarco Paga: Victor, Marc, ihr wart bei einem großen deutschen Unternehmen. Könnt ihr kurz euren Auftrag beschreiben?\nMarc Bialowons: \nDer Kunde hat uns damit beauftragt, einen Blick auf sein Platform Engineering zu werfen, das er gerade für knapp 2000 Mitarbeiter in der IT zur Verfügung stellt. Dabei war es wichtig, unvoreingenommen an das Thema heranzugehen und den Blick des Marktes darauf zu werfen. Wir haben das Thema schnell heruntergebrochen in einzelne Teilkomponenten bzw. unterschiedliche Arbeitspakete: Einerseits haben wir uns mit den Nutzern der Plattform auseinandergesetzt, in Form von User Interviews. Andererseits haben wir uns mit der Technik selbst befasst, damit herumgespielt und in einem Beispielprojekt die Plattform benutzt.\nVictor Volle:\n „Herumgespielt“ damit hat eigentlich Marco Paga. \nMP: Genau, ich hatte die Möglichkeit, mir die Plattform aus Entwicklersicht anzuschauen, zu schauen, wie man damit arbeiten kann, welche Services es gibt. Es war ein sehr spannender Einblick, weil ich mit einem Buddy zusammenarbeiten konnte, der mir die ersten Fragen beantwortet und mich herumgeführt hat. Von daher: Danke, Victor, dass du mir den Ball zugespielt hast. Wir drei waren zufällig in diesem Consulting-Auftrag unterwegs.\nMöchtet ihr noch etwas über den Kunden sagen?\nVV: \nDie haben sehr früh mit Platform Engineering angefangen. Die ersten Schritte waren vor fünf Jahren. An der Stelle muss ich skizzieren, was wir mit „Platform Engineering“ meinen. Sie haben ganz banal angefangen, Kubernetes bei sich zu benutzen und internen Teams anzubieten. Das ist für mich der minimale erste Schritt: ein Angebot, das Teams, die Software entwickeln, ganz klischeehaft „Value-Stream-Teams“ genannt, nutzen können, ohne Kubernetes selbst einrichten zu müssen – gerade vor fünf Jahren war das noch ein bisschen schwieriger –, sondern das eine Team, das zum Nukleus des Platform-Engineerings wurde, hat Kubernetes zusammen mit einem externen Dienstleister hochgezogen. Die haben es betreut und betrieben und dann intern angeboten. \nDann gab es ein Projekt, das Kafka verwendet hat, und andere Projekte wollten ebenfalls Kafka verwenden. Nicht jeder muss alle Details wissen, wie man das betreibt, einrichtet, hochzieht. Das wurde dann auch intern angeboten. Das waren die ersten Schritte, die fünf Jahre her sind. Das ist ganz schön lang. Solche Dinge gab es schon vorher, aber das dann sehr gezielt als Angebot für die eigenen Softwareentwicklungsteams bereitzustellen fand ich schon ziemlich beeindruckend. In Deutschland zählen sie für mich zu den Vorreitern. \nMP: Das heißt, sie haben Probleme gelöst, die sie damals schon hatten. Als der Begriff noch nicht wirklich gängig war. Sie haben verstanden, dass es einen Wert hat und das Ganze ein Produkt ist. \nVV: \nEin Produkt ist es dort sicherlich noch nicht. Aber was ich gut finde: Sie sind nicht einfach auf den [Platform-Engineering-]Hype aufgesprungen. Ich finde den Begriff sehr gut, aber er ist momentan auch in aller Munde. Sie haben damals mit einem Problem losgelegt und gemacht, was sie brauchten. Irgendwann haben sie es dann „Platform Engineering“ genannt. \nMP: Sollen wir den Aspekt einmal genauer beleuchten?\nMB: \nDas war für uns eine interessante Erkenntnis. Wir wurden quasi in kaltes Wasser geworfen, um uns einen externen Blick in „die Plattform“ zu erarbeiten. Daher gingen wir davon aus, dass wir uns „die Plattform“ ansehen können. Die erste Erkenntnis war dann aber, dass es gar nicht die eine Plattform gibt, auf der man sich einzelne Services automatisiert zusammenklicken kann. Es war eher ein sehr großes Konstrukt aus verschiedenen Plattform-Teams, die alle ihre spezifischen Services für die Projekte anbieten, aber noch nicht so sehr in einer einzelnen Plattform vereint. \nVV: \nUm dies zu verdeutlichen: Als du anfingst, unser Beispielprojekt zu bauen, Marco, wie viele Tickets hast du gebraucht, um alles zusammenzubekommen, was du brauchtest? \n„Wir haben alle gefragt: Wohin schaust du als erstes, wenn du etwas suchst? Jeder hat uns eine andere interne URL gesagt.“ \nMP: Das war auf jeden Fall im zweistelligen Bereich. Deswegen hatte ich auch Schwierigkeiten zu verstehen, was mit „Plattform“ gemeint ist. \nVV:\n Sie sprechen eher von einer „Organisationseinheit Platform Engineering“. Und ja, sie wollen ganz klar – das war auch eine unserer Empfehlungen – zu \neiner\n Plattform.\nZu unserem Vorgehen: Wir haben klassischen User Research gemacht – so gut wir es können, wir sind keine Produktmenschen. Dabei haben wir zwei Kerngruppen von Menschen identifiziert, die diese Plattform nutzen. Die eine Gruppe sind Leute, die sehr, sehr erfahren sind. Die sind früher selbst in Plattform-Teams gewesen oder arbeiten schon lange mit ihnen zusammen. Die andere Gruppe sind Leute, die weiter weg sind – das kann auch geographisch sein – oder die einfach noch nicht so lange dabei sind. Wir haben einen riesigen Unterschied in den Bedürfnissen dieser zwei User-Gruppen festgestellt: Die erfahrenen Menschen wollten dieses neue technische Feature und jenes Angebot usw. haben. Nur: Jeder wollte etwas anderes, was ihm oder ihr wichtig war. Die weniger erfahrenen Menschen – „erfahren“ muss hier nicht heißen, dass sie erst seit drei Jahren im Job sind, aber neu bei diesem Kunden oder bei der Plattform – waren teilweise noch sehr am Suchen. Wir haben alle gefragt: Wohin schaust du als erstes, wenn du etwas suchst? Jeder hat uns eine andere interne URL gesagt. Das heißt, es gibt nicht diesen einen Einstiegspunkt. Einer hat uns gezeigt, wie er in deren Weekly gezielt und sehr geschickt sucht, um das Richtige zu finden im „Wald vor lauter Bäumen“. Eine Plattform, die Menschen Self-Service-artig sehr einfach etwas zur Verfügung stellt, machen sie noch nicht. Wo sie richtig gut sind, ist alles andere: Unterstützung, Consulting, Support, Bereitstellen an Informationen bis in die Details. Gerade auch für den Betrieb, Observability und Logging, war alles da – in unterschiedlicher Ausprägung und Tiefe. Das hörten wir auch in den User-Interviews: Die waren zufrieden mit dem, was angeboten wurde, und wollten mehr. \nMB:\n Das ist ein super spannendes Learning aus dem Projekt: Es braucht nicht unbedingt eine „shiny“ Plattform, um Platform Engineering erfolgreich zu betreiben. Im Kern geht es um gute Leistungen, gute Services, die man als Team der eigenen Firma zur Verfügung stellt. Es war sehr erhellend zu sehen, dass nicht mit einem Tool wie Backstage angefangen wurde, sondern mit den Problemen, die man in der Softwareentwicklung hat. Bei 2000 Menschen in der Entwicklung kommt natürlich irgendwann eine neue Ebene dazu, nämlich die Metaebene: Wie benutze ich die Plattform möglichst effizient?\n„Im Kern geht es um gute Leistungen, gute Services, die man als Team der eigenen Firma zur Verfügung stellt.“\nFreedom and Rules \nVV\n: Was extrem spannend war, denn diese grundsätzliche Diskussion haben wir auch unabhängig von Platform Engineering immer wieder, war die Frage: Wie viel schreibe ich den Teams vor und wie viel Freiheit gebe ich? Das war dort in meinen Augen sehr ungewöhnlich, denn die Teams hatten sehr viel Freiheit. Wir sagen immer „Freedom and Rules“. Es muss eine Balance geben. Meine Lieblingsanekdote: Jemand, der sehr erfahren war und den wir interviewt haben, sagte, es gebe zu wenige Regeln. Aber dann sagte er wenig später, dass er sich selbst an gewisse Regeln nicht halte. Diesen Kampf haben wir immer wieder, sobald ein Team anderen Teams etwas bereitstellt oder vorschreibt – berühmt-berüchtigt: die Enterprise-Architektur im Elfenbeinturm. Das gab es dort in dieser Form nicht, und das tat auch manchmal weh. Aber das Angebot war einfach gut. Ich hatte nicht nur ein fertiges Kubernetes, sondern auch ein Kubernetes, das schon mit allem verknüpft war, was ich brauchte. Nicht ganz \nout of the box\n, aber es war der berühmte \nGolden Path\n, ein Spotify-Begriff. Das ist ein Riesengewinn. Marc Schnitzius \nsprach von „Cognitive Load“\n. Ich sage ganz banal: Aufwand runter. Ich schaue eher mit einer Management-Brille darauf. Ich will den Aufwand, der nicht notwendig ist, der keinen Value generiert, aus dem Value-Stream-Teams rausnehmen. Das klappt [in dem Unternehmen] einfach gut, weil das Angebot größtenteils schlüssig und aus einem Guss ist und funktioniert.\nMB: \n„Freedom and Rules“ hat bei diesem Kunden auch eine große Auswirkung darauf gehabt, wie die Plattform wahrgenommen wurde. Dadurch, dass die Teams am Ende die Entscheidungshoheit darüber hatten, die Plattform zu nutzen oder nicht zu nutzen und sich selbst etwas zusammenzustellen, eignete man sich implizit die Produktdenkweise an. Man fragte sich, welche Probleme der Teams es wirklich zu lösen gilt, damit die Plattform Traktion erfährt. Das führt zu einer sehr produktorientierten Denkweise im Plattform-Team. In anderen Unternehmen wird den Entwicklungsteams eher etwas vorgeschrieben, was sie als Standard-Entwicklungsprozess nutzen müssen.\nVV:\n Eines der wenigen Dinge, die vorgeschrieben waren: Wenn du in die Cloud gehen wolltest, war ein bestimmter Cloud-Provider vorgeschrieben, und du hast über das Plattform-Team einen Account bekommen. Das fand ich sehr gut. Das sind Basics. Das muss einfach gesetzt sein, sonst herrscht völliges Chaos. Aber in diesem Cloud-Account hätte ich tun und lassen können, was ich will. Ich hätte mit Haskell in Lambda mit einer selbstgestrickten MongoDB arbeiten können. Als ehemaliger Entwickler finde ich das toll. Als Mensch, der den Wildwuchs beherrschen muss, habe ich Angst. Es war gut zu sehen, dass das gut funktioniert hat. \nMB: \nEines der Architekturprinzipien, die sie beim Kunden angewendet haben, war: „You can use the new fancy stuff if you've tried out the old boring stuff first.“ Das hat sehr bei mir resoniert, weil es herrlich pragmatisch ist und gleichzeitig dem Drang, technisch Neues auszuprobieren, entspricht.\nVV:\n Der enge Kontakt mit den Nutzern ist das beste Mittel gegen den Elfenbeinturm. Wir kennen Kunden, wo sich die Enterprise-Architektur etwas ausdenkt, und alle sechs Wochen gibt es ein Architecture Board, bei dem man etwas vorstellen muss, und dann sagen die „Nein“, schicken dich zurück, und sechs Wochen später darfst du wiederkommen. Das gibt es dort [beim Kunden] nicht. Klar, es hat auch Nachteile, wenig vorzuschreiben. Bei Security ist bei uns immer die Grenze erreicht. \nMP: Wenn ihr das Thema Platform Engineering jetzt mit dem erweiterten Horizont beschreiben müsstet, würdet ihr es jetzt anders sehen als am Anfang des Projekts?\nVV: \nWas [beim Kunden] noch besser sein könnte, ist der Produktgedanke. Sie haben eng mit ihren Nutzern gearbeitet, aber eher mit denen, die ohnehin laut waren, weil sie sie gut kannten. Richtig wäre es herauszufinden, welche Nutzergruppen es gibt und wie groß sie sind und danach vorzugehen. Gerade in dieser Größe würde ich jedem dazu raten.\nDas zweite, was ich anders machen würde, ist das Thema Self-Service. Einfach loslegen zu können würde eine deutliche Beschleunigung ermöglichen. Das betrifft nur den Start eines Projekts, eines Services, das muss man sich auch klar machen. Wenn ich die Hürde niedrig halten möchte, gerade am Anfang einer Plattform, wenn sie noch nicht so ausgereift ist, möchte ich, dass die Leute sie benutzen.\nPlattformen auf der Plattform\nMP: Habt ihr bei dem Kunden irgendwelche Patterns gesehen, die für euch ein Augenöffner waren?\nMB: \nSie haben ein Kern-Plattform-Team, das die einzelnen Plattform-Services aufbaut und zur Verfügung stellt. Dadurch, dass sie eine derart große Organisation sind, die in unterschiedlichen Verticals, Produkten und Sparten aufgeteilt ist, haben sich „Platform-on-top-of-platform-Teams“, wie wir sie nannten, gebildet, die die Plattfom-Services genutzt haben, um eigene Mehrwerte neu zu kreieren, beispielsweise, um ein Applikations-Template für ihren spezifischen Bereich neu aufzubereiten, um die Entwickler, die in ihrem Bereich tätig sind, mit einer noch „fertigeren“ Lösung zu unterstützen. Das war ein interessantes Pattern, von dem wir am Anfang noch nicht sicher waren, ob es gut ist oder nicht. Am Schluss kamen wir zu der Erkenntnis, dass es ein sehr positives Zeichen ist, dass es eine lebende Plattform ist, wenn sich diese Teams bilden, wirklich damit arbeiten und eigene Lösungen auf Basis einer Plattform bauen. Denn genau das ist es, was man mit einem Plattform-Gedanken erreichen will. \nVV\n: Es gibt Schichten: ganz unten das Netzwerk, dann kommt vielleicht der Cloud-Provider, dann das Plattform-Team. Ganz oben sind die Value-Stream-Teams. Und wir dachten wirklich erst, zwischen Plattform-Teams und Value-Streams braucht es nichts mehr. Aber wenn ich z. B. einen großen E-Shop baue und darin 30, 40 oder 100 Services habe, haben diese Services in diesem Produkt ähnliche Anforderungen: Sie müssen in die gleiche CI/CD-Pipeline-artige Struktur hinein usw. In der Größe will ich das nicht für 2000 Entwickler standardisieren. Das wäre Wahnsinn. Ich würde völlig stillstehen. Deswegen sage ich, wie Marc, das ist gut. Wie auch Marc dachte ich zuerst: „Das riecht komisch.“ Jetzt sage ich: „It smells like green apples.“\nMB\n: Eine spannende Frage ist: Wie sieht es in Unternehmen aus, die nicht 2000 Menschen in der IT haben? Ich glaube tatsächlich, dass das, was in diesen „Platform-on-top-of-platform-Teams“ passiert ist, durchaus in einem kleineren Kontext in das Plattform-Team hineingezogen werden kann oder sollte. Sie haben sich Blaupausen bzw. Applikationstemplates überlegt – was Projekte, Produkte oder Applikationen sind, die sie häufig bauen, die man als Standard definieren kann – und eine technische Infrastruktur darunter gelegt, um diese skalierbar und wiederverwendbar zu machen. Das kann für ein Plattform-Team viel Mehrwert generieren. \n„Ab acht Teams muss man schon gute Gründe haben, sich aktiv gegen ein Plattform-Team zu entscheiden.“\nVV\n: Sie haben auch Support für ihre Leute geleistet und sie enablet, weil sie deren Fehlersituationen viel besser kennen als ein Plattform-Team für 2000 Leute. Wir glauben, dass dieses Pattern erst ab dieser einer Größe relevant wird. \nWir haben neulich darüber diskutiert, ab wann sich ein Plattform-Team lohnt. Es gab sehr unterschiedliche Meinungen, von „ab zwei Teams“ bis „ab acht Teams“. Wir haben keine finale Meinung. Wir haben festgestellt, dass man ab dem zweiten Team Dinge gleich handhaben muss – etwa, weil das zweite Team einfach nur ein Split des vorherigen Teams ist – und dass man ab dem vierten oder fünften Team auf jeden Fall darauf achten muss, um nicht irgendwann überrollt zu werden und dann hinterherlaufen zu müssen. Eine Daumenregel, auf die ihr mich aber bitte nicht festnagelt: Ab acht Teams muss man schon gute Gründe haben, sich aktiv \ngegen\n ein Plattform-Team zu entscheiden.\nMP: Was sind weitere Punkte, die nicht unter den Tisch fallen sollten?\nVV: \nEine Anekdote: Wir machen am Ende von Projekten immer eine Retrospektive. Die projektexterne Kollegin, die diese moderiert hat, war vorher schon etwas neidisch, weil das alles spannend klang. Hinterher sagte sie: „Jetzt bin ich noch neidischer.“ So war es auch. Das Projekt hat einfach Spaß gemacht, und das muss ich umso deutlicher sagen, weil ich am Anfang skeptisch war, ob es wirklich interessant ist. \nMB\n: Da kann ich mich voll anschließen. Mit einem „Outside View“ auf eine gewachsene Plattform zu schauen war unglaublich spannend. Wir haben viel gelernt und konnten auch glaube ich viel zurückgeben – hoffentlich! Das war sehr schön.\nVV\n: Unsere Empfehlungen kamen extrem gut an. Es war natürlich nicht wahnsinnig viel Neues, aus zwei Gründen: Wir haben ihnen vorab schon erzählt, was unsere Pläne sind, um uns früh Feedback zu holen, damit wir nicht aus deren Sicht in eine falsche Richtung laufen. Wir haben versucht, die Schwerpunkte zu betonen. Denn: Die Leute im Platform Engineering kommen aus der Technik. Gerade die, die früh angefangen haben und viel gemacht haben, kennt das: Dies wird gebaut, jenes hinzugefügt. Dadurch verringert sich die Innovationsgeschwindigkeit, gerade in den Bereichen, die wirklich ausgereift sind. Daher waren sie etwas enttäuscht. Wir arbeiten ja gerne mit der Simon-Wardley-Metapher \n„Pioneers, Settlers, Town Planners“\n. Die Pioneers am Anfang legen einfach los, machen einfach. Wenn dieselben Leute nach drei, vier Jahren immer noch da sind, wird denen langweilig. Denn es bedeutet viel Maintenance. Da brauche ich die Settler oder die Town Planner. Das war ein Effekt, den wir sehr deutlich dort sehen konnten: Die [Pioneers] wollten – natürlich – am liebsten neue Technologien, neue Features machen, und wir haben uns bemüht, sehr nachdrücklich zu sagen: Ihr seid in vielen Bereichen an einer anderen Stelle. Ihr müsst euch vor allem um die Leute kümmern, die neu reinkommen und nicht nur „Fancy Sh...“ machen. So waren sie natürlich nicht, ich übertreibe jetzt. Die waren richtig schlau, deswegen hat die Zusammenarbeit auch unglaublich Spaß gemacht.\nMP: Ich danke euch beiden sehr für eure Zeit! \nVV: \nVielen Dank auch an dich!\nDieses Gespräch führten Marc, Pascal, Marco und Max im Rahmen unseres Podcasts SoftwerkerCast. Weitere Folgen unter \nhttps://www.codecentric.de/softwerkercast\n\n\n\n

„Der enge Kontakt mit den Nutzern ist das beste Mittel gegen den Elfenbeinturm“

Cloud FinOps bietet einen etablierten Prozess, um Kosten für den Cloudbetrieb zu reduzieren (s. auch [diesen Artikel](https://www.codecentric.de/wissens-hub/blog/was-ist-finops)). Zu diesem Zweck bietet es ein etabliertes Cloud-unabhängiges Vorgehen, das eine Organisation schrittweise aufgreifen kann.
Das Tooling ist vorhanden, nutzt Daten aus den Cloud-Accounts und hilft im täglichen Geschäft.

## FinOps vs. DevOps ##
Der Begriff FinOps hat in erster Näherung eine Verbindung zum DevOps-Begriff. Bei DevOps geht es um die stärkere Zusammenarbeit der Development- und Operations-Abteilungen entlang der Wertschöpfungskette über Abteilungsgrenzen hinweg. Es ist wichtig zu beachten, dass FinOps nicht nur eine technische Initiative ist, sondern auch eine organisatorische und kulturelle Veränderung erfordert, um den Fokus auf Kosten und Wirtschaftlichkeit in der gesamten Organisation zu fördern. Dies kann die Implementierung von Tools und Prozessen, die Schulung von Teams und die Schaffung einer finanziellen Transparenz umfassen. 

## Cloud-Kosten im Blick behalten ##
Bei FinOps geht es um den Blick auf die Kosten der Cloud-Ressourcen durch alle Beteiligten. In vielen Organisationen, die wir begleitet haben, können Ressourcen bezogen werden, jedoch sind die Kosten für die tägliche Arbeit nicht transparent und im Normalfall nicht für die Optimierung handhabbar.
Bei der Entwicklung einer Funktionalität ist es damit nicht möglich, die Kosten zu sehen, wodurch diese Metrik nicht optimiert wird. Im Resultat steigen die Cloud-Kosten, im schlimmsten Fall ohne eine Erhöhung der Wertschöpfung.

In der On-Premises-Welt ist die Kostenerhebung und -verrechnung ein etablierter Prozess. Vereinfacht gesprochen wird der Bedarf nach Hardware und Infrastruktur für die nächsten Jahre geschätzt und darauf basierend angeschafft. In der On-Premises-Umgebung erfolgt die Kostenverwaltung durch Schätzungen und Anschaffungen von Hardware mit definierten Lebenszyklen. Die monatlichen Kosten werden nach einem festen Schlüssel auf die genutzten Applikationen verteilt, was eine transparente und kontrollierte Ressourcenverwaltung ermöglicht.

## FinOps einführen ##
Machen wir doch einfach FinOps! Ein gelebter Wandel ist nicht mit einem großen Sprung vollzogen, daher bietet das FinOps-Vorgehen die Phasen des „crawl“, „walk“ und „run“ an, um den organisatorischen Fortschritt darzustellen. Am Anfang finden noch viele Dinge manuell statt und werden weiter optimiert und, wenn möglich, automatisiert, um eine höhere Geschwindigkeit zu erreichen.
Wichtig ist hierbei, im Laufe des Prozesses die Unit Economics in den Fokus zu holen. Wie viel kostet es, einen Artikel in den Warenkorb zu legen, oder wie teuer sind die Cloud-Ressourcen pro Kunde? Die Idee ist, diejenigen Kosten zu identifizieren, die nicht zur Wertschöpfung beitragen, um sie gezielt zu reduzieren, während gleichzeitig diejenigen Ausgaben, die das Geschäft vorantreiben, bewusst akzeptiert werden. Dies ermöglicht eine optimierte und zielgerichtete Kostenkontrolle in Bezug auf die Leistungsfähigkeit des Unternehmens.

## Kein Blindflug ##
Durch FinOps sollen nicht blind Kosten gespart werden. Wir beziehen die Cloud-Kosten auf Metriken, die den Geschäftserfolg darstellen. Mehr Bestellungen in einem Online-Shop sorgen für höhere Cloud-Kosten, jedoch ist dies gewollt. Wir wollen nur die unnötigen Kosten sichtbar machen und reduzieren.

## Wie ist unser erprobtes Vorgehen? ##
Wir arbeiten in einem Framework, das im ersten Schritt eine kurze Vorarbeit benötigt, in der die Rahmenbedingungen wie Stakeholder und Verantwortungen abgestimmt werden. Das Framework bietet viele Aspekte, wobei wir einen Start wählen, der schnell erste Einsparungen erlaubt.

Bevor wir optimieren können, müssen wir den aktuellen Zustand erfassen können. Hier liegt die Arbeit darin, das aktuelle Account- und Tagging-Modell zu verstehen und bei Bedarf zu optimieren.
Die Aufgaben und Wünsche aller Beteiligten müssen über Tags und Accounts darstellbar sein, um darüber Auswertungen zu ermöglichen.

Es bietet sich an, wenn man auf der grünen Wiese startet, das Tagging und die Account-Struktur von Anfang an zu planen und umzusetzen.
Bei vorhandener Infrastruktur ist es möglich, mit einem Pilotprojekt zu starten, um die ersten Erfahrungen in der Organisation zu machen. Ein großer Vorteil für Unternehmen, die auf Aspekte des [Platform Engineering](https://www.codecentric.de/leistungen/platform-engineering) setzen, da die benötigten Anpassungen mit weniger Aufwand in der Breite umgesetzt werden können. Technisch ist es z. B. über Terraform oder [Crossplane](https://www.codecentric.de/wissens-hub/fachmedien/crossplane-gitops-fuer-die-multi-cloud) möglich.

Jeder Cloud Service Provider verfügt über eigene Billing-Komponenten, die eine Auswertung der Kosten ermöglichen und Vorschläge zur Kostenreduktion bieten. Nachdem die Tagging-Strategie umgesetzt ist, werden diese Auswertungen hilfreich. Ein erstes Arbeiten ist damit möglich, um die Sparpotenziale zu erkennen.
Sehr gute Ergebnisse erzielen wir bei der Verwendung von FinOps-Tools, die direkt mit den Umgebungen arbeiten. Über diesen Weg werden viele Möglichkeiten der Kosteneinsparung aufgezeigt, die übernommen werden können. Ein Begriff, der an dieser Stelle oft genannt wird, ist „Rightsizing“ und bedeutet, dass Services in einer genau passenden Größe verwendet werden. Um ein Gefühl dafür zu geben, wie es in der Praxis aussehen könnte: Zu große Compute-Instanzen fallen dabei auf.

An dieser Stelle wird das Show-Back und Charge-Back für die Beteiligten relevant. Show-Back bedeutet, dass Kosten der Entstehung zugeordnet werden können. Mit diesem Schritt ist es jedem Team möglich, in Echtzeit auf die Kosten zu schauen und Auswirkungen der eigenen Arbeit zu sehen.
Bei dem sogenannten Charge-Back handelt es sich um die Verrechnung der entstehenden Kosten auf die gewünschten Organisationseinheiten. Ein wichtiger Knackpunkt ist hierbei die Verteilung von verteilten Kosten, die durch ein optimales Tagging- und Account-Modell möglich gemacht werden.

FinOps-Tools sind derzeit im Trend und bieten immer mehr Funktionen zur Berichterstattung über Umweltaspekte wie Green IT und CO₂-Emissionen. Diese Tools sind nicht mehr nur auf die Kostenverwaltung beschränkt, sondern können auch umweltbezogene Metriken liefern. Dies ist im Einklang mit dem wachsenden Bewusstsein für Umweltschutz und Nachhaltigkeit in der IT-Branche.

Nach diesen ersten Schritten ist es ein individueller Weg, welche Aspekte auf dem Framework als Nächstes in den Fokus genommen werden. Wichtig ist es, den Aspekt in die Breite zu tragen und zu verankern: Aufbau eines FinOps-Teams, Aufnahme in Development Guidelines, OKR-Ziele usw. Es bietet sich an, kreativ zu sein und auch mal unkonventionelle Ideen auszuprobieren. Warum nicht einen Wettbewerb ausrufen, welches Team die größten prozentualen Einsparungen vornehmen kann?

## Ausblick ##
Dieser Artikel lieferte einen ersten Einblick in das Thema und gibt ein Gefühl für das Vorgehen. Im nächsten Artikel verknüpfen wir die Kosteneinsparungen mit einem Green-IT-Aspekt, was in den nächsten Jahren ebenfalls an Relevanz gewinnen wird.

Cloud FinOps

<p>Imagine you have a set of microservices or applications that you want to publish to the world. There are several alternatives out there that you can choose from. Most of the reverse proxies were created when container technology was not around, so you have to jump through some loops to get going. As a broadly used example we will have a peek at how to configure nginx and some of its downsides. To get our hands dirty, we will have a more detailed walk-through of the modern, dynamic Traefik reverse proxy which we will use to deploy some services.</p><h2><b>Best in class before Docker: Nginx</b></h2><p>There is quite a number of container deployments out there that use <a href="http://nginx.org/"><span>nginx</span></a>  as a front end. The configuration is easy to read and write and the C style syntax gives you a cozy feeling. A simple config to deploy a service might look like this:</p>

```p4
worker_processes 4;

events { worker_connections 1024; }

http {

upstream upstream-servers {

              least_conn;

                 server container1:80 weight=10 max_fails=3 fail_timeout=30s;

                 server container2:80 weight=10 max_fails=3 fail_timeout=30s;

                 server container1280 weight=10 max_fails=3 fail_timeout=30s;

            }

            server {

                 listen 80;

                 location / {

                        proxy_pass http://upstream-servers;

                        proxy_http_version 1.1;

                        proxy_set_header Host $host;

                    proxy_cache_bypass $http_upgrade;

                     }

                }

}
```

<p>With this config we created a simple HTTP reverse proxy on port 80. Nginx will answer the requests by forwarding these to the upstream servers. The container with the least number of active connections will be chosen from the pool. Nice configuration. Plain and easy to read.</p><p>One thing you will encounter when you deploy nginx in a mutable container enviroment is that you can’t replace containers without at least reloading the nginx configuration although the container DNS name is still the same. Nginx will cache the IP address to the container and you have to manually take care of it. You can work around this problem in many ways but still you have to take care of it.</p><p>Don’t get me wrong: I don’t want to pick on nginx. I like it and used it a lot before I switched to <a href="https://traefik.io/"><span>Traefik</span></a>  as my go to solution.</p><h2><b>Traefik</b></h2><p>There’s a more modern reverse proxy around that is able to handle dynamic container environments: <a href="https://traefik.io/"><span>Traefik</span></a> . It is a small application written in <a href="https://golang.org/"><span>GO</span></a>  tailored to the new challenges. You can use it as a frontend in a variety of environments. The simpler ones are <a href="https://www.docker.com/"><span>Docker</span></a>  and Docker Swarm, the more complex ones are <a href="https://mesos.apache.org/"><span>Apache Mesos</span></a>  or <a href="https://kubernetes.io/"><span>Kubernetes</span></a> . You can even read metadata from directory services like <a href="https://coreos.com/etcd/"><span>etcd</span></a>  or <a href="https://www.consul.io/"><span>Consul</span></a> .</p><p>Back to our application we want to deploy. Let’s imagine we have a set of services that are described in a <a href="https://docs.docker.com/compose/"><span>Docker Compose </span></a> file. We can wire up our services and deploy these. Here we can have a look at a simple configuration:</p><p>This configuration will start the <a href="https://hub.docker.com/r/emilevauge/whoami/"><span>whoami</span></a>  test image that will allow us to see our requests in a kind of echo chamber. You can start it with <span>docker-compose up</span> and call it with your browser. How can we deploy it on a specific virtual host? Let’s extend the configuration a bit by adding Docker labels.</p>

```p4

version: '3.1'

services:
  whoami:
    image: emilevauge/whoami
    networks:
      - web
    labels:
      - "traefik.backend=whoami"
      - "traefik.frontend.rule=Host:whoami.server.test"
    restart:
      always

networks:
  web:
    external:
      name: traefik_webgateway

```

<p>This is the configuration needed for Traefik to deploy our service at http://whoami.server.test . Pretty straightforward.</p><p>When you followed the example closely you might ask where Traefik is involved and you are right. Next we need to spin Traefik itself up:</p>

```p4

version: '3.1'

services:
  proxy:
    image: traefik:1.4
    command: --web --docker --docker.domain=server.test --logLevel=INFO
    networks:
      - webgateway
    ports:
      - "80:80"
      - "8080:8080"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - /dev/null:/traefik.toml
    restart:
      always

networks:
  webgateway:
    driver: bridge

```

<p>The config above takes care of starting Traefik and will connect to the hosting Docker daemon to retrieve the needed metadata. It will scan for Docker containers that are marked with labels and will publish the services accordingly. The connection is kept so that changes will be reflected without any delay.</p><p>Both services are wired together using a Docker network called call webgateway that is prefixed by the project name. If no project name is specified, the name is inferred from the directory name where the compose file is located.</p><p>You can find more configuration options on the documentation site: <span>https://docs.traefik.io/toml/#docker-backend</span>. This takes you straight to a backend configuration part. Below that there is a list of Docker labels that can be used to further configure the publishing of the services. Currently we just used traefik.backend and traefik.frontend.rule in the sample above but you can find more.</p><p>Once Traefik and the service are up you can connect to the service and test the deployment. Make sure you first start Traefik in this example because the config provides the network the services can connect to.</p><p>Have a look at the built in dashboard by pointing your browser to: <span>http://localhost:8080/</span></p><p><a href="https://media.graphassets.com/GIYAGUfjR0mGLyE7EWOW"><img src="https://media.graphassets.com/GIYAGUfjR0mGLyE7EWOW" alt /></a> </p><p>Here you can see what services are deployed and how these are configured. You see that our service is available as whoami.server.test. But since we don’t have a DNS record pointing from this name to our localhost, we need to manually set the <a href="https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.23"><span>Host header</span></a>  and call the localhost.</p>

```p9
curl -H Host:whoami.server.test http://localhost -v
```

<p>Once you have entered the command, you can see the request that is being sent to Traefik and the response that will be returned. The result will look similar to:</p>

```p4
  curl -H Host:whoami.server.test http://localhost
Hostname: 2f3de5835785
IP: 127.0.0.1
IP: 172.21.0.3
GET / HTTP/1.1
Host: whoami.server.test
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:45.0) Gecko/20100101 Firefox/45.0
Accept: */*
Accept-Encoding: gzip
Referer:
X-Forwarded-For: 172.21.0.1
X-Forwarded-Host: whoami.server.test
X-Forwarded-Proto: http
X-Forwarded-Server: b2554c36ab87
```

<h2><b>DNS</b></h2><p>To fully enjoy the power of Traefik, you need to take care of the DNS records of your deployments. But this is a one time setup, so don’t worry about it too much. One deployment we run at a customer consists of two DNS records per host. One is an A record pointing to the IP Address of the host. And the other is a CNAME record that catches all virtual hosts below this one and forwards it to the A entry. This is a simple way to locate our services.</p><p>Just a little example to show you the setup:</p>

```p4
server.test A 172.16.2.10

*.server.test CNAME server.test
```

<p>This will allow us to reach our server as server.test and whatever.server.test, youwant.server.test. When you access the site with your favorite tool like a REST service, httpie or a browser, the client will forward the target host in an HTTP header called Host. Traefik will find the right container based on this header to forward the request to.</p><p>One advantage of using virtual hosts is that you don’t need to take extra care of redirects in your web application. We ran into problems when using relative paths for deployments because nobody thought about that being an option. Once you have your environment set up, you can deploy the services as you like.</p><h2><b>Scaling out</b></h2><p>Deploying a single container is easy and we could achieve it without any great effort. But what about scaling out? What part of the config do I have to change? The simple answer is: You don’t have to change your config. Just spin up more containers and that’s it. In our simple example:</p>

```p10
docker-compose scale whoami=4
```

<p>This command will spin up four containers that will get added to the load balancer instantly. You can verify it by hitting the endpoint repeatedly and see the container name change and by having a look at the dashboard that is located on port 8080.</p><h2><b>Sticky Sessions</b></h2><p>Clearly I would strive for a stateless application backend that can be scaled independently and without any restrictions regarding the service endpoint.</p><p>Sometimes you don’t have the freedom because you are running a session-based application that doesn’t distribute the sessions in a cluster of servers. Or – if you think more of REST services – you heavily use caching of resources and you want your sessions pinned to a specific container. No matter why you want your clients to be pinned to a specific Docker container, there is an easy configuration switch to handle it:</p>

```
traefik.backend.loadbalancer.sticky=true
```

<p>This will check for a session cookie with a specific backend as a value. If the cookie is present and the backend is up, the request will be forwarded there. If the backend is down, another is chosen.</p><p>Be sure to use the upcoming 1.4 version for this feature or my patched Docker image (marcopaga/traefik:1.3.5.2) if you want to use this feature. Before these versions, the cookie path wasn’t specified so that clients tended to drop the cookie once in a while depending on the request path.</p><h2><b>Closing</b></h2><p>I’m pretty sure: It became clear how simple life can be when it comes to the deployment of your services and web applications with Traefik.<br /> If you want to play around with Traefik have a look at my <a href="https://github.com/marcopaga/Treafik-getting-started-article">sample project on github</a> . This vagrant multi machine setup will use ansible to create a local playground for you.</p>

Traefik – The modern reverse proxy

<p>In this article I want to give an overview of Tekton with the goal of explaining the basics and getting you started quickly.</p><p>According to its own homepage, Tekton wants to become the standard for CI/CD. On the one hand, it offers a framework for building cloud-native CI/CD systems in Kubernetes and, on top of that, standardized tooling for these systems. Thus, it has already found its way into Jenkins X and is the basis for <a href="https://cloud.redhat.com/learn/topics/ci-cd" target="_blank">RedHat OpenShift Pipelines</a> .</p><p>Developers who want to use a CI system benefit from the broad support, as existing pipelines and pipeline steps can be exchanged between Tekton CI implementations without effort.</p><p>The Tekton project uses Kubernetes as a platform and, at its core, represents the building blocks of a CI pipeline in the form of CRDs. A Custom Resource Definition (CRD) is a self-created Kubernetes object that can be used to make your own objects visible and usable within the Kubernetes API.</p><p>In Tekton, for example, objects such as a pipeline can be found that represent the same and can be configured by tasks that execute the individual process steps.</p><p>The entire configuration then takes place via manifests, as is usual with Kubernetes. The existing Kubernetes know-how comes into its own here, because in addition to configuration, introspection of the processes can also take place via this path.</p><p>The <a href="https://hub.tekton.dev/" target="_blank">Tekton Hub</a>  is offered as a central point of contact for tasks and pipelines maintained by the community. Many building blocks can already be found there to cover the most common steps. In addition to the public hub, it is very easy to implement specific solutions once within your own organization and distribute them reliably.</p><p>In addition to the manifests, Tekton of course also provides the <a href="https://github.com/tektoncd/pipeline" target="_blank">Kubernetes operators in the Tekton Pipelines Repository</a> . They execute the configured steps. As is common with modern CI systems, the build steps are executed within containers.</p><h2>Tekton installation</h2><p>Installation is done either by applying the Kubernetes manifests from the release page or by using the <a href="https://operatorhub.io/operator/tektoncd-operator" target="_blank">Tekton Operator</a> .</p><p>The Tekton operator is currently still in an early development phase and currently offers installation only. Instructions on how to configure the installation can be found on the <a href="https://tekton.dev/docs/operator/" target="_blank">help pages</a> .</p><p>Installation via the Kubernetes manifests is very well described in the <a href="https://tekton.dev/docs/getting-started/" target="_blank">Getting Started Guide</a> .</p><p>To quickly have a usable installation available, I recommend installing the pipeline component and the dashboard component to get a visual view of the running Tekton installation. The dashboard can be accessed from the outside via a browser.</p><h2>Ready-to-run project</h2><p>In the <a href="https://github.com/marcopaga/tekton-demo" target="_blank">GitHub project Tekton-Demo</a>  you can find a complete installation which runs with <a href="https://k3d.io/" target="_blank">K3d</a>  directly on the local system. The installation can be found in the README and is always up to date <a href="https://github.com/marcopaga/tekton-demo/blob/main/.github/workflows/create-cluster.yml" target="_blank">in the GitHub Action</a> .</p><p>After the installation has run successfully, the cluster is a running Tekton installation with tasks and pipelines installed in the namespace <code>tekton-pipelines</code>.</p><p>Since it is very easy to look in the wrong namespace I would like to recommend <code>kubectx</code> and <code>kubens</code> only briefly, because <code>kubens tekton-pipelines</code> sets the default namespace correctly.</p><p>The dashboard is accessible via a port forward and an event listener is usable via an ingress and can also already react to events, but we will get to that in another blog article.</p><h2>An example CI pipeline</h2><p>After the installation, we can already get to know the main components and use them to build a "Hello, World!" – example.</p><p>A <code>task</code> consists of a series of <code>steps</code> which are executed in order. A <code>step</code> is a self-contained command, which in the following example is named <code>hello</code>, the call to <code>echo "Hello World!"</code>. This is started and executed in a bash container, which of course can be changed to your liking.</p><p>In real use you can find commands at this point, which do a checkout, build images and much more.</p>

```
apiVersion: tekton.dev/v1beta1
kind: Task
metadata:
  name: hello
spec:
  steps:
    - name: hello
      image: bash:latest
      command:
        - echo
      args:
        - "Hello, world!"
```

<p>Also a <code>goodbye</code> task is created, which says goodbye with a <code>echo</code> command on the system console.</p><p>In this small example we will create a pipeline that calls the two tasks one after the other, so that when you look at the pipeline logs you will see both the hello and the goodbye.</p><p>Very intuitively – in my opinion anyway – we create a CRD of type <code>Pipeline</code> and define a list of tasks there, which can be provided with dependencies among each other. In this simple example we specify via <code>runAfter</code> that the farewell should take place after the greeting. <code>apiVersion: tekton.dev/v1beta1</code></p>

```
kind: Pipeline
metadata:
  name: hello-goodbye-pipeline
spec:
  tasks:
    - name: hello
      taskRef:
        name: hello
    - name: goodbye
      runAfter:
        - hello
      taskRef:
        name: goodbye
```

<p>The <code>task</code> defined above is linked via a <code>taskRef</code> so that the defined tasks are linked via it and the pipeline runs through the two steps.</p><h2>Interaction with Tekton</h2><p>As shown at the beginning, Tekton works by configuring and installing CRDs. These API objects can be retrieved and manipulated directly via <code>kubectl</code>, through which a traceable API is mapped. Installed pipelines can be retrieved easily:</p>

```
# kubectl get pipelines.tekton.dev --all-namespaces -o wide
NAMESPACE          NAME                     AGE
8
tekton-pipelines   hello-goodbye-pipeline   1s
9
```

<p>Furthermore it is of course possible to start a pipeline. In the repository you can find a <code>PipelineRun</code> which I show in the following:</p>

```
apiVersion: tekton.dev/v1beta1
kind: PipelineRun
metadata:
  generateName:  hello-goodbye-pipeline-
spec:
  pipelineRef:
    name:  hello-goodbye-pipeline
```

<p>The configuration provides a prefix for the generated runs via the <code>generateName</code> attribute. It also provides a reference to the pipeline to be used, which we created during the installation and looked at in the course of this article.</p><p>How to start a pipeline? Now we need another API object, the <code>PipelineRun</code>. This object brings the necessary parameters – in our case none yet – in connection with the pipeline to be executed. As a user, we can get the status and also the log output by reference to the generated run.</p><p>Here we go:</p>

```
kubectl create -n tekton-pipelines -f ./hello-goodbye-pipeline-run.yaml
```

<p>And as already indicated, we retrieve all the runs:</p>

```
kubectl get pipelineruns.tekton.dev --all-namespaces -o wide
NAMESPACE          NAME                             SUCCEEDED   REASON      STARTTIME   COMPLETIONTIME
8
tekton-pipelines   hello-goodbye-pipeline-v5h5l   True        Succeeded   13s         1s
```

<p>Here you can see the existing status fields of this object. For black-box testing, we can therefore wait for the <em>PipelineRun</em> status to change to <code>Succeeded</code> to detect the passing of a pipeline.</p><p>In addition to the direct interaction with <code>kubectl</code>, Tekton offers a specialized command line interface (CLI) that interacts directly with the cluster via the currently used Kubernetes context. Many Kubernetes-based tools come with a suitable CLI to work efficiently with the platform. <code>tkn</code> is the corresponding Go binary which can be run on different platforms without any problems. Installation instructions can be found in the <a href="https://github.com/tektoncd/cli" target="_blank">GitHub repository</a> .</p><p>With this CLI, it is then easier to retrieve e.g. the tasks and pipelines. Here is a short example:</p>

```
tkn task list --all-namespaces
tkn pipeline list --all-namespaces
```

<p>These two calls show all existing tasks and pipelines in all namespaces.</p><p>The inspection of the logs is done by this command:</p>

```
tkn pr logs $PIPELINE_RUN_NAME
```

<p>The output of all tasks is collected and traceable here and looks like this:</p>

```
[hello : hello] Hello World!

[goodbye : goodbye] Goodbye World!
```

<h2>Conclusion</h2><p>We have now done the installation with little effort and also already created the first pipeline. By doing so, we have already achieved a lot and could now take the first look behind the scenes.</p><p>In the following articles we will create a buildpack pipeline and extend the build pipeline with a WebHook trigger from outside. This will allow Tekton to automatically build a container image when a push is made to a Git repository.</p>

Tekton Cloud-native CI/CD – a pragmatic intro

<p>This article is part of a series that deals with Tekton CI/CD and its practical use. <a href="https://blog.codecentric.de/en/2022/01/tekton-cloud-native-ci-cd-pragmatic-intro/">In the first article</a>  we did the installation and created the first pipeline. <a href="https://blog.codecentric.de/en/2022/02/tekton-buildpack-pipeline/">In the second article</a>  we experienced the advantages of Tekton through the clever use of the reusable components.</p><p>This article is about embedding Tekton in a project context. The goal for this article is to first lay the groundwork for this. We will open a WebHook interface with Tekton Triggers and send a GitHub WebHook JSON object which starts a build in the Tekton installation.</p><h2>Possible use</h2><p>What do I mean by a “project context” at this point? So far we have been running Tekton in an isolated setup, which is not helpful in practice, since the developer experience suffers because of lost transparency of build states. The overall view is spread over at least two systems which are not linked to each other. Even worse, Tekton has to be started manually so far.</p><h2>Why not just use the integrated?</h2><p>The trend with the big platforms like <a href="https://github.com/" target="_blank">GitHub</a>  or <a href="https://about.gitlab.com" target="_blank">Gitlab</a>  is to integrate the development tools. Starting with the Git repository, to a pipeline solution like <a href="https://github.com/features/actions" target="_blank">GitHub Actions</a> , to the <a href="https://github.blog/2019-05-10-introducing-github-package-registry/" target="_blank">Container Repository</a> , to the integration of the <a href="https://about.gitlab.com/blog/2018/08/02/4-ways-to-use-gitlab-issue-boards/" target="_blank">Organization Tools</a> . The underlying reason for this is to increase transparency.</p><p>This is countered by the use of Tekton for the CI/CD execution aspect. This makes sense when the desire for compliance, reusability and supposed future viability increases. The <a href="https://github.com/tektoncd/community/blob/main/roadmap.md#mission-and-vision" target="_blank">directional vision</a>  is to spread API compatibility and build a broad eco-system. Of course, this is only the beginning of a journey and it remains to be seen if this is realistic. For decisions concerning the CI/CD system, future viability is an interesting criterion from my point of view.</p><p>Feel free to write your opinion in the comments or give feedback via <a href="https://twitter.com/m_p_dus" target="_blank">Twitter</a> .</p><h2>Triggers installation</h2><p>Tekton Triggers are another component that needs to be installed in the cluster. For this we can follow the installation instructions in the <a href="https://github.com/tektoncd/triggers" target="_blank">GitHub – Project</a>  to import the necessary manifests. In the chapter “<a href="https://github.com/tektoncd/triggers/blob/main/docs/install.md#setting-up-tekton-triggers" target="_blank">Setting Up Tekton Triggers</a> ” you can find the two files which can be imported via the tool of choice.</p><p>The file named release.yaml contains the whole Triggers base installation and the interceptors.yaml file brings <a href="https://tekton.dev/vault/triggers-main/interceptors/#overview" target="_blank">interceptors</a>  for easy connection to systems like gitlab, github or bitbucket. These should be installed as well, because we will use an installed <code>ClusterInterceptor</code> later on. In the next section I will describe what purpose these have.</p><p>At this point just the short hint that the Tekton – installation including the Tekton Triggers is ready built in my GitHub project. Just clone and test it. Everything important can be found in the README.md or in the github action which tests the code on every push.</p><h2>Triggers API objects</h2><p>The Triggers API looks very complicated at first glance, at least that’s how it looked to me. Best we go through step by step and understand what each object is used for. Here is my short <a href="https://remarkable.com/referral/NT3R-9TVK" target="_blank">Remarkable – note</a>  which helped me a lot in finding my direction:<br /> <img width="1024" height="1090" src="https://media.graphassets.com/d5mjEF6TveAGHMvkNVzs" alt /></p><h3>EventListener</h3><p>Our goal is to receive a WebHook from the outside. On the Kubernetes side, this means that a service provides a TCP port that can be used for this purpose. As an anchor, the EventListener is described and linked to the other objects. Besides the <code>ServiceAccount</code> to be used, the triggers are attached at this point. Behind an EventListener any number of triggers can listen to different requests.</p><p>By creating the EventListener, the described service is automatically created. Just briefly for classification: This service is only available in the cluster and, depending on the use case, can be made visible to other applications outside the cluster, for example, by means of an <code>Ingress</code>.</p><h3>Trigger</h3><p>The task of the trigger is based on assigning and processing the requests by using interceptors, TriggerBindings and TriggerTemplates. The trigger has a name and everything else is used in the objects used.</p><h3>Interceptor</h3><p>WebHooks are often called by specific systems. In the case of Tekton, these are Git repositories such as Gitlab or Github. The formats of the invocation and the security mechanisms used differ between the systems.</p><p>For example, a <a href="https://github.com/tektoncd/triggers/tree/main/examples/v1beta1/github" target="_blank">WebHook from Github</a>  is secured with an HMAC of the payload and a secret string whereas by <a href="https://github.com/tektoncd/triggers/tree/main/examples/v1beta1/gitlab" target="_blank">Gitlab</a>  an <code>X-Gitlab-Token</code> HTTP header is added with a secret.</p><p>We can use the appropriate interceptor, define the necessary secret and event type.</p><h3>TriggerBinding</h3><p>With this binding we access the JSON body of the request and extract the necessary information such as the URL of the git repository and the branch name.</p><p>The extracted values are then usable as parameters and can be used in the last object.</p><h3>TriggerTemplate</h3><p>At this point, the actual call is now made, namely the extracted parameters are referenced here and made available to a template, e.g. a PipelineRun. The PipelineRun is started with a WebHook call.</p><h2>Practical implementation in the sample project</h2><p>Here the <a href="https://github.com/marcopaga/tekton-demo/blob/2bf387b0df0563fe7d6238d03282d5de49f050c9/tekton-triggers/gitlab-trigger-pipeline-listener.yaml" target="_blank">complete example from the demo project</a> :</p><div>

```yaml
apiVersion: triggers.tekton.dev/v1beta1
kind: EventListener
metadata:
  name: gitlab-listener
spec:
  serviceAccountName: tekton-triggers-gitlab-sa
  triggers:
    - name: gitlab-push-events-trigger
      interceptors:
        - name: "verify-gitlab-payload"
          ref:
            name: "gitlab"
            kind: ClusterInterceptor
          params:
            - name: secretRef
              value:
                secretName: "gitlab-secret"
                secretKey: "secretToken"
            - name: eventTypes
              value:
                - "Push Hook"
      bindings:
        - name: git-revision
          value: $(body.checkout_sha)
        - name: git-repository-url
          value: $(body.repository.git_http_url)
      template:
        spec:
          params:
            - name: git-revision
            - name: git-repository-url
          resourcetemplates:
            - apiVersion: tekton.dev/v1beta1
              kind: PipelineRun
              metadata:
                generateName: show-parameter-triggered-pipeline-
              spec:
                pipelineRef:
                  name: show-parameter-pipeline
                params:
                  - name: image
                    value: test-image-build-by-buildpack-and-triggered:latest
                  - name: git-repository-url
                    value: $(tt.params.git-repository-url)
                  - name: git-revision
                    value: $(tt.params.git-revision)
```

</div><p>In the example, the call by a Gitlab instance is simulated by a curl. The call contains, as described for the interceptors, the necessary secret and the actual data of the call.</p><div>

```bash
curl -v \
-H 'X-GitLab-Token: 1234567' \
-H 'X-Gitlab-Event: Push Hook' \
-H 'Content-Type: application/json' \
--data-binary "@gitlab-push-event.json" \
http://localhost:8081
```

</div><p>In this short excerpt I would like to describe how a mapping to the call can take place, because on the one hand this call is a fire-and-forget solution, but on the other hand it can be necessary to trace the Tekton processing in the context of a debugging. This is possible because Tekton Triggers returns a JSON object which defines an event ID. This event ID is passed as a label to the PipelineRun which can then be identified by it. The following snippet shows this in practice and can <a href="https://github.com/marcopaga/tekton-demo/blob/2bf387b0df0563fe7d6238d03282d5de49f050c9/.github/workflows/create-cluster.yml#L77" target="_blank">be found in full here</a> .</p><div>

```bash
EVENT_ID=$(./trigger-tekton.sh | jq -r '.eventID')
          echo "EVENT-ID found in the response of the web-hook call${EVENT_ID}"
          # Wait for the triggered PipelineRun to complete
          kubectl -n tekton-pipelines wait --for=condition=SUCCEEDED=True --timeout=60s pipelineruns.tekton.dev -l triggers.tekton.dev/triggers-eventid==$EVENT_ID
```

</div><h2>Conclusion</h2><p>This article shows with a practical example how Tekton can be integrated and used in an existing environment. At this point we have built a CI system that automatically starts pipelines when a push has occurred.</p><p>How does the series continue? As announced, a post will follow showing the integration with Gitlab in a practical way, based on an AWS EKS cluster. What comes after that is still open: It would be possible, for example, to develop a separate task and make it available or to turn in the direction of <a href="https://tekton.dev/docs/chains/" target="_blank">supply chain security</a> .</p><p>If you have any questions or comments about the post, I would be happy to receive feedback from you here on the blog, by email or on <a href="https://twitter.com/m_p_dus" target="_blank">Twitter</a> .</p>

Tekton Triggers in practice

<p>In the <a href="https://blog.codecentric.de/en/2022/01/tekton-cloud-native-ci-cd-pragmatic-intro/" target="_blank">first article</a>  we mastered the Tekton installation, got to know the first API objects and created a first small pipeline. You might want to have a look at this <a href="https://remarkable.com/referral/NT3R-9TVK" target="_blank">Remarkable – note</a>  for a recap.<img width="1024" height="768" src="https://media.graphassets.com/EYMB79Quqrq5qF7isPAg" alt="Tekton Building Blocks" /><br /> Now we will create a practical pipeline that, as usual for a CI system, creates new Docker images when new commits are pushed. The reusability of Tekton components, both tasks and entire pipelines, is a strength that I would like to demonstrate practically in this article.</p><h2>How do we build?</h2><p>We can build container images in several ways.</p><p>Docker, the company that brought containers to the mainstream, defined writing a <code>Dockerfile</code> which built a container image step by step triggered by a <code>docker build</code>. Writing this starts very simple, but it quickly becomes very complex if you want to ensure a secure, stable build and operation.</p><p>I would like to set only two impulses that you might want to think through to get a clue of stuff to be taken care of:</p><ul><li>Should the CI system really pass a Docker socket to the build containers?</li><li>Should the root user really be used within the Docker image?</li></ul><p>For these topics there are many possible solutions. I will highlight the buildpack approach.</p><p><a href="https://buildpacks.io/" target="_blank">Cloud-Native Buildpacks</a>  are a simple solution to create container images. So what to do? You just need a <code>pack build my-image</code> to build the application in the current directory as a <code>my-image</code> and store it in an image repository. Admittedly, the solution is very easy to use, but at the same time a lot happens in the background to ensure an optimal image build. Issues like e.g. caching and security are solved transparently.</p><h2>Integration in Tekton</h2><p>We will need a pipeline that runs the required tasks step by step. The pipeline will first clone the source code from a Git repository and place it in a directory. The second step will read the source code in that directory and use buildpack tooling to build the image and push it to a container registry.</p><p>In the first article we looked at how to create a pipeline and link tasks but we haven’t worked with files yet.</p><h2>Workspaces</h2><p>Directories can be shared between tasks in Tekton using workspaces. Workspaces can leverage various Kubernetes storage types, for example, a <em>PersistentVolumeClaim</em>, a config map, or an <em>emptyDir</em>.</p><p>When defining a pipeline, we define the required workspaces. In our case, we define a workspace to store the source code from the Git repository for the runtime of the pipeline. At this point, only the name and the link to the tasks are known. Tasks can expect workspaces which can then be deployed under a specific name by the pipeline.</p><p>Here we see a short pipeline that clones the source code from a Git repository into a workspace named <em>source-workspace</em>.</p><div>

```yaml
apiVersion: tekton.dev/v1beta1
kind: Pipeline
metadata:
  name: git-clone-sample-pipeline
spec:
  params:
    - name: git-clone-url
      type: string
      description: HTTP URL of the git repository to clone
    - name: git-revision
      type: string
      default: "main"
      description: Git revision (branch, tag, commit-id) to clone
  workspaces:
    - name: source-workspace # Directory where application source is located. (REQUIRED)
  tasks:
    - name: fetch-repository # This task fetches a repository using the `git-clone` task you installed
      taskRef:
        name: git-clone
      workspaces:
        - name: output
          workspace: source-workspace
      params:
        - name: url
          value: $(params.git-clone-url)
        - name: revision
          value: $(params.git-revision)
        - name: subdirectory
          value: ""
        - name: deleteExisting
          value: "true"
```

</div><h2><em>PipelineRun</em></h2><p>As already described in the first article, we create a <code>PipelineRun</code> to start the pipeline and to pass parameters and workspaces.</p><p>In the following example, we start the pipeline defined above with the desired values. The Git repository is set to a fixed value and the <code>source-workspace</code> is linked to an existing <code>PersistentVolumeClaim</code>.</p><div>

```yaml
apiVersion: tekton.dev/v1beta1
kind: PipelineRun
metadata:
  generateName: git-clone-sample-pipeline-
spec:
  serviceAccountName: tekton-service-account
  pipelineRef:
    name: git-clone-sample-pipeline
  workspaces:
    - name: source-workspace
      subPath: source
      persistentVolumeClaim:
        claimName: source-workspace-pvc
  params:
    - name: git-clone-url
      value: https://github.com/marcopaga/feeding-the-ci-process-single-project.git
```

</div><p>Now the pipeline starts, clones the repository, and terminates successfully.</p><h2>Providing credentials for clone and push</h2><p>For open source projects with a publicly available repository, this is it. For internal use with credentials on a repository, we still need to provide them to the Git process.</p><p>While researching this aspect, I found various pieces of information. For me the variant which is described there worked well. In essence, a Secret is created with the credentials and extended with annotations describing what deployment and what server it is to be used for. The key <code>tekton.dev/git-0</code> indicates that this is to be used for github.com repositories.</p><div>

```yaml
apiVersion: v1
kind: Secret
metadata:
  name: github-clone-secret
  annotations:
    tekton.dev/git-0: https://github.com
type: kubernetes.io/basic-auth
stringData:
  username: git-clone-user-name
  password: git-clone-password
```

</div><p>This on its own is not enough, because the Secrets to be used must be added to the <em>ServiceAccount</em> of the <em>PipelineRun</em>. As you can see in the following example, the Secret is simply listed as well.</p><p>For the container image push, a Secret is also needed. Here it is sufficient to create a normal <a href="https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/#create-a-secret-by-providing-credentials-on-the-command-line" target="_blank">Docker Registry Secret</a>  as described here in the Tekton Docs. It is also important to add this to the <em>ServiceAccount</em>.</p><p>In the following you can see a <em>ServiceAccount </em>with the two defined Secrets.</p><div>

```yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  name: buildpacks-service-account
secrets:
  - name: docker-registry-secret
  - name: gitlab-clone-secret
```

</div><h2>Using an existing pipeline and tasks</h2><p>Now we have already created a pipeline with which we can clone the code. We can now continue with our knowledge and gradually add the next steps.<br /> On the Tekton Hub, we can find <a href="https://hub.tekton.dev/?query=buildpack" target="_blank">tasks for the build</a> . So far, so good! The tasks are well documented and actually we can build them directly.</p><p>But what’s that – you can also <a href="https://hub.tekton.dev/?query=buildpack&kind=Pipeline" target="_blank">search for pipelines</a> ? If we do that, we find a complete pipeline that is already done and tested.<br /> The buildpacks pipeline is beautifully documented. We find information about the background, the required dependencies, and the installation.<br /> As described in the first article, these are installed and used directly. The existing <code>PipelineRun</code> is adapted following the documentation and everything is ready.</p><h2>Recap</h2><p>This reusability allows us to collaborate and share CI components within our own organization and even in the open source ecosystem.<br /> We were able to create a working pipeline with very little time and effort by leveraging community components. Now we have a starting point to make our own extensions, benefit from the community of the Tekton Hub and hopefully even give back our own contributions.<br /> In the next article we will continue with Tekton Triggers on this basis and start a build of this pipeline when pushing it into a repository.</p>

Standing on the shoulders of the Tekton community: Tekton buildpack pipeline

<p>In my previous <a href="https://blog.codecentric.de/en/author/marco-paga/" target="_blank">blog posts</a>  I gave an intro to Tekton and showed how to configure and integrate it. This post will show you a way how to build CI pipelines with built-in testing.<br /> In software development, it is good practice to write tests for the code base. We see the value in our daily work in many places when it comes to further developing the software.<br /> But CI systems, although they make the safety net possible for whole teams in the first place, are often far from the principle. Build and test configurations are all too often developed and used without a net and a double bottom.<br /> This is where I would like to start and take the proven principle even further. The article describes the setup of a tested CI system using the example of Tekton with GitHub Actions.</p><h2>GitHub Actions</h2><p>GitHub Actions offer the possibility of building CI pipelines with little effort and use them for projects. My colleague Jonas wrote a wonderful <a href="https://blog.codecentric.de/en/2021/03/github-actions-nextgen-cicd/">blog post on this topic</a> , which I gladly refer to for more information.<br /> For this article it is important to know that the Actions also allow containerized execution of test code. Moreover, it is even possible to launch additional containers, which allows us to use a minimal Kubernetes cluster in the form of K3d within the test run.<br /> In the demo project used, each push runs through the pipeline and the results of the run are visible under the “Actions” tab on the GitHub pages. The configuration is done as usual with other tools by a file, which is stored in the repository under <code>.github/workflows</code>.</p><h2>Demo project</h2><p>The demo project uses GitHub Actions so that a build is started on every commit and push to the repository. The configuration of the pipeline can be found in <code>.github/workflows/create-cluster.yml</code>.<br /> Inside the GitHub action, a <a href="https://k3d.io/">k3d</a>  Kubernetes cluster is started. K3d starts a minimal <a href="https://github.com/k3s-io/k3s">k3s cluster</a>  which is provided by Rancher. Rancher offers a minimal cluster with this Kubernetes distribution which is optimal for CI operation, among other things. It requires very little memory and also the time to start is extremely low. This temporary cluster is used as a deployment target for the Tekton installation.<br /> After the cluster is available, the further installation starts with <a href="https://fluxcd.io/">Flux</a> , which is a tool used to implement the GitOps approach coined by Weaveworks. The configuration of the target cluster is managed in its entirety in git and is retrieved from there by the respective target cluster. GitOps tools and thus also Flux work pull-based compared to other declarative Infrastructure as Code tools.<br /> Perhaps the question arises: “Why Flux?”. From my point of view, it is a tiny, flexible deployment tool that allows the installation of Helm releases and simple YAML manifests with little effort. Integration into the deployment and the testing process are also quick.<br /> Flux installs the basic components of Tekton and also the desired additional components of the pipelines. Once all the installation steps have been completed, a fully-fledged CI system is available. The installation steps are mapped in the form of <code>customizations</code> which thus define the installation sequence of Kubernetes manifests. In this demo project, the Flux installation starts in <code>clusters/local/</code> and progresses from there through further references to installation files.<br /> The process outlined above runs autonomously and asynchronously. How can you tell in the CI process when the cluster is deployable? Determining this moment reproducibly, as error-free as possible and precisely is very important for testing, because otherwise there are always false positives in the pipeline, which would greatly reduce its acceptance by the teams using it.<br /> A fundamental problem is that the status of the Flux deployment is made available via a CRD, which itself is installed and made available by Flux.<br /> With on-board means of <code>kubectl wait</code> it is not possible to wait for a status change of a possibly not yet existing CRD, therefore the step “Wait for Flux CRD Deployment” was used. After this run, <code>kubectl wait</code> commands are used to wait for the successful run of the individual Flux customizations. When this has been achieved, the actual testing can begin.</p><h2>The testing</h2><p>From here on, it’s all about the test run in the ready-made K3d cluster. We start a Tekton pipeline by creating a PipelineRun as follows:</p><div>

```yaml
	apiVersion: tekton.dev/v1beta1
	kind: PipelineRun
	metadata:
	  generateName: hello-goodbye-pipeline-
	spec:
	  pipelineRef:
	    name: hello-goodbye-pipeline
```

</div><p>Interesting here is that the PipelineRun is generated according to a simple naming scheme configured via <code>generateName</code>. The prefix specified here is extended by a unique id by the system. The desired pipeline is specified via <code>pipelineRef</code>. For our simple case a sufficient configuration. More complex pipelines can have additional parameters and workspaces added here.</p><div>

```yaml
	- name: Execute and verify hello-world pipeline is run to completion
	run: |
		PIPELINE_RUN_NAME=$(kubectl create -n tekton-pipelines -f ./hello-goodbye-pipeline-run.yaml -o json | jq -r '.metadata.name')
		kubectl -n tekton-pipelines wait --for=condition=SUCCEEDED=True --timeout=60s pipelineruns.tekton.dev/$PIPELINE_RUN_NAME
		tkn pr --namespace tekton-pipelines logs $PIPELINE_RUN_NAME
```

</div><p>The <code>PipelineRun</code> shown above is started by the test and the generated name is read from the API with the Swiss Army Knife <a href="https://stedolan.github.io/jq/">jq</a> .<br /> Now we just wait for the pipeline to run successfully and report back a success if this is met.</p><p><code>kubectl -n tekton-pipelines wait --for=condition=SUCCEEDED=True --timeout=60s pipelineruns.tekton.dev/$PIPELINE_RUN_NAME</code></p><p>The GitHub Actions job is green when the pipeline has been successfully run.</p><h2>Recap</h2><p>With the approach described here, we have automated the testing of an entire CI system from the ground up. No more unpleasant surprises when a small change in the pipeline causes unwanted effects or the system has to be rebuilt. The tests are always running and make it possible for us to develop this part of the infrastructure like a product.<br /> If you have comments or questions feel free to contact me.</p>

GitHub Actions test a full Tekton CI installation

**The Open Policy Agent (OPA) is a general-purpose, open-source policy engine, i.e. a collection of components that allows for a uniform and efficient implementation of rules of all kinds. This article shows a small practical example.**

When was the last time you heard of a company or IT policy? Maybe you think of "We're supposed to make sure we set certain parameters in the Terraform script" or 
"We're supposed to make sure we don't run as root in the Kubernetes deployment."
The policy can be implemented by taking organizational action – which is a cumbersome description of a peer review or approval process – or by means of clever automation. The latter increases security on the one hand – because, let's be honest: a lot of times, some things remain unnoticed – and on the other hand, it also increases speed, since an automatic check within a pipeline is definitely faster than a human being can ever be.
I would like to take a closer look at this small example in this article, because I think that this is a nice way to speed up an in-house process through automation with little effort using the Open Policy Agent.

## OPA ecosystem
To be honest, the ecosystem is large and possible use cases are manifold. 
On the one hand, OPA provides the software components needed to execute rules at runtime, and on the other hand, it is an ecosystem with a wide variety of tools and integrations. And that's where I think the strength of this solution comes in. 
It gives us the opportunity to benefit from each other as a community, as we normally like to do in our work. 

## Usage
If we want to deploy the project, we can choose between several deployment variants. The following are the most prominent ones:

1. integration as a library, e.g. in a Go project or via Web Assembly.
2. standalone deployment as a service with REST-based API.
3. usage in a testing tool such as <a href="https://github.com/open-policy-agent/conftest" rel="noopener noreferrer" target="_blank">Conftest</a>. 

Depending on the deployment scenario, the approaches of loading and executing the data and rules differ. For example, it is possible to include the data and rules in the delivery as a package or to receive these rules from outside.

What the scenarios have in common is the general procedure: First, there is a call that is delivered to the engine from the outside. The rules are then executed and the decision is returned with meta-data. 
Conftest is the simplest tool, since in this case the rules and the input data are available and can simply be executed locally.

## Rego
This language is optimized for this purpose and inspired by Dataloc. I have to admit that I heard about it for the first time only during the research.
We can efficiently use it to define rules that are applied to structured input data. 
Documents or input data are known via a specific variable within the rule execution and can be validated via logical operations. Navigating within documents is similar to <a href="https://github.com/stedolan/jq" rel="noopener noreferrer" target="_blank">https://github.com/stedolan/jq</a> and easy, with a little practice.
That being said, we quickly move on to the obligatory "Hello, World!" example. As input data here, we use a JSON document with the Input object consisting of two attributes.
The policy checks whether the two attributes are present with the desired values.

Input data:
```yaml
{
    "greeting": "hello",
    "message": "world",
	
}

```
Policy:
```yaml
default result := false
result if {
    input.message == "world"
    input.greeting == "hello"
}
```
# Kubernetes

Input data can be any structured document, such as YAML or JSON, so Kubernetes manifests are a good example, which is why I will look at this use case in this short article.

Validation of Kubernetes manifests can be done both in the CI system and by an Admission Controller in the cluster. Within the CI system, OPA tooling is used to terminate a build with an appropriate error message. In addition, an active check can be included on the clusters in the form of the aforementioned Admission Controller. This Admission Controller rejects Kubernetes API objects that do not comply with the defined company defaults.

A small example of how to implement validation of Kubernetes manifests via the Open Policy Agent tool <a href="https://github.com/open-policy-agent/conftest" rel="noopener noreferrer" target="_blank">Conftest</a>: Conftest is a small command line tool that gets the Rego policies and deployment configuration, does the checking, outputs the result, and provides appropriate return code to act on it in the CI. 

We now implement these policies in Rego that check a deployment.

```yaml
# Referenced in the following rules to work only on deployments. Other API objects are ignored
is_deployment {
  input.kind = "Deployment"
}

# Only container images from the internal container repository should be used. Checked by a Regular Expression on the image name
deny[msg] {
    kubernetes.is_deployment
    container := input.spec.template.spec.containers[_]
    not re_match("^internal.repository.de/.+$", container.image)
    msg = sprintf("Container in Deployment %s should use an image from the internal repository", [name])
}

# We want to generate a warning if no liveness probe has been defined for a deployment. It is checked directly whether this was defined
warn[msg] {
    kubernetes.is_deployment
    container := input.spec.template.spec.containers[_]
    not container.livenessProbe
    msg = sprintf("Container in Deployment %s should define a livenessProbe", [name])
}
```

If a rule is not fulfilled, a message is returned by the msg block and is thus visible in the CI pipeline.
This is a very simple step that adds value right off the bat. If you have any questions about this, feel free to contact me directly e.g. via <a href="https://twitter.com/m_p_dus" rel="noopener noreferrer" target="_blank">Twitter</a> or by e-mail. I'll be happy to work with you to see how we can implement it.

# Further reading
This article has quickly given you a first overview of the Open Policy Agent (OPA) project and a way to use it. There are many more options to use the tool. To get a first impression of it, it is worth browsing the ecosystem page of the project.
Furthermore, we will post articles on this topic on this blog and also record a <a href="https://www.codecentric.de/softwerkercast" rel="noopener noreferrer" target="_blank">SoftwerkerCast episode</a> on this topic.

Open Policy Agent – Primer

Fragen und Anregungen?

Vielen Dank für deine Anfrage. Ich melde mich bei dir.

Vielen Dank für deine Anmeldung. Eine E-Mail zur Bestätigung ist zu dir unterwegs.

Diese Seite ist eine Vorschau. \nKlicken Sie hier\n, um den Vorschaumodus zu verlassen.

Zu deiner Suche haben wir leider keine passenden Blogartikel gefunden. 

Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.

Die \nDatenschutzerklärung\n der codecentric AG habe ich zur Kenntnis genommen und bestätige das mit der Absendung des Formulars.*

Entdecke spannende weiterführende Themen und lass dich von der codecentric Welt inspirieren.

Ich möchte eure Inhalte abonnieren. Diese Einwilligung kann ich jederzeit widerrufen bzw. den Blog Newsletter abbestellen. Die Datenschutzerklärung habe ich gelesen. Ich bin damit einverstanden, dass die codecentric AG, Hochstr. 11, 42697 Solingen, mich über eigene Dienstleistungen, branchenrelevante Events, Webinare und Publikationen der codecentric AG über die von mir angegebene E-Mail-Adresse informiert. Meine Einwilligung ist freiwillig. Ich kann meine Einwilligung jederzeit mit Wirkung für die Zukunft widerrufen (z.B. über den hierfür vorgesehenen Abmeldelink in unserem Newsletter, per E-Mail an datenschutz@codecentric.de oder per Post an die oben genannte Adresse der codecentric AG) erklären. Weitere Hinweise zur Verarbeitung meiner personenbezogenen Daten und zu meinen Rechten als betroffene Person finde ich hier: \nhttps://www.codecentric.de/datenschutzerklaerung\n

Bitte wähle deine/n gewünschte/n Standort/e aus.

Wir möchten dich als Mensch kennenlernen. Erzähle uns, wer du bist, worauf du Wert legst, wie du gerne arbeitest und was du von uns als Arbeitgeber erwartest.

Bitte füge deine Bewerbungsunterlagen ​(mind. Lebenslauf, gerne auch mehr)​​ ​als eine ​PDF-​Datei ​hinzu.

Es gilt die Datenschutzerklärung der codecentric AG, abrufbar unter \nDatenschutzbestimmungen\n. Mit dem Absenden des Formulars bestätige ich, dass ich diese zur Kenntnis genommen habe.

Job application form field placeholder 10

Keine passende Rolle gefunden? Bewirb dich bitte trotzdem initiativ! Jenseits von starren Schubladen zählen für uns vielmehr Motivation, Kompetenz und der Cultural Fit.

Job application form field placeholder 11

Dies ist ein Pflichtfeld, bitte fülle es aus.

Absenden

SoftwerkerCast - der IT-Podcast von Techies für Techies

Jetzt abonnieren

Hast du Fragen?

Mehr laden

Hier gibt's noch mehr vom Softwerker

Der Softwerker – Das Magazin

Zu den Ausgaben

SoftwerkerKonf

Zur SoftwerkerKonf

Unser SoftwerkerCast-Team

Fragen und Anregungen?

Schreibt uns

Gemeinsam bessere Projekte umsetzen.

Wir helfen deinem Unternehmen.

Unsere Leistungen

Hilf uns, noch besser zu werden.

Zu den Jobangeboten