bmoers / docker-mid-server Goto Github PK

Getting stuck in a CrashLoopBackOff when trying to deploy with Kubernetes.

Here is my yaml file

apiVersion: apps/v1
kind: Deployment
metadata:
   name: mid-server-dev
   labels:
      app: mid-server-dev
spec:
   replicas: 1
   selector:
      matchLabels:
         app: mid-server-dev
   template:
      metadata:
         labels:
            app: mid-server-dev
      spec:
         containers:
         - name: mid-server
           image: moers/mid-server:madrid.latest
           env:
              - name: HOST
                value: midserverdev
              - name: USER_NAME
                value: miduser
              - name: PASSWORD
                value: 'midpass'
           imagePullPolicy: Always

Here are the events

Normal Scheduled 9m59s default-scheduler Successfully assigned default/mid-server-dev-767cf45b57-xdqwt to k8s-worker-02
Normal Pulled 8m52s kubelet Successfully pulled image "moers/mid-server:paris.latest" in 1m6.391426568s
Normal Pulled 8m44s kubelet Successfully pulled image "moers/mid-server:paris.latest" in 746.891844ms
Normal Pulled 8m26s kubelet Successfully pulled image "moers/mid-server:paris.latest" in 1.016216712s
Normal Created 8m1s (x4 over 8m47s) kubelet Created container mid-server
Normal Started 8m1s (x4 over 8m46s) kubelet Started container mid-server
Normal Pulled 8m1s kubelet Successfully pulled image "moers/mid-server:paris.latest" in 780.482185ms
Normal Pulling 7m10s (x5 over 9m58s) kubelet Pulling image "moers/mid-server:paris.latest"
Warning BackOff 4m52s (x19 over 8m43s) kubelet Back-off restarting failed container

Here is the processor architecture
Linux k8s-master 5.4.0-1023-raspi #26-Ubuntu SMP PREEMPT Thu Nov 12 14:58:33 UTC 2020 aarch64 aarch64 aarch64 GNU/Linux

Any suggestions on getting this to work on a Pi?

Any chance of Windows mid server docker images?

I am seeing an issue while running orlando.08-28-2020_1009 image
The service comes up and registers but it fails to send the config.
If I install the ping utility in the docker container then it starts working.

I'm excited to try this and just have it work.

Do you have plans to update this to start form utah or vancouver instead of tokyo?

I was looking at the the app.js and noticed you're pointing to the old version of the docs to get the scrape the family data.

Im trying to install nodejs but mid account seems like it doesn't have enough privilege. Are there other accounts/passwords I can use to install packages? Or is there a better way of installing additional requirements?

I am seeing an issue while running orlando.08-28-2020_1009 image
The service comes up and registers but it fails to send the config.
If I install the ping utility in the docker container then it starts working.

Usually, when creating a mid server container, it starts doing an upgrade. After that I manually rekey it and that's it. This worked with quebec and all before them. With sandiego however the container restarts endlessly after what looks like an unsuccessful upgrade. In Servicenow the mid server alternates endlessly between "Upgrading" and "Down" status.

The command used to create the container:
sudo docker run -d --name servicenow_mid --restart unless-stopped --env SN_HOST_NAME=acme.service-now.com --env USER_NAME=acme-mid --env PASSWORD=**** moers/mid-server:sandiego.latest

The user has the roles "mid_server" and "snc_internal", only allowed for webservices. To avoid any local permission issues, I temporarily made the user an admin.

There are a number of warnings in the logs (see attachment). Among those:

AutoUpgrade.3600 WARNING *** WARNING *** Unable to determine upgrade scenario with current=sandiego-12-22-2021__patch9a-hotfix1-01-31-2023_02-01-2023_1625 assigned=sandiego-12-22-2021__patch9a-12-12-2022_01-04-2023_0931

Maybe that's an indication ?

Is there something I can check to fix this issues ?

THX

Maybe related to this issue, the shutdown doesn't seem to complete gracefully. The typical last lines in the logs are:

03/02/23 09:25:24 (742) MIDServer MID Server stopped
03/02/23 09:25:24 (742) MIDServer the ServiceNow MID Server is now terminated
DOCKER MONITOR: /opt/agent/logs/agent0.log.0 last updated 6 sec ago
...
DOCKER MONITOR: /opt/agent/logs/agent0.log.0 last updated 307 sec ago
DOCKER MONITOR: /opt/agent/logs/agent0.log.0 was not updated for 300sec, MID server potentially frozen.
DOCKER MONITOR: Stopping MID server process 1 now!
DOCKER: Stop MID server

It always restarts because the logs are too old. Even though /opt/agent/work/mid.pid is gone. But maybe that's the intention.

PS. Great work ! It's so much easier for managing mid servers !

This looks really cool Boris! However I'm getting a error:

docker pull moers/mid-server

Using default tag: latest
Error response from daemon: manifest for moers/mid-server:
latest not found: manifest unknown: manifest unknown

Looking in it myself and will update when found solution.

Deploying rome.latest fails during the upgrade step due to root:root permissions on /opt/agent/lib/log4j-core.jar:

/opt/agent/logs/dist_upgrade.log.0 shows:

09/05/22 08:34:34 (936)  |  INFO  |  /opt/agent/lib/log4j-core.jar cannot be deleted: /opt/agent/lib/log4j-core.jar (Permission denied)
586706ms left to timeout for deleting files. Retrying in 1000ms...
09/05/22 08:34:35 (937)  |  INFO  |  /opt/agent/lib/log4j-core.jar cannot be deleted: /opt/agent/lib/log4j-core.jar (Permission denied)
585705ms left to timeout for deleting files. Retrying in 1000ms...

Loops for 300s, resulting in container death:

DOCKER MONITOR: /opt/agent/logs/agent0.log.0 last updated 320 sec ago
DOCKER MONITOR: /opt/agent/logs/agent0.log.0 was not updated for 300sec, MID server potentially frozen.
DOCKER MONITOR: Stopping MID server process 1 now!
DOCKER: Stop MID server
ServiceNow MID Server is not running.

Permissions within /opt/agent/lib/:

-rwxr-xr-x.  1 mid  mid    301872 Jul 21 12:39 log4j-api.jar
-rwxr-xr-x.  1 root root  1770485 Jul 30 20:17 log4j-core.jar
-rwxr-xr-x.  1 mid  mid     23702 Jul 21 12:39 log4j-over-slf4j.jar

I suspect line 63 is the cause due to running after a chown -R mid:mid /opt/* on line 33:

Adding this line below 63 and rebuilding the image does resolve the issue:

RUN chown mid:mid /opt/agent/lib/log4j-core*.jar

It is likely there is a more elegant solution, but this has worked for us.