CI/CD mit Tekton
Tekton ist ein Open-Source-Framework zur Erstellung von CI/CD-Systemen. Mit Hilfe von Tekton können Entwickler:innen ihre Anwendungen kontinuierlich bauen, testen und deployen. Tekton kann als CI/CD-System in Kubernetes-Umgebungen zum Einsatz kommen. Auch in OpenShift kommt Tekton in Form des OpenShift Pipeline Operators zum Einsatz.
Trigger und Event-Listener
In Verbindung mit einem Source-Code-Management-System (SCM), wie bspw. Bitbucket, GitLab oder GitHub, ergibt sich oft die Anforderung, dass bestimmte Ereignisse im SCM den Start einer Tekton-Pipeline auslösen sollen. Wird bspw. ein Pull-Request integriert, soll im Anschluss der master-Branch gebaut und die Anwendung deployed werden.
Für diese Szenarien stellt Tekton die Ressourcen Trigger und EventListener zur Verfügung. Die Integration mit dem SCM erfolgt i.d.R. über Webhooks. Ein Ereignis im SCM löst den Webhook aus und dieser übergibt die Informationen zum Ereignis in Form eines Payloads an einen Endpunkt, der mit einem konkreten Event-Listener verbunden ist. Die Informationen aus dem Ereignis werden im Trigger extrahiert und anschließend verwendet, um eine bestimmte Tekton-Pipeline zu starten. Die nachfolgende Grafik stammt aus der offiziellen Tekton-Dokumentation und verdeutlicht das Zusammenspiel:
Interceptors
Die Validierung, Filterung und Transformation der Ereignis-Informationen erfolgt über sog. Interceptors. Tekton stellt für Bitbucket, GitLab und GitHub bereits fertige Interceptors zur Verfügung, die die Integration mit diesen SCMs erleichtern. Das nachfolgende Beispiel zeigt die Verwendung des Bitbucket Interceptors:
interceptors:
- ref:
name: bitbucket
params:
- name: secretRef
value:
secretName: bitbucket-server-secret
secretKey: secretToken
- name: eventTypes
value:
- repo:refs_changed
Der Interceptor überprüft, dass die erhaltenen Ereignis-Informationen auf Basis des konfigurierten Secrets im Webhook-Request von Bitbucket signiert wurden (Details). Dies stellt sicher, dass die Ereignis-Informationen nicht ungewollt manipuliert wurden. Mit Hilfe des Parameters eventTypes kann festgelegt werden für welche Ereignisse dieser Interceptor aktiv sein soll. Je nach SCM und zugehörigem Interceptor sind unterschiedliche Ereignisse konfigurierbar. Das Ereignis repo:refs_changed von Bitbucket entspricht bspw. einem Push eines Commits in ein Repository (Details).
In der Praxis gelangt man schnell an einen Punkt, an dem die Konfiguration über die vorhandenen Ereignisse (eventTypes) alleine nicht mehr ausreichend ist. Wenn man bspw. eine Pipeline nur dann starten möchte, wenn der Commit auf einen bestimmten Branch gepusht wurde und bspw. nicht wenn ein Tag gepusht wurde, oder wenn ein Branch erstellt wurde, aber nicht wenn der Branch gelöscht wurde.
CEL-Interceptors
Die vordefinierten Interceptors können mit Hilfe eines CEL-Interceptors erweitert werden. Der CEL-Interceptor ermöglicht u.a. die Filterung der Ereignis-Informationen. Die Ereignis-Informationen liegen im Payload im JSON-Format vor. Mit der Common Expression Language CEL kann der Payload bspw. wie folgt gefiltert werden:
interceptors:
- ref:
name: bitbucket
params:
- name: secretRef
value:
secretName: bitbucket-server-secret
secretKey: secretToken
- name: eventTypes
value:
- repo:refs_changed
- ref:
name: cel
params:
- name: filter
value: "body.changes[0].type == 'ADD' && body.changes[0].ref.type == 'BRANCH'"
Der Filter enthält einen booleschen Ausdruck, der nur dann zu true ausgewertet wird, wenn ein Commit auf einen Branch gepusht wurde.
Fazit
In Verbindung mit den integrierten Interceptors für gängige SCMs kann ein CEL-Interceptor eine sinnvolle Ergänzung sein, um basierend auf den Ereignis-Informationen im Payload zu entscheiden, ob eine Tekton-Pipeline gestartet werden soll, oder nicht. Einfache CEL-basierte Ausdrücke erlauben dafür ein individuelles Fine-Tuning.