Closed dudefellah closed 4 years ago
First request seems reasonable and easily done.
Not really sure how to accomplish the second request, but I like the idea as well.
Feel free to do a PR with your suggested changes and we'll take a look
Hi @dudefellah and @LBegnaud just to add that the Netdisco container images were created by someone who never used containers/docker before (me!) so not surprising that they make strange assumptions about "standard" ways to use containers/docker.
I would be very happy indeed to have more people working on this config, and also happy to give commit access direct to people who are able to update and test.
I'm happy to supply a PR once I get a little bit of time.
For the point about logging, I'm sure that the best solution would be to configure the relevant logging libraries to spit out to the console and never write to a file. For the time being, it's always possible to create a symlink between the intended logfile (eg. /home/netdisco/logs/netdisco-backend.log) and point it to /dev/stderr or /dev/stdout.
Anyway, I'll send you something in the next few days and you can let me know what you think.
It seems to me that forcing the users to make changes to the host running the container defeats the whole purpose of running containers in the first place since it's impossible to run the relevant netdisco containers without first modifying the host system. If VOLUMES was removed, the users wouldn't be forced to mount volumes, but they would still have the option of doing so through volume mapping (which can also be included in your docker-compose.yml).
like https://github.com/netdisco/netdisco-docker/blob/a90bfc3a6c8c63e8e83e3e4c68e5a52d04d45127/docker-compose-win.yml or am i totally missing the point here?
with our current architecture however we do need a place to store the mibs & config file where the containers can get to them.
@inphobia it should certainly be something you could use with docker-compose, or even with a command-line volume mapping (eg. docker -v "$(pwd)/mypath:/container-path" ...). In both of these cases though, the user optionally maps the volumes however they'd like. The use of VOLUMES inside the Dockerfile forces the user to map those volumes whether they like it or not.
Any user who might like to take netdisco for a spin, but not necessarily commit to anything would probably enjoy just bringing up the containers and playing around without having to modify anything on their end.
The use of VOLUMES inside the Dockerfile forces the user to map those volumes whether they like it or not.
perhaps i'm just thickheaded and not seeing the issue, but...
netdisco requires a database for everything, but where will the postgres container store it's data if no volumes are mapped? for the backend we need storage for at least the mib files.
granted, i don't know enough about docker, but i do know that without a database & and mibfiles netdisco won't do anything.
what do you think the options should be?
i think we're discussing this too much, but to clarify:
docker-compse down
without losing that data. But, as long as the container exists (docker-compose down deletes the container), it will persist any changes
seems like a no-brainer to remove the VOLUMES
inside the Dockerfile
, but preserve the instructions as they are now. If someone blindly follows the instructions, they'll have persistent volumes, but someone with a bit more docker knowledge can go around that for quick testing.
I'd be happy to be given merge capabilities and handle this. I recently installed 1903 so I can work on the other PR from @inphobia about Windows 10 instructions.
Hi,
I'm curious if there any plans on removing the VOLUMES (and as a side-effect, the need to add a user/group account on the host system in Linux) from the docker containers?
It seems to me that forcing the users to make changes to the host running the container defeats the whole purpose of running containers in the first place since it's impossible to run the relevant netdisco containers without first modifying the host system. If VOLUMES was removed, the users wouldn't be forced to mount volumes, but they would still have the option of doing so through volume mapping (which can also be included in your docker-compose.yml).
Also, on a slightly related topic, it would be nice if the container logs were spat out to stderr instead of a logfile on disk. This would fit in line with the way other containers are run (and play nicely with tools like docker logging drivers) while also taking away one of the uses of one of those mapped filesystem paths.