I have a self-managed full Camunda 8 stack.
All of the components working I think except one: webmodeler-websockets
Is it running, but the logs of this container:
“Starting the WebSocket server on port 8060…”
This log present just, after like 24 hours too. Nothing else.
Is it normal? And the related ingress URL → point to 404 page
It is the default one, deployed from helm chart of course (just ingress URL changed):
websockets:
## @extra webModeler.websockets.image configuration of the websockets Docker image
image:
## @param webModeler.websockets.image.repository defines which image repository to use for the websockets Docker image
repository: web-modeler-ee/modeler-websockets
## @param webModeler.websockets.sidecars can be used to attach extra containers to the modeler websockets deployment
sidecars: []
## @param webModeler.websockets.initContainers can be used to set up extra init containers for the application Pod
initContainers: []
## @param webModeler.websockets.publicHost can be used to define the host on which the WebSockets server can be reached from the Web Modeler client in the browser.
# The default value assumes that a port-forwarding to the websockets service has been created.
# Note: The host will only be used if the Ingress resource for Web Modeler is disabled.
publicHost: localhost
## @param webModeler.websockets.publicPort can be used to define the port number on which the WebSockets server can be reached from the Web Modeler client in the browser.
# The default value assumes that a port-forwarding to the websockets service on port 8085 has been created.
# Note: The port will only be used if the Ingress resource for Web Modeler is disabled.
publicPort: 8085
## @param webModeler.websockets.podAnnotations can be used to define extra websockets pod annotations
podAnnotations: {}
## @param webModeler.websockets.podLabels can be used to define extra websockets pod labels
podLabels: {}
## @param webModeler.websockets.env can be used to set extra environment variables in each websockets container
env: []
## @param webModeler.websockets.command can be used to override the default command provided by the container image, see https://kubernetes.io/docs/tasks/inject-data-application/define-command-argument-container/
command: []
## @param webModeler.websockets.extraVolumes can be used to define extra volumes for the websockets pod; useful for logging to a file
extraVolumes: []
## @param webModeler.restapi.extraVolumeMounts can be used to mount extra volumes for the restapi pods, useful for TLS and self-signed certificates
extraVolumeMounts: []
## @extra webModeler.websockets.podSecurityContext can be used to define the security options the websockets pod should be run with
## @param webModeler.websockets.podSecurityContext.runAsNonRoot
## @param webModeler.websockets.podSecurityContext.fsGroup
podSecurityContext:
runAsNonRoot: true
fsGroup: 1000
## @extra webModeler.websockets.containerSecurityContext can be used to define the security options the websockets container should be run with
## @param webModeler.websockets.containerSecurityContext.privileged
## @param webModeler.websockets.containerSecurityContext.readOnlyRootFilesystem
## @param webModeler.websockets.containerSecurityContext.allowPrivilegeEscalation
## @param webModeler.websockets.containerSecurityContext.runAsNonRoot
## @param webModeler.websockets.containerSecurityContext.runAsUser
containerSecurityContext:
privileged: false
readOnlyRootFilesystem: true
allowPrivilegeEscalation: false
runAsNonRoot: true
runAsUser: 1000
## @extra webModeler.websockets.startupProbe configuration of the websockets startup probe
startupProbe:
## @param webModeler.websockets.startupProbe.enabled if true, the startup probe will be enabled for the websockets container
enabled: false
## @param webModeler.websockets.startupProbe.initialDelaySeconds defines the number of seconds after the container has started before the probe is initiated
initialDelaySeconds: 10
## @param webModeler.websockets.startupProbe.periodSeconds defines how often the probe is executed
periodSeconds: 30
## @param webModeler.websockets.startupProbe.successThreshold defines how often the probe needs to succeed to be considered successful after having failed
successThreshold: 1
## @param webModeler.websockets.startupProbe.failureThreshold defines when the probe is considered failed so the container will be restarted
failureThreshold: 5
## @param webModeler.websockets.startupProbe.timeoutSeconds defines the number of seconds after which the probe times out
timeoutSeconds: 1
## @extra webModeler.websockets.readinessProbe configuration of the websockets readiness probe
readinessProbe:
## @param webModeler.websockets.readinessProbe.enabled if true, the readiness probe will be enabled for the websockets container
enabled: true
## @param webModeler.websockets.readinessProbe.initialDelaySeconds defines the number of seconds after the container has started before the probe is initiated
initialDelaySeconds: 10
## @param webModeler.websockets.readinessProbe.periodSeconds defines how often the probe is executed
periodSeconds: 30
## @param webModeler.websockets.readinessProbe.successThreshold defines how often the probe needs to succeed to be considered successful after having failed
successThreshold: 1
## @param webModeler.websockets.readinessProbe.failureThreshold defines when the probe is considered failed so the Pod will be marked unready
failureThreshold: 5
## @param webModeler.websockets.readinessProbe.timeoutSeconds defines the number of seconds after which the probe times out
timeoutSeconds: 1
## @extra webModeler.websockets.livenessProbe configuration of the websockets liveness probe
livenessProbe:
## @param webModeler.websockets.livenessProbe.enabled if true, the liveness probe will be enabled for the websockets container
enabled: true
## @param webModeler.websockets.livenessProbe.initialDelaySeconds defines the number of seconds after the container has started before the probe is initiated
initialDelaySeconds: 10
## @param webModeler.websockets.livenessProbe.periodSeconds defines how often the probe is executed
periodSeconds: 30
## @param webModeler.websockets.livenessProbe.successThreshold defines how often the probe needs to succeed to be considered successful after having failed
successThreshold: 1
## @param webModeler.websockets.livenessProbe.failureThreshold defines when the probe is considered failed so the container will be restarted
failureThreshold: 5
## @param webModeler.websockets.livenessProbe.timeoutSeconds defines the number of seconds after which the probe times out
timeoutSeconds: 1
## @param webModeler.websockets.nodeSelector can be used to select the nodes the websockets pods should run on
nodeSelector: {}
## @param webModeler.websockets.tolerations can be used to define pod tolerations, see https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/
tolerations: []
## @param webModeler.websockets.affinity can be used to define pod affinity or anti-affinity, see https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity
affinity: {}
## @extra webModeler.websockets.resources configuration of resource requests and limits for the container, see https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#requests-and-limits
## @param webModeler.websockets.resources.requests.cpu
## @param webModeler.websockets.resources.requests.memory
## @param webModeler.websockets.resources.limits.cpu
## @param webModeler.websockets.resources.limits.memory
resources:
requests:
cpu: 100m
memory: 64Mi
limits:
cpu: 200m
memory: 128Mi
## @extra webModeler.websockets.service configuration of the Web Modeler websockets service
service:
## @param webModeler.websockets.service.annotations can be used to define annotations which will be applied to the service
annotations: {}
## @param webModeler.websockets.service.type defines the type of the service, see https://kubernetes.io/docs/concepts/services-networking/service/#publishing-services-service-types
type: ClusterIP
## @param webModeler.websockets.service.port defines the port of the service
port: 80
## @extra webModeler.serviceAccount configuration for the service account the Web Modeler pods are assigned to
serviceAccount:
## @param webModeler.serviceAccount.enabled if true, enables the Web Modeler service account
enabled: true
## @param webModeler.serviceAccount.name can be used to set the name of the Web Modeler service account
name: ""
## @param webModeler.serviceAccount.annotations can be used to set the annotations of the Web Modeler service account
annotations: {}
## @param webModeler.serviceAccount.automountServiceAccountToken can be used to control whether the service account token should be automatically mounted
automountServiceAccountToken: false
ingress:
## @param webModeler.ingress.enabled if true, an Ingress resource will be deployed with the Web Modeler deployment. Only useful if an Ingress controller like NGINX is available.
enabled: true
## @param webModeler.ingress.className defines the class or configuration of ingress which should be used by the controller
className: nginx
## @param webModeler.ingress.annotations [object] defines the ingress related annotations, consumed mostly by the ingress controller
## @skip webModeler.ingress.annotations.ingress.kubernetes.io/rewrite-target
## @skip webModeler.ingress.annotations.nginx.ingress.kubernetes.io/ssl-redirect
## @skip webModeler.ingress.annotations.nginx.ingress.kubernetes.io/proxy-buffer-size
annotations:
ingress.kubernetes.io/rewrite-target: "/"
nginx.ingress.kubernetes.io/ssl-redirect: "true"
nginx.ingress.kubernetes.io/proxy-buffer-size: "128k"
## @extra webModeler.ingress.webapp configuration of the webapp ingress
webapp:
## @param webModeler.ingress.webapp.host defines the host of the ingress rule, see https://kubernetes.io/docs/concepts/services-networking/ingress/#ingress-rules; this is the host name on which the Web Modeler web application will be available
# Note: The value must be different from ingress.websockets.host
host: "webmodeler.camunda.XXXXXXXXXXXXXXX"
## @extra webModeler.ingress.webapp.tls configuration for TLS on the ingress resource, see https://kubernetes.io/docs/concepts/services-networking/ingress/#tls
tls:
## @param webModeler.ingress.webapp.tls.enabled if true, TLS will be configured on the ingress resource
enabled: true
## @param webModeler.ingress.webapp.tls.secretName defines the secret name which contains the TLS private key and certificate
secretName: camunda-tls
## @extra webModeler.ingress.websockets configuration of the websockets ingress
websockets:
## @param webModeler.ingress.websockets.host defines the host of the ingress rule, see https://kubernetes.io/docs/concepts/services-networking/ingress/#ingress-rules; this is the host name the Web Modeler client in the browser will use to connect to the WebSockets server
# Note: The value must be different from ingress.webapp.host
host: "websockets.camunda.XXXXXXXXXXXXXXX"
## @extra webModeler.ingress.websockets.tls configuration for TLS on the ingress resource, see https://kubernetes.io/docs/concepts/services-networking/ingress/#tls
tls:
## @param webModeler.ingress.websockets.tls.enabled if true, TLS will be configured on the ingress resource
enabled: true
## @param webModeler.ingress.websockets.tls.secretName defines the secret name which contains the TLS private key and certificate
secretName: camunda-tls
Your configuration file doesn’t seem to have anything wrong, the strange thing is that there is no error in the log, it just stays in the starting state as I understand it, have you checked that there is no service port conflict?
Starting the WebSocket server on port 8060...
New connection opened for app key XXXXXXXXXXXXXXXXXXXXXX.
Connection id 920359582.407541510 sending message {"event":"pusher:connection_established","data":"{\"socket_id\":\"920359582.407541510\",\"activity_timeout\":30}"}
web-modeler: connection id 920359582.407541510 received message: {"event":"pusher:ping","data":{}}.
Connection id 920359582.407541510 sending message {"event":"pusher:pong"}
web-modeler: connection id 920359582.407541510 received message: {"event":"pusher:ping","data":{}}.
Connection id 920359582.407541510 sending message {"event":"pusher:pong"}
(The log is always play ping-pong as a never ending story)
Where wants to go, could you please helm me with this information?
Maybe it is working fine?
Or as I saw from modelerwebapp configuration:
Anyway websockets ingress should work. From view of the ingress controller I can se logs regarding to it:
…[10/Apr/2024:16:07:54 +0000] “GET / HTTP/2.0” 404 …[camunda-camunda-web-modeler-websockets-80] 10.244.3.31:8060
Exec into websockets (port is opened):
/var/www/html $ netstat -ntlp
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:8060 0.0.0.0:* LISTEN 7/php
ps command:
/var/www/html $ ps -a
PID USER TIME COMMAND
1 1000 0:00 {docker-entrypoi} /bin/sh /docker-entrypoint.sh
7 1000 0:00 php /var/www/html/artisan websockets:serve --port 8060
10 1000 0:00 sh
17 1000 0:00 ps -a
/var/www/html $ wget 0.0.0.0:8060
Connecting to 0.0.0.0:8060 (0.0.0.0:8060)
wget: server returned error: HTTP/1.1 404 Not Found
Or there is a specific path where it is accessable?