Sonntag, 10. Mai 2020

Kubernetes Pod mit JProfiler überwachen

Wenn man seine Spring-Boot Applikation unter realen Bedingungen in einem Kubernetes Cluster mit JProfiler inspizieren möchte, muss man den Agenten von JProfiler einschleusen und sich dann mit diesem verbinden.

Hier ist ein Beispiel für ein Projekt mit folgenden Abhängigkeiten.

  • Spring Boot
  • Gradle
  • Google JIB
  • Kubernetes
Ein Docker Image, wie mit folgendem Dockerfile definiert, kann als Basis-Image für das eigene Projekt verwendet werden.

FROM openjdk:11-oracle
RUN yum -y install wget tar
# Download JProfiler
RUN wget https://download-gcdn.ej-technologies.com/jprofiler/jprofiler_linux_11_1_2.tar.gz -P /tmp/ &&\
 tar -xzf /tmp/jprofiler_linux_11_1_2.tar.gz -C /usr/local &&\
 rm /tmp/jprofiler_linux_11_1_2.tar.gz
# Set JProfiler agent variable
ENV JPAGENT_PATH="-agentpath:/usr/local/jprofiler11.1.2/bin/linux-x64/libjprofilerti.so=nowait,port=8849"
# Open port to connect to JProfiler agent
EXPOSE 8849

In der build.gradle Datei des Spring- Boot Projekts kann dieses Image im dem from Block der JIB Konfiguration verwendet werden.

jib {
    from {
        image = 'docker-base-jdk11-jprofiler:latest' // base image with profiling tools    }
    to {
        image = "IMAGE_NAME:${project.version}"    }
    container {
        ports = ['8080','8849']
        labels = [maintainer: 'Markus Hanses <hanses.markus@gmail.com>']
        jvmFlags = ['-agentpath:/usr/local/jprofiler11.1.2/bin/linux-x64/libjprofilerti.so=nowait,port=8849']
    }
}
Im Deployment Manifest der Applikation muss der Port des JProfiler Agenten freigegeben werden.


 -  name: jprofiler
    containerPort: 8849
Anschliessend kann der Port des K8s Pod mit dem einem Port des lokalen Entwicklungsrechners verbunden werden, um den Zugriff in den K8s Cluster zu ermöglichen.
kubectl port-forward POD_NAME 8849:8849
Danach kann die JProfiler Applikation auf dem Entwicklungsrechner über den lokalen Port mit dem K8s Pod verbunden werden und die Applikation überwacht werden. Nach dem Start von JProfiler, muss nun "Attach to running JVM" ausgewählt werden.


Anschliessend wähle "Direct connection to" und gebe die Adresse "localhost", sowie den Port "8849" ein.


Wenn alles wie oben eingerichtet wurde, wird sich der JProfiler nun mit dem Agenten in dem Pod der Spring-Boot Applikation verbinden.


Ein Hinweis: Die Anzahl der Pods für die Spring-Boot Applikation sollte auf 1 herunter gesetzt werden.



Sonntag, 12. April 2020

Docker Image für das Bauen von Java/Gradle Projekten und Deployment in Kubernetes mit Skaffold

Wenn man ein Java Projekt, wie zum Beispiel ein Spring Boot, automatisiert bauen und in ein Kubernetes Cluster einspielen möchte, der benötigt in den moderneren CI Tools, wie zum Beispiel Gitlab, ein Docker Image mit diversen Abhängigkeiten. Eine mögliche Kombination von Abhängigkeiten ist folgende: Java, Gradle, Docker CLI, Kubectl, Skaffold.

Aus dem Stand ein solches Image zusammenzustellen und es funktionstüchtig in eine Deployment Pipeline einzubringen, kostet nicht unerheblich viel Zeit. Um Dir einen schnelleren Start in Deinem Projekt zu ermöglichen, zeige ich hier ein Beispiel.




Montag, 30. März 2020

Spring Boot baut nicht auf Gitlab.com in der Gitlab-CI

Problem: Die Gitlab-CI auf Gitlab.com läuft beim Build eines Spring Boot 2.2.x Projekts in folgenden Fehler: 

 Plugin [id: 'org.springframework.boot', version: '2.2.6.RELEASE'] was not found in any of the following sources:
 - Gradle Core Plugins (plugin is not in 'org.gradle' namespace)
 - Plugin Repositories (could not resolve plugin artifact 'org.springframework.boot:org.springframework.boot.gradle.plugin:2.2.6.RELEASE')
   Searched in the following repositories:
     Gradle Central Plugin Repository


Lösung: Die Repositories in der Datei "build.gradle" muss um folgende Einträge ergänzt werden:

repositories {
    jcenter()
    mavenCentral()
    maven {
        url "https://plugins.gradle.org/m2/"    }
}

Unter MacOS ein mit SDKMAN installiertes JDK in IntelliJ integrieren

Problem: Wenn man unter MacOS seine Java SDKs mittels SDKMAN verwaltet, dann werden die mittels "sdk install java VERSION" installierten Java Versionen in der Dateiverwaltung nicht angezeigt. Da die Java Versionen vom SDKMAN nicht unter dem Standardverzeichnis "/Library/Java/JavaVirtualMachines/" abgelegt werden, sondern in einem versteckten Verzeichnis im eigenen Home unter "~/.sdkman/candidates/java/", ist eine Auswahl über die sich öffnende Dateiverwaltung in IntelliJ nicht sichtbar.



Lösung: Mit der Tastenkombination " CMD + SHIFT + . " werden die unsichtbaren Verzeichnisse sichtbar und das gewünschte JDK kann daraufhin ausgewählt werden.



Freitag, 20. März 2020

DomainDriven Design - Überblick (Präsentation)

IntelliJ & MacOS - Terminal öffnet sich mit Tastenkombination CMD-Shift-A (Find Actions)

Problem: Bei der Arbeit mit IntelliJ der Version 2019.3.x öffnet sich ein Terminal, wenn man in der IDE die Tastenkombination CMD-Shift-A (Find Actions) drückt.


Auslöser: Bei MacOS ist diese Tastenkombination bereits belegt. Unter dem deutschsprachigen Menü unter Systemeinstellungen -> Tastatur -> Kurzbefehle -> Dienste findet man den Eintrag "man-Seitenindex im...rminal durchsuchen".



Lösung: Diesen Eintrag deaktivieren.



Hintergrund: https://youtrack.jetbrains.com/issue/IDEA-209726?_ga=2.241101827.1264794351.1584727418-145849010.1582131891

Sonntag, 19. Januar 2020

iPad Art - Clean Code

In den Softwareentwicklungsprojekten ist Code-Qualität und Craftsmanship immer wieder ein Thema, mit dem man sich auf die eine oder andere Weise auseinandersetzen muss. Während in den Projekten die einen Softwareentwickler sehr daran interessiert sind die Qualität der Software zu verbessern, sind Andere entweder unmotiviert oder es fehlt ihnen an den dafür notwendigen Kenntnissen.

So oder so, ist viel Anstrengung auf zwischenmenschlicher Ebene erforderlich, um im Team ein gemeinsames Verständnis von Clean Code aufzubauen. Auch wenn eigentlich alle beteiligten Softwareentwickler bereits etwas von Clean Code gehört haben und sie regelmässig über den schlechten Code in ihrem Projekt fluchen, scheint es ihnen schwer zu fallen selber besseren Code zu schreiben.

Meiner Erfahrung nach, empfinden die Meisten es einfach als zu anstrengend, ihren eigenen Code und ihre Methodik in Frage zu stellen. Da er nach vielen Debug-Zyklen nun endlich funktioniert, ist es vermeintlich übertrieben noch mehr Zeit in die Implementierung zu investieren. Man ist froh sich endlich um andere wichtige Dinge kümmern zu können. Doch leider, führt eine undisziplinierte Vorgehensweise bei der Umsetzung so gut wie immer zu einer steten Verschlechterung der Wartbarkeit eines Softwareprodukts.

Diese Entwicklung habe ich versucht in dem folgenden Bild auszudrücken. Da Bilder dem Menschen einen Sachverhalt am besten näher bringen, habe ich angefangen einen kleinen Katalog mit den typischen Problemen in der Softwareentwicklung zu erstellen. Anhand tatsächlich existierender Code Smells, möchte ich das Thema verständlicher und greifbarer machen. Ein solches Vorgehen funktioniert dann am besten, wenn die Entwickler den Code Smell in ihrer Code-Basis wieder erkennen.



Dieses Bild soll ein erster Wurf sein und dient gleichzeitig als eine Einleitung in das Thema. Bei der Erstellung kam GoodNotes zum Einsatz.


- Update - 20.01.2020 -