docker config that works on windows10 1903

[inphobia]

seperate compose files to make containers work under windows10, with matching documentation.

biggest change is using local volumes for persistent storage to work around credentials/filesystem interaction.

basic functions all work: starting/stopping/changing config scheduling works/discovery/arpnip/speudo devices/updating stats/etc. ....

not yet tested with snmpv3 with priv+enc. sshcollector will most likely not work due to lack of ssh binary, but this goes for the linux version too.

docs are seperate for now and not yet linked from README.md

[LBegnaud]

in general it's a good idea to use docker local volumes vs shared folders... but what's this about missing ssh binary? Are you using docker for windows or windows docker? the first should be equivalent to regular docker, and images would have all the same binaries when you pull them.

[LBegnaud]

i really question the need to have two separate docker-compose files. Using local volumes should work for any purposes. It's really kind of a hack to expose local folders directly and manipulate them while the container is running. Much easier to load the netdisco-do container and link it to a local volume than to shared folders.

In general your changes here are pretty substantial, can you help me out and give a rough TL;DR ? Best i can tell these are probably just changes we should make for the generic instructions as well.

[inphobia]

in general it's a good idea to use docker local volumes vs shared folders... but what's this about missing ssh binary? Are you using docker for windows or windows docker? the first should be equivalent to regular docker, and images would have all the same binaries when you pull them.

about the ssh binary, net::openssh requires the actual binary but i couldn't find any reference in netdisco-base/Dockerfile to actuallly install it.

and i'm running windows 10 as os, but with docker & linux containers.

in the end one version of our container stuff would be prefered , but i can't see what the pro's and cons of my changes are , other that it works for me :)

[LBegnaud]

i'm not actually familiar with using net::openssh in netdisco, but i'd be really surprised if windows10 docker container worked any differently than a native linux docker container.

if the image is missing an ssh client, it probably needs to be added to the base DockerFile

per this simple project, we probably do need to add apk add openssh-client

Can you add that to your fork and rebuild to see if it works as expected?

If so, i think we could condense the instructions here to include the groupadd and whatnot if one wants to use symlinked folder shares and then a generic docker-compose-local.yml that would work for linux and windows systems that just uses native docker local storage.

Finally, if all that is the case, you can probably squash your fork and have a clean PR?

[inphobia]

i really question the need to have two separate docker-compose files. Using local volumes should work for any purposes. It's really kind of a hack to expose local folders directly and manipulate them while the container is running. Much easier to load the netdisco-do container and link it to a local volume than to shared folders.

with the "2 seperate compose files", are you referring to the windows<->linux split or the fact we have a compose file for netdisco-do?

if it's about the linux<->windows split, then i would prefer to somehow merge them. the thing i wasn't sure about is if changing the way persistent storage was handled would be appreciated.

if it's about the reason to have a seperate compose file for netdisco-do, well, i've been wondering about that myself too. if it were up to me i would just include that in netdisco-backend & use something like docker exec -it __containerid__ /home/netdisco/bin/netdisco-do or whatever. starting a new container each time to run netdisco-do seems like a lot of overhead to me.

In general your changes here are pretty substantial, can you help me out and give a rough TL;DR ? Best i can tell these are probably just changes we should make for the generic instructions as well.

sure, but there are several reasons which vary wildly.

• i noticed we started getting quite some issue reports about docker specific issues, but found it hard to reproduce them, even more so since my workstation is win10. but since build 1903 & higher has explicit support for linux containers on windows i thought it would be easiest to just go that path to debug stuff.
• when looking over those issues i found the docker documentation inconsitent (like #14 i find references in the official docs to both single & double quotes....), thought it would be easier to rewrite it (which it wasn't 😄 )
• i tend to do most my coding on windows with intellij idea + wsl support, which works quite well but not perfect. being able to add containerized test at the end of my build pipeline seemed interesting.
• in the long term i would also like to expand the netdisco regress framework, but for that i need to be able to have fixed input data (like having an snmpsim container which always returns the same values for snmp queries, so after a commit you can check if the returned data has changed and if that was the plan).

i would like to get somewhere that works on most platforms without specific steps, but that will mean loosing features (on opensuse with btrfs you can get nice deduplication of data, snapshots, etc...). but perhaps the audience that cares about that could most likely rewrite the dockerfiles to make it work anyway. i also have not taken into account any management frameworks to manage containers on a wider scale.

i guess the bottom line for me was to try & make a consistent version of netdisco that could be run without to much hassle, not to make it scale out or have live upgrades like most containers are meant to do.

[inphobia]

i'm not actually familiar with using net::openssh in netdisco, but i'd be really surprised if windows10 docker container worked any differently than a native linux docker container.

at least on windows 10 1903 if you run linux containers on windows it will spin up a linux machine in hyper-v in the background, which has some strange side effects:

• unix sockets are hard to get to work right due to limitations
• sharing filesystems can be tricky due to different acl mechanisms
• etc...

[LBegnaud]

Per your first comment I think most of the things you're asking this set of images to do it already does.

The two separate files i was referring to was one for linux and one for windows. Maybe we just keep the current docker-compose as the standard, and provide some notes about using local containers instead.

I'm all for getting rid of the netdisco-do docker-compose file altogether. It seems completely unnecessary. But we should make a separate issue to discuss that.

to your second comment. I think the biggest problem here really is filesystem sharing, but yes meta docker things do tend to be wonky on other non-linux platforms.

So to summarize this current situation.

• I think we need to add openssh-client (tracked in the issue you reopened and should probably make a simple PR to handle that separately)
• I think we need to cleanup the documentation to indicate that symlink method of mounting paths in the containers is only really feasible on linux (and if the specific permissions are set properly), otherwise use a generic docker-compose-local-vols.yml