Hello All,
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
Domingos_Dias
Do you have idea?
Thanks a lot
Can you show the full log?
Can you share your configuration file?
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
From deployment point of view:
containers:
- name: web-modeler-websockets
image: >-
XXXXXXXXXXXXXXXXXXX/web-modeler-ee/modeler-websockets:8.4.3
ports:
- name: http
containerPort: 8060
protocol: TCP
env:
- name: APP_NAME
value: Web Modeler WebSockets
- name: PUSHER_APP_ID
valueFrom:
configMapKeyRef:
name: camunda-web-modeler
key: pusher-app-id
- name: PUSHER_APP_KEY
valueFrom:
configMapKeyRef:
name: camunda-web-modeler
key: pusher-app-key
- name: PUSHER_APP_SECRET
valueFrom:
secretKeyRef:
name: camunda-web-modeler
key: pusher-app-secret
- name: PUSHER_APP_CLUSTER
value: web-modeler
resources:
limits:
cpu: 200m
memory: 128Mi
requests:
cpu: 100m
memory: 64Mi
livenessProbe:
tcpSocket:
port: http
initialDelaySeconds: 10
timeoutSeconds: 1
periodSeconds: 30
successThreshold: 1
failureThreshold: 5
readinessProbe:
tcpSocket:
port: http
initialDelaySeconds: 10
timeoutSeconds: 1
periodSeconds: 30
successThreshold: 1
failureThreshold: 5
terminationMessagePath: /dev/termination-log
terminationMessagePolicy: File
imagePullPolicy: IfNotPresent
securityContext:
privileged: false
runAsUser: 1000
runAsNonRoot: true
readOnlyRootFilesystem: true
allowPrivilegeEscalation: false
restartPolicy: Always
terminationGracePeriodSeconds: 30
dnsPolicy: ClusterFirst
securityContext:
runAsNonRoot: true
fsGroup: 1000
schedulerName: default-scheduler
strategy:
type: RollingUpdate
rollingUpdate:
maxUnavailable: 25%
maxSurge: 25%
revisionHistoryLimit: 10
progressDeadlineSeconds: 600
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?
Exactly. There is no service port conflict:
camunda-web-modeler-restapi ClusterIP 10.0.184.95 <none> 80/TCP,8091/TCP 29h
camunda-web-modeler-webapp ClusterIP 10.0.208.139 <none> 80/TCP,8071/TCP 29h
camunda-web-modeler-websockets ClusterIP 10.0.137.130 <none> 80/TCP 29h
Is there env variable for DEBUG log level?
I think you can use: APP_DEBUG: “true” in the environment variables, at least that’s how I do it in docker
Finally I saw something:
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:
- name: CLIENT_PUSHER_HOST
value: websockets.camunda.XXXXXXXXXXXXXX
- name: CLIENT_PUSHER_PORT
value: '443'
- name: CLIENT_PUSHER_FORCE_TLS
value: 'true'
- name: CLIENT_PUSHER_KEY
Necessary some certificate for webapp?
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?