ghost
commented
4 years ago I started looking at the docker-compose file yesterday as well (but I'm not a home-assistant software developer so my skillset is substantially more limited :smile: ). I didn't like that the existing docker-compose.yml ran as privileged. I know is needs access to the sdr dongles, but I didn't want privileged. So like you, I've been using:
devices:
- "/dev/bus/usb:/dev/bus/usb"I have multiple dongles, so pass the whole bus so they can all be accessed. Not what I'd want ideally but I'm guessing the goal behind the docker-compose is to have a "run and go" method.
I like that your version doesn't require a docker-build as it doesn't copy the talkgroups file in. In terms of keeping with the "run and go" would it make sense to move the talkgroups .csv files into their own /csv directory (or whatever) and then pass that as a volume and update the configuration file to source them from there? Then we could have multiple .csv and config.json could just pull them in from a directory.
My final thought was that I wasn't sure if we wanted to continue to run the docker container as root. That's generally not considered best practice as far as I know, but without that the user would have to configure permissions on the host to allow the docker user rw access to the sdr dongles. So it's not "fire and forget".
I would agree docker is the "easy" way to go with running trunk-recorder; mine is running on my Ryzen desktop but I've bought a NUC and will just copy a folder between the machines and docker-compose up when I move it to it's dedicated server. In the past I've tried to build it natively on Pi's but was converted over to being a docker person since my last run at trunk-recorder. Going docker this time was substantially easier.
robotastic
robbiet480
hayden-t
jp83
leee
Hi @robotastic,
Thought I should create a issue to continue work from https://github.com/robotastic/docker-gnuradio/issues/2. Now that I've figured out the path to get multiple architectures building properly, i'm working on improving the entire
trunk-recorderDocker ecosystem. This includes updating the two reposDockerfileto follow best practices, slimming them down as much as possible and improving the Docker Compose story. Unrelated totrunk-recorderspecifically, I'm also working on containerizing @chuot'srdio-scannerso that users can get a whole stack running with a single Docker Compose file and much faster too, especially for those on Raspberry Pi.I've created this issue because I was hoping to get the current lay of the land from you and @EricTendian. I see a lot of Docker issues in multiple repos but am unsure where my time is best spent so as to not duplicate work. So, a few questions to start:
en_US.UTF-8. Why? Can we stop doing that and just useCorC.UTF-8?docker-gnuradioand none of the extra cruft of this repo? I like keeping Docker images nice and small so its quick for users to get going.Here's the current Dockerfile I'm using which works nicely and hews to expected Docker standards:
And the new and improved
docker-compose.yaml, featuringrdio-scannersupport too:The big improvements to the Compose file are no more having to build a second image just for Compose, not having to run privileged mode and explicitly mounting CSVs instead of just copying everything over.
Once Docker is improved I strongly recommend that you suggest it as the premiere installation method for end users, especially those on Raspberry Pi, so that they don't have to deal with deps and compile times.
Excited to hear your thoughts and contribute to this fantastic project!