Neuigkeiten von trion.
Immer gut informiert.

Jib CLI - Docker Images ohne Dämon 2 Apr

Geschrieben von Thomas Kruse am 2. April 2021
Jib Logo

Jib CLI - Docker Images ohne Dämon bauen

Aus dem Java Umfeld stammt das Werkzeug Jib, mit dem sich Anwedungen in optimierte Docker / OCI Container Images verwandeln lassen. Typischerweise wird Jib zusammen mit dem Buildsystem der Anwendung, z.B. maven oder gradle, verwendet.

Doch nun hat Google Jib auch als Kommandozeilenwerkzeug (CLI) in einer ersten Version bereitgestellt. Damit lässt sich Jib auch für andere Arten von Containern einsetzen.

Canary Deployment mit traefik 9 Mär

Geschrieben von Thomas Kruse am 9. März 2021
traefik Proxy

In vielen Kundenprojekten ist der Wunsch zu beobachten, von klassisch betriebenen Anwendungen sofort in die Cloud oder zumindest nach Kubernetes zu migrieren. Vielleicht schwingt dabei der Wunsch mit, Zeit zu sparen, indem Zwischenschritte ausgelassen werden. Oder man ist sich sehr wohl bewußt, dass man in Gewissen Bereichen versäumt hat, Know-How aufzubauen und in Modernisierung zu investieren.

Wir empfehlen regelmäßig zumindest kleine Zwischenschritte einzuplanen, um Erfahrungen mit der Erstellung aber auch dem Design von Anwendungen für Container- und Cloudumgebungen zu sammeln. Das gilt um so mehr, wenn das Unternehmen sich nicht ganze Teams, die sich nur um Infrastruktur und Support kümmern können, leisten möchte.

Eine gute Möglichkeit zum Start stellt der Einsatz von Docker Containern ohne automatischen Orchestrator wie Kubernetes, Mesos oder Docker-Swarm dar. Dabei wählt man typischerweise eine Anwendung aus, die nicht absolut essentiell ist, und optimalerweise bereits von einem Team mit modernen Technologien und vor allem Mindset entwickelt und betreut wird.

Mit verhältnismäßig wenig Infrastruktur können dann auch bereits Patterns aus der Cloud-Welt verprobt werden und entsprechende Erfahrungen mit den notwendigen Umsystemen und Prozessen gewonnen werden. Wichtig ist dabei, dass man den Schwenk auf fertige Lösungen vornimmt, und nicht mit eigenen Mitteln Dinge nachbaut und wartet, die ein Orchestrator mitliefert.

Hat man sich für traefik als Reverseproxy und Loadbalancer entschieden, um Container verfügbar zu machen, kann man bereits von vielen Vorzügen profitieren.

Ein Kunde wünschte sich Canary-Deployments auszuprobieren, und das allein mit traefik. Wie so ein Canary oder A/B Deployment mit traefik umgesetzt werden kann, zeigt der folgende Beitrag.

trion-consulting Heek 3 Mär

Geschrieben von Thomas Kruse am 3. März 2021

Distanzierung zur TrioN Consulting Heek

Aus aktuellem Anlass stellen wir klar:

Bei der trion development GmbH aus Münster handelt es sich um ein eigenständiges Unternehmen, das nicht mit der Marke "TrioN Consulting" aus Heek-Nienborg in Vebindung...

Drone CI global environment Variable 28 Jan

Geschrieben von Thomas Kruse am 28. Januar 2021
Drone CI Logo

Bei Drone CI handelt es sich um einen OpenSource continuous integration (CI) Server. Dabei setzt Drone CI auf die Ausführung des Builds mittels Containern. Typischerweise werden dabei Docker oder Kubernetes als Container Plattform eingesetzt.

Eine Buildpipeline wird in YAML definiert, dabei können sowohl services definiert werden, die im Build verwendet werden, als auch persistente volumes und natürlich die Buildabläufe als steps.

Drone CI Kubernetes Pipeline Beispiel
kind: pipeline
type: kubernetes
name: build-demo

platform:
  os: linux
  arch: arm64

volumes:
  - name: cache
    temp: {}
  - name: docker
    host:
      path: /var/tmp/docker

services:
  - name: docker
    image: docker:20.10-dind
    environment:
      DOCKER_TLS_CERTDIR: ""
    resources:
      requests:
        cpu: 1
        memory: 2Gi
      limits:
        memory: 2Gi
    privileged: true
    ports:
    - 2375
    volumes:
    - name: docker
      path: /var/lib/docker

steps:
  - name: publish
    image: docker
    environment:
      DOCKER_HOST: "tcp://localhost:2375"
    resources:
      requests:
        cpu: 1
        memory: 128Mi
    privileged: true
    commands:
      - cd frontend && sleep 10 # docker sidecar needs time for startup
      - docker build -t registry.docker-registry:5000/demo/frontend .
      - docker push registry.docker-registry:5000/demo/frontend

File-Upload mit Nest.js 9 Nov

Geschrieben von Karsten Sitterberg am 9. November 2020
Nest.js Logo

Als Standard-Verfahren für Datei-Uploads kommt bei Nest.js-Anwendungen typischerweise ein Datei-Upload als multipart/form-data mit Hilfe der Multer-Bibliothek zum Einsatz. Dies ist jedoch nicht immer passend: Die Verwendung von multipart/form-data kommt typischerweise im Kontext von HTML Formularen vor. Ohne HTML Formular und eingebaute Logik eines Browser ist die Verwendung auf Clientseitig teilweise umständlich zu implementieren.

Im Kontext von Microservice Architekturen liegen manchmal Daten vor, die zwar als einzelne Verarbeitung behandelt werden sollen, die jedoch mit einem klassischen File-Upload Formular wenig zu tun haben.

Bei Nest.js kommt die aus dem Node / Express Umfeld bekannte Multer Bibliothek für Multipar-Uploads zum Einsatz. Mit einzelnen Binary-POSTs kann sie jedoch nicht umgehen.

In diesem Artikel werden wir einen Datei-Upload implementieren, der ohne Multer auskommt und stattdessen die Dateien direkt als Binärdaten einließt.

Build Warnung bei Dependency Updates 2 Okt

Geschrieben von Thomas Kruse am 2. Oktober 2020
GitLab

Ein typisches Java Projekt besteht nicht nur aus dem eigenen Code, sondern in der Regel auch vielen externen Bibliotheken als Abhängigkeiten.
Diese Abhängigkeiten machen dabei in einem Microservice mehr als 90% Anteil am gesamten Code aus. Die Wartung erfolgt zwar durch den jeweiligen Hersteller, jedoch muss das Projekt Team darauf achten, dass entsprechende Aktualisierungen auch im Projekt aufgenommen werden. Kritisch wird es dann, wenn Sicherheitsupdates zwar verfügbar sind, jedoch nicht die zugehörige Maven oder Gradle Konfiguration aktualisiert wird.

Um das Problem zu lösen gibt es verschiedene Ansätze mit einem unterschiedlichen Automatisierungsgrad. Wir wollen einen pragmatischen Ansatz vorstellen, der sich in der Praxis sehr bewährt hat und seinerseits keine zusätzlichen Abhängigkeiten einführt.

YAML als API in Spring Boot RestController 4 Sep

Geschrieben von Thomas Kruse am 4. September 2020
Spring Boot

Dank Spring Boot ist die Erstellung von Java basierten Anwendungen und Microservices extrem leicht geworden: Mit Spring Initializr ( https://start.spring.io ) ist eine API Anwendung schnell erstellt. Sinnvolle Standardeinstellungen und eine gute Entwicklerproduktivität machen Spring Boot auch im weiteren Verlauf eines Softwareprojekts zu einer beliebten Plattform.

Doch was ist, wenn man von den vorgegebenen Pfaden abweichen will?
Spring Boot zeigt sich hier flexibel: Am Beispiel von YAML als Datenformat für unsere Anwendung schauen wir uns das einmal genauer an.

GitLab CI Code Coverage bei Multi-Module Maven Projekt 3 Aug

Geschrieben von Thomas Kruse am 3. August 2020
GitLab

Auch wenn Microservice Architekturen und damit einhergehend Single-Module-Repositories im Trend liegen, gibt es immer wieder Gründe für ein Multi-Module Projekt. Sogar bei Microservice als Deployment.
Wenn es nun darum geht, die Code-Coverage zu ermitteln, um diese bei GitLab CI anzuzeigen oder Trends zu ermitteln, muss man sich etwas behelfen. GitLab CI ist im Verglech zu Jenkins nämlich deutlich dünner ausgestattet, so dass eine Fancy Plugins die Arbeit abnehmen. Damit ist Jenkins nicht automatisch besser oder GitLab CI schlechter, als Jenkins: Die Ausrichtung ist einfach anders.

Im folgenden betrachten wir einmal, wie die modulübergreifende Auswertung von Code Coverage, erhoben mit dem JaCoCo Maven Plugin, aussehen könnte. Der Ansatz lässt sich natürlich auf andere Coverage-Tools und Sprachen analog übertragen.

React Native oder NativeScript? Eine Auswahlhilfe für Entscheider 6 Jul

Geschrieben von Steffen Jacobs am 6. Juli 2020
NativeScript logo

React Native oder NativeScript? - Eine komparative Analyse für Enterpriseanwender
Im Bereich der mobilen Anwendungsentwicklung von nativen Apps gibt es viele Wege, die zum Ziel führen. Aus bereits im Vorfeld beschriebenen Gründen [1] [2] konnten wir diese Auswahl an Wegen für die meisten praktischen Anwendungsfälle bereits auf die beiden Cross-Platform-Frameworks React Native und NativeScript reduzieren.

Aber welches der beiden Frameworks sollte man denn nun für die eigene Anwendung verwenden? Die Lösung dazu und die Antwort auf weitere Fragen werden in dieser Analyse behandelt.

Für die Lesenden, die sich zunächst einmal grundlegend mit den beiden Frameworks auseinandersetzen möchten, haben wir bereits jeweils einen Artikel zu React Native[1] und einen zu Native Script [2] vorbereitet.

Keycloak SAML Integration Test mit Testcontainers und Spring Boot 15 Jun

Geschrieben von Thomas Kruse am 15. Juni 2020
Keycloak (logo)

OpenID Connect und OAuth2 sind vielleicht etwas moderner und hipper als das bereits etwas in die Jahre gekommene SAML 2 Protokoll. Soll jedoch im Enterpriseumfeld eine Anwendung in bestehende Landschaften integriert werden, führt selten ein Weg an SAML 2 vorbei. Das gilt um so stärker, wenn es sich um eine Branche mit hohem Sicherheitsbedarf wie Luftfahrt, Banken oder Versicherungen handelt.

Keycloak hat sich als zuverlässige und gleichzeitig sehr leicht zugängliche Plattform zur Umsetzung von OpenID Connect oder SAML erwiesen. Dabei kann Keycloak sowohl produktiv eingesetzt werden, als auch sehr komfortabel als lokale Testumgebung für Entwicklung und Test verwendet werden. Zur Integration von Keycloak in Spring Boot existieren neben einem Keycloak Modul auch Spring-Security-SAML bzw. OAuth2 Client und Resourceserver.

Gerade wenn es um das Thema Security geht, bringen automatisierte Tests ein wichtiges Sicherheitsnetz für die Software. Wir wollen Keycloak als SAML 2 IdP verwenden und mit einer Spring Boot Anwendung Authentifizierung mit SAML 2 als Beispielanwendung für automatisierte Integrationstests verwenden. Ein - relativ einfacher - Weg wäre, Keycloak als Docker Container im Rahmen der CI-Pipeline mit Jenkins, Bamboo oder GitLab-CI bereitzustellen, so dass die zu testende Software darauf zugreifen kann. Allerding verliert man damit die Möglichkeit, die Tests lokal genauso zu entwickeln und zu validieren, wie sie nachher in der Buildserver Umgebung laufen.

Eine Alternative stellen Testcontainers dar. Die allgemeine Verwendung von Testcontainers wurde bereits in Testcontainers mit JUnit 5 erläutert. Nun schauen wir uns an, wie Keycloak, Testcontainers und Spring Boot SAML 2 zusammen eingesetzt werden kann.

Los geht's!

Bitte teilen Sie uns mit, wie wir Sie am besten erreichen können.