sidion labor

Entwickler Blog

Ein neuer Ansatz für die Build Pipeline.

Was wäre, wenn man für die Build Pipeline keinen Server mehr bräuchte?
Die ganze Pipeline könnte überall ausgeführt werden, sogar auf den PCs der Entwickler.

Tekton ist ein Open Source Projekt der Continuous Delivery Foundation, dass die Build Pipeline in den
Kubernetes Cluster verlagert. Die Pipeline wird über Kubernetes Resourcen deklariert.
Sie besteht damit nur noch aus ein paar Dateien, die auf jedem Kubernetes Cluster deployed und ausgeführt werden können.

Spätestens seit der neuen Release Politik von Java, muss man sich als Backend-Entwickler immer öfter mit Migrationen von Programmiersprachen & Libraries beschäftigen. Im Frontend beispielsweise bringt Angular jedes halbe Jahr ein neues Release raus (zum Zeitpunkt des Schreibens ist Angular 12 die aktuellste Version). Hier habe ich im Kundenprojekt das bestehende Projekt bereits von Angular 7 auf 8 und dann noch mal von 8 auf 10 aktualisiert.
Im Backend wird bisher am häufigsten noch Java 8 verwendet. Es gibt aber auch schon hier und da Projekte, die Java 11 oder höher verwenden. Bei Java lohnt es sich wohl nur auf die LTS Versionen 8, 11 und dann 17 (gegen Ende des Jahres 2021) zu migrieren, sonst sollte man jedes halbe Jahr jede Version mitnehmen.
Java ist die Grundlage für Spring Boot und auch JUnit. Spring Boot hat mit dem Release Version 2.2.0 auf JUnit 5 umgestellt. Was das bedeutet und welche Erfahrungen ich mit der Migration eines Kundenprojekts von JUnit 4 auf JUnit 5 gesammelt habe, das möchte ich in diesem Artikel kurz beschreiben. (Dies soll aber kein JUnit 5 Tutorial sein!)

Viele Webanwendungen benötigen Usereingaben innerhalb von Formularen. Oftmals sind Eingabefelder mehr als nur simple Inputfelder und müssen zusätzliche Logik verwenden. Beispielsweise besondere Validatoren, die einschränken, was der Nutzer eingeben darf oder gewisse andere Features, wie eine Autocomplete- oder eine Filter-Funktion. Es ist kein Hexenwerk den Eingabefeldern zusätzliche Logik zu geben. Allerdings können sich, je nach Usecase, die benötigten extra Funktionen schnell anhäufen. Hat man nun mehrere Formulare mit gleichen oder ähnlichen, komplexen Eingabefeldern können der HTML- und TS-Code schnell unübersichtlich werden. Dafür bietet es sich an, die Logik in eigene Komponenten auszulagern.

Immer wieder kommt es zu Sicherheitslücken bei denen Passwörter entwendet und bekannt werden. Eine Seite, auf der man prüfen kann, ob die eigenen Passwörter schon mal in solch einer Sicherheitslücke aufgetaucht sind, ist „have i been pwned“ [4]. Dazu kommt, dass Passwörter oft mehrfach verwendet werden, so dass eine Sicherheitslücke auf einer unbedeutenden Seite dazu führen kann, dass auch das Passwort fürs Online-Banking bekannt wird. Physische Sicherheitsschlüssel schaffen hier Abhilfe, da für jede Webseite individuelle Zugangsdaten erzeugt werden, die nie diesen Sicherheitsschlüssel verlassen. Diese Funktion in eine Webseite einzubauen, ist genauso einfach wie eine traditionelle Benutzerregistrierung zu implementieren.

Bei den reinen Webservern / Reverse-Proxys gibt es 2 Platzhirsche. Auf der einen Seite den Apache HTTP Server und auf der anderen Seite den NGINX. Letzteren möchte ich in diesem Artikel etwas unter die Lupe nehmen. Mir ist selbstverständlich bewusst, dass es schon einige NGINX Tutorials gibt. Deshalb werde ich hier dafür auch nicht darauf eingehen, dass man z.B. mittels 'nginx -t' seine Konfiguration checken lassen kann und es soll auch keine Schritt-für-Schritt Anleitung sein. Allerdings werde ich versuchen, es durch die "Entwickler Brille" für meine Entwickler Kollegen so einfach wie möglich zu beschreiben und nicht zu tief in das "Ops" von "DevOps" einzutauchen. Es gibt für uns Entwickler ein paar nützliche Dinge - vor allem in Verbindung mit Docker, die ich wirklich für erwähnenswert halte. Ein Projekt mit meinen Azubis ist letztendlich ausschlaggebender Grund dafür, weshalb ich mich über den Jahreswechsel mit NGINX auseinandersetzte. Außerdem habe ich für den Artikel ein Code-Repository erstellt, welches ich unter https://github.com/m1well/nginx-playground bereitstelle. In meinem Repo sind minimale Konfigurationen für einen Reverse-Proxy, Load-Balancer und Rate-Limiter vorhanden. Getestet werden die Funktionalitäten mit 3 weiteren NGINX Containern, welche als Dummy Services dienen.