Current "Best Practice" Native or docker?

[Bradford Harley]

I am rebuilding my ships computer to a 64bit os and realizing that if the old pi had most applications on docker, how much less work it would be...   So, what are general thoughts as to docker vs. native install for signalk-influx-grafana?

Thanks in advance

Brad

SV Perspective

[Greg Lions]

Hi Bradley,

I just did the same. I was running on a small x86 platform (Wyse 3040 ), but the emmc storage got burned up so ive reverted back to Rpi4. As i was in a big hurry to get this done, i switched to using the Openplotter image so was up and running very quickly. Note that Openplotter doesnt use Docker for Influx/Grafana but install is easy via its Installer.....

Cheers,

Greg

--
You received this message because you are subscribed to the Google Groups "Signal K" group.
To unsubscribe from this group and stop receiving emails from it, send an email to signalk+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/signalk/e3776d90-ffed-4c50-9e26-b379e2009ec9n%40googlegroups.com.

[Teppo Kurki]

I think both work, there is no single best practice. With OpenPlotter and BBN os using native Node I'd think that has most users.

In Docker:

+ you don't need to manage Node version separately and you'll get an updated Node with a server update

+/- upgrades (and rollbacks) are straightforward but not in the SK server admin UI

- no granular updates for server components (rerunning npm install of a native sk server will update all components like n2k-signalk to the current ones, image is fixed to how things were when built), you can't update Node separately

- plugins that access RPi specific hardware or software do not work (out of the box)

- using server setup script is not as straightforward

+ you can manage other software like Grafana with the same infra)

+ server is sandboxed and less susceptible to supply chain threats

To view this discussion on the web visit https://groups.google.com/d/msgid/signalk/CALjZkHg2rRJ_hsw3SUtKMJ%2BAODtOUvnamA_%2B%3DSUQaViz6EgoQw%40mail.gmail.com.

[Bradford Harley]

Teppo,

That's a great list of pros and cons.   I am an old unix/linux hack and build the system myself rather than relying on BBN or openplotter, so not terribly worried about general management.   I haven't played with Docker much and good to know the hardware interface is a bit of a hurdle.   I have it running both ways at the moment (native and containerized) and will play with the hardware interface to pican-m and usb devices.   I'll do a writeup if there is interest in it.

Brad

SV Perspective

To view this discussion on the web visit https://groups.google.com/d/msgid/signalk/CAOyOCEBeQ1nbODn1tstTX0uGVLc%2Bzi0kmFD-2iRYGaQhix0MJg%40mail.gmail.com.

[Teppo Kurki]

A few more points:

you avoid problems with serialport bindings, that seems to be a pretty frequent problem when people update their systems piecemeal. With Docker you get everything in the server proper in one package, avoiding inconsistencies.

Permissions between host and container are a bit of a dark art, same for networking if you need to go beyond exposing a few ports and outbound connections.

[Владимир Калачихин]

And Docker is twice as slow as native, and consumes twice as many resources. Raspberry is not a supercomputer, and electricity is not superfluous.

суббота, 17 декабря 2022 г. в 08:45:09 UTC+3, Teppo Kurki:

[Bradford Harley]

" And Docker is twice as slow as native, and consumes twice as many resources. Raspberry is not a supercomputer, and electricity is not superfluous.
"

I did a fair amount of investigation and have never seen any testing or studies that showed docker being twice as slow, nor consume twice as many resources as native on.  I don't even see that with a virtual machine on the pi.   Max penalty I saw was 13% for one type of IO, and most were within 5% of native.   Do you have anything to substantiate your claim? 

on to the thread, I've played with settings in docker and exposing the hardware is pretty straight forward.   
If you want to open everything up the --privileged flag allows that..
'docker run -d --init --name signalk-server --privileged --restart=unless-stopped -p 3000:3000 -p 10110:10110 -v signalk_data:/home/node/.signalk signalk/signalk-server'

If you want to open up just specific devices, here is an example that exposes just a USB gps.   
'docker run -d --init --name signalk-server --device=/dev/ttyACM0 --restart=unless-stopped -p 3000:3000 -p 10110:10110 -v signalk_data:/home/node/.signalk signalk/signalk-server'
I'll do a writeup and send it in.   I also can do a relative performance test using influx which is the largest load in my configuration.

[Teppo Kurki]

You’ll have to back that up with numbers.

My own experience does not agree (no noticeable difference between native and docker sk/influxdb/grafana) and googling for docker overhead gives you references to stuff that say ”very little cpu and ram overhead as docker is not virtualisation".

--
You received this message because you are subscribed to the Google Groups "Signal K" group.
To unsubscribe from this group and stop receiving emails from it, send an email to signalk+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/signalk/0cc24a8b-c4c7-4881-9034-bc12dda95254n%40googlegroups.com.

[Владимир Калачихин]

суббота, 17 декабря 2022 г. в 20:21:07 UTC+3, bradfor...@gmail.com:

I'll do a writeup and send it in.   I also can do a relative performance test using influx which is the largest load in my configuration.

That would be valuable.

I did not make instrumental measurements. And I haven't tried SignalK.

But the Dockerised GaladrielMap subjectively responds much slower than a native application.