Trying to get this up in a docker-swarm with swarm-launcher

[sxiii]

Hi @feelingsurf

I wonder why did you removed the HEALTHCHECK; it actually worked in my docker-swarm when I launched containers by hand pretty well?

The main question is this:

I am trying to make working and stable instance of docker-viewer with a help of @tlex from this swarm-launcher tool:

ix-ai/swarm-launcher#7

The idea is no have a container that goes via VPN (OpenVPN). So let's say we run 1 container on 1 nodes (having several laptops with docker; for example; in my case) - and each container connects to VPN on it's own (to a different servers) and then runs a feelingsurf-viewer.

The swarm-launcher is used because docker does not allow you to launch containers in privileged mode on a nodes; and when you don't do it; the nodes cannot use OpenVPN and establish a tunnel to VPN services.

My current problem is that containers, when launched from swarm-launcher, are constantly restarting, probably because the networks are not matching between swarm-launcher and the chromium (feelingsurfviewer) itself. Or maybe because the healthcheck is just globally broken I don't know?

Any ideas on this?

Thanks a lot.

Den

[feelingsurf]

Hello @sxiii,

HEALTHCHECK is still available in the stable docker image and works most of the time.

In newer version (docker tag unstable) we have decided to remove the health check as it was not correctly detecting app crashes in certain conditions.

Regarding the issue with your setup, I believe you should not need to run the container in privileged mode. Adding --cap-add SYS_ADMIN in the docker run command should be enough.

[sxiii]

Hi @feelingsurf .

Yes, I am already running it with --cap-add NET_ADMIN. Does it differs somehow from SYS_ADMIN? I will test this out.

The thing is that running in a swarm is different as we don't have the privileged options as well as not having the cap-add options. So, I need to use the ix-ai/swarm-launcher to run privileged containers on the hosts. This make the case a little bit harder.

I need a swarm because I have 20 to 30 +/- physical servers and running around them would be a real hassle.

I will test with SYS_ADMIN through ix-ai/swarm-launcher. I'll comment if it helped.

Thanks
Den

[sxiii]

Hi @feelingsurf

Can you please elaborate more on "healthcheck not correctly detecting app crashes in cetrain conditions"? (q#1)

Also; would healthcheck work if I use newer FSVIEWER version 1.3.1 while still having the HEALTHCHECK active in dockerfile? (q#2)

Last question#3, is it possible to use AppImage file inside of the container? If I make my own alpine-based container; and add AppImage there; would it accept my token as argument or not?

Thanks

[feelingsurf]

Hello @sxiii,

Can you please elaborate more on "healthcheck not correctly detecting app crashes in cetrain conditions"? (q#1)

The health check feature was meant to give a reliable way to know if the app inside the container was working or not. Unfortunately we were facing cases where Chromium renderer would crash and not the main process which was leading to a healthy state despite the app not working normally. As we found no fix for this issue we decided to remove the health check feature.

Also; would healthcheck work if I use newer FSVIEWER version 1.3.1 while still having the HEALTHCHECK active in dockerfile? (q#2)

Healthcheck won't work in viewer > 1.3.0 as it was removed. Btw you should not use 1.3.1 as it was not published as a stable release yet.

Last question#3, is it possible to use AppImage file inside of the container? If I make my own alpine-based container; and add AppImage there; would it accept my token as argument or not?

We have not tested this case.

Best regards

[sxiii]

Hi @feelingsurf. Thanks for your precise answer.

I am thinking also about removing healthcheck and just make the containers be automatically killed ones in a while (each 30 or 60 minutes maybe) -> that might be a simpler way to maximize the project stability. Do you have any idea on restart timing that you would recommend?

I've tested the case with both AppImage and ZIP archive. In both cases it works perfect if launched like this for the AppImage:
access_token=TOKEN ./FeelingSurfViewer-linux-x86_64-1.3.0.AppImage
or, accordingly for the ZIP:
access_token=TOKEN ./FeelingSurfViewer

I see Alpine Linux as the best container base; faster and smaller than others. So I will test it out!

UPDATE: your sources are built against glibc (of course!); while Alpine uses musl by default. There are some Alpine images with glibc by default and there is even ready-made packages of glibc that can be easily added to alpine. I've tested both approaches (using docker image with glibc support and adding package manually); most of the library errors gone; but these I can't beat:

Error log

Error relocating /usr/bin/libffmpeg.so: __isnan: symbol not found
Error relocating /usr/bin/libffmpeg.so: __isinf: symbol not found
Error relocating /usr/bin/libffmpeg.so: strtoll_l: symbol not found
Error relocating /usr/bin/libffmpeg.so: strtoull_l: symbol not found
Error relocating /usr/bin/FeelingSurfViewer: __fdelt_chk: symbol not found
Error relocating /usr/bin/FeelingSurfViewer: __sbrk: symbol not found
Error relocating /usr/bin/FeelingSurfViewer: __res_nclose: symbol not found
Error relocating /usr/bin/FeelingSurfViewer: __res_ninit: symbol not found
Error relocating /usr/bin/FeelingSurfViewer: __vsnprintf_chk: symbol not found
Error relocating /usr/bin/FeelingSurfViewer: __isnan: symbol not found
Error relocating /usr/bin/FeelingSurfViewer: __isinf: symbol not found
Error relocating /usr/bin/FeelingSurfViewer: __isnanf: symbol not found
Error relocating /usr/bin/FeelingSurfViewer: strtoll_l: symbol not found
Error relocating /usr/bin/FeelingSurfViewer: strtoull_l: symbol not found
Error relocating /usr/bin/FeelingSurfViewer: backtrace: symbol not found
Error relocating /usr/bin/FeelingSurfViewer: __strncat_chk: symbol not found
Error relocating /usr/bin/FeelingSurfViewer: __longjmp_chk: symbol not found
Error relocating /usr/bin/FeelingSurfViewer: __fprintf_chk: symbol not found
Error relocating /usr/bin/FeelingSurfViewer: __sprintf_chk: symbol not found
Error relocating /usr/bin/FeelingSurfViewer: initstate_r: symbol not found
Error relocating /usr/bin/FeelingSurfViewer: random_r: symbol not found
Error relocating /usr/bin/FeelingSurfViewer: __isinff: symbol not found
Error relocating /usr/bin/FeelingSurfViewer: __vfprintf_chk: symbol not found
Error relocating /usr/bin/FeelingSurfViewer: __snprintf_chk: symbol not found
Error relocating /usr/bin/FeelingSurfViewer: gnu_get_libc_version: symbol not found
Error relocating /usr/bin/FeelingSurfViewer: __register_atfork: symbol not found
Error relocating /usr/bin/FeelingSurfViewer: __longjmp_chk: symbol not found

I wonder if you can recompile the chromium/electron against musl (it's possible; as Alpine has nicely working chromium in it's repos) and share the binary with me?

These are patches required for electron to compile on musl: https://github.com/12101111/overlay/tree/master/dev-util/electron/files/6.1.6/chromium

UPDATE 2: I was able to unpack your electron app's asar file and get the sources; so now I will try to repack them into electron compiled against musl on alpine.

[feelingsurf]

@sxiii restarting the containers every hour seems like a good idea.

Regarding musl we do not want to compile electron ourselves and prefer to stick to official pre-built releases as it's one of the reason why we based our app on Electron.

[sxiii]

Understood, @feelingsurf. Thanks for answering. I will update this thread if I manage to add auto-restart. (meanwhile; I wasn't able to build electron for alpine (yet?)).