docker image - health check Fehler

[P.A.Trick]

Kenne mich mit Kubernetes überhaupt nicht aus, deshalb sorry, wenn das, was jetzt folgt, dumme Ideen sind, aber:

Wie spielen der im Dockerfile in Zeile 255 definierte HEALTHCHECK und die livenessProbe aus deinem manifest zusammen?

livenessProbe:
            httpGet:
              path: /fhem/healthcheck
              port: 8083
            initialDelaySeconds: 60
            periodSeconds: 20
            timeoutSeconds: 5
            failureThreshold: 3

Vielleicht "maskiert" diese livenessProbe den HEALTHCHECK, sodass dieser gar nicht ausgeführt wird und dann natürlich auch keine results-Datei angelegt wird?

Anders gefragt: Läuft bei dir im Image überhaupt health-check.sh? Meine Vermutung ist, nein.
Nochmal anders gefragt: Kannst du die livenessProbe irgendwie anpassen, dass da nicht mit httpGet gearbeitet wird, sondern ein Skript innerhalb des Containers (ist Container bei Kubernetes überhaupt der richtige Begriff?) ausgeführt wird?
Also, dass die livenessProbe einfach selbst alle paar Sekunden /health-check.sh ausführt?

Dabei sehe ich grade aber auch, dass DockerImageInfo ein Attribut "DockerHealthCheck" für alle FHEMWEB-Devices hinzufügt (Zeile 84); vielleicht reicht es also auch, wenn du bei allen FHEMWEB-Devices DockerHealthCheck auf 0 setzt. Angenommen du hast nur ein FHEMWEB-Device hilft vielleicht schon ein:

Code Auswählen Erweitern

attr WEB DockerHealthCheck 0

Das Attribut DockerHealthcheck habe ich ausprobiert, allerdings hat es nichts geändert.
Danke für deine Gedanken, aber ich hatte jetzt keine Lust mehr weiter zu probieren und habe es mit
einem Kubernetes post command gefixt.

Nicht schön, aber besser als diese nervigen Meldungen.

Code Auswählen Erweitern

 
        containers:
        - name: fhem
          image: ghcr.io/fhem/fhem-docker:5.2.2-bookworm
          lifecycle:
             postStart:
               exec:
                 command: ["/bin/sh", "-c", "echo 'ok' > /tmp/health-check.result"]


[Sidey]

Hi, ich habe den Beitrag erst heute gesehen.


Es ist so, dass im container ein health-check script liegt.
Das script prüft, ob der container noch antwortet. Es legt auch health-check.result an.

Ich habe kein kubernetes zum testen, aber so sollte der health check aussehen, damit das script verwendet wird:

Code Auswählen Erweitern

 
        livenessProbe:
          exec:
            command:
            - /bin/bash
            - /health-check.sh  # Pfad zum Skript im offiziellen Image
          initialDelaySeconds: 60 # Puffer für das Laden der fhem.cfg
          periodSeconds: 60       # Häufigkeit der Prüfung
          timeoutSeconds: 15      # Skript-Laufzeit abwarten
          failureThreshold: 3     # Neustart nach 3 Fehlversuchen


[P.A.Trick]

Hi, ich habe den Beitrag erst heute gesehen.


Es ist so, dass im container ein health-check script liegt.
Das script prüft, ob der container noch antwortet. Es legt auch health-check.result an.

Ich habe kein kubernetes zum testen, aber so sollte der health check aussehen, damit das script verwendet wird:

Code Auswählen Erweitern

 
        livenessProbe:
          exec:
            command:
            - /bin/bash
            - /health-check.sh  # Pfad zum Skript im offiziellen Image
          initialDelaySeconds: 60 # Puffer für das Laden der fhem.cfg
          periodSeconds: 60       # Häufigkeit der Prüfung
          timeoutSeconds: 15      # Skript-Laufzeit abwarten
          failureThreshold: 3     # Neustart nach 3 Fehlversuchen


Vielen Dank aber ich kann sagen das es super unter k3s läuft:

Code Auswählen Erweitern

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: fhem
  namespace: fhem
spec:
  replicas: 1
  selector:
    matchLabels:
      app: fhem
  template:
    metadata:
      labels:
        app: fhem
    spec:
      hostNetwork: true # Use host network to allow direct access to devices
      containers:
        - name: fhem
          image: ghcr.io/fhem/fhem-docker:5.2.7-bookworm
          lifecycle:
            postStart:
              exec:
                command: ["/bin/sh", "-c", "echo 'ok' > /tmp/health-check.result"]
          env:
            - name: TZ
              value: "Europe/Berlin"
          ports:
            - containerPort: 8083
          volumeMounts:
            - name: fhem-data
              mountPath: /opt/fhem
          resources:
            requests:
              cpu: "100m"
              memory: "256Mi"
            limits:
              cpu: "500m"
              memory: "512Mi"
          livenessProbe:
            httpGet:
              path: /fhem/healthcheck
              port: 8083
            initialDelaySeconds: 60
            periodSeconds: 20
            timeoutSeconds: 5
            failureThreshold: 3
          readinessProbe:
            httpGet:
              path: /
              port: 8083
            initialDelaySeconds: 30
            periodSeconds: 10
            timeoutSeconds: 5
            failureThreshold: 3
      volumes:
        - name: fhem-data
          persistentVolumeClaim:
            claimName: fhem-pvc


[Sidey]

Du legst eine leere Datei health-check.result an.

In der Datei soll das Ergebnis vom Health Check stehen.
Das Script legt es an und berücksichtigt noch, dass es mehrere FHEMWeb Instanzen geben können und auch unter welchem Pfad die Erreichbar sind.

Folglich kann Docker Image Info damit nicht arbeiten.
Deiner Variante fehlt das. Das muss kein Problem sein, kann aber mal eines werden.


Grüße Sidey

[P.A.Trick]

Du legst eine leere Datei health-check.result an.

In der Datei soll das Ergebnis vom Health Check stehen.
Das Script legt es an und berücksichtigt noch, dass es mehrere FHEMWeb Instanzen geben können und auch unter welchem Pfad die Erreichbar sind.

Folglich kann Docker Image Info damit nicht arbeiten.
Deiner Variante fehlt das. Das muss kein Problem sein, kann aber mal eines werden.


Grüße Sidey

Genau das mache ich ja und funktioniert super!

Code Auswählen Erweitern

          lifecycle:
            postStart:
              exec:
                command: ["/bin/sh", "-c", "echo 'ok' > /tmp/health-check.result"]


[Sidey]

Genau das mache ich ja und funktioniert super!

Code Auswählen Erweitern

          lifecycle:
            postStart:
              exec:
                command: ["/bin/sh", "-c", "echo 'ok' > /tmp/health-check.result"]


Ich interpretiere das so, dass nach dem Starten des Containers immer ein 'ok' in /tmp/health-check.result geschrieben wird.
Egal wie sich der Zustand verändert oder wie viele FHEMWEB Instanzen es auch gibt.

Das macht das Healthcheck script so nicht.
Du hast eine Fehlermeldung mit diesem Workaround unterdrückt. Das funktioniert super, das verstehe ich.

Ich wollte nur darauf hinweisen, dass dein Workaround die Funktion des healthcheck script nicht abbildet und dass dies nicht der empfohlene Weg ist den Healthcheck des containers zu realisieren.
Du kannst es natürlich für dich so belassen.
Der Nächste User, der über die Lösung stolpert, sollte es einordnen können, dass es nicht der empfohlene Weg ist, health-check.result manuell zu mocken.


Grüße Sidey

[P.A.Trick]

Genau das mache ich ja und funktioniert super!

Code Auswählen Erweitern

          lifecycle:
            postStart:
              exec:
                command: ["/bin/sh", "-c", "echo 'ok' > /tmp/health-check.result"]


Ich interpretiere das so, dass nach dem Starten des Containers immer ein 'ok' in /tmp/health-check.result geschrieben wird.
Egal wie sich der Zustand verändert oder wie viele FHEMWEB Instanzen es auch gibt.

Das macht das Healthcheck script so nicht.
Du hast eine Fehlermeldung mit diesem Workaround unterdrückt. Das funktioniert super, das verstehe ich.

Ich wollte nur darauf hinweisen, dass dein Workaround die Funktion des healthcheck script nicht abbildet und dass dies nicht der empfohlene Weg ist den Healthcheck des containers zu realisieren.
Du kannst es natürlich für dich so belassen.
Der Nächste User, der über die Lösung stolpert, sollte es einordnen können, dass es nicht der empfohlene Weg ist, health-check.result manuell zu mocken.


Grüße Sidey

Ja da gebe ich dir recht, dass es "nur" ein Workaround ist. Hast du eine alternative Lösung die unter k3s lauffähig ist?

[Sidey]

Ja da gebe ich dir recht, dass es "nur" ein Workaround ist. Hast du eine alternative Lösung die unter k3s lauffähig ist?

Ich nehme an, mein Vorschlag aus dem Beitrag hier sollte laufen:

https://forum.fhem.de/index.php?topic=142936.msg1361815#msg1361815

Mangels eigenem Kubernetes konnte ich es nicht testen.