Projekt - Zukunft der Arbeit

Im Landkreis Günzburg startet gerade ein spannendes Projekt zum Thema "Zukunft der Arbeit". Im Rahmen des Projekts wird es unter anderem um die Bereiche Digitalisierung und New-Work gehen. Als IT-Dienstleister freue ich mich natürlich besonders, wenn die Teilnehmer einer Unternehmensbefragung mehr Aktivitäten zu IT-Kompetenz, Datenschutz und IT-Sicherheit wünschen / planen. Details und Hintergründe gibt es auf der Projektseite der Regionalmarketing Günzburg: https://www.guenzburg-meinlandkreis.de/projekte/zukunft-der-arbeit/.

Im Vorfeld der Kickoff-Veranstaltung hatte in einigen Input in Form eines Miro-Boards geben. Das entsprechende Board kann über folgende URL weiterhin aufgerufen werden:
https://miro.com/app/board/uXjVO3vNwQ8=/.

Von meiner Seite besteht insbesondere Interesse an folgenden Dingen:

  • Austausch zum "Remote-First"-Prinzip und asynchroner Remote-Arbeit
  • Organisation eines Working Out Loud Circle
  • Aufbau einer "Projektwerkstatt" um diese Prinzipien und Arbeitsmethoden praktisch auszutesten

Für die Projektwerkstatt hatte ich die beiden Themen LoRaWAN und Predictive Maintenance mit dem Arduino Nicla Sense ME und der Plattform Edge Impulse vorgeschlagen.

Als Vorbereitung zu weiteren Workshops möchte ich noch eine Linksammlung zu den angesprochenen Themen weitergeben.

Remote-First

Working Out Loud

LoRaWAN

IT-Sicherheit

K3s unter Rocky Linux 8 mit k3sup

Letztes Jahr hatte ich im Blog-Eintrag CodeReady Containers for OKD unter Windows 10 ein kleines lokales Setup vorgestellt. Für Entwicklung und Test von Kubernetes Operatoren benötigt man aber auch schnell eine Umgebung aus mehreren Nodes. Mit dem Tool k3sup und der Kubernetes Distribution K3s lässt sich eine derartige Umgebung unter Rocky Linux 8 mit wenigen Befehlen aufsetzen.

Der Kubernetes Cluster besteht hierbei aus drei Rocky Linux 8 VMs (je 2 CPUs / 4 GB RAM / 20 GB Disk). Kubectl und k3sup nutze ich direkt auf meiner Entwickler-Workstation unter WSL2.

Im ersten Schritt wird k3sup lokal installiert:

curl -sLSo get_k3sup.sh https://get.k3sup.dev
bash get_k3sup.sh
sudo install k3sup /usr/local/bin/
which k3sup

Entgegen der k3s-Installationsanleitung habe ich auf den VMs die Firewall nicht deaktiviert. Stattdessen habe ich folgende Firewall-Rules eingerichtet.

Auf dem Server-Node (rock8-t05):

sudo firewall-cmd --permanent --add-port=6443/tcp
sudo firewall-cmd --permanent --add-port=10250/tcp
sudo firewall-cmd --permanent --add-port=8472/udp
sudo firewall-cmd --permanent --zone=trusted --add-source=10.42.0.0/16 # pods
sudo firewall-cmd --permanent --zone=trusted --add-source=10.43.0.0/16 # services
sudo firewall-cmd --reload

Auf den Agent-Nodes (rock8-t06 und rock8-t07):

sudo firewall-cmd --permanent --add-port=10250/tcp
sudo firewall-cmd --permanent --add-port=8472/udp
sudo firewall-cmd --permanent --zone=trusted --add-source=10.42.0.0/16 # pods
sudo firewall-cmd --permanent --zone=trusted --add-source=10.43.0.0/16 # services
sudo firewall-cmd --reload

Nachdem die Firewalls auf den einzelnen Nodes nun vorbereitet sind, können wir via k3sup den Server-Node (rock8-t05) aufbauen:

k3sup install --user ansible --host rock8-t05

Sobald der Server-Node steht, können die beiden Agent-Nodes eingerichtet werden:

k3sup join --user ansible --server-host rock8-t05 --host rock8-t06
k3sup join --user ansible --server-host rock8-t05 --host rock8-t07

Damit sollte der Kubernetes Cluster schon einsatzbereit sein. Dies lässt sich z.B. mit folgenden Befehlen prüfen:

$ export KUBECONFIG=~/kubeconfig
$ kubectl config set-context default
Context "default" modified.
$ kubectl cluster-info
Kubernetes control plane is running at https://rock8-t05:6443
CoreDNS is running at https://rock8-t05:6443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy
Metrics-server is running at https://rock8-t05:6443/api/v1/namespaces/kube-system/services/https:metrics-server:https/proxy

To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.
$ kubectl get node
NAME        STATUS   ROLES                  AGE     VERSION
rock8-t06   Ready    <none>                 4m22s   v1.23.6+k3s1
rock8-t07   Ready    <none>                 106s    v1.23.6+k3s1
rock8-t05   Ready    control-plane,master   8m39s   v1.23.6+k3s1

LoRaWAN als Brücke für das Internet der Dinge

LoRaWAN bietet für IoT Anwendungen eine kostengünstige und einfache Anbindung an bestehende IT-Systeme. Das The Things Network formt hierzu ein offenes und globales Ökosystem zum Betrieb von LoRaWAN Netzwerken. In den letzten Monaten haben wir einige Erfahrung mit LoRaWAN gesammelt, Highlight war die Teilnahme an der The Things Summer Academy.

RasPi 4 mit RAK2287 Concentrator
RasPi 4 mit RAK2287 Concentrator

Besonders spannend, durch IoT verschmelzen bisher getrennte Fachgebiete miteinander. Gleichzeitig werden Themen wie IT-Sicherheit und moderne Prozesse für die Software-Entwicklung für neue Kundengruppen relevant. D.h. immer mehr Unternehmen finden sich in der Rolle als Softwarehersteller oder IT-Unternehmen wieder.

Arduino MKR WAN 1300 + MKR ENV Shield
Arduino MKR WAN 1300 + MKR ENV Shield

In diesem Bereich ergeben sich für uns einige Aufgabenfelder, zum einen die Anbindung von IoT-Umgebungen an Data-Streaming-Plattformen wie Apache Kafka und die passende Wahl von Datenformat (Payload Encoding/Decoding) zum mit Apache Avro. Für den Einsatz von klassischen Datenbanken wie PostgreSQL und die Datenvisualisierung mit Grafana haben wir ebenfalls Anwendungsfälle untersucht.

CodeReady Containers for OKD unter Windows 10

Die Firma RedHat bietet mit Openshift eine sehr umfassende Kubernetes Distribution. Bei OKD handelt es sich um das entsprechende Open Source Upstream-Projekt. Für Entwickler-Teams oder den Einsatz in der Produktion wird Openshift normalerweise in einem Cluster aus mehreren Server-Knoten oder VMs installiert. Für die Entwicklung von Images, Templates, Kubernetes-Operatoren oder um sich mit Openshift vertraut zu machen, ist eine kleine lokale Mini-Installation von Vorteil. Früher gab es hierfür z.B. minishift oder minikube. Für Openshift 4 wurde diese Form von Umgebung in "CodeReady Containers" (CRC) umbenannt.

Die Installationsanleitung für Linux, Mac OS und Windows befindet sich hier: Getting Started Guide und der OKD-Download der CRC-Umgebung hier: Download CodeReady Containers for OKD.

Zusätzlich zur Installationsanleitung sollten unter Windows 10 folgende Punkte beachtet werden:

  • Das Windows 10 System sollte mindestens 16 GB RAM haben, besser 32 GB. Bei 16 GB RAM müssen evtl. Anwendungen und Dienste vor dem Start der CRC-Umgebung gestoppt werden.
  • Der Installationsbenutzer muss zu einem lokalen Administrator werden können und zusätzlich Mitglied der Gruppe "Hyper-V-Administratoren" sein.

Installation und Start sind nach dem Download, in einer klassichen Windows Eingabeaufforderung, wie folgt möglich:

crc setup
crc start -n 8.8.8.8

Bei Fehlern kann der Debug-Output über die Zusatzoption "--log-level debug" aktiviert werden.

Für erste Tests der Umgebung kann z.B. mein Demojee auf Github genutzt werden:
https://github.com/FrankBergerITServices/openshift-jee-sample

Die Corona-Warn-App - Das cwa-server Backend in einer Docker Umgebung

Da der Code der Corona-Warn-App nun komplett auf GitHub veröffentlicht wurde, ergibt sich nun für uns die Chance Möglichkeiten und Probleme in der Software-Entwicklung an einem sehr aktuellen Projekt live mitzuverfolgen. Mir ist bewusst, dass Tracking-Apps politisch und ethisch enormes Konfliktpotenzial bieten. Meiner Meinung nach wird der Nutzen derartiger Apps stark überschätzt und die entstehenden ethischen Probleme leider ignoriert. Erfolg oder Misserfolg werden sich wohl erst hinterher genau mit Fakten belegen lassen. Es gibt also einiges zu lernen! Im nachfolgenden Post möchte ich Euch zeigen wie Ihr das cwa-server Backend der App in einer Docker Umgebung aufsetzen könnt. Danach werden wir mit einem kleinen Python-Script einen Submission-Key an das Backend schicken und das Ergebnis in der Datenbank überprüfen.

CWA – Das cwa-server Backend in einer Docker Umgebung

[Durch Click auf die Play-Schaltfläche erfolgt ein Verbindungsaufbau zu YouTube/Google und es werden Daten an an diese externen Dienste übertragen]

Um Euch lokal eine passende Entwicklungs-Umgebung aufzubauen empfehle ich folgende Werkzeuge:

Sobald Ihr die Tools installiert habt, könnt Ihr den Code auch schon von GitHub clonen und die Umgebung mit Docker-Compose aufbauen lassen:

mkdir -p /c/cwa
cd /c/cwa
git clone https://github.com/corona-warn-app/cwa-server.git
cd cwa-server
docker-compose build
docker-compose up

Sobald die Docker Container laufen könnt Ihr z.B. mit einem eigenen kleinen Python-Client auf das Backend zugreifen. Der HTTP Body des POST-Request besteht in diesem Fall leider nicht aus klassischem Text oder Daten im JSON-Format. Für die API wird Protobuf von Google genutzt, dabei handelt es sich um ein schlankes binär Format. Für unseren Python-Client müssen wir zunächst mit den .proto-Files aus dem Source Code und dem Protobuf-Compiler von Google passende Python-Klassen bauen. Bei dieser Gelegenheit installieren wir auch gleich noch das Protobuf-Binding für Python. Evtl. müsst Ihr noch die Pfade an Eure Umgebung anpassen:

pip install protobuf
mkdir -p /c/cwa/cwa-client
cd /c/cwa/cwa-client
/c/tools/protoc/bin/protoc.exe --python_out=/c/cwa/cwa-client \
 --proto_path=/c/cwa/cwa-server/common/protocols/src/main/proto \
 app/coronawarn/server/common/protocols/external/exposurenotification/temporary_exposure_key_export.proto \
 app/coronawarn/server/common/protocols/internal/submission_payload.proto

Damit müsstet Ihr dann folgenden Python-Client ausführen können:

import http.client
from datetime import datetime, timedelta
from app.coronawarn.server.common.protocols.internal.submission_payload_pb2 import SubmissionPayload

submission = SubmissionPayload()
key = submission.keys.add()
key.key_data = bytes("FranksDemoKey222", "utf-8")
key.rolling_start_interval_number = int(((datetime.today() - timedelta(days=14)).timestamp())/600)
key.rolling_period = 144
key.transmission_risk_level = 4

conn = http.client.HTTPConnection('localhost', 8000)
headers = {'Content-Type': 'application/x-protobuf',
           'cwa-fake': '0',
           'cwa-authorization': 'edc07f08-a1aa-11ea-bb37-0242ac130002'}
conn.request("POST", "/version/v1/diagnosis-keys", submission.SerializeToString(), headers)
response = conn.getresponse()
print(response.status, response.reason)

Um auf die Postgres Datenbank zugreifen zu können, haben uns die CWA-Entwickler pgAdmin als Web-Oberfläche in einem eigenen Container mitgeliefert. Ihr müsst dort noch die Datenbank-Verbindung einrichten. Danach könnt Ihr mit folgendem SQL Statement prüfen ob unser POST-Request zu einem Eintrag in der Datenbank geführt hat:

SELECT encode(key_data, 'escape')
     , rolling_period
	 , rolling_start_interval_number
	 , submission_timestamp
	 , transmission_risk_level
	FROM public.diagnosis_key
	WHERE key_data like 'FranksDemoKey%';