blog.mhus.de

Nach einigen Kämpfen kann der Desktop jetzt auch unter Linux mittels DEB-Datei und APT-Kommando installiert werden. Die korrekte Datei ist nun hinterlegt und die Dokumentation wurde aktualisiert. Problem war der JVM Parameter '-XstartOnMainThread' der zwar unter MaxOSX angegeben werden muss, damit SWT funktioniert, aber unter Linux nicht existiert und hier verhindert, dass die Binary ausgeführt werden kann. Leider hat die erstellung eines Desktop-Eintrags noch nicht richtig funktioniert, die Dokumentation habe ich schon drin gelassen und als 'WIP' markiert.

Aktuell können Benutzer keine Dateien verwalten, Dateien im Hintergrund. Funktionen wie Logs Speichern, Dateien von Pods herunterladen oder beim Ausführen von Exec einen Mitschnitt machen. Um diese Funktionen bereitzustellen wird ein System benötigt bei dem der Benutzer im Hintergrund Dateien ablegen und herunterladen kann. Ist die Anwendung lokal gestartet soll der Datei-Explorer/Finder aufgehen anstelle von einem Download. Hier sollen die Dateien im User Home abgelegt werden. Wird KT2L in Kubernetes gestartet ist es besser die Dateien werden in einem Volume oder einem S3 Bucket abgelegt. Da es keine echten Benutzerrechte auf Dateiebene gibt müssen die Dateien sicher voneinander getrennt werden und der Zugriff auf 'andere' verhindert werden. Aber so kann auch das Sharing von Dateien umgesetzt werden. Wenn mehrere Benutzer in einer Gruppe sind, kann die Gruppe als Basis der Dateien genutzt werden (z.B. alle Admins). Die Funktion ist nicht abhängig von Clustern, aber vom angemel

Eigentlich sollte bei einem Refresh im Browser alles weggeworfen werden und es fängt von vorne an. Das ist so auch der Standart wenn man Vaadin nutzt. Genauer wird sogar bei Wechsel der Seite (Routing) immer alles neu geladen. Navigierst du zurück, ist alles weg. Nachteil des Verhaltens ist, dass man keine echte Anwendung bauen kann in der der Status einer Seite, die gerade nicht zu sehen ist, bestehen bleibt. Blöd wenn man z.B. ein Log oder zwei Logs laufen hat und dann mal was anderes schauen will. Huch, Log weg. Deshalb wurde bei KT2L auf die Fähigkeit verzichtet die Session `serializable` zu halten und somit stateless auf mehreren Instanzen bereit zu stellen: Einmal an einer Instanz angemeldet, musst du dort auch bleiben, sonst ist deine Anwendung weg. Vorteil: im Hintergrund kann die Anwendung schön weiter arbeiten, Logs und Events sammeln,  damit die Ansicht aktuell bleibt. Solange im Browser nicht 'Refresh' gedrückt wird ist alles gut. Leider hat sich der Teil mit dem Re

Unter dem Grid wird nun ein Footer dargestellt in dem die Anzahl der Ressourcen im Grid angezeigt wird. Wird gefiltert, werden die angezeigte und tatsächliche Menge an Einträgen angezeigt. Wurden Einträge selektiert, wird auch die Anzahl der selektierten Einträge angezeigt. Die Formatierung muss noch angepasst werden, ggf. noch ein Kürzel, damit die Anzeige besser eingeordnet werden kann. Um Platz für den Foster zu schaffen habe ich Padding und Margin in den Layouts entfernt. Damit rückt alles mehr zusammen und sieht kompakter aus.

 If you configure your k8s cluster with terraform one of the final steps is to install a fluxcd operator. The operator are responsible to manage the resources inside of the cluster. In this way a fully automatic creation process is possible. To install flux a terraform provider is available preparing a install and sync configuration which can be installed in k8s using the kubernetes/kubectl providers. In fluxcd itself it is possible to use substitution . This means you can use variables to prepare the k8s yaml files. This is useful for variable content like different cluster names and domain names for all stages. Or more specialised arn ids of created resources while creating the cluster in aws. To use substitution fluxcd offers to link the configuration to a config map. In the map a set of key values can be defined to replace variable values. The map can also be created with terraform and the kubectl provider. Do not store secrets in the config map. Try to use secrets instead. Applyi

  Working out Jenkins/CI pipelines it is a common task to create Spring Boot Images. Doing this with kubernetes agents is a challenge since docker is no more available from inside of containers. The task is quiet simple, create a spring boot image with `mvn spring-boot:build-image` inside a kubernetes pod. By default this fails because spring try to execute 'buildpacks' but the needed docker service is not available. The docker service is needed to create the container image. With spring 2.6 and beneath it is not possible to use another service then docker. But it is possible to use buildpacks separately after creating the project jar file. As replacement of docker it is possible to use podman as service. podman is compatible with docker and also supports the docker.sock. Looking forward to spring boot 2.7 which supports also podman as alternative to docker I did not try to use 'kaniko'. Objectives of this post: Create a woking pod and script to create spring boot image