Docker status #365
Comments
|
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 😄 ). 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: 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. |
|
@robbiet480 Thanks so much for looking into this! Improving Docker support has been on my list of things to do for a long time. I agree - once this is buttoned up, this should be the primary way of running Trunk Recorder. I can look at setting up an automated build pipeline so it automatically spits out new multi-arch images when there is a push to the repo. It may take a little EC2 time, but totally worth it. I actually just started messing around with buildx too, so all in on this approach. More detailed:
For the Pi - It could be interesting to look at https://www.balena.io as a way to push and manage Docker images on the Pi. Thanks again for digging into this! |
|
@jquagga Thanks for your feedback here. I knew I forgot to do something when building the new Dockerfile... will push a fix to run as non-root. I don’t believe the user will need to do anything with permissions to pass in the device but will check it out. As for the CSV thing, I like it this way, only because it’s the most flexible option. If users want a folder, they can mount a folder and update their config to point to the mounted path. @robotastic I’d suggest using a GitHub action to do builds since it’s just so easy to use. This one looks perfect and is plug and play. As for your responses, a few things:
|
|
Cool - I didn't realize the GitHub actions included some compute time. I will work on getting that going, and that action you linked to looks like a good starting point. since it is running on Githubs compute, the long build time isn't the end of the world, esp since there are not that many commits. I will go checkout the openmhz code. It was suppose to check for duplicate system shortnames... clearly broken though. |
|
@robotastic Did you get anywhere with determining if we can do static builds? That's probably the second biggest thing holding up progress & optimization, after getting GNURadio 3.8 building. |
|
#366 is ready for review. We should get that GNURadio Docker image merged before merging #366. Honestly though, I was thinking if its a good idea to continue building GNURadio and |
|
Oh yeah, we should absolutely attempt to get static builds going still. The latest image size (with GNURadio 3.8) is 1.92GB. If we got static builds going, we could probably get to under 100mb. Just tried to get static builds going following the path of #226 but no go thus far. Probably going to take serious work from @robotastic but will be well worth it I think. I sadly don't know enough about C compilers to figure out how to build a static binary that also includes all the deps. |
|
Thanks for patching up the Docker script - I just got something similar working on GitLab and was going to turn to this. I will go work on Static linking right now. I am not sure if we need to even worry about building GnuRadio. I think I was doing that because the version of gnuradio that used to be in the apt-get repo was so old. It is probably better to just install GR using apt-get. Maybe we could keep a bleeding edge version that would compile gnuradio from src nightly to test against. |
|
Would also agree that we should continue doing apt-get for GNURadio. |
|
Ok... slight wrinkle... I have everything building staticly, except when it gets to all the gnuradio libs. and if you install them using apt-get, you only get shared libraries. It looks like if you want static libraries, you have to build grnuadio from source. You can use this flag: ENABLE_STATIC_LIBS |
|
Not the worst idea to build GNURadio from scratch if it means we also can drop any GUI requirements. That would be a HUGE size savings and almost certainly get things starting up faster too. |
|
Just doing |
|
Ok, question on this one. I was trying to help someone in the gitter get docker going on their pi which meant they were trying to use the updated guide in wiki. I've been using the "legacy" trun-recorder-docker image but thought I'd give the new spin I go. Using the default docker-compose now listed on the wiki (the one which runs as nobody and doesn't build a new image) with the :edge image as of today tosses an error that it cannot find config.json. I think this is because the changes to the docker image now put the recorder binary into /recorder, but does not pass a I have another docker image next to this one running audioplayer.php so I have to adjust paths in that to match the new docker setup. Before I do that, I wanted to confirm which way this was going to go. |
|
Frick. Good catch @jquagga. Will submit a PR to hardcode looking for config at Good reminder for me btw: @robotastic You still need to cut a new release of |
|
@robotastic To get TR build going, ou just need to cut a 1.0 of gnuradio repo then restart the trunk-recorder build. Its trying to grab |
|
wheres the armv7 docker image at ? |
It's set to build but for some reason failing when building on top of the GNURadio image. Looking into it now. |
|
We're being bit by this issue in CMake. |
|
any old docker images i can get ? |
|
Nope, armv7 was never properly built. Will have a fix late today probably. |
|
oh ok, that would be neat ! thanks |
|
@hayden-t @robotastic just merged #448 so in the next hour or so you should see valid armv7 images live on his Docker Hub as v3.3.2. |
|
@hayden-t |
|
ok i got it, and tried to run it, i will open support ticket seperately |
|
can you help #450 |
|
Sorry to tack on here, but I can't get docker usb permissions to work with the latest Docker images. I have my own really old Docker build based on previous image that I overlaid and copied in my own config a year or two ago, but something underlying must have changed. I previously had --privileged -v /dev/bus/usb:/dev/bus/usb. I've tried --device /dev/bus/usb and --device-cgroup-rule 'a : rwm'. I keep getting the usual: Using device #0 Generic RTL2832U OEM I understand from the FAQ to git rtl-sdr and build it, but shouldn't that be built into the image from Dockerfile? What am I missing? I happen to be running on a small thin client machine with Rancher OS, lightweight operating system. For reference I just got openwebrx docker image running with my rtl-sdr out-of-the-box. Please help. Thanks. |
|
Even though this issue was about Docker, the purpose and original use of this issue was for growing Docker support, not providing support on Docker issues. The comments in March probably could've been a new thread, so lets keep closed issues closed. @jp83 as for your issue, I think it deserves a new issue of its own - would you be willing to create one? I also think referencing which openwebrx image you use (and the Dockerfile for it) could also be especially helpful for @robbiet480 or whoever wants to take up the fix. Thanks! |
|
Understand, opened #461. |
Hi @robotastic,
Thought I should create a issue to continue work from robotastic/docker-gnuradio#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!
The text was updated successfully, but these errors were encountered: