Neuigkeiten von trion.
Immer gut informiert.

Multi-Arch Docker Build mit GitHub Actions und DockerHub 3 Aug

Geschrieben von Thomas Kruse am 3. August 2021
Docker

Nachdem DockerHub die automatischen Builds von Docker Images nicht mehr kostenlos für jeden anbietet, bieten sich GitHub Actions als eine praktische Alternative an. ( Die Umsetzung von Multi-Arch Builds mit DockerHub wurde in dem Beitrag Docker Multi Arch Images mit DockerHub behandelt.)
In diesem Beitrag wird eine Umsetzung von Multi-Arch Images am Beispiel das Angular-CLI Docker Images vorgestellt.

Lighthouse CI mit Docker 22 Jul

Geschrieben von Thomas Kruse am 22. Juli 2021
Lighthouse Logo

Lighthouse CLI

Lighthouse ist ein Feature des Chromium und Google Chrome Browsers, mit dem Webseiten auf bestimmte Merkmale hin untersucht werden können.
Wichtige Merkmale sind dabei typischerweise die Performance der Webseite oder deren SEO-Eigenschaften. Die Performance ist dabei sowohl fuer die SEO- als auch die Nutzerzufriedenheit sehr wichtig. Ebenfalls oft gefordert ist ein barrierefreier Zugang, der durch die Accessibility Metric abgebildet wird.

Manuelle Tests werden durch Entwickler - gerade unter Zeitdruck - schnell vergessen und sind auch fehleranfällig.
Lighthouse bietet daher auch einen Modus für CI Server an, um automatisiert und regelmäßig Metrikdaten zu erheben. Diese können dann auf einem Dashboard-Server gespeichert werden, so dass auch Auswertungen im Laufe der Zeit ermöglicht werden.

Der Server kann dabei lokal betrieben werden, oder der von Google bereitgestellte öffentliche Server kann verwendet werden.

Lighthouse Einzelreport
Abbildung 1. Lighthouse Beispielreport ohne zeitlichen Verlauf

Speziell zur Ausführung auf CI Servern gibt es das Paket "LHCI", kurz für Lighthouse CI. Damit wird die Integration in das Dashboard als auch die Analyse lokaler Anwendungen ermöglicht. Das erspart das Deployment auf einem Webserver und ist insbesondere für SPA Anwendungen wie Angular, Vue oder React interessant.

Lighthouse Docker Image (auch auf ARM)

Damit Lighthouse CI komfortabel in modernen Buildservern ausgeführt werden kann, empfiehlt sich die Verwendung von Containern.
Das auf DockerHub verfügbare Image trion/chromium-lighthouse stellt auf Basis von Chromium, Node.js und LHCI eine passende Umgebung sowohl für Intel als auch ARM64 Architekturen bereit.
Damit kann sowohl Lighthouse selbst als auch das LHCI ausgeführt werden.

Beispiel im CI Server

Im folgenden wird gezeigt, wie Lighthouse CI im Build durch ein Container Image bzw. Docker Container integriert werden kann.
Als Beispiel dient dabei eine Angular Anwendung, die ebenfalls im CI Server gebaut wird.

Jib CLI als Build Container 7 Jun

Geschrieben von Thomas Kruse am 7. Juni 2021
Jib Logo

Jib CLI als Build Container

Bereits in dem Beitrag Jib CLI Docker Images wurde das Potential von Jib CLI vorgestellt.
Als nächster Schritt soll Jib CLI auch in Build Pipelines eingesetzt werden, um auch hier ohne Docker Daemon Container Images bauen zu können.

MQTT-Broker im Vergleich 3 Mai

Geschrieben von Christian Bittner am 3. Mai 2021
MQTT-Logo

Die Covid Pandemie hat zumindest einen (vermutlich) positiven Nebeneffekt: Die Digitialisierung, die vierte industrielle Revolution, IoT & Co oder wie man das Ganze auch nennen mag erlebt einen Boom. Eines der wesentlichen Protokolle für IoT / Maschinenkommunikation ist MQTT. Um Aktoren/Sensoren/Steuerungssysteme miteinander nach dem Publish-Subscribe Muster plaudern zu lassen bedarf es dabei eines Brokers.

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.

Los geht's!

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